Mikael Agren patched the original ROMs to add ahigh-score table. Check out his project blog and demo movie.
Space Invadersas described on the Wikipediawas 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 Z 83). 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 . 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 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, (*****************************************************************************************************************************************************************************, 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.
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 02 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 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.
(**********************************************************************************: 2A 8F LD HL, ($) ******************************************************************************************************** F); Increments with every shot ... (********************************************************************************: 2C INC L; ... but only LSB ** ... (A:) **************************************************************************************************************************************************************************** (8F) ********************************************************************************************************************************************************************************** LD************************************************************************ FL, 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 AA the shortcut jumps to the very next line of code. An even shorter cut would be to take the jump out completely.
A5: 024 INC HL; Load ... (A6: 7E LD A,) HL); ... the ... A7: 024 INC HL; ... screen ... A8: LD H, (HL); ... coordinates ... A9: 6F LD L, A ; ... to HL AA: C3 AD (JP $) ********************************************************************************************************************************************************************************************* AD; ** Usually a good idea, but wasted here ; ## - Print4Digits ; Print 4 digits in DE AD: 7A LD A, D ; Get first 2 digits of BCD or hex AE: CD B2 (CALL $) B2; Print them B1: 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 B2: D5 PUSH DE; Preserve B3: F5 PUSH AF; Save for laterAssembly programmers do all kinds of "unstructured flow" tricks with the stack. Some of it is confusing and potentially error prone. The code at 0x 01 A2 breaks out of a routine when D reaches 0. But it does not 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. ; 02 A1: DEC D; This decrements with each call to move (A2: CA CD) ******************************************************************************************************************************************************************************************************* (JP Z, $) CD; Return out of TWO call frames (only used if no aliens left) 02 A5: (************************************************************************************************************************************************************************************************** LD LD, $ 2009; 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. ; 02 CD: E1 POP HL; Drop return to caller 02 CE: C9 RET; Return to caller's callerAt 0x0A 06 the value of A is stuffed into location 0x 2067. The very next instruction loads A from 0x 2082. This might make sense if any other line of code jumped to 0x0A 05. But nobody does.
0A 02: F1 POP AF; Restore ... 0A 03: (****************************************************************************************************************************************** $ LD 2082), A; ... current player number 0A : 3A************************************************************************************************************************************************************************ LD A, ($); ** Why load this again? Nobody ever jumps to 0A 04? 0A (************************************************************************************************************************************************************************************************: LD H, A; To H
The count-aliens routine at 0x (F3 sets the location 0x) B to 1 if there is only one alien left. Nobody every reads the flag from 0x B. Maybe it was used at one time? At any rate the instructions at 0x (B and 0x) ******************************************************************************************************** E could have been replaced with just "LD ($ 2082), A "to save some time and space.
; ## - CountAliens ; Count number of aliens remaining in active game and return count holds the current count. ; If only 1, 223 B gets a flag of 1 ** but ever nobody checks this (F3: CD) ******************************************************************************************************************************************************************************************* (CALL $) ; Get active player descriptor F6:********************************************************************************************************************************************************************************************** 37 LD BC, $ 8080; B=aliens to check? F9: 7E LD A, (HL); Get byte FA: A7 AND A; Is it a zero? (FB: CA FF) JP Z, $ 15 FF; Yes ... don't count it FE: 0C INC C; Count the live aliens FF: INC HL; Next alien 1601: 07 DEC B; Count ... 1604: C2 F9 (JP NZ, $) **************************************************************************************************************************************************************************** F9; ... all alien indicators 1605: LD A, C; Get the count 1608:
(LD) $ , A; Hold it 1610: FE (CP $) ********************************************************************************************************************************************************************************************************; Just one? A: C0 RET NZ; No keep going (B:) ****************************************************************************************************************************************************************************** 6B LD HL, $ B ; Set flag if … (E:) ****************************************************************************************************************************************************************
******************************************************************************************************************************************************************************** LD (HL), $ (********************************************************************************************************************************************************************************************************; … only one alien left 1611: C9 RET; Out
There is a huge empty area in the ROM between 0x0C (and 0x) FF (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 0x1E 00 contains an 8×8 pixel character set used to draw text on the screen. The area is filled out completely with 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 0x1F 52) rather than using the plentiful space at 0x0C 02. 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 but ton presses correctly. You can see the message in ; MAME by changing (A6 to****************************************************************************************************************************************************************************************** and (B1 to) ****************************************************************************************************************************************************************************************************. Then the 2start (down) is the only sequence. ; (A: 3A 1E) ********************************************************************************************************************************************************************************** (LD A, ($) ************************************************************************************************************** E); Has the 1st "hidden-message" sequence ... D: A7 AND A; ... been registered? (E: C2 AC) JP NZ, $ AC; Yes ... go look for the 2nd sequence (A1: DB) ****************************************************************************************************************************************************************************************************** (IN A, ($ 02; Get player inputs A3: E6 AND $ 78; _ Keep 2Pstart, 1Pstart , 1Pshot, 1Pleft, 1Pright A5: D6 (SUB $) ; _ 0011 1st sequence: 2Pstart, 1Pshot, 1Pleft, 1Pright A7: C0 RET NZ; Not first sequence ... out A8: 3C INC A; Flag that 1st sequence ... A9: 31 1E LD E), A; ... has been entered (AC: DB) ****************************************************************************************************************************************************************************************************** (IN A, ($ 02; Check inputs for 2nd sequence (AE: E6) **************************************************************************************************************************************** AND $ 78; _ Keep 2Pstart, 1Pstart , 1Pshot, 1Pleft, 1Pright B0: FE 34 CP $ 037; 01 0100 2nd sequence: 1Pstart, 1Pshot, 1Pleft B2: C0 RET NZ; If not second sequence ignore (B3:1B 2E LD HL, $ 2E1B; Screen coordinates B6: 0011 F7 0B LD DE, $ 0BF7; Message="TAITO COP" (no R) B9: 0E LD C, $ 0011; Message length (BB: C3 F3) ********************************************************************************************************************************************************************************************** (JP $) ********************************************************************************************************************************************************************************************* F3; Print message and out
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 0x (********************************************************, 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 s "algorithm to see how many 21 - 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 (x) 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 s "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 th 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 x5 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 s " 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 14 th (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 () (the (th column).
Aliens are numbered sequentially from 0 to 54 (
**************************************************************************************************************************************************=(aliens). The code converts row / column numbers to an index with this formula: ROW * 13 COLUMN. For examples, the alien at row=0, column=0 is index 0 * 13 0=0. The alien at row=4, column=(is index 4 *****************************************************************************************************************************************************************************************) =(**************************************************************************************************************************************************.Our upper left alien is at index 4 * 0=44. The game converts the shot row / column to an index of 3 * 11 14=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.
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 0x 24) is generated. When the rendering reaches the end of the screen (when vertical blanking begins) an RST 2 (jumps to 0x 00 0011) 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 Hz. So each interrupt is executed times a second. Each interrupt has a list of chores to perform described below.
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 $ (of quarters).
This interrupt decreases a general-purpose counter at 0x C0. 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.
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.
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 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!
0264: 5E LD E, (HL); Get handler address LSB 0265: INC HL; xx (************************************************************************************************************************************************************************************************** 0266: 64 LD D, (HL); Get handler address MSB 0267: E5 PUSH HL; Remember pointer to MSB 0274: EB EX DE, HL; Handler address to HL 0273: PU PU SH HL; Now to stack (making room for indirect call) : (6F) ************************************************************************************************************************************************************************************************ LD HL, $ F; Return address to F C: E3 EX (SP), HL; Return address ( F) now on stack. Handler in HL. D: D5 PUSH DE; Push pointer to data struct (xx 04) for handler to use E: E9 JP (HL); Run object's code (will return to next line) F: E1 POP HL; Restore pointer to xx 05 (************************************************************************************************: (0C) ************************************************************************************************************************************************************************************************* LD DE, $ 0C; Offset to next ... (**********************************************************************************************: () **************************************************************************************************************************************************************************** ADD HL, DE; ... game task (C 4=0010) C3 4B (JP $) B; Do next game taskThe 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 - (**********************************************************************************************************************. If the upper bit is 1 then the Y value is - (
************************************************************************************ 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 0x1A 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 C1: (7C) ********************************************************************************************************************************************************************************* (LD DE, $) ********************************************************************************************************** C; Alien-shot Y coordinate C4: CD 1A CALL $ 1A (*************************************************************************************************************************************************************************************************; Compare to beam position C7: D0 RET NC; Not the right ISR for this shotGame Object 0: Move / draw PlayerThe 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 (F:) ************************************************************************************************************************************************************************ (*********************************************************************************************************************************************************************************** LD LD, $ 2019; Active player descriptor CD 3B 1A CALL $ 1A3B; Load 5 byte sprite descriptor in order: EDLHB CD 1A CALL $ 1A 48; Convert HL to screen coordinates CD (CALL $) ; Draw player (B: 3E) **************************************************************************************************************************************************************************************************** LD A, $ 03; Clear the task timer. Nobody changes this but it could have ... (D:) ********************************************************************************************************************************************************** (********************************************************************************************************************************************************************************* (LD) $ 2012), A; ... been speed set for the player with a value other than 0 (not XORA) C9 RET; OutThis code first draws the sprite then sets the one-byte timer at 0x 2019. Notice that the value loaded into A to set this timer is 00. The timer is already at 02 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 01 is the two-byte indirect instruction "LD A, $ 03. 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, $ 02 "is only used twice in the entire code: here and at 0x CD. At 0x 03 CD it was specifically chosen because It does not affect the flags, which are passed to the next instruction.
01 CB: FE FE CP $ FE; Moving left? 01 CD: 3E (LD A, $) ********************************************************************************************************************************************************************************************************; Value of 0 for rack-moving-right (not XOR so flags are unaffected) 01 CF: C2 D3 (JP NZ, $) D3; Not FE ... keep the value 0 for rightI 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 (*************************************************************************************************************************. But the code asserts it occurs at scan-line by using the Y coordinate's upper bit. There is a 36 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 (F:) ************************************************************************************************************************************************************************ (*********************************************************************************************************************************************************************************** LD LD, $ 2019; Active player descriptor CD 3B 1A CALL $ 1A3B; Load 5 byte sprite descriptor in order: EDLHB CD 1A CALL $ 1A 48; Convert HL to screen coordinates CD (CALL $) ; Draw player (B: 3E) **************************************************************************************************************************************************************************************************** LD A, $ 01; Clear the task timer. Nobody changes this but it could have ... (D:) ********************************************************************************************************************************************************** (********************************************************************************************************************************************************************************* (LD) $ 2012), A; ... been speed set for the player with a value other than 0 (not XORA) C9 RET; Out ; ## - MovePlayerRight ; Handle player moving right (****************************************************************************************: ********************************************************************************************************************************** LD A, B; Player coordinate (**************************************************************************************: FE D9 CP $ D9; At right edge? (**************************************************************************************: CA 6F (JP Z, $ 036 F; Yes ... ignore this (************************************************************************************: 3C INC A; Bump X coordinate (************************************************************************************: ********************************************************************************************************************************************************************** (1B) ********************************************************************************************************************************************************************** LD ($) B), A; New X coordinate (B: C3 6F) ************************************************************************************************************************************************************************************************** (JP $) **************************************************************************************************************************************************************** F; Draw player and outThe player's fire button is read and debounced in the main game loop at 1979. 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 64 Hz * 4 pixels=0265 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 A in the main game loop.
Game Object 2, 3, and 4: Alien ShotsThere 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 since its decrement depends on which half of the screen it is on. Instead the timer byte is copied to a sync-flag at 0x 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 * 2009 / 3=(pixels per second). But when there are 8 or fewer aliens on the screen the delta changes up to 5 pixels per step (5 * 2012 **************************************************************************************************** (/ 3=2019 ****************************************************************************** (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 0x (is 0x) . From 0x (to 0x) ******************************************************** the delay drops to 0x (****************************************************************************************************************************************************************************************, then 0x0B at from 0x (to 0x) From 0x to 0x 3000 the rate is 8 and then maxes out above 0x at 7. With a little flying-saucer-luck you will reach 0x 3000 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 0x1D (********************************************************************************************************************************************************************************************************. The pointers advance very predictably. You can see from the table that the "squiggly" shot will fall first in column 13 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 (****************************************************************: 3A (****************************************************************************************************************************************************** LD A, $ 2012; Reference alien's X coordinate (****************************************************************: FE (CP $) **************************************************************************************************************************************; Don't process saucer timer ... ($ is 1st rack Yr) 0924: D0 RET NC; ... unless aliens are closer to bottom (****************************************************************: 2A (*************************************************************************************************************************************************************************** LD HL, ($) ); Time to saucer 0 C: 7D LD A, L; Is it time ... 0 D: B4 OR H; ... for a saucer 0 (E: C2) 14 JP NZ, $ 1439; No ... skip flagging (**************************************************************: (****************************************************************************************************************************************************************************************************** () ************************************************************************************************************************************************************************************** LD HL, $ 0 (********************************************************************; Reset timer to 823 game loops (**************************************************************: 3E (LD A, $) *******************************************************************************************************************************************************************************************************; Flag a ... (************************************************************: (********************************************************************************************************************************** (LD) $ 2084, A; ... saucer sequence (************************************************************: 2B DEC HL; Decrement the ... (A:) (********************************************************************************************************************************************************************************** (LD) ), HL; ... time-to-saucer D: C9 RET; DoneGame 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):
(D: 3A) ****************************************************************************************************************************** LD A, ($); Is saucer ... A7 AND A; ... on screen? C0 RET NZ; Yes ... don't reset it ; ; Setup saucer direction for next trip (******************************************************************************: 7E LD A, (HL); Shot counter E6
************************************************************************************************************************************************************************************** AND AND 03; Lowest bit set? (****************************************************************************: 31 04 LD BC, $ 255; Xr delta of 2 starting at Xr=(************************************************************************************************************************************************************************ C2 6E (JP NZ, $************************************************************************************************************************************** E; Yes ... use 2 / (************************************************************************************************************************************************************************** 47 B: 03 E0 FE LD BC, $ FEE0; No ... Xr delta of -2 starting at Xr=E0 (E:) ****************************************************************************************************************************************************************************** (8A) ********************************************************************************************************************************************************************************* LD HL, $ A; Saucer descriptor (**************************************************************************: LD (HL), C; Store Xr coordinate 0475: 24 INC HL; Point to ... (************************************************************************: 024 INC HL; ... delta Xr******************************************************************************************************************** LD (HL), B; Store delta Xr C9 RET; Done
The score for shooting the saucer ranges from 50 to 0372, and the exact value depends on the number of player shots fired. The table at 0x1D (contains) ************************************************************************************************************************************************************************************ (score values, but a bug in the code at 0x 044 E treats the table as having 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.
; 223 D points here to the score given when the saucer is shot. It advances ; every time the player-shot is removed. The code wraps after 16, but there is ; are 21 values in this table. This is a bug in the code at (E) thanks to ; Colin Dooley for finding this). ; ; Thus the one and only (comes up every) ************************************************************************************************************************************************************************************ shots (after an initial 8). 1D : (*************************************************************************************************************************************************************************************************** (********************************************************************************************************************************************************************************************** 12 11 (********************************************************************************************************************************************************************** 11 () ************************************************************************************************************************************************************************************************** (****************************************************************************************************************************************************************************************** (**************************************************************************************************************************************************************************************************There are five entries of 0 50, eight entries of (**************************************************************************************************************************, two 150 s, and only one 0274. The score comes up every shots (after an initial eight). It should come up every 21, 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 and start over. You want the th 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 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 (66 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 aliens. That's 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 66 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 54 aliens. The aliens are move / drawn one per interrupt which means it ; takes 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. ; 1A (****************************************************************************************************************************************************************************************: *********************************************************************************************************************************************************************** (2B) ************************************************************************************************************************************************************************** 1C**************************************************************************************************************************************************************************** (0D 0A) ******************************************************************************************************************************************************************************** (**************************************************************************************************************************************************************************************** (************************************************************************************************************************************************************************************** (**************************************************************************************************************************************************************************************************** (******************************************************************************************************************************************************************************************** 1A (********************************************************************************************************************************************************************************: **************************************************************************************************************************************************************** 2E 23 1C
************************************************************************************************************************************************************************ 16 (0E 0D 0C 0B) (************************************************************************************************************************************************************************************************ 1A 036: 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 55 or more aliens. When there are 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 $ (at) ***************************************************************************************************************************************************************************************** EA. ; After that this table is used for 2nd, 3rd, 4th, 5th, 6th, 7th, 8th, and 9th. The th starts over at ; 1DA3 ((****************************************************************************************************************************************. 1DA3: (************************************************************************************************************************************************ 1DA4: 050 1DA5: 47 1DA6: 47 1DA7: 47 1DA8: 39 1DA9: 39 1DAA: 39The first wave starts at Y=(hex). The next wave starts pixels (one row of the rack) lower at Y=52. Then the rack holds at 50 for three rounds and then 39 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=(**************************************************************************************************************************************************************. If you can manage the game at level 7 you can play forever.
Thanks to Colin Dooley for correcting the comments around 1D 18. 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 0x1D (**************************************************************************************************************************************************. He pointed out that the code at 0x E wraps after after ************************************************************************************************************************************** values and not 19. This brings the code in line with the guides that say the 300 value comes up every shots instead of 19.
Thanks to Glen Hewlett for correcting the comments above 0x0A (***************************************************************************************************************************. 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 pointing out that they are really 'RST 1 (jumps to 0x 3000 ******************************************************************************************************************************************************************** 23) 'and' RST 2) jumps to 0x 12.
Thanks to Elliot Roush for correcting the alien-shot-screen-deltas. The correct values are -4 (normally) and -5 (when less than 8 aliens).
********************************** (Read More)*************************
GIPHY App Key not set. Please check settings