Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Random byte in SG-1000 ROMs

Reply to topic
Author Message
  • Joined: 08 Dec 2005
  • Posts: 488
  • Location: Melbourne, Australia
Reply with quote
Random byte in SG-1000 ROMs
Post 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?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post 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...
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2005
  • Posts: 488
  • Location: Melbourne, Australia
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Tue Jul 26, 2011 12:18 am
Paul Baker wrote
the 40k version can be described as C+C+C+C+D


From a mapping point of view, the mapping for those is C C C C D D (spanning 48k of address space in total)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2005
  • Posts: 488
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Sun Apr 26, 2015 2:46 pm
Maxim wrote
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.

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.

Maxim wrote
All the checksums I've come across in this world of Sega 8-bit have been simple addition.
Maxim wrote
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...

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.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!