Electron to BBC Conversions

[BigEd]

Not sure if this affects your reasoning, but the RAM is arranged such that you can get two consecutive nibbles in two accesses - or at least, two nibbles from the same page. Which is to say, you don't get two arbitrary accesses.

[crj]

I've finally tracked down an earlier StarDot conversation which is quite illuminating, if only in confirming what I'd managed to deduce somewhat painfully in this thread.

It does appear that the Electron is modelling a 2MHz 8-bit random-access memory subsystem, which is then shared between the CPU and video.

The page-access issue is a good point. According to the circuit diagram, the Electron uses 4164-15 parts, which take 260ns for a random access, 145ns for paged access. Hence, 405ns for random access to a byte consisting of two nibbles. But, alas, 520ns for two random-access nibbles - not quite fast enough. )-8

Conversely, now I see the full horror of how the Electron implemented two entirely different strategies for bus arbitration between CPU and video depending on whether it was in MODE0/1/2/3 or MODE4/5/6, I can't help feeling that a single-byte video FIFO would actually have been simpler, as well as giving better performance in all cases. Have a "FIFO demand" signal which becomes true during each hsync pulse and false once the final byte for the line has been read. Then, every 2MHz cycle: is the FIFO empty and in demand? If so, fetch a byte for video. If not, let the CPU have a cycle. Given one byte is always enough to keep the video subsystem happy for at least 650ns and a CPU memory access takes 500ns, that could never fail.

[BigEd]

Bear in mind the Electron ULA was (is) completely full, to the point of only just being routeable. So it's possible there are better ways of arranging things which there just isn't room for - but also possible that there are better ways which weren't thought of.

[crj]

Agreed. But giving the memory subsystem to the CPU and video on alternate cycles in some modes, CPU during flyback and video during raster output in other modes, sounds to me a whole bunch more resource-intensive than an 8-bit edge-triggered latch.

(In an ideal world, you'd also arrange that the CPU not crash when you changed from one to the other. (-8 )

[BigEd]

I suppose with a replacement ULA project you could experiment with these kinds of tactics - if you had the self-control to use only the original nibble RAM and not implement a simpler but more costly shadowing scheme!

The efforts to reverse engineer the ULA might well give us some interesting information about the implementation and the layout.

[crj]

Indeed. It'll be interesting to see what those projects come up with!

[ThomasHarte]

Sorry, I was on holiday!

The Electron's 6502:

• runs at 2Mhz when accessing ROMs in any mode;
• runs at 1Mhz when accessing RAM in modes 4–6, regardless of the current raster position;
• runs at 1Mhz when accessing RAM in modes 0–3 if pixels are not currently being output; if pixels are currently being output then the CPU clock is stopped until they are no longer being output. So 0–2 are slower than 3, because 2/10ths of lines in 3 are blank, and all of them are the same speed as modes 4–6 when drawing the border.

Transitions from 2Mhz to 1Mhz follow much the same rule as (I understand) the BBC micro applies: you've got to be in phase, so in 2Mhz terms a 1Mhz cycle that follows a 2Mhz cycle can cost either 2 or 3 cycles. ElectrEm warning: it has an off-by-one error on that transition that makes it just a shade slower than it should be when transitioning. That's what's going on with this BASIC benchmark, even though commercial software tends to work well because it tends to transition between ROM and RAM very rarely.

Clock Signal has no such error and is the only emulator to get the proper numbers for that benchmark.

So, for software that isn't racing the beam you're probably fine just waiting for the display interrupt then burning half the available cycles before proceeding.

Re: palettes and modes, switching palettes on the 100Hz interrupt is the most common way to hide program data within the display, given that there's no CRTC so you can't just redefine the display size to increase your room for program data.

More complicated things, off the top of my head, if memory serves:

• Gauntlet (in the game menu), Kane and at least one of the flight simulators that is probably 737 Flight Path change mode mid display. The latter does it several times for a menu screen, switching between the 80-column and 40-column modes;
• Southern Belle and Evening Star also use a palette swap to hide data, but trigger on a tape data-related interrupt;
• Spy vs Spy switches to black at the 100Hz interrupt, then busy loops for a while, then switches back to colours. So it hides data in a thin band in the middle of the display;
• Sphere of Destiny is almost entirely a busy palette-changing loop;
• Firetrack switches between modes 6 and 5 after counting in a busy loop to get a hardware scroll.

... but I must plead sufficient ignorance of the BBC's catalogue as to be unable to produce a version of that list specialised to titles that don't already have native BBC versions, and therefore those that might be of interest for a conversion.

Re: Pi options, given that there are almost no examples of a hardware scroll (Firetrack as mentioned for a smooth scroll, also Syncron and probably others I've forgotten just use the 8-pixel vertical scroll), I would dare imagine that differential frame analysis would work pretty well, though the problem would be which graphics mode to use on the BBC. E.g. Sphere of Destiny uses all eight colours and contains a 320px section of display for informational text. So if you don't want to get into supplying the BBC with mode-change locations then you'll probably have to mess up the text.

[crj]

• runs at 1Mhz when accessing RAM in modes 0–3 if pixels are not currently being output; if pixels are currently being output then the CPU clock is stopped until they are no longer being output.

Really? Not 2MHz?

[myelin]

Yep, the Electron never accesses RAM (or &FCxx/FDxx, and maybe &FExx) faster than 1MHz.

[davidb]

The 1MHz access is mentioned in chapter 5 of the Acorn Electron Service Manual.

[ThomasHarte]

I checked, and it is Flight Path 737 I was thinking of, as attached.

'Flying Experience' and 'Select Level (1 to 6)' are Mode 1; the six numbered options are Mode 4 with busy wait palette changes. So that's all eight colours on a 320px width display. I think possibly a developer found himself with an opportunity for amusement.

The actual game also has a 1/6 mode split as pictured, but just the one.

Also, a quick bit of extra detail on my ElectrEm comments: rather than applying a cost of two or three 2Mhz cycle lengths when a 1Mhz access follows a 2Mhz access depending on phase, it applies a cost of 1 or 2, owing to my misreading of the EAUG. At the time I understood memory to be pumping out as though an 8-bit 2Mhz device, so either you hit the 2Mhz-sized window or you have to wait for it. What actually seems to be going on, conceptually at least, is that there is a 1Mhz signal clock aligned for proper RAM access an the job is to transition the CPU onto that. So it either has to pause for a 2Mhz cycle or it doesn't but either way it's then on a 1Mhz clock. If I had known more about the BBC and its stretched cycles at the time, I hopefully would not have made the error. As per my extended exposition, I'm still a little annoyed about it.

[crj]

Ooh - I'd not seen the Service Manual before. That would have saved me a certain amount of reverse engineering earlier in this thread!

It's curious that the divide-by-thirteen clock signal is an input to the ULA. I'd have thought that awkward clock divisions were exactly what a ULA was good at.


And yeah, it seems the Elecrton's memory subsystem is, indeed, horrible. I guess getting it out the door at a cost point was much more important to Acorn than performance at the time it was being designed. /-8

[Michael Brown]

I don't suppose anyone has been able to convert Flightpath 737 to work on the BBC B from its original Electron version?

Mick.