Skip to content

03-executable.md

Latest commit

 

History

History
147 lines (112 loc) · 5.43 KB

03-executable.md

File metadata and controls

147 lines (112 loc) · 5.43 KB
Raw

03 — /cdi_origami

82,720 bytes in the root of the disc, named directly by the volume descriptor's application identifier. CD-i runs CD-RTOS, Philips' OS-9 2.4 derivative, so this is not a flat binary but a concatenation of four relocatable OS-9/68000 modules, packed end to end with no padding at all:

python tools/os9mod.py _work/files/cdi_origami
offset name type size purpose
0x000000 origami Prgrm 76,840 the application
0x012C28 cdi_bpsys Sbrtn 3,608 Philips base program system
0x013A40 cdi_vsync Prgrm 1,048 vertical-sync helper
0x013E58 cdi_vsync_trap Trap 1,224 its trap handler

76,840 + 3,608 + 1,048 + 1,224 = 82,720. Exactly the file size.

Validation

Every module starts with the $4AFC sync word and is self-checking twice over: M$Parity at offset 46 is the complement of the XOR of the 24 header words, and a 24-bit CRC (poly $800063, preset $FFFFFF) over the whole module including the stored CRC must come out at $800FE3.

module parity CRC-24
origami 0x1D30 OK 0xA311E6 OK
cdi_bpsys 0x1244 OK 0x81BF47 OK
cdi_vsync 0x3500 OK 0x556164 OK
cdi_vsync_trap 0x1B3E OK 0x0AC41F OK

All four pass. The binary has not been modified since it was linked.

Header layout

Worth stating because the classic OS-9 documentation will mislead you twice here. M$Name is a four-byte offset at byte 12, not two; and the names are NUL-terminated, not high-bit-terminated as OS-9/6809 documents describe.

0   $4AFC sync            18  type   1=Prgrm 2=Sbrtn 3=Multi 4=Data $B=Trap
2   M$SysRev              19  lang   1 = 68000 object
4   M$Size (4)            20  attr   bit7 re-entrant, bit5 sticky
8   M$Owner (4)           21  revision
12  M$Name  (4)           46  M$Parity
16  M$Accs  (2)
48  M$Exec  52 M$Excpt  56 M$Mem  60 M$Stack  64 M$IData  68 M$IRefs

For origami, M$Name = 0x48, and the string at that offset is origami\0-F\0 — the module name followed by the linker option string that built it. cdi_vsync carries the same -F.

The main module asks for 16,670 bytes of static storage and a 3,072-byte stack, and enters at 0x50 with an exception vector at 0x1BA. That is the whole memory footprint of a program that drives 739 MB of content.

Nine names that are not in the credits

At offset 0x48 inside cdi_bpsys — before any code, in the space right after the header — sits a comma-separated list:

M.Armendariz,L.Barnes,W.Hunt,J.Kesselman,S.McClellan,R.Moore,T.Nutt,J.Piesing,J.Rotter

These are not the people in /bibliographic. cdi_bpsys is the CD-i base program system, the Philips/OptImage support library that every CD-i title links against, and this is its author list travelling inside the shipped binary of an unrelated Dutch origami disc. J. Piesing is Jon Piesing, a Philips CD-i engineer whose name is attached to a good deal of the platform's specification work.

If you are documenting another CD-i title, look for this string. It should be in every disc that links the same library revision, and comparing the lists across titles would date the library.

What the strings say the program does

python tools/cdistrings.py

Seventy-five readable runs. The interesting ones cluster in two places.

The image subsystem, at 0x2AF7–0x2B87 — allocation tags, which is how we know what the renderer supports:

ClutData        AnimData        mymem           image memory
Dyuv Pic Descr. Clut Pic Descr. RunL Pic Descr.
Dyuv line ptr table             Clut line ptr table
RunL line ptr table

Three picture types — DYUV, CLUT and run-length — each with a picture descriptor and a line-pointer table. Only the first two are actually used by any file on the disc; see 05-video.md.

The path builder, at 0x2BD6–0x2C24. The disc paths are not stored whole. Apart from the three /MISC files, which are literals, every model path is assembled at run time from four pieces:

/MISC/origami_pictures.rtf
BASIS  IEDEREEN  DOEMEER  FELICI
SwapA  SwapB
/      /      .rtf

so "/" + "BASIS" + "/" + "bergen" + ".rtf".

Errors. Only two, both from the runtime rather than the game:

**** Stack Overflow ****
**** Can't install trap handler ****
E_bp_allocate(): not enough memory for "%s"

The model table

At 0x4762, 37 NUL-terminated names in one block, in this order:

sterbloem poppetje bergen dolly pup boom kasteel toren boerderij dubhuis onderztr
pinguin hartje doosjemd paard hoed hond servetring ster hemdje kerstman samoerai
rammelaar model2 bal versiering kaart model3 laars baby
beer clown houder kerstster abloem pauw huis

The line breaks above are not arbitrary. The table splits 11 / 11 / 8 / 7, which is exactly the file count of BASIS, IEDEREEN, DOEMEER and FELICI. The table is the menu, in menu order, and the directory a model belongs to is implied by its index rather than stored.

Every one of the 37 names resolves to a file, and every real-time file on the disc is named by the table. There are no dangling references in either direction — which is unusual, and worth stating precisely because the sibling Ultra CD-i Soccer pipeline found eight.

Two of the names are placeholders that shipped: model2 and model3, in DOEMEER, with no model1 anywhere. See 08-leftovers.md.