I’ve finally managed to get my hands on an Acorn Electron and being able to compare frequency output between a real Electron and my FPGA implementation, the results were a little surprising.

The Electron

The Electron was supposed to be fully working, but arrived with a few non-functioning keys, one of which ironically was the N key which I needed to try the SOUND test.

It was quickly clear the issue was the Futaba switches. The seller, to their credit, covered the cost of a few replacement switches and I managed to get a couple of the keys (including N) working again by de-soldering the switches and cleaning the pins/contacts.

N key switch desoldered and removed for cleaning

N key switch desoldered and removed for cleaning

I have a feeling someone has already done some “work” on a few key switches as the two areas circled red in the image below look rather blobby. Also there’s a scratch across one of the key matrix traces although no real damage appears to have been done.

Circled Red - Someone's attempt to fix before?

Circled Red - Someone's attempt to fix before?

The inset in the top right shows one of the removed Futaba switches prior to cleaning the pins/contacts which (for that key at least) was sufficient to get it working again. The right most green circle is after soldering it back into place. I repeated this on the comma key (left most green circle).

Whilst the red circled joints look unsightly, they do appear to be allowing a good contact so I’ve left them alone for now.

Keyboard re-assembly or maybe a quick word game

Keyboard re-assembly or maybe a quick word game

I was pleased to find the ULA is socketed (middle right just above the Electron logo) as I’d like to eventually test my ULA reimplementation in place of the real ULA. A socket makes testing a future board that little bit easier.

Sound Testing

With the Electron’s keyboard back up and running a sound test could finally take place. Whilst I knew my implementation sounded too high a frequency from youtube comparisons, I didn’t want to make any further tweaks until seeing exactly what a real Electron output via the SOUND command or by setting the FE07 and FE06 registers directly.

As mentioned in a previous post, the Advanced User Guide (AUG) states the shared register should produce frequencies according to

\[ {Frequency}=\frac{1MHz}{(16 \times (S+1))} \]

That means writing 0 or 255 to the shared counter register should (according to the AUG) produce a square wave with a max frequency of 62.5kHz and a minimum of 244Hz.

This little BASIC snippet sets the comm mode to sound output and puts the value 255 into the shared counter which should output the minimum frequency possible.

?&FE07=&B0+2
?&FE06=255

As the following trace shows (pay no attention to the excess noise on the yellow trace, it’s due to the use of long ground cable unlike the short probe connection on the FPGA), the Electron (yellow trace) output 122Hz whilst the FPGA (blue trace) is showing 244Hz. It appears, contrary to the AUG stated range of 244Hz to 61.5kHz, that the Electron sound range is actually 122Hz to 31.25kHz.

Electron (yellow) and FPGA (blue) audio traces

Electron (yellow) and FPGA (blue) audio traces

It’s not just the AUG that states this, the schematics (at least by my understanding) also show a 244Hz through 61.5kHz range. Whether the schematics are wrong or I’ve misinterpreted I’m not certain, either way, the FPGA core needed an extra divide by two stage. With that change made the sound frequency matches the Electron whether using a direct register setting or the SOUND command.

Here’s a short recording of the Electorn core running the Frogger clone, Hopper.

There’s perhaps still a little further room for improvement on the sound as the Electron hardware has additional filtering prior to the speaker. Before I look into that, I’d like to verify my guess that the Electron may have used a pseudo progressive PAL signal rather than interlaced. Judging by this Electron’s picture, I’m now doubting that’s the case.

I also want to investigate the timing of various interrupts and compare my implementation, although the answer to a few questions may remain a mystery until reverse engineering of the ULA die occurs.