ZSNES on Intel Mac, further progress

Strictly for discussing ZSNES development and for submitting code. You can also join us on IRC at irc.libera.chat in #zsnes.
Please, no requests here.

Moderator: ZSNES Mods

hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

bztunk wrote:What i want to know is, how did you find out what line to change where?

Blatant luck?
Yes, of course there's an element of that. But gdb is a great help as well. And it takes code reading skill too. But it's not necessary to understand all the code, only tiny parts of it.
Deathlike2 wrote:It's just possible that the NASM compiler for the Mac is just crappy at the moment. I remember hearing about some registers that can't be used for "some stupid reason" when it works just fine on the Linux/Windows version...
As far as I'm aware I did not encounter any problems with the registers. I think this is because the registers were saved and restored at appropriate times in the assembly code.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

hector, I'm just referring to the state of the compiler at the time... as it matures, these problems will fix themselves.

I'm sure Nach will love to get a hold of the code.. when he gets back.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Zsnes developers, please apply the patch to be found here:

http://hectorchu.googlepages.com

Mac Aficionados, please test the binary found on the same page.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

BRPXQZME wrote: I have the assembly/gcc-flag hacking skills comparable to those of a fish :P
Really? If you knew assembly as well as I did, why do you need help?
hector wrote:If anyone can provide pointers to where I can find hosting I can share the patch and the executable with you guys.
You can make a post, make a code tag and just post the patch...

Other options are to post to our tracker, or e-mail to one of the devs.


And I would very much like to see this patch.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Nach wrote:And I would very much like to see this patch.
See post above yours.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Yes I see, you posted as I was writing my response.

Okay looked this over.
I'm thinking it wants EXTSYMs defined in particular sections...
This could be a NASM or linker issue though.

Your malloc_size = 0 for example makes me think that it's not linking a BSS variable, but will link a DATA one there.

Any reason you removed -mdynamic-no-pic ?
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Nach wrote:Any reason you removed -mdynamic-no-pic ?
It raised the code alignment runtime warning.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Even with all your other changes?

ZSNES uses ebx, I only shudder to think what evil PIC code might do...
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Yes, enabling dynamic-no-pic still produces a code alignment warning.

I'm not sure you should worry too much about the registers, as the emulation core works fine for example.
BRPXQZME
Hazed
Posts: 54
Joined: Tue May 30, 2006 3:47 am
Location: Centreville, VA
Contact:

Post by BRPXQZME »

As long as you use the registers cleanly, it SHOULD work okay (or the screenshots here are fake and my senses deceive me even on my very own MacBook! :D ). That ebx thing being used as a PIC register is a Darwin quirk to watch out for... but as long as you don't trash it it should be fine?

These changes I find a bit weird (because like hell I understand what and why they change things), but they do make a working ZSNES, so the logical progression would be to make an app out of it... also, in the end, it might be better to be all goody-two-shoes about putting the SDL framework in a ZSNES.app/Contents/Frameworks/ since Mac users tend to expect a process like "Download .dmg file -> Open .dmg file -> Copy app to Applications Folder -> Run".

And yes, a good deal of these problems are probably caused by NASM being new and bad at OS X plus Apple GCC weirdness. That said, it's impressive that ZSNES runs natively on the Mac.
Nach wrote:Really? If you knew assembly as well as I did, why do you need help?
It's more about the 3-second attention sp--- OOOOH! SHINY!
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

BRPXQZME wrote:
Nach wrote:Really? If you knew assembly as well as I did, why do you need help?
It's more about the 3-second attention sp--- OOOOH! SHINY!
No insulting the fish. Thank you.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

First of all I would like to thank everyone's hard work on making ZSNES work on the Mac but I have a few question maybe someone could answer for me.

First of all I don't really know much about Macs so excuse any stupid questions I may ask.

1) Will ZSNES work on a Mac without any X11 framework libraries?
2) Will there be need for special features for Mac users.
3) This will be using the linux codebase correct?
4) Will someone be interested in becoming the official maintainer of the mac version?
5) Is there a way to detect what platform we are on before they run it to so PPC users don't try to run it?
6) Can someone please write a document on what is required to maintain compatibility with Mac OS X so other port maintainers such as myself will not constantly break it. This is an important one for me since I am about half way through my rewrite of the CPU code in ZSNES and I would like to be sure it still works on a Mac.

Thanks.
bztunk
Hazed
Posts: 84
Joined: Mon Dec 27, 2004 9:08 pm
Location: In A.D. 2101, war was beginning.

Post by bztunk »

pagefault wrote: 3) This will be using the linux codebase correct?
*SDL
16:13 <Link`sAdventure> If I had my choice between Fedora and Windows, I'd pick windows.
BRPXQZME
Hazed
Posts: 54
Joined: Tue May 30, 2006 3:47 am
Location: Centreville, VA
Contact:

Post by BRPXQZME »

pagefault wrote:1) Will ZSNES work on a Mac without any X11 framework libraries?
It does, it's just that it's the easiest way to set it in a quick ./configure with the X11 directory. In reality, you're not supposed to do that, I think... it's just a little trickier to link to the libs that aren't in the X11 folder. I'm still new to OS X development, so I haven't gotten my sea legs just yet.
2) Will there be need for special features for Mac users.
Nothing too special, I would imagine. A few key configuration changes (maybe). The only thing that would have to be added to make it follow some "10 commandments of OS X" that's probably out there is to make an app, which would probably be better off in a separate (rarely touched) codebase and only really used for releases (like MPlayerOSX is not actually IN MPlayer, but is rather a seperate project you can drop MPlayer into). It'd have a nice icon, you could drag-n-drop your ROM's onto it, and it'd work straight out of the box, if you did it right. No real need to do much more than that, it's just a full package the way a Mac user would expect a typical application.
3) This will be using the linux codebase correct?
Well, it is right now, and it works just dandy. SDL is awesome.
4) Will someone be interested in becoming the official maintainer of the mac version?
Someone will... even if it involves forcing a $2000 computer on them that they don't want!! (I'll be off on a pilgrimage, unfortunately. It will involve the forested countryside of the Shenandoah, old Sega controllers, and much finger-breaking. If Segata Sanshiro could stop a cruise missile with his bare hands, then I should learn how to as well.)
5) Is there a way to detect what platform we are on before they run it to so PPC users don't try to run it?
OS X will just pop up a dialog that says it "is not supported on this architecture", although it'd be worth a mention in the FAQ when it's all said and done.
6) Can someone please write a document on what is required to maintain compatibility with Mac OS X so other port maintainers such as myself will not constantly break it. This is an important one for me since I am about half way through my rewrite of the CPU code in ZSNES and I would like to be sure it still works on a Mac.
Short of reading all of Apple's documentation, there's probably not all that much that could be written for sure. Probably the best that can be done is to just have people with a Mac try run it. Chances are, you wouldn't be breaking anything if it still works across all the other platforms, though.
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

pagefault wrote:1) Will ZSNES work on a Mac without any X11 framework libraries?
Yes. Even SDL doesn't require X11.
pagefault wrote:2) Will there be need for special features for Mac users.
.app package, to include SDL library and icon.
pagefault wrote:3) This will be using the linux codebase correct?
Yes.
pagefault wrote:4) Will someone be interested in becoming the official maintainer of the mac version?
I can do it.
pagefault wrote:5) Is there a way to detect what platform we are on before they run it to so PPC users don't try to run it?
Yes, of course.
pagefault wrote:6) Can someone please write a document on what is required to maintain compatibility with Mac OS X so other port maintainers such as myself will not constantly break it. This is an important one for me since I am about half way through my rewrite of the CPU code in ZSNES and I would like to be sure it still works on a Mac.
Currently there are issues with NASM on OS X, probably in the out_macho module, that required me to move EXTSYMS in a couple of files around. Basically the values of the symbols within the file with the EXTSYMS were all messed up, so I had the brilliant idea of "let's try moving it around" and lo and behold it worked :D. Apart from that there weren't any issues with the C code, so if you're just porting asm to C that shouldn't break Mac compatability. As I mentioned before my next job, should I take it, would be to find out what the problem is in NASM so that any other problems with zsnes at the moment can be fixed and the workarounds with EXTSYMS undone.
I can keep testing the latest code on my mac and if any gotchas happen they can be documented at the time.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

I just tested it, it works wonderfully.

When this is put into a standard OS X app form, as in a .dmg, etc. Will we still be required to get SDL or is there some other way around it like packaging it or something?

This might just be a problem on my end, but ZSNES doesn't seem to be saving to it's zguicfgl.dat file, everytime I open all the settings are erased and I get the 1 time only message. I see it's located in /Users/*user*/.zsnes, and I can see the rom saves are working... .srm files.


Also what are the plans for the icon? Isn't OS X standard size for icons like 128? I believe the current one with zsnesw tops at 48.
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

I think the .app bundle will contain libSDL so that no extra downloading will be required on the user's part.

I believe that a commit by Grinvader recently made GUI settings save fubar. See https://zsnes.bountysource.com/svn/!revision/3139.

There are various sizes of icon in the source, the highest being 64x64. Perhaps the guy with the vector drawing can export a 128x128 version.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

What's the status on being able to compile with opengl enabled? Is this going to be a problem?
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

I don't think OpenGL will be available, and it's not really needed.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

Isn't OGL needed for the S (stretch) video modes? This is especially important for those with an iMac because of it's widescreen LCD. Also, when I mirror ZSNES to my TV under any res I get black bars on the side because it lacks S mode.

OS X uses OpenGL for it's games and many programs, is there some reason why this isn't possible with ZSNES? :?
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

It may be possible, but I haven't investigated it.

The Windows port is able to do stretch modes and it doesn't use OpenGL I think. Anyway I'll work on it after getting NASM working properly.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

I believe the Windows port uses DirectX to achieve this.
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Great news!

I've found the bug in nasm which was messing up the relocation info and have sent this information to Apple.

Therefore the EXTSYM workarounds in chips/fxtable.asm and chips/dsp1proc.asm are not needed.

Nach, when are the other parts of my patch going to be submitted? After all, they produce a working zsnes on Mac.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

hector wrote: Nach, when are the other parts of my patch going to be submitted? After all, they produce a working zsnes on Mac.
I correct one item in your patch which was pointed out, but differently.
EXTSYMs we ignore okay.
What's the deal with the putchar/getchar wrapper?
I also wonder what's with the key change layout.
The config file stuff I will alter properly when I get a chance. If you look at SVN you'll see we're quite busy at the moment.

BTW send your patch to the NASM team too, guys in charge of it is Cristopher something IIRC.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Code: Select all

Index: macros.mac
===================================================================
--- macros.mac	(revision 3183)
+++ macros.mac	(working copy)
@@ -63,3 +63,6 @@
 %macro ALIGN16 0
   times ($$-$) & 1Fh nop    ; Long word alignment
 %endmacro
+
+; Ensure data section precedes bss if any
+section .data
nasm's outmacho seems to care about the order the sections are presented to it, so we need this to ensure a section for data is created before the bss if it exists.

Code: Select all

Index: configure.in
===================================================================
--- configure.in	(revision 3183)
+++ configure.in	(working copy)
@@ -47,10 +47,10 @@
     NFLAGS="$NFLAGS -D__BSDSDL__ -f elf -DELF"
     ;;
   *-*-darwin* )
-    CFLAGS="$CFLAGS -D__MACOSX__ -arch i386 -mdynamic-no-pic"
+    CFLAGS="$CFLAGS -D__MACOSX__ -arch i386 -mstackrealign"
     NFLAGS="$NFLAGS -D__MACOSX__ -f macho"
     MMLIB_FILES="$MMLIB_FILES \$(MMLIBDIR)/osx.o"
-    LDFLAGS="$LDFLAGS -framework Carbon -framework IOKit -mdynamic-no-pic"
+    LDFLAGS="$LDFLAGS -framework Carbon -framework IOKit"
     ;;
   *-*-cygwin* | *-*-*ming*)
     NFLAGS="$NFLAGS -f win32"
@@ -159,10 +159,10 @@
   AC_MSG_CHECKING(if you want crazy optimizations)
   AC_MSG_RESULT($release)
   if test x$release = xyes; then
-    CFLAGS="$CFLAGS -O3 -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -s"
+    CFLAGS="$CFLAGS -O3 -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr"
     NFLAGS="$NFLAGS -O99999999"
   else
-    CFLAGS="$CFLAGS -O3 -fomit-frame-pointer -s"
+    CFLAGS="$CFLAGS -O3 -fomit-frame-pointer"
     NFLAGS="$NFLAGS -O1"
   fi
 
mdynamic-no-pic doesn't appear to do anything useful so get rid of it for now. mstackrealign is needed because zsnes uses 4 byte aligned stacks, but Mac OS X requires 16 byte aligned stacks. Remove -s from CFLAGS as g++ under OS X has problems with this. I think a strip at the end of the build would be the replacement for this.

Code: Select all

Index: linux/sdllink.c
===================================================================
--- linux/sdllink.c	(revision 3183)
+++ linux/sdllink.c	(working copy)
@@ -105,6 +105,7 @@
 extern int CurKeyPos;
 extern int CurKeyReadPos;
 extern int KeyBuffer[16];
+int sdl_keysym_to_pc_scancode(int sym);
 
 /* MOUSE INPUT */
 static float MouseMinX = 0;
@@ -168,6 +169,16 @@
 extern void gl_clearwin(void);
 #endif
 
+int getchar_help()
+{
+	return getchar();
+}
+
+void putchar_help(int c)
+{
+	putchar(c);
+}
+
 static void adjustMouseXScale(void)
 {
 	MouseXScale = (MouseMaxX - MouseMinX) / ((float) WindowWidth);
Under Mac OS X the scancodes are different to the standard PC ordering. Therefore a function is needed to translate from the OS-independent SDL keysyms to PC scancode values. sdl_keysym_to_pc_scancode() does this.
The wrappers for putchar and getchar are needed because for some reason ld complains about external relocation symbols in read-only segments. The symbols it complains about are these two. Anyway, you were the one who introduced a wrapper for malloc for exactly this reason.

Code: Select all

@@ -202,20 +213,18 @@
           numlockptr = 1;
         else
           numlockptr = 0;
-        if (event.key.keysym.scancode - 8 >= 0)
-        {
-          //if (pressed[event.key.keysym.scancode - 8] != 2)
-          pressed[event.key.keysym.scancode - 8] = 1;
-          ProcessKeyBuf(event.key.keysym.sym);
-        }
+        event.key.keysym.scancode = sdl_keysym_to_pc_scancode(event.key.keysym.sym);
+        //if (pressed[event.key.keysym.scancode] != 2)
+        pressed[event.key.keysym.scancode] = 1;
+        ProcessKeyBuf(event.key.keysym.sym);
         break;
 
       case SDL_KEYUP:
         if (event.key.keysym.sym == SDLK_LSHIFT ||
             event.key.keysym.sym == SDLK_RSHIFT)
           shiftptr = 0;
-        if (event.key.keysym.scancode - 8 >= 0)
-          pressed[event.key.keysym.scancode - 8] = 0;
+        event.key.keysym.scancode = sdl_keysym_to_pc_scancode(event.key.keysym.sym);
+        pressed[event.key.keysym.scancode] = 0;
         break;
 
       case SDL_MOUSEMOTION:
Make this translation the default. Maybe you don't like this part so much, in which case feel free to make it Mac OS X specific using the __MAC_OS_X__ define.

Code: Select all

Index: uic.c
===================================================================
--- uic.c	(revision 3183)
+++ uic.c	(working copy)
@@ -131,7 +131,7 @@
 }
 
 void *malloc_ptr;
-unsigned int malloc_size;
+unsigned int malloc_size = 0;
 
 void malloc_help()
 {
This fixes the gcc error of being unable to resolve the symbol malloc_size. Don't know why, but why resist?

By the way, with SVN as of revision 3218 the gui config file seems to save and restore properly now, but SuperFX2 seems to have broken. For example, Starfox works, but Yoshi's Island doesn't, whereas it worked on revision 3184. Is it also broken on your end, or have we found a Mac-only issue?
Post Reply