Ykhjuy

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 where many designs with multiple banks, but never set up especially in a way as 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 occure?

First of all, the influence of video access on a CPU is for most case neglectable. That is if there is already a separate banks, where the CPU can execute Programm/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 primary (if at all) a solution to avoide performance slow down by video access during screen manipulation, but to avoide 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 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 an the exemption in every days 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, 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 keep clode to the line in display, but never overtake 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 from the main memory and the alternate memory space on the expansion card, 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.