5 ms·

The thing I found fascinating about this machine is it has no video RAM at all. I couldn't initially understand how it could possibly work without a frame buffe

The thing I found fascinating about this machine is it has no video RAM at all. I couldn't initially understand how it could possibly work without a frame buffer. What it does is you have to redraw the screen dynamically on every frame with precise timing in sync with the sweep of the CRT beam. It also has little memory generally. There's no dedicated RAM chips, there's 128 bytes (not kilobytes) on the PIA you can use and that's it.

tenebrisalietum 4y ago
Basically you have some CPU cycles in the "horizontal blank" part of each line that you can use to change chip registers for that line. The TIA had some delay bits/latches so you could write player 1 data and player 2 data on alternate lines, but with one delayed so they'd appear on the same line. Your actual game code was expected to run in VBLANK. You can of course alter registers while the line is being drawn, if your timing is precise and your data is prepared, and that's the basis of doing advanced things like 6 digit scores and non-symmetrical playfields.
jacquesm 4y ago
There were other computers from that era that did the same thing but the 2600 did it more elegantly: https://www.timexsinclair.com/computers/sinclair-zx80/ https://www.timexsinclair.com/computers/sinclair-zx80/ And the Apple-1 which is also a very elegant solution to the same problem but without some of the drawbacks (it does have video memory but the CPU isn't slowed down much): http://forum.6502.org/viewtopic.php?t=1352 http://forum.6502.org/viewtopic.php?t=1352
- Someone 4y ago
  Viewed from today, both the ZX80 and the 2600 are very limited, but viewed from either machine, not the same thing, IMO. The ZX81 used the CPU for generating the video signal, but it had a character ROM (small, of course. https://en.wikipedia.org/wiki/ZX80_character_set https://en.wikipedia.org/wiki/ZX80_character_set), used its copious (ha!) memory for storing data for the entire screen, and shipped with the necessary software so that it, when left alone, would show the contents of the current screen without aid from the currently running program. IIRC, ZX80 video memory wasn’t a width × height matrix, but more like in a text file, with a special byte value separating lines, making empty lines cheap (you only needed to store the EOL token), and left-aligned text cheaper than right-aligned text, memory-wise (leading spaces ate into memory use, trailing ones needn’t be stored). The system needed that because that memory came from your one kilobyte of RAM. Filling the screen would use a large fraction of available memory)
alex_suzuki 4y ago
Also called „racing the beam“, like the highly recommended book. If you’re interested in a quick writeup with some pointers to reference material and sample code, check out my post: https://blog.classycode.com/the-atari-2600-a-personal-journey-into-the-past-5b8cadebc6eb https://blog.classycode.com/the-atari-2600-a-personal-journe... You might enjoy it.
deleted 4y ago
[deleted]
kabdib 4y ago
You have an extra 8 bits in the PIA's I/O port direction register. If you're not using inputs right now you can use that as temporary memory. It's not like the joystick cares if it's getting a little backwards current. Oh, there are lots of tricks. And when the tricks run out, you run on desperation, you rewrite your display kernel for the fifth time, to get 8 precious cycles back just before the score line. Victory is sweet. I had a cow-orker (we were both out of the 8-bit computer games division) who decided it would be good for his career (at Atari) to learn 2600 game programming. He got a Stella devkit, a copy of the same dev documentation that has been published everywhere (that's all that anyone got at the time), and over the next four months or so I watched him slowly go mad. I'm not kidding, his mental state was terrible. About then Jack Tramiel bought the company and we all got to work on different stuff, yay. The 2600 hackers over in Consumer games had a reputation for being pretty wild and unhinged. I am half serious when I say that it was the machine that did it to them.
- JetSetIlly 4y ago
  There are also three bits available in Port B of the RIOT, which controls the front panel. I don't know of any real world examples of ROMs that make use of it but if you ever desperately needed an additional boolean value then it would come in handy.
vikingerik 4y ago
It does have video RAM, at least sort of. There's about 20 registers on the graphics chip that control the display of the playfield bits and sprite objects. They hold the values persistently until rewritten, so in a way that is functioning as video RAM, just not as a bitmap, and it holds a one-dimensional scanline rather than a two-dimensional frame. Another way of looking at it is that the video "RAM" is actually the phosphor on the display screen, persisting each scanline when written until refreshed on the next frame.
- diydsp 4y ago
  > a one-dimensional scanline And iiuc it's only abt 40% of the line. You have to update it during the line! and sometimes it's fwd and sometimes bkwd so you can't simply let it repeat a simple pattern!
  - vikingerik 4y ago
    I don't know where you're getting that from. You can indeed leave all the registers alone and it will repeat whatever is there for any number of scanlines until you do change it. In fact, this is what happens if you power up the 2600 without a cartridge - you see vertical stripes, because whatever garbage was in the registers on powerup just stays there and repeats onto every scanline, with no software changing it. "Sometimes forward and sometimes backward" would only apply to the three registers of playfield bits, and is fully controllable by software, in the CTRLPF register.
    - kgwxd 4y ago
      I'm sure they're talking about manipulating a single line and the fact that you're extremely limited by the behavior of machine for that particular line. Anything that doesn't fit within the hardware design constraints needs mid-line changes and/or clever hacks and, even with those, what you want to output might just not be physically possible.

tenebrisalietum 4y ago

Basically you have some CPU cycles in the "horizontal blank" part of each line that you can use to change chip registers for that line. The TIA had some delay bits/latches so you could write player 1 data and player 2 data on alternate lines, but with one delayed so they'd appear on the same line. Your actual game code was expected to run in VBLANK. You can of course alter registers while the line is being drawn, if your timing is precise and your data is prepared, and that's the basis of doing advanced things like 6 digit scores and non-symmetrical playfields.

jacquesm 4y ago

There were other computers from that era that did the same thing but the 2600 did it more elegantly: https://www.timexsinclair.com/computers/sinclair-zx80/ https://www.timexsinclair.com/computers/sinclair-zx80/ And the Apple-1 which is also a very elegant solution to the same problem but without some of the drawbacks (it does have video memory but the CPU isn't slowed down much): http://forum.6502.org/viewtopic.php?t=1352 http://forum.6502.org/viewtopic.php?t=1352

Someone 4y ago
Viewed from today, both the ZX80 and the 2600 are very limited, but viewed from either machine, not the same thing, IMO. The ZX81 used the CPU for generating the video signal, but it had a character ROM (small, of course. https://en.wikipedia.org/wiki/ZX80_character_set https://en.wikipedia.org/wiki/ZX80_character_set), used its copious (ha!) memory for storing data for the entire screen, and shipped with the necessary software so that it, when left alone, would show the contents of the current screen without aid from the currently running program. IIRC, ZX80 video memory wasn’t a width × height matrix, but more like in a text file, with a special byte value separating lines, making empty lines cheap (you only needed to store the EOL token), and left-aligned text cheaper than right-aligned text, memory-wise (leading spaces ate into memory use, trailing ones needn’t be stored). The system needed that because that memory came from your one kilobyte of RAM. Filling the screen would use a large fraction of available memory)

alex_suzuki 4y ago

Also called „racing the beam“, like the highly recommended book. If you’re interested in a quick writeup with some pointers to reference material and sample code, check out my post: https://blog.classycode.com/the-atari-2600-a-personal-journey-into-the-past-5b8cadebc6eb https://blog.classycode.com/the-atari-2600-a-personal-journe... You might enjoy it.

deleted 4y ago

[deleted]

kabdib 4y ago

You have an extra 8 bits in the PIA's I/O port direction register. If you're not using inputs right now you can use that as temporary memory. It's not like the joystick cares if it's getting a little backwards current. Oh, there are lots of tricks. And when the tricks run out, you run on desperation, you rewrite your display kernel for the fifth time, to get 8 precious cycles back just before the score line. Victory is sweet. I had a cow-orker (we were both out of the 8-bit computer games division) who decided it would be good for his career (at Atari) to learn 2600 game programming. He got a Stella devkit, a copy of the same dev documentation that has been published everywhere (that's all that anyone got at the time), and over the next four months or so I watched him slowly go mad. I'm not kidding, his mental state was terrible. About then Jack Tramiel bought the company and we all got to work on different stuff, yay. The 2600 hackers over in Consumer games had a reputation for being pretty wild and unhinged. I am half serious when I say that it was the machine that did it to them.

JetSetIlly 4y ago
There are also three bits available in Port B of the RIOT, which controls the front panel. I don't know of any real world examples of ROMs that make use of it but if you ever desperately needed an additional boolean value then it would come in handy.

vikingerik 4y ago

It does have video RAM, at least sort of. There's about 20 registers on the graphics chip that control the display of the playfield bits and sprite objects. They hold the values persistently until rewritten, so in a way that is functioning as video RAM, just not as a bitmap, and it holds a one-dimensional scanline rather than a two-dimensional frame. Another way of looking at it is that the video "RAM" is actually the phosphor on the display screen, persisting each scanline when written until refreshed on the next frame.

diydsp 4y ago
> a one-dimensional scanline And iiuc it's only abt 40% of the line. You have to update it during the line! and sometimes it's fwd and sometimes bkwd so you can't simply let it repeat a simple pattern!
- vikingerik 4y ago
  I don't know where you're getting that from. You can indeed leave all the registers alone and it will repeat whatever is there for any number of scanlines until you do change it. In fact, this is what happens if you power up the 2600 without a cartridge - you see vertical stripes, because whatever garbage was in the registers on powerup just stays there and repeats onto every scanline, with no software changing it. "Sometimes forward and sometimes backward" would only apply to the three registers of playfield bits, and is fully controllable by software, in the CTRLPF register.
  - kgwxd 4y ago
    I'm sure they're talking about manipulating a single line and the fact that you're extremely limited by the behavior of machine for that particular line. Anything that doesn't fit within the hardware design constraints needs mid-line changes and/or clever hacks and, even with those, what you want to output might just not be physically possible.