By Rob Beschizza at 10:23 am Wed, Feb 20, 2013
This demo, for the 1977 Atari VCS/2600 console, was coded by Andreas "Shadow/Noice" Gustafsson with music by Ilmarque/Trilobit. It operates using less working memory than the text of this blog post could be stored in. [YT via Metafilter]
I love the demo scene that’s been around since at least the late ’90s.
Lots of guys I know are game developers at places like DICE and iD because of the hacking skills they developed working on these things.
This was made for 64k!
Some talk about the scene –
I was checking out demos on my Amiga 1000 in 1990 and I assume I was not the first one. There were amazing demos that fit in just the boot loaders of the disks put out by certain eye patch wearing groups.
WAY earlier than 1990. Plenty of Demos in the 80’s.
Whoops! Yeah, I thought I typed “late-80s”. I had a C-64 back in 1984 and saw some great demos (and music on the SID chip) the same way that dculberson above said: patch-wearing c-64 groups.
But I remember when the Amiga came out around ’88’-89 that they were really taking off, at least from what I saw stuck in the MidWest. :)
Ahhh ok, 128 bytes of working memory, not 128 bytes for the entire program. Was very confused for a while.
So you could think of it as being a kind of tiny video player program, streaming data from ROM and piping it to the screen/audio registers. (But, no doubt, it’s actually vastly more tricksy and intricate than that.)
Ah, thanks. 128 bytes for the program would have been essentially impossible — the text in the demo alone was more than that.
In any case, yes, you can make lots of pretty animations in almost no space just using a lot of sine waves.
Sine waves are pretty impressive on a VCS though, it didn’t have much in the way of advanced math capabilities. It’s not easy to just precalculate and store the values in the ROM either unless you cheat and use an oversized ROM.
The flicker free text scroller was really impressive too. That sort of thing is really hard to do on 2600 hardware.
> 128 bytes of working memory, not 128 bytes for the entire program.
Yeah, I was mystified until I realized that, too. While I am constantly amazed by the capabilities of the demo scene to cram functionality into tiny footprints, a 128-byte demo with this level of functionality was only explainable as “fucking sorcery.”
Ah, back in the days when a kb of RAM meant something.
I miss my Vic-20. 3583 bytes, baby.
Hey hey 16k, what does that get you today?
It is quite the opposite of a video player. All this was generated on the fly.
In the 2600, you usually set up an interrupt to happen at the beginning of each scan line. For effects like these you would use different wait loops so that you started the object at the right position. The sine waves were in a ROM table. For fine positioning you had to use slightly slower addressing modes, so there was probably a second table for that.
I think that the most amazing game was 2600 Chess. How they managed that one in 128 bytes of RAM an can’t imagine.
Yes, misleading headline. What’s really interesting is that there are people today who still know how to do that on primitive VCS hardware.
More headline bashing: EVERYTHING on the Atari VCS, every single game ever, ran with just 128 bytes of RAM. That’s all it had. The cartridges had significantly more ROM, however.
I’d love to see more of the old Atari stuff ported to iOS! Some of those old titles would be a very good fit for the iOS UI.
Atari ported a lot of their 2600 titles in the Greatest Hits app for iOS.
Back in the early 80’s, I earned a living writing VCS games. The demo is impressive in that the author had to write a “kernel” to draw onscreen. What that means is each scan line requires that certain registers be preloaded just before the electron gun needs to draw the pixels on screen.
If you were clever, you could load up to 4 or 5 registers in time to beat the gun and then reload the registers for the next scan line. There was a separate register that synced the computer to the the gun’s horizontal sync but using it meant wasting a few of the 76 CPU cycles per scan line so we’d just code all our branches so we were sure that no matter which path the code took, it was 76 cycles per scan line. As you can imagine, a multi-scanline “kernel” written in 6502 assembly language took a lot of thought to map out.
Since each game was different, each game needed its own kernel. Some kernels were found by accident when a bug surfaced and showed a neat effect like what the demo shows. One of the programmers I worked with referred to those bugs as “lucky bugs.”
In the beginning, a programmer did everything – game design, program, music, art and it looked like it as few were good at all those skills. Music, sound effects and art were the early skills that were initially delegated out. Our artists were quite good and one year, we programmers got together and chipped in a $1,000 plus to buy the lead artist a briefcase which we stuffed with $1,000 in $1 bills. Fun times.
The impressive part is usually the size of the binary, not the required RAM. To reproduce this blog post (or the whole demo for that matter) no RAM is required at all. All the program needs to do is read every byte from the binary and write it to the right output.
Those processors are Von Neumann architectures which means that the program itself doesn’t need to be in the RAM in order to be executed.
I learned Chess algorithms from the source code of Sargon on a Commodore 64. I started programming on a C64 when I was 6-7 years old. Unfortunately, being versed in C64 Basic and 20+ other variations of the Basic language doesn’t impress anyone on a resume these days.:P
Oh man, flashback central! I used to love some of those great Future Crew demos back in the early 90s! I remember meeting one of them ages back, the guy could type in Assembly faster than I could type in English. Lovely people
Programmers these days with their high level languages. Bloat! Bloat! Bloat!
«128bytes ought to be enough for anybody»
Mail (will not be published) (required)
Submit a tip
The rules you agree to by using this website.
Who will be eaten first?
Jason Weisberger, Publisher
Ken Snider, Sysadmin