I tried 'Swoop'. Don't know how to play the game (I am not much of a gamer, never have been), but music and sounds play fine in vasi's build and stutter in my build and also in my October 2009 build.

Assuming the basilisk-cvs list is working properly, there have been no changes in the B2 source since March: http://sourceforge.net/mailarchive/foru ... silisk-cvs

On the other hand, there have been quite a number of changes in SDL 1.2 since last month: http://hg.libsdl.org/SDL/shortlog/5960 . I built from revision 5960, which is still the newest. Can you tell me which revision you worked from? And maybe also share your patches to SDL. I didn't patch SDL at all, and my small changes to the B2 source are all at github: https://github.com/vasi/b2gui/commits/b ... creen-lion

It would also be great if you could let me know of a specific application or game where my B2 build is very noticeably slower than yours, like Swoop but in the other direction. Once we can easily tell the difference between 'slow' and 'fast', maybe we can bisect and find an SDL revision that's fast in both SL and Lion.

In the past years I noticed that sometimes changes are made to cvs that are not reported in the mailing list.

I tried building BasiliskII in the way I described above with todays freshly downloaded source, BasiliskII from cvs and SDL-1.2 through Mercurial (I suppose that is the last revision?). It resulted in a BasiliskII application that only shows a light grey screen and after a couple of seconds a single system beep. It could only be stopped with a forced quit in OSX and Console showed this message, endlessly repeated in high succession:


I also tried building BasiliskII in the way I describe above, again with the source from August 23, but now with the original SDL-1.2 as downloaded then through Mercurial, without the memory leak patch for SheepShaver applied. It results in an application that behaves the same as my yesterday's working build (fast startup, Finder, application launching, but stuttering sound in 'Swoop'), with one notable exception: It has the same memory leak that we know from SheepShaver:

So, apparently, BasiliskII is affected by the same memory leak with SDL 1.2.14 (and later 1.2) as SheepShaver.


I really do not know. How or where can I find which revision is the source code I used?


It is this patch (some call it a hack) by Jean-Pierre Chombier:
http://bugzilla.libsdl.org/show_bug.cgi?id=870

Described in more detail here for SDL 1.2.14:
http://www.emaculation.com/forum/viewto ... 5746#35746

Last month I applied the patch to SDL-1.2 I got through Mercurial (then the latest revision?) in order to be able to build a SheepShaver version that could run full-screen and did not have the memory leak. Apparently I succeeded somehow, although the files had changed since 1.2.14 and I needed to adapt the patch as described in the forum post linked to above.

Here are the files, original and patched side by side, for SDL 1.2.14 and for the August 23 SDL-1.2
http://www.xs4all.nl/~ronaldpr/sheepsha ... _patch.zip

The speed differences between my BasiliskII build and vasi's build are remarkable.

I already mentioned the startup, 7 seconds in my build and 35 seconds in vasi's build.

Creating a .sea.hqx archive from the Swoop folder with DropStuff is faster in vasi's build:
vasi's build: 25 seconds
my build: 70 seconds

but copying the 7.5.5 system folder is much faster in my build:
vasi's build: 150 seconds
my build: 4 seconds

Sound and music do not always stutter. I can hear no difference between both builds with sound and music in Prince of Persia. But, of course, Prince of Persia is less demanding.

I put together a Snow Leopard boot disk, and I'm not seeing nearly those differences! While running with the basilisk_ii_prefs at the bottom of this post, I get these timings:

Startup: V 7s, RPR 5s
System folder copy (33 MB): V 8s, RPR 6s
Archiving Swoop with DropStuff: V 5s, RPR 15s

Some notes:

• The stuttering I'm seeing in Swoop in the RPR build is not just audio stuttering, but video as well.
• In my build, I recommend turning off jitfpu. Gravitation, Ltd 5.0 is showing strange results with it on.

Indeed, with your settings the differences in speed between your build and my build are minimal.

I always (for years) used these:

jit true
jitfpu true
jitdebug false
jitcachesize 4096
jitlazyflush false
jitinline false

Especially the last two make the difference. I see no difference in my build between these settings and your settings, but in your build the difference is huge. Interestingly the different settings seem not to affect Swoop.

I wonder what causes this different behavior between our builds and also what makes your application almost twice the size of mine.

The audio and (indeed) video stuttering in Swoop in my build is severe, but yesterday I dug up Return to Zork and it plays OK in my build, though smoother in your build.

Cat_7 must be correct that your build is simply not using the JIT. This would explain not only the lack of JIT console messages, but also why the jit* settings have no effect on your build. Indeed, setting 'jitfpu true' on your build doesn't cause the problems in Gravitation Ltd, although it does in every JIT-enabled build I've tried.

I could try and hack up my GUI so that its default settings (with no pre-existing basilisk_ii_prefs file) are better, since clearly some of them are suboptimal. Here are the current defaults:



I propose adding/changing the following:



Does this seem reasonable for modern Macs?

It seems to me those are sensible defaults.

Best,
Cat_7

In which case probably none of the BasiliskII for MacOSX builds published and used here since 2006 (and possibly before that) ever used the JIT.



OK, except for the extfs setting.
1. "$HOME/Desktop/" will not work unless you make the GUI replace it with the actual /Users/username/Desktop path.
2. Because of serious problems in past versions, we have always warned against using an existing (important) folder, certainly not keep the default "/", and advised to create a separate 'shared' folder for that purpose only.

Would "~/Desktop" do?

EDIT: Nope, these expressions are not evaluated during startup

Cat_7

Yeah, I know it doesn't actually interpolate variables, I can do that in the default-setting code however. If ~/Desktop isn't a good default, maybe instead we should just use a directory that probably doesn't exist yet? ~/BasiliskiII or something.

Instructions in the manual are to put all related files and apps (BasiliskII, ROM, GUI, keycodes) together inside one folder named "BasiliskII". That folder can be anywhere, so the name "BasiliskII" for the shared folder may not be a good idea. The manual instructs to create a shared folder anywhere it is convenient and proceeds to describe a setup with a folder "Shared" inside the BasiliskII folder.

Perhaps it could say "Changeme"or "SetMeToSomeLocation" ?

Cat_7

Great idea, Cat_7!

The new version of B2 and B2GUI are up at Github, the default preferences now adjusted as I suggested below, plus the following new changes:

extfs -> "Put an OS X path here to share it with Basilisk"
rom -> "Put the path to your ROM file here"

Please test them out, and let me know if everything's acceptable. Just in case Github is lagging again, you can also get the new versions here: http://dl.dropbox.com/u/1355986/BasiliskII.zip

Hi,

Your GUI and build work perfectly in both Snow Leopard and Lion! Thanks

If you allow me one remarks for ease of use:
-Why not also include a browse button for the search for a shared folder? (Why didn't I think of that before?)

And a thought: the old GUI could assume a rom file called Mac OS ROM to be present in the foder it was in. Can that behaviour be duplicated in your GUI, even though it needs absolute paths? I believe there is no way to add comments in the prefs file?

Best,
Cat_7

I'll see if I can arrange that. The Gtk file picker is so horrid though, it's almost not worth it, ugh!



Hmm, I think I can make that happen. Should the GUI look in the folder containing the GUI, or the folder containing B2? And "Mac OS ROM" is the exact name of the ROM to look for?



You can add lines beginning with '#' manually, but the GUI provides no way to do this. I haven't investigated much, but I think with the current code it would be a pretty hard feature to add. Sorry!

Not sure, but isn't the feature that Cat_7 remembers a (not quite the same) feature in SheepShaver? When no rom file is defined in its prefs file, SheepShaver will recognize and use a rom file in the same folder with the exact name "Mac OS ROM". As far as I know, BasiliskII does not have a similar feature and BasiliskIIGUI does not write a "Mac OS ROM" by itself.

I am trying to make my installation portable by putting the rom and disk images into the app. How would i format the path to tell the app the files are inside it?

Hi,

The Basilisk application is actually a folder (as are all Mac applications). When you right-click on the Basilisk application, you can select "Show content" You then get into the folder structure of the BasiliskII.app folder. You should be able to place rom and disk there.
The path would look like /Volumes/YourMacHDName/Users/your username/BasiliskII.app/Contents......
Or, if and when you don't need the absolute path, BasiliskII.app/Contents.....

However, the preferences file needs to be found by BasiliskII when it starts. On Mac OSX BasiliskII always looks for this file in your homefolder. The file is called ".basilisk_ii_prefs" (mark the dot in front of the name. It makes the file invisible with normal finder settings).
So, in a normal situation, BasiliskII is dependent on your home folder containing that file and thus is not fully portable.

The only file that is always found in the basiliskII folder is a rom file called "ROM" or "Mac OS ROM" The disk image file needs a path set leading to it.

You might be able to conjure up some script that executes when you start BasiliskII, telling it where to find the required files as some form of command line with arguments. But I never tried in OSX.

There are some similar efforts with SheepShaver: The self-contained SheepShaver virtual machines and the COI package. Perhaps you can learn the trick from these.

A word of caution though: when you create a self-contained package that seems very easy to use, it will loose some flexibility in that files are fixed in place and name and size. Changing anything, like creating a bigger disk, using a different rom, etc. become inherently difficult for the recipient of your package.

Best,
Cat_7