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?

  • 4
    Given that serial accesses are more likely than not, I always wondered why a design didn't use the low bit of addressing to select a RAM bank, and halt the CPU only if it is accessing the same one as video that cycle. But I think the answer always ends up back at fixed memory maps and caution about growing RAM sizes: it's impossible to consolidate two distinct banks of chips into a single bank if both need to be accessed simultaneously.
    – Tommy
    Commented Dec 31, 2018 at 22:09
  • 4
    It's an interesting question. The cost and performance should be compared with dual ported RAM which achieves the same result. Commented Dec 31, 2018 at 22:12
  • 1
    @tofro Why? It's a general and accurate description – or, are you thinking of some more specialized usage of the term, that would not be applicable in this case?
    – rwallace
    Commented Dec 31, 2018 at 22:46
  • 3
    @tofro Erm. AFAICR he nevver says 'banked', only 'bank (of memory)'. These terms are not interchangable. A bank of memory is a seperate memory entity (usually seperate chips). It does not denote where (and when) it's located within a certain address space. In contrast 'banked' denotes a system where multiple banks share the same address space. So yes, the Amiga does have memory banks, and no, it is not a banked system.
    – Raffzahn
    Commented Jan 1, 2019 at 0:45
  • 1
    this scheme actually requires 3 banks of memory to work: a pair of banks for frame buffers which are switched between, and a third bank for program data (and code). there are a lot of other things a program does besides accessing video memory, including the CPU reading the program instructions themselves from memory.
    – Ken Gober
    Commented Jan 2, 2019 at 14:01

9 Answers 9


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.

  • Many of Eugene Jarvis' games for William Electronics would write the top half of display memory while the beam was scanning the bottom half of the screen, and then write the bottom half while the beam was scanning the top half. Since the machines debuted in an era before 64K DRAM chips became common, I would expect the upper and lower 16K of display memory could have been in separate banks, though whether the buses were separated to allow CPU access to one concurrent with display access to the other I don't know.
    – supercat
    Commented Mar 10 at 19:29

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.

  • 6
    Though you get the same memory access speed regardless of which banks are on display.
    – Tommy
    Commented Dec 31, 2018 at 23:22
  • @Tommy Good point.
    – Davislor
    Commented Jan 1, 2019 at 0:00
  • @Davislor: The use of two separate memory banks made it possible for the system to accommodate three memory operations per cycle using banks of memory that are only fast enough to accommodate two. I think the video fetches are done simultaneously rather than interleaved, but the concept is sound.
    – supercat
    Commented Jan 1, 2019 at 18:46
  • @supercat The manual shows the timing and signals, so yes, that’s what the latches are for. To clarify: the design doesn’t give faster CPU access to the unused bank than to the used bank in single high resolution mode.
    – Davislor
    Commented Jan 2, 2019 at 0:36
  • 1
    @Davislor: If the Apple had used one bank of memory on one frame, then one for the next, etc., clocking out data at the rate required for a maximum-resolution display, the CPU would have times when it would be able to access things at ~2MHz, but long intervals when it would get no access at all. Fetching a byte from each bank every ~microsecond minimizes the length of time between main-CPU access opportunities.
    – supercat
    Commented Jan 2, 2019 at 18:05

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.


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.

  • Interesting that the arcade used a V60. Regarding the CPC, I guess page flipping doesn't really fit the question, as it's about independent access due separate pages, isn't it? Page flipping was present with many computers - just take the A2.
    – Raffzahn
    Commented Oct 28, 2019 at 20:22
  • I think page flipping does fit the OP's "video chip and CPU switching back-and-forth between two banks each frame" part of the question. X11's DBE might also qualify too.
    – scruss
    Commented Oct 29, 2019 at 0:33
  • Not really, reading close shows that the questions background is about avoiding shared access, so CPU and video can access their respective buffer at full speed without having either (usually the CPU) wait - like the spectrum does. Page flipping does still have CPU and video share the RAM.
    – Raffzahn
    Commented Oct 29, 2019 at 1:57

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.


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.


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

  • I don't get that. I was referring to the fastest copy operations which would be possible on such a CPU, given a fast bus speed. In the CPU cant write the data faster, then having different buffered for different frames does not solve a problem for most use cases.
    – Sascha
    Commented Jan 1, 2019 at 18:42
  • Whoops. Misread your answer. It's fine! Carry on.
    – wizzwizz4
    Commented Jan 1, 2019 at 18:42

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


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .