Weird problem with SGDK on REAL hardware
Moderator: Stef
Weird problem with SGDK on REAL hardware
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?
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?
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 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.
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.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Uninitialized variables are my most probable guess, maybe TMSS related too
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
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.
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.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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:
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.
Code: Select all
dd if=input.bin of=output.bin bs=128K conv=sync
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.
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).
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).
http://ucon64.sourceforge.net/doragasu wrote:What's Ucon?
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 $<
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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.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).
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 ?
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.
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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
A1 comes from this
The first three words go to d5, d6, and d7. The next five longs go into a0 through a4.
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
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?
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?