Atari VCS (2600) Demo 2012
February 20, 2013 7:08 AM   Subscribe

Atari VCS Demo 2012 - Liquid Candy by Noice [slyt] VCS or 2600? Ah, who cares about nomenclature, just enjoy. If anyone knows how the heck this is done on a VCS, please comment.
posted by marienbad (30 comments total) 17 users marked this as a favorite
Have this too - C64 Demo - "We Are New" by Fairlight. At the end, is that an FLI picture that they are scrolling with the credits?
posted by marienbad at 7:10 AM on February 20, 2013 [2 favorites]

That is really, really fucking impressive.
posted by griphus at 7:13 AM on February 20, 2013

Have you seen elevated, a recent webgl/javascript demo?
posted by gwint at 7:27 AM on February 20, 2013 [1 favorite]

Synthcart + MIDI mods, no?
posted by Sys Rq at 7:37 AM on February 20, 2013

Very impressive!

The text in the title cards only shows 6 characters at a time, so must be using the technique with 2 interspersed tripled players. The end titles do the same, with interlaced scan lines so it looks like there are 12 characters on each line.

In the first part, the color stripes in each scan line must be the two players and the ball, at full width. It would be interesting to see what's going on behind the black bars at the edges.

For that and the helix, I'm guessing they probably have precalculated tables in the ROM for the sine wave, and maybe also premultiplied versions for the scaling. The helix shapes could probably also be precalculated. Looks like it is using two adjacent sprites per scanline to draw them.

I wonder if the one that looks like a color field behind vertical stripes is just blasting color changes into the registers from a big precalculated table rather than doing any calculation at runtime. Actually must be inlined instructions, not a table: probably doing continuous loads and stores to get a color change every 5 cycles/15 pixels.

The spinning bottles are probably just two players on each line, doubled. No horizontal movement so it is probably just feeding different bitmaps in for each frame and scanline.

It's making very good use of the graphics hardware it has to work with. I think this is probably implemented a lot like Pitfall II, where the cartridge has basically everything precalculated in a big ROM or running on a much fancier CPU, and the VCS itself is mostly just blasting instructions out of the pseudo-ROM into the hardware registers. Still quite a feat.
posted by enf at 7:44 AM on February 20, 2013 [10 favorites]

posted by cortex at 8:09 AM on February 20, 2013

VCS rendering doesn't involve writing pixels to a frame buffer, as is the modern approach, because there wasn't enough RAM to store that many pixels. Instead, VCS code "races the beam," effectively changing the color that the CRT displays as the raster sweeps across and down the screen. Delicate instruction timing allows the software to stay in sync with which on-screen pixel is being generated at any given moment. Non-rendering tasks like game logic and sound are performed during the intervals when the beam snaps back to the first column or to the first row.

So the fluid that we see shifting left and right in this demo can be produced by repeatedly rendering the same series of colors to each line of the display, but delaying the execution of that rendering by a few microseconds in either direction with each step down. The helix is similar, with each line slightly different from the last. It would probably be impossible for a VCS to render these visuals shifting up and down instead of left and right.
posted by rlk at 8:15 AM on February 20, 2013 [4 favorites]

If you're interested in this stuff I recommend Racing the Beam, a really great book about the tricks the original Atari creators needed just to hack the machine into doing more than Pong.
posted by steinsaltz at 8:41 AM on February 20, 2013 [2 favorites]

Wonder if this was an emulator, or actual hardware.
posted by mrbill at 8:49 AM on February 20, 2013

I think the video must be from an emulator because the edges of the pixels are so crisp. Conversion from real NTSC output would probably look fuzzy.
posted by enf at 8:53 AM on February 20, 2013

I'm guessing they're using the heck out of a tiny sin/cos table.

Also clever interleaving makes it sound like there's more going on aurally than actually exists. The sound generator only has two-voice polyphony IIRC.
posted by RobotVoodooPower at 8:59 AM on February 20, 2013

Dammit, people, I have work to do, I do not have time to re-visit the demoscene of my teen years today! You're going to go make me dig my MindCandy DVD out of storage to play in the background...

Granted, these are an entirely different level of "holy crap" from the PC demoscene.
posted by jferg at 9:10 AM on February 20, 2013 [1 favorite]

People might also find David Crane's iPhone app on VCS development interesting
posted by fallingbadgers at 10:01 AM on February 20, 2013

Wonder if this was an emulator, or actual hardware.

The More Inside on the video has a link to the ROM. It claims it works on both.

The thing to remember about demos on limited hardware is that they don't display arbitrary things, they just give the appearance of it, by tailoring the display precisely to the hardware. One unique feature of the VCS/2600 is that the processor clock is precisely tied to the length of scan lines on the display, which isn't true of most other systems, and makes some non-intuitive things possible. This means that, while the 2600 is grossly less capable than even an NES in terms of general effects, there are probably some specific effects at which it can be better.
posted by JHarris at 12:57 PM on February 20, 2013

By the way, while a VCS by itself has only 128 bytes of memory, it is possible for cartridges to include at least 128 more bytes. Also, the Starpath Supercharger contained 6K of RAM, although I'm unsure if the 2600 itself could access that RAM as RAM that it, itself, could write to.
posted by JHarris at 2:10 PM on February 20, 2013

The atari 2600 demoscene is actually surprisingly vibrant - there are demos released on that platform quite regularly. (Doctor by Trilobit is my favourite)

"We Are New" by Fairlight. At the end, is that an FLI picture that they are scrolling with the credits?

No, Louie64 is just really amazingly talented with multicolour.

As to the effects in this demo, they're all pretty much well understood demoscene standards (in my other life, i do some myself) - I watched it earlier, but sadly I can't go through it piece by piece at work since youtube is blocked (bah, i work at a bank, what can you do?). That said (I'll do more deconstruction later if people care):

* The twister - the technique is you pre-render single scanlines for 16 rotations, and change your sprite pointer each line. This plays directly into the 2600's strenghts (on the 2600, sprites are the entire screen high - or one line high, if you prefer to think of it that way)

* the plasma - the standard algorythm for this is colour=a.sin(x)+b.sin(y)+c.cos(x)+d.cos(y), and you move a,b,c,d. ish. So this simplifies to a set of small tables you calculate in the vertical blank:

Then for each pixel, you now just need c=table1[x]+table2[y], which on a 4502 simplifies to:
lda table1,x ; 3 cycles
adc table2,y ; 3 cycles
sta colour ; 3 cycles

for a total of 9 cycles. If you look at the way the playfield is layed out on this one, you can see that they're approximately this far apart.

the black stripes are to visually hide the massive pixels - the in doctor, they just embarace the hugeness.

* 6 char scroller - David Crane actually pioneered this in dragster. It's a horizontal multiplexer. Essentially, you wait until the sprite has been display, and then you hit the display latch again. The atari will start the sprite _every time_ the latch is hit, so you can do it
posted by jaymzjulian at 4:18 PM on February 20, 2013 [2 favorites]

The R/W pin of the CPU is not exposed on the cartridge slot, so apparently cartridge 'mappers' set aside a part of the address space for the 'write port'; any access to those addresses is assumed to be a write rather than a read. At least, this is what I glean from reading the source code of stella, one of the open source atari emulators.
posted by jepler at 5:17 PM on February 20, 2013 [1 favorite]

I did some looking into it jepler, that does seem to be the process, although how it works precisely I don't know; to write data, you have to supply the data to be written. I expect it's done using one specific byte as a register to store the data. The most extra bytes of RAM I could find in a cart is 256.

It turns out I was correct, the Supercharger's 6K of RAM cannot be directly modified by the VCS processor; it probably uses its own processor to handle loading data off of tape. BTW, apropos of nothing, but I've discovered that the Supercharger game Dragonstomper is rather fun, for a 2600 game.
posted by JHarris at 6:27 PM on February 20, 2013

For that and the helix, I'm guessing they probably have precalculated tables in the ROM for the sine wave, and maybe also premultiplied versions for the scaling. The helix shapes could probably also be precalculated.

I've always wondered how realistic it was when a godlike AI in a science fiction story was able to make primitive computers do amazing things with code beyond the understanding of human programers.

Pretty realistic, I guess.
posted by straight at 6:44 PM on February 20, 2013

I forget the specifics of the sara chip, but all of these schemes are essentially the same: how it's done, is through a set of 16bit reads - so if you read for example:

lda $ffee

puts on the address bus the value $ffee - the bankswitch/ram chip then latches on this, and inteprets the address as data rather than an address. So $ff might be a "set write address" command, and $ee would be the parameter. You might then have $fe be the "write to memory" command, and write a value to it using lda $fe33 to write $33 to it.
posted by jaymzjulian at 6:48 PM on February 20, 2013 [1 favorite]

Ah, that would work. You're trading both time (two operations instead of one) and address space though. The 6507 only has 4K of address space; if you're special casing two values of the high byte for this scheme, then that space isn't being used for game ROM, although that can be gotten around somewhat with bank switching.

I find this stuff immensely interesting. The Intellivision, by way of contrast, is only able to communicate with its graphics chip at VBLANK, which makes it much less flexible, even though it has better support for hardware sprites and backgrounds.
posted by JHarris at 7:10 PM on February 20, 2013

At first I assumed the RAM schemes must be much like what jaymzjulian says, but have a look at the atari schematic. The address lines are directly connected between the cartridge and the microprocessor. So if you perform a write instruction the 6507 will drive the address lines and the data lines appropriately even if it's an address that is normally cartridge ROM. So then all you need is the convention that a certain address range is the 'read port' and a certain address range is the 'write port'.

But I'm still not 100% sure of this and all the docs about mappers seem to assume I know exactly how they work already...
posted by jepler at 7:36 PM on February 20, 2013

jepler, actually you're right - now that I look up the sara, you read from $1000-$1080, and write to $1080-$1100 - see this:

Clearly I can't keep consoles straight in my brain anymore :).
posted by jaymzjulian at 8:17 PM on February 20, 2013

Hmm, but I thought the 6507 left out pins on the processor, and that's why it can only address 4K?

(I am generally interested in this stuff and have had a Computer Architecture class, but I'm mostly a layperson on this, although I've mused about with playing around with an Arduino or a Raspberry Pi.)
posted by JHarris at 8:33 PM on February 20, 2013

Looking at the schematic, I only count 13 address lines, enough to address 8K, which is in keeping with what I've read: 4K of cartridge address space, and 4K devoted to onboard RAM and I/O chips.
posted by JHarris at 8:39 PM on February 20, 2013

Aaah, but you aren't really disputing what I said about having to reserve part of the address space. And it's obvious that the on-cart hardware does its own thing with the signals coming from the CPU than just pass along reads to RAM, that's how bank switching works. I'm misreading things, heh, nevermind, I'll shut up now.
posted by JHarris at 8:43 PM on February 20, 2013

Wow, amazing discussion guys, thanks.

Reading about this recently, made me want to try some 6502 asm. So I have been reading a book online and can understand lda inx dec etc etc, and am ok with binary/logic etc. Are there any online asm programming exercises that start simple and get harder and harder? I have a 6502 assembler/emulator which I can write it on, and do a mem dump to check values. I appreciate it is different on different hardware, but just thinking in assembler would be a good first step for me, although I doubt I will ever be able to do anything like this demo though!
posted by marienbad at 1:17 PM on February 21, 2013

there is
posted by jaymzjulian at 4:26 PM on February 21, 2013

marienbad, I once wrote some short routines in machine code -- that is, not assembly, but with the C64 programmer reference manual in one hand POKEing opcode values into memory. It's not hard at all.

The biggest gotcha I can think of has to do with branch instructions, which are all relative on the 6502, a number of bytes forward or backward. But branch instruction parameters are all one byte, so branches are limited to 128 bytes back or 127 forward. If you want to jump further, you'll have to branch to a JMP.

The 6502 only has three registers, the Accumulator, X and Y, meaning you do a lot of temporary storage of values. The Accumulator is where you'll do most of your math. X and Y are good for temporary storage, but also come into play with some indexing modes. They're almost, but not *completely*, interchangeable.

The 6502 has no floating point instructions (which, considering its age, is no surprise), but it also has no hardware multiply or divide. You'll have to make due with bit shifting: shift/rolling a byte left multiplies by two, and right divides by two. (With the ROL/ROR instructions the bit shifted in comes out of the carry bit, and the one going out goes there, which you can use to do multi-byte math.)
posted by JHarris at 8:39 PM on February 21, 2013

jaymzjulian's link mentions the C64 Programmer's Reference Guide. It's indispensable, and you could get started with just about with it alone. It documents the VIC-II, SID and both CIA chips, provides a memory map, and has an excellent chapter on machine code. It's available in its entirety, as PDFs, here.
posted by JHarris at 8:49 PM on February 21, 2013

« Older We are GARGOYLES!   |   Drop in For a Bounce Newer »

This thread has been archived and is closed to new comments