Other threads reminded me that one good use of a large bank of RAM is for storing a framebuffer. It also appears that most conventional VRAM chips have gone out of production - they are long obsolete for commercial purposes, and yet too advanced for most hobbyists to make use of. So we're left with trying to do something useful with conventional DRAM.

I'm going to assume a relatively ambitious SVGA timing here; a 48MHz pixel clock for 840x525 @ 75Hz. This would map very nicely to my natively 1680x1050 Sun monitor, and would allow putting a coloured border around an 800x512 active framebuffer. I'm also going to try and keep using that standard 24MHz master clock. Using a variable-frequency oscillator would allow more flexibility in setting up the output, but assuming a specific use-case should help in defining the problem more clearly.

The 50ns EDO DRAMs we've been discussing are fast enough to produce 16 bits per 24MHz clock in fast-page mode, and they'll hold their output steady even after /CAS goes inactive (that's what EDO means, versus FPM). We should therefore be able to latch 16 bits at the same time as we pull /CAS high, present one 8-bit half of that to the CLUT and thus to the RGB DACs while /CAS stays high, then present the other 8-bit half when we pull /CAS low to retrieve the next pair of pixels.

Each row of the DRAM is 2048 bytes, so we can dump out a complete 840-pixel row of pixels without needing to change rows in the DRAM, and there's even scope for smooth (2-pixel) horizontal scrolling. There are 1024 rows in the DRAM, which is twice as many as we technically need for 512 active rows of pixels, even if we dedicate a whole DRAM row to each pixel row (when we could actually squeeze two pixel rows into each DRAM row). This adds a lot of flexibility for hardware effects.

All we need is a presettable 10-bit counter to present column addresses from, another to figure out horizontal timing, and yet another to coordinate vertical timing. Some auxiliary memory is also needed to set up these counters per row, with the correct DRAM row and column to start on, the correct front and back porches and border widths…

DRAM refresh is straightforward - we just need to include two DRAM auto-refresh cycles in each horizontal blanking interval, perhaps on the rising and falling edges of HSYNC. That will cycle through every DRAM row (and then some) in every frame, which at 75Hz is within the required refresh period. For configurable video timing, something more flexible would need to be arranged here, so that the correct number of auto-refresh cycles get issued per scanline.

What's less straightforward is arranging for updates to the framebuffer. The DRAM is effectively unavailable for this while scanning out pixels, but in principle it should be possible to work around this with minimal complexity, by forcing CPU wait-states if an access is attempted during this time. Alternatively, writes could be directed into a FIFO so that only reads normally need to be wait-stated. But if we're implementing a FIFO…

…why not introduce a small microcontroller as a video coprocessor? The DRAM chip itself comes in a TSSOP package, so a QFP-48 MCU - available for about €1.50 - should provide enough I/O pins to both drive the DRAM for writing (and R-M-W cycles) and interface to the 65xx bus to be fed commands and image data. An 8-bit interface to the DRAM should be sufficient since it still allows writing two pixels in parallel (just open both halves for writing with common data) for fast fills, though R-M-W cycles for bit-masked updates will take longer. The MCU can buffer commands from the CPU while the DRAM is busy, and act on them when the blanking interval arrives.

Now, I wonder whether the MCU's internal clock sources and timers can sensibly be used to reduce the amount of external logic needed for the main scanout function…