[HN Gopher] Space Invaders
___________________________________________________________________
Space Invaders
Author : Tomte
Score : 77 points
Date : 2025-03-12 10:46 UTC (12 hours ago)
(HTM) web link (www.computerarcheology.com)
(TXT) w3m dump (www.computerarcheology.com)
| 383toast wrote:
| such a classic game
| plg wrote:
| how do I play this
| 4ndrewl wrote:
| with joy in your heart at the memory of better, simpler times.
| flohofwoe wrote:
| > 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.
|
| That's common for machine code written without an assembler but
| typed directly into a hex monitor (don't know if Invaders was
| developed that way though). You kept a couple of nops in
| 'reserve' - usually after branches and returns - so that fixes
| can be applied without having to move the rest of the code around
| (which would mean retyping everything).
| raq2185 wrote:
| Even using an assembler, (which we did most of the time), we
| would leave a pool at the end of each PROM (and they were PROMs
| with a 6 week lead time) so we could patch a bug and only have
| to change one PROM and not the whole set.
| JohnFen wrote:
| And about the ones in the code flow, it was also pretty common
| practice in those days to use NOPs as time delays.
| nomel wrote:
| It's required whenever your clock cycle time is near your
| timing requirements. Not so much a problem with multi GHz
| microcontrollers, but still needed for cheap ones.
|
| Manually add up all cycles for each instruction in each
| branch, then pad the shorter with noop to make them the same.
| Repeat for each code path, and cry when you need to make a
| change.
| JohnFen wrote:
| Yep, it's a practice I still engage in with several of my
| microcontroller-based projects.
| ndiddy wrote:
| Space Invaders was written by hand, as professional development
| tools cost way too much at that point. This interview contains
| a picture of a couple of the pages from the Space Invaders
| source code notebook. https://shmuplations.com/spaceinvaders/
| Jeema101 wrote:
| _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'm wondering what the mechanism is here to avoid bus contention
| between the video circuit and the CPU both accessing the VRAM at
| the same time.
|
| Might be evident from studying the schematic I would suppose...
| pjc50 wrote:
| Hardware sprite systems such as the Atari 2600 did not have any
| VRAM.
|
| The 2600 had 128 _bytes_ of RAM. It supported a small number of
| fixed sprites. These were implemented by setting the X and Y
| coordinates in registers; as the scan-out of pixels passed that
| point, it would switch to drawing in the sprite color if a
| pixel was present at the bit position in the sprite.
|
| It was possible to count how far down the screen the scan-out
| had got and re-use a sprite that had already been used above,
| to get more than the allowed number of sprites.
|
| See the book _Racing the beam_ for a lot more detail.
|
| Edit: however this WAS a VRAM system. Seems to have added a
| dedicated shift helper but is still using blitting to VRAM. See
| "game timing" section of OP page.
| Someone wrote:
| https://retrocomputing.stackexchange.com/a/11456:
|
| _"Space Invaders uses a simple display format where bytes are
| read from memory in order via an address counter, and shifted
| out via a shift register. Timing is controlled by discrete
| hardware.
|
| The video hardware has priority over the CPU. When it needs to
| read a byte it asserts the 8080's READY signal, giving it
| exclusive access to the memory bus. This can be seen on the
| schematic
| (https://www.robotron-2084.co.uk/taito/documents/space-
| invade...) at 5F.
|
| This technique has the advantage of the 8080 not having to be
| synchronized with the display hardware at all."_
| lordfrito wrote:
| RAM was too expensive to have two full frame buffers with page
| flipping. So they resorted to timing tricks.
|
| Many times the RAM was dual ported (CPU writes while video
| hardware reads).
|
| Other times they'd do clever clock tricks... for example, using
| 10 MHz capable RAM, generate a 10 MHz clock, and divide it down
| to two different 5 Mhz. One 5MHz clock is sync'd to the rising
| edge of 10 MHz, the other is sync'd to the falling edge. Sort
| of "interleaving" the two 5 MHz clocks. Total clock rate is 10
| MHz, but the two 5MHz hardware circuits are out of phase and
| don't interfere with each other.
|
| Later on, as RAM prices fell and double buffered images became
| economically possible in arcade machines, true page flipping
| started getting used, they would simply isolate the CPU and
| video buses from each other as the frame buffer was flipped. I
| know this is how things worked on I, Robot (1984)... this
| technique could have been used earlier but not much as not many
| games had real frame buffers at the time.
| cushychicken wrote:
| I always use ascii_invaders, an ncurses based Space Invaders
| clone, as my first test package on a new buildroot system.
|
| Here's how to add it, if you're curious. (Blog is from a job site
| I run.)
|
| https://www.firmwarejobs.com/blog/buildroot-by-example-pt-1-...
| flyinghamster wrote:
| There was a vector-based cabinet predating Space Invaders:
| Cinematronics' Space Wars (1977), which used custom hardware to
| re-implement the original PDP-1 Spacewar! game. It was strictly a
| two-player game; you couldn't play against the computer.
| Cinematronics would use the platform for later games like Star
| Castle and Tail Gunner, also vector-based.
| renewedrebecca wrote:
| I _loved_ Star Castle.
| susam wrote:
| This is the game that originally inspired me to computer
| programming.
|
| I first stumbled upon this game in the 1990s in my school's
| computer laboratory. I wanted to develop something similar on my
| own but the little GW-BASIC programming I knew and the very
| limited access to computers (<= 3 hours per month) I had wasn't
| sufficient to take on an endeavour like this. I did write a few
| simple text adventure games and a BRICKS clone too. But writing
| an invaders-like game was too challenging for me back then.
|
| Finally, three years ago, I sat down one afternoon and fulfilled
| that childhood dream of mine.
|
| Here's the result: https://susam.net/invaders.html
|
| It's a single HTML page with no external dependencies, so you are
| very welcome to "View Source".
| TheAmazingRace wrote:
| The background sound feels like a spacey jingle. I like it.
| It's mesmerizing lol.
| susam wrote:
| Thanks! Yes, the background music too is inspired by the
| four-note loop of the original Space Invaders. Here's the
| source code for it: https://github.com/susam/invaders/blob/0.
| 9.0/invaders.html#L...
| Frederation wrote:
| Very nice. I have a sim. story but about Donkey Kong on the
| C64.
| dylan604 wrote:
| I had the same idea as an "over the weekend" project. I had the
| sprites moving (with each invader's "arms" animated while the
| grid moved) and could control the player. Clearly the "over the
| weekend" was too ambitious, and I stopped before ever trying to
| add fire/bullets/collision/etc. So I essentially got no where,
| but effectively killed the weekend while spending $0 while
| avoided doing other things that would have definitely cost >$0.
|
| So congrats on sticking to it to complete yours
| thih9 wrote:
| New titles are still being produced by Taito. The corporation is
| a subsidiary of Square Enix since 2006, but I still find it
| impressive. E.g.:
|
| > Also joining Apple Arcade on April 3 are Space Invaders
| Infinity Gene Evolve, the newest entry in the influential series
| by TAITO CORPORATION
|
| https://www.apple.com/newsroom/2025/03/apple-arcade-launches...
|
| https://apps.apple.com/us/app/spaceinvaders-infinitygene-evo...
| ferguess_k wrote:
| The hardware part fascinates me more. Has anyone fancied building
| a X-bit game console drawing schematics?
|
| I guess there are two ways to do it. One is to use an FPGA board,
| but you would need to build a soft core. The other is to buy
| physical components (CPU, clocks, resistors, capacitors,
| ROMs/RAMs, etc.) and build a prototype on a few bread boards, in
| Ben Eater's style, but you need to purchase a lot of components.
|
| I wouldn't go down the emulation route because it is less
| interesting.
|
| The more I think about it, the more I think it's fun project. One
| gets to learn so much with it. I have always wondered how the
| Japanese built those little machines that made -- and still make
| the world gone crazy, but all those interviews with
| Nintendo/Sony/Sega people were mostly focused on game directors,
| producers, designers and artists. There were not even enough with
| programmers, let alone hardware designers. But I could be wrong.
| Maybe I just didn't look hard enough or need to learn Japanese.
| TheOtherHobbes wrote:
| Building a system around a vintage CPU is pretty
| straightforward, especially if you keep it simple with static
| memory.
|
| Emulation with an FPGA is arguably harder.
|
| Hardest of all is copying the earlier video games where
| everything ran on discrete logic - often extremely clever.
|
| Even something like Pong is an interesting challenge.
| kjs3 wrote:
| _Hardest of all is copying the earlier video games_
|
| On the other hand, many of the old games are exhaustively
| documented and built for component-level repair. A trade-off,
| I suppose.
| thaumasiotes wrote:
| > Hardest of all is copying the earlier video games where
| everything ran on discrete logic
|
| What does this mean? I'm not aware of a big pickup in analog
| computing.
| musictubes wrote:
| And of course Space Invaders was programmed inside of a Dwarf
| Fortress game. It's simplified of course and not exactly real
| time lol. Wonder what it would take to emulate the full version
| inside of DF.
|
| https://youtu.be/j2cMHwo3nAU
| PaulHoule wrote:
| Pinball games usually have two tilt mechanisms: (1) to prevent
| you from moving the playfield as a whole, and (2) to prevent you
| from smashing the coin mechanism in front of the cabinet because
| otherwise you could get free plays by smashing the coin mech.
|
| Coin-op video games have (2) because they use the same coin
| mechanisms as pinball games and have the same vulnerability.
|
| I used to play pinball seriously [1][2] and frequently found
| machines where the type 1 tilt was insensitive or not working at
| all, whereas I never found a machine where the type 2 tilt didn't
| work. The type 2 tilt still gives you trouble when using certain
| tactics to rescue the ball from the drain, such as giving a hard
| impact to the left or right front of the table, though pulling
| the table quickly a few inches forward works on a machine with a
| dead type 1 tilt.
|
| [1] get a score two orders of magnitude higher than most people
| would think possible, leave 30 credits on the machine
|
| [2] get threatened that they'd kick me out of the game room as an
| undergraduate at a state school, never get bothered as a grad
| student at an Ivy League school
| joezydeco wrote:
| The "plumb-bob" tilt for [1] is dependent on a conical weight
| hanging on a rod, surrounded by a brass ring. Raising the
| weight higher or lower makes the tilt more or less sensitive by
| changing the distance between the cone and ring. Many operators
| adjust this and fail to fasten it tightly enough and the cone
| falls into the cabinet.
|
| The "slam tilt" switch for [2] is a leaf switch with a small
| intertial counterweight on one of the leafs and rarely falls
| apart.
|
| Funny enough, modern slot machines still call a tamper or
| intrusion event a "tilt".
| ChrisMarshallNY wrote:
| The theme song: https://www.youtube.com/watch?v=qg_wuKLqV8g
___________________________________________________________________
(page generated 2025-03-12 23:01 UTC)