modemwars/annotations/30_corrections.json
2026-08-23 02:09:40 -05:00

62 lines
4 KiB
JSON

{
"chunk": "corrections",
"unit": "game/highMemoryFBB8",
"notes": {
"FD70": {
"unit": "game/highMemoryFBB8",
"block": [
"radarDroneShapesRle - 180 bytes, $FD70-$FE23: an RLE-compressed set of eight 24x21 sprite",
"shapes whose first byte ($01) is the escape marker. runMissileScreen ($7587, comcen screens",
"overlay) points A/Y at it with LDA #$70 / LDY #$FD ($7592-$7594) and calls unpackRleTo0200",
"($67CB) at $7596; the unpacker always writes exactly 512 bytes to $0200-$03FF, so the block",
"becomes eight shapes on a 64-byte stride (63 sprite bytes plus one spare byte each).",
"loadDirectionShapeSprite ($3340) copies $0200 + 64*shape into sprite 0 ($8A00) or sprite 5",
"($8B40); on this screen the caller is cmdDroneMove at $5322, which passes (heading + 4) AND 7 -",
"the heading turned 180 degrees, because a received command's coordinates are mirrored - to draw",
"the opponent's drone blip. Decoded, the eight shapes are a small top-down aircraft glyph in the",
"middle byte of sprite rows 7-13 (north = $08,$1C,$7F,$08,$08,$08,$1C), in compass order",
"N, NE, E, SE, S, SW, W, NW.",
"Correction: the first survey pass labelled this arrowGlyphTable, read the escape/count/value",
"triples as '2-byte record headers' and stated that 'no static reference to this table exists",
"anywhere in the disassembly ... it may be unused leftover data'. That is wrong: the block is",
"live data, decompressed every time the missile/radar screen is entered. No reference appears in",
"XREF.txt only because the address reaches the unpacker as two immediate operands in A/Y, never as",
"an absolute operand."
]
},
"FE24": {
"unit": "game/highMemoryFBB8",
"block": [
"droneScreenShapesRle - 367 bytes, $FE24-$FF92: the second RLE stream, escape marker $05.",
"enterDroneScreen ($7FE6, comcen screens overlay) loads A/Y with LDA #$24 / LDY #$FE",
"($7FEC-$7FEE) and calls unpackRleTo0200 ($67CB) at $7FF0, which again expands it to exactly 512",
"bytes at $0200-$03FF = eight shapes on a 64-byte stride. The drone screen copies one of them",
"into sprite 5 through loadDirectionShapeSprite ($802A when the screen is reset, $810B at launch,",
"$829E on every camera step) as the heading indicator; the shapes are the big top-down drone",
"silhouettes in the same compass order N, NE, E, SE, S, SW, W, NW.",
"Correction: the survey pass called this aircraftShapeTable, started it three bytes early at",
"$FE21 (those three bytes are the last run of the $FD70 stream, not a header), described the",
"$05,$xx run tokens as record headers and judged it 'probably stale data' that 'nothing",
"references'. All of that is wrong - see the note at $FD70 for why the reference does not show up",
"in XREF.txt."
]
},
"FF90": {
"unit": "game/highMemoryFBB8",
"block": [
"$FF90-$FF92 is not a block of its own. It is the last token of the compressed stream that starts",
"at $FE24: escape marker $05, count $0E, value $00 - the 14 zero bytes that pad the eighth shape",
"out to its 64-byte slot and bring the unpacker's output to exactly 512 bytes. Decoding the",
"stream byte by byte confirms it: the run that begins here is consumed at $FF92, and the very next",
"byte, $FF93, is the first byte of droneViewfinderSprite, the 63-byte uncompressed reticle that",
"launchDrone copies into sprite 2 at $80EB. So nothing at the top of this block is spare:",
"$FD70-$FFD1 is two compressed sprite sets and one raw sprite, back to back, ending exactly at",
"$FFD1 just below the CPU vectors.",
"Correction: the survey pass labelled $FF90 unknownShapeTail, gave it 66 bytes and called it 'most",
"likely unused leftover memory ... stale bytes that resemble the end of the $8800 message block'.",
"It is neither unused nor related to $8800 - that block's tail ($897F-$89FF) is an unrelated",
"$00/$FF dither pattern and does not match these bytes."
]
}
}
}