Login  •  Register


The time is now: Wed Jul 30, 2014 1:07 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 3 of 3 [ 69 posts ]    Go to page Previous  1, 2, 3
Print view Previous topic  |  Next topic
Author Message
 Post subject:
PostPosted: Sat Sep 24, 2011 9:21 am 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3982
Location: Amsterdam, Netherlands
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Sat Sep 24, 2011 11:48 am 
Offline
Tinkerer

Joined: Mon Feb 23, 2009 11:46 pm
Posts: 48
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Sat Sep 24, 2011 1:35 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3982
Location: Amsterdam, Netherlands
vasi wrote:
Assuming the basilisk-cvs list is working properly

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:
Code:
24-09-11 13:41:51   [0x0-0x28e28e].BasiliskII-3[84467]   Sat Sep 24 13:41:51 MacKanjer4.local BasiliskII[84467] <Error>: CGContextFlush: invalid context 0x0


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:
Code:
24-09-11 14:51:29   BasiliskII[45375]   *** __NSAutoreleaseNoPool(): Object 0x273ecd30 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking

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

vasi wrote:
Can you tell me which revision you worked from?

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

Quote:
And maybe also share your patches to SDL.

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


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Sat Sep 24, 2011 2:33 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3982
Location: Amsterdam, Netherlands
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Wed Sep 28, 2011 4:02 pm 
Offline
Tinkerer

Joined: Mon Feb 23, 2009 11:46 pm
Posts: 48
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.


Code:
disk /Users/vasi/Desktop/emu/MacOS 7.6.1.img
disk /Users/vasi/Desktop/emu/HFS.img
extfs /Users/vasi/Desktop
screen dga/1024/768
seriala
serialb
ether slirp
udptunnel false
udpport 6066
rom /Users/vasi/Desktop/emu/Quadra.ROM
bootdrive 0
bootdriver 0
ramsize 268435456
frameskip 0
modelid 14
cpu 4
fpu true
nocdrom false
nosound false
noclipconversion false
nogui false
jit true
jitfpu false
jitdebug false
jitcachesize 8192
jitlazyflush true
jitinline true
keyboardtype 5
keycodes false
mousewheelmode 1
mousewheellines 3
dsp /dev/dsp
mixer /dev/mixer
ignoresegv false
idlewait true


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Wed Sep 28, 2011 9:01 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3982
Location: Amsterdam, Netherlands
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Thu Sep 29, 2011 4:16 am 
Offline
Tinkerer

Joined: Mon Feb 23, 2009 11:46 pm
Posts: 48
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:

Code:
extfs /
screen win/512/384
seriala
serialb
udptunnel false
udpport 6066
bootdrive 0
bootdriver 0
ramsize 8388608
frameskip 6
modelid 5
cpu 3
fpu false
nocdrom false
nosound false
noclipconversion false
nogui false
jit false
jitfpu false
jitdebug false
jitcachesize 0
jitlazyflush false
jitinline false
keyboardtype 5
keycodes false
mousewheelmode 1
mousewheellines 3
dsp /dev/dsp
mixer /dev/mixer
ignoresegv false
idlewait true


I propose adding/changing the following:

Code:
extfs $HOME/Desktop/
screen win/800/600
frameskip 0
ramsize 67108864
jit true
jitcachesize 8192
jitlazyflush true
jitinline true
idlewait true
ether slirp


Does this seem reasonable for modern Macs?


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Thu Sep 29, 2011 6:32 am 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 3370
Location: Sittard, The Netherlands
It seems to me those are sensible defaults.

Best,
Cat_7


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Thu Sep 29, 2011 9:31 am 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3982
Location: Amsterdam, Netherlands
vasi wrote:
Cat_7 must be correct that your build is simply not using the JIT.

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.

Quote:
I propose adding/changing the following:

Code:
extfs $HOME/Desktop/
screen win/800/600
frameskip 0
ramsize 67108864
jit true
jitcachesize 8192
jitlazyflush true
jitinline true
idlewait true
ether slirp


Does this seem reasonable for modern Macs?


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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Thu Sep 29, 2011 11:57 am 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 3370
Location: Sittard, The Netherlands
Would "~/Desktop" do?

EDIT: Nope, these expressions are not evaluated during startup

Cat_7


Last edited by Cat_7 on Thu Sep 29, 2011 1:33 pm, edited 1 time in total.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Thu Sep 29, 2011 2:45 pm 
Offline
Tinkerer

Joined: Mon Feb 23, 2009 11:46 pm
Posts: 48
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Thu Sep 29, 2011 3:47 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3982
Location: Amsterdam, Netherlands
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Thu Sep 29, 2011 3:51 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 3370
Location: Sittard, The Netherlands
Perhaps it could say "Changeme"or "SetMeToSomeLocation" ?

Cat_7


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Oct 10, 2011 6:33 am 
Offline
Tinkerer

Joined: Mon Feb 23, 2009 11:46 pm
Posts: 48
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


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Oct 10, 2011 3:45 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 3370
Location: Sittard, The Netherlands
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


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Tue Oct 18, 2011 4:09 pm 
Offline
Tinkerer

Joined: Mon Feb 23, 2009 11:46 pm
Posts: 48
Cat_7 wrote:
Why not also include a browse button for the search for a shared folder?


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

Quote:
And a thought: the old GUI could assume a rom file called Mac OS ROM to be present in the foder it was in.


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?

Quote:
I believe there is no way to add comments in the prefs file?


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!


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Tue Oct 18, 2011 8:22 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3982
Location: Amsterdam, Netherlands
vasi wrote:
Quote:
And a thought: the old GUI could assume a rom file called Mac OS ROM to be present in the foder it was in.

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?

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.


Top
 Profile  
Post a reply  
PostPosted: Sat Sep 01, 2012 1:43 am 
Offline
Space Cadet

Joined: Sat Sep 01, 2012 1:41 am
Posts: 2
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?


Top
 Profile  
Post a reply  
PostPosted: Sat Sep 01, 2012 6:04 am 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 3370
Location: Sittard, The Netherlands
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


Top
 Profile  
Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 3 of 3 [ 69 posts ]    Go to page Previous  1, 2, 3


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group