Jump to content

Raine + OS X


RomainQ

Recommended Posts

Hi Tux,

I'm a french developer, as I was stuck at home recovering from injury, I decided to give a try to get the latest Raine on my Mac to get some 90's fun :) !

So I've found Raine is now on github (nice !). I get it and tried to make it ! After 3 days of hard try / error, I managed to get it running and playing with it on my 64bit hardware !

I made several modifications to be able to compile it on OS X. I would like to share it with you, so people could make it on OS X easily too ! How can I do ? Github pull requests ?

 

Here are some points:

Environment:

  • Clean OSX install, 10.10.5 with Xcode and command line tools.
  • Use homebrew to reach a unix like dev environment (brew install xxx --universal). The --universal option to get both i386 and x86_64 in a fat dylib
    • Install sdl, sdl_image, sdl_ttf, sdl_sound
    • install muparser after adding the universal option in the formulae (brew edit muparser to edit and add it, just copy the example of sdl for instance to add univeral option).
    • install nasm to get the lastest asm compiler
    • install gettext and force the link (brew link gettext --force). No danger to do so, unlink can be done if necessary
    • intall libpng and libtiff is not yet present
    • install xz

You don't think you need Xcode here, just install gcc from homebrew too.

 

Then I started to launch make... I needed to update:

  • detect-cpu: as the script does not see my processor as 64bit and wrongly set it as x86...
  • makefile: update the darwin sections to use correctly the homebrews binaries and libs
  • cpuinfo.c: add includes to compile on OSX
  • adding missing bitmaps directory and content for the final app
  • adding missing fonts directory and content for the final app
  • update starscream init function as on OSX you can't use mov to load a variable address, you need to do a lea with indirection (portable, works on linux too)

And here I am. I get a full 32 bit Raine app running on OSX, 0.64.9 with asm optimisations.

But:

I had to disable the asm video core as I can't get the move.s working. It compiles, but it seems that code was first set as data (strange asm.inc def for CODE_SEG)... Do you still use this strange asm code ? Seems that it is so optimized (self modifying code no ??) that it keeps crashing on OSX (I think it is not allowed to modify the program on the fly or the program memory address can't be accessed like that on OSX). So I use the C video core.

 

I also tried to compile a full native C as 64bit, but the z80 does not compile (the helpers on asm version have more methods than the C one ... not up to date ?).

 

Et voila !

Romain

ps: I can't attach the Rain.app because it's too big. I might put it on a dropbox for people to test

Link to comment
Share on other sites

Excellent news !

I am french too by the way, but let's keep english on the forum !

 

For info I had given up on the osx build because I didn't get any feed back for it or almost nothing plus I had to build this on an hackintosh and it was not really convenient. I have a pc built around and amd athlon64 so it's not really convenient to run osx stuff on it.

 

For the asm code, yeah it's bleeding edge auto-modifying code, it's moved in the data segment precisely for this reason, the code segment is read-only on all modern os-es. I had found a work-around for this in osx, if you test my last osx build which is quite old now it should work and it's full asm, but it's very old stuff for me so I forgot exactly what I did ! There is a lot of asm inside even if using the c video core which should be complete now, the 68020 core is 100% asm, the 68000, the default z80 core, the 6502 core, plus some other functions here and there in the code (s files, but also inline asm in C source, usually the inline asm doesn't auto-modify itself though). So all of this requires quite a lot of testing. To test 68020, either run a taito f3 game, or gunbird.

Also the z80 c-core is not finished, currently I used it only as a proof of concept to make a full amd64 binary with very few drivers inside. The rom bankswitch doesn't work which means that most drivers wouldn't work with it. I don't remember which driver I took but it worked !

But making a compatible code for the rom bankswitch is a real pain because the way mz80 works obliged to make a lot of special cases and now they are very hard to port to some other cpu core... there are some perl scripts to build a raine with only some specific drivers so you can easily build something with just the C z80 core + a good driver which will work with it. The emudx games work fine with it, that's what I used for the amd64 build, it worked fine.

 

Yeah git pull requests are all the rage these days so if you want to make one you are welcome, or just send a simple patch either to the forum or by mail.

I just checked the git log, the last modifications for osx seem to date from december 2013 already !

Ah yeah after looking at the comments I remember I was unable to build a working binary with osx 10.8, I had to do it in 10.6, but for some reason the resulting binary seems to work everywhere, it might be related to this asm problem. Notice that normally even on hardened systems which don't allow that there should be a way to make an exception and to tell it to accept raine, but no idea if it's possible in osx (it is in windows and linux at least). Search for "osx" in git log if you want to have a look, I am not sure some of these changes are necessary on a real mac, my hardware behaved strangely sometimes in osx !

 

I think I covered everything, congratulations for your work anyway, it's rare to find someone willing to spend so much time to build raine, especially in osx where it's very hard !

Edited by Tux
Link to comment
Share on other sites

yeh, french power :wink: Congrats for your nice emulator.

Thanks for your reply. I'm not a hardcore player, but I love puzzle bobble, NAM-1975 and Metal Slug ... It keeps my mind happy while recovering !

I confirm that it's working very well on my macbook air. It's a full 32bit (i386) app, just the video core that is in C (as you said with little asm but this part works !). My job is to develop iOS and Mac apps so I've got the hardware. Don't hesitate to ask for tests on OSX. I love ASM (intel, not most of your at&t syntax ;)) and C, sdl, all is fun !

 

I was not able to run your 0.63 binary because it is linked to png lib somewhere... not available on my mac. That's why homebrew is nice, everybody can have the same environment with few command lines to set it up.

 

Ok, I'll try to send you pull requests on github, otherwise I'll make patch files and sent them to you (I did not try to compile on linux again with my modifications).

 

I'll try to learn about self modifying code on OSX, but loading the function from data section made the app crash. It did not even try to run the asm code ...

 

And by the way, there is a nice project, called OpenEmu on OSX, which unify all emulators in one place. If I could work on Raine core and add it, it would be nice. But maybe I won't have time for that ... ;)

 

See you !

Romain

 

 

post-56110-0-24286500-1445459912_thumb.jpg

Link to comment
Share on other sites

Yeah when it can't execute any code in the data segment and crashes instead it's the sign of a hardened os which removes the execution permission from the data segment, it's a little over-paranoid if you ask me, buffer overflows are in the stack segment usually, not in the data segment, but I guess there are ways to inject code there too...

For the 68020 crashing, in the beginning this core was the C core from uae, then Antiriad and friends took the asm produced by the compiler and started to modify it directly... Yeah these were crazy times ! Now what we have is the modified asm version and the c version is lost !

I guess the crash is probably in Execute68020 in source/68020/newcpu.c look at the comments, there is an ifdef to use the asm version for everyone, you might want to try the c version instead for you here...

Edited by Tux
Link to comment
Share on other sites

Woh, you were totally crazy those days to hack asm like that !! Anyway, it makes it "non portable" on hardened os ... it would be great to have a clean plain C project working ! It would help for future platforms and full 64bit compile. Rewriting the asm in 64bit version could be hard... even if I saw that starscream has been updated in 0.27a version to get x86_64 !

 

The 68020 is not working for the same reason as the video asm core code, it is self modifying... The crash comes from InitJedi(), calling Init020_00(). This function is self modifying.

 

You say that the c version is lost but in the 68020 source directory there is also a c directory. Code inside is from uae. I might give it a try ?!

 

I also saw the mprotect() call on OSX to enable read/write/execute flags on pages... never used it so I need to check if it can do the job for self modifying code !

Link to comment
Share on other sites

Got the 68020 C files compiling and linking, and running gunbird does not crash anymore. But (there is always a but), the video does not start, I've got 1 second of sound and then Raine goes into infinite loop, sucking 100% CPU.

I don't know how to debug that for the moment !! Is my Gunbird rom ok ? Seems so as it is checked by Raine.

Link to comment
Share on other sites

Ah yes I had even completely forgotten about these. If I am not wrong this c directory is from the early days of raine32 when the guy who created it first tried to revert to the C version because he couldn't make the asm version to work, but he used visualc and not mingw32, it was probably the main cause of his problems... You are in uncharted territory here, never used these files !

 

But it could be interesting to take a look...

The idea to have an optional C version of raine is not new, I gave it a try last year to see what we could do with android (their tool to pseudo compile C code by converting it to some bytecode, forgot the name, but it's slower than java this way and it's not low level at all). Anyway it was hard, produced a very large binary with bugs very hard to track (good luck with the debugger there !). So I gave up, too many problems, too frustrating, and raine is not about some too big thing where you can't go to low level, it's the opposite actually !

 

The other reason would be to make an amd64 pure binary but I don't think it would be faster, even with the new registers and the new instructions, this code is insanely optimized, and anyway with modern machines it takes less than 1% cpu when running any emulated game ! But still it could be interesting. The problem is that the cpu cores can't be just replaced, they are not compatible with each other, plus most of them were modified in raine either to be faster or to adapt to some tricky emulation problems, so it would not be an easy task to replace them.

For the cpu cores to take, I am not totally sure :

- cz80 seems nice for the z80 and very easy to adapt. Now as I said it's not finished and what remains to do is not easy !

- for the 68k, I am not sure, there is this old unused c code for the 68020, and maybe the updated starscream to amd64 asm, but it would probably be better to have some pure C code here, and maybe merge 68000 and 68020 (which was the idea at the beginning of raine, they had the hope that starscream would eventually support the 68020 but it never happened). Well uae evolved in this way now with their core you can emulate anything from the 68000 to the 68040 with some jit options which could also be interesting. Now it would not be easy, the changes integrated to raine would need to be reapplied there, and usage of this thing is probably very different from what we have now.

- 6502 : absolutely no idea. It's not used in a lot of drivers anyway but still I guess I would need to find something in this case...

- and then there is the case of this sh2, I have started a git branch for that trying to integrate the asm core from a saturn emu which would fit very well raine, but I am not sure I'll finish it.

 

Anyway I'll take a look at this, eventually create a repo on github with your sources and send the url, it would be easier to check this 100% cpu problem, but my first guess would be that this C emu doesn't work because a few of the required changes made to raine were forgotten in the C version... ! It would be much easier if you can make it work using mprotect, but I think mprotect works only for allocated memory, here it's already compiled code. You could always try to move it but it would be tricky !

There is probably a global option in osx to do that. It's called "data execution prevention", browsing google about that, I found this :

http://www.cnet.com/news/how-to-bypass-gatekeeper-in-os-x-mavericks/ maybe it could help ?

The other way is to use mprotect which is really tricky here...

 

EDIT : just pushed a change to git to make this c version of the 68020 usable. Just uncomment C68020 in the makefile to use it. It probably never worked, there was something really stupid in Execute68020, it divided the asked cycles by 16 (!) before executing ! Everything was going so slowly... !

Also the speed hack handling needed to be adjusted the cycles can't be set directly to 0 with this version.

And apparently the timing of instructions was just thrown to the trash in the asm version, all the instructions used 4 cycles, never noticed that until now !

Well with all the speed hacks used for the 68020 I guess it didn't really matter anyway...

Edited by Tux
Link to comment
Share on other sites

Great feedback again thanks !! Seems you have 10 years of dev knowledge in your mind ! Crazy asm.

Of course keeping the 32bit optimized version is nice, a pure C project is nice too (I can imagine Raine on arm / RaspberryPi ?).

 

For the 68k, what about https://github.com/kstenerud/Musashi ? It's a 68000, 68010, 68EC020, and 68020 emulator written in C.

 

I'll check your global option on osx for self modifying code and the C code for the 68020 !

Link to comment
Share on other sites

Gatekeeper has nothing to do with the issue of self modifying code. I can run unsigned app on my Mac easily by unlocking it in the security center.

Yes, creating a mmpage and copy the asm code to be run as self modifying will be really hard ! ;)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...