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)
For some reason, I want to see this cartridge stuffed into one of those FPGA-based NES emulators (one that takes cartridges.)
I wonder if there's a way to turn the attributes (background and foreground color) into 8x1 cells.
You can set the character height to 1, and can actually make the width of each cell 4 without any attribute clash issues.
Since the card only has 16,384 bytes of memory, you can only get 102 rows this way. With a 4x2 cell, you can fill in the whole 200 rows of the display (still 100 rows, but each row is doubled.)
The CGA always runs at 60 hz, and strangely enough, does not send out an interlaced signal, so it really does run at a true "200p" resolutionm, 60 hertz non-interlaced. Don't be confused by the fact the CGA's graphics layout is arranged in an interlaced fashion - it does that because the CRTC can't address more than 128 rows, so with the row height set to 1 scanline, the CRTC is "recycled" for the second pass.
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.
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)
For some reason, I want to see this cartridge stuffed into one of those FPGA-based NES emulators (one that takes cartridges.)
I wonder if there's a way to turn the attributes (background and foreground color) into 8x1 cells.
You can set the character height to 1, and can actually make the width of each cell 4 without any attribute clash issues.
Since the card only has 16,384 bytes of memory, you can only get 102 rows this way. With a 4x2 cell, you can fill in the whole 200 rows of the display (still 100 rows, but each row is doubled.)
The CGA always runs at 60 hz, and strangely enough, does not send out an interlaced signal, so it really does run at a true "200p" resolutionm, 60 hertz non-interlaced. Don't be confused by the fact the CGA's graphics layout is arranged in an interlaced fashion - it does that because the CRTC can't address more than 128 rows, so with the row height set to 1 scanline, the CRTC is "recycled" for the second pass.