t could save some parts here, and lose some parts there.
The sort of memory that the AL422B is is designed to automatically increment the address from its clock input, so it saves an awful lot of support chips and address counters.
Not really? Where are you "losing parts"?
I mean, let's think about this. If you're trying to emulate a "normal" old computer with memory mapped video you're going to need a block of memory that can be arbitrarily random-accessed by the CPU *and* is regularly serially accessed by the display refresh circuitry to update the contents of what gets shoved out to the CRT on a time-critical basis. Again, let's get clear on what "Snow" is: it's the result of a CPU access to that shared block of memory "starving" the CRT refresh circuitry, thus resulting in garbage being loaded into the output shift register instead of it receiving the contents of the memory the display address circuitry was pointing at when the conflicting CPU action happened.
This chip you're talking about is a FIFO with two independent address counters, and "in" and an "out"; these counters can be incremented, and they can be reset. That's it. There's no random access. So obviously you can't just have the CPU write arbitrary updates directly into the FIFO's memory and treat it like a dual-port memory chip. (Which is, in the end, basically all it is.) So if you're going to try to use it to implement it as a "de-snow-ing" measure then the role you're going have to employ it for is as a cache after the "real" framebuffer to allow for the video refresh read-out to happen asynchronously. (And thereby tolerate interruption from the CPU.) Which... sure, you could do, but again,
where are you losing parts? To fill the FIFO you're still going to have a complete video address generator circuit that increments through the framebuffer memory, reads it, shoves it through a character generator (if it's not a pure bitmap), and translates it into dots. The difference is instead of those dots going into a shift register and immediately output the plan here is we're going to shove those dots into this fifo, where they're going to sit for some period and then be drawn out the other side at a fixed rate tied to the CRT sync. So what sort of changes is this going to entail?
- Our video address generator can no longer be directly linked to sync generation or other video timing goo, because that's the whole point, it's not synchronous anymore. Essentially what we need here is a generalized DMA circuit that's going to walk through the framebuffer memory as fast as possible and stuff it into the FIFO... but because, again, our point here was that we don't want to WAIT the CPU we're going to WAIT the video address generator instead.
- When the DMA is waiting because it's blocked on a CPU access obviously the "write" counter on the FIFO is blocked too. So when designing this system we're going to have to decide how far behind the output should wait behind the input. You said we're going to use two of these FIFOs, so I guess this is easy, have it stall for one frame. When you take all the blanking areas into account the active area off a computer screen isn't going to be much more than half the total vsync frame interval, so this should hopefully be sufficient to make sure the output counter doesn't catch up with the input counter. We hope.
- Because our video address generator is now incapable of generating the video sync pulses we're going to need a brand new, completely separate timing chain to generate those. This chain is also going to have to have line and row counters to generate the output clock signals for your AL422B FIFOs...
So... again, where does anything get deleted here? This reads to me like you're basically
doubling the number of counter chains in the system, and you're also adding the memory arbitration systems you'd be adding to implement wait states; you're just putting them on the FIFO fill system instead of the CPU.
FWIW, there were, back in the day, CRT controllers like the
Intel 8275H that used FIFO memory combined with DMA to cut down on the amount of overhead imposed by sharing the same block of memory between a CPU and video refresh. To be clear, this system typically stalled the CPU when it was filling its FIFOs (two 80 character line buffers), but it still cut down on contention a *lot* because it only had to stall the CPU for 80 byte reads every (however many lines tall your characters were) raster lines instead of 80
perfectly synchronous byte reads *every raster line*. Essentially what you're proposing here is building that except buffering every raster line and (hoping) the contention will always be low enough that you don't overrun your buffer on a given frame.
Considering we're talking about "vintage-like" computers here... again, just spitballing, wouldn't it make a heck of a lot more sense to just us a readily available sub-50ns SRAM (Infineon makes 512Kbyte *10ns* parts you can get 1x priced for $7.00 from Mouser) and do few little clever cycle-stretching mods to give you hitless memory access instead? (One relatively lightweight strategy could simply be "double-clocking" the memory compared to what either the CPU or video circuitry could need to access it at and use latches to give you "wiggle room" on the available access windows. That, in fact, appears to be from the datasheet what the AL422B is doing internally to arbitrate access to the bulk DRAM storage.) That would require a *lot* less in terms of changes to the original video addressing and sync generation circuitry. A modern 10ns SRAM might not be original, but it's no worse than the AL422B by that count.
