[ggambetta]

Yes, I was thinking of adding "pixel breakpoints" (a specialized form of the regular memory watches, with some logic to convert pixel coordinates to VRAM). I didn't get around to actually doing it, but I did add a command to fill the VRAM with random data, so I could stop before a CALL, random the VRAM, execute the CALL, and see what that particular routine was doing.

NES - no idea, I've only done ZX Spectrum and PC. But you should still be able to read the emulated RAM and make a new renderer from that data.

[royjacobs]

Any machine that draws without a framebuffer (NES, C64, Atari 2600) would be pretty complex if you'd have to manually handle these timings.

However, in the NES example you could perhaps embed a NES emulator and hook into its drawing code instead. But that does mean that the emulator itself doesn't introduce any glitches or flaws of its own, of course. At least you'd be able to get some decent timing information from the emulator to properly handle sprite multiplexing and whatnot.

[boomlinde]

Minor correction, the C64 does frame buffering. Timing and accuracy is still a major concern for all these platforms, though (especially the 2600, where even horizontal sprite positioning is based on the relative speeds of the pixel clock and the CPU).

For a platform that doesn't quite viciously depend on perfect timing (or some of the simpler NES and C64 games), say like the MSX, the concept of sprites and tiles could instead be a very useful abstraction for this kind of remake. No need to deeply examine the code; just capture VRAM and video register writes.

[royjacobs]

Sorry, I should have been more accurate. I was indeed trying to refer to all the crazy raster-level tricks that people would do, to multiplex sprites, change palettes, etc

[TheZenPsycho]

not to mention things like hblank interrupt based parallax scrolling!