Bdtjtk

If a home computer or console has two banks of memory, A and B, then the following design is possible:

The video chip only connects to bank A. The CPU connects to both. During active scan line, CPU access to bank A is slow because it must share bandwidth with the video chip, but it can access bank B at full speed. This is useful because you can put code and non-video data in bank B, though the CPU will still hit some slowdown because it must write to bank A in order to prepare the next frame while the current one is showing.

The Amiga is perhaps the best-known example of this design; the two banks were called chip memory (the first 512K) and fast memory (the rest), respectively. The 48K Spectrum was also a popular example; the two banks were the first 16K and the other 32K respectively.

It seems to me you could improve performance with a variant design: as above, except the video chip and the CPU each connect to both banks.

In the first frame, the video chip displays from bank A while the CPU prepares the next frame in bank B.

In the second frame, the video chip switches to displaying from bank B while the CPU prepares the next frame in bank A.

In the third frame, it switches back to the first arrangement, etc.

It seems to me this fairly minor variation on the historical design would allow the CPU to always work at full speed even when writing the data for the next frame. (In this context, I'm just thinking about scenarios where the CPU does that work, not ones where the video chip itself contains acceleration hardware that writes to video memory.)

Did any historical machines work the way I suggest, with video chip and CPU switching back-and-forth between two banks each frame? If not, why not? Is there some disadvantage I'm not taking into account?

Did any historical machines work the way I suggest, with video chip and CPU switching back-and-forth between two banks each frame?

Not that I'm aware of. There were many designs with multiple banks, but never set up especially in the way that you ask for.

If not, why not? Is there some disadvantage I'm not taking into account?

Maybe because it's a very narrow solution for a problem that didn't really occur?

First of all, the influence of video access on a CPU is for most cases negligible. That is if there is already a separate bank, where the CPU can execute program/data without being slowed down by video. Even in a close loop CPU access to video memory is more in the region of every 10th cycle or less (*1), thus, if a video circuit allows at least some video access during display, no significant performance impact happens. Since most transactions on video memory are writes, a single write buffer may already provide a great relief.

Second, this solution will only speed up programs that use a two buffer based rendering scheme. They are a rather new development, only introduced with CPU/GPU setups fast enough to render a whole scene within 1/50th of a second or less from base data. Nothing early machines could do. Here it was faster to just manipulate the existing, single screen. Heck, real early ones had to use sprites as a crutch to overcome speed issues.

Third, use of double buffering isn't primarily (if at all) a solution to avoid performance slow down by video access during screen manipulation, but to avoid flicker. Double buffer handling does at first increase handling effort, as either full rendering or interleaved update (*2) is required. Its advantage is a decoupling in timing (below the level of a frame) between display and update (*3). With two buffers the CPU no longer needs to synchronize sequence and speed of screen update with video. Even frame drops are possible - not nice but possible - without harming the presented picture.

*1 - Yes, tighter examples can be constructed on several machines, but they are the exception in everyday tasks.

*2 - This means, when updating a buffer (the one not displayed), it does not represent the previous frame, but the one before that, so two counts of update related bookkeeping need to be held and managed. This can make code rather complicated - usually resulting in abstract engines - something again easy to do today, but hard to implement on power constrained systems back then.

*3 - With a single display buffer updates have to happen complete during retrace, or 'following the beam'. This means that during a frame only the parts that have already be displayed can be changed without generating flicker or ripple. The hurdle is to use as much time as possible, so keeping close to the line in display, but never overtake the video circuit. This includes looking ahead when it's about sprites and alike.

The Apple IIe with 80-column text card was capable of something like this. It came with a second, 64K memory space available through bank-switching. From page 23 of The Apple IIe Technical Reference Manual:

Data for the high-resolution graphics displays are stored in either of two 8192-byte areas in memory. These areas are called High-Resolution Page 1 and Page 2; think of them as buffers where you can put data to be displayed.

There were separate latches between the main memory and the alternate memory space and the display controller, and in double-high resolution, you would enable both latches, interlacing the bitmaps stored in each buffer. The two halves of video memory were split between $2000–$3FFF of the main memory space and the alternate memory space. See page 35 of the manual, among other places.

The Apple IIe did not, however, give faster access to banks of memory the current video mode was not using.

In my opinion it's a system design question:

• At the time of relevance of this question RAM was expensive, so storing a sequence of images directly in RAM for any significant sequence length was prohibitive if you intend to build a cheap system, so lets go with 2 frames




• For cheap system the read/write speed (i.e. a Z80 or 6510 even only copying data to you video banks - probably in the 200kB/s range for a Z80, and on the order of 50-100 for a 6502) would be limited by the CPU/data bus (the DRAMS had access times significantly below 1 microsecond), meaning that storing 2 Frames wouldn't really help you a lot (since you could not update the buffer one more time)

The only way out to make sense of such a system would have been to give it multiple CPUs connected to one video buffer each. So that means that for a typical 8 bit system, the solution would not have helped much in any use case. I am unsure if specialized expensive video/graphics equipment did something like this (I could imagine that).

Relatively few programs update the entire display every frame. When using a double-buffered display, anything that will be shown on two or more consecutive frames will need to be updated at least twice; it would be rare that writing something twice on inactive banks would be cheaper than writing it once on an active bank.

A somewhat more useful variation on your proposal would be to have one memory bank for the top half of the screen and one for the bottom. Many of Eugene Jarvis' games like Defender, Stargate, Robotron, etc. would write the bottom half of the screen while the beam was on the top half, and vice versa. I don't think the hardware used separate banks with the described access timings, but doing so would have made it possible to use slower DRAMs than would otherwise have been required.