[TheZenPsycho]

this is way cool. I wonder if there's an easier way to find those entry points. For videoram for instance, isn't it possible to set a break point on a write to some spot in vram, and then dump stack at that point- one of the functions on the stack is going to be your "draw tile" function, no?

and how do you deal with the somewhat more complicated NES games where "sprites" are often constructed of multiple conjoined hardware sprites? there's no "draw sprite" method there, it's just manipulating x,y registers in obj ram!

[georgemcbay]

Yeah, this is really cool and the poster did a great job of writing it up and making everything available.

His bit on the legality of this sort of thing when done without permission should be ignored, though (to be fair, he does offer the standard IANAL disclaimer). If you made graphics/sound/music that were totally unique, you'd be fine, but if you made higher resolution versions of what already existed that is clearly a derivative work and puts you in copyright violation trouble, if the copyright owner cares to go after you.

Also, as you mentioned this method wouldn't work that great for all platforms; basically any older console or older console-like computer (eg. Amiga, Atari ST) tends to have much more complicated interplay between the graphics being drawn and the hardware (real or emulated) in terms of timing (eg. to vsync/vblank), having the graphics actually be low-level commands to a coprocessor, etc. Once you get to the PC era where games are generally using a relatively straightforward memcpy-type bitblt you're fine, but before that all bets are off, at the very least the code you are patching in is likely to be much more complex and fragile, if it could be made to work at all.

[ggambetta]

About the legality, for "totally new art", sure, but if I play an X-Wing remake I want Darth Vader to look like Darth Vader... and as you say, a higher-res Darth Vader would probably infringe something.

[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!