Racing the Beam: The Atari Video Computer System

[Disco Scottie]

Just finished reading it tonight. Went by too quickly! I would love to see an ongoing series of books telling the story of how each and every 2600 cart was made, a "Behind The Code" if you will. The farthest I ever got programming was some simple BASIC on the 800, but I still enjoy reading about the tech side of things. You guys did a great job putting this together, and I look forward to your future efforts.

 

And may I say to Joe Decuir, thank you for helping create a device that truly changed my life. My fondest childhood memories are of the first night at home in 1981 with my very own Video Computer System, playing Space Invaders and Missile Command until the wee hours of the morning. I was all of 10 at the time, and it was the beginning of my love affair with technology. Had it not been for your team of hardware designers, I imagine many of us would have traveled very different roads in our lives. Thank you from the bottom of my heart.

[VideoFever1982]

Just finished reading it tonight. Went by too quickly! I would love to see an ongoing series of books telling the story of how each and every 2600 cart was made, a "Behind The Code" if you will.

That would be nice but WOW! over 1000 books? I picked this up recently but haven't had a chance to read it yet.

[ClausB]

Very interesting book. A little thin, so I'm reading it again.

 

The excerpt below seems to be in error. I looked at the Space Invaders kernel with the Stella debugger and there are not multiple HMOVEs per line. It looks pretty much like a typical six-sprite kernel.

 

Does the technique described below even work? Do any games use it?

Edited August 10, 2009 by ClausB

[+batari]

Very interesting book. A little thin, so I'm reading it again.

 

The excerpt below seems to be in error. I looked at the Space Invaders kernel with the Stella debugger and there are not multiple HMOVEs per line. It looks pretty much like a typical six-sprite kernel.

 

Does the technique described below even work? Do any games use it?

Yes, I think that's an error - there should be no need to reposition the sprites except for a new row of invaders, and that does not need to be done in the middle of a line. Possibly what he was trying to say that there was no need for a full repositioning routine (e.g. divide by 15 loop, RESPx and HMOVE) and instead just do a few subsequent HMOVEs for a few lines to adjust the next row of invaders to the left or right.

 

Possibly, he could have been referring to the explosions, which would probably require multiple GRPx updates with VDEL turned on so the sprites could be changed in the middle of the kernel.

[SeaGtGruff]

Wow, it looks like strobing HMOVE twice in a row will double the movement; three times will triple the movement; etc.-- without increasing the size of the extra blanking. I haven't tried it on a real console yet, but that's what happens in an emulator.

 

I'm thinking this can be used to move a player more than the usual 7 left or 8 right per line. So if you alternate HMP0 and HMP1 between 4 left and 4 right from line to line, and strobe HMOVE twice after WSYNC, you should be able to move the players 8 left and 8 right without using cycle 73 or 74 HMOVEs. And you should be able to move the players 8 right at the same time as moving the missiles 8 left, or things like that.

 

I see definite possibilities!

 

Michael

[Thomas Jentzsch]

Yes, I think that's an error...

Yup.

 

Maybe they are confusing HMOVE with RESPx and Space Invaders with Galaxian here?

[+batari]

Wow, it looks like strobing HMOVE twice in a row will double the movement; three times will triple the movement; etc.-- without increasing the size of the extra blanking. I haven't tried it on a real console yet, but that's what happens in an emulator.

 

I'm thinking this can be used to move a player more than the usual 7 left or 8 right per line. So if you alternate HMP0 and HMP1 between 4 left and 4 right from line to line, and strobe HMOVE twice after WSYNC, you should be able to move the players 8 left and 8 right without using cycle 73 or 74 HMOVEs. And you should be able to move the players 8 right at the same time as moving the missiles 8 left, or things like that.

 

I see definite possibilities!

 

Michael

If I understand the hardware correctly, strobing HMOVE multiple times should not allow you to move further. I expect that what you are seeing is an emulator bug.

[SeaGtGruff]

If I understand the hardware correctly, strobing HMOVE multiple times should not allow you to move further. I expect that what you are seeing is an emulator bug.

Yeah, I'm definitely going to try it on real hardware before I get too excited. But I can't figure out why the book mentions strobing HMOVE repeatedly unless it does *something* interesting-- or unless it was just a typo. I mean, when I first read that quote, I figured they must have meant strobing the RESxx registers repeatedly, not HMOVE.

 

All I know is, if it works on real hardware, I'm probably going to rewrite my bitmap kernel to use it!

 

Michael

[SeaGtGruff]

All I know is, if it works on real hardware, I'm probably going to rewrite my bitmap kernel to use it!

Crud! I haven't tried it on my 2600 yet, but I tried it on my 7800 and it doesn't work. That's a shame, because it would have been really cool if it had worked.

 

Michael

[ClausB]

Maybe they are confusing HMOVE with RESPx and Space Invaders with Galaxian here?

 

I figured they must have meant strobing the RESxx registers repeatedly, not HMOVE.

 

The Space Invaders kernel doesn't use multiple RESPx strobes per scan line either. Does Galaxian?

 

Would that technique work? The Stella doc says strobing RESPx causes the player to redraw in the new position on the next scan line.

[SeaGtGruff]

Maybe they are confusing HMOVE with RESPx and Space Invaders with Galaxian here?

 

I figured they must have meant strobing the RESxx registers repeatedly, not HMOVE.

 

The Space Invaders kernel doesn't use multiple RESPx strobes per scan line either. Does Galaxian?

Yes, it's my understanding that Galaxian does this.

 

Would that technique work? The Stella doc says strobing RESPx causes the player to redraw in the new position on the next scan line.

The Stella doc is mostly correct. If you strobe RESPx on a line, it resets that player's horizontal position right away, but it doesn't restart the drawing process right away-- or something like that-- so the player won't show up until the next scan line (unless RESP0 is strobed during the HBLANK period). But if you've got NUSIZx set to display multiple copies of the player, the additional copies *will* be drawn on the current scan line, even though the main copy won't be.

 

However, if you keep strobing RESPx, the player's position will keep getting reset, but the extra copies might not show up if you're strobing RESPx too soon after the previous RESPx, because the player's position might get reset before the TIA starts to draw the extra copies. So if you want to keep strobing RESPx, the trick is to wait a little bit between each RESPx, to give at least one of the extra copies a chance to be displayed before the next RESPx.

 

The TIA hardware notes by Andrew Towers explain this and other stuff. It's well worth a read, and then a re-read, and then a few dozen more re-reads.

 

Michael

[ClausB]

The TIA hardware notes by Andrew Towers explain this and other stuff. It's well worth a read, and then a re-read, and then a few dozen more re-reads.

Thanks!

[+stephena]

The TIA hardware notes by Andrew Towers explain this and other stuff. It's well worth a read, and then a re-read, and then a few dozen more re-reads.

I can definitely agree with this. I'm probably through my 10th reading, and I still have to go back to it again. Incidentally, this is exactly the part I'm working on in Stella right now; the interaction of RESPx and NUSIZx when these strange 'tricks' are done.

 

Speaking of Stella, does the bug mentioned above (multiple HMOVEs per line doing more movement than it should) happen in the 3.0 alpha release of Stella? And if so, what should the behaviour be? Perhaps ignore all subsequent writes to HMOVE on the same scanline??

[SeaGtGruff]

Speaking of Stella, does the bug mentioned above (multiple HMOVEs per line doing more movement than it should) happen in the 3.0 alpha release of Stella? And if so, what should the behaviour be? Perhaps ignore all subsequent writes to HMOVE on the same scanline??

Yes, the alpha2 pre-release of 3.0 has the bug in it, as does the latest version of z26 (which hasn't been updated in years).

 

I'm not sure what the correct behavior should be regarding multiple HMOVEs on a scanline. I suspect that it has a lot to do with timing, because you can do a cycle 3 HMOVE and a cycle 73 or 74 HMOVE on the same scan line, and both will be performed. That's how my bitmap kernel for batari Basic works. I don't know who first came up with the idea for this trick, but the first time I ever saw it mentioned was in an AtariAge post by supercat (John Payson)-- or it may have been on the Stella mailing list. So as far as I know, John Payson should be credited for thinking up this particular trick.

 

A normal cycle 3 HMOVE (i.e., one performed immediately after WSYNC) can shift a sprite up to 7 color clocks to the left or 8 color clocks to the right. Historically speaking (i.e., dating from back in the heyday of the Atari 2600), the technique referred to as "venetian blinds" uses normal HMOVEs to shift the players 7 color clocks to the left on one line, then 7 color clocks to the right on the next line. (At least, that's my understanding of the traditional "venetian blinds" technique.) This results in players that have "slats," like the slats in venetian blinds-- hence the nickname for this technique.

 

A variation of this is referred to as "flicker blinds," where the players are lined up differently on odd frames versus even frames, and the shifting left and shifting right is done differently on odd lines versus even lines. When the odd frames and even frames are flickered together, the flickering effectively eliminates the slats from the player shapes.

 

The problem is, shifting 7 left and 7 right leaves a 1-pixel gap between some of the columns, and causes a 1-pixel overlap between other columns.

 

On the other hand, a cycle 73 or 74 HMOVE can shift a sprite up to 15 color clocks to the left or 0 color clocks to the right. That means if you do a normal cycle 3 HMOVE at the beginning of a line, you can shift the players 8 pixels to the right on that line. And if you do a cycle 73 or 74 HMOVE at the end of that same line, you can shift the players 8 pixels to the left for the next line. That way, the 1-pixel gap and the 1-pixel overlap are eliminated. (Thank you, John!)

 

The documentation for the TIA says you should wait at least 24 cycles after strobing HMOVE before changing the horizontal motion registers, otherwise "unpredictable" results can occur. I don't know if anyone has ever tried to document these results in detail, but I suspect that the results *will* be predictable if a given motion register is always changed on the same cycle after an HMOVE. Anyway, it may be that multiple strobes to HMOVE must occur at least 24 cycles apart, otherwise the second HMOVE will occur while the first one is still being performed, causing the second one to be ignored-- but that's pure speculation on my part, and it may be utterly wrong. Unfortunately (if the preceding speculation is correct), that would mean if you did a cycle 3 HMOVE, the earliest you could effectively strobe HMOVE again would be a cycle 27 HMOVE-- and a cycle 27 HMOVE won't move the sprites at all, because only HMOVE cycles that occur during the HBLANK period will move the sprites.

 

Paul Slocum put together a document called the "ATARI 2600 ADVANCED PROGRAMMING GUIDE," compiled from information that had been posted by various programmers. It contains an "HMOVE Timing Chart" from Brad Mott that lists (in table form) the results of strobing HMOVE on different cycles. You should be able to find it by searching the Stella mailing list archives, but I'm attaching a copy to this post for your convenience. It also describes the multi-RESPx trick, in a section by Christopher Tumber.

 

Michael

2600_advanced_prog_guide.txt

[+batari]

I take some of what I said back. You might be able to get an extra few pixels of motion out of the sprites by doing two HMOVEs. You will not get twice the movement, however.

 

A cycle 73-74 HMOVE will trigger the motion counters, but the HMOVE blank is disabled because the latch to enable it is cleared about 1-2 cycles later. I believe the cycle 73-74 HMOVE will start moving sprites sooner than a cycle 3 HMOVE. During HBLANK, sprites are moved 0-15 pixels left, at a rate of one pixel every 4 color clocks. If we start with cycle 73-74, we have 15-18 color clocks before the next HMOVE. Assuming motion will start over with the second HMOVE, we might get a few extra pixels of movement. Probably 2 or 3 pixels would be my guess, but I don't know for sure without trying some code.

[diogoandrei]

I found this book to be amazing. It's a nice reading and very insightful. I am actually reading it again.

 

I see that this book belongs to Platform Studies (Platform Studies link). That brings me to ask: when will we have another title? Is there a new book on the way? =)

Edited January 12, 2011 by diogoandrei

[toptenmaterial]

No chapter on E.T. darn.

 

Hee, you know, I really lobbied for an E.T. chapter. I might be the only person around who actually likes the game. Maybe we'll do it for the sequel

I don't think it's as bad as everyone makes it out to be either. I sure as heck played it considerably more than Pac-Man when I was a kid..

 

..Al

I started playing e.t. in earnest for the first time a couple of weeks ago. I must say it's a very ambitious game and not the dud it was made out to be. The overhead view adventure game concept was very novel, just not fluid. The graphics are really good for the VCS. It seems very ahead of it's time, but I think that the gameplay just didn't keep up with the ideas and concept. In this respect, it reminds me quite a bit of Castlevania 2: Simon's Quest on the NES.

[high voltage]

I just finished reading it at work. Excellent read indeed, only complaint I reckon is that the (official licensed) TV-Boy should have deserved a mention, together with the Jakks Joystick and the Flashbacks.

[fiddlepaddle]

I just finished reading it at work. Excellent read indeed, only complaint I reckon is that the (official licensed) TV-Boy should have deserved a mention, together with the Jakks Joystick and the Flashbacks.

They pay you for that?! Can I get a job there?

[high voltage]

I just finished reading it at work. Excellent read indeed, only complaint I reckon is that the (official licensed) TV-Boy should have deserved a mention, together with the Jakks Joystick and the Flashbacks.

They pay you for that?! Can I get a job there?

 

I'm a daywatch in a museum, yes, we're allowed to read books, play video games on handhelds etc....best job ever.

[ibogost]

I found this book to be amazing. It's a nice reading and very insightful. I am actually reading it again.

 

I see that this book belongs to Platform Studies (Platform Studies link). That brings me to ask: when will we have another title? Is there a new book on the way? =)

 

I'm sorry I've been so lax in participating in the forums here. I'm trying to catch up!

 

We've got a Wii book coming next year, and an Amiga book too, and a Dynabook (!) book in progress. More are in discussion, including a book on the Williams arcade board and other arcade boards. Still seeking authors for Apple ][, C64.

[+Philsan]

I found this book to be amazing. It's a nice reading and very insightful. I am actually reading it again.

 

I see that this book belongs to Platform Studies (Platform Studies link). That brings me to ask: when will we have another title? Is there a new book on the way? =)

 

I'm sorry I've been so lax in participating in the forums here. I'm trying to catch up!

 

We've got a Wii book coming next year, and an Amiga book too, and a Dynabook (!) book in progress. More are in discussion, including a book on the Williams arcade board and other arcade boards. Still seeking authors for Apple ][, C64.

I bought your book, very interesting, thanks!

 

You made a book regarding VCS and a book regarding Amiga will be published next year.

What about a book regarding VCS sons and Amiga parents, Atari 8-bit computers (400/800/1200/XL/XE)?

Those 1979 advanced computers, in particular 400/800, were leaders of the market in 1980-1982.

[ibogost]

I bought your book, very interesting, thanks!

 

You made a book regarding VCS and a book regarding Amiga will be published next year.

What about a book regarding VCS sons and Amiga parents, Atari 8-bit computers (400/800/1200/XL/XE)?

Those 1979 advanced computers, in particular 400/800, were leaders of the market in 1980-1982.

 

Thanks for buying the book!

 

We'd welcome a book about the Atari 8-bit computers in the series, of course. Just to be clear about the series's intentions, it's not a place for me and Nick to publish, nor is it a place just for books like Racing the Beam, but an invitation for those interested in writing books about the relationship between computer platforms and creativity. So really, anything that fits that theme is fair game. Not just hardware platforms, but others as well... a book on BASIC or Java, for example, or on Flash or even Facebook would be welcome. The books would just have to address those subjects as platforms.

[maiki]

Those figures are for sure only American sales, since I can't see any Sinclair...

[Retro Rogue]

We've got a Wii book coming next year, and an Amiga book too,

 

What's the Amiga book going to cover?