If an Atari 2600 is feeding video to a black and white television set, the time between a store to one of the color registers and a corresponding change in the intensity of signal output by the beam could be less than 280ns (the approximate time required to show one pixel). Typical color television sets of the 1970s and early 1980s would add about a pixel worth of latency in their color decode circuitry. If a game were to include a loop like:rainwarrior wrote:This is kind of a bizarre statement. What is "sub-pixel latency" supposed to mean?93143 wrote:Good luck emulating a fully accurate Super Accelerator System with sub-pixel latency (ie: "none"), or even a few scanlines of latency, on any modern system. A Raspberry Pi isn't powerful enough, and a full-scale PC isn't real-time enough (I'm not sure it's powerful enough either). Just using a framebuffer adds a whole frame of latency by itself. You'd basically have to completely take over a powerful PC at the hardware level, bypassing the OS and drivers, and probably write parts of the emulator in shader language, to get anywhere near what an FPGA could do if properly programmed.
Code: Select all
lp: ; Total loop time 76 cycles==1 line lda INP0 ; 3 cycles sta COLUBK ' 3 cycles ... another 10 repetitions of that, for 66 cycles total lda 0 ; Waste 3 cycles lda INTIM ; 4 cycles bmi lp ; Assume 3 cycles
In one particular weird corner case on the Atari 2600, a pixel can be split between multiple colors, though I don't think this could be very well exploited because the exact effects seem to vary with conditions like temperature. If the screen is programmed to switch color registers at the midpoint of each scan line, the switch isn't synchronized with the same pixel boundaries as everything else. If memory serves, the pixel where the split occurs would be shown as about 1/4 the old color, about 1/4 the logical AND of the old and new colors, and about 1/2 the new color, though as noted this is probably not consistent enough to actually be useful. While I wouldn't fault any hardware recreation that omits this quirk (it was certainly not intentional), a recreation that is trying to match the original hardware as precisely as possible should include it.