Good news to follow...
I PMed fonzie about that and he wrote:
Hi,
I'm crap in ASM SH2 so you'll notice that my demos uses only 68k (sh2's are looping in their cache ram).
In fact, the sega genesis code need to be compilated @ 0x880000 because when the 32x is enabled, the cartridge acces from genesis shift to 0x880000 (magic!).
Also, you need to have a good genesis rom header (the 32x/md header used in all 32x games).
Because this header (compiled @ 0x0) do that:
-Define where sh2 code starts (main and sub)
-Makes the genesis copy a little program in his ram
-Genesis jump on it.
-Genesis enable the 32x (both sh2 jumps on their code, cartridge shift @ 0x880000)
-Genesis (RE) jmp on the cartridge on the code compilated @ 0x880000
And all is ready for use!
So using GCC to build a 32x rom was never made (imagine else, WOW i want it, I want it!).
So you should contact Devster if you want more informations because I never made any 32x stuff using the sh2 and i would be very happy if you make a gcc packtage for 32X.
Btw: If you look at walmarsx sources, you'll find some important infos in maincode.68k (about the 32x rom structure / header).
Bye and good luck.
Fonzie
So I've had a look at maincode.68k of devsters WalMarsX and saw there are master.bin and slave.bin included.
If we somehow get these .bin files externally created via compiling C-files, we may have a working 32X game.
But my problem is: devster provides links to WinXP versions of snasm68K and snasmsh2...the first one really is WinXP compatible,
but the latter one (as well as all snasm tools) does not work under XP,
instead it gives the error:
Code:
INTERRUPT 0DH, GENERAL PROTECTION FAULT possible illegal address
error code = 0000
eax = 00000000 esi = 00047000 flags = 3202 ds = 01C7
ebx = 00047000 edi = 000404F0 eip = 000011D1 es = 01C7
ecx = 00047000 ebp = 00000000 cs = 01BF fs = 0000
edx = 00000000 esp = 00046F08 ss = 01C7 gs = 0000
Furthermore the demo GNUSNASM from the official 32x devkit shows a way how to call C-functions from asm code.
But as long as snasmsh2 does not work, I can't use WallMarsX.
The good news starts here:
I've worked on recompiling the GNUSIERA example using the usual Saturn GNUSH compiler from KPIT!
Then I ran into problems while linking with ld (libc and libgcc were not included, I found out later),
1st try:
I recompiled every single library of the example, found a bug in ASM code(hehe),
one in C-code and besides deprecated notation warning concerning asm files, it worked.
OK, for some unknown reason, make says: no rule to make target *.c or *.s,
although the makefile got:
Code:
.c.o:
$(CC) $(CFLAGS) -c $(INCLUDES) $<
.s.o:
$(AS) $(ASFLAGS) $(INCLUDES) -o $@ $<
So I had to list the files explicitly. Any clue on that?
It's fine, but the linking problem wasn't gone.
2nd try:
I realized that two libraries where missing,
so the next try was to just take libc.a and libgcc.a from the saturn compiler.
But the linker had an unknown reference to atexit() and I don't know where I can find this.
3rd try:
Unlike the GNUSIERA example, the Saturn SGL samples don't use ld, but gcc to link.
So I tried very carefully to adapt this(beware: I don't know much about linking and such tools).
And yes, it works. Everything could be recreated(rom.bin, sdram.bin),
but this example is for the CartDev 32x devkit (guess it, I don't got one) and the upload(to devkit) utility seems to place
the files at the right location:
Code:
toaddr 0x60c0000 1 0xf1
toaddr 0xe000001 1 0x7f
toaddr 0xe000000 0 0x06
toaddr 0x9080000 @sdram.bin
toaddr 0x900c000 @rom.bin
toaddr 0x9000000 @md.bin
toaddr 0xe000001 1 0x3c
toaddr 0xe080001 1 0x01
toaddr 0x60c0000 1 0xf3
So no chance to run the files in an emulator.
There must be an additional step for linking a ROM cartridge.
One last question: the GNUSIERA example obviously uses srec format and converts this to binary.
Although I link with sh-coff-gcc almost exactly like with Saturn(of course other link script),
the file rom.coff seems to be in srec format, not coff.
I found it out when I tried to use sh-coff-objcopy instead of the GNUSIERA sretobin.exe and it said the format is unrecognized.
So I compared rom.coff with sl.coff from saturn demos and the format really is not comparable.
So how could I accidently link a srec file with sh-coff-gcc?
Oh, my bottom hurts. Think the working 32X cartridge gets delayed to some other day.
I would appreciate your help.