Electron to BBC Conversions

[Michael Brown]

Hi All,

Thought I'd start a new topic here.

Many years ago I came across some games that only got released on the Acorn Electron.
These games would usually run faster on the BBC than they would on the Electron.

For the purpose of this topic I am refering only to Machine Code games and not Basic ones as they can be slowed down with various FOR/NEXT loops etc.

Back in the day I never had an Electron (or access to one) so a lot of guess work went into getting the right speed for the game.

Now days we have emulators like BeebEm, B-em and ElectrEm to test the games.

The first game I came across was a Defender clone called Guardian by Alligata that was written by Steve Evans who had written several BBC games for them - but no BBC released version of Guardian (unless the author wrote one but didn't submit it or Alligata didn't publish it).

Here's a list of things to do...

1) take the original Electron uef of Guardian and load it into ElectrEm and see how it performs making a note of the speed of the game and the sound effects and any mode 6 screens.

2) take the original Electron uef of Guardian and load it into BeebEm or B-em and see also how it performs again making a note of the speed of the game and the sound effects.

3) load in a copy of the amended version and compare with the 2 above.

here is my latest revised version of Guardian with the speed set faster than the version on my disc014 but slightly slower than the original euf.

guardian.zip

(8.63 KiB) Downloaded 141 times

The idea is to get this game to run on the BBC at the same speed as the original uef does on a Electron.
It would appear that my original attempt on disc014 made the game too slow.

Here's the routine to slow the game down that gets poked into memory at &3A2

3A2 LDX #&FF
3A4 LDY #&12
3A6 DEY
3A7 BNE &3A6
3A9 DEX
3AA BNE &3A4
3AC JSR whatever routine was originally intended
3AF RTS
Note the &12 at &3A4 is currently included in the version of the game above and the one on disc014 has &18 which slows the game down further.

Also with Electron games the Envelopes sometimes need changing - well the last 6 numbers to 126,0,0,-126,126,126.

regards,
Mick.

[leenew]

Has the slowing down made the game more jerky?
Can it be done in a smoother way?
Challenge?

Lee.

[Michael Brown]

I think what's needed it to take the new version and load it into both BeebEm and b-em emulators and also load it onto a real BBC and compare the 3 and see where any jerky (if any) come into play.

It may then be that altering that figure (&12) to say &11 or &13 makes for a less jerky game.

I can't use my Beeb but the newer version seems alright under emulation.

Hopefully members can check this game out and leave me some feadback.

regards,

Mick.

PS If anyone has a better or alternative way to make Electron games run at the correct speed on the Beeb, then please let me know.

[lurkio]

Mick, this is a very minor and unconstructive comment, I suppose, but do you want to change the subject of this thread from "Converts" to "Conversions"?

Otherwise it sounds like it's about former Elk users who saw the light and became converts to The Way Of The Beeb -- which is only right and proper!

[runs like hell before daveejhitchins reads this]

[Michael Brown]

Sorted.

[daveejhitchins]

[runs like hell before daveejhitchins reads this]

Dave H

[Wouter Scholten]

I think what's needed it to take the new version and load it into both BeebEm and b-em emulators and also load it onto a real BBC and compare the 3 and see where any jerky (if any) come into play.

It may then be that altering that figure (&12) to say &11 or &13 makes for a less jerky game.

I can't use my Beeb but the newer version seems alright under emulation.

Hopefully members can check this game out and leave me some feadback.

regards,

Mick.

PS If anyone has a better or alternative way to make Electron games run at the correct speed on the Beeb, then please let me know.

I tried the new version of Guardian and it's much better, as in playable and not as if I'm watching slow motion. But I have no reference as to what the original speed is. I do notice big slow downs when there are 2 or 3 landers picking up men at the same time on screen, then scrolling is juddery. Is it that way on the Electron?

As to proper speed decrease, this is not so easy as the time per loop can vary. I think the way to be most accurate is to use a interrupt routine that sets up a 6522 timer (a high order counter in zpage should not be needed, with the counter starting at 65535 you have 0.06 seconds), then when the loop ends you read out the 6522 counter registers to decide on how much time to wait. For MODE 5, what was the speed difference, about a factor 2? Well, wait (speedfactor-1) * elapsed time (elapsed time = 65535-counter) and then continue. This does not take into account games that speed up by I think it was switching the screen of during vertical retrace that I read about. So would need to measure there what would be a more appropriate speedfactor. Also vsync waiting or counting in games may be getting cooked by the long wait in one particular spot at the end of the game loop...

[Michael Brown]

Just loaded the uef again into ElectrEm and there is a bit of judder, not sure though if this is a emulator problem - so this needs playing on a real Electron to see what happens there.

Just tried the game again and one thing I have noticed is that the game seems to run slower on B-em than it does on BeebEm.
Now if it is just BeebEm that runs it fast then I can add a detect routine to check for BeebEm and if not there then change the contents of &38A5 from &12 to &08 to make it faster on B-em (and a real BBC?).

Here is a brand new modified version of the game with the check for BeebEm.
Speed is set at &12 under BeebEm and will change to &08 under B-em (and on a real BBC?).

guardiantest.zip

(8.63 KiB) Downloaded 152 times

What I really need is for someone to play this newly amended verson of the game on a real BBC and compare the speed with B-em and if they are the same, and it is simply a BeebEm issue, then hopefully this version should sort it.

regards,
Mick.

[leenew]

Hi Mick
I have tried the latest image on a real beeb and it plays well.
I have tried it on BeebEm and it seems to be comparable.
However, when playing it on B-Em, it is really sluggish, so I would ditch the differentiation between the emulators and I will try it again.
Please bear in mind I still haven't played it on a real Electron or Electron Emulator so I am not sure of the original speed, but it seems about right to me....

**EDIT** I have played the game in JSBeeb and the speed seems comparable, but it seems *SMOOTHER*, not as jerky....

Lee.

[Michael Brown]

Hi Lee,

That's odd - I thought B-Em would be closer to a BBC than BeebEm is.
Sadly cannot ditch the Emulator detector as it only detects if BeebEm is there (or not) and not B-em.

One thing I have done is alter the code that slows the game down to make it JSR its original routine &18A8 first then do the slow-down instead of the slow-down then JSR&18A8.

Here is another test image of that change.
Can someone check what this runs like on all formats.

Mick.

guardiantest2.zip

(8.63 KiB) Downloaded 146 times

[Michael Brown]

Hi,

After playing the latest version a few times on both BeebEm and B-em - I think I have the closest balance I can get with this.
If anyone has any issues then please let me know.
If not - then I will add this version to my collection and re-post the disc asap.

regards,
Mick.

[Michael Brown]

Disc 014 now re-posted featuring this amended version of Guardian.
I hope this is better for everyone.

regards,
Mick.

PS Will also re-post Alternative discs 105 and 109 which feature this change as well.

[Commie_User]

Well all's well that ends well but Electron to BBC Conversions?

If there's all that big a stack of games people want on the Beeb, perhaps a homebrew EPROM set is called for. Jam 'em in the motherboard to make a BBC fully Elk compatible and somebody's on for a nice earner.

It may be less hassle than converting every game but I don't know.

[jms2]

That's not how it works unfortunately. The Electron has different hardware to a BBC and is fundamentally not fully compatible with it. Apart from the OS, which has to be different between the two machines for this reason, the only rom in an Electron is Basic 2 which is identical to the BBC version.

There's next to nothing that an "elk mode" rom could achieve in a BBC, except trivial things like making Mode 7 not work!

[crj]

That's not how it works unfortunately. The Electron has different hardware to a BBC and is fundamentally not fully compatible with it.

As a thought experiment, suppose you were willing to unplug the 6502 from your Beeb and put a logic board it and the mainboard. How much would that need to do to convince Electron games to run on the Beeb?

What if, for example, that board just slowed down memory access, and a modified OS took care of presenting the Electron's facilities implemented in terms of Beeb hardware? How much stuff would be happy with then?

The next step would be a biggie: map between the Electron and Beeb layouts for Shiela. Just about the only bits of hardware on a stock Electron are the ROM paging register, keyboard, video, sound and tape; which of those would games be most likely to poke directly rather than through published OS routines?

(It occurs to me that it's display mode changes would be the absolute pits, because that's achieved by a write to a single register on the Electron but requires dozens of CRTC registers to be updated on the Beeb.)

[jms2]

I'd imagine it could be done, but even for partial compatibility it would still be difficult - not the simple writing of a new rom as Commie_user envisaged.

As an example of what some Elk games might do, Citadel reads the keyboard in hardware and so uses the rom select register and expects to find a keyboard in rom 8 (I think its rom 8 anyway).

[Commie_User]

I'd imagine it could be done, but even for partial compatibility it would still be difficult - not the simple writing of a new rom as Commie_user envisaged.

Oh I don't know. (Literally!)

What about something like the Apollo Vampire card for the Amiga 600? Apparently you just plop it over the CPU and it accelerates the machine and adds new graphics modes, HDMI out, USB and all kinds of whatnot. Dan Wood on Youtube had a go and it was lovely to see him have a tinker.




Is it theoretically possible to add all kinds of whatnot to the BBC B to expand compatibility?

[RobC]

Rather than developing new hardware, as crazy as it might sound, there could be some mileage in putting an Elk emulator on the Pi co-pro.

[crj]

You'd have to have a really good strategy for getting screen updates across the Tube in a timely manner!

(I remember us discussing this recently, but I don't seem to be able to find where.)

[RobC]

You'd have to have a really good strategy for getting screen updates across the Tube in a timely manner!

I don't think it would need to be that good as:

a) You'd just send differences so you're changing the same number of pixels as the Elk's CPU.
b) The host will be running at 2MHz whereas the original Elk will have been running at least twice as slow when accessing RAM.
c) The Pi can supply data as quickly as the host can read it.
d) Any hardware tricks will essentially be a subset of what the Beeb can do.

Some thought would have to be put into how to handle mid-frame palette changes etc. but I think it's doable.

[chrisn]

That's odd - I thought B-Em would be closer to a BBC than BeebEm is.
Sadly cannot ditch the Emulator detector as it only detects if BeebEm is there (or not) and not B-em.

One thing I have done is alter the code that slows the game down to make it JSR its original routine &18A8 first then do the slow-down instead of the slow-down then JSR&18A8.

I wonder what needs to be improved in BeebEm to make it more accurate. How are you detecting the emulator, and when detected, what adjustments do you make? Is it the playing speed or are there other issues?

[crj]

I don't think it would need to be that good as:

a) You'd just send differences so you're changing the same number of pixels as the Elk's CPU.
b) The host will be running at 2MHz whereas the original Elk will have been running at least twice as slow when accessing RAM.
c) The Pi can supply data as quickly as the host can read it.
d) Any hardware tricks will essentially be a subset of what the Beeb can do.

Some thought would have to be put into how to handle mid-frame palette changes etc. but I think it's doable.

OK. Here's the back of the envelope for a semi-sophisticated implementation.

The emulated Electron does:

Code: Select all

STA (&10),Y

...to write a byte to the screen. That takes six cycles which in the best case (i.e. Electron's performance being worst-case) is 6µs.

I will now assume:

• The Raspberry Pi runs infinitely fast (which it basically does, in this context (-8 )
• Each screen memory write in the emulated Electron becomes three bytes over Tube FIFO 1: low address, high address, byte
• So that this can work, you've hijacked the Tube Host System and replaced it with a custom alternative
• Your poke tight loop is running in zero page

The tight loop would look something like:

Code: Select all

.poke
  LDY &FEE1
  LDA &FEE1 : STA sta_absolute+2
  LDA &FEE1 : .sta_absolute STA &0000,Y
  BIT &FEE0
  BMI poke
  \ Handle things other than pokes!

That takes 4+4+3+4+5+4+3=27 cycles, so 13.5µs . Which is conspicuously higher than 6µs. I guess you could rely on the Electron not sustaining that write rate most of the time, sneak in some code on the Raspberry Pi to elide writes, and tolerate screen updates lagging occasionally, but it's all uncomfortably tight!

[RobC]

You'd want to have several routines for writing data to the screen - one for writing bytes at unrelated addresses (as you've shown) and others for writing runs of bytes (e.g. 8 lines, 8 columns etc) which can therefore be quicker. The Pi can decide on the best one to use.

However, I think the key point is that the Electron isn't going to be doing writes all the time (as you've said). In terms of screen updates, I'd say it's comparable to Spectrum and is probably running at a similar speed. The Spectrum emulator has already shown that the Pi co-pro is fast enough to cope with Spectrum games...

...to write a byte to the screen. That takes six cycles which in the best case (i.e. Electron's performance being worst-case) is 6µs.

I thought the Electron's worst performing case was slower than 1MHz (e.g. modes 0, 1 & 2)?

[crj]

You'd want to have several routines for writing data to the screen - one for writing bytes at unrelated addresses (as you've shown) and others for writing runs of bytes (e.g. 8 lines, 8 columns etc) which can therefore be quicker. The Pi can decide on the best one to use.

Ah, but it can't! Not straightforwardly, anyway.

The problem is that if you want to combine writes, you have to delay the first write to see if any more come in. You could get cunning and start out sending bytes one by one, only combining them if a backlog begins to accumulate, but then the combiner becomes quite closely coupled with the code that's trying to emulate a 2MHz bus in real time, rather than a preprocessing step...

However, I think the key point is that the Electron isn't going to be doing writes all the time (as you've said).

The absolute worst case would be a CLS/mode change. Typing "MODE 2" means the Electron will start doing a batch of "STA &3000,Y : STA &3100,Y : ..." instructions back to back. People writing video games obviously want to be approaching that level of optimisation for texture-fills, though they may well not succeed.

In terms of screen updates, I'd say it's comparable to Spectrum and is probably running at a similar speed. The Spectrum emulator has already shown that the Pi co-pro is fast enough to cope with Spectrum games...

Well, unless you're messing with changing attributes between scan lines (which some software did, but I assume that doesn't work on the emulator?) the Spectrum has 6.75Kbytes of screen memory and it's futile to write to it more than once per frame, which means people are unlikely to perform more than 50*6.75=337.5Kbytes of screen writes per second.

By contrast, MODE0/1/2 on an Electron has 20Kbytes of screen memory, giving a much higher practical upper bound of 1000Kbytes/second on what could ever be useful.

I thought the Electron's worst performing case was slower than 1MHz (e.g. modes 0, 1 & 2)?

Not sure. I'm much less familiar with Electron hardware than Beeb. But if it's a 4-bit-wide 4MHz memory system, that's a sustained 2Mbytes/sec of memory I/O, and it needs to read 1Mbyte/sec to render 20Kbytes 50 times a second, so intuitively I guesstimated 1MHz being left over for the CPU. I see Wikipedia quoting 0.5897MHz as a worst case, but it doesn't exactly show its working. (Reading between the lines, that would make sense only if the Electron had no kind of FIFO between memory and the video subsystem so that, if it needs a byte every 650ns, it holds the bus continuously rather than reading two bytes every three cycles and letting the CPU have the other. Whoops!)

Conversely, Wikipedia has also highlighted something I'd overlooked, which is that ROM access is at full speed. So if you execute STA &3000,Y from ROM, that's not 4 cycles so much as 3 fast cycles and 1 slow one. Even using 0.5897MHz as the speed for RAM accesses, that's suddenly only 3.2us per access.

[RobC]

Ah, but it can't! Not straightforwardly, anyway.

The problem is that if you want to combine writes, you have to delay the first write to see if any more come in. You could get cunning and start out sending bytes one by one, only combining them if a backlog begins to accumulate, but then the combiner becomes quite closely coupled with the code that's trying to emulate a 2MHz bus in real time, rather than a preprocessing step...

I wasn't advocating running in step with the original CPU. You can get the Pi to process a frame's worth of instructions and then send all the screen updates for that frame. This allows you to only send the differences and batch up writes.

The absolute worst case would be a CLS/mode change. Typing "MODE 2" means the Electron will start doing a batch of "STA &3000,Y : STA &3100,Y : ..." instructions back to back. People writing video games obviously want to be approaching that level of optimisation for texture-fills, though they may well not succeed.

It would be a relatively simple case to detect and you already have code on the Beeb that does CLS

Also,I use a batch of unrolled stores to do something similar to update a whole row in my Spectrum emulator.

By contrast, MODE0/1/2 on an Electron has 20Kbytes of screen memory, giving a much higher practical upper bound of 1000Kbytes/second on what could ever be useful

That's the theoretical limit without using overscan (20KB/frame x 50fps). This originally put me off from thinking you could use the Tube for games and emulators as you can't get anywhere near this sort of bandwidth across the Tube. However, the point is that the vast majority of real life software won't be getting anywhere near this.

[davidb]

d) Any hardware tricks will essentially be a subset of what the Beeb can do.

Some thought would have to be put into how to handle mid-frame palette changes etc. but I think it's doable.

I think the Electron can change the palette more quickly in certain modes (see this post) but maybe you were already thinking along those lines.

[crj]

I wasn't advocating running in step with the original CPU. You can get the Pi to process a frame's worth of instructions and then send all the screen updates for that frame. This allows you to only send the differences and batch up writes.

I don't have much of a feel for how fast a Pi can emulate the Electron. In general, the more you do before batching up some writes, the higher the latency. And reordering writes risks the occasional visible shear. (Though if that turned out to be the worst problem, I guess things would be going pretty well all things considered. (-8 )

Though doing that wouldn't decouple the Electron from emulated real time, so things like copy protection schemes may well still work, it would decouple the Electron from actual real time, as manifested through the Beeb's I/O. Would batching mess with things like Vsync interrupts?

But I admit I'm now far less sure that such techniques would be doomed. Maybe suck it and see...

It would be a relatively simple case to detect and you already have code on the Beeb that does CLS

If you just checked PC against the appropriate address in the OS ROM, sure. Though even then, you possibly need to cope with arranging that the emulated Electron appeared to take the right amount of time. Maybe even cope with some joker writing to the screen under interrupt while a CLS was in progress. Detecting CLS-like patterns in other code might be more of a challenge.


In the bigger picture, the Tube interface and API may not be the best fit for using Beeb peripherals from a hardware emulator. It's way better suited to hooking in at the OS level. The main reason to use PiTubeDirect is that it's already ubiquitous - and that's a good reason. Starting from scratch, either attaching to the CPU socket, allowing bus-speed access to all the Beeb's peripherals, or attaching to a ROM socket, where you can at least provide a continuous stream of instructions to execute, might be more straightforward.

[RobC]

I think the Electron can change the palette more quickly in certain modes (see this post) but maybe you were already thinking along those lines.

Ah - good point. I'd forgotten about that thread even though I followed it closely at the time. Do many (any?) games make use of the Electron's ability to do this?

Would batching mess with things like Vsync interrupts?

I batch things up by character row on the Spectrum emulator. This might be good enough for most things.

The main reason to use PiTubeDirect is that it's already ubiquitous - and that's a good reason.

Completely agree. It's by no means an ideal solution but I think it's the best that's currently available, it's cheap and it's likely to do a reasonable job in this context.

[davidb]

I think the Electron can change the palette more quickly in certain modes (see this post) but maybe you were already thinking along those lines.

Ah - good point. I'd forgotten about that thread even though I followed it closely at the time. Do many (any?) games make use of the Electron's ability to do this?

Not yet. There are games that palette switch but possibly not at a frequency that would pose much of a problem, I suspect. Otherwise, ThomasHarte might remember some games that might cause problems.

[crj]

Previously, I wrote:

(Reading between the lines, that would make sense only if the Electron had no kind of FIFO between memory and the video subsystem so that, if it needs a byte every 650ns, it holds the bus continuously rather than reading two bytes every three cycles and letting the CPU have the other. Whoops!)

A few days later, I suddenly realise: the Electron's memory system isn't an 8-bit 2MHz system; it's a 4-bit 4Mhz system.

So the video subsystem actually needs two nibbles every 650ns. The Electron's ULA must already contain a nibble latch so it can mediate between the 8-bit 6502 and video subsystem, and 4-bit memory. If they'd just added a second nibble latch so the video and CPU subsystems each had their own, that ought to have been sufficient to maintain full RAM utilisation and let the 6502 get a word in edgeways during video display.

If my reckoning is right, it's a real shame they didn't shoehorn in that small amount of extra logic. )-8