asmx and padding?

8bitwizard · Post by **8bitwizard** » Sun Sep 23, 2007 5:11 pm

Stef wrote:The genesis hardware need a 128 KB size alignment or your rom won't work correctly. You said objcopy do padding, can it does size alignement which is somewhat different from padding (padding just fill until you reach the pad size where alignement fill until size align).

Maybe some emulator or game copier or flash loader wants a size alignment, but there is no such thing in real hardware. An EPROM programmer will not make half of a chip disappear simply because your binary file was a bit short.

I use ucon64 to convert the binary for my mgh game copier, and that handles all the padding and interleave needed for its file format.

My cartridge board is designed to take 27512 and larger EPROMs, but it probably needs rewiring for 2764/27128/27256. With a little bit of razor cutting and rewiring, I could probably make a 16K cartridge using a pair of 2764 chips, but it's not really worth the effort for me to make anything smaller than 128K (2x27512). Actually it hasn't even been worth the effort to make anything smaller than 256K, since I don't want to go changing the 28/32 pin jumpers all the time.

cdoty · Post by **cdoty** » Sun Sep 23, 2007 5:14 pm

TmEE co.(TM) wrote:My software doesn't pad anything, since erased (flash)EPROM already has FF in unused places...

The padding could still be required, your eprom would be performing the 'padding'.

What in the Genesis would require the padding? The checksum is software only. And would be affected by the padding only if the flash cartridge doesn't erase to 0xFF.

8bitwizard · Post by **8bitwizard** » Sun Sep 23, 2007 5:20 pm

cdoty wrote:
TmEE co.(TM) wrote:My software doesn't pad anything, since erased (flash)EPROM already has FF in unused places...
The padding could still be required, your eprom would be performing the 'padding'.

What in the Genesis would require the padding? The checksum is software only. And would be affected by the padding only if the flash cartridge doesn't erase to 0xFF.

And even then, there's an end address in the header that tells it exactly where to stop computing the checksum. There is no requirement that your checksum end exactly at the end of your ROM chip. (Of course there is actually no requirement that you have a checksum at all, or that you use Sega's "official" algorithm.)

The only thing that absolutely has to be in the header is 1) the reset/initial SP vectors, 2) the interrupt vectors if you want to use Hsync/Vsync/etc., 3) "SEGA" at 0x100. Everything else from 0x104 to 0x1FF is just documentation for Sega and ROM organizers and emulators. If your game wants to use that data, it can, otherwise it never gets used.