Hi
@Eudimorphodon , the 128K will rarely be used and only in special lower-speed modes, where high resolution or color are required, and most high speed graphics would occur within around 56K of screen space. To meet the original specs, I'll probably have to play with the vector routines so that there's a mix of 256x192 and 512x192 onscreen at the same time - which makes sense if you consider that I'm designing for low-resolution monitors, and the bit clock will be the same for both modes, with the number of colors simultaneous being affected by the color depth per pixel - eg, 1 byte = 2 pixels at 512, with 4 bits per pixel, and 1 pixel at 256 with 8 bits per pixel.
And yeah, that's pretty slow, but part of the spec is hardware acceleration around that, so characters can hopefully be drawn in about 8-16uS with a two dimensional DMA, and vector graphics much the same - probably around 250ns per pixel or so... I've sketched out some block diagrams and it looks doable - I just need to find the best way to assemble it with the least hardware and work out what is important. Actually, it will probably take longer just to set up a 2D DMA than to execute it -
Scrolling won't be too bad - similar, I can just set the scroll to happen via the hardware copy, and move things around pretty quickly. I'm also trying to work out whether I can preprogram various transfers into the DMA via a cache - but that might make it too complex for the PCB size constraints.
So I'm hoping that the screen routines should be reasonably fast, and since screen output can be via serial (eg, to a terminal or external computer ) or via a hook to some software that drives the hardware accelerator, I'm hoping it should be pretty quick... Or I could cheat and have multi-plane graphics, with text overlaid a graphics plane that is bit addressable.
It all depends on how I end up rolling the final design, but speed is the objective. Still, the raster can be accessed directly, and either opened as a file, or the program can page it in, in 4K sections and access directly. Either way, it is, as you note, a LOT of memory to throw around just to get a few characters on screen.
The screen isn't emulated at all, so all I/O is via simulated console port at the moment, while I write the software. I still have to finish more of the hardware design and order some PCBs and assemble pieces yet before I can get to the next stage.