The 5488 bytes LOAD_INITIAL_STATE copies to $EA90 -- which is to say the whole of the runtime area, $EA90 to the top of memory, written out in full and moved into place with one LDIR. Nothing is built at run time; the castle is simply copied.

It is laid out exactly as the running game reads it, in the four regions MAIN_LOOP and FRAME_TICK walk. The bytes below are grouped one record to a line.

What is in it, read out of the data: three empty records for the player, the weapon and the sound slot, which are filled in when a game starts rather than here; 115 objects of the 119 slots, among them sixteen mushrooms, ten each of the eight kinds of food, and, last of them, the drop controller (sprite $31) that runs PUT_DOWN; five monsters, one each of the mummy, Dracula, the devil, Frankenstein's monster and the humpback; and 274 sixteen-byte records for the doors and the furniture.

The doors are the surprise. Every one is sixteen bytes, not eight -- one record holding both of its sides -- which is why DOOR_OTHER_SIDE flips bit 3 of an address: it is moving between the two halves of a single record. The last region is 274 of these sixteen-byte records: 205 doors, and 69 pairs of pieces of furniture, one in each of two rooms, stored the same way though nothing ever crosses between them -- 36 of the pairs are not even the same piece. A record's type byte says which (see DOOR_KINDS in build_aticatac.py): its handler, found by DISPATCH_FROM_LIST, is a door routine for a door and DRAW_DOOR, the draw-only tail of DOOR, for furniture. Each room's list names the records that are in it; the objects and monsters it names nowhere, finding them by their own room byte.