Intel BasiliskII GUI for MacOSX 10.6 and 10.7
Moderators: Cat_7, Ronald P. Regensburg
Ok, new Lion-compatible version posted. Sorry for the delay! The repo and docs at github are updated as well.
I have verified the bug with selecting full-screen mode, but I have no idea at all why it happens. This whole thing is such a kludge! Cocoa-fying it is definitely on my todo list, but unfortunately it's rather low priority, sorry. If anybody wants to volunteer to help, that could definitely help motivate me
I have verified the bug with selecting full-screen mode, but I have no idea at all why it happens. This whole thing is such a kludge! Cocoa-fying it is definitely on my todo list, but unfortunately it's rather low priority, sorry. If anybody wants to volunteer to help, that could definitely help motivate me
Good and bad news. I think I figured out why the fullscreen selector in the GUI isn't working, and it should be fixable.
However, I can't properly test, because BasiliskII won't go fullscreen at all on Lion. I suspect this is the same SDL bug as SheepShaver has, though I'm unsure. But my attempts to build B2 on Lion have been utter failures, the new LLVM compilers look to be too different. Could someone else build a B2 that uses a patched SDL, and will hopefully work on Lion fullscreen?
However, I can't properly test, because BasiliskII won't go fullscreen at all on Lion. I suspect this is the same SDL bug as SheepShaver has, though I'm unsure. But my attempts to build B2 on Lion have been utter failures, the new LLVM compilers look to be too different. Could someone else build a B2 that uses a patched SDL, and will hopefully work on Lion fullscreen?
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
I can't comment on the use of your GUI in Lion because I still run Snow Leopard.
About the full-screen setting:
1. Something is visibly wrong in the interface to start with:
When I choose "Fullscreen", not only the setting for Window Refresh Rate disappears (which is correct), but also the settings for Width, and Height disappear. That should not happen. One should be able to choose resolution settings independently from window or fullscreen setting.
There is also a "Frame buffer Spec File" setting and when "Fullscreen" is chosen a "Frame Buffer Name" setting is added. As far as I know, both should not appear in the GUI for the MacOSX version of BasiliskII and they are not present (not visible) in the old GUI.
2. The resulting line in the prefs file when Fullscreen is set in your GUI is
while it should be
or
etc.
3. When a correct fullscreen value is available in the prefs file, for instance:
and your GUI is started, it reads the resolution values in the "Frame Buffer Name" field: 1024/768 and I can write a proper value to the prefs file by entering the resolutions settings in that field. But it should, of course, not work that way.
Apparently there is a mix-up between hidden setting fields when Fullscreen is chosen.
"Frame Buffer Name" and "Frame Buffer Spec File" should be hidden always.
Only "Window Refresh Rate" should be hidden when Fullscreen is chosen.
It is probably a simple coding error or syntax error that causes this mix-up.
Edit: Makes me think of what can happen with something small like a misplaced or missing quote character somewhere.
About the full-screen setting:
1. Something is visibly wrong in the interface to start with:
When I choose "Fullscreen", not only the setting for Window Refresh Rate disappears (which is correct), but also the settings for Width, and Height disappear. That should not happen. One should be able to choose resolution settings independently from window or fullscreen setting.
There is also a "Frame buffer Spec File" setting and when "Fullscreen" is chosen a "Frame Buffer Name" setting is added. As far as I know, both should not appear in the GUI for the MacOSX version of BasiliskII and they are not present (not visible) in the old GUI.
2. The resulting line in the prefs file when Fullscreen is set in your GUI is
Code: Select all
screen dga/
Code: Select all
screen dga/0/0
Code: Select all
screen dga/1024/768
3. When a correct fullscreen value is available in the prefs file, for instance:
Code: Select all
screen dga/1024/768
Apparently there is a mix-up between hidden setting fields when Fullscreen is chosen.
"Frame Buffer Name" and "Frame Buffer Spec File" should be hidden always.
Only "Window Refresh Rate" should be hidden when Fullscreen is chosen.
It is probably a simple coding error or syntax error that causes this mix-up.
Edit: Makes me think of what can happen with something small like a misplaced or missing quote character somewhere.
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
You mean you can't run BasiliskII full-screen or you can't run it at all? BasiliskII will not run full-screen in Lion, regardless prefs settings being correct or not. If your GUI now writes the settings to the prefs file correctly, that will be fine as far as the GUI is concerned.
I do not know if BasiliskII can be compiled in Snow Leopard with the SDL 1.2 that is corrected for full-screen in Lion. I succeeded in doing that with SheepShaver. I can try, maybe later today or this weekend.
I do not know if BasiliskII can be compiled in Snow Leopard with the SDL 1.2 that is corrected for full-screen in Lion. I succeeded in doing that with SheepShaver. I can try, maybe later today or this weekend.
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Success! I managed to build Basilisk II with working Lion fullscreen, and also tested my fix for my GUI. Both are available for download here: https://github.com/vasi/b2gui/downloads . Compilation instructions for B2 are here: https://github.com/vasi/b2gui/blob/b2-f ... /README.md , though building unfortunately works only on Snow Leopard.
Let me know if there are any problems!
Let me know if there are any problems!
Hi,
Basilisk II full screen works in Lion!.
The gui still has some quirks: you have to enter /0/0 in the framebuffer field to get the line
"screen dga/0/0" in the prefs file, and it displays some listbox control remnants just above and behind the frame buffer name entry field.
As Ronald said: you used to be able to set a resolution that would then be used in full screen. Setting "maximum" to both horizontal and vertical resolution would end up as dga/0/0 in the prefs file. Other choices would end up like e.g., "dga/1024/768" So, full screen respects the choices made in the resolution field and only replaces "win" with "dga", expect when the choices are "maximum", in which case these values are replaced by "0", which leads to running the native resolution full screen.
Best,
Cat_7
Basilisk II full screen works in Lion!.
The gui still has some quirks: you have to enter /0/0 in the framebuffer field to get the line
"screen dga/0/0" in the prefs file, and it displays some listbox control remnants just above and behind the frame buffer name entry field.
As Ronald said: you used to be able to set a resolution that would then be used in full screen. Setting "maximum" to both horizontal and vertical resolution would end up as dga/0/0 in the prefs file. Other choices would end up like e.g., "dga/1024/768" So, full screen respects the choices made in the resolution field and only replaces "win" with "dga", expect when the choices are "maximum", in which case these values are replaced by "0", which leads to running the native resolution full screen.
Best,
Cat_7
Glad it's working for you, too.Cat_7 wrote:Basilisk II full screen works in Lion!.
Did you download the new BasiliskIIGUI from here, as of an hour ago or so? It doesn't mess up the controls, doesn't have a framebuffer field, and allows setting 'Maximum' and 'Maximum' to get dga/0/0.The gui still has some quirks: you have to enter /0/0 in the framebuffer field to get the line
"screen dga/0/0" in the prefs file, and it displays some listbox control remnants just above and behind the frame buffer name entry field.
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
I think you accidentally switched files. I downloaded the GUI only minutes ago and it is again the one created yesterday.vasi wrote:Did you download the new BasiliskIIGUI from here, as of an hour ago or so? It doesn't mess up the controls, doesn't have a framebuffer field, and allows setting 'Maximum' and 'Maximum' to get dga/0/0.
Yes, I was the first download. The one currently at github displays the error described above. Just downloaded again.
Best,
Cat_7
Best,
Cat_7
Last edited by Cat_7 on Fri Sep 23, 2011 4:52 pm, edited 1 time in total.
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Hmm, at least in Lion it doesn't seem to be running slowly. I only have Snow Leopard in a VM right now, so it's hard to compare speed--maybe I'll throw SL onto an old hard drive and try it out there.
Do the console messages look like the ones at the end of this post? Then they're just normal, indicating that the JIT is working. For some reason JIT profiling is turned on by default in the B2 source, I guess I could turn that off and it might make a slight difference.
[/code]
Do the console messages look like the ones at the end of this post? Then they're just normal, indicating that the JIT is working. For some reason JIT profiling is turned on by default in the B2 source, I guess I could turn that off and it might make a slight difference.
Code: Select all
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : enable runtime disassemblers : no
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : compile FPU instructions : yes
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : requested translation cache size : 8192 KB
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: Max CPUID level=10 Processor is GenuineIntel [PentiumPro]
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : target processor has CMOV instructions : yes
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : target processor can suffer from partial register stalls : yes
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : alignment for loops, jumps are 16, 16
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : lazy translation cache invalidation : on
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : register aliasing : on
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : FP register aliasing : on
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : lazy constant offsetting : on
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : translate through constant jumps : on
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : separate blockinfo allocation : on
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : building compiler function tables
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : supposedly 42382 compileable opcodes!
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : actual translation cache size : 8192 KB at 0x1595B000
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : gather statistics on untranslated insns count
11-09-23 1:55:36.913 PM [0x0-0x380380].BasiliskII: <JIT compiler> : gather statistics on translation time
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Inspired by you, I again compiled BasiliskII in Snow Leopard, now for i386 architecture, and using the patched SDL 1.2 source I used for SheepShaver. The resulting application runs fine in Snow Leopard, again much faster then your build, and without the JIT compiler messages in Console. Also, the application is about half the size of your build (1.3 vs 2.7 MB). I have no idea where the differences come from. Could someone check if this build also can run full-screen in Lion? (Added my initials to the archive name for identification.)
http://www.xs4all.nl/~ronaldpr/basilisk ... .6-RPR.zip
Edit: I used the source I downloaded one month ago, August 23.
http://www.xs4all.nl/~ronaldpr/basilisk ... .6-RPR.zip
Edit: I used the source I downloaded one month ago, August 23.
Hi,
I see no speed differences in Lion between both builds. (EDIT: I only looked at boot times, not actual performance, which is way slower is Ronalds build)
Ronald' latest build also does full screen in Lion.
Best,
cat_7
I see no speed differences in Lion between both builds. (EDIT: I only looked at boot times, not actual performance, which is way slower is Ronalds build)
Ronald' latest build also does full screen in Lion.
Best,
cat_7
Last edited by Cat_7 on Sat Sep 24, 2011 6:03 am, edited 1 time in total.
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Ronald, I'm glad you got your build working! What did you do differently since yesterday? You reported:
The speed difference you're seeing could be because we're using different SDLs. I think you're using 1.2.14 patched with just a single fix for Lion, right? I used the version from hg HEAD, which has seen a lot of churn recently, it could be one of the changes made it slow on 10.6. Alternatively, maybe it's just that your SDL version still allows VOSF and/or threaded screen updates. Do you see the speed difference become more pronounced with larger screen sizes?
Anyhow, if your version works fullscreen on Lion, and also works full-speed on SL, then you should probably make a new sticky post for it, I'm sure a lot of people would be interested in downloading it.
I think it's important that we document our build techniques, as SS and B2 seem to be becoming harder to build correctly, and I want to make sure it remains possible for us and for others. Did you use any different configure params? Any patches?Compiling BasiliskII in Snow Leopard does not work. Everything seems to proceed fine, but the resulting BasiliskII application crashes at launch with a long list of errors.
The speed difference you're seeing could be because we're using different SDLs. I think you're using 1.2.14 patched with just a single fix for Lion, right? I used the version from hg HEAD, which has seen a lot of churn recently, it could be one of the changes made it slow on 10.6. Alternatively, maybe it's just that your SDL version still allows VOSF and/or threaded screen updates. Do you see the speed difference become more pronounced with larger screen sizes?
Anyhow, if your version works fullscreen on Lion, and also works full-speed on SL, then you should probably make a new sticky post for it, I'm sure a lot of people would be interested in downloading it.
Hm, bad news, your version seems to be slower for me, at least on Lion. It boots very quickly, and runs ok in the Finder, but a couple of games I tried were both too stuttery to play. I tried Swoop and Loony Labyrinth pinball (no download available, sorry). Neither your version nor mine appear to be using VOSF on my Mac, so that's not the problem. Any ideas?
Hi,
Using the same prefs file, it seems the jit is not enabled in SL in Ronalds build, while it is in Vasi's:
From Ronalds build:
hsp-snow-leopard-hackintosh:~ hsp$ /Users/hsp/BasiliskII/BasiliskII_ronald.app/Contents/MacOS/BasiliskII ; exit;
Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using SDL/coreaudio audio output
VOSF acceleration is not profitable on this platform, disabling it
FATAL: Could not reallocate framebuffer at previous address
FATAL: Could not reallocate framebuffer at previous address
VOSF acceleration is not profitable on this platform, disabling it
logout
[Process completed]
From Vasis build:
/Users/hsp/BasiliskII/BasiliskII_vasi.app/Contents/MacOS/BasiliskII ; exit;
hsp-snow-leopard-hackintosh:~ hsp$ /Users/hsp/BasiliskII/BasiliskII_vasi.app/Contents/MacOS/BasiliskII ; exit;
Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using SDL/coreaudio audio output
<JIT compiler> : enable runtime disassemblers : no
<JIT compiler> : compile FPU instructions : yes
<JIT compiler> : requested translation cache size : 4096 KB
Max CPUID level=10 Processor is GenuineIntel [PentiumPro]
<JIT compiler> : target processor has CMOV instructions : yes
<JIT compiler> : target processor can suffer from partial register stalls : yes
<JIT compiler> : alignment for loops, jumps are 16, 16
<JIT compiler> : lazy translation cache invalidation : on
<JIT compiler> : register aliasing : on
<JIT compiler> : FP register aliasing : on
<JIT compiler> : lazy constant offsetting : on
<JIT compiler> : translate through constant jumps : on
<JIT compiler> : separate blockinfo allocation : on
<JIT compiler> : building compiler function tables
<JIT compiler> : supposedly 42382 compileable opcodes!
<JIT compiler> : actual translation cache size : 4096 KB at 0x1A626000
<JIT compiler> : gather statistics on untranslated insns count
<JIT compiler> : gather statistics on translation time
FATAL: Could not reallocate framebuffer at previous address
FATAL: Could not reallocate framebuffer at previous address
### Compile Block statistics
Number of calls to compile_block : 453370
Total emulation time : 42.8 sec
Total compilation time : 2.2 sec (5.2%)
Sorting out untranslated instructions count...
Rank Opc Count Name
logout
[Process completed]
Going to try this in Lion in a minute.
Cat_7
Using the same prefs file, it seems the jit is not enabled in SL in Ronalds build, while it is in Vasi's:
From Ronalds build:
hsp-snow-leopard-hackintosh:~ hsp$ /Users/hsp/BasiliskII/BasiliskII_ronald.app/Contents/MacOS/BasiliskII ; exit;
Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using SDL/coreaudio audio output
VOSF acceleration is not profitable on this platform, disabling it
FATAL: Could not reallocate framebuffer at previous address
FATAL: Could not reallocate framebuffer at previous address
VOSF acceleration is not profitable on this platform, disabling it
logout
[Process completed]
From Vasis build:
/Users/hsp/BasiliskII/BasiliskII_vasi.app/Contents/MacOS/BasiliskII ; exit;
hsp-snow-leopard-hackintosh:~ hsp$ /Users/hsp/BasiliskII/BasiliskII_vasi.app/Contents/MacOS/BasiliskII ; exit;
Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using SDL/coreaudio audio output
<JIT compiler> : enable runtime disassemblers : no
<JIT compiler> : compile FPU instructions : yes
<JIT compiler> : requested translation cache size : 4096 KB
Max CPUID level=10 Processor is GenuineIntel [PentiumPro]
<JIT compiler> : target processor has CMOV instructions : yes
<JIT compiler> : target processor can suffer from partial register stalls : yes
<JIT compiler> : alignment for loops, jumps are 16, 16
<JIT compiler> : lazy translation cache invalidation : on
<JIT compiler> : register aliasing : on
<JIT compiler> : FP register aliasing : on
<JIT compiler> : lazy constant offsetting : on
<JIT compiler> : translate through constant jumps : on
<JIT compiler> : separate blockinfo allocation : on
<JIT compiler> : building compiler function tables
<JIT compiler> : supposedly 42382 compileable opcodes!
<JIT compiler> : actual translation cache size : 4096 KB at 0x1A626000
<JIT compiler> : gather statistics on untranslated insns count
<JIT compiler> : gather statistics on translation time
FATAL: Could not reallocate framebuffer at previous address
FATAL: Could not reallocate framebuffer at previous address
### Compile Block statistics
Number of calls to compile_block : 453370
Total emulation time : 42.8 sec
Total compilation time : 2.2 sec (5.2%)
Sorting out untranslated instructions count...
Rank Opc Count Name
logout
[Process completed]
Going to try this in Lion in a minute.
Cat_7
Cat_7: That doesn't (necessarily) mean that JIT is disabled in Ronald's build, it could be that he just turned off JIT profiling messages. I honestly don't even know why the messages are on by default, they have the potential to slow down the JIT--next time I do a build, I'll probably turn the messages off.
- Ronald P. Regensburg
- Expert User
- Posts: 7821
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
I have never seen the JIT profiling messages in any BasiliskII build before. I used the source I downloaded August 23. Could this profiling have been turned on or added recently to the source?
That was on August 23, the same date I downloaded BasiliskII (and SheepShaver) source I used again this time.
(SheepShaver built with this SDL could be run in Lion in full-screen mode but it had the same memory leak that is a known issue with SheepShaver and SDL 1.2.14. I than patched the SDL source for the memory leak with SheepShaver. That was a little tricky because I know how to apply the patch to SDL 1.2.14, but there were several changes in exactly the SDL source files that the patch needs to be applied to. I must have done something right, because the resulting 64-bit SheepShaver runs full-screen in Lion and does not have the memory leak.)
I used copies of the same SDL and BasiliskII source I used for SheepShaver in August.
Also tried launching applications in both your build and mine. Considerably slower in your build.
I did not yet try 'Swoop'.
Maybe try with more recent source?
This is how I built this one with August 23 source in OSX 10.6.8 and with XCode 3.2.6 installed:
The only difference was that I compiled now for i386.vasi wrote:Ronald, I'm glad you got your build working! What did you do differently since yesterday? You reported:
Compiling BasiliskII in Snow Leopard does not work. Everything seems to proceed fine, but the resulting BasiliskII application crashes at launch with a long list of errors.
I really do not know which is which. I installed Mercurial and didThe speed difference you're seeing could be because we're using different SDLs. I think you're using 1.2.14 patched with just a single fix for Lion, right?
Code: Select all
hg clone -u SDL-1.2 http://hg.libsdl.org/SDL SDL-1.2
(SheepShaver built with this SDL could be run in Lion in full-screen mode but it had the same memory leak that is a known issue with SheepShaver and SDL 1.2.14. I than patched the SDL source for the memory leak with SheepShaver. That was a little tricky because I know how to apply the patch to SDL 1.2.14, but there were several changes in exactly the SDL source files that the patch needs to be applied to. I must have done something right, because the resulting 64-bit SheepShaver runs full-screen in Lion and does not have the memory leak.)
I used copies of the same SDL and BasiliskII source I used for SheepShaver in August.
No, it is the same for different screen sizes.Do you see the speed difference become more pronounced with larger screen sizes?
Also tried launching applications in both your build and mine. Considerably slower in your build.
I did not yet try 'Swoop'.
Maybe first try and see if we can do better. It would be only useful (yet) for running full-screen in Lion but possibly also slower in Lion. In Snow Leopard there is no performance difference between this build and my October 2009 build.Anyhow, if your version works fullscreen on Lion, and also works full-speed on SL, then you should probably make a new sticky post for it, I'm sure a lot of people would be interested in downloading it.
Maybe try with more recent source?
This is how I built this one with August 23 source in OSX 10.6.8 and with XCode 3.2.6 installed:
Code: Select all
export CC="gcc -arch i386" CXX="g++ -arch i386"
cd SDL/SDL-1.2-patched
./autogen.sh
./configure --disable-shared --prefix=`pwd`
make
make install
PATH=`pwd`/bin:$PATH
export PATH
cd ../../BasiliskII/src/Unix
./autogen.sh --disable-vosf --enable-sdl-static --enable-sdl-audio --enable-sdl-video
make
make BasiliskII_app