5 ms·

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 runnin

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.
- toast0 5y ago
  > And there's no interrupt so you have to time most of this with cycle counting and polling the timer Cycle counting is pretty important, but there is the WSYNC register to pause the CPU until the next Horzintal Blanking time. (Of course, this was patented and Nintendo avoided it in the NES/Famicom, although some mappers had a similar thing (and interrupts!)
- exsf0859 5y ago
  Back in the day, I saw VCS game developers use two techniques: 1) they would start with a working kernel from an existing game, and incrementally modify it to create a new kernel for a new game. 2) they would code 2-dimensionally on large sheets of graph paper, where each cell corresponded to both a 6507 CPU cycle and a portion of the horizontal scan line. By writing out the instructions this way, they could visually check that the code would execute at the correct time.
snorkel 5y ago
I dabbled with Atari 2600 game programming. I can appreciate how the frugality of the VCS design put really tight constraints on game devs and in hindsight the VCS could’ve been worlds better if a bit more was invested in hardware. As a game dev on VCS, the kernel of your game loop is essentially drawing each horizontal scanline (on a CRT screen) in realtime, so you have a budget of about 20 assembly instructions (during the hblank at the start of each scan line) to describe what gets drawn on that line as it’s being drawn, including players and missles, and playfield. Then between each frame (during the vblank and overscan) you have a budget of about 30 assembly op codes to detect collisions, change the playfield graphics, adjust the sound, check paddle/joystick inputs, etc. It’s a crazy tight clock cycle budget to work with. I honestly struggled with writing a simple game that could use so few machine op codes per frame, I couldn’t stay in budget so my frames were a mess. I wonder what could’ve been if Atari invested a bit more in giving developers a little bit more to work with. Nintendo NES came out soon after and seemed to learn from Ataris mistakes with the VCS.
- skeeter2020 5y ago
  >> Nintendo NES came out soon after Not really true. The Famicom(identical tech specs to the NES) was released in 1983 while the VCS came out in 1977. There's also a big difference betwen 2KB of ram plus 2KB dedicated video vs. the 128 bytes of an Atari 2600.
- Narishma 5y ago
  The NES came out much later. 6 years later in Japan and 8 years later in the US.
butterisgood 5y ago
Racing the Beam is an excellent book.

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.

toast0 5y ago
> And there's no interrupt so you have to time most of this with cycle counting and polling the timer Cycle counting is pretty important, but there is the WSYNC register to pause the CPU until the next Horzintal Blanking time. (Of course, this was patented and Nintendo avoided it in the NES/Famicom, although some mappers had a similar thing (and interrupts!)
exsf0859 5y ago
Back in the day, I saw VCS game developers use two techniques: 1) they would start with a working kernel from an existing game, and incrementally modify it to create a new kernel for a new game. 2) they would code 2-dimensionally on large sheets of graph paper, where each cell corresponded to both a 6507 CPU cycle and a portion of the horizontal scan line. By writing out the instructions this way, they could visually check that the code would execute at the correct time.

snorkel 5y ago

I dabbled with Atari 2600 game programming. I can appreciate how the frugality of the VCS design put really tight constraints on game devs and in hindsight the VCS could’ve been worlds better if a bit more was invested in hardware. As a game dev on VCS, the kernel of your game loop is essentially drawing each horizontal scanline (on a CRT screen) in realtime, so you have a budget of about 20 assembly instructions (during the hblank at the start of each scan line) to describe what gets drawn on that line as it’s being drawn, including players and missles, and playfield. Then between each frame (during the vblank and overscan) you have a budget of about 30 assembly op codes to detect collisions, change the playfield graphics, adjust the sound, check paddle/joystick inputs, etc. It’s a crazy tight clock cycle budget to work with. I honestly struggled with writing a simple game that could use so few machine op codes per frame, I couldn’t stay in budget so my frames were a mess. I wonder what could’ve been if Atari invested a bit more in giving developers a little bit more to work with. Nintendo NES came out soon after and seemed to learn from Ataris mistakes with the VCS.

skeeter2020 5y ago
>> Nintendo NES came out soon after Not really true. The Famicom(identical tech specs to the NES) was released in 1983 while the VCS came out in 1977. There's also a big difference betwen 2KB of ram plus 2KB dedicated video vs. the 128 bytes of an Atari 2600.
Narishma 5y ago
The NES came out much later. 6 years later in Japan and 8 years later in the US.

butterisgood 5y ago

Racing the Beam is an excellent book.