Space Invaders
Space Invaders

    
      

 Disassembled Code as Z80 opcodes
 RAM Usage
 Hardware Info


Mikael Agren patched the original ROMs to add a high-score table. 
Check out his project blog and demo movie.

The Space Invaders System
Space Invaders as described on the Wikipedia was one of the very first video arcade games. 
Released in 1978 by Taito, it ushered in the Golden Age of Arcade Games. Most video games before SI used dedicated circuit boards without 
a CPU. SI uses an 8080 CPU (the primitive forerunner of the Z80). The CPU board carried forward into several other games.

SI uses a black-and-white raster display (grid of pixels). Interestingly, vector graphics like in Atari Asteroids did not hit the market 
until 1979. In SI the hardware paints the monitor in the usual way: from left to right and top to bottom with a vertical retrace at the 
end. But the monitor is rotated counterclockwise 90 degrees counter-clockwise in the game cabinet. The rotation makes the code comments 
and screen coordinates a bit confusing. Here and in the code comments I'll use the terms "rotated" and "non-rotated" to help.

The game uses colored transparencies that overlay certain areas of the monitor. The player's area is green and the flying saucer line is 
red. The overlays are obvious when you see shots changing colors at the top and bottom of the screen.

Screen memory is organized as one-pixel-per-bit -- eight pixels per byte. All sprites in the game are one byte wide but many rows long (on 
the rotated screen they are all 8 bits tall but 8, 16, or more bits wide). Rarely does a game sprite align perfectly to a byte boundary in 
screen memory. Most of the time the image pixels have to be shifted. Some of the pixels fall in the first byte of screen memory and some 
spill over into the next byte. The 8080 instruction-set lacks multi-bit shifts to make sprite rendering practical. But the SI hardware 
includes a 2-byte shift register mapped into port memory. The sprite drawing hardware runs all images through the shift register for a 
very fast bit-mapping.

The Space Invaders sounds are all discrete analog circuitry. Opamps and decaying RC networks create an eerie realism that digital sound 
chips fall short of today. The individual sound circuits are triggered by bits in two output ports. 

In the early eighties you would have found the Space Invaders cabinet in an arcade right next to the pinball machines. So a "tilt" switch, 
like you would find in a pinball machine, would not have seemed as strange as it does today. If you shake, slap, or otherwise physically 
abuse an SI cabinet you will get a TILT message and your game will end.

General Code Structure
The assembly code is filled with lots of questionable structures. In general, there are lots and lots of NOP instructions. Some are executed 
in the code flow, but most are used as padding between code sections. I suspect that the value 00 was the default written to empty areas 
instead of the more common FF. For an EEPROM an erased memory byte contains "FF" and you have to burn the 0's in.

I added "%%" to comments in the code that you can search for to find these questionable areas. I'll note a few really strange code spots 
in passing:

The code at 0456 reads a two byte value from memory, increments it, and writes it back. But the code only increments the LSB. The upper 
byte never changes and is never accessed anywhere else in the code.

0456: 2A 8F 20        LD      HL,($208F)          ; Increments with every shot ...
0459: 2C              INC     L                   ; ... but only LSB ** ...
045A: 22 8F 20        LD      ($208F),HL          ; ... used for saucer direction

A common shortcut in assembly is to replace a CALL followed by a RET with just a JUMP to the subroutine. At 09AA the shortcut jumps to 
the very next line of code. An even shorter cut would be to take the jump out completely.

09A5: 23              INC     HL                  ; Load ...
09A6: 7E              LD      A,(HL)              ; ... the ...
09A7: 23              INC     HL                  ; ... screen ...
09A8: 66              LD      H,(HL)              ; ... coordinates ...
09A9: 6F              LD      L,A                 ; ... to HL
09AA: C3 AD 09        JP      $09AD               ; ** Usually a good idea, but wasted here

;##-Print4Digits
; Print 4 digits in DE
09AD: 7A              LD      A,D                 ; Get first 2 digits of BCD or hex
09AE: CD B2 09        CALL    $09B2               ; Print them
09B1: 7B              LD      A,E                 ; Get second 2 digits of BCD or hex (fall into print)

;##-DrawHexByte
; Display 2 digits in A to screen at HL
09B2: D5              PUSH    DE                  ; Preserve
09B3: F5              PUSH    AF                  ; Save for later

Assembly programmers do all kinds of "unstructured flow" tricks with the stack. Some of it is confusing and potentially error prone. The 
code at 0x01A2 breaks out of a routine when D reaches 0. But it doesn't return to the caller -- it discards a slot on the stack returns to 
the caller's caller (the grand-caller?)! The code makes some dangerous assumptions about who is calling it.

;##-MoveRefAlien
; The "reference alien" is the bottom left. All other aliens are drawn relative to this
; reference. This routine moves the reference alien (the delta is set elsewhere) and toggles
; the animation frame number between 0 and 1.
;
01A1: 15              DEC     D                   ; This decrements with each call to move
01A2: CA CD 01        JP      Z,$01CD             ; Return out of TWO call frames (only used if no aliens left)
01A5: 21 06 20        LD      HL,$2006            ; Set current alien ...
...
;##-ReturnTwo
; If there are no aliens left on the screen then MoveDrawAlien comes here which returns from the
; caller's stack frame.
;
01CD: E1              POP     HL                  ; Drop return to caller
01CE: C9              RET                         ; Return to caller's caller

At 0x0A01 the value of A is stuffed into location 0x2067. The very next instruction loads A from 0x2067. This might make sense if any other 
line of code jumped to 0x0A04. But nobody does.

0A00: F1              POP     AF                  ; Restore ...
0A01: 32 67 20        LD      ($2067),A           ; ... current player number
0A04: 3A 67 20        LD      A,($2067)           ; ** Why load this again? Nobody ever jumps to 0A04?
0A07: 67              LD      H,A                 ; To H

The count-aliens routine at 0x15F3 sets the location 0x206B to 1 if there is only one alien left. Nobody every reads the flag from 0x206B. Maybe 
it was used at one time? At any rate the instructions at 0x160B and 0x160E could have been replaced with just "LD ($2067),A" to save some time 
and space.

;##-CountAliens
; Count number of aliens remaining in active game and return count 2082 holds the current count.
; If only 1, 206B gets a flag of 1 ** but ever nobody checks this
15F3: CD 11 16        CALL    $1611               ; Get active player descriptor
15F6: 01 00 37        LD      BC,$3700            ; B=55 aliens to check?
15F9: 7E              LD      A,(HL)              ; Get byte
15FA: A7              AND     A                   ; Is it a zero?
15FB: CA FF 15        JP      Z,$15FF             ; Yes ... don't count it
15FE: 0C              INC     C                   ; Count the live aliens
15FF: 23              INC     HL                  ; Next alien
1600: 05              DEC     B                   ; Count ...
1601: C2 F9 15        JP      NZ,$15F9            ; ... all alien indicators
1604: 79              LD      A,C                 ; Get the count
1605: 32 82 20        LD      ($2082),A           ; Hold it
1608: FE 01           CP      $01                 ; Just one?
160A: C0              RET     NZ                  ; No keep going
160B: 21 6B 20        LD      HL,$206B            ; Set flag if ...
160E: 36 01           LD      (HL),$01            ; ... only one alien left
1610: C9              RET                         ; Out

There is a huge empty area in the ROM between 0x0C00 and 0x13FF (2K bytes but not on a 2K ROM chip boundary, which would have saved the cost of 
a chip). That's 1/4th of the ROM empty, which leaves a lot of space for expansion. And yet it appears the developers felt they were running 
out of space! (Update ... this area was for a diagnostics routine that got dropped)

The end of ROM beginning at 0x1E00 contains an 8x8 pixel character set used to draw text on the screen. The area is filled out completely 
with 64 characters, but some of them were not used in messages by the game. The developers reclaimed the space of these unused characters 
for other purposes (see 0x1F50) rather than using the plentiful space at 0x0C00. Very strange.


There is a hidden message in the Space Invaders code. You can get the message "TAITO COP", with no "R" as in "CORP", to appear at the top 
of the screen during the demo play. Wait for the demo play to start and hold down "2 Start", "1 Fire", "1 Left", and "1 Right". The order 
you press them and the timing does not matter as long as you get all the buttons down at the same time eventually.

That's the first sequence. Then you have to hold down the second sequence: "1 Start", "1 Fire", "1 Left". Again the timing does not matter. 
An easy way is to hold down the first sequence and just switch start buttons and let up on "1 Right". You will see the message at the top 
of the screen in the "Flying Saucer" area (in red). The message will be erased when the demo finishes and you will have to reenter it every 
demo.

The MAME emulator has trouble with these simultaneous button presses. I was unable to reproduce the sequences in the emulator. I did patch 
the code to make a simpler sequence: "2 Start" then "1 Start".

;##-CheckHiddenMes
; There is a hidden message "TAITO COP" (with no "R") in the game. It can only be 
; displayed in the demonstration game during the splash screens. You must enter
; 2 seqences of buttons. Timing is not critical. As long as you eventually get all
; the buttons up/down in the correct pattern then the game will register the
; sequence.
;
; 1st: 2start(down) 1start(up)   1fire(down) 1left(down) 1right(down)
; 2nd: 2start(up)   1start(down) 1fire(down) 1left(down) 1right(up)
;
; Unfortunately MAME does not deliver the simultaneous button presses correctly. You can see the message in
; MAME by changing 19A6 to 02 and 19B1 to 02. Then the 2start(down) is the only sequence. 
;
199A: 3A 1E 20        LD      A,($201E)           ; Has the 1st "hidden-message" sequence ...
199D: A7              AND     A                   ; ... been registered?
199E: C2 AC 19        JP      NZ,$19AC            ; Yes ... go look for the 2nd sequence
19A1: DB 01           IN      A,($01)             ; Get player inputs
19A3: E6 76           AND     $76                 ; 0111_0110 Keep 2Pstart, 1Pstart, 1Pshot, 1Pleft, 1Pright
19A5: D6 72           SUB     $72                 ; 0111_0010 1st sequence: 2Pstart, 1Pshot, 1Pleft, 1Pright
19A7: C0              RET     NZ                  ; Not first sequence ... out
19A8: 3C              INC     A                   ; Flag that 1st sequence ...
19A9: 32 1E 20        LD      ($201E),A           ; ... has been entered
19AC: DB 01           IN      A,($01)             ; Check inputs for 2nd sequence
19AE: E6 76           AND     $76                 ; 0111_0110 Keep 2Pstart, 1Pstart, 1Pshot, 1Pleft, 1Pright
19B0: FE 34           CP      $34                 ; 0011_0100 2nd sequence: 1Pstart, 1Pshot, 1Pleft 
19B2: C0              RET     NZ                  ; If not second sequence ignore
19B3: 21 1B 2E        LD      HL,$2E1B            ; Screen coordinates
19B6: 11 F7 0B        LD      DE,$0BF7            ; Message = "TAITO COP" (no R)
19B9: 0E 09           LD      C,$09               ; Message length
19BB: C3 F3 08        JP      $08F3               ; Print message and out

Code Bug
There is a bug in the code, but it is very subtle. Here is a quick way to see it:

Shoot all the aliens but the one in the upper left. Try and stay to the left side of the screen as much as possible because you want to 
keep the aliens from shooting as much of your right shield as you can. Wait for this last alien to wiggle down the screen. Move to the 
far right side of the screen under the right edge of your right shield. The alien will turn green as it crosses the screen going from 
right to left above your shields. Just as it hits the left side of the screen and turns to eat your shields fire a shot into your shield. 
The game will think your shot hit the last alien and the next round will begin.

The timing is very critical, and it might take you several tries to see the bug. The best way to reproduce it is to play invaders in MAME 
and press Shift+F7 when there is only one alien left. That will save the state of your game, and you can press F7 to reload that state if 
you miss the timing. Eventually you will see it.

The bug is documented in the code at 0x1504, but I'll explain it in detail here.

The aliens are all drawn relative to the bottom left alien in the rack. This is the "reference alien". Even if it has been shot it continues 
to move as the origin for all the others (see discussion on The Aliens below).

There is an algorithm in the code to convert a screen point to a column/row coordinate within the alien rack. Rows go from 0 (the bottom row) 
up to 4 (the top row). Columns go from 0 (the left column) up to 10 (the right column). The code uses a "count the 16s" algorithm to see how 
many 16-pixels to add to the reference alien to get to (or just past) the target point. There are separate counts for X and Y. Each alien 
consumes a 16x16 pixel area on the screen. If the player's shot hits any pixel within the alien rack, this algorithm will find the row/column 
coordinate of the alien that was hit.

The "count the 16s" algorithm does NOT do boundary checking at all. The caller must assure that the target point is within the alien rack or 
unexpected values will result. If the target point is far to the right of the reference then the algorithm will produce a column number greater 
than the maximum 11th column. If the target point is left of the reference the results are a bit strange (see the code) and incorrect. Thus it 
is very important for the caller to make sure the target point is actually inside the alien rack.

The player-shot-collision code appears, at first glance, to check the boundary conditions correctly with some logical assumptions as follows:

The code first checks to see if the player's shot hit the saucer or exited the top of the screen. Next the code checks to see if the player's 
shot is above the Y coordinate of the reference alien. If the player's shot hits something below the saucer's zone and above the lowest alien 
point then it has to be inside the alien's 11x5 grid. What else could it be? No alien shots can be on the left or right of the grid. They can't 
be above it. Because the player's shot hit SOMETHING above the lowest alien point it must be a hit within the alien rack. Thus the "count 16s" 
algorithm will function correctly.

This assumption is the bug in the code. When the alien rack is down in the player's shield area then the player's shot can hit something outside 
the rack square -- the shields.

Start a new game and watch the full alien rack as it hits the right side of the screen and moves left. Move so you are peaking out of the right 
edge of the right shield. Position yourself so your shots will just miss the edge of your shield. Notice that when the aliens turn at the left 
side of the screen your shots are missing the alien rack but would be hitting an extra column of aliens if there were one.

The key point here is that the right edge of the player's right shield is in the 12th (invalid) column when the alien rack turns on the left 
side of the screen.

Now imagine all the aliens are dead except for the upper left. This alien is in row 4. Rows are numbered from 0 to 4 from bottom to top. This 
alien is in column 0. Columns are numbered from 0 to 10 from left to right.

The alien wiggles around and you shoot the right edge of your right shield when it makes its turn on the left into your screen row. The Y 
coordinate of your shot is below the alien. The game correctly calculates your shot hit row 3 (one below 4). The shot is outside the alien rack, 
but the code calculates the column anyway. It gets 11 (the 12th column).

Aliens are numbered sequentially from 0 to 54 (11*55 = 55 aliens). The code converts row/column numbers to an index with this 
formula: ROW*11 + COLUMN. For examples, the alien at row=0, column=0 is index 0*11+0 = 0. The alien at row=4, column=10 is index 4*11+10 = 54.

Our upper left alien is at index 4*11+0 = 44. The game converts the shot row/column to an index of 3*11+11 = 44. The indices are the same and 
the game thinks the shot hit the last alien. The column overflow effectively moves the shot to the start of the next row.

Game Timing
The game-play timing is based on an interrupt from the video system. Actually there are two interrupts. When the video rendering reaches the 
middle of the screen an RST 1 (jumps to 0x0008) is generated. When the rendering reaches the end of the screen (when vertical blanking begins) 
an RST 2 (jumps to 0x0010) is generated.

The separate interrupts allow the code to keep out of the way of the monitor's electron beam. If an object is moved in memory while the 
rendering hardware is drawing from the same memory then part of the image will be drawn at the old place and part at the new. This makes 
a very brief visual glitch that could, in theory, be noticed by the player. The flickers accumulate in the players mind over time.

Objects at the top of the screen are drawn after the mid-screen interrupt. Objects at the bottom of the screen are drawn after the end-screen 
interrupt. Thus the code and hardware work on different halves of the screen. I'll talk more about the mechanics of this in Game Objects below.

The screen refresh rate is 60Hz. So each interrupt is executed 60 times a second. Each interrupt has a list of chores to perform described below.

End of Screen Interrupt
The end-screen interrupt checks the tilt switch. It counts the credits as coins are inserted. The limit is 99 stored as a byte of 
binary-coded-decimal. After that coins are just ignored (an overflow would wipe out $25 of quarters).

This interrupt decreases a general-purpose counter at 0x20C0. This counter is used to time small delays in the attract mode. The print-text 
code sets this timer and waits for it to reach zero before moving to the next letter. Thus the letters appear on the screen in a slow, 
steady beat.

This interrupt also counts the aliens and changes the rate of the "step" sound. The sound rate is independent of the actual steps, as I'll 
explain below in The Aliens.

There are three different alien shots, each with a different picture. The end-screen interrupt sets a flag to keep all three in sync so that 
only one shot is processed per screen refresh.

This interrupt code draws exactly one alien every interrupt. This interrupt code keeps up with the time between flying saucers.

And most importantly, this interrupt (like the mid-screen interrupt) gives all five game objects a chance to run. Each object decides which 
interrupt to use based on which half of the screen it is on. I'll discuss this in detail in Game Objects below.

Mid Screen Interrupt
The mid-screen interrupt handles attract-mode tasks. In the attract mode there are two different animations to amuse a potential player 
passing by the cabinet. The first is an upside down "Y" in the message "PLAY" above "SPACE INVADERS". The small alien drags the letter 
off the screen and brings back the correct one. The second is an extra "C" in "INSERT CCOIN". The small alien shoots the extra "C". These 
animations happen every-other pass through the attract mode and not on the first pass.

The mid-screen interrupt advances the "next alien" cursor for the draw-alien process managed by the end-screen interrupt. See The Aliens 
below.

And most importantly again, this interrupt (like the end-screen interrupt) gives all five game objects a chance to run. Each object 
decides which interrupt to use based on which half of the screen it is on. I'll discuss this in detail in Game Objects below.

Game Objects
There are five game objects processed by the interrupt routines. They are (1) the player at the bottom of the screen, (2) the player's shot, 
and (3) (4) (5) three different alien shots. The Flying Saucer that appears briefly at the top of the screen uses the (5) alien shot. Only 
one of these objects (saucer or shot) can be on the screen at the same time.

Each task has a 16 byte data structure. The first three bytes of each structure are timers that the system uses to decide how often to run a 
task. It is up to the task to reset its timer once it runs. The three bytes are organized as one two-byte timer and a second one-byte timer. 
If the first two-bytes are zero then the task manager moves to the third byte.

A single two-byte timer would have been sufficient. I suspect, based on some evidence in the code, that the first two-byte timer was meant for 
the initial startup time of the object. The player's object uses this timer to delay for two seconds at the start of the game. The second timer 
was meant to delay between handlings once the object gets started. The alien shots use this timer to slow them down.

The next two bytes in each structure are a pointer to the task's code. This reminds me of a modern day object-oriented virtual function 
pointer table!

0263: 5E              LD      E,(HL)              ; Get handler address LSB
0264: 23              INC     HL                  ; xx04
0265: 56              LD      D,(HL)              ; Get handler address MSB
0266: E5              PUSH    HL                  ; Remember pointer to MSB
0267: EB              EX      DE,HL               ; Handler address to HL
0268: E5              PUSH    HL                  ; Now to stack (making room for indirect call)
0269: 21 6F 02        LD      HL,$026F            ; Return address to 026F
026C: E3              EX      (SP),HL             ; Return address (026F) now on stack. Handler in HL.
026D: D5              PUSH    DE                  ; Push pointer to data struct (xx04) for handler to use
026E: E9              JP      (HL)                ; Run object's code (will return to next line)
026F: E1              POP     HL                  ; Restore pointer to xx04
0270: 11 0C 00        LD      DE,$000C            ; Offset to next ... 
0273: 19              ADD     HL,DE               ; ... game task (C+4=10)
0274: C3 4B 02        JP      $024B               ; Do next game task

The remaining bytes in each object structure are object-specific data.

Each object has an X,Y coordinate in its specific data. The upper bit of the Y coordinate defines which half of the 
non-rotated screen the sprite is on. If the upper bit is 0 then the Y value is 0-127. If the upper bit is 1 then 
the Y value is 128-255 (223 is the screen limit). The first thing the interrupts do is set a bit identifying which one 
is running. Both interrupts call the task routines, but the routines only run in the context of one of them based on 
their Y coordinate.

The routine at 0x1A06 compares the upper bit of the Y coordinate to the interrupt-id. If the beam is on the other half of 
the screen then the C flag is set, which allows the task to run in the current context. If the beam is on the same half 
of the screen then the task routine returns and is executed by the "other" interrupt when the beam has moved on. For instance, 
here is the check for an alien shot:

; Move the alien shot
05C1: 11 7C 20        LD      DE,$207C            ; Alien-shot Y coordinate
05C4: CD 06 1A        CALL    $1A06               ; Compare to beam position
05C7: D0              RET     NC                  ; Not the right ISR for this shot

Game Object 0: Move/draw Player
The player object is unique in that code only calls it with the mid-screen interrupt no matter which half of the screen the 
player is on. Remember that on the non-rotated screen the player moves up and down on the left side of the screen. The end-screen 
interrupt specifically skips this object, and the object code does not compare its Y coordinate to the interrupt id like the others do.

The player runs every screen refresh. That's as fast as it can be. But the code appears to be designed to make the player run 
slower. There is a line of code that sets the second-byte-timer that would slow the player down -- if it were non-zero.

Here are the last lines few lines of the player's object code:

; Draw player sprite
036F: 21 18 20        LD      HL,$2018            ; Active player descriptor
0372: CD 3B 1A        CALL    $1A3B               ; Load 5 byte sprite descriptor in order: EDLHB
0375: CD 47 1A        CALL    $1A47               ; Convert HL to screen coordinates
0378: CD 39 14        CALL    $1439               ; Draw player
037B: 3E 00           LD      A,$00               ; Clear the task timer. Nobody changes this but it could have ...
037D: 32 12 20        LD      ($2012),A           ; ... been speed set for the player with a value other than 0 (not XORA)
0380: C9              RET                         ; Out

This code first draws the sprite then sets the one-byte timer at 0x2012. Notice that the value loaded into A to set this timer is 00. 
The timer is already at 00 or this task would never have run. In fact, this is the only place in the code that writes to this memory location.

Notice that the instruction to set A to 00 is the two-byte indirect instruction "LD A,$00". A faster, smaller way is to use the 
one-byte instruction "XOR A" that exclusive-ORs the register with itself. This "fast zero" is used all over the code. In fact, the less 
efficient instruction "LD A,$00" is only used twice in the entire code: here and at 0x00CD. At 0x00CD it was specifically chosen because 
it does not affect the flags, which are passed to the next instruction.

00CB: FE FE           CP      $FE                 ; Moving left?
00CD: 3E 00           LD      A,$00               ; Value of 0 for rack-moving-right (not XOR so flags are unaffected)
00CF: C2 D3 00        JP      NZ,$00D3            ; Not FE ... keep the value 0 for right

I suspect at one time the "LD A" had a non-zero value. But a delay of any kind was probably too slow for play.

I suspect the task was originally designed to pick an interrupt based on Y like the other objects. Why was the task changed to run at 
only mid-screen? I suspect -- and this is pure speculation -- that the pick-a-half-of-the-screen algorithm produced an undesirable visual 
effect. The mid-screen interrupt happens at scan-line 96. But the code asserts it happens at scan-line 128 by using the Y coordinate's 
upper bit. There is a 32 byte discrepancy near the middle of the screen, and the player moving left and right at the mid screen may have 
made this difference obvious with the flicker it was trying to avoid. I need to burn a new set of ROMs to test this theory since it would 
not appear in the MAME emulator which drives a faster monitor.

The player task code is straight forward. If the player is blowing up then the code flips back and forth between two images for half a 
second. If the game is in player-mode then the buttons translate to left or right.

; Draw player sprite
036F: 21 18 20        LD      HL,$2018            ; Active player descriptor
0372: CD 3B 1A        CALL    $1A3B               ; Load 5 byte sprite descriptor in order: EDLHB
0375: CD 47 1A        CALL    $1A47               ; Convert HL to screen coordinates
0378: CD 39 14        CALL    $1439               ; Draw player
037B: 3E 00           LD      A,$00               ; Clear the task timer. Nobody changes this but it could have ...
037D: 32 12 20        LD      ($2012),A           ; ... been speed set for the player with a value other than 0 (not XORA)
0380: C9              RET                         ; Out

;##-MovePlayerRight
; Handle player moving right
0381: 78              LD      A,B                 ; Player coordinate
0382: FE D9           CP      $D9                 ; At right edge?
0384: CA 6F 03        JP      Z,$036F             ; Yes ... ignore this
0387: 3C              INC     A                   ; Bump X coordinate
0388: 32 1B 20        LD      ($201B),A           ; New X coordinate
038B: C3 6F 03        JP      $036F               ; Draw player and out

The player's fire button is read and debounced in the main game loop at 1618. In demo mode the player always fires, and when the player 
shot is removed from play a new demo command is read from an 11 byte table. The change of direction in the demo thus depends on the shot 
exploding, which is somewhat non periodic.

Game Object 1: Move/draw Player's Shot
The player's shot uses the Y coordinate and interrupt id to decide when to run. The shot can be in several states: just starting, moving 
up screen, blowing up because of hitting an alien, or blowing because of hitting something else.

The shot's deltaY (rotated screen) is a constant 4-pixels per interrupt. The shot covers the entire screen at a rate of 60Hz*4 pixels = 240 
pixels/sec. The shot image itself is just a single byte -- a four-pixel line.

The sprite drawing algorithm checks the bits on the screen as it writes new bits. If a bit overlaps then a collision detection flag is set. 
If the player's shot is drawn over anything on the screen then a flag is set and checked at 190A in the main game loop.

Game Object 2, 3, and 4: Alien Shots
There are three different alien shots in the game, and each has a unique picture. Object 2 is the "Rolling" shot. It spirals a bit as it 
falls. Object 3 is the "Plunger" shot. It reminds me of a bathroom plunger falling down the screen. Object 4 is the "Squiggly" shot. It 
looks like a turning zig-zag line much like a resistor circuit symbol.

The byte timer from Object 2 is used to synchronize the three shots so that only one shot is processed per screen. The objects can't 
synchronize directly from the timer byte at 2032 since its decrement depends on which half of the screen it is on. Instead the timer byte is 
copied to a sync-flag at 0x2080 where it remains constant for all the shots between end and mid screen interrupts.

The code uses a common routine to handle all three shots. Each shot task copies its data structure to a common area, calls the handler, 
and then copies the changed data back to its personal area.

The common handler is responsible for moving each shot. The normal delta Y for the shots is a constant 4 pixels down per step. A shot makes
a step every 3 frames. (4*60/3 = 80 pixels per second). But when there are 8 or fewer aliens on the screen the delta changes up to 5 pixels 
per step (5*60/3 = 100 pixels per second).

The common handler also initiates the alien shots. Each shot has a move-counter that starts when the shot is dropped and counts up with 
each step as it falls. The game keeps a constant reload rate that determines how fast the aliens can fire. The game takes the smallest 
count of the other two shots and compares it to the reload rate. If it is too soon since the last shot then no shot is fired.

The reload rate gets faster as the game progresses. The code uses the upper two digits of the player's score as a lookup into the table 
at 1AA1 and sets the reload rate to the value in the table at 1CB8. The reload rate for anything below 0x0200 is 0x30. From 0x0200 to 0x1000 
the delay drops to 0x10, then 0x0B at from 0x1000 to 0x2000. From 0x2000 to 0x3000 the rate is 8 and then maxes out above 0x3000 at 7. With a little 
flying-saucer-luck you will reach 0x3000 in 2 or 3 racks.

The "rolling" shot (object 2) drops right over the player when it falls. The other two shots use pointers into a table of columns at 0x1D00. 
The pointers advance very predictably. You can see from the table that the "squiggly" shot will fall first in column 11 and then 1, 6, and 3.

When there is only one alien left on the screen the plunger shot is disabled. Only the "rolling" (tracking) and squiggly shots are active, 
which means the tracking shot gets fired more often.

Flying Saucer
The flying saucer shares the object-task with the "squiggly" shot. Only one of them can be on the screen at a time. The main loop keeps up 
with the time-until-saucer.

;##-TimeToSaucer
0913: 3A 09 20        LD      A,($2009)           ; Reference alien's X coordinate
0916: FE 78           CP      $78                 ; Don't process saucer timer ... ($78 is 1st rack Yr)
0918: D0              RET     NC                  ; ... unless aliens are closer to bottom
0919: 2A 91 20        LD      HL,($2091)          ; Time to saucer
091C: 7D              LD      A,L                 ; Is it time ...
091D: B4              OR      H                   ; ... for a saucer
091E: C2 29 09        JP      NZ,$0929            ; No ... skip flagging
0921: 21 00 06        LD      HL,$0600            ; Reset timer to 600 game loops
0924: 3E 01           LD      A,$01               ; Flag a ...
0926: 32 83 20        LD      ($2083),A           ; ... saucer sequence
0929: 2B              DEC     HL                  ; Decrement the ...
092A: 22 91 20        LD      ($2091),HL          ; ... time-to-saucer
092D: C9              RET                         ; Done

Game task 4 checks the "time for saucer" flag. If it isn't time or if there is already a squiggly shot going then it handles the 
squiggly shot. If there are 8 or more aliens on the screen then a saucer begins its journey across the screen.

The flying saucer's direction is linked to the player's shot count. The lowest bit of the count determines which side of the screen the 
saucer comes from. If the saucer appears after an even number of player shots then it comes from the right. After an odd number it comes 
from the left. The saucer object structure is re-initialized every time the player's shot blows up. Here is the code in Object 1 (player fire):

045D: 3A 84 20        LD      A,($2084)           ; Is saucer ...
0460: A7              AND     A                   ; ... on screen?
0461: C0              RET     NZ                  ; Yes ... don't reset it
;
; Setup saucer direction for next trip
0462: 7E              LD      A,(HL)              ; Shot counter
0463: E6 01           AND     $01                 ; Lowest bit set?
0465: 01 29 02        LD      BC,$0229            ; Xr delta of 2 starting at Xr=29
0468: C2 6E 04        JP      NZ,$046E            ; Yes ... use 2/29
046B: 01 E0 FE        LD      BC,$FEE0            ; No ... Xr delta of -2 starting at Xr=E0
046E: 21 8A 20        LD      HL,$208A            ; Saucer descriptor
0471: 71              LD      (HL),C              ; Store Xr coordinate
0472: 23              INC     HL                  ; Point to ...
0473: 23              INC     HL                  ; ... delta Xr
0474: 70              LD      (HL),B              ; Store delta Xr
0475: C9              RET                         ; Done

The score for shooting the saucer ranges from 50 to 300, and the exact value depends on the number of player shots fired. The table 
at 0x1D54 contains 16 score values, but a bug in the code at 0x044E treats the table as having 15 values. The saucer data starts out 
pointing to the first entry. Every time the player's shot blows up the pointer is incremented and wraps back around. Here is the 
table. You have to append a trailing "0" to every value to get the three digit score.

; 208D points here to the score given when the saucer is shot. It advances 
; every time the player-shot is removed. The code wraps after 15, but there
; are 16 values in this table. This is a bug in the code at 044E (thanks to
; Colin Dooley for finding this).
;
; Thus the one and only 300 comes up every 15 shots (after an initial 8).
1D54: 10 05 05 10 15 10 10 05 30 10 10 10 05 15 10 05 

There are five entries of 050, eight entries of 100, two 150s, and only one 300. The 300 score comes up every 15 shots (after an initial 
eight). It should come up every 16, but again -- the code has a bug.

Eric Furrer discovered the pattern long ago to get 300 points for the saucer every time. The algorithm can be more easily described once 
you've seen the code:

At the start of every level keep a count of the shots you make as they explode -- whether they hit anything or not. Count to 8 and start over. 
From then on count to 15 and start over. You want the 15th shot to be the one that hits the saucer (or the first 8th if you can manage it).

The Aliens
There are 5 rows of 11 aliens in Space Invaders. There are three types of aliens. Each type has two pictures that flip to make animation 
with each "step".

The lower left alien of the rack is the "reference" alien. The game keeps up with the reference alien's coordinates and all the others are 
drawn relative to it. Each player has a 55 byte table that tracks the living/dead state of each alien.

The end-screen interrupt draws precisely one alien each screen painting. The lower left alien moves left or right 2 pixels and the code 
redraws it. On the next pass (interrupt) the alien to the right of the reference moves. The wave continues each screen refresh (60 times 
a second) from left to right and bottom to top. Once all live aliens have been drawn the process starts again. When the rack hits the 
left or right side of the screen the direction reverses and the reference alien is dropped 8 pixels.

The more aliens there are on the screen the longer it takes to get back around to moving the reference alien. At the start of the round 
there are 55 aliens. That's 55 interrupts or almost 1 second to move the entire rack. At the end of the round there is only one alien 
left. It moves 2 pixels left or right 60 times a second. That's about two seconds from side to side.

The game does a nasty trick to the timing when there is one alien left. Instead of moving 2 pixels both directions the alien moves 2 
pixels at a time to the left but 3 pixels at a time to the right. The last little alien is faster going right than it is going left. This 
changes the timing up just enough to make it difficult to lead the advancing alien with a shot.

The speed of the fleet tones does NOT match the actual speed of the alien rack. The delay-between-tones is read from a table and depends on 
how many aliens are left in play.

; Alien delay lists. First list is the number of aliens. The second list is the corresponding delay.
; This delay is only for the rate of change in the fleet's sound.
; The check takes the first num-aliens-value that is lower or the same as the actual num-aliens on screen.
;
; The game starts with 55 aliens. The aliens are move/drawn one per interrupt which means it
; takes 55 interrupts. The first delay value is 52 ... which is almost in sync with the number
; of aliens. It is a tad faster and you can observe the sound and steps getting out of sync.
;
1A11: 32 2B 24 1C 16 11 0D 0A 08 07 06 05 04 03 02 01
1A21: 34 2E 27 22 1C 18 15 13 10 0E 0D 0C 0B 09 07 05     
1A31: FF   ; ** Needless terminator. The list value "1" catches everything.

The first value in the table is a delay of 52 interrupts between sounds when there are 50 or more aliens. When there are 55 aliens the 
step sounds are faster than the rack. When there are 50 aliens the step sounds are slower than the rack.

When there are 43 aliens the step speed changes to 46 interrupts between changes. Again, the sounds are faster than the aliens. When 
there is only 1 alien left the delay minimizes to 5 interrupts between changes. Anything faster sounds unpleasing.

Even though the alien racks speeds up very smoothly as they die, the step sounds take sudden changes. If you wait a bit between killings 
you can hear the sudden changes -- especially at the beginning of the game when the deltas in the table are large.

The table at 1DA3 gives the starting Y (rotated) coordinates for the alien rack with each new round.

;##-AlienStartTable
; Starting Y coordinates for aliens at beginning of rounds. The first round is initialized to $78 at 07EA.
; After that this table is used for 2nd, 3rd, 4th, 5th, 6th, 7th, 8th, and 9th. The 10th starts over at
; 1DA3 (60).
1DA3: 60                                    
1DA4: 50                                    
1DA5: 48                                    
1DA6: 48                                    
1DA7: 48                                    
1DA8: 40                                    
1DA9: 40                                    
1DAA: 40   

The first wave starts at Y=78 (hex). The next wave starts 16 pixels (one row of the rack) lower at Y=50. Then the rack holds at 48 for 
three rounds and then 40 for three rounds. The value Y=40 is just above the player's shields.

Round 7 is as hard as the game gets. By that time the player's score is above 3000, which means the aliens reload their shots at the 
fastest rate. The aliens never start out lower than Y=40. If you can manage the game at level 7 you can play forever.

Corrections
Thanks to Colin Dooley for correcting the comments around 1D15. He pointed out the "rolling" shot tracks the player ... not the "plunger" 
shot as originally commented.

Thanks to Colin Dooley for correcting the comments around the saucer-score-table at 0x1D54. He pointed out that the code at 0x044E wraps 
after 15 values and not 16. This brings the code in line with the guides that say the 300 value comes up every 15 shots (instead of 16).

Thanks to Glen Hewlett for correcting the comments above 0x0A93. He points out the length is in C and not B.

Thanks to Adrian Torres for pointing out that hexidecimal values in the write-up should be prefixed with '0x'. He also corrected
'RST 8' and 'RST 10' pointing out that they are really 'RST 1 (jumps to 0x0008)' and 'RST 2 (jumps to 0x0010)'.

Thanks to Elliot Roush for correcting the alien-shot-screen-deltas. The correct values are -4 (normally) and -5 (when less than 8 aliens).


      
    