Back in a July 2017 blog post I made the assumption that the Electron used a pseudo progressive, rather than true interlaced, display format.

Having recently purchased an Electron I’ve finally had the chance to take some measurements and verify that assumption.

Electron PAL Timings

The Electron supports several different graphics modes but each is based on a 640x256 resolution with the 320 and 160 modes having double/quad pixels and the text modes (3 and 6) having 2 blank lines after every 8 vertical lines.

With the Electron in a fresh boot state (mode 6) and having issued “COLOUR129:CLS” to get a white screen with 2 black lines every 8. I hooked the oscilloscope up and took some measurements of the PAL signal (in blue) as well as RTC/DispEnd (shown in pink) interrupts which provide timing for the Electron’s “TIME” command.

The trace below shows a single field of 25 rows of active video that make up a mode 6 display, where each row is 8 lines of video data followed by 2 blank lines for a total of 250 lines. The lack of active video either side of vsync is a combination of sync lines and top/bottom border regions.

It became clear the Electron uses two fields per frame with 312.5 lines per field at 50Hz. As you would expect from an interlaced 50Hz PAL signal and not the 312 lines I would have expected from a pseudo progressive signal.

However, zooming in on the start and end of the vsync pulse for each field shows vsync cutting into the scanline preceding and following it and doing so at a different point for each field. Field 1 has a 11us partial line before vsync begins and a 17us partial after, whilst Field 2 has a 43us partial before and 49us partial after.

In a standard PAL signal, VSync usually occupies 2.5 scanlines in one field and then 2.5 scanlines in the next but offset by 1/2 a scanline. The Electron has the 1/2 scanline offset, it just doesn’t appear to be aligned to the start and mid-point of a scanline.

I believe the non-standard partial lines may be accomplishing a similar effect as the pseudo progressive signal described in the July blog post whilst retaining the full 625 scanlines per interlaced frame.

One Scanline

The per line signal is easier to see in the below images and measurements show the following timing

hsync = 4us (64px)
backporch = 6us (96px)
border = 6us (96px)
active video = 40us (640px)
border = 6us (96px)
front porch = 2us (32px)
Total: 64us (1024px)

Interrupts

The DispEnd interrupt occurs aligned to the leading edge of the hsync that follows the last active display line 256 (or 250 in modes 3 & 6)).

The RTC on the other hand, is not aligned to the hsync signal and always occurs when the vsync counter reaches 200 (1/2 scanlines) i.e during line 100. Where within that scanline it occurs, differs by field.

RTC occurs nearer the start of the scanline on the first field and closer to the end on the second. As shown in the following two images:

The reason for this is that the ULA display logic will reset the vsync counter to 0 when the vsync count reaches 625 half scanlines (e.g 312.5 full scanlines) but only when the hsync counter also reaches 16 or 32. As the hsync counter is not reset along with vsync, the following field will reach a 625 count 1/2 a scanline later which is 16 hsync counts. This causes successive fields to alternate between a reset on 16 and on 32 and thus the RTC interrupt to shift field to field.

Schematics

Sheet 7 of the ULA schematics covers the display logic timing that generates the above H/V Sync and interrupts.

Four separate counters are used, a 5 bit counter for hsync operating from 0..31 clocked at 0.5MHz, a 10 bit counter for vsync clocked at 32.25kHz and counting one field worth of 1/2 scan lines 0..624 i.e 312.5 lines and finally a 4 bit counter for the active video row 0..10 (0..7 for modes 0,1,2,4,5 and 0..9 for modes 3 and 6).

A fourth 2 bit counter is shown on the schematics for VSB although I’m not sure how this could generate the 2.5 lines of vsync. It appears to generate 3 lines of vsync which is not what a real Electron produces. My implementation generates 2.5 lines of vsync (5 vsync counts [564,568]) to match the Electron rather than schematic.

Another such difference is the hsync timing which schematics show occurring on a count of 26 and 27 (4us total) however that leaves 28-31 (8us) before the counter resets to 0 which signifies the start of the 40us active part of a line. HSync really needs to occur during counts 24 and 25 leaving 26-31 or 12us for the backporch/border after the hsync ends and a sufficient border and front porch count before the hsync begins. I’ve again assumed the schematics are incorrect and used a count of 24-25 for timing hsync in my core.

As noted in prior blog posts, perhaps my interpretation of the schematics is incorrect or the final Electron ULA had further changes not noted on this version of the schematics.

Core PAL Timings

As far as the core goes, I’ve totally rewritten the display logic to function in a similar way to the logic on sheet 7 of the ULA schematics other than the exceptions noted above.

The result is a pretty close replica of the Electron’s PAL signal with just a few minor differences. For example the partial scanlines that vsync interrupts are 12us and 18us wide for field 1 and 42 and 48 wide for field 2. That contrasts to the Electron’s which measured 11us and 17us for field 1 and 43us and 49us for field 2. Visually however, with both Core and Electron connected via scart to a TV they look identical to me.

As a knock on effect of this change, the timing of the DISPEND (above) and RTC (below) interrupts are now a lot more accurate. This is important because the Electron uses these interrupts to derive timing information for the TIME command amongst other things.

With the previous version of the core which had 624 rather than 625 scalines per frame run side-by-side with a real Electron, the two would drift out of sync by roughly 1 second every 5 minutes. This issue no longer occurs with the two keeping good time.

Project Complete!

Thanks to Erique’s recent ARM firmware additions, there is no longer any need to convert UEF to RAW before loading tapes into the core as the firmware now supports loading from decompressed UEF files directly.

UEF save support will hopefully make it into a future firmware version along with a tape counter to allow skipping to a suitable location within a tape before hitting Play/Rec.

With the Core able to load and play Elite (and any other game I’ve tried), save your progress, having no known bugs and just a few minor differences from an Issue 2 Electron I feel it’s safe to call this project complete! at least as far as the original project goals are concerned.

A Binary version of the core is available to download from the FPGA Arcade site and source code from their SVN repository.

Where Next?

A long path to go from mostly harmless to Elite! Well, that and expansions!

I’ve already implemented the first add on, the Electron’s Plus1 module. This provides support for ROM cartridges and two joysticks (printer port not supported).

Whilst this is now working allowing you to use LISP (no takers?) rather than BASIC or run Starship Command without waiting several minutes for it to load from tape, there’s a little more work required UI wise to make using ROMs simpler.

Beyond that, I’m not sure.

I’m toying with the idea of implementing the Plus3 for floppy disk support or Plus5 for the “tube” bus which provides support for Acorn’s second processor. Then again, it might finally be time for a new project, learning how to reverse engineer the ULA die. Assuming that’s not beyond me, I might then be able to put to bed some of the questions I have had over the last few months regarding my interpretation of the schematics and how the Electron appears to function slightly differently.

and then? NES on the Replay would be nice wouldn’t it…