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

Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

hector, you are way way way behind on the current copy of the code.

As of this post, we are at revision 3222...
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 »

The patch is still valid for the current revision.
BRPXQZME
Hazed
Posts: 54
Joined: Tue May 30, 2006 3:47 am
Location: Centreville, VA
Contact:

Post by BRPXQZME »

tehnick wrote: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?
The .app file can package the SDL.framework (available from libsdl.org); ideally, that's how it should be linked.
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.
It's at 64 as it is... I went for that "real arcade feel" and scaled it up using one of those fancy filters, but I obviously don't have an app or I'd share it with the rest of the class....
tehnick wrote:OS X uses OpenGL for it's games and many programs, is there some reason why this isn't possible with ZSNES? :?
First, I don't know exactly how you compiled your ZSNES, but I'm pretty sure OpenGL is working for me. I used the configure option --with-opengl-prefix=/usr/X11R6 because I have X11 installed, and somehow or other it's linked to both the OpenGL framework and to /usr/X11R6/lib/libGL.1.dylib; obviously this isn't the correct way to go about it but rather a quick hack that I did for the sake of GET IT TO COMPILE. Clearly, this ZSNES binary isn't linked against X and SDL isn't using it, but if I had half a clue the OpenGL would be linked in the correct place.
hector wrote:mdynamic-no-pic doesn't appear to do anything useful so get rid of it for now.
That flag is basically for if you're using GCC's inline assembly. Basically gets rid of gcc being a pain in the neck when you have something like:

Code: Select all

__asm__ __volatile__(
<blah>
: "+S" (src), "+D" (dst), "+m" (count)
: "b" (palette), "c" (stage->sdp)
: "cc", "%eax", "%edx"
);
and then gcc says it can't find anything in BREG because it's already reserved ebx for PIC... well, the code DEMANDS to use ebx, so then you pass that flag! For ZSNES, since all the assembly isn't GCC inline, it doesn't matter either way, but you should probably use it anyway... none of the other supported platforms use PIC by default, so why should OS X?
mstackrealign is needed because zsnes uses 4 byte aligned stacks, but Mac OS X requires 16 byte aligned stacks.
Seconded.
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.
It works fine for other platforms, and it only gets broken with Apple's g++, and then only with parsegen. Maybe taking the flag out isn't the right way to go (it is, after all, a problem with Apple GCC, not the code), but you I guess you could just go the 'strip' route...


Either way, this is some good stuff!
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: 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.
I'd prefer to not work around bugs in the assembler if we can fix the assembler.
hector wrote: mdynamic-no-pic doesn't appear to do anything useful so get rid of it for now.
It is useful according to the docs I read. Does it work along side the other parameter?
hector wrote: 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.
No. I ported stupid code.

Just wrapping directly is idiotic. I'd look into removing those two functions, for fixing this as I think ZSNES is idiotic too regarding this. However it seems to demonstrate another bug with Apple stuff.
hector wrote: This fixes the gcc error of being unable to resolve the symbol malloc_size. Don't know why, but why resist?
BSS vs. DATA obviously. Apple bug which should be killed.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
BRPXQZME
Hazed
Posts: 54
Joined: Tue May 30, 2006 3:47 am
Location: Centreville, VA
Contact:

Post by BRPXQZME »

Nach wrote:
hector wrote: 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.
I'd prefer to not work around bugs in the assembler if we can fix the assembler.
In the long run, good idea. In the short run, just maintain a patch file in a sticky thread entitled HOW TO COMPILE ON MAC OS X or something like that in the earnest hope they fix the bug.
hector wrote: mdynamic-no-pic doesn't appear to do anything useful so get rid of it for now.
It is useful according to the docs I read. Does it work along side the other parameter?
Almost certainly. Although it isn't an ld flag, so that one can go.


EDIT: yeah... made equivalent changes to accommodate for SVN updates and the patch, and

Code: Select all

/usr/bin/ld: ui.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_malloc_size
collect2: ld returned 1 exit status
shows up despite adding in a .data before the .bss

Here's the updated patch (minus the section .data) so we're all on the same page here.... (maybe I'm just patching something in wrong)

ANOTHER EDIT: Nerfing it down to a warning, I don't see any gripes about sdlintrf.o, so that seems okay... but running the binary will procure a "Bus error". Hm.
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

You'll probably still require the 'section .data' at the end of macros.mac.
BRPXQZME
Hazed
Posts: 54
Joined: Tue May 30, 2006 3:47 am
Location: Centreville, VA
Contact:

Post by BRPXQZME »

Perhaps. I just left it out because it doesn't currently make any difference (seemed to before, though). Trying out latest SVN and checking to make sure I kept everything in the patch... I just figured out that I did miss one part.

EDIT: Okay, lots of just plain braindeadedness collected in various places. Nothing serious. It's okay. *deep breath*

This patch on 3228 works for me. That'll teach me to try to mess with someone else's committing spree.

3230? This one is fine, too.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

Can you up the latest patch? Doesn't seem to be working for revision 3231.

patching file chips/fxtable.asm
patching file chips/dsp1proc.asm
patching file macros.mac
patching file configure.in
patching file linux/sdllink.c
patching file linux/sdlintrf.asm
Hunk #1 FAILED at 21.
Hunk #2 succeeded at 81 (offset -37 lines).
Hunk #3 succeeded at 96 (offset -37 lines).
Hunk #4 succeeded at 461 (offset -74 lines).
1 out of 4 hunks FAILED -- saving rejects to file linux/sdlintrf.asm.rej
patching file uic.c
Hunk #1 succeeded at 133 (offset 2 lines).
Hunk #2 FAILED at 234.
1 out of 2 hunks FAILED -- saving rejects to file uic.c.rej
BRPXQZME
Hazed
Posts: 54
Joined: Tue May 30, 2006 3:47 am
Location: Centreville, VA
Contact:

Post by BRPXQZME »

The patch is to be applied to a clean pull off SVN, so revert all those files before applying the patch. (that is, works for me!)

EDIT: This one patches against 3232-3234.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

Hm, I just checked it out twice and same thing. I'm using the patch from here: http://hectorchu.googlepages.com/

Are you sure it hasn't been updated? =/
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Hi tehnick, no I haven't updated the patch, simply because Google Pages doesn't work with Safari, and I don't want to install Firefox. I can only update it when I get access to a Windows machine.

If you examine the rejected hunks you can work out how to patch it by hand. Otherwise you can use the patches from BRPXQZME.
Aaron
Lurker
Posts: 157
Joined: Sat Dec 31, 2005 7:26 am

Post by Aaron »

hector wrote:Hi tehnick, no I haven't updated the patch, simply because Google Pages doesn't work with Safari, and I don't want to install Firefox. I can only update it when I get access to a Windows machine.
You'd go through that much trouble just 'cause you don't want to install Firefox? Well, you can install Linux (I suggest Ubuntu), or you can try another web browser like Camino.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

I messed with packaging a bit and came up with this.

http://nourism.net/ZSNES_r3234.dmg

I made it .app executable and added the ZSNES icon to it. I didn't put any libraries for SDL or anything in it though. (So youll probably need SDL and X11 for it to work) But atleast the terminal window doesn't need to be opened all the time.
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Just a note regarding the linker flag -read_only_relocs:

With this set to suppress, the wrappers for getchar, putchar and also malloc can be removed.

However, this flag can also hide errors that crash zsnes. If the following change is reverted

Code: Select all

Index: uic.c
===================================================================
--- uic.c       (revision 3234)
+++ uic.c       (working copy)
@@ -133,7 +133,7 @@
 }
 
 void *malloc_ptr;
-unsigned int malloc_size;
+unsigned int malloc_size = 0;
 
 void malloc_help()
 {
malloc_size appears as a common symbol in uic.o rather than a data symbol. During linking, an error is normally produced that _malloc_size is a read-only relocatable symbol. This actually seems to happen because the linker can't find _malloc_size in uic.o for some strange reason. If this error is suppressed the resultant zsnes will crash with a bus error. BRPXQZME, I believe the bus error you experienced was for this very reason. In your case the fix would be the above patch.

To summarize the wrappers for getchar, putchar and malloc are not required by Mac OS X after all. However there is still some mystery as to why the linker can find malloc_ptr but not malloc_size.
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Just made a startling discovery.

malloc_size appears to be a special name. Because if we change the variable name to malloc_siz for instance, the resulting zsnes executable works fine (this is with the patch reverted).

Nach, can you either rename malloc_size to malloc_siz, or remove the malloc wrapper from the code?

PS malloc_size() is a function in Mac OS X! Type 'man malloc_size' to see what I mean.
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

As of revision 3233 upto 3235, no roms will output video, just a black screen with sound. I couldn't get 3232 to run so I'm not sure where exactly this started to happen.

Can anyone else confirm?
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

tehnick, I have a pretty good idea why you're experiencing these problems.

Were you following the discussion earlier on where I said I fixed the nasm bug? Well, you'll need to use a bug-fixed copy of nasm too!

Get a copy of latest CVS nasm. Then, apply this patch:

Code: Select all

--- output/outmacho.bak 2006-06-14 21:53:56.000000000 +0100
+++ output/outmacho.c   2006-06-13 21:41:03.000000000 +0100
@@ -1088,6 +1088,7 @@ static void macho_fixup_relocs (struct r
                sym = undefsyms[i];
                if (sym->initial_snum == r->snum) {
                    r->snum = sym->snum;
+                   break;
                }
            }
        }
This was the patch I sent to Apple, but they are refusing to apply it until I show them a testcase that verifies it. So until I send that to them we'll have to make use of our self-compiled bug-fixed nasms.

With your bug-fixed nasm you can revert the changes to chips/fxtable.asm and chips/dsp1proc.asm.

With these changes you'll find that latest SVN will work again! (It works for me)
Last edited by hector on Wed Jun 14, 2006 10:01 pm, edited 3 times in total.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Try compiling clean first.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

Sorry to bother you again hector, but your patch doesn't seem to be working... :? I also tried to apply it manually and then compiled nasm, then tried compiling revision 3235 with the same problem occuring.

your patch..

Code: Select all

--- output/outmacho.bak 2006-06-14 21:53:56.000000000 +0100 
+++ output/outmacho.c   2006-06-13 21:41:03.000000000 +0100 
@@ -1088,6 +1088,7 @@ static void macho_fixup_relocs (struct r 
                sym = undefsyms[i]; 
                if (sym->initial_snum == r->snum) { 
                    r->snum = sym->snum; 
+                   break; 
                } 
            } 
        } 
error..

Code: Select all

nicks-computer:~/nasm nick$ patch -p0 < ~/Desktop/nasm.patch 
patching file output/outmacho.c
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 1088.
1 out of 1 hunk FAILED -- saving rejects to file output/outmacho.c.rej
Deathlike2: I've already tried that with no luck.
Last edited by tehnick on Wed Jun 14, 2006 11:04 pm, edited 1 time in total.
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Maybe my diff is bad. Since it's only one line, can you just go in and add that line yourself?
tehnick
Hazed
Posts: 52
Joined: Wed Oct 06, 2004 1:41 am

Post by tehnick »

Sorry, I edited my post too late.

I also tried to apply it manually and then compiled nasm, then tried compiling revision 3235 with the same problem occuring.
hector
Rookie
Posts: 49
Joined: Fri Jun 09, 2006 12:47 am

Post by hector »

Well in that case I don't know what the problem could be. As I said earlier the latest SVN works fine here.

I'm using this patch at the moment:

Code: Select all

Index: ui.asm
===================================================================
--- ui.asm	(revision 3235)
+++ ui.asm	(working copy)
@@ -21,7 +21,7 @@
 %include "macros.mac"
 
 EXTSYM PrintStr,PrintChar,ram7fa,wramdataa,MMXSupport
-EXTSYM MMXextSupport,malloc_ptr,malloc_size,malloc_help
+EXTSYM MMXextSupport,malloc_ptr,malloc_siz,malloc_help
 EXTSYM BitConv32Ptr,spcBuffera,spritetablea,vcache2bs,vcache4bs,vcache8bs
 EXTSYM RGBtoYUVPtr,newgfx16b,vidbuffer,vidbufferofsa,vidbufferofsmos,ngwinptr
 EXTSYM vidbufferofsb,headdata,romdata,sfxramdata,setaramdata,wramdata,ram7f,vram
@@ -115,7 +115,7 @@
 %macro AllocmemFail 3
     mov eax,%1
     add eax,1000h
-    mov [malloc_size],eax
+    mov [malloc_siz],eax
     pushad
     call malloc_help
     popad
@@ -133,7 +133,7 @@
 %macro AllocmemOkay 3
     mov eax,%1
     add eax,1000h
-    mov [malloc_size],eax
+    mov [malloc_siz],eax
     pushad
     call malloc_help
     popad
Index: macros.mac
===================================================================
--- macros.mac	(revision 3235)
+++ 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
Index: configure.in
===================================================================
--- configure.in	(revision 3235)
+++ 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 -mdynamic-no-pic -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 -mdynamic-no-pic -read_only_relocs suppress"
     ;;
   *-*-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
 
Index: linux/sdllink.c
===================================================================
--- linux/sdllink.c	(revision 3235)
+++ 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;
@@ -202,20 +203,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:
@@ -451,6 +450,108 @@
   return TRUE;
 }
 
+int sdl_keysym_to_pc_scancode(int sym)
+{
+    switch (sym)
+    {
+    case SDLK_ESCAPE:       return 0x01;
+    case SDLK_1:            return 0x02;
+    case SDLK_2:            return 0x03;
+    case SDLK_3:            return 0x04;
+    case SDLK_4:            return 0x05;
+    case SDLK_5:            return 0x06;
+    case SDLK_6:            return 0x07;
+    case SDLK_7:            return 0x08;
+    case SDLK_8:            return 0x09;
+    case SDLK_9:            return 0x0a;
+    case SDLK_0:            return 0x0b;
+    case SDLK_MINUS:        return 0x0c;
+    case SDLK_EQUALS:       return 0x0d;
+    case SDLK_BACKSPACE:    return 0x0e;
+    case SDLK_TAB:          return 0x0f;
+    case SDLK_q:            return 0x10;
+    case SDLK_w:            return 0x11;
+    case SDLK_e:            return 0x12;
+    case SDLK_r:            return 0x13;
+    case SDLK_t:            return 0x14;
+    case SDLK_y:            return 0x15;
+    case SDLK_u:            return 0x16;
+    case SDLK_i:            return 0x17;
+    case SDLK_o:            return 0x18;
+    case SDLK_p:            return 0x19;
+    case SDLK_LEFTBRACKET:  return 0x1a;
+    case SDLK_RIGHTBRACKET: return 0x1b;
+    case SDLK_RETURN:       return 0x1c;
+    case SDLK_LCTRL:        return 0x1d;
+    case SDLK_a:            return 0x1e;
+    case SDLK_s:            return 0x1f;
+    case SDLK_d:            return 0x20;
+    case SDLK_f:            return 0x21;
+    case SDLK_g:            return 0x22;
+    case SDLK_h:            return 0x23;
+    case SDLK_j:            return 0x24;
+    case SDLK_k:            return 0x25;
+    case SDLK_l:            return 0x26;
+    case SDLK_SEMICOLON:    return 0x27;
+    case SDLK_QUOTE:        return 0x28;
+    case SDLK_HASH:         return 0x29;
+    case SDLK_LSHIFT:       return 0x2a;
+    case SDLK_BACKSLASH:    return 0x2b;
+    case SDLK_z:            return 0x2c;
+    case SDLK_x:            return 0x2d;
+    case SDLK_c:            return 0x2e;
+    case SDLK_v:            return 0x2f;
+    case SDLK_b:            return 0x30;
+    case SDLK_n:            return 0x31;
+    case SDLK_m:            return 0x32;
+    case SDLK_COMMA:        return 0x33;
+    case SDLK_PERIOD:       return 0x34;
+    case SDLK_SLASH:        return 0x35;
+    case SDLK_RSHIFT:       return 0x36;
+    case SDLK_KP_MULTIPLY:  return 0x37;
+    case SDLK_LALT:         return 0x38;
+    case SDLK_SPACE:        return 0x39;
+    case SDLK_CAPSLOCK:     return 0x3a;
+    case SDLK_F1:           return 0x3b;
+    case SDLK_F2:           return 0x3c;
+    case SDLK_F3:           return 0x3d;
+    case SDLK_F4:           return 0x3e;
+    case SDLK_F5:           return 0x3f;
+    case SDLK_F6:           return 0x40;
+    case SDLK_F7:           return 0x41;
+    case SDLK_F8:           return 0x42;
+    case SDLK_F9:           return 0x43;
+    case SDLK_F10:          return 0x44;
+    case SDLK_NUMLOCK:      return 0x45;
+    case SDLK_SCROLLOCK:    return 0x46;
+    case SDLK_KP7:          return 0x47;
+    case SDLK_KP8:          return 0x48;
+    case SDLK_KP9:          return 0x49;
+    case SDLK_KP_MINUS:     return 0x4a;
+    case SDLK_KP4:          return 0x4b;
+    case SDLK_KP5:          return 0x4c;
+    case SDLK_KP6:          return 0x4d;
+    case SDLK_KP_PLUS:      return 0x4e;
+    case SDLK_KP1:          return 0x4f;
+    case SDLK_KP2:          return 0x50;
+    case SDLK_KP3:          return 0x51;
+    case SDLK_KP0:          return 0x52;
+    case SDLK_KP_PERIOD:    return 0x53;
+    case SDLK_F11:          return 0x57;
+    case SDLK_F12:          return 0x58;
+    case SDLK_HOME:         return 0x59;
+    case SDLK_UP:           return 0x5a;
+    case SDLK_PAGEUP:       return 0x5b;
+    case SDLK_LEFT:         return 0x5c;
+    case SDLK_RIGHT:        return 0x5e;
+    case SDLK_END:          return 0x5f;
+    case SDLK_DOWN:         return 0x60;
+    case SDLK_PAGEDOWN:     return 0x61;
+    case SDLK_INSERT:       return 0x62;
+    case SDLK_DELETE:       return 0x63;
+    }
+    return 0x64+sym;
+}
 
 void ProcessKeyBuf(int scancode)
 {
Index: uic.c
===================================================================
--- uic.c	(revision 3235)
+++ uic.c	(working copy)
@@ -133,11 +133,11 @@
 }
 
 void *malloc_ptr;
-unsigned int malloc_size;
+unsigned int malloc_siz;
 
 void malloc_help()
 {
-  malloc_ptr=malloc(malloc_size);
+  malloc_ptr=malloc(malloc_siz);
 }
 
 extern bool input1gp;
Make sure the system is using your compiled nasm and not the old one. I made sure of this by putting the path to the new nasm at the front of my PATH variable.
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, can you either rename malloc_size to malloc_siz, or remove the malloc wrapper from the code?
No and no, but thanks for the tip.

Hopefully SVN should be friendlier for you now.
Have you tried getting the NASM patch to the NASM people?
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

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 »

The first one is CVS revision 1.4 of the file.
The second one is the latest CVS revision, 1.7.

I've now sent a testcase to Apple and the fix should eventually appear in CVS.

Thank you Nach for the commits. I don't want to seem ungrateful, but will you also consider committing the change to the LDFLAGS (-read_only_relocs suppress), and adding and using the function sdl_keysym_to_pc_scancode().
Post Reply