Did any machines alternate between two video memory banks?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

Yes, such computers existed. First of all, we must remember about Agat, the Soviet almost-clone of Apple II. The native Agat-8 video mode (not compatible with Apple II) allowed using a memory page (one of many, with the ability to quickly randomly switch) for the video buffer that was disconnected from the address space of the processor. Later versions (from the mid-90s) of semi-home-made (small-scale, handicraft) post-Soviet home computers relatively often used a similar architecture.

Answer 4

The Sega Super Scaler series arcade machine boards did this, to a certain extent. They used multiple processors to update sprites while they were off screen. For example the Y Board had three 68000s sharing multiple RAM banks, two of which held separate sprite banks. The later System 32 had 768 K of dual-ported VRAM set up for sharing between the V60 main processor and the graphics chips. The Super Scalers were essentially sprite based, however, so their entire display wasn't buffered by simple page flips.

In the 8-bit world, the Amstrad CPC used 6845 CRTC registers 12 and 13 to define the screen memory address. One could page flip between them very quickly (by alternating between &4000 and &c000, say), but this would use half the available RAM of the computer for display and you'd still have to redraw in time for the screen refresh to keep the display smooth.

Answer 5

The BBC Master was designed with a fairly complex memory-map overlay system. There was 32KB of primary RAM, 128KB of ROM, four 16KB "sideways RAM" banks which could be loaded with ROM-like data from disk, and a 32KB "shadow RAM" bank which was used to move the video display and the disk filesystem workspace out of the primary RAM. This left much more of the primary RAM available for user programs than in the earlier BBC Microcomputer, with which it remained mostly compatible.

The "shadow" system could be switched off at runtime, so that user software could write directly to the video RAM, as was common for games which found the operating system graphics routines too slow and restrictive. It was also possible to use the primary and shadow RAM alternately for double buffering.

Quoting https://github.com/simondotm/bbc-shadow-ram :-

; Accessing & controlling the Shadow RAM is achieved using the Access control register (ACCCON) at &FE34 
; See page 162 of the New Advanced User Guide (http://www.msknight.com/bbc/manuals/new-advanced-user-guide.pdf)
; Bit 7 - IRR - IRQ control
; Bit 6 - TST - always 0
; Bit 5 - IFJ - 1MHz bus/ROM cartridge select 
; Bit 4 - ITU - TUBE select
; Bit 3 - Y - 8Kb RAM function select
; Bit 2 - X - Main memory RAM source select
; Bit 1 - E - VDU Driver RAM Source select
; Bit 0 - D - CRTC RAM Source select


; D=0 Use main memory for screen, D=1 Use Shadow RAM for screen (contrary to what is specified in AUG)
; E=0 VDU Driver uses Shadow RAM, E=1 VDU Driver uses main memory
; X=0 Normal RAM in main memory, X=1 Shadow RAM in main memory
; Y=0 8K RAM at &C000 to &DFFF, Y=1 VDU Driver code at &C000
; ITU=0 enable external TUBE, ITU=1 enable internal TUBE
; IFJ=0 1Mhz bus at &FC00 to &FDFF, IFJ=1 cartridge at &FC00
; TST=0 normal state (do not change), TST=1 hardware test
; IRR=0 after IRQ processed, IRR=1 IRQ to CPU

; so double buffer rendering works as follows:
;   D=0,X=1 - Display from main memory, Draw to shadow memory (&3000-&7FFF)
;   D=1,X=0 - Display from shadow memory, Draw to main memory (&3000-&7FFF)

The BBC Micro & Master hardware could access video memory at full speed from the CPU and display hardware simultaneously, so this alternating technique was not necessary for high performance at all. It was simply a secondary use of a system designed to optimise the layout of a limited address space.

Answer 6

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.

Answer 7

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).

Answer 8

An interesting proposal... I do wonder if we may have seen the like if other advances hadn't made it irrelevant. For instance, in the case of the Amiga (and somewhat, the Atari STe) as well as a lot of consoles, the main things that this design would accelerate are instead cared for quite well by hardware scrolling, sprite engines (and/or general blitters), palette manipulation and special effects such as halfbrite, shadow/highlight, tinting etc. All of which make tactics like doublebuffering, and so the additional speed of writing to two separate, switchable memory buffers, mostly or wholly unnecessary. On the PC side, we have Window Accelerator functions which can draw into the active display memory (e.g. the 256KB of a VGA, which is insufficient to hold two separate pages at any resolution above 640x400) fast enough that most routine functions can be completed in less than a single frame scan.

(That said, in lower resolutions, I have a feeling VGA, possibly even EGA can be set up to operate almost exactly as you describe ... with the difference being, of course, that they don't provide most systems with any kind of CPU-executable RAM. But they can be chained so that their memory space is divided into two or more entirely discrete buffers, one of which can be written into without any kind of performance penalty, even with regular single ported DRAM, whilst another is being used to construct the display... at least, if I'm remembering things correctly. It might be that they still have contention but just hide it really well through FIFO buffering and simply being much faster than most other home computer chipsets...)

Answer 9

The Soviet home computers Elektronika BK-0011(M) had 2 video pages. For some reason, the English page does not mention that fact, only the Russian one does:

две страницы памяти можно было поочерёдно отображать на экран, что обеспечивало мгновенное обновление информации

which means (Google translate)

two pages of memory could be displayed alternately on the screen, which provided an instant update of information