1990 · Domark

Castle Master

This minisite awaits a maintainer’s check. A model this site has not proven yet worked on it (one whose name was not recorded), so its claims have not been tested against the game (how the check works).

01 · The display

A castle inside a fixed frame

The ornate border stays around a small drawing window. The scene uses 120 horizontal pixel pairs and 120 rows. Its 3,600-byte working buffer is rearranged into the bitmap’s character-cell order when the image is copied to the screen.

Initialized display before menu drawing, reconstructed from the loaded bitmap and colours. The surrounding artwork is loaded once; the scene window is redrawn. $65EC transfers the scene; $C200 copies initial colours into hardware colour RAM.

02 · Stored geometry

Rooms are lists of objects

Each area has a small header followed by variable-length object records. The directory includes a global-object entry alongside the named locations. Select an area to inspect its stored geometry.

The diagram plots stored X/Z positions and extents for records with types other than zero. It shows data coordinates, without camera rotation, clipping or gameplay visibility. The database holds 34 area headers and 546 object records. $9D00, $9D4F, $76D0.

03 · Perspective

A zero-depth point can land in the corner

A point with zero depth can land at the centre or at the bottom-right corner, depending on which vertices came before it. Within one projection call, the first nonzero-depth vertex sends the loop past the centre shortcut. A later zero vector then lands at (119,119). Whether ordinary play reaches this case remains open.

For nonzero depth, the point’s horizontal offset is multiplied by sixty and divided by its depth, then added to the screen centre. Edge comparisons use sixteen-bit arithmetic, which wraps at signed extremes.

Choose a sequence to see how the earlier vertex changes the zero-depth result. $3C05, $3C12, $3D0F.

04 · Lettering

Four bytes hold a letter

Each character packs eight rows into four bytes. A nibble supplies four logical pixels; each becomes a pair of physical pixels. The renderer expands the packed letter into a temporary buffer before placing it in the bitmap.

The table contains 59 glyphs from space through Z. Each expanded row occupies two bytes. The first low-nibble row uses a distinct pixel-pair value. $231A, $857B, $8590.

05 · Instrument data

Instrument reads overlap

The sound driver takes ten bytes when it selects an instrument. The default offsets advance by nine. The last byte of one window therefore also begins the next.

FieldValue

The highlighted byte belongs to two adjacent instrument windows. Each voice selects its own group of eight offsets. $0F15, $CB58, $CB5C.

06 · Saving

A save records state and object flags

The save contains a block of player and game state, followed by one flags byte for every object. Geometry stays in the loaded database. The object records are visited in directory order.

The 652-byte payload has 106 state bytes and 546 object flags. Loading restores those state bytes and object flags. Geometry comes from the resident database. $04AE, $056C, $05D8.

Evidence and open behavior

The Source tab contains the annotated snapshot listing and checked facts. Complete painter output, signed transforms, ordinary interaction routes and sustained music remain open. A complete rescue route has not been replayed. About records the verification scope and provenance.