Space Invaders (Computer Archeology's annotated disassembly)

Space Invaders moves its rack of aliens one alien per frame. The interrupt at scanline 96 calls CursorNextAlien, which skips dead aliens to the next live one and waits until the end-of-screen interrupt's DrawAlien has drawn it. Only when the cursor passes the last of the 55 slots does MoveRefAlien step the reference alien, from which every other alien is drawn. A step of the rack therefore takes one 60 Hz frame per live alien: 55 frames at the start, 1 for the last alien. The listing reads MAME's invaders set, Midway's release. space-invaders/march

About: Space Invaders Remaining-enemy speed-up

[
 55,
 1
]

The frame count leaves out frames when the rack stands still, such as while the player's ship explodes (CursorNextAlien returns at once).

Cited by: Enemy formation, Remaining-enemy speed-up, Space Invaders

When the rack bumps an edge, RackBump reverses it and drops it 8 px: it sets the next step's drop from $200E, which the game's RAM copy fills with $F8 (-8), and MoveRefAlien clears the drop after one step. Its step to the right is 2 px, or 3 px when one alien is left; its step to the left is always 2 px. space-invaders/last-alien

About: Space Invaders Remaining-enemy speed-up

{
 "right": 2,
 "rightLastAlien": 3,
 "left": 2
}

Two comments in RackBump have the direction backwards: L3171 says "Rack now moving right" where the code stores 1, which the branch at L3164-L3165 (and RAMUse.md) reads as moving left, and L3184 says "Rack now moving left" where it stores 0. MoveRefAlien's comments (L328-L330) call $2007 "DeltaX"; RackBump fills it with the drop.

Cited by: Space Invaders

Each pass of the game loop, SpeedShots checks the number of aliens left; below 9 it sets the alien shots' step ($207E, added to a shot's Y each move) to $FB, -5 px, in place of the $FC (-4 px) that the game's RAM copy puts there, so the aliens' shots fall faster. space-invaders/shot-speed

About: Space Invaders Remaining-enemy speed-up

Value: 9 aliens (threshold)

The comment at L1506 says "Normally FF (-4)": the usual value is $FC, and $FF (-1) is what the splash animation at 18AE stores. RAMUse.md L135 says the delta is "Normally -1 but set to -4 with less than 9 aliens"; in play the code starts it at -4 and sets -5. The $FC sits after the "PLAY PLAYER<1>" message, in the part of the mirror whose comment (L4080, L4089-L4092) calls its copy to RAM a harmless mistake; the shot step depends on it.

Space Invaders awards one extra ship per player when the upper two digits of the score reach 15, or 10 with DIP switch bit 3 set: at 1,500 or 1,000 points. It then clears the player's award flag, so no second ship follows. space-invaders/extra-ship

About: Space Invaders Extra life

[
 1500,
 1000
]

Cited by: Extra life

Each new rack starts lower on the screen. The first rack's bottom row starts at Y $78. When a rack is cleared, the count of racks beaten (taken mod 8, plus 1) picks the next start from an 8-entry table, $60, $50, $48, $48, $48, $40, $40, $40, so the 10th rack starts where the 2nd did. space-invaders/rack-start

About: Space Invaders Difficulty ramp

[
 120,
 96,
 80,
 72,
 72,
 72,
 64,
 64,
 64
]

Y grows upward on the rotated screen, and CursorNextAlien ends the player's turn when an alien's Y falls below $28, so a lower start leaves fewer drops before the aliens land.

Cited by: Difficulty ramp

Space Invaders keeps one high score, four BCD digits at $20F4–$20F5. When a player's game ends, it compares that player's score with it, upper digits first, and copies the score over it if the score is higher. space-invaders/high-score

About: Space Invaders High score

Cited by: High score

Computer Archeology credits Mikael Agren with patching the original Space Invaders ROMs to add a high-score table. space-invaders/high-score-hack

About: Space Invaders High score

The patch's own blog post is linked from the README; the atlas hasn't archived it.

Cited by: High score

The shields are pixels in the 1-bit screen bitmap, not objects. Each player has a RAM buffer of four copies of the 44-byte ShieldImage, 22 rows of 2 bytes, a 22 × 16 px shape of 294 lit pixels (computed); RestoreShields ORs the buffer onto the screen, the four shields with 23 rows between them (45 from start to start), and in a two-player game RememberShields copies them from the screen back into the player's buffer, so each player keeps their own damage. The buffers are redrawn from the image at the start of a game and with each new rack. space-invaders/shields-bitmap

About: Space Invaders Destructible terrain

{
 "width": 22,
 "height": 16,
 "pixels": 294,
 "shields": 4,
 "gap": 23,
 "pitch": 45
}

gap is the empty columns between two shields (23) and pitch the distance from one shield's first column to the next one's (45). The shields sit at screen address $2806 on: memory rows 32 on, bytes 6 and 7, which is 48 to 63 px up from the bottom of the 256 px column. RememberShields' comments note its load and store run the other way from its own comment ("should be DE"); it copies screen to buffer.

Cited by: Destructible terrain

Nothing tests for shields as such. Every shot is drawn with DrawSprCollision, which ANDs each byte of the shifted sprite with the screen before ORing it in and sets the collision flag if any pixel was already lit, so a shot hits a shield when its newly drawn sprite overlaps a lit shield pixel. The player's shot is 1 px wide and 4 px long and moves 4 px a step, so it is tested against every pixel row on its path (computed). A player's shot that collides below the rack takes status 3, the code for a hit on something other than an alien. space-invaders/shield-hit-test

About: Space Invaders Destructible terrain

{
 "shotWidth": 1,
 "shotLength": 4,
 "shotStep": 4
}

Rack and saucer hits come from the same flag: MovePlyShot copies it to alienIsExploding ($2002), and PlayerShotHit sorts the hit by the shot's height (saucer from Yr $CE, the top from $D8, the rack from the reference alien's row up). Alien shots, the player's ship, and the bottom line are lit pixels too, so the same test hits them.

Cited by: Destructible terrain

A player's shot that hits a shield erases itself, then ORs the 8 × 8 px ShotExploding pattern onto the screen around the point of impact; after the blow-up timer counts down from 16, EndOfBlowup erases that pattern with an inverted AND. The erase clears every pixel under the pattern's 38 set bits (computed), shield pixels included, and the first erase had already cleared the shield pixels under the shot itself, so the hole is the explosion's shape plus the shot's last 4 px. space-invaders/shot-crater

About: Space Invaders Destructible terrain

{
 "pattern": [
  8,
  8
 ],
 "pixels": 38,
 "timer": 16
}

The explosion is placed 2 px back along the shot's path (Yr − 2) and 3 px across (Xr − 3), which centers the 8 px wide pattern on the 1 px shot. The same explosion ends a shot that hits an alien shot or leaves the top of the playfield. The disassembly's picture of the pattern is in memory order, rotated from the screen.

Cited by: Destructible terrain

An alien shot ends when its newly drawn sprite collides with any lit pixel, or when it falls below the playfield; a collision at the player's height kills the player instead. Its blow-up timer starts at 4: on the first tick ShotBlowingUp erases the shot and draws the 6 × 8 px AShotExplo pattern, and on the tick that reaches 0 it erases that pattern with an inverted AND, so a shield loses the pattern's 26 pixels (computed) plus those under the shot itself. space-invaders/bomb-crater

About: Space Invaders Destructible terrain

{
 "pattern": [
  6,
  8
 ],
 "pixels": 26,
 "timer": 4
}

The three alien shots take turns, one per interrupt tick (GameObj2's comment), so the explosion lasts three of that shot's own updates, not three frames. A collision with the player's shot or the bottom line blows the shot up the same way; at the player's height (Yr $1E to $26) it also clears playerAlive.

Cited by: Destructible terrain

Aliens that reach the shields erase them. DrawSprite, which draws each alien, stores the shifted sprite bytes over the screen instead of ORing them in, both bytes of each of its 16 rows, so wherever an alien is drawn the shield pixels in those bytes are replaced by the alien's image and its blank pixels. The disassembly's comment on CodeBug1 describes a lone alien that "enters the players shields on the lower left where it begins to eat them". space-invaders/aliens-erase-shields

About: Space Invaders Destructible terrain

A shot alien's explosion is erased by EraseSimpleSprite, which zeroes two whole bytes per row, so an alien shot down inside a shield clears that patch too. Nothing restores a shield before the next rack.

Cited by: Destructible terrain