Weird problem with SGDK on REAL hardware

doragasu · Post by **doragasu** » Tue Oct 09, 2012 9:04 am

A friend of mine is developing his first Megadrive/Genesis game using SGDK. He had it almost finished, but he detected a very strange problem.

The game works perfect on emulators, and also works perfect on real hardware when using an Everdrive Flash cart. But the game doesn't start when using simple flash carts (i.e. one containing only an EPROM/Flash chip, or even with the MD Pro flash carts.

We have only found one emulator the game doesn't work with: Picodrive 1.80 (used on a OpenPandora, I suppose Wiz/Caanoo versions behave the same). If you load this emulator and launch the ROM, the screen gets all black (excepting a white line on the top) and then the emulator immediately exits (I suppose it crashes and silently exits). But if you load the emulator, then load (and start) a commercial ROM and then, without exiting the emulator, load the developed game, then it works perfect!

The behaviour of the emulator gave me an idea for a test with real hardware:
1.- I have inserted a commercial game in my Megadrive I (PAL) and powered it on.
2.- WITHOUT POWERING OFF the Megadrive, I carefully removed the commercial game and then inserted the flawed game cart.
3.- I hit the RESET button and... the flawed game started working!

So the flawed game only starts if I previously play a commercial game and hot-swap it!

This gave me the idea that maybe it's an initialization problem. Maybe the flawed game misses some kind of initialization code the commercial games (and also the Everdrive loader) have.

I almost forgot: the flawed game fails to start on Megadrive I and II, but works perfect on Megadrive III.

Any ideas?

djcouchycouch · Post by **djcouchycouch** » Tue Oct 09, 2012 10:36 am

It does sound like there's some data not being initialized correctly.

The solutions I got are pretty much brute force trial and error:

- See if you can simplify the code as much as possible to try to find the location of the problem.
- See if you can set all your variables to a known value (0xbeef of something) and then look at your RAM at start up to see if there's anything out of the ordinary.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Tue Oct 09, 2012 11:21 am

Uninitialized variables are my most probable guess, maybe TMSS related too

doragasu · Post by **doragasu** » Tue Oct 09, 2012 12:03 pm

We thought about TMSS, but SGDK is supposed to handle TMSS stuff in the startup code, before main() is called, right?

Also the ROM has SEGA at 0x100, and the "Produced under license..." message is displayed.

We will check for uninitialized variables, but if that's the case, I suppose the compiler should be launching warnings.

djcouchycouch · Post by **djcouchycouch** » Tue Oct 09, 2012 12:44 pm

doragasu wrote:We will check for uninitialized variables, but if that's the case, I suppose the compiler should be launching warnings.

SGDK's makefile might not have that set. You might have to mess around with the settings.

Stef · Post by **Stef** » Tue Oct 09, 2012 2:21 pm

Do you checked the rom size pad ?
If it works on everdrive but not on another flash card, it may be related.
In SGDK i do 128 KB padding but you can try with 512 KB padding instead and see if that fix your problem.

Post by **KanedaFr** » Wed Oct 10, 2012 12:22 am

fix it with Ucon

Chilly Willy · Post by **Chilly Willy** » Wed Oct 10, 2012 1:43 am

I use dd to pad files. It's part of every linux distro, but in CygWin or MinGW, you have to install it separately. You pad files like this:

Code: Select all

	dd if=input.bin of=output.bin bs=128K conv=sync

where the block size (bs=) sets the amount to pad to. 128K tells it to pad the file to the next 128K boundary. A number by itself is bytes, K means kilobytes, and M means megabytes.

Anywho, your problem may be not handling hardware right... maybe you forgot to make a pointer volatile. Also, if you DO access hardware directly in the C code, you MUST NOT compile with the optimization level greater than 1. On certain CPUs, gcc will optimize such code so that it fails... most often on real hardware as opposed to emulators. That's not an issue on x86 or ARM, but IS an issue on PPC, MIPS, SH, and M68K.

doragasu · Post by **doragasu** » Wed Oct 10, 2012 8:52 am

What's Ucon?

We have tried with padding set to 512 kiB without success.

@ChillyWilly: Your suggestions about optimization issues make sense, we will try setting O1 and see what happens. But I'm not sure this can really be the problem, because of the way it works when doing a hot-swap with a commercial game.

To me it looks like a TMSS or initialization problem!

PS: To build my friend is using SGDK on windows (GCC 3.6).

Post by **KanedaFr** » Wed Oct 10, 2012 9:14 am

doragasu wrote:What's Ucon?

http://ucon64.sourceforge.net/
I use it for padding and checksum fix (perhaps another reason why it doesn't work)

Extract from my makefile

Code: Select all

UCON= $(GDK_PATH)/bin/ucon64/ucon64 --gen

$(UCON) --pad $<
$(UCON) --chk $<
$(UCON) --smd $<

note it could also upload your rom to Tototek Flash card

Stef · Post by **Stef** » Wed Oct 10, 2012 9:44 am

doragasu wrote:What's Ucon?

We have tried with padding set to 512 kiB without success.

@ChillyWilly: Your suggestions about optimization issues make sense, we will try setting O1 and see what happens. But I'm not sure this can really be the problem, because of the way it works when doing a hot-swap with a commercial game.

To me it looks like a TMSS or initialization problem!

PS: To build my friend is using SGDK on windows (GCC 3.6).

As you said, it may be a TMSS related problem but as i am using an everdrive to test on real hardware i cannot reproduce it.
What is weird is that Picodrive seems to handle the initialization problem...

Checking the boot part i cannot identify where is the problem :
http://code.google.com/p/sgdk/source/br ... oot/sega.s

By the way, your MD1 is a TMSS one right ?

doragasu · Post by **doragasu** » Wed Oct 10, 2012 1:01 pm

My MD1 is a TMSS one. We also tried on a MD2 with the same result.

As we were suspecting TMSS, we already checked sega.s and identified the code dealing with TMSS, but my understanding of 68k asm is limited. I suppose this line:

move.l #0x53454741,0x2f00(%a1)

Writes SEGA to 0xA14000, by using some kind of relative addressing. But I can't find when a1 is loaded, and I suppose it's loaded with 0xA11100 value.

The behaviour of Picodrive 1.80 could be an unrelated bug in the emulator, but it doesn't look like. I also tested the ROM with Picodrive 1.51 (for PSP), and with this Picodrive version (as well as with all the other tested emulators), the ROM worked flawlessly.

doragasu · Post by **doragasu** » Wed Oct 10, 2012 6:40 pm

The optimization tip also didn't work. The rom was compiled with -O1 from the beginning.

Chilly Willy · Post by **Chilly Willy** » Wed Oct 10, 2012 6:49 pm

A1 comes from this

Code: Select all

        lea     Table,%a5
        movem.w (%a5)+,%d5-%d7
        movem.l (%a5)+,%a0-%a4
...

Table:
        dc.w    0x8000,0x3fff,0x0100
        dc.l    0xA00000,0xA11100,0xA11200,0xC00000,0xC00004

The first three words go to d5, d6, and d7. The next five longs go into a0 through a4.

doragasu · Post by **doragasu** » Wed Oct 10, 2012 6:56 pm

Good to know, thanks.

Other test I have done: Commenting out everything (but including inside the ROM the resources), makes the ROM boot.

I have also tested Angry Birds ROM: With Picodrive 1.80, it exits the emulator 1 or 2 seconds after starting. With Everdrive, it boots perfect. With my flashcart it doesn't boot in my MD1! Could the problem be related? Maybe a bug in SGDK?