Proposed: "The Ultimate Electron Upgrade"

[BigEd]

Ah, thanks.
Are all ULAs the same - would this upgrade work for any model of Elk?

[hoglet]

Ah, thanks.
Are all ULAs the same - would this upgrade work for any model of Elk?

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.

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.

[BigEd]

Thanks! That looks rather like a Signetics logo to me.

Edit:

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

- http://www.edn.com/design/integrated-ci ... d-IC-logic
("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)

[BigEd]

Thanks! That looks rather like a Signetics logo to me.

And yet, that logo is also very like a Synertek logo - and we see evidence that it's Synertek who were a second source.

[1024MAK]

Simtek Corporation
Synertek
Signetics (Now Philips)

Mark

[paulb]

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!

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.

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

[hoglet]

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

At the moment the on-board RAM is not connected, and 32K of block RAM in the FPGA is being used instead.

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

[paulb]

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

At the moment the on-board RAM is not connected, and 32K of block RAM in the FPGA is being used instead.

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.

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.

[richardtoohey]

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.

[hoglet]

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

[davidb]

Very impressive!

The palette switching thread has more test cases, as I'm sure you remember.

[daveejhitchins]

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

Dave H

[hoglet]

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

Thanks Dave, but I have a couple already that run well at 4MHz in an Atom.

Do you know what speed the ROM is in the Electron?

Dave

[daveejhitchins]

[Do you know what speed the ROM is in the Electron?

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.

Dave H

[hoglet]

[Do you know what speed the ROM is in the Electron?

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.
Dave H

I guess it would need to be ~100ns.

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]

This is awesome.

Agreed

I'll have to wait until there are a few less wires involved ... ... if it gets to that stage.

But it's no fun without lots of wires. It's all the wires that make it a real home brew system....

Mark

[hoglet]

New, improved, now with added MODE 7:
https://github.com/hoglet67/ElectronFpg ... ac15ac6197

And more bad spellin

Edit: and one more:

Dave

[daveejhitchins]

Dave H

[BigEd]

Most excellent time-travel back to 1983! The SSD is here, courtesy of PitfallJones:
viewtopic.php?f=41&t=7573

[dixiestoat]

What some fantastic work..!!

[hoglet]

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

[hoglet]

In another thread:

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;

Hmmm, I'll need to think about this one.

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

[ThomasHarte]

Hmmm, I'll need to think about this one.

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.

[paulb]

Hmmm, I'll need to think about this one.

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.

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?

[hoglet]

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

[hoglet]

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.

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 

The code that installs this ISR is:

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 

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

[ThomasHarte]

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.

[hoglet]

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

[danielj]

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.

[hoglet]

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.

It seems that a rather obscure MMFS bug is responsible for messing with the interrupts register on the electron.

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

https://github.com/hoglet67/MMFS/blob/d ... 0.asm#L100

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