{
 "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."
   ]
  }
 }
}