Proposed: "The Ultimate Electron Upgrade"
Re: Proposed: "The Ultimate Electron Upgrade"
Ah, thanks.
Are all ULAs the same - would this upgrade work for any model of Elk?
Are all ULAs the same - would this upgrade work for any model of Elk?
Re: Proposed: "The Ultimate Electron Upgrade"
The ULAs are functionally the same, but there are two different packages in use. Issue 4 Electrons use a Ferranti ULA in an LCC type package, and the Electron board contains a ZIF socket.BigEd wrote:Ah, thanks.
Are all ULAs the same - would this upgrade work for any model of Elk?
Issue 6 Electrons encapsulate the ULA in a blob of resin on small carrier board that is soldered directly into the PCB.
The pad layout on the Electron PCB is the same in both cases, and matches a standard 68-pin PGA socket.
In both cases, this update will involve desoldering the existing ULA (or socket) and replacing it with a 68 pin PGA socket. This socket can now take either the old ULA (or socket), or the future FPGA/CPLD update. You need a decent desoldering station to do this. DaveH did my issue 4 board last year, and I did Rich's donated issue 6 board last week.
The update should work with either issue.
Dave
By the way, does anyone know if the issue 6 ULA is also Ferranti? There's an S logo on the underside of the ULA board that suggests not.
Re: Proposed: "The Ultimate Electron Upgrade"
Thanks! That looks rather like a Signetics logo to me.
Edit:
("Uncommitted IC logic" By William Twaddell, Western Editor -EDN, April 05, 1980)
Edit: historical notes found on the web (citations needed!)
- Philips bought the US chip firm Signetics in 1975
- Ferranti's ULA was implemented in the CDI semiconductor process (which incidentally was licensed from Fairchild)
Edit:
- http://www.edn.com/design/integrated-ci ... d-IC-logicWith the renewed interest in semicustom ICs evident since 1976, Fairchild, Texas Instruments and Motorola have returned to the market—Fairchild and Motorola in ECL arrays and Texas Instruments in I²L and STL (Schottky transistor logic), a technology similar to ISL (integrated Schottky logic) but said to be faster. Interest has not been confined to the US, either; Europe has at least four manufacturers (Ferranti, Philips, Plessey and Siemens), while in Japan, Fujitsu, Hitachi and NEC are prominent.
("Uncommitted IC logic" By William Twaddell, Western Editor -EDN, April 05, 1980)
Edit: historical notes found on the web (citations needed!)
- Philips bought the US chip firm Signetics in 1975
- Ferranti's ULA was implemented in the CDI semiconductor process (which incidentally was licensed from Fairchild)
Re: Proposed: "The Ultimate Electron Upgrade"
And yet, that logo is also very like a Synertek logo - and we see evidence that it's Synertek who were a second source.BigEd wrote:Thanks! That looks rather like a Signetics logo to me.
- 1024MAK
- Posts: 10487
- Joined: Mon Apr 18, 2011 5:46 pm
- Location: Looking forward to summer in Somerset, UK...
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
Mark
- Attachments
-
- signetic.gif (138 Bytes) Viewed 3670 times
-
- synertek.gif (149 Bytes) Viewed 3670 times
-
- simtek.gif (159 Bytes) Viewed 3670 times
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki - for answers to many questions...
Fault finding index • Acorn BBC Model B minimal configuration • Logic Levels for 5V TTL Systems
BeebWiki - for answers to many questions...
Fault finding index • Acorn BBC Model B minimal configuration • Logic Levels for 5V TTL Systems
Re: Proposed: "The Ultimate Electron Upgrade"
Nice work! This might mean that I'm spared the effort of doing something similar in Verilog for the iCE40, but then again that might be an interesting learning exercise, anyway. Indeed, I might have more of a clue about translating your VHDL now than I did before looking into Verilog back in June, meaning that I could attempt to do what I originally had in mind, which wasn't to actually write any new code at all.hoglet wrote: I'm currently prototyping this with a Papilo Duo and some level shifters.
The code is on github:
https://github.com/hoglet67/ElectronFpg ... la_duo.vhd
An no prizes for spotting I've mis-spelled Amazingly!![]()

Does the FPGA drive the Electron's on-board RAM or are those pins not connected? (Lazy question based on thread skim and failure to consult the circuit diagram.

Re: Proposed: "The Ultimate Electron Upgrade"
At the moment the on-board RAM is not connected, and 32K of block RAM in the FPGA is being used instead.paulb wrote: Does the FPGA drive the Electron's on-board RAM or are those pins not connected? (Lazy question based on thread skim and failure to consult the circuit diagram.)
I think there are two alternative designs here:
- use an larger FPGA and replace existing RAM with block RAM in the FPGA (which is what I have currently)
- use a CPLD (or smaller FPGA) as a more minimalist / faithful reproduction of the ULA that makes use of the existing RAM
I think both of these are worthwhile endeavours, and they both have their pros and cons, depending on your perspective.
If we can obtain some decent photos of the ULA die, I'm also interested in seeing the original design reverse engineered.
Dave
Re: Proposed: "The Ultimate Electron Upgrade"
Agreed. I guess using the block RAM does allow turbo-board-like things (or their equivalents), making a range of features possible that wouldn't be if the on-board RAM were used.hoglet wrote:At the moment the on-board RAM is not connected, and 32K of block RAM in the FPGA is being used instead.paulb wrote: Does the FPGA drive the Electron's on-board RAM or are those pins not connected? (Lazy question based on thread skim and failure to consult the circuit diagram.)
I think there are two alternative designs here:
- use an larger FPGA and replace existing RAM with block RAM in the FPGA (which is what I have currently)
- use a CPLD (or smaller FPGA) as a more minimalist / faithful reproduction of the ULA that makes use of the existing RAM
I think both of these are worthwhile endeavours, and they both have their pros and cons, depending on your perspective.
- richardtoohey
- Posts: 4009
- Joined: Thu Dec 29, 2011 5:13 am
- Location: Tauranga, New Zealand
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
This is awesome.
I did see the other thread about Electron FPGA but missed the the plan is the ULA part could eventually be reused in a real Electron as a ULA replacement/enhancement part.
I've got a couple of poorly Electrons and I know at least one of them is the ULA (Dave H has offered to help but I've not got around (who? me?
) to digging the machine out.)
I'll have to wait until there are a few less wires involved ...
... if it gets to that stage. 


I did see the other thread about Electron FPGA but missed the the plan is the ULA part could eventually be reused in a real Electron as a ULA replacement/enhancement part.
I've got a couple of poorly Electrons and I know at least one of them is the ULA (Dave H has offered to help but I've not got around (who? me?

I'll have to wait until there are a few less wires involved ...


Re: Proposed: "The Ultimate Electron Upgrade"
I've got a little bit further with this project.
The memory contention logic is now implemented, so the FOR/NEXT loop speeds now match the original Electron pretty closely in each of the screen modes. It's also possible to run at fixed 1, 2 and (in theory any way) 4MHz. The highest speed doesn't work yet, probably down to the ROM and/or 6502 speed. There are hot keys to allow dynamic switching, and a flashing LED to confirm the speed setting.
I've also added a SD Card Interface using a cheap 99p (ish) interface: There is space in the FPGA to include a copy of MMFS, so no external plus one is needed: Which means I've now got access to more software for testing: Gauntlet seems to work OK, and I think that was one of the games that is pretty picky about timing: Not sure what's next, cassette interface maybe?
Dave
The memory contention logic is now implemented, so the FOR/NEXT loop speeds now match the original Electron pretty closely in each of the screen modes. It's also possible to run at fixed 1, 2 and (in theory any way) 4MHz. The highest speed doesn't work yet, probably down to the ROM and/or 6502 speed. There are hot keys to allow dynamic switching, and a flashing LED to confirm the speed setting.
I've also added a SD Card Interface using a cheap 99p (ish) interface: There is space in the FPGA to include a copy of MMFS, so no external plus one is needed: Which means I've now got access to more software for testing: Gauntlet seems to work OK, and I think that was one of the games that is pretty picky about timing: Not sure what's next, cassette interface maybe?
Dave
- daveejhitchins
- Posts: 6109
- Joined: Wed Jun 13, 2012 6:23 pm
- Location: Newton Aycliffe, County Durham
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
Dave, if you need a 4MHz 6502 pm me and I'll get one in the post - I'll send you a few - just in case, as I havent tested them at 4MHz.hoglet wrote:It's also possible to run at fixed 1, 2 and (in theory any way) 4MHz. The highest speed doesn't work yet, probably down to the ROM and/or 6502 speed.
Dave H

Re: Proposed: "The Ultimate Electron Upgrade"
Thanks Dave, but I have a couple already that run well at 4MHz in an Atom.daveejhitchins wrote:Dave, if you need a 4MHz 6502 pm me and I'll get one in the post - I'll send you a few - just in case, as I havent tested them at 4MHz.hoglet wrote:It's also possible to run at fixed 1, 2 and (in theory any way) 4MHz. The highest speed doesn't work yet, probably down to the ROM and/or 6502 speed.
Do you know what speed the ROM is in the Electron?
Dave
- daveejhitchins
- Posts: 6109
- Joined: Wed Jun 13, 2012 6:23 pm
- Location: Newton Aycliffe, County Durham
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
No, sorry . . . What speed would you need? I may have some faster-than-normal 512's that would do. Packed away, at the moment. I may know where they are, though.hoglet wrote:[Do you know what speed the ROM is in the Electron?
Dave H

Re: Proposed: "The Ultimate Electron Upgrade"
I guess it would need to be ~100ns.daveejhitchins wrote:No, sorry . . . What speed would you need? I may have some faster-than-normal 512's that would do. Packed away, at the moment. I may know where they are, though.hoglet wrote:[Do you know what speed the ROM is in the Electron?
Dave H
I just wrote a small test program that runs 100% from RAM, which in this case will be the FPGA block RAM which should easily be fast enough.
All the program does is disable interrupts then continuously scan the keyboard and increment a screen memory location.
Anyway, with either of my 4MHz capable processors it crashes when switching to 4MHz. All other speeds are fine.
I'll get the scope out tomorrow and see if I can spot what's happening, because I expected this would have worked.
Dave
- 1024MAK
- Posts: 10487
- Joined: Mon Apr 18, 2011 5:46 pm
- Location: Looking forward to summer in Somerset, UK...
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
Agreedrichardtoohey wrote:This is awesome.![]()
![]()

But it's no fun without lots of wires. It's all the wires that make it a real home brew system....richardtoohey wrote:I'll have to wait until there are a few less wires involved ...... if it gets to that stage.


Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki - for answers to many questions...
Fault finding index • Acorn BBC Model B minimal configuration • Logic Levels for 5V TTL Systems
BeebWiki - for answers to many questions...
Fault finding index • Acorn BBC Model B minimal configuration • Logic Levels for 5V TTL Systems
Re: Proposed: "The Ultimate Electron Upgrade"
New, improved, now with added MODE 7:
https://github.com/hoglet67/ElectronFpg ... ac15ac6197
And more bad spellin
Edit: and one more: Dave
https://github.com/hoglet67/ElectronFpg ... ac15ac6197
And more bad spellin

Edit: and one more: Dave
- daveejhitchins
- Posts: 6109
- Joined: Wed Jun 13, 2012 6:23 pm
- Location: Newton Aycliffe, County Durham
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
Most excellent time-travel back to 1983! The SSD is here, courtesy of PitfallJones:
viewtopic.php?f=41&t=7573
viewtopic.php?f=41&t=7573
-
- Posts: 282
- Joined: Tue Oct 09, 2012 9:58 am
- Location: Warwickshire
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
What some fantastic work..!!



If in doubt, CTRL-BREAK thou should clout..
Re: Proposed: "The Ultimate Electron Upgrade"
Hi Guys,
This afternoon I've been working on one of the last missing pieces: Cassette In and Out.
I'd already done the Cassette In implementation for Electron FPGA, so enabling that in the ULA replacement was just a matter of wiring it up:
https://github.com/hoglet67/ElectronFpg ... e2386d?w=1
To get this to work in a real electron I needed to add a couple of external 10K resistors to bias the input bit to the right voltage. This is expected, as the cassette input is capacitively coupled to the ULA.
With this I was able to load and run FireTrack from tape.
The Cassette Out implementation needed some more development, and there's a heavy dose of speculation on my part on how it works in the real ULA:
https://github.com/hoglet67/ElectronFpg ... f2fccd&w=1
On the real Electron ULA the cassette output is pseudo sinusoidal: i.e. there are four separate output levels: 1.9V, 2.4V, 3.7V and 4.2V.
I guess this could be generated from a Xilinx using two outputs and a ladder DAC with a couple of carefully chosen resistors. I have't done that yet, so it's just a simple square wave.
But this does seem to work in practice, and I can connect the output up to my Beeb and save from the electron and load into the Beeb.
I'd value some feedback from other Electron experts on any of the assumptions I have made.
- that clearing of the Transmit Data Empty interrupt (when FE04 is written) is what starts the transmission.
- that further writes to FE04 while transmitting won't extend the number of bits in the character, but will corrupt the data being sent
- that the Transmit Data Empty interrupt happens between the last data bit and the stop bit.
Dave
This afternoon I've been working on one of the last missing pieces: Cassette In and Out.
I'd already done the Cassette In implementation for Electron FPGA, so enabling that in the ULA replacement was just a matter of wiring it up:
https://github.com/hoglet67/ElectronFpg ... e2386d?w=1
To get this to work in a real electron I needed to add a couple of external 10K resistors to bias the input bit to the right voltage. This is expected, as the cassette input is capacitively coupled to the ULA.
With this I was able to load and run FireTrack from tape.



The Cassette Out implementation needed some more development, and there's a heavy dose of speculation on my part on how it works in the real ULA:
https://github.com/hoglet67/ElectronFpg ... f2fccd&w=1
On the real Electron ULA the cassette output is pseudo sinusoidal: i.e. there are four separate output levels: 1.9V, 2.4V, 3.7V and 4.2V.
I guess this could be generated from a Xilinx using two outputs and a ladder DAC with a couple of carefully chosen resistors. I have't done that yet, so it's just a simple square wave.
But this does seem to work in practice, and I can connect the output up to my Beeb and save from the electron and load into the Beeb.
I'd value some feedback from other Electron experts on any of the assumptions I have made.
- that clearing of the Transmit Data Empty interrupt (when FE04 is written) is what starts the transmission.
- that further writes to FE04 while transmitting won't extend the number of bits in the character, but will corrupt the data being sent
- that the Transmit Data Empty interrupt happens between the last data bit and the stop bit.
Dave
Re: Proposed: "The Ultimate Electron Upgrade"
In another thread:
Can you be more precise about the sequence of register writes needed to invoke this?
Any idea why this might be happening in the real ULA? Seems like the receive state machine must be running even in transmit mode?
Dave
Hmmm, I'll need to think about this one.ThomasHarte wrote:From memory, from writing ElectrEm, a decade and a half ago:
- a hardware quirk causes the 'receive data' (the real one; this isn't a comment about mislabelling) to be triggered if the tape hardware is put into output mode and appropriate data is sent to look like a stop bit. Joe Blade uses that like a programmable interrupt counter — analogous to those other platforms where you can say "give me an interrupt in 32 lines" — in order to trigger its palette change; possibly Northern Star and Southern Belle do too;
Can you be more precise about the sequence of register writes needed to invoke this?
Any idea why this might be happening in the real ULA? Seems like the receive state machine must be running even in transmit mode?
Dave
-
- Posts: 513
- Joined: Sat Dec 23, 2000 5:56 pm
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
Memory failed me a little; I think Joe Blade merely expects the tape data full bit to remain set for its entire run. However, my current mental model of the tape hardware is then what you suggest: input mode versus output mode affects whether the register self-shifts or is filled by tape data. That's it. All potential interrupt sources are evaluated regardless of mode.hoglet wrote:Hmmm, I'll need to think about this one.
Re: Proposed: "The Ultimate Electron Upgrade"
Isn't this the mechanism by which most of Peter Scott's later games (conversions like Sim City and Predator plus originals like Spycat) blank half or so of the screen, leaving only the playing area visible at the bottom?ThomasHarte wrote:Memory failed me a little; I think Joe Blade merely expects the tape data full bit to remain set for its entire run. However, my current mental model of the tape hardware is then what you suggest: input mode versus output mode affects whether the register self-shifts or is filled by tape data. That's it. All potential interrupt sources are evaluated regardless of mode.hoglet wrote:Hmmm, I'll need to think about this one.
Re: Proposed: "The Ultimate Electron Upgrade"
I've been looking through the Tape output implementation part of Thomas's ElectrEm sources:
https://github.com/TomHarte/ElectrEm/bl ... e.cpp#L163
This was very informative.
It seems that ULA maintains separate bit counters for the transmit and receive tape character processing, and that these are both running independently when data is being transmitted.
This is not how I have currently implemented it in the FPGA, which I think explains why Joe Blade is just giving me a black screen.
I'll have a little think about that, and do some tweaking.
Thanks guys for the input.
Dave
https://github.com/TomHarte/ElectrEm/bl ... e.cpp#L163
This was very informative.
It seems that ULA maintains separate bit counters for the transmit and receive tape character processing, and that these are both running independently when data is being transmitted.
This is not how I have currently implemented it in the FPGA, which I think explains why Joe Blade is just giving me a black screen.
I'll have a little think about that, and do some tweaking.
Thanks guys for the input.
Dave
Re: Proposed: "The Ultimate Electron Upgrade"
I'm trying to understand the way that Joe Blade uses interrupts to mask part of the screen.
I've disassembled the code, and found the ISR it installs.
The code that installs this ISR is:
It seems this interrupt service routine is doing the following:
- if interrupt status bit 2 (display end) is set, then the &FF is written to the palette registers at &FE08 and &FE09.
- if interrupt status bit 5 (transmit data empty) is set, then some other values are written to the palette registers at &FE08 and &FE09.
What's confusing me a bit is that the last value written to &FE00 is &0C, which doesn't enable any of the the tape interrupts.
So the only interrupts that are active are the timer interrupt (at line 100) and the display end (at line 256).
Edit: After a bit more debugging, it seems for some reason the branch at 129 is never being taken, i.e. it thinks the display interrupt flag is always set. I don't understand this at all.
Dave
I've disassembled the code, and found the ISR it installs.
Code: Select all
011B : LDA FC
011D : PHA
011E : TXA
011F : PHA
0120 : TYA
0121 : PHA
0122 : LDA FE00
0125 : AND #04
0127 : CMP #04 ;; is the display end interrupt flag set
0129 : BNE 013D
012B : LDA #FF ;; yes, blank the screen
012D : STA FE08
0130 : STA FE09
0133 : PLA
0134 : TAY
0135 : PLA
0136 : TAX
0137 : PLA
0138 : STA FC
013A : JMP (0100)
013D : LDA FE00 ;; is the transmit data empty interrupt flag set
0140 : AND #20
0142 : CMP #20
0144 : BNE 0133
0146 : NOP ;; yes, unblank the screen
0147 : LDX 0159
014A : LDA 21D8,X
014D : STA FE08
0150 : LDA 21DC,X
0153 : STA FE09
0156 : JMP 0133
Code: Select all
0102 : SEI
0103 : LDA 0204
0106 : STA 0100
0109 : LDA 0205
010C : STA 0101
010F : LDA #1B
0111 : STA 0204
0114 : LDA #01
0116 : STA 0205
0119 : CLI
011A : RTS
- if interrupt status bit 2 (display end) is set, then the &FF is written to the palette registers at &FE08 and &FE09.
- if interrupt status bit 5 (transmit data empty) is set, then some other values are written to the palette registers at &FE08 and &FE09.
What's confusing me a bit is that the last value written to &FE00 is &0C, which doesn't enable any of the the tape interrupts.
So the only interrupts that are active are the timer interrupt (at line 100) and the display end (at line 256).
Edit: After a bit more debugging, it seems for some reason the branch at 129 is never being taken, i.e. it thinks the display interrupt flag is always set. I don't understand this at all.
Dave
-
- Posts: 513
- Joined: Sat Dec 23, 2000 5:56 pm
- Contact:
Re: Proposed: "The Ultimate Electron Upgrade"
Certainly under emulation the reason that Joe Blade works is that if the display end flag is set then the blank palette is set; transmit data empty is always set — it went high while the tape was loading and nobody has cleared it since — so the second test always passes. It's exactly the same thing as if(display end) {blank} else {not blank}, but for some reason expressed so as to depend upon the tape status.
EDIT: I believe Southern Belle to be another good example of the tape interrupts all always being evaluated. It sets the tape to output mode but expects interrupts to be triggered by receive data full. So that's possibly even a better experiment than Joe Blade because it relies upon output mode triggering input interrupts every single frame, whereas Joe Blade merely requires that input mode set an output mode flag once, at some time previous.
EDIT: I believe Southern Belle to be another good example of the tape interrupts all always being evaluated. It sets the tape to output mode but expects interrupts to be triggered by receive data full. So that's possibly even a better experiment than Joe Blade because it relies upon output mode triggering input interrupts every single frame, whereas Joe Blade merely requires that input mode set an output mode flag once, at some time previous.
Re: Proposed: "The Ultimate Electron Upgrade"
Thanks Thomas,
I think where I'm coming unstuck that that the power on value of the TDE flag in my FPGA system is 0 , where as I think it should be 1.
Where I'm getting confused is understanding under what conditions this flag is set.
I'm wondering it's better to think of it as a "not sending" flag?
i.e. It's set at all times, apart from when a character is actually being transmitted.
Dave
I think where I'm coming unstuck that that the power on value of the TDE flag in my FPGA system is 0 , where as I think it should be 1.
Where I'm getting confused is understanding under what conditions this flag is set.
I'm wondering it's better to think of it as a "not sending" flag?
i.e. It's set at all times, apart from when a character is actually being transmitted.
Dave
Re: Proposed: "The Ultimate Electron Upgrade"
OK. I just emailed the architect of this mysterious silicon box to ask if he had any wiring layer diagrams or anything. Will keep you posted!
d.
d.
Re: Proposed: "The Ultimate Electron Upgrade"
It seems that a rather obscure MMFS bug is responsible for messing with the interrupts register on the electron.hoglet wrote: Edit: After a bit more debugging, it seems for some reason the branch at 129 is never being taken, i.e. it thinks the display interrupt flag is always set. I don't understand this at all.
Specifically, this fragment of code is included in the Electron version, and really shouldn't be, as it's Beeb specific:
Code: Select all
\ Illuminate Caps Lock & Shift Lock
.SetLEDS
LDX #&6
STX &FE40
INX
STX &FE40
RTS
On the Electron this switches off the display interrupt, which seriously confuses Joe Blade's interrupt handling code.

I'll fix that now and see if I get any further.
Dave