The book "Racing the Beam: The Atari Video Computer System" is a pretty interesting overview of the technical challenges they had to overcome. The racing part comes to having to have the frame ready to paint before the CRT beam drew them.
I hate to nitpick, but I think it's more interesting to think about it as it actually is. You mentioned having the "frame" ready, but there is no frame.
The platform has produced some masterpieces of creativity under limitations. You have 128 bytes of RAM to work with (for all non-register variables and stack) and slavish timing requirements.
The timing is nightmarish because you're actually controlling the painting of each scanline as the raster sweeps across and down the screen. The design of an Atari 2600 game's "kernel" (as they're called) is one where timing and cycle counting dominates.
Game logic has to sit in specific points in time where the video raster isn't painting (horizontal and vertical blanking intervals). When the raster is sweeping across the phosphors your code is concerned primarily with manipulating the registers of the Television Interface Adapter (TIA) chip to produce the desired video output. There are some "tricks" the TIA can perform itself (mirroring the playfield output across a vertical center line, etc) that can be used to free up some cycles. Creative use of the 5 movable objects (two "player" sprites, two "missile" sprites, and a "ball" sprite) can be used to make more detailed graphics than would be possible with the playfield alone (which has a fairly coarse resolution).
> The platform has produced some masterpieces of creativity under limitations. You have 128 bytes of RAM to work with (for all non-register variables and stack)
And as the CPU was a 6502, you had three 8-bit registers within the CPU, one 8-bit accumulator and two 8-bit index registers.
On the 2600, you can use a fourth register, the stack pointer. The 2600 as a machine has no interrupts, so if a section of code doesn't push/pop/call anything, stack memory is never touched and you can do whatever you want with the stack pointer register.
There's more tricks with the stack pointer on this machine too. Set it to point to the top of a sequence of video registers, and then you can rapidly write values to that sequence of registers just by issuing push instructions, which are faster than load/store/decrement!
I'll give you more detail of one way to use that trick then. The single-bit missile and ball objects are turned on or off by writing to their activation register, controlled by bit 1 of that register. Why bit 1, why not 0 or 7? Because that lines up with the zero flag in the 6502's flags register.
What you do is set the stack pointer to that video register, compare on the object's Y-coordinate, then push the flags register to turn the object on or off! So the code needs no shifts or conditions or branches. It's even cycle invariant which is a great property on this machine.
The video hardware was deliberately designed to do this (by chip legend Jay Miner), and Combat's code does. Also, the registers for the two missiles and the ball are adjacent, so you can do this trick to all of them in succession without resetting the stack pointer.
Thanks for sharing that. That's a neat piece of trivia. I'm already very impressed by Jay Miner's work, and this just adds to that. It makes sense that the TIA would be designed hand-in-glove for the 6507.
BTW - I saw in your other comments that you wrote INV+. This counts as my little brush with "celebrity" for the day. >smile<
> Set it to point to the top of a sequence of video registers, and then you can rapidly write values to that sequence of registers just by issuing push instructions
How did that work on the 2600? The 6502's stack pointer is also only 8-bits, just like the other registers, and hardwired to use page 1 as the upper byte of the ultimate 16-bit stack address. Were the video registers mapped into the page 1 address zone?
Yes. It's really that everything exists in both pages. The video registers exist at 0x00 through 0x3F and the RAM is at 0x80 through 0xFF, both in zero-page for the fast access instructions and in page 1 for the stack pointer.
It's not so much a mapping as a lack of mapping. The hardware simply doesn't decode address line 8. So accessing 0x002F and 0x012F are the same video register for example. If you push something to 0x01FF, you can read it from 0x00FF.
There are more duplications within the address space as well. Address lines 13 and above don't exist in hardware on the 2600, so 0x20FF and 0x40FF and 0x60FF etc also access the same thing. The video registers from 0x00 through 0x3F are also duplicated from 0x40 through 0x7F, by not decoding address line 6 either. The important one is address line 12, which enables the cartridge ROM instead of the video/RAM; in fact that line is wired directly to the chip-enable pin on the cartridge slot.
I went looking for the owner of the Atari brand for a luxury tech pitch, basically to do a heritage brand revitalization play, but couldn't figure out who to talk to at the time. Most luxury tech products were just too vulgar or too superficial to survive, but I could totally do one with Atari.
I read about that and thought it was such a waste. The products themselves I may just develop and create a new one, but it just seemed like such an obvious win to use the Atari brand.
The owner of the brand is the company called Atari SA, previously Infogrames. The CEO is called Fred Chesnay and the company is listed on the French stock exchange. They have a portfolio of products around the brand and seem to be willing to explore many territories, including cryptocurrencies, hotels, as well as good old video games including mobile games and an AMD based pc/console hybrid for the living room coming out at the moment.
Given the wide range of ideas I'm sure they would be willing to do business if you have a good one.
That is a big red warning, considering not much changes if you enable it. Though, seeing as the "human clock" doesn't work on humanclock.com - it does seem fair to have a message... and congrats to them for making it work mostly perfectly without JS!
Most of the internet is just a blank page. I want to get some tshirts printed up that say "You need to enable JavaScript to run this app."
Ethernet is not necessary. The webserver can talk to it's IP router with any protocol that they both implement. Just because everyone everywhere uses ethernet doesn't mean that you have to!
2600 cartridges can contain any amount of extra RAM or even CPU hardware.
But this pretty well isn't real. There's no way you could drive a workable Ethernet connection just from an RF output. Also the "screenshot" is completely fake, the 2600 has nowhere near enough video objects to output all of that.
Multiplexing on the 2600 can't go nearly as far as that screenshot shows. The 2600 has two sprites per line plus a few single-bit objects. There's a particular way to reuse sprites within the same scanline, but only at certain fixed intervals which isn't what we see here, plus strobing the positioning register that fast requires every single CPU cycle so it's impossible to also write the color and playfield registers at the same time.
So I had the following thoughts a time ago. I wondered how feasible it would be to connect two Ataris through the Controller B port and implement some sort of dual-screen game.
Each port has something resembling 5 GPIO pins (direction UDLR and the button) and 2 analog pins that work like the IBM joystick adapter interface - reset the capacitor and wait until you get a 1 to measure the potentiometer resistance. No interrupt connection, so it's totally polled.
I wondered how effectively the 5 joystick pins could be used to implement a bit-banged RS-232 interface. The Commodore 64 KERNAL did that over the user port, speeds up to 2400 baud. From there maybe you can implement PPP but you are still talking about getting a minimal TCP/IP stack on there.
Now ... you probably can't drive the display at the same time.
And I'm sure the TCP/IP implementation would be super limited and only one TCP connection possible at once. Some caching reverse proxy would be needed. And maybe even then only fixed length responses with little or no headers. Could it be done in 4Kbytes of ROM?
27 comments
[ 3.2 ms ] story [ 71.9 ms ] threadThe platform has produced some masterpieces of creativity under limitations. You have 128 bytes of RAM to work with (for all non-register variables and stack) and slavish timing requirements.
The timing is nightmarish because you're actually controlling the painting of each scanline as the raster sweeps across and down the screen. The design of an Atari 2600 game's "kernel" (as they're called) is one where timing and cycle counting dominates.
Game logic has to sit in specific points in time where the video raster isn't painting (horizontal and vertical blanking intervals). When the raster is sweeping across the phosphors your code is concerned primarily with manipulating the registers of the Television Interface Adapter (TIA) chip to produce the desired video output. There are some "tricks" the TIA can perform itself (mirroring the playfield output across a vertical center line, etc) that can be used to free up some cycles. Creative use of the 5 movable objects (two "player" sprites, two "missile" sprites, and a "ball" sprite) can be used to make more detailed graphics than would be possible with the playfield alone (which has a fairly coarse resolution).
And as the CPU was a 6502, you had three 8-bit registers within the CPU, one 8-bit accumulator and two 8-bit index registers.
There's more tricks with the stack pointer on this machine too. Set it to point to the top of a sequence of video registers, and then you can rapidly write values to that sequence of registers just by issuing push instructions, which are faster than load/store/decrement!
I am remound of the perennial HN favorite: http://blog.moertel.com/posts/2013-12-14-great-old-timey-gam...
What you do is set the stack pointer to that video register, compare on the object's Y-coordinate, then push the flags register to turn the object on or off! So the code needs no shifts or conditions or branches. It's even cycle invariant which is a great property on this machine.
The video hardware was deliberately designed to do this (by chip legend Jay Miner), and Combat's code does. Also, the registers for the two missiles and the ball are adjacent, so you can do this trick to all of them in succession without resetting the stack pointer.
BTW - I saw in your other comments that you wrote INV+. This counts as my little brush with "celebrity" for the day. >smile<
How did that work on the 2600? The 6502's stack pointer is also only 8-bits, just like the other registers, and hardwired to use page 1 as the upper byte of the ultimate 16-bit stack address. Were the video registers mapped into the page 1 address zone?
It's not so much a mapping as a lack of mapping. The hardware simply doesn't decode address line 8. So accessing 0x002F and 0x012F are the same video register for example. If you push something to 0x01FF, you can read it from 0x00FF.
There are more duplications within the address space as well. Address lines 13 and above don't exist in hardware on the 2600, so 0x20FF and 0x40FF and 0x60FF etc also access the same thing. The video registers from 0x00 through 0x3F are also duplicated from 0x40 through 0x7F, by not decoding address line 6 either. The important one is address line 12, which enables the cartridge ROM instead of the video/RAM; in fact that line is wired directly to the chip-enable pin on the cartridge slot.
https://atariage.com/2600/programming/index.html
Given the wide range of ideas I'm sure they would be willing to do business if you have a good one.
Would it really, though?
Most of the internet is just a blank page. I want to get some tshirts printed up that say "You need to enable JavaScript to run this app."
But the cartridge claims to have IIS and Apache on it. Neither of those can run in 128 bytes.
But this pretty well isn't real. There's no way you could drive a workable Ethernet connection just from an RF output. Also the "screenshot" is completely fake, the 2600 has nowhere near enough video objects to output all of that.
[0]: https://en.wikipedia.org/wiki/Sprite_multiplexing
[1]: https://scarybeastsecurity.blogspot.com/2020/07/turning-400-...
Source: I know the 2600 well, I wrote and published a homebrew game: http://dos486.com/atari/
Each port has something resembling 5 GPIO pins (direction UDLR and the button) and 2 analog pins that work like the IBM joystick adapter interface - reset the capacitor and wait until you get a 1 to measure the potentiometer resistance. No interrupt connection, so it's totally polled.
I wondered how effectively the 5 joystick pins could be used to implement a bit-banged RS-232 interface. The Commodore 64 KERNAL did that over the user port, speeds up to 2400 baud. From there maybe you can implement PPP but you are still talking about getting a minimal TCP/IP stack on there.
Now ... you probably can't drive the display at the same time.
And I'm sure the TCP/IP implementation would be super limited and only one TCP connection possible at once. Some caching reverse proxy would be needed. And maybe even then only fixed length responses with little or no headers. Could it be done in 4Kbytes of ROM?