Game runs in emu but not on console

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

superjoebob
Very interested
Posts: 66
Joined: Fri Oct 15, 2010 7:06 am
Location: Vancouver, Canada
Contact:

Game runs in emu but not on console

Post by superjoebob »

Hey everyone,
I know this is probably obvious newbie stuff, but I figure since I'm new to this and can't seem to find an answer elsewhere I'll see if you guys know what the deal is. I've been working on a game for the Genesis using SGDK. I compiled all the sample programs and they all run perfectly in Gens and Kega. When I burn them to my NEO MYTH cartridge however, the only one that will run is the sound example, the others just show a black screen indefinitely. Is there something I'm missing, perhaps a region lockout?

Thanks :D
On a never ending quest to compose for the Genesis/Megadrive
Chilly Willy
Very interested
Posts: 2993
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy »

The most common failure in MD programming that works fine on emulators is having word or long data or code on odd boundaries. Double-check that all instructions start on an even boundary, and that word or long data is also on an even boundary.

If you incbin blocks of data and cannot guarantee their length, use alignment directives after the block to make sure whatever is after the block is always aligned properly.
Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef »

SGDK provides some tools for data alignment if you need that.
Also by default i am padding rom size to 128 KB (required for everdrive) but maybe the neo myth needs 256 KB padding.
As far i remember all samples works perfectly on my MD1 with everdrive.
Last edited by Stef on Mon Apr 09, 2012 9:23 am, edited 1 time in total.
superjoebob
Very interested
Posts: 66
Joined: Fri Oct 15, 2010 7:06 am
Location: Vancouver, Canada
Contact:

Post by superjoebob »

Holy crap, just looked at the format options on my Neo Myth and there was a check box that said "128M Fix" or something like that. Enabled it and the game works perfectly now, thanks Stef!
On a never ending quest to compose for the Genesis/Megadrive
Moon-Watcher
Very interested
Posts: 117
Joined: Sun Jan 02, 2011 9:14 pm
Contact:

Post by Moon-Watcher »

Chilly Willy
Very interested
Posts: 2993
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy »

Hmm - the NeoMyth menu for the MD used to have an issue if the rom wasn't padded to the nearest sector (512 bytes) - the last few bytes weren't being loaded to psram. I cured that a little while back, so you should make sure you're using the latest MD menu. But that's for SD loading. There shouldn't be such an issue with games in flash, but it's possible the client had a problem with games that weren't padding to a certain length.

On my own stuff, I have taken to automatically padding the length.

Code: Select all

$(TARGET).bin: $(TARGET).elf
	$(MDOBJC) -O binary $< temp.bin
	$(DD) if=temp.bin of=$@ bs=4096K conv=sync
where $(DD) is dd. The above line builds the elf file for the program, uses objcopy to turn it into a plain binary, then dd pads the binary to 4096K. If you use a value for bs that is smaller than the size of the file, it pads the file to the next boundary matching the size. For example. If you put bs=64K, it would make the final rom a multiple of 64K long - so if the temp.bin was 90K, the final file would be 128K.

But yes, that's another reason files might not work on real hardware - they don't load completely on the flash cart for some reason, like not padded to an expected boundary.
TmEE co.(TM)
Very interested
Posts: 2452
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) »

I am really not seeing why ROM has to be padded... you do an erase in the flash and you write only the data that is relevant and leave rest untouched. I've been doing it for years and never have problems.
Do the menu programs in flashcarts not erase the last fraction or something ?
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
Chilly Willy
Very interested
Posts: 2993
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy »

TmEE co.(TM) wrote:I am really not seeing why ROM has to be padded... you do an erase in the flash and you write only the data that is relevant and leave rest untouched. I've been doing it for years and never have problems.
Do the menu programs in flashcarts not erase the last fraction or something ?
The menus don't write flash - you write flash over USB from a PC using the PC client software. However, the NeoFlash PC Client software sucks ass. My guess is when a file doesn't meet certain padding constraints, it puts it on the wrong boundary in the flash, or doesn't write the whole file to flash, or any number of other crazy things. Dr.neo needs to open the latest version of that so others can fix it, like with the menus. That's why folks need to get a Neo2-SD or Neo2-Pro - so they can run stuff from SD instead of from flash.

I've thought of making the menus write flash for the Neo2-SD and Neo2-Pro so that people can burn flash from SD and avoid the PC client, but I've never done any flash code and have yet to make any progress in the MD Menu on it. Maybe you can help on that.
TmEE co.(TM)
Very interested
Posts: 2452
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) »

Flashes usually have very standard commands and responses, there should not be much problems. Datasheets even provide complete alogs to write/erase/verify etc. the data. Only thing you got to worry about is someone unplugging the AC brick during erase. Chances are that whole chip gets messed up.
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
Chilly Willy
Very interested
Posts: 2993
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy »

TmEE co.(TM) wrote:Flashes usually have very standard commands and responses, there should not be much problems. Datasheets even provide complete alogs to write/erase/verify etc. the data. Only thing you got to worry about is someone unplugging the AC brick during erase. Chances are that whole chip gets messed up.
At which point the user could reburn the menu with the PC client - that at least works for everybody. It's only burning the game flash that fails or is problematic. So worst case is they have to do something that isn't a problem.

This would only be dealing with the Neo2-SD and Neo2-Pro since they're the only things with both game flash and an SD interface. The Neo3-SD has the SD interface, but no game flash, so you'd never be burning games to flash.

Towards that end, the GBA menu DOES have the ability to write the menu flash - it stores game saves in the menu flash. From the GBA menu code, there appear to be two kinds of menu flash used. I have no idea what game flash is used on the Neo2-SD and Pro. Is there a "standard" way to ID flash? I could work that into the menu to show the man/id of the menu and game flash chips.
superjoebob
Very interested
Posts: 66
Joined: Fri Oct 15, 2010 7:06 am
Location: Vancouver, Canada
Contact:

Post by superjoebob »

Small world eh? :lol:
On a never ending quest to compose for the Genesis/Megadrive
mic_
Very interested
Posts: 265
Joined: Tue Aug 12, 2008 12:26 pm
Location: Sweden
Contact:

Post by mic_ »

I have no idea what game flash is used on the Neo2-SD and Pro. Is there a "standard" way to ID flash?
What about madmonkey's open source programmer ?
Chilly Willy
Very interested
Posts: 2993
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy »

mic_ wrote:
I have no idea what game flash is used on the Neo2-SD and Pro. Is there a "standard" way to ID flash?
What about madmonkey's open source programmer ?
That has none of that info. It has USB command sequences that no one understands because that level of info isn't available to us. I'm sure it's some kind of combination of ASIC and flash commands, but right now, they're simply done because "that's what you do". Maybe if I learn enough about the flash via the menu, I'll figure out what the USB side is doing and can fix that as well.
mic_
Very interested
Posts: 265
Joined: Tue Aug 12, 2008 12:26 pm
Location: Sweden
Contact:

Post by mic_ »

My Neo2-SD (non-Pro) has one chip from ST. I can't quite make out the part number, but it could be M36DR432A (which would be a 32 Mbit flash + 4 Mbit SRAM chip).
Then there are two chips labeled 4050L0YTQ2, which according to google are flash memories made for mobile phones (by Intel?). Dunno what their sizes are.

The Neo2 Pros aren't translucent so I have no idea what they contain.
Chilly Willy
Very interested
Posts: 2993
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy »

mic_ wrote:My Neo2-SD (non-Pro) has one chip from ST. I can't quite make out the part number, but it could be M36DR432A (which would be a 32 Mbit flash + 4 Mbit SRAM chip).
Then there are two chips labeled 4050L0YTQ2, which according to google are flash memories made for mobile phones (by Intel?). Dunno what their sizes are.

The Neo2 Pros aren't translucent so I have no idea what they contain.
Thanks, I have a translucent Pro, so I can check what's on it.

I looked again at the old PC client software I have, and the SlimLoader IV looks pretty simple: you do bulk transfers to cart to do read/write operations. The first byte is a command, and is followed by a variable amount of argument bytes.

Command:
b3 = 0=discard read data, 1=return read data
b2 = clear internal return buffer? Not sure about this bit.
b1 = 0=GAME ROM BUS, 1=SAVE RAM BUS
b0 = 0=READ, 1=WRITE to GBA cart

READ GAME BUS outputs the next three bytes onto the game rom bus, and does a read operation. You set b3 of the command to return the read data in a bulk USB transfer in after the command bulk transfer out is done. If you don't set b3, the data read from the cart is ignored. I'm not completely sure what b2 does, but it's normally set for the first read that returns data, and clear for all other reads, so I'm guessing it clears the buffer used for holding the data read until the bulk input transfer. You get two bytes for each read operation since the GAME BUS is a word bus.

WRITE GAME BUS outputs the next three bytes on the game rom bus, and the next two bytes after than on the data bus. Again, b2 is normally set for the first write, and clear for all remaining writes.

READ SRAM BUS outputs the next two bytes on the save ram bus. The save ram bus is only 16 bits, and reads/writes a byte, so if you set b3, a single byte is returned for each read operation.

WRITE SRAM BUS outputs the next two bytes on the save ram bus, and the next byte on the data bus.

And that appears to be all there is. Those four operations allow you to do everything on the GBA cart. In fact, doing the proper operations on the game bus would allow you to read SD cards through the SLIV just like on the console. It wouldn't be remotely as fast as using a dedicated card reader, but it would work.

Note that this is all geared towards the GBA cart... I'm not sure how it would handle the extra stuff in the N64 cart - you can also read/write the U2 menu flash in the N64 cart via the usb, but it's not part of the GBA bus. My guess is the U2 menu flash sits on the GBA bus behind the N64 Myth CPLD and looks for some kind of setting that is not normally used on the GBA cart that it then decodes for the U2 flash.
Post Reply