Target Renegade

01 · Video

One frame from memory

The playfield and panel use different screen areas and character shapes. The display changes those selections while the beam draws the picture. Small video control values, called registers, hold each selection. Reading them once would miss the changes.

A recording of 38 video writes rebuilt all 104,448 pixels with zero differences from the emulator capture. The page carries only the 2,229 RAM bytes the picture reads, its colours, and the write timings. Native comparison picture.

The interrupt dispatcher, which briefly takes over from the main game, at $AAF0 selects routines through a table of return addresses. The playfield keeps two grids of character numbers, called screen buffers, at $4000 and $4400. Its character shapes are at $4800. The panel uses its own grid at $3400 and shapes at $3800.

02 · Fighters

Reflecting a fighter component

A sprite is a picture the computer can position independently of the background. A fighter is assembled from several stored sprite components. A component contains 21 rows of three bytes. Facing can reflect each row. A single-colour shape reverses its individual on/off bits. A multicolour shape uses pairs of bits for four possible colours. Reflecting those pairs keeps each pixel's colour intact.

The reflection routines beginning at $FD42 fill a temporary area of reflected pictures, called a cache, at $7E00–$7FFF. Each shared component has a spare alignment byte so that the next starts 64 bytes later. Reflection leaves that byte alone. The display routine then chooses a stored pointer or a cache pointer for each hardware sprite.

All 99 shared components matched native reflection in both modes: 198 sprite cases. The byte reversal was also checked on all 256 possible byte values. Colours here are illustrative. The mode switch shows the two encodings and does not name a pose for every stored component.

03 · Sprites

Every fighter is built from the same 99 pictures

The game stores 99 shared fighter and object pictures from $5000 to $68BF. Each takes 64 bytes: 63 bytes of picture, which is 21 rows of three bytes, and one spare byte. A picture is 24 pixels wide in a hires sprite, or 12 pixels of two bits each in a multicolour sprite. Each is stored facing one way, and the game builds the other facing by reflecting it (the reflection tool above shows how).

Components 95, 96, and 97 are thin diagonal sticks at three angles. They look like the baseball bat, but the code that would confirm it has not been traced.

04 · Assembly

A fighter is more than one sprite

A man on screen is taller than one 21-row sprite, so the game builds each fighter from components. The code marks three components for the player ($94F8) and two for each of the two ordinary enemies ($950E). The C64 has eight sprites. That makes seven components for fighters, and the eighth appears to carry a weapon that is held or lying on the floor. A motorbike takes four: a pair of top components that differ by two sprite numbers, and a pair of lower ones that differ by one ($901B, $9023). The last opponent is drawn from one of twenty top components and one of twenty lower ones, set 24 units apart to the side he faces ($8D8B).

Commodore User wrote that "each man is four sprites large" and that Mr. Big is "eleven sprites huge".¹⁰ The component counts above do not match those numbers, so the magazine may have counted screen area in sprite-sized blocks. That is open. The sheet suggests one reading: hires outlines laid over multicolour fills. The sprite-assignment routines have not been traced far enough to say whether the game does that.

05 · Scrolling

The screen is copied a piece at a time while it scrolls

The playfield uses two screen buffers, at $4000 and $4400, and flips between them. The video chip's fine-scroll setting moves the picture by up to seven pixels. When it wraps, the character data must move by one whole cell. The game does not copy the whole screen in one frame. It copies the character data into the hidden buffer in pieces, one at each fine-scroll step: three 256-byte chunks and a 31-byte tail ($AA12 for scrolling left, $AA81 for right, $A9A3 for up and down). At the next whole-cell step the colour shift below runs and the buffers swap.

Colour memory cannot be double-buffered, so it is shifted in one go at the swap: columns 1 to 39 move one cell left in each of 20 colour rows ($A5FD). The shift for the other direction leaves row 0 unchanged ($A6A9), and whether that shows on the screen has not been checked. While a coarse scroll is pending the main loop waits for the raster beam to pass line $90 before it updates the score ($A742).

06 · Backgrounds

A map 80 blocks wide and 20 deep

Each load holds one background map, 80 columns by 20 blocks, shared by its stages, and each block is 16 characters ($2A6C). That is 320 by 80 character cells, and the Levels tab draws all five. In the first stage the code has four camera-row targets, at rows 20, 40, 60, and 80 ($8402), for the vertical moves between its sections. That fits Commodore User's account of a car park of four levels joined by a lift.¹⁰ It has not been checked by playing through.

07 · The panel

The picture is split in two

The status panel at the bottom uses its own screen and character set, so the display switches between the playfield and the panel part-way down. An interrupt at raster line $CF sets the display mode and switches to the panel's screen and font ($AB6B). A second at line $D5 sets the mode back, schedules a third at $EE, and clears all eight sprite Y positions ($AB98). The camera transitions patch those line numbers. The frame demonstration rebuilds one such frame from memory, pixel for pixel.