This repository holds a commented disassembly of Super Cobra for the MSX (Konami, 1983, cartridge RC-705). Everything here comes out of the binary and can be regenerated from it.
The ROM goes in the root, as supercobra.rom. Exactly 8192 bytes:
sha256 062aeefd04e6ac28f565c15bd1010fc2a007bfbe8d3898ff8586778462091470make comprueba checks it.
make # trace, listing, reassembly, checks and tests
make listado # rebuilds src/supercobra.asm from the annotations
make verify # reassembles and compares with the ROM, byte for byte
make sanity # nothing declared as data may come out as code,
# and no byte may be left unassigned
make test # the checks
make imagenes # rebuilds the drawings by reading the ROM
make web # rebuilds this sitesrc/supercobra.entries | the entry points, each with its justification |
src/supercobra.nocode | the ranges the tracer must not read as code |
src/supercobra.notes | the only file edited by hand: all the annotations |
src/supercobra.asm | the listing, generated by tools/mkasm.py |
tools/ | the tracer, the listing generator and the measuring tools |
tests/ | the checks on the listing and the annotations |
docs/ | this site |
Annotations are anchored to an address, so they survive a retrace. The directives follow theNestruo's guidelines:
L | a label and what the routine does |
C | a comment on that line |
B | a block header before that address |
D | a data range, with its name and its explanation |
F | the row width of a data block |
The tracer follows the real flow from the entry points. What cannot be deduced statically —the interrupt hook, the two tables embedded behind a call— is declared by hand in the .entries, with the reason written next to it.
This cartridge also has two routines that are never reached by a call: 0x4691 does a push hl with the address of one of them, and the dispatcher ends in jp (hl), so the ret of the state routine lands there. Without that, 0x488B and 0x49EA stayed declared as data while being code.
There is no assumption dressed up as a fact here. What is not known is in Open questions, and it says so.
make verify reassembles the listing and compares the result with the original ROM. It has to come out identical, byte for byte. And make sanity then checks what reassembly cannot catch: that no range declared as data is being read as code, and that not a single one of the 8192 bytes is left unassigned.