Record 7; the room's objects follow from RECORDS. Twenty bytes, the layout of every object record. The fields this part of the code reads: +0 and +1, where the sprite is on the screen (x, and y of its top row, counted up from the bottom of the screen); +2 and +3, its width in pixels and height in rows; +4 and +5, the sprite (image, then mask); +6 to +8, where the object is in the room, +6 and +8 along the floor and +7 the height of its top (ISO_MOVE turns a change in them into a change of +0 and +1); +9 to +11, its size along each; +12, its kind in the low nibble and flags above it; +19, its number in the object table (0 for the knight, who is not in it).

The listing names the fields wherever IX holds a record's address: OBJ_SCREEN_X (+0), OBJ_SCREEN_Y (+1), OBJ_WIDTH (+2), OBJ_ROWS (+3), OBJ_SPRITE (+4, a word), OBJ_X (+6), OBJ_TOP (+7), OBJ_Z (+8), OBJ_LEN_X (+9), OBJ_HEIGHT (+10), OBJ_LEN_Z (+11), OBJ_KIND (+12), OBJ_DIRECTION (+13), OBJ_STATE (+14), OBJ_COUNT (+15), OBJ_WEIGHT (+16), OBJ_FRAME (+17), OBJ_COURSE (+18) and OBJ_NUMBER (+19); OBJ_SIZE is the record's twenty bytes. They are EQUs at the top of the source file. A door's record uses the same bytes for its own things -- +13 the room behind it, +14 the key, +15, +16 and +18 where the knight arrives, +17 the way through -- and the routines that read a door say so.

On the tape this is his record at the start of a game. START copies it to the master copy (MASTER_OBJECTS), and TITLE_SCREEN copies it back at every new game and whenever he is carried off to another room, all but +14: bit 5 of +14 says which way his sprite images face, and MIMAN turns the images themselves round in memory when he turns, so the record must go on saying which way they face now.