Jagged - try to open the dosbox.conf file in TextEdit and play around with the output-setting, and maybe the windowresolution settings.

MiniMax wrote:

Jagged - try to open the dosbox.conf file in TextEdit and play around with the output-setting, and maybe the windowresolution settings.

I'd also suggest trying full screen to see what happens there. If it works, you can play full screen without having to change your resolution.

I compiled the OSX version using compiler features the G3 CPU doesn't support (-faltivec). Thats probably the reason why you can't see anything.

The only solution would be to make a new binary dedicated for low-end apples. If I find some time I could compile one for you.

Any idea how much this improves speed? If it's not significant this optimization
should better be left out.

Well.. to find out how much performance boost the -faltivec gives I had to compile a version without all that compiler voodoo. Doing so the original problem would be solved (JaggedPath needing a G3 "optimized" binary).

I don't think that leaving out all the performance options in the actual release binary is a general good idea. It would hurt _all_ PowerPC users and give only a benefit to a very little group of G3 users. Let's face it: the first G4 was introduced in 1999 about 8 years ago - most people have G4 and up.

So my suggestion is to compile a OSX 10.2 or 10.3 "G3 optimized" binary and pack it to the official OSX release of DOSBox (in a seperate folder "G3 optimized binary/").

Yep, maybe adding a note on the homepage. Thanks for noting!

I have a G3 iBook as well, so thank you rheonie for informing us. 😀

So my suggestion is to compile a OSX 10.2 or 10.3 "G3 optimized" binary and pack it to the official OSX release of DOSBox (in a seperate folder "G3 optimized binary/").

I wasn't able to build a OSX 10.3 Panther version of DOSbox with the Xcode 2.4/GCC compilers (actually I wasn't able to compile SDL-1.2.11). I included the usual compilerswitches for Apples incarnation of the GCC compiler (-isysroot and the like) but SDL kept ignoring them and used the headers and libraries from the buildsystem (which is 10.4 Tiger).

So all I was able to compile is a G3 "optimized" version of DOSBox for OSX 10.4 Tiger. Maybe this one also runs on Panther or below but I dout that.

You can get it here:
http://www.enosnusnu.de/index.php?/archives/7 … ild-for-G3.html

rhonie - maybe you need to add -L/path/to/10.3/libs and -I/path/to/10.3/includes when building SDL?

maybe you need to add -L/path/to/10.3/libs and -I/path/to/10.3/includes when building SDL?

I also tried that one but it didn't help either 🙁. Maybe I'll add Xcode to one of the G3 iMacs at work and compile myself a working SDL 1.2.11 for 10.3 and place it under /opt/SDL-10.3/ orso and use that one for future "DOSBox G3" builds.

BTW, DOSBox itself wasn't so picky and used the compiler settings I told it to use. But without a 10.3 compatible SDL I can't build a 10.3 compatible DOSBox.

I don't know a single bit about Xcode, but .... MacOSX is a Unix/Linux system at heart. So if Xcode is a port of the GNU Compiler Suite, with fixed headers, libraries, suitable flags, it should be be possible to install Xcode inside a chroot'ed environment and fake an 10.3 environment. Outside the chroot'ed Xcode you have your 10.4 files - inside you can only access the 10.3 files.

.. it should be be possible to install Xcode inside a chroot'ed environment and fake an 10.3 environment.

Thats exactly how the whole thing works - or at least should work. 😀

You have different root trees with the complete headers and libraries for OSX 10.2 (abadonned in later Xcode releases) - 10.4 (universal). They reside under "/Developer/SDKs/" and you tell the compiler which one to use by adding "-isysroot /Developer/SDKs/MacOSX10.3.9.sdk/" to C, CPP and/or CXXFLAGS and "-isysroot /Developer/SDKs/MacOSX10.3.9.sdk/ -Wl,-syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk/" to LDFLAGS.

This works for ZLIB, libPNG and DOSBox and even the additional SDL helper libraries but not for libSDL itself. The problem is most likely somewhere in the autoconfig scripts. I could either fix these or simply choose the easy way and use a real 10.3 system to compile libSDL. I have in mind to choose the latter. 😀

rhonie - a chroot'ed installation is very different from just setting a few variables. It works pretty much like mounting drives in DOSBox. You need to be super-user (root) for it to work.

You start by creating a directory somewhere, and set up a minimal copy of the normal file-system. E.g.

1# mkdir /tmp/xcode-jail
2# mkdir /tmp/xcode-jail/etc
3# mkdir /tmp/xcode-jail/bin
4# mkdir /tmp/xcode-jail/lib
5# cp /etc/passwd /tmp/xcode-jail/etc
6# cp /etc/shad ow /tmp/xcode-jail/etc
7# cp -r /bin /tmp/xcode-jail/bin
8# cp -r /lib /tmp/xcode-jail/lib

(this is not a working setup - a lot of files will be missing, and you should trim the passwd and shadow file down to just 3-4 entries (root, sys, nobody, ...))

Now you test the jail with

1# chroot /tmp/xcode-jail /bin/ls /etc

If it works, then ls (and any other program) will only be able to see the inside of the "jail". It is like you had done a mount / /tmp/xcode-jail in DOSBox.
ls is a simple program. It is much more revealing if you can do a

1# chroot /tmp/xcode-jail /bin/sh