60fps Video on a CGA? – The GlyphBlaster(martypc.blogspot.com)
martypc.blogspot.com
60fps Video on a CGA? – The GlyphBlaster
https://martypc.blogspot.com/2026/05/60fps-video-on-cga-glyphblaster.html
11 comments
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)
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)
Replacing the RAM would probably be straightforward - on the CGA its only 16K, so only twice as big as the font ROM. It's slightly trickier, considering the address lines are row and column multiplexed, and there are eight sockets to tap, and you have to be able to support reading and writing.
The CGA is dumb and re-fetches memory eight times per character row, so what you could do is tie in to HSYNC, so you could basically synthesize three new address lines from the row counter. That would give you a virtual 128K of video memory - a single character cell could then have 8 different sets of foreground and background colors. You could make some pretty impressive composite art with that!
I will likely do this for fun at some point, because I want to see "Never Gonna Give You Up" in the classic magenta & cyan palette, but this is not going to be something that anyone else will likely ever do as the RAM is soldered in - and nobody but Omega-level nerds are going to de-solder eight chips for a meme.
The CGA is dumb and re-fetches memory eight times per character row, so what you could do is tie in to HSYNC, so you could basically synthesize three new address lines from the row counter. That would give you a virtual 128K of video memory - a single character cell could then have 8 different sets of foreground and background colors. You could make some pretty impressive composite art with that!
I will likely do this for fun at some point, because I want to see "Never Gonna Give You Up" in the classic magenta & cyan palette, but this is not going to be something that anyone else will likely ever do as the RAM is soldered in - and nobody but Omega-level nerds are going to de-solder eight chips for a meme.
Using the CGA as a crappy monitor - another in the series of absurd uses of modern powerful processors to do crazy things on retro hardware.
Next step is implementing 2D sprite engine. Then 3d sprite engine. Then OpenGL commands. Then getting Crysis to run on the IBM PC.
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.
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.
As trollbridge said, there isn't enough VRAM in the CGA to have 200 rows of 80 columns (2 bytes per cell - one for character and one for attribute). But it can be done in 40-column mode. As the CRTC can only do 128 rows unattended, it requires the CPU to be involved (reprogramming the CRTC several times per frame on particular scanlines) but 8088 MPH and Area 5150 did such things.
I'm 90% sure someone has done this, interrupts on each scan line.
Incredible! Such a creative hack.
This was an excellent read. It always amazes me when people discover functionality in old hardware, even if it couldn't be exploited at the time. It reminds me of "8088 MPH", the demo of 1024 colors on CGA, from 2015:
https://trixter.oldskool.org/2015/04/07/8088-mph-we-break-al...