Skip to content

Latest commit

 

History

History
143 lines (110 loc) · 6.9 KB

File metadata and controls

143 lines (110 loc) · 6.9 KB

12 - Open questions

Everything here is unresolved, with the measurement that motivates it. None of it is speculation dressed up as fact; where a reading is likely it is labelled as a reading.

1. The geometry of GSBlk

3.5 MB of the disc -- a third of everything -- is eleven GSBlk files, and no rendering of them yet produces a picture.

What is known: they are not compressed (zlib on the unpacked file gives 0.09 to 0.50, entropy 1.66 to 4.96, both the profile of raw planar art); levels share large runs (L1 and L2 agree on 110,882 of 319,488 bytes); occupancy runs from 73.9 % to 95.2 % of the fixed buffer.

What was tried and failed: 16 x 16 and 32 x 32 blocks at 4 and 5 bitplanes, interleaved and plane-separated, with and without a leading mask plane, from offset 0 and from a range of offsets. All render as noise with visible structure on 16-pixel boundaries.

What is missing is almost certainly an index. SprDR is a directory of pointers (09-level-data.md) and its table 2 records carry two 32-bit file pointers each; those may index into GSBlk and give per-block offsets and sizes that are not a fixed stride. The next step is to follow SprDR's pointers rather than to guess a stride.

2. Where the level palettes are

Lx_ChipI has copper MOVE COLORxx lists for the loader's own screens. No other file does. The game's own palettes must be plain 16- or 32-word arrays somewhere in GSBlk or LLoad, and without them question 1 cannot be finished convincingly even if the geometry falls out.

3. The CHFI codec

Eight blocks in Lx_CompE.cru, header 'CHFI' <u32 unpacked> <u32 packed>, compressing 918,384 bytes down to 184,188. Block 0 unpacks to 92,160 bytes, which is exactly a 320 x 288 PAL frame at eight bitplanes; block 4 is 23,040, two planes of the same frame. The payload is high entropy and does not respond to RNC, LZSS or RLE probes.

CHFI is not a known Amiga format. It appears nowhere else on the disc. The decoder is inside Lx_CompE's own module or in Lx_ReloD, and finding it means disassembling 68000 rather than guessing.

4. What plays the in-game music

The disc has exactly one ProTracker module (endpart, in Lx_CompC) and one 118-second CD audio track. Scanning all 84 unpacked files for M.K., M!K!, FLT4, 6CHN and 8CHN finds nothing else.

So either the CD track is the whole soundtrack, or there is an in-house player whose data carries no magic word. Lx_ReloD unpacks to 262,144 bytes and is the obvious place to look; the per-level LLoad files are the other.

5. Why three files are dated 1992

Lx_DataL.exe (1992-08-14 18:28:07), Lx_ReloD.cru (18:26:17) and Lx_TPage.cru (18:26:56) carry real timestamps from a machine with a working clock, two years and four months before the disc was mastered, while every other file on the disc is stamped with the AmigaDOS epoch.

Those three files are also, exactly and only, the three that contain the marker CDIOEND.

Two readings, neither confirmed:

  • The three were copied from a directory that preserved their datestamps -- a stable "engine" directory on a hard disk -- while everything else was regenerated during the build. But Lx_TPage contains Dragonstone's own menus and its title screen, so the file cannot literally be from 1992.
  • The datestamps were inherited from templates or from an earlier project's files, and only the contents were replaced.

Core Design shipped CDTV work in that era, so a 1992 CD I/O module being carried forward is plausible -- but the timestamps belong to the files that contain it, not to the module inside them, and nothing on the disc distinguishes the two cases.

6. What freeanim.library is

c/FreeAnim is a SAS/C 6 program that opens dos.library, intuition.library and freeanim.library, which is not on the disc and must therefore be resident in Kickstart or in the CD32's extended ROM.

The name and the position in the startup sequence -- after Workbench has been suppressed, immediately before the game takes the machine -- point at reclaiming the memory held by the CD32's boot animation. That reading is not confirmed, and a search of the usual Amiga documentation did not turn up the library by name.

7. Whether German levels 2 and 5 displayed correctly

L2_Int_G and L5_Int_G encode ü, ä and ö as 0x8F, 0xA5 and 0x8C, where the other nine German files use the CP437 values 0x81, 0x84 and 0x94. ß is 0xE1 in all eleven.

If the game's font is a plain CP437 glyph table, a German player saw HolztÅr and HÑndler through the two biggest text files in the game. If the font carries duplicate umlaut glyphs at both sets of codes, nobody ever noticed. Answering it means finding the font -- probably in Lx_ReloD, which is what draws the verb bar -- and reading its glyph order.

8. Whether sector 21 is Core's accident or Commodore's

The 876 bytes after the trademark banner are a complete unlinked AmigaDOS object module named exec, defining Commodore's own message-port functions with debug symbols intact (11-leftovers.md).

This cannot be settled from one disc. If the same bytes appear on other CDTV and CD32 titles, the trademark block Commodore distributed to developers was itself built by concatenating the banner with a stale buffer, and the fragment has been pressed onto every disc of the format ever made. If they do not, it is specific to this master. Hashes for the comparison are in 11-leftovers.md and the check is the first open item of the shared CD32 platform notes.

9. What was in level 4

Nothing on the disc answers this. There is no orphaned art, no unreferenced text, no dead filename: the row in the loader's index table is blanked and that is the whole trace (11-leftovers.md). The Amiga floppy release is the only place left to look.

10. Smaller loose ends

  • The SprDR table-2 records end with 0x0480 0x0390 (1,152 and 912) in every record examined. A world size? A scroll limit? Unread.
  • The 60-byte object record has eight signed 16-bit pairs in the range -20..+32 that read like hot spots and bounding boxes, but the assignment of fields to meanings is a guess.
  • Lx_ChipI's copper list at 0x0234 writes COLOR16 through COLOR22 while BPLCON0 selects only four bitplanes. Something later switches to five or more planes, or those registers are being staged for sprites.
  • The DNLD header's third field marks the end of the initialised code and variables, but the modules address data well past it. What the loader does with the number is unread.
  • Lx_DataL.exe makes no library calls at all, which means it walks the ISO 9660 directory itself to find Lx_ChipI.cru and Lx_ReloD.cru. The directory-parsing code has not been disassembled, and it is the most interesting 53 KB on the disc for anyone documenting how CD32 titles reach their data without AmigaDOS.