Forums

The following can be found within the Sonic Spinball (SMS) ROM:

88
1C58 C5 M PUSH BC
1C59 21 00 00 M ld HL,RobotnicShipAnim
1C5C M XREF CreateState
1C5C CD 00 00 M CALL CreateState
1C5F D1 M POP DE
1C60 38 00 M JR C,AppendRightError_1988
1C62 21 4B D7 M ld HL,StateRight
1C65 19 M add HL,DE
1C66 71 M ld (HL),C
1C67 M AppendRightError_1988
1C67    _YSpeed 3
1C67 FD 36 28 06 M ld (IY+ItemYSpeedHi),lo(3*SpdFac)
1C6B FD 36 27 00 M ld (IY+ItemYSpeedLo),0
1C6F

1C6F    _Goto EndItemsCheck
1C6F 18 00 M JR EndItemsCheck
1C71

1C71 ;=== Re Entry (into the volcano) ===
1C71 Reentry:
1C71    _AppendRight ReentryAnim
1C71 M XREF AppendRight
1C71 CD 00 00 M CALL AppendRight
1C74 M bcs AppendRightError_1992
1C74 38 00 M jr C,AppendRightError_1992
1C76 C5 M PUSH BC
1C77 21 00 00 M ld HL,ReentryAnim
1C7A M XREF CreateState
1C7A CD 00 00 M CALL CreateState
1C7D D1 M POP DE
1C7E 38 00 M JR C,AppendRightError_1992
1C80 21 4B D7 M ld HL,StateRight
1C83 19 M add HL,DE
1C84 71 M ld (HL),C
1C85 M AppendRightError_1992
1C85    _YSpeed 3
1C85 FD 36 28 06 M ld (IY+ItemYSpeedHi),lo(3*SpdFac)
1C89 FD 36 27 00 M ld (IY+ItemYSpeedLo),0
1C8D

1C8D EndItemsCheck:
1C8D FD 7E 05       ld A,(IY+ItemYHi)    ;Check if hit stop point
1C90 FD BE 31    cp (IY+ItemParm0)
1C93    bne EndItemsNext
1C93 20 00 M jr NZ,EndItemsNext
1C95

1C95 FD 7E 04       ld A,(IY+ItemYLo)
1C98

This code looks very unusual, in particular due to:

* The presence of addresses and opcode bytes on the far left.
* The XREF, _Goto and bcs "instructions". These are clearly related to the calls and jumps - all of which appear to have immediate data of zero.

Does anyone know what this code might be? A disassembly? Output from a high-level compiler?

P.S. It seems that this code corresponds to the part of the binary at $15e55-$15e94.

Quote

* The presence of addresses and opcode bytes on the far left.

Very cool find. This is a listing file which the assembler produces, that contains the absolute addresses and the byte sequences for each instruction. I don't know which Z80 assembler exactly, however.

I wonder if the M prefixes code that is part of a macro, to indicate macro expansion. Typically listing files don't show expanded macros unless you direct the assembler to do so.

Something similar turned up in an NES game called Air Fortress.
The only speculation I've heard is that maybe instead of filling unused ROM space with zeros or FF, it just grabbed random data from the programmer's hard drive/RAM.
Though it's a bit odd as the text is at $1F600 and doesn't go until the end of the bank.

The Sonic 2 "beta" ROM has some chunks of source code in it too.

Basically if you enlarge a file by just setting the pointer to your desired point then all the space from the end of your file to the pointer get filled with whatever there was before on your HDD and if a program does not overwrite it with zeroes you got stuff like that.

I hear that whole source code of some games are found that way :O

Can you add it to a Development page for the game? I've done that for a few different games, e.g. this recently:

http://www.smspower.org/Development/ManOverboard-GG

...including comments with mild profanity.

The M stuff does look a lot like macro expansion, with the unexpected "opcodes" being the macros themselves. XREF and bcs seem a bit like someone trying to overlay a different mnemonic system onto the Z80 standard set...

The inclusion is more likely due to memory managers not blanking RAM than due to file expansion.

Maxim wrote

Can you add it to a Development page for the game?

Sure. I was planning to do that soon (I added a similar page for Hang On / Safari Hunt just recently), but I didn't know exactly how to describe the code. Unlike other examples, this is clearly not hand-written assembly.

Charles MacDonald wrote

This is a listing file which the assembler produces, that contains the absolute addresses and the byte sequences for each instruction.

I see. That makes sense.

Maxim wrote

The M stuff does look a lot like macro expansion, with the unexpected "opcodes" being the macros themselves.

So, for example, _AppendRight is a macro which expands to give several lines - the first of which is "XREF AppendRight"? Then this nested macro expands to "CALL AppendRight"?

That seems believable. You can't see the level of the macro "stack" but any line with no bytes recorded seems to be a macro.

Author	Message
RetroSpark Joined: 08 Dec 2005 Posts: 488 Location: Melbourne, Australia	Sonic Spinball: Unusual Source Code in ROM Posted: Fri Jun 17, 2011 12:10 am
	The following can be found within the Sonic Spinball (SMS) ROM: 88 1C58 C5 M PUSH BC 1C59 21 00 00 M ld HL,RobotnicShipAnim 1C5C M XREF CreateState 1C5C CD 00 00 M CALL CreateState 1C5F D1 M POP DE 1C60 38 00 M JR C,AppendRightError_1988 1C62 21 4B D7 M ld HL,StateRight 1C65 19 M add HL,DE 1C66 71 M ld (HL),C 1C67 M AppendRightError_1988 1C67 _YSpeed 3 1C67 FD 36 28 06 M ld (IY+ItemYSpeedHi),lo(3SpdFac) 1C6B FD 36 27 00 M ld (IY+ItemYSpeedLo),0 1C6F 1C6F _Goto EndItemsCheck 1C6F 18 00 M JR EndItemsCheck 1C71 1C71 ;=== Re Entry (into the volcano) === 1C71 Reentry: 1C71 _AppendRight ReentryAnim 1C71 M XREF AppendRight 1C71 CD 00 00 M CALL AppendRight 1C74 M bcs AppendRightError_1992 1C74 38 00 M jr C,AppendRightError_1992 1C76 C5 M PUSH BC 1C77 21 00 00 M ld HL,ReentryAnim 1C7A M XREF CreateState 1C7A CD 00 00 M CALL CreateState 1C7D D1 M POP DE 1C7E 38 00 M JR C,AppendRightError_1992 1C80 21 4B D7 M ld HL,StateRight 1C83 19 M add HL,DE 1C84 71 M ld (HL),C 1C85 M AppendRightError_1992 1C85 _YSpeed 3 1C85 FD 36 28 06 M ld (IY+ItemYSpeedHi),lo(3SpdFac) 1C89 FD 36 27 00 M ld (IY+ItemYSpeedLo),0 1C8D 1C8D EndItemsCheck: 1C8D FD 7E 05 ld A,(IY+ItemYHi) ;Check if hit stop point 1C90 FD BE 31 cp (IY+ItemParm0) 1C93 bne EndItemsNext 1C93 20 00 M jr NZ,EndItemsNext 1C95 1C95 FD 7E 04 ld A,(IY+ItemYLo) 1C98 This code looks very unusual, in particular due to: * The presence of addresses and opcode bytes on the far left. * The XREF, _Goto and bcs "instructions". These are clearly related to the calls and jumps - all of which appear to have immediate data of zero. Does anyone know what this code might be? A disassembly? Output from a high-level compiler? P.S. It seems that this code corresponds to the part of the binary at $15e55-$15e94.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Fri Jun 17, 2011 3:01 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote * The presence of addresses and opcode bytes on the far left. Very cool find. This is a listing file which the assembler produces, that contains the absolute addresses and the byte sequences for each instruction. I don't know which Z80 assembler exactly, however. I wonder if the M prefixes code that is part of a macro, to indicate macro expansion. Typically listing files don't show expanded macros unless you direct the assembler to do so.

KingMike Joined: 14 Oct 2008 Posts: 511	Posted: Fri Jun 17, 2011 5:14 am
KingMike Joined: 14 Oct 2008 Posts: 511	Something similar turned up in an NES game called Air Fortress. The only speculation I've heard is that maybe instead of filling unused ROM space with zeros or FF, it just grabbed random data from the programmer's hard drive/RAM. Though it's a bit odd as the text is at $1F600 and doesn't go until the end of the bank.

TmEE Joined: 31 Oct 2007 Posts: 853 Location: Estonia, Rapla city	Posted: Fri Jun 17, 2011 7:59 am
	The Sonic 2 "beta" ROM has some chunks of source code in it too. Basically if you enlarge a file by just setting the pointer to your desired point then all the space from the end of your file to the pointer get filled with whatever there was before on your HDD and if a program does not overwrite it with zeroes you got stuff like that. I hear that whole source code of some games are found that way :O

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Fri Jun 17, 2011 8:17 am
	Can you add it to a Development page for the game? I've done that for a few different games, e.g. this recently: http://www.smspower.org/Development/ManOverboard-GG ...including comments with mild profanity. The M stuff does look a lot like macro expansion, with the unexpected "opcodes" being the macros themselves. XREF and bcs seem a bit like someone trying to overlay a different mnemonic system onto the Z80 standard set... The inclusion is more likely due to memory managers not blanking RAM than due to file expansion.

RetroSpark Joined: 08 Dec 2005 Posts: 488 Location: Melbourne, Australia	Posted: Fri Jun 17, 2011 11:49 am
	Maxim wrote Can you add it to a Development page for the game? Sure. I was planning to do that soon (I added a similar page for Hang On / Safari Hunt just recently), but I didn't know exactly how to describe the code. Unlike other examples, this is clearly not hand-written assembly. Charles MacDonald wrote This is a listing file which the assembler produces, that contains the absolute addresses and the byte sequences for each instruction. I see. That makes sense. Maxim wrote The M stuff does look a lot like macro expansion, with the unexpected "opcodes" being the macros themselves. So, for example, _AppendRight is a macro which expands to give several lines - the first of which is "XREF AppendRight"? Then this nested macro expands to "CALL AppendRight"?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Fri Jun 17, 2011 12:48 pm
	That seems believable. You can't see the level of the macro "stack" but any line with no bytes recorded seems to be a macro.

Forums

View topic - Sonic Spinball: Unusual Source Code in ROM