That's the best solution in general for being up to date. Last I checked (and this was just with the dev machines), dosbox compiled fine, you just needed a small patch to get the dynamic core working properly.

I've played about with this and managed to get DosBox compiled on my Intel iMac - it's definitely a big improvement. Using the current dosbox-0.63 under Rosetta, I can't get CPU settings above 3500 with my favourite old DOS game (Betrayal at Krondor) before reaching 100% CPU (ie. one core). With my personally compiled version, CPU is at 70% of one core, with CPU settings of 20000 - fast enough for that game.

However, although I am a programmer, I am new to Macs, and I could only get this working by modifying the risc_x86.h header - not a good idea even if it hasn't cause me any problems. I am also new to sourceforge (I know, I know, but anywhere I've worked has always been focussed on proprietary software, not OSS).

So, I see that there a dynamic core patch on sourceforge, but where do I get it (I can't find it) and is there information on compiling this properly for the Intel iMacs? Edit: Should have looked further - found it. Hmm, it is pretty much what I did ... except I popped esi and edi off in the order they were pushed.

What error message did you get and what was your fix to make it compile?

(My Macbook won't arrive until 2-3 weeks time, so that's how new I'm at Macs...)

Actually, when I look back over the source I see I was wrong about what I did to get it to compile (I did this shortly after I got my iMac about five weeks ago so was working on memory).

I got the message "PIC register '%ebx' clobbered in 'asm'". So I did initially try to do what the patch does (modify risc_x86.h to pushl the registers then popl them back in sequence) but that didn't work. I got the same error.

So (I wouldn't recommend this since I'm not really sure what it means to do it), I removed %ebx from one line:

1        register Bit32u tempflags=reg_flags & FMASK_TEST;
2        __asm__ volatile (
3                "pushl %%ebp                                            \n"
4                "pushl $(run_return_adress)                     \n"
5                "pushl  %2                                                      \n"
6                "jmp  *%3                                                       \n"
7                "run_return_adress:                                     \n"
8                "popl %%ebp                                                     \n"
9                :"=a" (retval), "=c" (tempflags)
10                :"r" (tempflags),"r" (code)
11-                :"%edx",%ebx,"%edi","%esi","cc","memory"
12+                :"%edx","%edi","%esi","cc","memory"
13        );

This compiles and /seems/ to work fine, but as far as I'm concerned there are unknown consequences (unknown to me) in doing this. I'm sure someone out there could explain. I haven't had any issues running dosbox either with or without dynamic core, but I may just have not hit any problem code yet.

I also haven't got around to packaging dosbox up - I still just run it as an Intel-only binary in my home directory.

By the way, before compiling dosbox you'll also have to compile SDL. It wouldn't link until I modified libtool to use g++ instead of gcc.

Edit: And I just noticed in your first message you mention "download a compiler". You just need to insert your Mac OS X Installer DVD and install the developer tools. This includes X11, XCode and gcc, so no need to download anything.

I'd love to help but alas I've just got a PPC Mac mini here.

X11? What do I need that diabolical piece of software for? 🙁

Some people use x11 apps still, especially if they really like'em. However don't be confused, it's not needed at all to compile dosbox for Mac OS X.

Ah, thanks for the information. Well, that error is unfortunately quite a bit over my head (I know C++, but skipped the assembly courses). Guess I'll have to wait until someone releases a compiled universal binary.

> So I did initially try to do what the patch does (modify risc_x86.h to pushl
> the registers then popl them back in sequence)

Could you try to add push ebx/pop ebx pairs, until something changes?
From that sourceforge it sounds like something on the stack needs to
be aligned, and adding (maybe 4 pairs) to your current working compile
should keep at least the alignment of the stack.

Anyone compiling a universal 0.65?

I have found two versions of 0.63 for Intel Macs.

1) The CVS build at: http://mac.punknews.org/dosbox.html
2) Dosbox86 from http://lamer0.com/

The CVS build is very unstable, but lamers version is rock solid!
Could any of these guys compile 0.65 please?

I would do it myself, but I have trouble with the Dynamic Core Patch. 😜

I just checked lamer0's site, and it says (in quite old news):

A universal dosbox port with a working dynarec core. My patches for the dynarec core can be found at the official dosbox's sourceforge website.

So why wasn't 0.65 released as a universal binary?

Because the DosBox devs don't use OSX?

Compiling a universal build requires quite a bit of extra work and awareness, a fair bit of which is over my head honestly. I don't even know how to make a build with static libraries so that I can just post it and the person could run it without also installing the same SDL libraries I used! On top of that more than likely the Intel users are going to want it built with the dynamic core turned on which means making two separate builds entirely and then merging them with the tools into one. All theoretically doable but I'm not up for it. If I was I'd probably do it. If you really, really want it done. Either tell me how to do it or better yet, do it yourself. 🤣

It looks like it may be as easy as passing arch flags to the compiler and linker-

From http://www.codecomments.com/archive242-2006-1-772220.html

> Allen Brunson <brunsona@takethisout.newsguy.com> wrote: > > I believe the right way is to pass -arch ppc -arch i386 to the com […]
Show full quote

> Allen Brunson <brunsona@takethisout.newsguy.com> wrote:
>
> I believe the right way is to pass -arch ppc -arch i386 to the compiler.
> My (limited) understanding is that this will produce universal .o files,
> and when you go to link you'll get a universal library.

Your understanding is correct; that's how it works as long as you pass
-arch ppc -arch i386 to the linker as well.

Examples of this technique can from other makefile based packages can be found at:
http://www.entropy.ch/blog/Software/2006/02/0 … Build-Tips.html
http://blog.janik.cz/archives/2005/12/18/T20_09_25/

There is another way, using the lipo tool to combine binaries manually, but that's a lot more work.

Colin

Hmm, I wonder if everyone just ignored the quote I pasted? Let me try again:

A universal dosbox port with a working dynarec core. My patches for the dynarec core can be found at the official dosbox's sourceforge website.

Said by Lamer0 of http://www.lamer0.com/ as was linked above by Edgar (and I've downloaded his compile and I get full speed in Supercars International at 12000 CPU cycles, which is what I used to run on my PC, only here on my Macbook, with dynamic core, that takes about 30-50% of CPU power).

And people still listed why there's no universal of .65. No one's made it and submitted it.

I currently build dosbox myself with the dependencies provided by darwinports, which aren't built universal and I've not a clue how to force them to be. (Or if you can) So building a universal would demand I take care of that first. Even then, it'd still be ideal to make two separate builds and like them, that way x86 people are blessed with the dynamic core. Which is what I believe Lamer0 did for his build. 😀

eobet. wd doesn't believe the patches are totally correct. (the save of registers deal with allready saved registers).
The discussion then continued between 2 mac debuggers and hasn't reached a final conclusion yet (e.g what the correct patch is)
http://sourceforge.net/tracker/index.php?func … 551&atid=467234

Ah, thank you for the information.

http://mac.punknews.org/dosbox

take a look here