The KM684000BLP-7L (70ns Low Power) 512K RAM chip used here provides more memory than needed, and requires a paging scheme to access it all. A single 32K RAM chip would still be plenty. Other types of RAM could also used. A dynamic RAM interface would allow megabytes of RAM, but I can't think of a useful application in this project. Anything that requires a lot of memory will probably consume a lot of CPU time and thus run very slowly on a 1.79 MHz CPU.
The Atom firmware still has anti-snow features, such as waiting for the vertical blanking period before scrolling the screen. This may also be an aesthetic measure to ensure that partly-scrolled screens never appear. I have not investigated to find out all the places where such waiting occurs. I suspect that it probably does not happen for all accesses, since this would slow things down when a lot of accesses are required. The firmware could be tweaked to remove waiting in some routines, thereby increasing the screen access speed.
The CPU address space is smaller than the 512K RAM, so the extra memory is paged.
CPU space VDU space 0000-3FFF RAM 4000-7FFF 16K page (0 to 32). = 1 by default 8000-9FFF 8K page (0 to 63) = 4 by default 8K page (0 to 64) = 4 by default => to display A000-FFFF ROM and I/O
There are three independent paged areas:
This paging architecture increases the graphical abilities. For example, the CPU can clear the screen, then select another page. It can then clear that page and draw an image there. The VDU continues to see the first (cleared) screen. After drawing the complete image, the CPU can tell the VDU to display the page containing the image. A human viewer will perceive this as being drawn 'instantly', though of course it was not.
An extension of this is to draw a series of images, then cycle through them to produce a short animation. This could have a start and an end like a 'flicker book', or be an endless loop like a juggler or a galloping horse as often seen in old zoetropes:
With 512K RAM less the 32K system RAM, there is 480K free. This is enough for sixty 8K pages, i.e. 2 seconds animation at 30 frames per second (NTSC) or 2.4 seconds at 25 frames per second (PAL).
A good tip is to keep the user's attention elsewhere when the CPU has to be busy. For example, you may need to spend a lot of time preparing a short animation sequence for a zooming star field (as per the Millennium Falcon entering hyperspace). Instead of displaying a message "Please wait... busy.", you can display a screen showing engine activity and perhaps explaining what the pilot should watch out for at the destination. By the time the user has read it, the preparations should be ready.