5 ms·

"By paring back the hardware, the designers of the Atari Video Computer System gave game programmers room to be creative" That's some rose-coloured glasses rig

by dusted 5y ago

"By paring back the hardware, the designers of the Atari Video Computer System gave game programmers room to be creative" That's some rose-coloured glasses right there if there ever were any. "You know, we COULD give this thing hardware sprites, independent video and audio chips!" "No! Think of the game programmers! They thrive on constraint!" My money is on the money.. The cheapest design that still allowed (the best programmers to make) reasonably good games. That said, the system was enjoyable to play when I was a kid, and it's enjoyable to read about now, great article!

Someone 5y ago
Indeed. https://en.m.wikipedia.org/wiki/Atari_2600#MOS_Technology_6502/6507 https://en.m.wikipedia.org/wiki/Atari_2600#MOS_Technology_65...: “Over two days, MOS and Cyan engineers sketched out a 6502-based console design by Meyer and Milner's specifications. Financial models showed that even at $25, the 6502 would be too expensive, and Peddle offered them a planned 6507 microprocessor, a cost-reduced version of the 6502, and MOS's RIOT chip for input/output. Cyan and MOS negotiated the 6507 and RIOT chips at $12 a pair“
reaperducer 5y ago
Artists very often thrive when constrained. Programming used to be an art.
bitwize 5y ago
The player-missile graphics were hardware sprites, albeit more cumbersome to use. So far as I know, sprites as you know them -- reprogrammable two-dimensional bitmaps whose x and y coordinates can be set with hardware registers -- didn't even come about in a non-cost-prohibitive manner until the TI-99/4 in 1979. (Edit: The Intellivision had similar capabilities around the same time. The first Atari 8-bit computers were also contemporary, but used a more advanced variant of the 2600's technology involving per-scanline display lists, which approach would be used also by the 7800.) The designers of the TI-99/4 and TI-99/4A certainly did coin the term "sprite" as it's used in the computer graphics sense. Even arcade games of the era (late 1970s) tended to use framebuffer displays. The mechanic of the invaders slowly speeding up as they were picked off in Space Invaders (1978) stems from the fact that the fewer invaders on screen, the faster the CPU could blit them all.
- Damogran6 5y ago
  At the same time, the 4a didn't have Vector graphics...you HAD to program with sprites with the included basic. So much graph paper...so much conversions of binary to hex.
  - bitwize 5y ago
    The 4A did have a framebuffer graphics mode, it was just not available from BASIC. Vector graphics were thus available in software such as TI Logo II. You could even use sprites with it. Bitmap mode, as it was called, was also used for the graphics in games such as Parsec, where a fast software scrolling routine provided the game's smooth scrolling background. The 4A was a nerfed machine in general: its powerful 16-bit CPU could only access directly 256 bytes of RAM, with the rest being mediated through the video chip. Its built-in BASIC was both slow, being written in GPL bytecode, and nerfed in that it provided virtually no direct access to the machine's features and actually locked you out of some of them, like bitmap and multicolor mode and even sprites. Extended BASIC got you sprites and some other features, but you still needed the expensive PEB in order to load machine code routines. These limitations were tragic, as the machine itself was rather powerful even compared to machines from a few years later, and there wasn't much reason to limit it except that TI saw it as a giant version of their calculators and wanted it to be cartridge-driven with only the barest allowable user programmability.
    - chasil 5y ago
      The DNOS minicomputer division demanded that the 99/4 be absolutely crippled, so powerful operating systems could not be run on the machine. I was "lucky" enough to get a 99/4a early on, then a job at Deere converting DNOS systems to Xenix and TI System V on 68000 NuBus. https://en.m.wikipedia.org/wiki/TI-DNOS https://en.m.wikipedia.org/wiki/TI-DNOS
      - Damogran6 5y ago
        Holy cow!
    - 5y ago
beebeepka 5y ago
All in all, yes, it was enjoyable. Except for that pacman port. Absolutely unplayable. Apparently I've been a high FPS bastard my entire life
- anthk 5y ago
  There was a Pacman homebrew release for the 2600 a few years ago which was amazing.
Jeema101 5y ago
Yes you are correct. The reason it was designed the way it was, was to eliminate the need for a framebuffer. RAM was very expensive in 1977, but a 6502 running at about 1.2MHz was just fast enough to keep up with the requirements of drawing each line on the fly. It was basically an extreme example of the old 'CPU time vs. RAM space' tradeoff.
- retrac 5y ago
  > a 6502 running at about 1.2MHz was just fast enough to keep up with the requirements of drawing each line on the fly /Just/ fast enough. One can actually emulate a normal framebuffer on the 2600 if there's extra RAM on the cartridge. Or display a bitmap image from ROM. Since the 2600 can only draw from shift registers, including two 1-bit tall by 8-bit wide "sprites", one has to position the sprites to interleave, and then load the correct byte values into the shift registers, the exact cycle before it's clocked out to the display. There are 76 cycles during a scanline, and without self-modifying code it takes a minimum of 8 cycles to do the right kind of load-store for a single sprite. Add some accounting overhead, and there's just enough time to do this 6 times per line, giving a practical resolution of 48 pixels horizontal. (My attempt has 5 cycles spare in the main loop, IIRC.) One can double the 48 pixels further by interlacing. Switching between two frames offset by one pixel, yielding an effective 96 x 96 pixels when motion-blurred together. This is the technique by which the high-resolution title screens of some later and homebrew games are displayed. The processor is lock-stepped with the CRT beam the whole time. It runs the loop of load/store instructions typically 192 times for each of the 192 scanlines drawn. A hard real-time obligation 60 times a second that uses 70% of your CPU time. Any game logic or calculations, detecting the controller inputs, etc. must be left to the short vertical blanking interval. And there's no interrupt so you have to time most of this with cycle counting and polling the timer. I really don't know how the wizards did it back in the day, without the excellent emulators available today. I found rewinding and single-stepping the 'hardware', comparing the TIA's registers with the scan cycle step-by-step, to be essential for getting it to display basically anything. Developers in the 70s just got an Atari 2600 motherboard with RAM or EEPROMs. No debugging tools per se, really.
  - 5y ago
apricot 5y ago
The 2600 was designed to be a Pong and Combat machine. Players, missiles, balls, background. Its designers had absolutely no idea programmers would write things like Adventure and Pitfall for it.

by dusted 5y ago

Someone 5y ago

Indeed. https://en.m.wikipedia.org/wiki/Atari_2600#MOS_Technology_6502/6507 https://en.m.wikipedia.org/wiki/Atari_2600#MOS_Technology_65...: “Over two days, MOS and Cyan engineers sketched out a 6502-based console design by Meyer and Milner's specifications. Financial models showed that even at $25, the 6502 would be too expensive, and Peddle offered them a planned 6507 microprocessor, a cost-reduced version of the 6502, and MOS's RIOT chip for input/output. Cyan and MOS negotiated the 6507 and RIOT chips at $12 a pair“

reaperducer 5y ago

Artists very often thrive when constrained. Programming used to be an art.

bitwize 5y ago

The player-missile graphics were hardware sprites, albeit more cumbersome to use. So far as I know, sprites as you know them -- reprogrammable two-dimensional bitmaps whose x and y coordinates can be set with hardware registers -- didn't even come about in a non-cost-prohibitive manner until the TI-99/4 in 1979. (Edit: The Intellivision had similar capabilities around the same time. The first Atari 8-bit computers were also contemporary, but used a more advanced variant of the 2600's technology involving per-scanline display lists, which approach would be used also by the 7800.) The designers of the TI-99/4 and TI-99/4A certainly did coin the term "sprite" as it's used in the computer graphics sense. Even arcade games of the era (late 1970s) tended to use framebuffer displays. The mechanic of the invaders slowly speeding up as they were picked off in Space Invaders (1978) stems from the fact that the fewer invaders on screen, the faster the CPU could blit them all.

Damogran6 5y ago
At the same time, the 4a didn't have Vector graphics...you HAD to program with sprites with the included basic. So much graph paper...so much conversions of binary to hex.
- bitwize 5y ago
  The 4A did have a framebuffer graphics mode, it was just not available from BASIC. Vector graphics were thus available in software such as TI Logo II. You could even use sprites with it. Bitmap mode, as it was called, was also used for the graphics in games such as Parsec, where a fast software scrolling routine provided the game's smooth scrolling background. The 4A was a nerfed machine in general: its powerful 16-bit CPU could only access directly 256 bytes of RAM, with the rest being mediated through the video chip. Its built-in BASIC was both slow, being written in GPL bytecode, and nerfed in that it provided virtually no direct access to the machine's features and actually locked you out of some of them, like bitmap and multicolor mode and even sprites. Extended BASIC got you sprites and some other features, but you still needed the expensive PEB in order to load machine code routines. These limitations were tragic, as the machine itself was rather powerful even compared to machines from a few years later, and there wasn't much reason to limit it except that TI saw it as a giant version of their calculators and wanted it to be cartridge-driven with only the barest allowable user programmability.
  - chasil 5y ago
    The DNOS minicomputer division demanded that the 99/4 be absolutely crippled, so powerful operating systems could not be run on the machine. I was "lucky" enough to get a 99/4a early on, then a job at Deere converting DNOS systems to Xenix and TI System V on 68000 NuBus. https://en.m.wikipedia.org/wiki/TI-DNOS https://en.m.wikipedia.org/wiki/TI-DNOS
    - Damogran6 5y ago
      Holy cow!
  - 5y ago

beebeepka 5y ago

All in all, yes, it was enjoyable. Except for that pacman port. Absolutely unplayable. Apparently I've been a high FPS bastard my entire life

anthk 5y ago
There was a Pacman homebrew release for the 2600 a few years ago which was amazing.

Jeema101 5y ago

Yes you are correct. The reason it was designed the way it was, was to eliminate the need for a framebuffer. RAM was very expensive in 1977, but a 6502 running at about 1.2MHz was just fast enough to keep up with the requirements of drawing each line on the fly. It was basically an extreme example of the old 'CPU time vs. RAM space' tradeoff.

retrac 5y ago
> a 6502 running at about 1.2MHz was just fast enough to keep up with the requirements of drawing each line on the fly /Just/ fast enough. One can actually emulate a normal framebuffer on the 2600 if there's extra RAM on the cartridge. Or display a bitmap image from ROM. Since the 2600 can only draw from shift registers, including two 1-bit tall by 8-bit wide "sprites", one has to position the sprites to interleave, and then load the correct byte values into the shift registers, the exact cycle before it's clocked out to the display. There are 76 cycles during a scanline, and without self-modifying code it takes a minimum of 8 cycles to do the right kind of load-store for a single sprite. Add some accounting overhead, and there's just enough time to do this 6 times per line, giving a practical resolution of 48 pixels horizontal. (My attempt has 5 cycles spare in the main loop, IIRC.) One can double the 48 pixels further by interlacing. Switching between two frames offset by one pixel, yielding an effective 96 x 96 pixels when motion-blurred together. This is the technique by which the high-resolution title screens of some later and homebrew games are displayed. The processor is lock-stepped with the CRT beam the whole time. It runs the loop of load/store instructions typically 192 times for each of the 192 scanlines drawn. A hard real-time obligation 60 times a second that uses 70% of your CPU time. Any game logic or calculations, detecting the controller inputs, etc. must be left to the short vertical blanking interval. And there's no interrupt so you have to time most of this with cycle counting and polling the timer. I really don't know how the wizards did it back in the day, without the excellent emulators available today. I found rewinding and single-stepping the 'hardware', comparing the TIA's registers with the scan cycle step-by-step, to be essential for getting it to display basically anything. Developers in the 70s just got an Atari 2600 motherboard with RAM or EEPROMs. No debugging tools per se, really.
- 5y ago

apricot 5y ago

The 2600 was designed to be a Pong and Combat machine. Players, missiles, balls, background. Its designers had absolutely no idea programmers would write things like Adventure and Pitfall for it.