27

The Atari 2600 has two 8-bit wide player sprites, and it appears to be these sprites which are used to draw these aliens.

Space invaders in the Atari 2600

There are a few different ways to produce many copies of one sprite; controlled by nusiz0 and nusiz1. If you don't want the sprite stretched, then there's a choice between:

  • one copy of the sprite
  • two copies of the sprite, close together, far apart, or medium.
  • three copies of the sprite, close together, or medium

I suppose it's possible they used player 1 and player 2, both together, three copies of each, to get the six aliens on a row. But what about when an alien gets shot down? Some kind of routine needs to work out how to configure each sprite, with number of copies and distance between changing every time. Has that ever been disassembled? I'd be interested to figure it out.

1
  • 1
    Galaxian does one better for the record: seven on a line rather than six. – Tommy Sep 11 '18 at 16:22
9

This answer elaborates a bit on the answers by @Raffzahn and @thrust26. The answer by @thrust26 is correct. The alien sprites are not positioned by repeated RESP0 or RESP1 triggers as the code below shows. The book "Racing the beam" mentions the following in a section about sprites:

Rick Maurer, the programmer for the VCS port of Space Invaders, discovered that strobing HMOVE while a line was being drawn would reposition objects immediately.

This suggests that this technique was used in Space Invaders. However, the only HMOVE triggers that appear in the code occur directly after a WSYNC, so definitely not multiple times per scan line.

The aliens are drawn using the two player sprites. Both NUSIZ0 and NUSIZ1 are set to $06 which means single pixel resolution and three copies each at a medium spacing. The copies of both sprites interlace to form a row of six in a pattern "A B A B A B". The appearance of each "copy" is changed by loading different sprite patterns in the GRP0 and GRP1 registers by carefully timed code:

           lda  ($f8),y   ; Load pattern for alien six in X.
           tax  
           lda  ($ee),y   ; Load pattern for alien one in GRP0
           sta  GRP0
           lda  ($f0),y   ; Load pattern for alien two in GRP1
           sta  GRP1
           lda  ($f2),y   ; Update pattern for alien three in GRP0
           sta  GRP0
           lda  ($f4),y   ; Update pattern for alien four in GRP1
           sta  GRP1
           lda  ($f6),y   ; Update pattern for alien five in GRP0
           sta  GRP0
           txa            ; Update pattern for alien six in GRP1
           sta  GRP1

The Y register counts down from 9 to 0 (inclusive) to draw ten scan lines for each alien in a row. An alien pattern can easily be modified by adjusting the low byte of any of the pointers in $ee to $f8. Interestingly, these scan lines are drawn without any intermediate WSYNC trigger, purely based on careful instruction timing.

1
  • 1
    This answer needs more upvotes – OmarL May 24 at 21:32
34

It's rather simple. Neither the multiple sprite mode, nor any secret trick is used.

The TIA doesn't have any directly-accessible register for storing a sprite position ahead of time. Sprites are drawn when they are enabled on the actual line (Y coordinate) and whenever RESPx is triggered (X coordinate). To display the 6 aliens, RESPx gets triggered 6 successive times. To not draw an alien the corresponding player is just cleared for that activation — or, during an explosion, replaced by the appropriate sprite.


You really want to read the by now classic book Racing the Beam. A must-read for anyone interested in TIA workings — and way less work than crawling through disassemblies and guessing what happened :))

10
  • 6
    @Wilson It goes into the specific details of several classics, like Pit-Fall, Pac-Man, Asteroids, Space Invaiders and so on. It's about the machine and how it was done in a whole sense, targeted at a broader audience, not just coders - but don't underestimate the detail, it's still a challenging read. – Raffzahn Sep 7 '18 at 13:56
  • 1
    How did they do the timing so the register is set/cleared at the right times? Did they have to time the instruction stream from start-of-line? – Maury Markowitz Sep 7 '18 at 14:26
  • 4
    @MauryMarkowitz Jup, exactly. A CPU clock is 3 pixel clocks. So everything is caclulated from the start of teh line. The mechanic is rather simple. When the work of a line is done, one TIA register is accessed, which outs the CPU into hold until the start of the next line, resulting in cycle exact synchronisation. Easy to count from there on. Well, there are a lot of fine print to think about, byut basicy that's it. – Raffzahn Sep 7 '18 at 14:30
  • 5
    Damb. And I thought .Net was annoying. – Maury Markowitz Sep 7 '18 at 14:30
  • 4
    @Wilson NieDzejkob's solution may work, except that a NOP is two clocks. Better to prepare 6 memory locations with the sprite data (Alien, Explosion or nothing) and then move them into the register during the line drawn. A good place to store such serial accessed data is the stack, so the drawing can be done by repeating PLA; STA GRP0; STA RESP0 six times. That adds up to 10 cycles or 30 pixels each. With double with sprites (NUSIZ0=5), it will exactly look like above picture, with aliens (16px) spaced almost an aliens width (14px) apart, doesn't it? TIA programing is fun. – Raffzahn Sep 8 '18 at 1:16
4

Late to the party, but I think wrong information should be corrected.

The Space Invader sprites are simply displayed using 3 copies of each of the two sprites. The RESPx trick was first shown in Galaxian three years later.

4
  • So how does the program tickle nusiz0 and nusiz1 to remove a shot-down alien? Or, how can there be 5 aliens and one explosion on a scanline without using the RESPx trick? – OmarL May 19 at 19:55
  • 1
    @OmarL: Every pixel of each sprite will be shown with whatever data happens to be in the corresponding pixel of the sprite data register at the moment the pixel is being output. Space Invaders displays six different sprite shapes in essentially the same way as the Blackjack cartridge does, except that the former cartridge places the sprites at fixed locations and thus performs the GRPx stores at fixed locations within each line. – supercat May 19 at 21:22
  • 2
    Welcome to Retrocomputing! Can you improve this answer by providing supporting evidence, such as a quote or link to a source? – DrSheldon May 20 at 4:05
  • 1
    You can easily check yourself in Stella. Just enter the debugger and break inside the kernel. Then you can see the source code. – thrust26 May 20 at 20:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.