2 ms·

I seem to recall the article being about Apple II hardware, but it might have been Atari 2600. They are of similar generations. edit: Yep, you are right - the

I seem to recall the article being about Apple II hardware, but it might have been Atari 2600. They are of similar generations. edit: Yep, you are right - the article is titled "Racing the Beam" https://www.wired.com/2009/03/racing-the-beam/ https://www.wired.com/2009/03/racing-the-beam/

Someone 6y ago
If so, “sprite location could be calculated right up until the moment the first row was drawn to the screen” is a tad optimistic. In theory, you could, but on the Atari 2600, during screen drawing, the CPU cycle budget for each line was 76 cycles (see https://cdn.hackaday.io/files/1646277043401568/Atari_2600_Programming_for_Newbies_Revised_Edition.pdf https://cdn.hackaday.io/files/1646277043401568/Atari_2600_Pr...). Rounding up, that’s 40 instructions, and if the current line is different from the previous one, you’d have to update memory from that same budget. Because of that, reading of user input and updating of player/object positions typically/always was done during the vertical blank interval.
caymanjim 6y ago
I was part of the Commodore 64 demo scene back in the 80s, and this technique was heavily used. You only had so many sprites available, limited color palette, could only use one font (with a small set of glyphs), etc. By setting up "raster interrupts", which would execute code when the CRT reached a specific raster line on the 320x200 display, you could do all sorts of trickery. The raster interrupt would trigger after it rendered the first horizontal line, and then you could change the pointer to the sprite/font/palette/etc. for the duration of the next display line. A common effect that everyone would learn first was to simply change the background color, so that every display line was a different color, producing a rainbow background. In a sense, the [video] demo scene was almost entirely about this effect. How much could you do in the tiny number of CPU cycles available to you between the raster interrupt triggered at the end of one horizontal scan line, and the start of the next line, as the beam wrapped around? You could just barely execute about a dozen CPU instructions. Usually you'd flip a couple pointers that the video hardware would look at when it started rendering again, and then you'd pad in a couple no-op instructions so that the change occurred "off screen". This really happened in the margins of the CRT that were covered by a bezel, which meant that on some displays the transition really was invisible to the eye, but on others, there would be flickering at the edges as the background color changed. I used to test my demos on multiple displays to try to minimize the effect, having to shave off an instruction or two in order to make things look better.

Someone 6y ago

If so, “sprite location could be calculated right up until the moment the first row was drawn to the screen” is a tad optimistic. In theory, you could, but on the Atari 2600, during screen drawing, the CPU cycle budget for each line was 76 cycles (see https://cdn.hackaday.io/files/1646277043401568/Atari_2600_Programming_for_Newbies_Revised_Edition.pdf https://cdn.hackaday.io/files/1646277043401568/Atari_2600_Pr...). Rounding up, that’s 40 instructions, and if the current line is different from the previous one, you’d have to update memory from that same budget. Because of that, reading of user input and updating of player/object positions typically/always was done during the vertical blank interval.

caymanjim 6y ago

I was part of the Commodore 64 demo scene back in the 80s, and this technique was heavily used. You only had so many sprites available, limited color palette, could only use one font (with a small set of glyphs), etc. By setting up "raster interrupts", which would execute code when the CRT reached a specific raster line on the 320x200 display, you could do all sorts of trickery. The raster interrupt would trigger after it rendered the first horizontal line, and then you could change the pointer to the sprite/font/palette/etc. for the duration of the next display line. A common effect that everyone would learn first was to simply change the background color, so that every display line was a different color, producing a rainbow background. In a sense, the [video] demo scene was almost entirely about this effect. How much could you do in the tiny number of CPU cycles available to you between the raster interrupt triggered at the end of one horizontal scan line, and the start of the next line, as the beam wrapped around? You could just barely execute about a dozen CPU instructions. Usually you'd flip a couple pointers that the video hardware would look at when it started rendering again, and then you'd pad in a couple no-op instructions so that the change occurred "off screen". This really happened in the margins of the CRT that were covered by a bezel, which meant that on some displays the transition really was invisible to the eye, but on others, there would be flickering at the edges as the background color changed. I used to test my demos on multiple displays to try to minimize the effect, having to shave off an instruction or two in order to make things look better.