30

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.

Omar and Lorraine
  • 38,883
  • 14
  • 134
  • 274

3 Answers3

35

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 :))

Omar and Lorraine
  • 38,883
  • 14
  • 134
  • 274
Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • Does Racing the Beam talk about this game in particular? – Omar and Lorraine Sep 07 '18 at 13:52
  • 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 07 '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 07 '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 07 '18 at 14:30
  • 6
    Damb. And I thought .Net was annoying. – Maury Markowitz Sep 07 '18 at 14:30
  • @Raffzahn That means that for each alien, there's one code path if it's there and one code path if it's not, but! beq and friends take a different number of cycles in these two cases! could you elaborate? – Omar and Lorraine Sep 07 '18 at 14:53
  • @Wilson well, you could always compensate for that with a nop – Maya Sep 07 '18 at 17:17
  • 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 08 '18 at 01:16
  • 1
    @Raffzahn: A better technique is to set up six zero-page pointers, one for each alien, to the appropriate shape data. Then lda (ptr0),y / sta GRP0 / lda (ptr1),y / sta GRP1 etc. will take 8 cycles (24 pixels) per alien. Without exploiting VDELPx or the X register, placing the sprites so the last pixel of the first alien is output just as the third store hits will cause the store for the last alien to arrive precisely when it's needed, but will require the sprites to move in three-pixel increments. – supercat Feb 26 '20 at 21:46
  • 1
    @Raffzahn: If one pre-loads the shape for the last sprite and copies it into X before the first alien is displayed, and then uses STX rather than an LDA/STA pair, that will add eight more pixels worth of leeway to the timing (the limiting factor would then be the store for the second-to-last sprite). – supercat Feb 26 '20 at 21:49
17

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.

WimC
  • 1,086
  • 7
  • 9
  • 1
    This answer needs more upvotes – Omar and Lorraine May 24 '21 at 21:32
  • I think the quote confuses HMOVE and RESPx, and Galaxian definitely uses repeated RESPX though I doubt Space Invaders would do so. – supercat May 24 '23 at 21:18
  • Fun fact I remember reading somewhere: this also meant that the fewer there were left, the faster they would update/move, so the game sped up the more successful the player was - and this was an unintentional game mechanic that was well liked and later was added deliberately to games. – htmlcoderexe Mar 19 '24 at 14:29
6

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.

thrust26
  • 61
  • 1
  • 2
  • 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? – Omar and Lorraine May 19 '21 at 19:55
  • 2
    @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 '21 at 21:22
  • 3
    Welcome to Retrocomputing! Can you improve this answer by providing supporting evidence, such as a quote or link to a source? – DrSheldon May 20 '21 at 04: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 '21 at 20:16
  • Please take the [tour] to better understand how SE works. The point of Stack Exchange answers is that they are self-contained and (where ever possible) backed up with references and examples, and not that they point elsewhere to find the answer. Thanks. – Greenonline Mar 18 '24 at 23:01