3 ms·
> 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 em
by 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 agoBack 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.