The Acorn Electron, trying to provide 32K of RAM as cheaply as possible, uses four 64k chips, for a 4-bit data bus. Obviously, this involves trading away some performance.

(In all the following discussion, I'm talking about outside active scan line. During active scan line, the need to share bandwidth with the display, complicates things further.)

I have seen it said that the 6502 CPU runs at 2 MHz when accessing ROM, but 1 MHz when accessing RAM. I'm interpreting this as:

The ROM was 8 bits wide, as normal, full speed access.

The 6502, having been designed by another company many years earlier, doesn't know anything about the 4-bit data bus. It issues an 8-bit transaction, and some glue logic (maybe in the big ULA?) decomposes this into a pair of 4-bit transactions. To the glue logic, the RAM is running at full 2 MHz (but only 4 bits at a time). To the 6502, it looks like the RAM is 8 bits wide, but for some reason is particularly slow, only capable of 1 MHz.

If the above is correct, then one thing I don't understand is:

Why doesn't the glue logic use fast page mode for the second nibble? The CPU isn't designed to do so, but the CPU wouldn't need to know anything about it. If the glue logic did, then the CPU would just notice lesser slowdown, like the RAM running at about 1.4 MHz?

Is there some technical reason this would not work, or am I misunderstanding the situation?

  • Fast page mode isn't supported by 1983 DRAMs...
    – Zac67
    Jan 2 at 18:53
  • @Zac67 Um? I'm under the impression it was supported by 16kbit onward, i.e. starting in the mid-70s. retrocomputing.stackexchange.com/questions/5269/…
    – rwallace
    Jan 2 at 19:07
  • 1
    @rwallace - well, in en.wikipedia.org/wiki/Dynamic_random-access_memory it states "Fast page mode DRAM was introduced in 1986 and was used with Intel 80486". Regular page mode was much earlier.
    – Jon Custer
    Jan 2 at 19:33
  • 1
    @JonCuster That's why noone should believe Wiki withotu crosschecking - or more in general, take anything with additional clauses (like here 'with 486' ) as a base fact. FPM was delivered by RAM designs way before the 486. PM/FPM/EDO RAM began to appear from ca. 1977 on, so not just before the 486, but even any x86 :)) RAM interface is an issue the memory controller handles. Not the CPU. At least until that moved into the CPU, somwhen in the early 2000s by AMD K8. The background of the 486 statement is that at the time FPM/EDO controller became part of the chipset (North-Bridge).
    – Raffzahn
    Jan 2 at 20:10
  • 1
    @Raffzahn: On the 4116, 4516, etc. it's necessary to commit relatively early after a memory cycle as to whether the next access will or will not be to the same page. Did later memories perhaps add a means of "recalling" the last page? Such a feature could improve performance of accesses that happen to be sequential without degrading the performance of non-sequential accesses.
    – supercat
    Jan 2 at 21:09

3 Answers 3


This diagram comes from page 7 of the Electron service manual:

enter image description here

As you can see, both CPU and VDU accesses involve a single RAS and two CASs. It is therefore using page mode.

  • 5
    This also explains the other half of the question: despite using page mode, it can’t run at 2MHz when accessing RAM because the VDU is using half the RAM bandwidth already. Jan 2 at 20:58

Is there some technical reason this would not work, or am I misunderstanding the situation?


First of all, it already uses PM when running at 1 MHz.

Second it's basically a 2 MHz system with the CPU running at 2 MHz, but when accessing RAM 'stretching' one cycle to give half of the bus time to video. A feature it shares with many other 6502 systems it shares the RAM with Video. Regarding RAM access the Electron thus works like any other 1 MHz 6502 system (think Commodore or Apple) (*1).

Bottom line: Using PM allows to save hardware cost (RAM chips *2) without giving up performance compared to other 1 MHz systems.

The Really Nice Part

The real nifty part comes when the CPU does not access RAM. Now the 2 MHz clock will no longer be stretched, allowing ROM access at twice the speed of RAM. Why that? Well, at that point it's useful to remember that we're talking about a BASIC machine, a setup where the CPU usually runs most of the time an interpreter stored in ROM. Exact numbers depend a lot on task and coding, but it may be safe do assume that >80% of all memory cycles will be ROM-fetches(*3). As a result a 1 MHz RAM/2 MHz ROM system will run rather similar or above to system with an over all 1.6 MHz clock.

Bottom line: Doing it this way results in

  • A System saving on hardware cost (*2) - exactly what a low(er) cost system needs.

  • A System that runs with a fixed 1 MHz cycle time for RAM access while sparing time for video. On par with most other 6502 systems at the time.

  • A System that runs at double speed when accessing ROM. Way better than most others.

  • A speed gain that does a good job in reducing influence of high resolution modes (*4).

A win-win-win-win, no matter how to look at.

*1 - In fact, in bandwith resolution (0..3?) video modes this is't enough and the CPU will be stopped during display of a video line (40 out of 64 cycles) - kinda like Sinclair ZX81 in Slow or C64 when the VICII fetches a new line

*2 - Important in a country where Sinclair is a household name :))

*3 - Best case will be all ROM instructions (immediate, branches, etc) at full 2 MHz, worst case may be Indirect Indexed or Indexed Indirect where 3 of 6 memory cycles are RAM access, resulting in 9 (or 10) 2 MHz cycles, still an effective >1.25 MHz.

*4 - IMHO the very reason why the Electron excels at high bandwidth modes compared with other machines of the same time.

  • Right, good points! I did specify outside active scan line, but you're probably right, it was designed like other 6502 systems (except Atari): on the basis that what happens during active scan line, determines the design of memory access timing.
    – rwallace
    Jan 2 at 23:59
  • 1
    "a setup where the CPU usually runs most of the time an interpreter stored in ROM." a luck that Acorn wrote their own interpreter. Microsoft's 6502 based interpreter had its main interpreter fetch routine in the zero page using self modifying code CHRGET. Jan 3 at 15:01
  • 2
    @PatrickSchlüter: Only a tiny fraction of a typical program's execution time will be spent in CHRGET. When processing "FOR I=1024 TO 2023:POKE I,X:NEXT", CHRGET will get called 7 times per loop, but each execution of the loop will take thousands of cycles.
    – supercat
    Jan 3 at 22:09
  • 2
    @rwallace The behaviour is the same within or outside scan lines (ignoring the high band with modes for that). CPU always gets one 2 MHz clock cycle, while the other goes to Video - no matter if it uses it or not. Now looking at this, one could of course throw some hardware at it and also give the CPU the other cycle, whenever video doesn't need it. That might speed up RAM access in average by some 30-40% - but in average result in less than 10% speed gain. Not bad, but also not really worth it. Though, could make a nice (late) hack :))
    – Raffzahn
    Jan 4 at 15:00

The short answer is; based on the used RAS and CAS waveforms, it already uses page mode for accessing a single byte with two concecutive page mode cycles.

The RAS goes low once to open a row address and during the RAS low time the CAS strobes low two times for accessing two different column addresses in the same row. If it did not use page mode, there would only be one CAS pulse during a RAS pulse.

You are correct that the 6502 does not know what kind of memory it has.

And the glue logic, the ULA, does convert a single byte access from 6502 into two 4-bit page mode transactions.

The RAM memory has a bandwidth of 2 MHz like the ROM, but the RAM bandwidth is required to be shared the bandwidth with video system and 6502.

So every other RAM bus cycle is given to MCU and every other to video system. This is why each system gets guaranteed 1 MHz bandwidth completely independently.

And the CPU is still limited to 1 MHz even if video system does not require the full 1 MHz bandwidth.

  • 2
    N.B. I was editing the answer to be correct while the erroneus answer received a downvote. I wish there was a comment for the reason of the downvote.
    – Justme
    Jan 2 at 21:54
  • 2
    Original was definitely wrong, but I'd say there are still some false information (or at least not set into the right relations.). For example ROM has to be good for 4 MHz to work in a 2 MHz 6502 system. Likewise the RAM has to be close to 3 MHz as it needs to do 4 access within one 1 MHz cycle (two full, two PM). All nicely shown in Tommy's diagram.
    – Raffzahn
    Jan 2 at 22:14
  • @Raffzahn The ROM is accessed by the 2 MHz 6502 and it needs to be fast enough to work with that. I never claimed how capable the ROM is as it is not said in the service manual, but just at what bandwidth it is being used. The Hitachi HN613256PC23 is rated for 250ns access time and read cycle, so 4 MHz. The DRAM access time is 150ns, and has single cycle time of 260ns and page mode cycle time of 145ns, at least for the TI parts used in it, so a tad below 4 MHz even without page mode.
    – Justme
    Jan 2 at 22:51
  • 1
    Well, even reading it a second time, I still see 2 MHz mentioned as feature of RAM and ROM, which is simply misleading. A 2 MHz 6502 needs the full 4 MHz bandwidth to make it work. The fact that it leaved it half the time unused does neither change requirement nor usage pattern. Likewise it still states that each 'side' using the RAM gets 1 MHz bandwidth, which again is not true, as they each do two 4 bit access per 500ns. So unless you straighten the numbers (maybe just read them from above diagram), I would see this answer creating more confusion than answering the question.
    – Raffzahn
    Jan 2 at 23:09
  • 1
    @Raffzahn I am quoting the service manual. ROM is accessed with 2 MHz 6502 and for RAM accesses it runs at 1 MHz. That does not anywhere imply anything else for the speeds other than the bandwidth the memories are used, memory accesses per second. CPU can access DRAM byte once per 1us, so can video system, totaling up to 500ns cycle time per byte or 2 MHz. Two tranfers in page mode per byte. What are you confused about that? How it should be written then?
    – Justme
    Jan 2 at 23:18

You must log in to answer this question.

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