paul@33 | 1 | Potential Design Improvements for the Acorn Electron
|
paul@33 | 2 | ====================================================
|
paul@33 | 3 |
|
paul@33 | 4 | The Acorn Electron was designed to be a variant of the BBC Microcomputer that
|
paul@33 | 5 | was intended to be simpler, easier and cheaper to produce whilst retaining a
|
paul@33 | 6 | degree of compatibility and offering many of the same features, principally
|
paul@33 | 7 | the wide range of graphics modes, BBC BASIC, and extensible hardware and
|
paul@33 | 8 | software capabilities. Upon its introduction in late 1981, the BBC Micro
|
paul@33 | 9 | competed favourably against its immediate contemporaries, such as the ZX81 and
|
paul@36 | 10 | VIC-20, as well as machines introduced slightly later, such as the ZX Spectrum
|
paul@33 | 11 | and Commodore 64. By producing a less expensive machine that retained certain
|
paul@33 | 12 | key features, the motivation was to bring BBC Micro technology to bear on the
|
paul@33 | 13 | lower end of the home computer market, albeit approximately two years after
|
paul@33 | 14 | its initial introduction.
|
paul@33 | 15 |
|
paul@33 | 16 | Unfortunately, various features were omitted from the Acorn Electron that made
|
paul@33 | 17 | it less competitive than it could have been against a steadily improving range
|
paul@33 | 18 | of competitors: multi-channel sound support, MODE 7 teletext, support for
|
paul@33 | 19 | relatively smooth horizontal hardware scrolling (and other display control
|
paul@33 | 20 | features), and the double-speed bus with interleaved CPU and video access.
|
paul@33 | 21 | More RAM would also have been beneficial, although costly at the prices of the
|
paul@33 | 22 | day. Such deficiencies outweighed the significant benefits of substantial
|
paul@33 | 23 | software compatibility, and some of them effectively curtailed that
|
paul@33 | 24 | compatibility by making even reasonably well-written software titles
|
paul@33 | 25 | effectively unusable, particularly games relying on the BBC Micro's hardware
|
paul@33 | 26 | scrolling capabilities, including "official" Acornsoft titles.
|
paul@33 | 27 |
|
paul@33 | 28 | In hindsight, numerous features could be suggested that would make the
|
paul@33 | 29 | Electron more competitive, but many of these features would incur a
|
paul@33 | 30 | substantial cost. For example, giving the Electron 64K of RAM would have
|
paul@33 | 31 | increased the price substantially. Introducing the double-speed bus and faster
|
paul@33 | 32 | memory may also have increased the price in a prohibitive fashion. Thus, it
|
paul@33 | 33 | becomes worthwhile to consider minimal alterations to the machine's
|
paul@33 | 34 | specification that offer the greatest benefits for the least additional cost.
|
paul@33 | 35 |
|
paul@33 | 36 | Improving System Performance
|
paul@33 | 37 | ----------------------------
|
paul@33 | 38 |
|
paul@77 | 39 | The ULA and the CPU share access to the RAM, meaning that when the ULA needs
|
paul@77 | 40 | to fill the display, the CPU will either take it in turns with the ULA to
|
paul@77 | 41 | access RAM or even relinquish access to the RAM for the entire duration of the
|
paul@77 | 42 | visible portion of a display line. However, even outside these periods of
|
paul@77 | 43 | contention, it appears that the CPU still only accesses the RAM at 1MHz, even
|
paul@77 | 44 | though the RAM can sustain 2MHz access (and indeed does when both the CPU and
|
paul@77 | 45 | ULA access it in turns). By allowing the CPU to entirely take over the RAM
|
paul@77 | 46 | outside display periods (just as the ULA can do) and to access it on every
|
paul@77 | 47 | 2MHz cycle, performance would be significantly improved: the CPU would be able
|
paul@77 | 48 | to do twice as much work in the largest-memory screen modes, for example.
|
paul@77 | 49 |
|
paul@33 | 50 | Although RAM is accessed by the CPU at 1MHz, ROM is accessed at 2MHz. Thus,
|
paul@33 | 51 | deploying software that runs from ROM can potentially provide significant
|
paul@33 | 52 | performance benefits. Since the unexpanded Electron provides no convenient
|
paul@33 | 53 | means of installing ROM-based software - the Plus 1 and other expansion units
|
paul@33 | 54 | offered ROM cartridge slots, and various expansions provided ROM sockets - the
|
paul@36 | 55 | improved Electron would ideally need to offer a ROM cartridge slot as part of
|
paul@69 | 56 | the unexpanded machine.
|
paul@69 | 57 |
|
paul@69 | 58 | A side-benefit of adding this feature to the base machine would arguably be an
|
paul@69 | 59 | increased demand for cartridge-based software, potentially at a slightly
|
paul@69 | 60 | higher price and also offering additional hardware features if necessary, thus
|
paul@69 | 61 | making any cost incurred in the manufacture of the base unit more bearable.
|
paul@69 | 62 | And in school environments where unexpanded BBC Microcomputers were often used
|
paul@69 | 63 | with tapes, the use of ROM cartridges for instant and reliable loading of
|
paul@69 | 64 | software would have given the Electron a practical advantage: it would be a
|
paul@69 | 65 | cheaper machine that could later be expanded with disk drives (the other main
|
paul@69 | 66 | way of providing fast and reliable storage) while still offering a substantial
|
paul@69 | 67 | saving over the BBC Micro.
|
paul@33 | 68 |
|
paul@33 | 69 | The Slogger/Elektuur turbo board modified the system to permit the CPU to
|
paul@33 | 70 | access the bottom 8K of RAM without interruption by the ULA. This feature,
|
paul@33 | 71 | already known at Acorn during the Electron's design period, permitted
|
paul@33 | 72 | substantial improvements to performance and could also be incorporated into an
|
paul@36 | 73 | improved Electron, although it presumably needs motherboard-level changes.
|
paul@36 | 74 | Such turbo boards may have employed an additional RAM chip to avoid
|
paul@36 | 75 | complicated changes to the memory access logic, since the ULA appears to
|
paul@36 | 76 | access four memory chips at once to provide each byte, and it is therefore not
|
paul@36 | 77 | possible to just "borrow" one of the chips in order to isolate 8K of RAM for
|
paul@36 | 78 | direct access by the CPU.
|
paul@47 | 79 |
|
paul@62 | 80 | Being able to disable the ULA's access to RAM for a period of time while also
|
paul@62 | 81 | disabling the video signal, effectively achieving the same as blanking the
|
paul@62 | 82 | palette, would be a very simple but useful enhancement that would speed up
|
paul@62 | 83 | programs needing to render large amounts of non-real-time content to the
|
paul@62 | 84 | screen.
|
paul@62 | 85 |
|
paul@47 | 86 | Improving Display Capabilities
|
paul@47 | 87 | ------------------------------
|
paul@47 | 88 |
|
paul@47 | 89 | Perhaps the simplest improvement to the display capabilities would be to
|
paul@60 | 90 | permit the RGB output levels to hold intermediate values between the current
|
paul@60 | 91 | high and low states, presumably enforced by various circuits. This would
|
paul@60 | 92 | permit the choice of colours beyond the primary and secondary colour selection
|
paul@60 | 93 | at a cost of some extra palette bits in the ULA and an adjustment to the board
|
paul@60 | 94 | circuitry and would only benefit UHF and colour composite video displays, but
|
paul@60 | 95 | the latter limitation might not be a significant issue for the majority of the
|
paul@60 | 96 | intended audience.
|
paul@69 | 97 |
|
paul@69 | 98 | Supporting Local Area Networking
|
paul@69 | 99 | --------------------------------
|
paul@69 | 100 |
|
paul@69 | 101 | The Electron was mostly aimed at the home market, but a cheaper computer would
|
paul@69 | 102 | have been very attractive for schools, especially those wanting to purchase a
|
paul@69 | 103 | number of machines for networking. Having an option available in the standard
|
paul@69 | 104 | Electron would have given such customers a cheap Econet terminal, albeit
|
paul@69 | 105 | without the MODE 7 capabilities of the BBC, whilst ignoring the requirement of
|
paul@69 | 106 | reliable, fast storage that standalone machines need to have in such
|
paul@69 | 107 | environments. With content available on demand over the network, the need for
|
paul@69 | 108 | low-memory screen mode usage - in order to retain as much content in memory as
|
paul@69 | 109 | possible - would also be diminished.
|
paul@71 | 110 |
|
paul@71 | 111 | About this Document
|
paul@71 | 112 | -------------------
|
paul@71 | 113 |
|
paul@71 | 114 | The most recent version of this document and accompanying distribution should
|
paul@71 | 115 | be available from the following location:
|
paul@71 | 116 |
|
paul@71 | 117 | http://hgweb.boddie.org.uk/ULA
|
paul@71 | 118 |
|
paul@71 | 119 | Copyright and licence information can be found in the docs directory of this
|
paul@71 | 120 | distribution - see docs/COPYING.txt for more information.
|