Great article. It sort of reminds me of that project that "reverse-emulated" things on an NES via bus stuffing.
It also highlights how much faster modern technology is - this is software, running on a Pi Pico, that is fast enough to mimic the ROMs of old.
The sky's the limit when doing things like this on retro systems. Insert an interposer or replacement device in such a way that it can do the advanced calculations needed to present the right data to the rest of the system at the right times.
This is a demo running on the C64 Ultimate (modern FPGA recreation sold by the modern Commodore as owned by Perifractic et al) at 48MHz CPU speed, generating amazing graphics on the screen with nothing more than rewriting the background color. Sure, it's not really possible to do that on real vintage C64 hardware (as the VIC-II is clocked at ~1MHz and thus a similar thing running on a SuperCPU and original C64 would be limited to 8-pixel-wide "pixels") but it does show that when the hardware can accept the faster data rate (or if you do what GloriousCow did here and override the input to the hardware via ROM space), then you can do amazing things that would not otherwise be possible, but which are still technically being generated by the vintage hardware in the end.
In fact, I'd bet you could do something similar with the char ROM of a C64 and get a very similar effect, including the way the color/attribute RAM can stomp on the image separately.
I wonder how fun a similar project, but also replacing the actual RAM used, would be. If you could also shove data into the RAM that contains the color attributes in the same way, you could have a lower-resolution color overlay on top of your monochrome data. I don't think you'd get single-pixel resolution, but you would get single-line resolution on some platforms (C64 would require FLI code to force the chip to re-fetch every scanline instead of every 8 lines, I don't know enough about CGA to know off-hand whether it fetches every line or latches the values)
VikingCoder•11m ago
For some reason, I want to see this cartridge stuffed into one of those FPGA-based NES emulators (one that takes cartridges.)
LocalH•42m ago
It also highlights how much faster modern technology is - this is software, running on a Pi Pico, that is fast enough to mimic the ROMs of old.
The sky's the limit when doing things like this on retro systems. Insert an interposer or replacement device in such a way that it can do the advanced calculations needed to present the right data to the rest of the system at the right times.
Reminds me of things like this: https://csdb.dk/release/?id=243862 (Video here for those like me who don't own a C64 Ultimate: https://youtu.be/eub1AmT-Gys?si=GQ-CVxCqG7mrR7mG )
This is a demo running on the C64 Ultimate (modern FPGA recreation sold by the modern Commodore as owned by Perifractic et al) at 48MHz CPU speed, generating amazing graphics on the screen with nothing more than rewriting the background color. Sure, it's not really possible to do that on real vintage C64 hardware (as the VIC-II is clocked at ~1MHz and thus a similar thing running on a SuperCPU and original C64 would be limited to 8-pixel-wide "pixels") but it does show that when the hardware can accept the faster data rate (or if you do what GloriousCow did here and override the input to the hardware via ROM space), then you can do amazing things that would not otherwise be possible, but which are still technically being generated by the vintage hardware in the end.
In fact, I'd bet you could do something similar with the char ROM of a C64 and get a very similar effect, including the way the color/attribute RAM can stomp on the image separately.
I wonder how fun a similar project, but also replacing the actual RAM used, would be. If you could also shove data into the RAM that contains the color attributes in the same way, you could have a lower-resolution color overlay on top of your monochrome data. I don't think you'd get single-pixel resolution, but you would get single-line resolution on some platforms (C64 would require FLI code to force the chip to re-fetch every scanline instead of every 8 lines, I don't know enough about CGA to know off-hand whether it fetches every line or latches the values)