Presently, the only technical information regarding the Acorn Electron available anywhere online is except for the officially sanctioned Advanced User Guide (from now on referred to simply as the AUG, and available from the BBC Documentation Project). However the AUG is mostly aimed at explaining the various OS calls, and the few sections that deal in the actual hardware information leave most information either ambiguous or simply absent.
I don't have any documentation besides the AUG myself, but in order to get my Electron emulator (ElectrEm) working I've figured a lot of stuff out - my implementations being at least as similar to the real hardware as is necessary to fool 99% of all software, including the Electron OS itself. In this document I attempt to share what I have assumed to be true in order to implement my emulator.
So don't take any of the information presented here as gospel, and if you know explicitly different on even the smallest point then e-mail me, but otherwise this is probably the closest to correct technical information on the Acorn Electron publically available.
This document will be updated as I gain better information, but the assumption that any better information will ever turn up on this long dead and little documented micro is a great one.
This document is best read with a copy of the AUG - electronic or otherwise - to hand, as I have endeavoured not to repeat most of the (correct) information offered in its chapters 13 & 14.
It probably won't help anyone at all much, but the insides of an Electron can be seen on the 8bs public domain software site at this location.
The Electron CPU is a SynerTek 6502A (part code SY6502A). This particular model of 6502A was presumably chosen because it can survive with a halted clock for 40us without losing its state.
Although a 6502A should only be clocked at 1.79Mhz, I've yet to find anything to disprove the AUG's belief that its maximum clock rate is 2Mhz. Indeed, I've had success with emulating a number of games which rely quite heavily upon cycle timings assuming 2Mhz is correct, so I'd go further and agree that while the Electron is running, there are periods when the CPU clock is 2Mhz.
Although some people (particularly on the BBC Micro mailing list with specific attention payed to coding an Electron version of the BBC Micro's 'Zalaga') seem to think the undocumented opcodes of this 6502 are fairly unique, David Boddie claims :
"Paul [Boddie] and I have been working on one or two of the "undocumented" opcodes, and they do seem to be very similar to those documented for other 6502 variants. Certainly, 0x1f and 0x1b are basically ASL of a memory location followed by ORA of this result with the accumulator. The C, N and Z flags are affected by this. Documentation for this instruction is available from various places. I found some useful information by using Google to search for something like "6502 opcodes"."
And suggests reference to these links :
The only other logic bearing chip in a non-upgraded Electron is the ULA. This handles sound generation, graphics output, tape data input/output, ROM paging and interrupts.
The ULA has 15 registers, each of which resides in RAM page FE. When the ULA decodes this address it ignores the top nibble. Notice that reading from a write only register simply results in a read of the underlying ROM byte. In a real machine, Acorn have left a copyright message and some credits in the ROM over pages FC, FD and FE, but in most OS dumps available online this message is missing.
Register by register :
This appears to be two registers in one location. The interrupt status register, which is read, and the interrupt control register, which is written to.
When any part of the ULA (e.g. the tape interface or the video circuits) wants to generate an interrupt, it takes its personal interrupt line high. The line will remain high all the time it is generating an interrupt. It is these lines which are read to get the interrupt status byte. Any that are high result in a 1 in the relevant bit of the interrupt status register. Otherwise a 0 is present. The most significant bit is always set, and the least significant bit (master IRQ) is set if any of the devices currently enabled is requesting an interrupt.
The 'power on' bit is set when the machine is first switched on, but is reset the very first time the status register is read.
Writing values to the two lowest bits appears to have no effect.
These function pretty much as the AUG states. Notice that the bits in FE02 marked '0' should be considered to be 'X's, since they do not need to be set to '0' - any of them can be set to '1' with no ill effects.
There is one quirk with the screen start address. If address 0000 is loaded, it is immediately replaced with a hardcoded 'minimum' screen start address which depends upon the graphics mode. Similarly, if when drawing the screen the (15 bit) address counter overflows, this mode specific start address is assumed instead of 0000.
However, interestingly, it seems that setting an address below the mode specific start address causes the display to be taken from that address - so the region [mode start address, 32768) is not absolutely enforced.
The mode specific start address is simply derived from the number of bytes a full screen in that mode occupies, as follows : &3000 for modes 0,1 and 2, &4000 for mode 3, &5800 for modes 4 and 5, and &6000 for mode 6.
As you would expect, screen start address is read once at the start of frame, and any alterations from then on do not come into effect until the next frame.
This register acts mostly as described in the AUG, but with one major difference - the bits move exactly the opposite way to that described.
i.e. a new bit coming from the tape appears in bit 7, and makes its way towards bit 0, and when writing to tape, bit 0 is written, then all the bits move down one.
My information is based upon the bit ordering in bytes saved on cassette - I don't know where Mark Holmes and Adrian Dickens (authors of the AUG) got their information.
This operates exactly as specified in the AUG. To tie together the information on paged ROMs though, the rule for paging appears to be simply this : if roms 0-7 or 12-15 are currently paged, any value written to the paging part of this register will be honoured. If ROMs 8-11 are paged, only values of 8-15 are honoured.
I'd imagine this strange rule holds so that when BASIC (roms 10 & 11, only 1 ROM but it appears in two slots) is paged in, as it normally will be, interrupt clearing can be done simply by writing a word with the low nibble as all 0's, without having to worry about accidentally paging out the current ROM.
As for the keyboard (ROMS 8 & 9, but again only 1 'ROM'), the key lines are arranged like this :
| Bit 3 | Bit 2 | Bit 1 | Bit 0 | |
| Line 0 | space bar | copy | right cursor | |
| Line 1 | delete | return | down cursor | left cursor |
| Line 2 | colon | up cursor | minus | |
| Line 3 | forward slash | semi-colon | p | 0 |
| Line 4 | full stop | l | o | 9 |
| Line 5 | comma | k | i | 8 |
| Line 6 | m | j | u | 7 |
| Line 7 | n | h | y | 6 |
| Line 8 | b | g | t | 5 |
| Line 9 | v | f | r | 4 |
| Line 10 | c | d | e | 3 |
| Line 11 | x | s | w | 2 |
| Line 12 | z | a | q | 1 |
| Line 13 | shift | ctrl | func | escape |
(both left and right shift are mapped onto the same spot in the keyboard map)
i.e. for any address read in the keyboard range while it is paged in, the return result depends upon the low 13 address lines. If only of them is low (0), then a byte is returned with the high nibble equal to 0, and the low nibble arranged such that a '1' is in any bit where the corresponding key from the above table is depressed. If more than one address line is low, the result is the logical OR of all the lines specified.
The result for the bits with no keys defined is always 0.
The counter operates as stated. No matter what value you write to it in tape read/write mode, those modes appear still to function.
Now, a few notes about the speaker. Of the possible frequency settings generated by the 256 possible values written to this register, it is worth noticing that the two lowest are inaudible to the human ear. Thinking in terms of a discreet sound wave incapable of storing inaudible frequencies, both of these settings produce a constant output level distinguishable from if the speaker were off.
Therefore, by setting this register to 0 or 1, it is possible to use the speaker virtually as a simple on/off toggle device, as on the ZX Spectrum, for example.
Operates as stated. And further :
The 'not used' counter mode appears to mean a mode where the counter isn't used by any other device, rather than a particular bit combination which is 'not used' - i.e. the ULA wouldn't recognise it as a counter mode.
Attempting to set the display to mode 7 results in mode 4. Mode changes take effect at the end of the current scanline, although I have yet to determine the effect on internal counters of switching, e.g. from an 80 byte mode to a 40 byte mode in the middle of an 8 scanline block.
these operate exactly as specified.
Timing is an interesting issue on the Electron. This is what I have been able to determine.
As specified in the AUG, when accessing the ROM or keyboard areas, or the ULA registers, the CPU is clocked at 2Mhz.
When accessing RAM in modes 4-6, the CPU is simply clocked at 1Mhz. Since the ULA must move the CPU clock from the 2Mhz clock down to the 1Mhz clock, from time to time (on average, every one time in two), a 2Mhz clock cycle is lost waiting for a time when the transition is possible.
In modes 0-3, attention must be payed to the current activities of the video circuits. If they are in the middle 5/8ths of the time between one HSYNC and the next, then attempting to access RAM causes the CPU clock to be stopped until the video circuits exit that region. Access to RAM at any other time is at 2Mhz.
Assuming a constant 2Mhz clock, the video circuits generate 312 scanlines a frame, one scanline every 128 cycles. This actually gives 50.08 frames a second.
Creating a scanline numbering scheme where the first scanline with pixels is scanline 0, in all modes the end of display interrupt is generated exactly upon the HSYNC at the end of scanline 255, and the RTC interrupt is generated upon the HSYNC at the end of scanline 100 . VSYNC is not signalled in any way.
The AUG is very confused on this matter. Besides the error in which way the bits travel within &FE04, it seems to have the tape data full and data empty interrupt enable/status bits (in &FE00) oppositely named. Or else the Electron OS is enabling the 'data empty' interrupt whenever you try to load something.
Some other things which just aren't made clear - the tape data register full interrupt is disabled when that register is read as well as when the next bit comes along and it loses data.
The tape data register empty interrupt is only cleared when that register is written to. This interrupt is enabled immediately upon entering tape write mode, and at all points while it is enabled high tone (effectively identical to a stream of '1's) is output to tape.
Data is always saved at 1200 baud. This is actually more likely to be 1000000 / (16*(51+1)) = ~1202 baud, but audio tapes stretch and so any preciseness of figure cannot be relied upon.
Data is saved as bytes, each with a start and stop bit - i.e. every 10 bits 1 byte is read. Each bit lasts the same amount of time on a tape (1/1200th of a second for 1200 baud), and in that time a 0 is encoded as a single high/low, whereas a 1 is a high/low/high/low in the same amount of time. Unlike most other micros, tape data is encoded with a sine wave. A total byte is stored as 0 (the start bit), bit 0, bit 1 . . . bit 7, 1 (the stop bit).
The Plus 3 (and the Advanced Plus 3 also, the only difference from the Electron's viewpoint is the attached ROM) is simply a WD1770 drive controller without its interrupt line connected.
The WD1770 occupies the address range FCC4-FCC7 (inclusive), and in addition a Plus 3 specific drive control register is provided at FCC0, although I have yet to determine its layout.
From gARetH baBB, correcting my idea that turbo mode consisted of 32kb of 2Mhz RAM and that 'shadow' mode used paged ROM slots:
"[With the MRB] There are 3 modes, off, "Turbo" and "Shadow".
Turbo used the normal Elk OS, but supplied an overlaid 8k of as you say 2MHz memory access from 0 - Slogger before the MRB had a turbo board which just had this mode. The original turbo design actually came out of Acorn.
Shadow overlaid the full 32k of normal RAM and used it's own OS to provide the neccessary support to get at the underlying screen memory which was used by the ULA and obviously freed up more for program space.
Neither mode put any RAM in SWR."
The SynerTek CPU. Paul and David Boddie have examined some of the more commonly used undocumented opcodes, but it occurs to me some of the official ones may differ in timing, or 'bugs' (e.g. does the LDA zp,x ever load from stack memory, what is the effect of JMP (&xxFF)?).
The ULA. I'd really like to know which parts I have guessed wrong! I have finally discovered a game, 'Flight Path 737', which mixes 40 byte and 80 byte graphics modes (producing an incorrect display in ElectrEm!), so I might be able to figure out some more about the video address counters soon. I'm especially worried about the tape interrupts.
Any DFS interfaces that existed. Where in memory was the 8271, and what about a drive control register?
Does anyone have a copy of 'The Acorn User' from November 1987? Apparently it contained a program for hardware scrolling on an Electron - no doubt the accompanying article must have said something about the Electron hardware!
gARetH baBB has promised me some information about the Plus 3 drive control register and the First Byte joystick interface, but its always good to have multiple sources! And what about miscellaneous other joystick interfaces? Any besides the Plus 1 which are analogue?
If you have even the slightest anecdotal information on any of these topics, then please e-mail me right now!