Paradroid

01 · The 001

Secret: the 001 burns out on its own in a little over eight minutes

The briefing warns that the device burns out unless it changes hosts often. It does not say that the bare helmet burns out too: a player who never takes a host loses the game by waiting.

Seconds alone

The slider counts passes at 16.5 a second. Tested in VICE: the 001 left alone lost two points of its limit in 800 frames, and with the limit set to 1 the next fall emptied its energy and the game ended, as above.

The burn-out rule lives in alert ($3E32) and has no exception for the 001. Every 16 passes it tests the pass count against the host's mask from burn_masks ($6DDE); class 0's mask is $7F, so the 001 loses a point of its limit every 128 passes, half as fast as a 123. The 001 starts each ship with a limit of 64, so after 64 × 128 passes, a little over eight minutes of play, its energy is 0 and out_of_energy ($144D) ends the game. A host other than the 001 that burns out only drops the player back to the 001 (How it works).

02 · A memory editor

Secret: a memory editor is left in the game

Between the game's text routines sits a small editor that shows an address and its byte on the status bar and changes either from the keyboard. Nothing in the game calls it, but it still works.

The editor running in VICE after one instruction of the game was changed so that the main loop calls it: the status bar as the editor starts, at address $0010, and after a press of J, with the chosen digit blinking and the byte at the new address, $4C.

The editor is abmon ($0D63-$0F0A), named by its own status line, "( abmon : 0000 - 00 )" (str_abmon, $0D2D). Each call reads one key: A and D switch it on and off, comma and full stop move along the six digits, and J and M add to or take away from the digit chosen, so the address steps by 1, 16, 256 or 4,096 and the byte by 1 or 16. Every change is written straight back to memory. No instruction in the program jumps to it or names any address inside it, yet init_vars ($0900) still sets up its variables at every cold start.

To try it, change the main loop's call of score_tick at $13E3 into a call of the editor, the bytes $63 $0D at $13E4, from a cartridge or an emulator's monitor. The score then stops counting up on screen, since the editor has taken the place of the routine that does it.

03 · Sprites

Secret: a robot with no sprite to show it on is taken off the ship

The game shows robots, shots and explosions on six hardware sprites. A robot that walks into view when all six are taken is removed from the ship for good, and the player is paid nothing for it.

In droid_step ($18CA), a robot entering the window asks find_sprite for one of sprites 1 to 6. When none is free, the code sets its energy to 0 and calls unpopulate, which clears its place in the ship's population table, so the robot does not come back on a later visit to the deck. The count of robots in the ship falls with it, and a ship can be cleared with fewer robots destroyed than it held. A crowded screen, with shots and explosions on most of the sprites, is when it happens.

04 · Transfer

Secret: a lost transfer still takes the robot off the ship

Losing a transfer throws the 001 out of its host, but the robot it tried to take is removed all the same, as if the transfer had been won.

transfer_result ($21CF) settles who won, and then transfer_done ($2260) runs for every result: it sets the target's energy to 0, frees its sprite and clears its place in the ship (unpopulate). A player who loses keeps the 001 and loses the host's ram points, but the robot is gone, unscored. A lost transfer is therefore a way to clear a big robot from a deck for the price of a host, though from the bare 001 a loss ends the game.

05 · The enquiry

Secret: every droid stands between 1.00 and 1.99 m

The robot enquiry prints a height for every type. Each one is "1." followed by two digits from the droid's record, so the command cyborg and the little disposal robot are never more than 99 cm apart.

The byte is binary-coded decimal, two digits in one byte, and the code prints its two halves as they are. So the 001 and the 821, whose bytes are $00, stand exactly a metre tall, and the 614, the 711 and the 751, at $93, are the tallest at 1.93 m. Weight has three digits of its own, from 23 kg for the 302 to 227 kg for the 751.

06 · Energisers

Secret: an energiser charges 5 points for every point of energy

The energisers on each deck refill the host, and the score pays for it. Slide to see what a refill costs.

Energy to refill

Tested in VICE: on deck 7's energiser for 200 frames with the energy set to 16, the host gained 17 points of energy and the score fell by 85.

Standing on an energiser cell, floor_cell ($2E7B) adds a point of energy every fourth pass, up to the host's limit, and calls score_down with 5 each time. The points come off the score a point at a time, the way an award goes on (score_tick, $0A7D). The debt meets the score at 0 and stops there: the tick that would take the score below 0 sets it to 0 and drops whatever is still owed, so for a player with no points to lose, an energiser costs nothing.

07 · The day's scores

Secret: the day's best and worst scores start at 6809 and 6502

The title pages show the top and the lowest score of the day. Before anyone plays, they are 6809, held by AEB, and 6502, held by TSO.

A game that ended on 50 points, under 6502, in VICE: the lowest score of the day, and a prompt for initials.

The two scores are eight BCD digits each, top_score at $E70C and worst_score at $E710, and score_check ($E4E5) compares every finished game with both. A score above the top or below the worst takes its place and asks for initials. The two starting numbers are also the part numbers of two 8-bit processors, the Motorola 6809 and the MOS 6502; the game says nothing more about them, or about AEB and TSO.