|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
Random byte in SG-1000 ROMs
Posted: Mon Jul 25, 2011 12:11 pm Last edited by RetroSpark on Wed Aug 03, 2011 10:15 pm; edited 1 time in total |
I've noticed some SG-1000 ROMs have a seemingly random byte at the end - that is, after all of the game code and data, but before padding with $ff.
The byte is never accessed and changes significantly between versions of the same game. Some examples are: Champion Baseball 16k: $48 40k: $36
Congo Bongo v0: $c2 v1: $07 40k: $03 Pacar 16k: $21 40k: $30 Sega Flipper 16k: $4c 40k: $f1 Is this byte likely to have a meaning? If so, it's not obviously a checksum - what could it be? If not, is there a good reason to include a random byte in each build of a game? |
|
|
Posted: Mon Jul 25, 2011 1:13 pm |
It looks a lot like a checksum to me. However, I can't immediately see the algorithm. The SF-7000 IPL has a similar checksum but that has the advantage of (1) including the code for checking it and (2) just being a value such that the bytewise sum is zero. Being attached to the end of the data is a little odd too, almost as if its value is independent of the ffs that follow... | |
|
Posted: Mon Jul 25, 2011 2:30 pm |
I expected a checksum to work exactly as you describe for the SF-7000 IPL. If this is indeed a checksum, the algorithm must be fairly complex.
Consider "Sega Flipper". Label the two halves of the 16k version A and B, so that the ROM as a whole is A+B. Similarly, the 40k version can be described as C+C+C+C+D. Other than for this last byte, A+B and C+D differ in 171 bytes - these have all been increased by exactly $60. Either the checksum algorithm counts C four times (this seems unlikely to me), or somehow adding $60 to several bytes causes the checksum to differ by $a5 - an odd number. |
|
|
Posted: Mon Jul 25, 2011 3:18 pm |
How about if the checksum is per-ROM? I think your description means that still wouldn't matter...
It'd be trivial for there to be a shift and/or an XOR in the algorithm to increase the entropy, which also makes figuring it out a lot harder; but then. all the checksums I've come across in this world of Sega 8-bit have been simple addition. |
|
|
Posted: Tue Jul 26, 2011 12:18 am |
From a mapping point of view, the mapping for those is C C C C D D (spanning 48k of address space in total) |
|
|
Posted: Fri Mar 27, 2015 11:07 am |
Could it be just a bug in the assembler they used? Outputting an excess byte or forgetting to clear host memory by one byte? | |
|
Posted: Sun Apr 26, 2015 2:46 pm |
As explained here, "Basic Level II" is the same. The last byte of the ROM contains $38 in order that the 8-bit sum of all the bytes is zero.
Given that these values do not seem to result from simple addition, I think they are unlikely to relate to a checksum. Bock's suggestion of a bug in the assembler (or in a tool/method used to convert assembler output to a plain binary) seems to be the most likely explanation - especially due to the byte's position between the useful data and the blank space. Therefore, it is most likely that the byte has no meaning at all. |
|