32 records of 9 bytes, each a place where a charm lies. In the game as loaded only bytes 1 to 4 are filled: x, y, z and room number. init_special_objects fills in the rest when a game starts. Byte 0 becomes the charm's type, $60 to $67, taken in turn, so the eight kinds go round the table in a fixed order and each lies in exactly four places; only the starting kind varies, from the seed at $5BA0 plus the refresh register. Bytes 5 to 8 get a copy of bytes 1 to 4, and from then on they, not 1 to 4, say where the charm is now: x, y, z and room.

On entering a room, find_special_objs_here makes an object record, from $5C48 upwards, for every entry whose type is not 0 and whose byte 8 is this room. It gives the object a size of 5 by 5 by 12 and flags $14, and stores the address of the entry itself at +16 and +17 of the record, so the object can find its entry again. On leaving, update_special_objs writes the object's type and position back into bytes 0 and 5 to 8, which is how a charm that has been carried and dropped stays where it was put. Picking a charm up, feeding it to the cauldron or losing it writes 0 to byte 0, which takes that entry out of the game (pickup_object, add_obj_to_cauldron, upd_185_187).

This table only says where the charms lie. Which of them the wizard wants, and in what order, is the separate list at objects_required, which shuffle_objects_required rotates at the start of a game.

No room holds more than one entry, so the two object slots from $5C48 to $5C87 are always enough. The 32 rooms are all different, and all exist in location_tbl.