Menu
▾
▴
basilisk-devel — Basilisk II development-related discussion
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(42) |
Oct
(17) |
Nov
(7) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(14) |
Feb
(8) |
Mar
(13) |
Apr
(10) |
May
(28) |
Jun
(28) |
Jul
(23) |
Aug
(7) |
Sep
(2) |
Oct
(24) |
Nov
(9) |
Dec
(2) |
| 2002 |
Jan
(58) |
Feb
(15) |
Mar
(57) |
Apr
(26) |
May
(7) |
Jun
|
Jul
(10) |
Aug
|
Sep
(19) |
Oct
(9) |
Nov
(6) |
Dec
(4) |
| 2003 |
Jan
(4) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(14) |
Jun
(3) |
Jul
(7) |
Aug
(4) |
Sep
(7) |
Oct
(4) |
Nov
(11) |
Dec
(3) |
| 2004 |
Jan
(32) |
Feb
(21) |
Mar
(3) |
Apr
(11) |
May
(33) |
Jun
(42) |
Jul
(46) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(42) |
Dec
(23) |
| 2005 |
Jan
(5) |
Feb
(2) |
Mar
(12) |
Apr
(26) |
May
(8) |
Jun
(18) |
Jul
(21) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(10) |
Dec
(1) |
| 2006 |
Jan
(17) |
Feb
(17) |
Mar
(3) |
Apr
(2) |
May
(2) |
Jun
(7) |
Jul
(6) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(7) |
Dec
(4) |
| 2007 |
Jan
(6) |
Feb
(4) |
Mar
|
Apr
(3) |
May
(7) |
Jun
(17) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
| 2008 |
Jan
(14) |
Feb
(2) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
(22) |
Mar
(3) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
(15) |
Sep
|
Oct
(32) |
Nov
(9) |
Dec
|
| 2010 |
Jan
(18) |
Feb
(2) |
Mar
(14) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(7) |
Sep
(6) |
Oct
(35) |
Nov
(4) |
Dec
|
| 2011 |
Jan
(4) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(9) |
Oct
|
Nov
|
Dec
(4) |
| 2012 |
Jan
(4) |
Feb
|
Mar
(8) |
Apr
(9) |
May
|
Jun
(176) |
Jul
(86) |
Aug
(20) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(13) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
|
From: <jea...@pa...> - 2005-07-01 12:59:50
|
Would in the 2.3 release of SS for windows also the adobe-altivec problem= be solved ? And if so, is a public download to be expected soon ? Thx. >----- Oorspronkelijk bericht ----- >Van: Gwenole Beauchesne [mailto:gb....@fr...] >Verzonden: donderdag, juni 30, 2005 07:52 PM >Aan: bas...@li... >Onderwerp: [B2-devel] Planning for SheepShaver 2.3 > >Hi, > >We can also release a SheepShaver 2.3 soon. Issues left: > >General: >- Audio is not automatically enabled with NewWorld ROMs and MacOS >=3D=20 >8.6. There are workarounds through the "Audio" control pannel IIRC. So,=20 >that's not release critical. >- Ethernet doesn't work in DIRECT_ADDRESSING mode yet. >- We need to find a way to sanely abort if people are trying to use=20 >MacOS < 8.5 with NewWorld ROMs. Or is it supposed to work? > >MacOS X: >- I have no news for the Tiger problems. >- There is no GUI nor CoreGraphics used yet. That's not important to=20 >make a release since we can link with libSDL.a. >- Add support for Mach/i386 relocations to dyngen to have JIT working=20 >on x86. >- Build with -mdynamic-no-pic. > >Windows: >- Fullscreen DGA doesn't work >- Integrate new GTK+2 based GUI > >I committed some important bug fixes recently which improves stability=20 >everywhere. However, there may be regressions so some more testing=20 >needs to be done. Especially for clean installs. I only have 8.1, 8.6,=20 >9.0 handy and I again forgot to bring back 7.1.2. > >Again, spinning release candidates could bring more build/application=20 >testers. > >Since roadmaps are a hype thing to tell nowadays, here are the features=20 >planned for 3.0: >- Make InputSprockets work but I have absolutely no idea how. >- Now that SheepShaver reached a decent stability level in CVS, I could=20 >get back to the JIT in the future. AFAICS, it's not difficult to bring=20 >in a 2x speed increase and thus reaching 30% of native speeds. 40+ is=20 >possible but I am not sure yet how/if the profiler will work correctly.=20 >;-) Just need some time to merge all current bits and experiments +=20 >dump remaining techniques out of my head. >- Host CPU sw assisted OpenGL rendering. Easy to do but simply=20 >boring/tedious to handle and check all thunks. Aranym people did it=20 >though. I have to think again for hwaccel through 3D cards.=20 >Synchronization won't be trivial and offscreen rendering is not really=20 >effecient IIRC and depends on certain cards+drivers. > >Bye, >Gwenol=E9. > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id 492&opclick >_______________________________________________ >basilisk-devel mailing list >bas...@li... >https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > |
|
From: Gwenole B. <gb....@fr...> - 2005-07-01 09:39:55
|
Le vendredi, 1 jul 2005, =E0 00:00 Europe/Paris, Michael Dickison a = =E9crit=20 : > Yup, paranoia works! But I tried compiling the CVS today and I get the=20= > following error: > > g++ -I../include -I. -DHAVE_CONFIG_H -D_REENTRANT=20 > -DDATADIR=3D\"/usr/local/share/SheepShaver\" -g -O2 -I/sw/include/SDL=20= > -D_THREAD_SAFE -c main_unix.cpp -o obj/main_unix.o > main_unix.cpp: In function `void TriggerInterrupt()': > main_unix.cpp:1517: error: 'idle_resume' was not declared in this = scope > make: *** [obj/main_unix.o] Error 1 You generally need to update the Basilisk II tree as well. ;-) >> Please tell me your screen depth. Since you could build from sources,=20= >> I'd also appreciate to know the video modes reported by SDL (#define=20= >> DEBUG 1 in video_sdl.cpp) + in Unix/video_blit.cpp, around line 570,=20= >> remove the test for !blitter_found and the abort(), this will output=20= >> the right RGB mask to use for your screen. > > I made the changes to the March snapshot, and in the Console I get=20 > three groups of messages, once at startup, second when the Mac OS=20 > desktop loads (startup is done), and lastly when I shutdown/quit (and=20= > my screen is 1024x768@Thousands of colors): [...] > Current video mode: > 640x480 (ID 81), 32 bpp > the_buffer =3D 0x47c5000, the_buffer_copy =3D 0x465b000 > ### No appropriate blitter found > R/G/B mask values : 0xff0000, 0x00ff00, 0x0000ff (depth =3D 32) > R/G/B shift values : 16/8/0 > monitor.mac_frame_base =3D 047c5000 Seems like SDL guessed a best mode with depth greater than what's is=20 available on your system, or I need some other heuristics to determine=20= the current screen depth. Please try: <http://gwenole.beauchesne.free.fr/sheepshaver/sdl_video_info.c> bash-2.05a$ gcc sdl_video_info.c $(sdl-config --cflags --libs) bash-2.05a$ ./a.out Max screen dimensions: 1152x768 Current screen depth: 16 bpp SDL supports 1152x768x16 with a HWSURFACE (windowed) SDL supports 1152x768x16 with a HWSURFACE (fullscreen) > By gdb I think you mean the CrashReporter log? Anyway, this is the=20 > long message I get per crash, I cannot make any sense of it but=20 > hopefully it helps: > > Thread: 0 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x40810000 > > Thread 0 crashed with PPC Thread State: > srr0: 0x40c6624c srr1: 0x0200f930 vrsave: 0x00000000 > cr: 0x4010e0f1 xer: 0x00000000 lr: 0x40ca7388 ctr: 0x40c60000 > r0: 0x00000000 r1: 0x203fffea r2: 0x00000000 r3: 0x40810000 > r4: 0x2054500c r5: 0x00000000 r6: 0x00002070 r7: 0x00000000 > r8: 0x00000000 r9: 0x2054500c r10: 0x00000006 r11: 0x000002f4 > r12: 0x00000861 r13: 0x00000000 r14: 0x00000000 r15: 0x0002003d > r16: 0x40810000 r17: 0x00000000 r18: 0x408153de r19: 0x4085975c > r20: 0x40814c0e r21: 0x23ffff88 r22: 0x4080020a r23: 0x00000000 > r24: 0x40815532 r25: 0x00000027 r26: 0x00000000 r27: 0x00006054 > r28: 0x00000000 r29: 0x40ca7388 r30: 0x40c60000 r31: 0x68fff000 One of the 68k ROM routine tried to write into the ROM... The weird=20 thing is that we normally catch those kind of errors exactly. Is=20 CrashReporter overriding our Mach exception handler? Let's see with: <http://gwenole.beauchesne.free.fr/sheepshaver/sigsegv_standalone.cpp> 1) In default mode with: g++ sigsegv_standalone.cpp, you must have this=20= file in the BasiliskII/src/Unix/ directory 2) With SDL: g++ sigsegv_standalone.cpp -DUSE_SDL $(sdl-config=20 --cflags --libs) If CrashReporter appears in SDL mode, try to uncomment the=20 SDL_INIT_NOPARACHUTE part. You normally should get on the console=20 something like: bash-2.05a$ ./a.out Checking with SDL sigsegv_test_handler(0x185207b, 0x3a7c) expected fault at 0x185207b expected instruction address range: 0x3a68-0x3ac0 sigsegv_insn_handler(0x1852001, 0x3c28) 00003c28: byte read access r0 (rd =3D 0) sigsegv_insn_handler(0x1852002, 0x3c80) 00003c80: word read access r0 (rd =3D 0) sigsegv_insn_handler(0x1852004, 0x3cd8) 00003cd8: long read access r0 (rd =3D 0) sigsegv_insn_handler(0x1852004, 0x3d2c) 00003d2c: long read access r0 (rd =3D 0) sigsegv_insn_handler(0x1852001, 0x3d80) 00003d80: byte read access r0 (rd =3D 0) sigsegv_insn_handler(0x1852002, 0x3dd8) 00003dd8: word read access r0 (rd =3D 0) sigsegv_insn_handler(0x1852004, 0x3e30) 00003e30: long read access r0 (rd =3D 0) sigsegv_insn_handler(0x1852004, 0x3e84) 00003e84: long read access r0 (rd =3D 0) do_test() returned 0 Bye, Gwenol=E9.= |
|
From: Michael D. <mic...@gm...> - 2005-06-30 23:04:59
|
> Something that may be worth testing is to > #define SYSTEM_CLOBBERS_R2 1 > in ppc_asm.tmpl and make sure main_unix.cpp and ppc_asm.S get > recompiled. e.g. remove the matching objects in obj/ > > If this still doesn't work, edit the Makefile to add -mdynamic-no- > pic to both CXXFLAGS and CFLAGS and make clean ; make. > > Please try both independently first, just to know which one was > effective if it works. Neither (nor both) makes a difference, unfortunately, but the app keeps running anyway (fine, it seems). I've seen other people on the list report the same problem in the archives, and it seems to have worked regardless. I sent an email to the listhost about testing display (debug messages). it should arrive later (it needed to be moderated). --Michael |
|
From: Gwenole B. <gb....@fr...> - 2005-06-30 22:49:46
|
Le jeudi, 30 jun 2005, =E0 23:20 Europe/Paris, Gwenole Beauchesne a = =E9crit=20 : >> I am using SDL 1.2.8 from Fink, Mac OS 8.6 from a burned CD, Mac OS=20= >> 10.4.1 on an iBook G4, the console has nothing particularly useful --=20= >> Thread 0 crashes on launch, as reported by other OS X users. > > Could be another problem related to Tiger since it doesn't crash for=20= > me on 10.2.8. Something that may be worth testing is to #define SYSTEM_CLOBBERS_R2 1 in ppc_asm.tmpl and make sure main_unix.cpp and ppc_asm.S get=20 recompiled. e.g. remove the matching objects in obj/ If this still doesn't work, edit the Makefile to add -mdynamic-no-pic=20 to both CXXFLAGS and CFLAGS and make clean ; make. Please try both independently first, just to know which one was=20 effective if it works. > Does gdb report something useful like where it may have crashed? It=20 > probably could because MacOS X also uses the PowerOpen ABI so the=20 > stack frames may be compatible (to get the backchain). Hmm, thinking again about it, I don't think MacOS X follows the POE=20 standard. Netherless, the ABI appears to define the LR save area at=20 8(r1), like in MacOS Classic. Bye, Gwenol=E9.= |
|
From: Michael D. <mic...@gm...> - 2005-06-30 22:01:36
|
>> Hi, I got SheepShaver to compile and run on Tiger (thanks for the =20
>> new paranoia.cpp!)
>>
>
> So it works? Nice, thanks, I will commit along with the Linux =20
> version I was using.
Yup, paranoia works! But I tried compiling the CVS today and I get =20
the following error:
g++ -I../include -I. -DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=3D\"/usr/=20
local/share/SheepShaver\" -g -O2 -I/sw/include/SDL -D_THREAD_SAFE -c =20
main_unix.cpp -o obj/main_unix.o
main_unix.cpp: In function `void TriggerInterrupt()':
main_unix.cpp:1517: error: 'idle_resume' was not declared in this scope
make: *** [obj/main_unix.o] Error 1
> Please tell me your screen depth. Since you could build from =20
> sources, I'd also appreciate to know the video modes reported by =20
> SDL (#define DEBUG 1 in video_sdl.cpp) + in Unix/video_blit.cpp, =20
> around line 570, remove the test for !blitter_found and the abort=20
> (), this will output the right RGB mask to use for your screen.
I made the changes to the March snapshot, and in the Console I get =20
three groups of messages, once at startup, second when the Mac OS =20
desktop loads (startup is done), and lastly when I shutdown/quit (and =20=
my screen is 1024x768@Thousands of colors):
Available video modes:
640x480 (ID 81), 2 colors
800x600 (ID 83), 2 colors
640x480 (ID 81), 4 colors
800x600 (ID 83), 4 colors
640x480 (ID 81), 16 colors
800x600 (ID 83), 16 colors
640x480 (ID 81), 256 colors
800x600 (ID 83), 256 colors
640x480 (ID 81), 32768 colors
800x600 (ID 83), 32768 colors
640x480 (ID 81), 16777216 colors
800x600 (ID 83), 16777216 colors
video_open()
Current video mode:
640x480 (ID 81), 32 bpp
the_buffer =3D 0x47c5000, the_buffer_copy =3D 0x465b000
### No appropriate blitter found
R/G/B mask values : 0xff0000, 0x00ff00, 0x0000ff (depth =3D 32)
R/G/B shift values : 16/8/0
monitor.mac_frame_base =3D 047c5000
...
video_close()
3088 refreshes in 53479196 usec =3D 57.742080 refreshes/sec
frame buffer unlocked
releasing the_buffer at 0x47c5000 (1480704 bytes)
video_open()
Current video mode:
800x600 (ID 83), 32 bpp
the_buffer =3D 0x4aed000, the_buffer_copy =3D 0x465b000
### No appropriate blitter found
R/G/B mask values : 0xff0000, 0x00ff00, 0x0000ff (depth =3D 32)
R/G/B shift values : 16/8/0
monitor.mac_frame_base =3D 04aed000
...
video_close()
2829 refreshes in 51659797 usec =3D 54.762120 refreshes/sec
frame buffer unlocked
releasing the_buffer at 0x4aed000 (2498560 bytes)
>> I am using SDL 1.2.8 from Fink, Mac OS 8.6 from a burned CD, Mac =20
>> OS 10.4.1 on an iBook G4, the console has nothing particularly =20
>> useful -- Thread 0 crashes on launch, as reported by other OS X =20
>> users.
>>
>
> Could be another problem related to Tiger since it doesn't crash =20
> for me on 10.2.8. Does gdb report something useful like where it =20
> may have crashed? It probably could because MacOS X also uses the =20
> PowerOpen ABI so the stack frames may be compatible (to get the =20
> backchain).
By gdb I think you mean the CrashReporter log? Anyway, this is the =20
long message I get per crash, I cannot make any sense of it but =20
hopefully it helps:
Host Name: michael-dickisons-ibook-g4
Date/Time: 2005-06-30 16:46:01.142 -0500
OS Version: 10.4.1 (Build 8B15)
Report Version: 3
Command: SheepShaver
Path: /Users/michaeldickison/Documents/Computing/Sources/=20
SheepShaver-2.2/src/Unix/SheepShaver.app/Contents/MacOS/SheepShaver
Parent: WindowServer [59]
Version: ??? (2.2)
PID: 17573
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x40810000
Thread 0 Crashed:
Thread 1:
0 libSystem.B.dylib 0x90042ae8 mach_wait_until + 8
1 libSystem.B.dylib 0x900428a0 nanosleep + 384
2 SheepShaver 0x00012100 0x3000 + 61696
3 SheepShaver 0x00025ce4 catch_exception_raise + 13064
4 libSDL-1.2.0.dylib 0x00238d94 SDL_RunThread + 72 =20
(SDL_thread.c:218)
5 libSDL-1.2.0.dylib 0x00238918 RunThread + 16 (SDL_systhread.c:=20=
83)
6 libSystem.B.dylib 0x9002c3d4 _pthread_body + 96
Thread 2:
0 libSystem.B.dylib 0x90042ae8 mach_wait_until + 8
1 libSystem.B.dylib 0x900428a0 nanosleep + 384
2 SheepShaver 0x00012100 0x3000 + 61696
3 SheepShaver 0x00005768 0x3000 + 10088
4 libSystem.B.dylib 0x9002c3d4 _pthread_body + 96
Thread 3:
0 libSystem.B.dylib 0x90042ae8 mach_wait_until + 8
1 libSystem.B.dylib 0x900428a0 nanosleep + 384
2 SheepShaver 0x00012100 0x3000 + 61696
3 SheepShaver 0x000053b8 0x3000 + 9144
4 libSystem.B.dylib 0x9002c3d4 _pthread_body + 96
Thread 0 crashed with PPC Thread State:
srr0: 0x40c6624c srr1: 0x0200f930 vrsave: 0x00000000
cr: 0x4010e0f1 xer: 0x00000000 lr: 0x40ca7388 ctr: 0x40c60000
r0: 0x00000000 r1: 0x203fffea r2: 0x00000000 r3: 0x40810000
r4: 0x2054500c r5: 0x00000000 r6: 0x00002070 r7: 0x00000000
r8: 0x00000000 r9: 0x2054500c r10: 0x00000006 r11: 0x000002f4
r12: 0x00000861 r13: 0x00000000 r14: 0x00000000 r15: 0x0002003d
r16: 0x40810000 r17: 0x00000000 r18: 0x408153de r19: 0x4085975c
r20: 0x40814c0e r21: 0x23ffff88 r22: 0x4080020a r23: 0x00000000
r24: 0x40815532 r25: 0x00000027 r26: 0x00000000 r27: 0x00006054
r28: 0x00000000 r29: 0x40ca7388 r30: 0x40c60000 r31: 0x68fff000
Binary Images Description:
0x3000 - 0x36fff SheepShaver ??? (2.2) /Users/=20
michaeldickison/Documents/Computing/Sources/SheepShaver-2.2/src/Unix/=20
SheepShaver.app/Contents/MacOS/SheepShaver
0x205000 - 0x252fff libSDL-1.2.0.dylib /sw/lib/=20
libSDL-1.2.0.dylib
0x8fe00000 - 0x8fe50fff dyld 43 /usr/lib/dyld
0x90000000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/=20
libmathCommon.A.dylib
0x90204000 - 0x90257fff com.apple.CoreText 1.0.0 (???) /System/=20
Library/Frameworks/ApplicationServices.framework/Versions/A/=20
Frameworks/CoreText.framework/Versions/A/CoreText
0x90284000 - 0x90335fff ATS /System/Library/Frameworks/=20
ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/=20
Versions/A/ATS
0x90364000 - 0x9069cfff com.apple.CoreGraphics 1.256.5 (???) /=20
System/Library/Frameworks/ApplicationServices.framework/Versions/A/=20
Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x90727000 - 0x90800fff com.apple.CoreFoundation 6.4.1 (368.1) /=20
System/Library/Frameworks/CoreFoundation.framework/Versions/A/=20
CoreFoundation
0x90849000 - 0x90849fff com.apple.CoreServices 10.4 (???) /System/=20
Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x9084b000 - 0x9094dfff libicucore.A.dylib /usr/lib/=20
libicucore.A.dylib
0x909a7000 - 0x90a2bfff libobjc.A.dylib /usr/lib/libobjc.A.dylib
0x90a55000 - 0x90ac9fff com.apple.framework.IOKit 1.4 (???) /=20
System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x90ae3000 - 0x90af5fff libauto.dylib /usr/lib/libauto.dylib
0x90afc000 - 0x90dc1fff com.apple.CoreServices.CarbonCore 10.4 =20
(611.1) /System/Library/Frameworks/CoreServices.framework/Versions/=20=
A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x90e24000 - 0x90ea4fff com.apple.CoreServices.OSServices 4.0 =20
(4.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/=20=
A/Frameworks/OSServices.framework/Versions/A/OSServices
0x90eee000 - 0x90f2efff com.apple.CFNetwork 4.0 (80) /System/=20
Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/=20
CFNetwork.framework/Versions/A/CFNetwork
0x90f43000 - 0x90f5bfff com.apple.WebServices 1.1.2 (1.1.0) /=20
System/Library/Frameworks/CoreServices.framework/Versions/A/=20
Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore
0x90f6b000 - 0x90fe9fff com.apple.SearchKit 1.0.3 /System/Library/=20
Frameworks/CoreServices.framework/Versions/A/Frameworks/=20
SearchKit.framework/Versions/A/SearchKit
0x9102e000 - 0x91055fff com.apple.Metadata 0.1 (121) /System/=20
Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/=20
Metadata.framework/Versions/A/Metadata
0x91066000 - 0x91073fff libz.1.dylib /usr/lib/libz.1.dylib
0x91076000 - 0x91238fff com.apple.security 4.0 (221) /System/=20
Library/Frameworks/Security.framework/Versions/A/Security
0x9133a000 - 0x91343fff com.apple.DiskArbitration 2.1 /System/=20
Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9134a000 - 0x91371fff com.apple.SystemConfiguration 1.8.0 /=20
System/Library/Frameworks/SystemConfiguration.framework/Versions/A/=20
SystemConfiguration
0x91384000 - 0x9138cfff libbsm.dylib /usr/lib/libbsm.dylib
0x91390000 - 0x9140efff com.apple.audio.CoreAudio 3.0.0 (3.0) /=20
System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x9144c000 - 0x9144cfff com.apple.ApplicationServices 10.4 (???) /=20
System/Library/Frameworks/ApplicationServices.framework/Versions/A/=20
ApplicationServices
0x9144e000 - 0x91486fff com.apple.AE 1.5 (297) /System/Library/=20
Frameworks/ApplicationServices.framework/Versions/A/Frameworks/=20
AE.framework/Versions/A/AE
0x914a1000 - 0x9156cfff com.apple.ColorSync 4.4 /System/Library/=20
Frameworks/ApplicationServices.framework/Versions/A/Frameworks/=20
ColorSync.framework/Versions/A/ColorSync
0x915c1000 - 0x91654fff com.apple.print.framework.PrintCore 4.0 =20
(172) /System/Library/Frameworks/ApplicationServices.framework/=20
Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x9169a000 - 0x91757fff com.apple.QD 3.8.5 (???) /System/Library/=20
Frameworks/ApplicationServices.framework/Versions/A/Frameworks/=20
QD.framework/Versions/A/QD
0x91795000 - 0x917f3fff com.apple.HIServices 1.5.0 (???) /System/=20
Library/Frameworks/ApplicationServices.framework/Versions/A/=20
Frameworks/HIServices.framework/Versions/A/HIServices
0x91821000 - 0x91844fff com.apple.LangAnalysis 1.6 /System/Library/=20=
Frameworks/ApplicationServices.framework/Versions/A/Frameworks/=20
LangAnalysis.framework/Versions/A/LangAnalysis
0x91858000 - 0x9187dfff com.apple.FindByContent 1.5 /System/=20
Library/Frameworks/ApplicationServices.framework/Versions/A/=20
Frameworks/FindByContent.framework/Versions/A/FindByContent
0x91890000 - 0x918d0fff com.apple.LaunchServices 10.4.2 (156) /=20
System/Library/Frameworks/ApplicationServices.framework/Versions/A/=20
Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x918eb000 - 0x918fffff com.apple.speech.synthesis.framework 3.3 /=20
System/Library/Frameworks/ApplicationServices.framework/Versions/A/=20
Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x9190d000 - 0x91943fff com.apple.ImageIO.framework 1.0 /System/=20
Library/Frameworks/ApplicationServices.framework/Versions/A/=20
Frameworks/ImageIO.framework/Versions/A/ImageIO
0x91957000 - 0x91a19fff libcrypto.0.9.7.dylib /usr/lib/libcrypto.=20
0.9.7.dylib
0x91a65000 - 0x91a7afff libcups.2.dylib /usr/lib/libcups.2.dylib
0x91a7f000 - 0x91a9bfff libJPEG.dylib /System/Library/Frameworks/=20
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/=20=
Versions/A/Resources/libJPEG.dylib
0x91aa0000 - 0x91b0ffff libJP2.dylib /System/Library/Frameworks/=20
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/=20=
Versions/A/Resources/libJP2.dylib
0x91b26000 - 0x91b2afff libGIF.dylib /System/Library/Frameworks/=20
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/=20=
Versions/A/Resources/libGIF.dylib
0x91b2c000 - 0x91b44fff libRaw.dylib /System/Library/Frameworks/=20
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/=20=
Versions/A/Resources/libRaw.dylib
0x91b47000 - 0x91b8afff libTIFF.dylib /System/Library/Frameworks/=20
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/=20=
Versions/A/Resources/libTIFF.dylib
0x91b91000 - 0x91baafff libPng.dylib /System/Library/Frameworks/=20
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/=20=
Versions/A/Resources/libPng.dylib
0x91baf000 - 0x91bb2fff libRadiance.dylib /System/Library/=20
Frameworks/ApplicationServices.framework/Versions/A/Frameworks/=20
ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x91bb4000 - 0x91bb4fff com.apple.Accelerate 1.1.1 (Accelerate =20
1.1.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/=20
Accelerate
0x91bb6000 - 0x91ca0fff com.apple.vImage 2.0 /System/Library/=20
Frameworks/Accelerate.framework/Versions/A/Frameworks/=20
vImage.framework/Versions/A/vImage
0x91ca8000 - 0x91cc7fff com.apple.Accelerate.vecLib 3.1.1 (vecLib =20
3.1.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/=20
Frameworks/vecLib.framework/Versions/A/vecLib
0x91d33000 - 0x91d53fff libmx.A.dylib /usr/lib/libmx.A.dylib
0x91d59000 - 0x91dbefff libvMisc.dylib /System/Library/Frameworks/=20=
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/=20
A/libvMisc.dylib
0x91dc8000 - 0x91e5afff libvDSP.dylib /System/Library/Frameworks/=20
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/=20
A/libvDSP.dylib
0x91e74000 - 0x92404fff libBLAS.dylib /System/Library/Frameworks/=20
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/=20
A/libBLAS.dylib
0x9244c000 - 0x9275cfff libLAPACK.dylib /System/Library/=20
Frameworks/Accelerate.framework/Versions/A/Frameworks/=20
vecLib.framework/Versions/A/libLAPACK.dylib
0x92789000 - 0x92814fff com.apple.DesktopServices 1.3 /System/=20
Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/=20
DesktopServicesPriv
0x92856000 - 0x92a7ffff com.apple.Foundation 6.4 (567) /System/=20
Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x92b9d000 - 0x92c7bfff libxml2.2.dylib /usr/lib/libxml2.2.dylib
0x92c9b000 - 0x92d89fff libiconv.2.dylib /usr/lib/libiconv.2.dylib
0x92d9b000 - 0x92db9fff libGL.dylib /System/Library/Frameworks/=20
OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x92dc4000 - 0x92e1efff libGLU.dylib /System/Library/Frameworks/=20
OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x92e3c000 - 0x92e3cfff com.apple.Carbon 10.4 (???) /System/=20
Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x92e3e000 - 0x92e52fff com.apple.ImageCapture 3.0 /System/Library/=20=
Frameworks/Carbon.framework/Versions/A/Frameworks/=20
ImageCapture.framework/Versions/A/ImageCapture
0x92e6a000 - 0x92e7afff com.apple.speech.recognition.framework =20
3.4 /System/Library/Frameworks/Carbon.framework/Versions/A/=20
Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x92e86000 - 0x92e9bfff com.apple.securityhi 2.0 (203) /System/=20
Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
SecurityHI.framework/Versions/A/SecurityHI
0x92ead000 - 0x92f34fff com.apple.ink.framework 101.2 (69) /System/=20=
Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
Ink.framework/Versions/A/Ink
0x92f48000 - 0x92f53fff com.apple.help 1.0.3 (32) /System/Library/=20
Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/=20
Versions/A/Help
0x92f5d000 - 0x92f8afff com.apple.openscripting 1.2.2 (???) /=20
System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
OpenScripting.framework/Versions/A/OpenScripting
0x92fa4000 - 0x92fb4fff com.apple.print.framework.Print 4.0 (187) /=20=
System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
Print.framework/Versions/A/Print
0x92fc0000 - 0x93026fff com.apple.htmlrendering 1.1.2 /System/=20
Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
HTMLRendering.framework/Versions/A/HTMLRendering
0x93057000 - 0x930a9fff com.apple.NavigationServices 3.4 /System/=20
Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
NavigationServices.framework/Versions/A/NavigationServices
0x930d5000 - 0x930f2fff com.apple.audio.SoundManager 3.9 /System/=20
Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
CarbonSound.framework/Versions/A/CarbonSound
0x93104000 - 0x93111fff com.apple.CommonPanels 1.2.2 (73) /System/=20
Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
CommonPanels.framework/Versions/A/CommonPanels
0x9311a000 - 0x9342afff com.apple.HIToolbox 1.4.1 (???) /System/=20
Library/Frameworks/Carbon.framework/Versions/A/Frameworks/=20
HIToolbox.framework/Versions/A/HIToolbox
0x93575000 - 0x93581fff com.apple.opengl 1.4.0 /System/Library/=20
Frameworks/OpenGL.framework/Versions/A/OpenGL
0x93613000 - 0x93613fff com.apple.Cocoa 6.4 (???) /System/Library/=20
Frameworks/Cocoa.framework/Versions/A/Cocoa
0x93615000 - 0x93c46fff com.apple.AppKit 6.4.1 (824.1) /System/=20
Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x93fd2000 - 0x9403cfff com.apple.CoreData 1.0 (46) /System/=20
Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x94074000 - 0x9413efff com.apple.audio.toolbox.AudioToolbox 1.4 /=20
System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x94192000 - 0x94192fff com.apple.audio.units.AudioUnit 1.4 /=20
System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x94194000 - 0x942f3fff com.apple.QuartzCore 1.4.1 /System/Library/=20=
Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x9433b000 - 0x94378fff libsqlite3.0.dylib /usr/lib/=20
libsqlite3.0.dylib
0x94380000 - 0x943cbfff libGLImage.dylib /System/Library/=20
Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x9456b000 - 0x9457afff libCGATS.A.dylib /System/Library/=20
Frameworks/ApplicationServices.framework/Versions/A/Frameworks/=20
CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib
0x94582000 - 0x9458efff libCSync.A.dylib /System/Library/=20
Frameworks/ApplicationServices.framework/Versions/A/Frameworks/=20
CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x945d3000 - 0x945e7fff libRIP.A.dylib /System/Library/Frameworks/=20=
ApplicationServices.framework/Versions/A/Frameworks/=20
CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x945ed000 - 0x9484ffff com.apple.QuickTime 7.0.1 /System/Library/=20
Frameworks/QuickTime.framework/Versions/A/QuickTime
0x94922000 - 0x94941fff com.apple.vecLib 3.1.1 (vecLib 3.1.1) /=20
System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x95483000 - 0x95506fff libstdc++.6.dylib /usr/lib/libstdc++.6.dylib
0x95584000 - 0x9558cfff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib
0x97a74000 - 0x97a81fff com.apple.agl 2.5.6 (AGL-2.5.6) /System/=20
Library/Frameworks/AGL.framework/Versions/A/AGL
> Thanks,
> Gwenol=E9.
Thank you!
--Michael=
|
|
From: Gwenole B. <gb....@fr...> - 2005-06-30 21:26:08
|
Le jeudi, 30 jun 2005, =E0 19:55 Europe/Paris, Todd Vierling a =E9crit : > Really, these days, truly portable code shouldn't touch DirectX at all > unless there's a very pressing need to do so. SDL is probably the=20 > better > way to go here, ditching DirectX altogether. Sure, it might be a=20 > little > more abstraction, but it would probably buy you a lot in=20 > maintainability. Sure, SDL will remain the most portable way but e.g. on Linux, using=20 SDL causes a 2x graphics performance slow-down, and this is noticeable.=20= At one point, I also wanted to locally change parts of SDL to suit=20 B2/SS needs but I haven't looked at it further yet. Especially a sync=20 mechanism with main SDL-1.2 sources if it ever changes again, which I=20 doubt since it's stable and only new ports get committed nowadays...= |
|
From: Gwenole B. <gb....@fr...> - 2005-06-30 21:20:47
|
Le jeudi, 30 jun 2005, =E0 06:49 Europe/Paris, Michael Dickison a =E9crit = : > Hi, I got SheepShaver to compile and run on Tiger (thanks for the new=20= > paranoia.cpp!) So it works? Nice, thanks, I will commit along with the Linux version I=20= was using. > -- however, the display is screwed up, specifically, it looks like=20 > this: http://home.uchicago.edu/~mikeru/Picture%201.png Please tell me your screen depth. Since you could build from sources,=20 I'd also appreciate to know the video modes reported by SDL (#define=20 DEBUG 1 in video_sdl.cpp) + in Unix/video_blit.cpp, around line 570,=20 remove the test for !blitter_found and the abort(), this will output=20 the right RGB mask to use for your screen. > I am using SDL 1.2.8 from Fink, Mac OS 8.6 from a burned CD, Mac OS=20 > 10.4.1 on an iBook G4, the console has nothing particularly useful --=20= > Thread 0 crashes on launch, as reported by other OS X users. Could be another problem related to Tiger since it doesn't crash for me=20= on 10.2.8. Does gdb report something useful like where it may have=20 crashed? It probably could because MacOS X also uses the PowerOpen ABI=20= so the stack frames may be compatible (to get the backchain). Thanks, Gwenol=E9.= |
|
From: Todd V. <tv...@du...> - 2005-06-30 17:56:13
|
On Thu, 30 Jun 2005, Rob Snyder wrote: > > Note that in no way do I intend to maintain the Windows port. It's not a > > sane exercise. Once the two mentioned bits are fixed, I am done with it. > I have been looking at the windows code lately like Lauris old DX code. The > only problem is that Lauris code really needs to be re written from scratch. > while the DX calls would workon a modern version of DX since it is backwards > compatible but there are so many improved ways of doing the same thing in DX9 > it the old DX5 code from Lauri looks well awful. Really, these days, truly portable code shouldn't touch DirectX at all unless there's a very pressing need to do so. SDL is probably the better way to go here, ditching DirectX altogether. Sure, it might be a little more abstraction, but it would probably buy you a lot in maintainability. -- -- Todd Vierling <tv...@du...> <tv...@po...> <to...@vi...> |
|
From: Gwenole B. <gb....@fr...> - 2005-06-30 17:52:17
|
Hi, We can also release a SheepShaver 2.3 soon. Issues left: General: - Audio is not automatically enabled with NewWorld ROMs and MacOS >=3D=20= 8.6. There are workarounds through the "Audio" control pannel IIRC. So,=20= that's not release critical. - Ethernet doesn't work in DIRECT_ADDRESSING mode yet. - We need to find a way to sanely abort if people are trying to use=20 MacOS < 8.5 with NewWorld ROMs. Or is it supposed to work? MacOS X: - I have no news for the Tiger problems. - There is no GUI nor CoreGraphics used yet. That's not important to=20 make a release since we can link with libSDL.a. - Add support for Mach/i386 relocations to dyngen to have JIT working=20 on x86. - Build with -mdynamic-no-pic. Windows: - Fullscreen DGA doesn't work - Integrate new GTK+2 based GUI I committed some important bug fixes recently which improves stability=20= everywhere. However, there may be regressions so some more testing=20 needs to be done. Especially for clean installs. I only have 8.1, 8.6,=20= 9.0 handy and I again forgot to bring back 7.1.2. Again, spinning release candidates could bring more build/application=20 testers. Since roadmaps are a hype thing to tell nowadays, here are the features=20= planned for 3.0: - Make InputSprockets work but I have absolutely no idea how. - Now that SheepShaver reached a decent stability level in CVS, I could=20= get back to the JIT in the future. AFAICS, it's not difficult to bring=20= in a 2x speed increase and thus reaching 30% of native speeds. 40+ is=20 possible but I am not sure yet how/if the profiler will work correctly.=20= ;-) Just need some time to merge all current bits and experiments +=20 dump remaining techniques out of my head. - Host CPU sw assisted OpenGL rendering. Easy to do but simply=20 boring/tedious to handle and check all thunks. Aranym people did it=20 though. I have to think again for hwaccel through 3D cards.=20 Synchronization won't be trivial and offscreen rendering is not really=20= effecient IIRC and depends on certain cards+drivers. Bye, Gwenol=E9.= |
|
From: Rob S. <Ro...@xb...> - 2005-06-30 17:22:58
|
Gwenole Beauchesne wrote: > Hi, > > I think we can really release 1.0 this year. ;-) I have the following > troublesome issues on top of my head: > > General: > - Does 24-bit addressing (non 32-bit clean ROMs) work in > DIRECT_ADDRESSING mode? I can't test right now since my older > Macintosh LC is on an island in the other side of the planet so I > can't get the ROM. ;-) But it should be possible to make a 68040 only > mode with DIRECT_ADDRESSING and the other cpu levels that use the > usual memory_banks. That could even be done without increasing the > code size if I remember the UAE black magic around cpufunctbl[]. > > Mac OS X: > - I can't rebuild in 10.2.8. Nigel, can you test builds with > HAVE_SLIRP enabled for network support? It works if I build SDL > versions within Unix/ but those don't have your GUI and video > enhancements. > - Note that you could also consider the new "tunnel" driver that > exposes a TAP-like interface but it has some incompatibilities with > Tiger and doesn't work in 10.2 either, IIRC. > - Build with -mdynamic-no-pic > - B2 now works in Darwin 8.0.1 for x86, with JIT. People that payed > for an OSX/Intel dev system would probably want to have a look at > porting Nigel's Cocoa additions... > > Windows: > - Fullscreen DGA doesn't work > - Finish the new GTK+2 based GUI > > CPU emulation: > - It's not fully debugged but now that I managed to get a replacement > battery for my old Quadra 630, there is hope I could write a testsuite > some day. Anyhow, the emulator is quite stable already, including the > JIT. > > Note that in no way do I intend to maintain the Windows port. It's not > a sane exercise. Once the two mentioned bits are fixed, I am done with > it. Other people will maintain it: fixing bugs left and merging the > native DirectX video graphics support code from Lauri. Some people > expressed their interest in maintaining the Windows version. > > Then, if we start spinning 1.0 release candidates for build testers, > that would probably attract more people. > > Bye, > Gwenolé. > > Gwenole, I have been looking at the windows code lately like Lauris old DX code. The only problem is that Lauris code really needs to be re written from scratch. while the DX calls would workon a modern version of DX since it is backwards compatible but there are so many improved ways of doing the same thing in DX9 it the old DX5 code from Lauri looks well awful. A. We need a Windows Developer and frankly I am just not that person. ( too busy with my own open source projects ) B. We could always scratch DX and find someone who knows OpenGL programming open gl has similiar functions to process 2d functions like DX and it be compatible across the board. But agian this is a issue of just needing someone to even do that. What about Large file transfers from AppleTalk. Did that ever get fix where b2 would crash if it was sending out large files via Atalk. > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Gwenole B. <gb....@fr...> - 2005-06-30 16:46:12
|
Hi, I think we can really release 1.0 this year. ;-) I have the following=20 troublesome issues on top of my head: General: - Does 24-bit addressing (non 32-bit clean ROMs) work in=20 DIRECT_ADDRESSING mode? I can't test right now since my older Macintosh=20= LC is on an island in the other side of the planet so I can't get the=20 ROM. ;-) But it should be possible to make a 68040 only mode with=20 DIRECT_ADDRESSING and the other cpu levels that use the usual=20 memory_banks. That could even be done without increasing the code size=20= if I remember the UAE black magic around cpufunctbl[]. Mac OS X: - I can't rebuild in 10.2.8. Nigel, can you test builds with HAVE_SLIRP=20= enabled for network support? It works if I build SDL versions within=20 Unix/ but those don't have your GUI and video enhancements. - Note that you could also consider the new "tunnel" driver that=20 exposes a TAP-like interface but it has some incompatibilities with=20 Tiger and doesn't work in 10.2 either, IIRC. - Build with -mdynamic-no-pic - B2 now works in Darwin 8.0.1 for x86, with JIT. People that payed for=20= an OSX/Intel dev system would probably want to have a look at porting=20 Nigel's Cocoa additions... Windows: - Fullscreen DGA doesn't work - Finish the new GTK+2 based GUI CPU emulation: - It's not fully debugged but now that I managed to get a replacement=20 battery for my old Quadra 630, there is hope I could write a testsuite=20= some day. Anyhow, the emulator is quite stable already, including the=20 JIT. Note that in no way do I intend to maintain the Windows port. It's not=20= a sane exercise. Once the two mentioned bits are fixed, I am done with=20= it. Other people will maintain it: fixing bugs left and merging the=20 native DirectX video graphics support code from Lauri. Some people=20 expressed their interest in maintaining the Windows version. Then, if we start spinning 1.0 release candidates for build testers,=20 that would probably attract more people. Bye, Gwenol=E9.= |
|
From: Michael D. <mic...@gm...> - 2005-06-30 04:49:56
|
Hi, I got SheepShaver to compile and run on Tiger (thanks for the new paranoia.cpp!) -- however, the display is screwed up, specifically, it looks like this: http://home.uchicago.edu/~mikeru/Picture%201.png I am using SDL 1.2.8 from Fink, Mac OS 8.6 from a burned CD, Mac OS 10.4.1 on an iBook G4, the console has nothing particularly useful -- Thread 0 crashes on launch, as reported by other OS X users. This happens with both the March snapshot and the CVS, with the options, -- enable-sdl-video --enable-sdl-audio --disable-vosf --without-gtk -- without-esd Has anyone had this problem before (is it Tiger specific)? Does anyone have any suggestions? Thanks in advance. --Michael |
|
From: howard s. <how...@ho...> - 2005-06-25 16:15:52
|
<html><div style='background-color:'><DIV class=RTE> <P>Hello,</P> <P>You need to install the X development packages to compile. Install the compat-readline 4.3 package to get rid of the dependency problem. Suse ships with readline 5<BR><BR>Howard</P><BR><BR><BR>>From: "Joe Sparks" <JS...@al...><BR>>Reply-To: bas...@li...<BR>>To: <bas...@li...><BR>>Subject: [B2-devel] SheepShaver on SuSE 9.2 - x86_64<BR>>Date: Mon, 20 Jun 2005 14:44:37 -0700<BR>>MIME-Version: 1.0<BR>>Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by mc7-f8.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 14:47:26 -0700<BR>>Received: from projects.sourceforge.net (sc8-sf-list2-b.sourceforge.net [10.3.1.8])by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTPid F2FB4890DE; Mon, 20 Jun 2005 14:45:23 -0700 (PDT)<BR>>Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12] helo=sc8-sf-mx2.sourceforge.net)by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30)id 1DkU4P-0007RN-4xfor bas...@li...; Mon, 20 Jun 2005 14:44:41 -0700<BR>>Received: from smtp.alphasmart.com ([64.166.25.66])by sc8-sf-mx2.sourceforge.net with esmtp (Exim 4.41)id 1DkU4N-0005Gu-LQfor bas...@li...; Mon, 20 Jun 2005 14:44:41 -0700<BR>>Received: by smtp.alphasmart.com (Postfix, from userid 744)id D45DA4B00DA; Mon, 20 Jun 2005 14:43:09 -0700 (PDT)<BR>>Received: from joes (unknown [192.168.4.149])by smtp.alphasmart.com (Postfix) with SMTP id 417B04B0114for <bas...@li...>; Mon, 20 Jun 2005 14:43:06 -0700 (PDT)<BR>>X-Message-Info: dpeAAki3kMSXVM4ZfMuui/2PltRZeDairyaeNfNZM2s=<BR>>X-MSMail-Priority: Normal<BR>>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)<BR>>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180<BR>>X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on smtp.alphasmart.com<BR>>X-Spam-Level: <BR>>X-Spam-Status: No, score=-5.8 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2<BR>>X-Spam-Score: 0.1 (/)<BR>>X-Spam-Report: Spam Filtering performed by sourceforge.net.See http://spamassassin.org/tag/ for more details.Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=2000010.0 SF_CHICKENPOX_PARATHESES_CLOSE BODY: Text interparsed with )0.0 SF_CHICKENPOX_HASH BODY: Text interparsed with0.0 SF_CHICKENPOX_PERIOD BODY: Text interparsed with .0.0 SF_CHICKENPOX_SLASH BODY: Text interparsed with /0.0 SF_CHICKENPOX_MINUS BODY: Text interparsed with -0.0 SF_CHICKENPOX_COLON BODY: Text interparsed with :0.0 SF_CHICKENPOX_UNDERSCORE BODY: Text interparsed with _<BR>>Errors-To: bas...@li...<BR>>X-BeenThere: bas...@li...<BR>>X-Mailman-Version: 2.0.9-sf.net<BR>>Precedence: bulk<BR>>List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/basilisk-devel>,<mailto:bas...@li...?subject=unsubscribe><BR>>List-Id: Discussions related to the development of Basilisk II <basilisk-devel.lists.sourceforge.net><BR>>List-Post: <mailto:bas...@li...><BR>>List-Help: <mailto:bas...@li...?subject=help><BR>>List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/basilisk-devel>,<mailto:bas...@li...?subject=subscribe><BR>>List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=basilisk-devel><BR>>Return-Path: bas...@li...<BR>>X-OriginalArrivalTime: 20 Jun 2005 21:47:26.0561 (UTC) FILETIME=[A6274510:01C575E1]<BR>><BR>>Hello,<BR>><BR>>I need a bit of help. I am running a standard installation of SuSE 9.2 on a<BR>>dual AMD Opteron 64bit system with 2G ECC RAM.<BR>><BR>>If I try to use the pre-built RPM (SheepShaver-2.2-18.x86_64.rpm) I get the<BR>>following error<BR>><BR>>error: Failed dependencies:<BR>> libreadline.so.4.3()(64bit) is needed by SheepShaver-2.2-18<BR>><BR>>I have searched for something to offer that dependency, but have not been<BR>>able to find it. After giving up on that, I decided to try the CVS. I<BR>>downloaded the current CVS then went to /SheepShaver/src/Unix/ and tried to<BR>>run the autogen.sh file. This is what I get:<BR>><BR>> + Running aclocal: configure.ac:411: warning: underquoted definition of<BR>>AC_CHECK_FRAMEWORK<BR>> run info '(automake)Extending aclocal'<BR>> or see http://sources.redhat.com/automake/automake.html#Extending-aclocal<BR>>configure.ac:506: warning: underquoted definition of AC_TRANSLATE_DEFINE<BR>>aclocal:configure.ac:245: warning: macro `AM_PATH_GTK_2_0' not found in<BR>>library<BR>>aclocal:configure.ac:267: warning: macro `AM_PATH_GTK' not found in library<BR>>aclocal:configure.ac:281: warning: macro `AM_PATH_ESD' not found in library<BR>>done.<BR>> + Running autoheader: done.<BR>> + Running autoconf: done.<BR>> + Running 'configure ':<BR>> ** If you wish to pass arguments to ./configure, please<BR>> ** specify them on the command line.<BR>>checking build system type... x86_64-unknown-linux-gnu<BR>>checking host system type... x86_64-unknown-linux-gnu<BR>>checking target system type... x86_64-unknown-linux-gnu<BR>>checking for gcc... gcc<BR>>checking for C compiler default output file name... a.out<BR>>checking whether the C compiler works... yes<BR>>checking whether we are cross compiling... no<BR>>checking for suffix of executables...<BR>>checking for suffix of object files... o<BR>>checking whether we are using the GNU C compiler... yes<BR>>checking whether gcc accepts -g... yes<BR>>checking for gcc option to accept ANSI C... none needed<BR>>checking how to run the C preprocessor... gcc -E<BR>>checking for g++... g++<BR>>checking whether we are using the GNU C++ compiler... yes<BR>>checking whether g++ accepts -g... yes<BR>>checking whether make sets $(MAKE)... yes<BR>>checking for a BSD-compatible install... /usr/bin/install -c<BR>>checking for egrep... grep -E<BR>>checking for file... /usr/bin/file<BR>>checking for perl... /usr/bin/perl<BR>>checking for PowerPC target CPU... no<BR>>checking for mon... no<BR>>configure: WARNING: Could not find mon, ignoring --with-mon.<BR>>checking for sem_init in -lposix4... no<BR>>checking for X... no<BR>>configure: error: You need X11 to run SheepShaver.<BR>><BR>>My system has X11R6 installed. What do I need to do to get it installed and<BR>>working? I would really like to get FileMaker 3.0 installed and running<BR>>under MacOS 9.0 on this system. Our current system is way too slow and as<BR>>far as I can tell, SheepShaver is the only emulator that will do OS 9.x.<BR>><BR>>Thanks,<BR>><BR>>Joe<BR>><BR>><BR>><BR>>-------------------------------------------------------<BR>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies<BR>>from IBM. Find simple to follow Roadmaps, straightforward articles,<BR>>informative Webcasts and more! Get everything you need to get up to<BR>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click<BR>>_______________________________________________<BR>>basilisk-devel mailing list<BR>>bas...@li...<BR>>https://lists.sourceforge.net/lists/listinfo/basilisk-devel<BR></DIV></div></html> |
|
From: Gwenole B. <gb....@fr...> - 2005-06-22 23:09:45
|
Hi, For those willing to try out Basilisk II with the new Intel Compilers=20 v9.0 will notice that the generated executable doesn't work. You will=20 have to wait for the next compiler updates, which are due out soon. I=20 don't know if it worked with v8.1but I had finally took the time to=20 look at using icc for compiling B2 during the beta program. I don't expect much performance improvement since most of the time is=20 spent in the JIT generated code. However, it's still interesting to=20 test other compilers to catch out possible errors in the code. Bye, Gwenol=E9.= |
|
From: Gwenole B. <gb....@fr...> - 2005-06-22 22:44:23
|
Hi,
I am on holidays and found out the old K6-2/300 system is still working=20=
here. So, I fixed SheepShaver to build and run on it with a=20
Mandrakelinux 8.1 distro. This means it now builds with gcc "2.96" and=20=
older glibc 2.2.X versions. Performance varies from 50 to 100 % of an=20
ancient PowerMac 6100 @ 60 MHz according to some Speedometer 4=20
benchmarks.
I would be interested to know how SheepShaver goes building and running=20=
on various x86 systems. A user expressed his wish to get it working on=20=
{BeOS,Zeta}/x86 but I don't have that OS and I am not sure gcc 2.95.x=20
is capable enough to build the emulator sources.
BTW, my Quadra 630 no longer boots, it was 10+ years old. The battery=20
is likely dead and finding a replacement doesn't seem simple (a Rayonac=20=
840 according to some sites). This means I no longer have any 68k=20
system, so I can't build a testsuite for the Basilisk II m68k emulator.=20=
The UAE emulation should be stable enough though.
I'd prefer working on the ppc emulator anyway. The following hosts=20
still need to be supported: mips, ia64.
Bye,
Gwenol=E9.=
|
|
From: Gwenole B. <gb....@fr...> - 2005-06-21 20:07:20
|
Hi, > "ibook:~ thomholwerda$ =20 > /Users/thomholwerda/SheepShaver/SheepShaver.macosx/SheepShaver.app/=20 > Contents/MacOS/SheepShaver; exit > SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig > Paranoia checks... > FATAL: sc->regs->gpr[2] in signal handler (00000040) doesn't have =20 > expected value (affebad5) > Maybe you need a different kernel? > logout > [Process completed]" Please grab the following file: <http://gwenole.beauchesne.free.fr/sheepshaver/paranoia_osx.cpp> and place it in the SheepShaver/src/Unix/ directory Then, assuming you already have a compiled source tree: bash-2.05a$ g++ -O2 -g -I. -I../include -DTEST paranoia_osx.cpp =20 -lpthread obj/user_strings.o obj/user_strings_unix.o You should get something like: bash-2.05a$ ./a.out Paranoia checks... [emul_thread] waiting for tick thread to initialize [tick_thread] waiting for emul thread to initialize [emul_thread] filling in registers and waiting for interrupt [tick_thread] trigger interrupt SIGUSR2 caught ...passed Oh, I have just placed a paranoia_osx.bz2 file at the same location. =20 You can download it instead, bunzip2 it, and make sure it's executable: =20= chmod 755 paranoia_osx. This version matches more closely what the main SheepShaver thread is =20= doing. Bye, Gwenol=E9.= |
|
From: Joe S. <JS...@al...> - 2005-06-20 21:44:41
|
Hello,
I need a bit of help. I am running a standard installation of SuSE 9.2 on a
dual AMD Opteron 64bit system with 2G ECC RAM.
If I try to use the pre-built RPM (SheepShaver-2.2-18.x86_64.rpm) I get the
following error
error: Failed dependencies:
libreadline.so.4.3()(64bit) is needed by SheepShaver-2.2-18
I have searched for something to offer that dependency, but have not been
able to find it. After giving up on that, I decided to try the CVS. I
downloaded the current CVS then went to /SheepShaver/src/Unix/ and tried to
run the autogen.sh file. This is what I get:
+ Running aclocal: configure.ac:411: warning: underquoted definition of
AC_CHECK_FRAMEWORK
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.ac:506: warning: underquoted definition of AC_TRANSLATE_DEFINE
aclocal:configure.ac:245: warning: macro `AM_PATH_GTK_2_0' not found in
library
aclocal:configure.ac:267: warning: macro `AM_PATH_GTK' not found in library
aclocal:configure.ac:281: warning: macro `AM_PATH_ESD' not found in library
done.
+ Running autoheader: done.
+ Running autoconf: done.
+ Running 'configure ':
** If you wish to pass arguments to ./configure, please
** specify them on the command line.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for egrep... grep -E
checking for file... /usr/bin/file
checking for perl... /usr/bin/perl
checking for PowerPC target CPU... no
checking for mon... no
configure: WARNING: Could not find mon, ignoring --with-mon.
checking for sem_init in -lposix4... no
checking for X... no
configure: error: You need X11 to run SheepShaver.
My system has X11R6 installed. What do I need to do to get it installed and
working? I would really like to get FileMaker 3.0 installed and running
under MacOS 9.0 on this system. Our current system is way too slow and as
far as I can tell, SheepShaver is the only emulator that will do OS 9.x.
Thanks,
Joe
|
|
From: Gwenole B. <gb....@fr...> - 2005-06-13 20:33:32
|
Hi, I have recently updated the Basilisk II CVS with: 1) Much improved responsiveness on NetBSD systems. Since the time slice is not small enough there, I opted for an hybrid=20 m68k instruction counter (countdown) vs. periodic time check. The=20 countdown is recalibrated every 10 ticks and kicks in at around 1000=20 Hz. When the counter is below zero, a normal check is performed to see=20= if a Mac timeslice (16 ms) expired and thus triggering interrupts.=20 Performance is not fully on par with a system supporting small=20 quantums, but mouse and operations are now much smoother under=20 NetBSD/i386. Next commits will adapt the code for SDL video and fix the extra=20 ethernet interrupt trigger with has to be called only if there is no=20 pthreads at all (ether_dummy.cpp used). 2) You now can use Basilisk II with JIT on Darwin 8.0.1 for x86, thus=20 very likely permitting it to run in next MacOS incarnations. ;-) Bye, Gwenol=E9.= |
|
From: Tomek J. <to...@je...> - 2005-06-05 10:52:54
|
Gwenole Beauchesne napisa=C5=82(a): > Hi, > > On fast machines, or with JIT enabled, Speedometer 3.23 can crash at=20 > the exit of FPU tests. With a Quadra 630 ROM, the relevant code=20 > snippet is: > pc 0200db76 | 0838 0000 1efc btst #$00,MMFlags > pc 0200db7c | 660e bne.s $0200db8c > pc 0200db8c | 2008 move.l a0,d0 > pc 0200db8e | 2240 movea.l d0,a1 > pc 0200db90 | 6702 beq.s $0200db94 > pc 0200db92 | 2051 movea.l (a1),a0 > The crash occurs once you validate the "Tests are done" dialog. > > A1 is somehow corrupted and always has 0xffff00ff when a crash occurs= =2E=20 > I could reproduce the problem in 32-bit or 64-bit x86 mode. In any=20 > addressing mode. In 68030+FPU or 68040, which are the same. With any=20 > FPU emulation (UAE, IEEE). > > Of course, it's easier (faster) to get a crash with JIT enabled. This= =20 > yielded the question of possible problems with nested EMUL_OP=20 > processing or Execute68k()? I am not quite sure. > > Workarounding the faulting 68k instruction will simply make B2 crash=20 > later. The OS is 8.1 with 32 MB. > > Anobody got similar problems? > I have identical problem with Speedometer 4.0 both with the Linux and=20 Windows version of Sheepshaver. Tests are finished, the results are=20 about to be displayed and poof! Sheepshaver crashes. It happens every=20 time. The OS is 8.6 and the fost PC is AMD64 3200. Tomek |
|
From: Gwenole B. <gb....@fr...> - 2005-06-05 07:51:43
|
Hi, On fast machines, or with JIT enabled, Speedometer 3.23 can crash at the exit of FPU tests. With a Quadra 630 ROM, the relevant code snippet is: pc 0200db76 | 0838 0000 1efc btst #$00,MMFlags pc 0200db7c | 660e bne.s $0200db8c pc 0200db8c | 2008 move.l a0,d0 pc 0200db8e | 2240 movea.l d0,a1 pc 0200db90 | 6702 beq.s $0200db94 pc 0200db92 | 2051 movea.l (a1),a0 The crash occurs once you validate the "Tests are done" dialog. A1 is somehow corrupted and always has 0xffff00ff when a crash occurs. I could reproduce the problem in 32-bit or 64-bit x86 mode. In any addressing mode. In 68030+FPU or 68040, which are the same. With any FPU emulation (UAE, IEEE). Of course, it's easier (faster) to get a crash with JIT enabled. This yielded the question of possible problems with nested EMUL_OP processing or Execute68k()? I am not quite sure. Workarounding the faulting 68k instruction will simply make B2 crash later. The OS is 8.1 with 32 MB. Anobody got similar problems? |
|
From: Thilo L. <t.l...@we...> - 2005-05-26 06:45:08
|
Hi, I recently tried to run the old Game "Siedler 2" or Settlers 2 on both emu= lators on OSX. The game is protected and checks if the original CD is inserted. After a number of tries in BasiliskII (Nigel Pearson's OSX port), it worke= d perfectly=20 (using System 7.6.1 or 8) but very slow.=20 Then I tried to use it in Sheepshaver (OSX Ver 21.Mar.2005 from Gwenol=E9 Be= auchesne's site), with System 8.6, but the game quits with the error message, that th= e original CD should be inserted (which I did because I ran the game from that). Then I setup Sheepshaver to use the same boot image i used with Basilisk (= System 8) and for my suprise it booted up flawlessly. But the error message was the = same. (I even tried the Win32 version, same problem) It seems there is a difference in the CDRom emulation in both emulators or= that the Sheepshaver CDRom emulation is less complete... Can someone explain or confirm that=3F --=20 Thilo Leibelt t.l...@we... =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/=3Fmc=3D021201 |
|
From: Thilo L. <t.l...@we...> - 2005-05-26 06:31:36
|
-- Thilo Leibelt t.l...@we... ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 |
|
From: Gwenole B. <gb....@fr...> - 2005-05-22 21:31:19
|
Le mardi, 17 mai 2005, =E0 06:36 Europe/Paris, Gwenole Beauchesne a = =E9crit=20 : > It's planned but I would like to fix the remaining bugs first and=20 > improve how packets are interacting with B2. Fixed in CVS for my ppc system (MacOS X & Linux). > Strangely, I sometimes don't get good performance. Yesterday, it was=20= > 1.2 KB/sec (yes kilobyte) vs. 450 KB/sec on x86_64 though the=20 > Linux/ppc version was at around 200 KB/sec. This is because I had switched Fetch into passive mode. Disabling=20 passive mode brought speed again. |
|
From: Gwenole B. <gb....@fr...> - 2005-05-17 04:54:47
|
Hi, > Paranoia checks... > FATAL: sc->regs->gpr[2] in signal handler (00000040) doesn't have=20 > expected value (affebad5) > Maybe you need a different kernel? > logout > [Process completed]" This could mean Tiger no longer preserves r2 (either the Mach kernel or=20= the BSD subsystem). Is the Classic environment still available in MacOS=20= X 10.4? Possible solutions: - Use Mach signals to avoid passing through the BSD system that may=20 alter global registers? - Use a "code copy" mode in the CPU emulator. This will be the most=20 fast-path portable solution (including NetBSD/ppc) though performance=20 won't be 100% native speeds but we could expect around 90% I think. > My best guess is that this is simply a problem with the new Tiger=20 > kernel, and that its currently being worked on. I hope? :). Sorry, I don't have 10.4 and probably won't. I got upset by MacOS X=20 lately: they didn't support POSIX signal info frames correctly, no=20 anonymous POSIX semaphores either, no correct implementation of POSIX=20 cancellation points in their threads, no POSIX poll() neither FreeBSD=20 kqueue, slow context switches (for SIGSEGV recovery vs. Linux/ppc), etc. Well, I am running 10.2.8 but claiming a "rock-solid UNIX foundation"=20 can't be right, I am afraid. Oh sorry, just bad mood today, got up too=20= early. But thanks Christian for BasiliskII/SheepShaver. Besides being very=20 good emulators, they also are very good testcases. ;-) Bye, Gwenol=E9.= |
|
From: Gwenole B. <gb....@fr...> - 2005-05-17 04:36:18
|
Le dimanche, 15 mai 2005, =E0 12:44 Europe/Paris, Tomek Jerzykowski a=20 =E9crit : > Does it also apply to Sheepshaver? I think it doesn't, but since they > both share a lot of code, at least it makes sense to ask. It's planned but I would like to fix the remaining bugs first and=20 improve how packets are interacting with B2. Strangely, I sometimes=20 don't get good performance. Yesterday, it was 1.2 KB/sec (yes kilobyte)=20= vs. 450 KB/sec on x86_64 though the Linux/ppc version was at around 200=20= KB/sec. |
9 messages has been excluded from this view by a project administrator.
