Second Processor Elite for the Electron

[jms2]

Many, many years ago, I managed to cobble together a revived version of John Wike's E2P board, thus giving my Electron a Second Processor. At the time I was acutely aware that there was actually very little software to run on it, and in particular the legendary Tube version of Elite wouldn't run. I knew a conversion was possible, but I had no idea where to start with it.

Recently Mark Moxon has released his incredibly detailed comments on the source for BBC Elite (BBCElite.com) and this provided the key to making a conversion possible. Another vital ingredient was a partial disassembly of the Electron tape version, which I think must have come from Kees because I don't remember doing it myself. Thanks Kees if so!

Anyway, here it is! It's a bit slow, and there is scope to improve it but I decided to release this version anyway to get some feedback.

As far as I know, there is no emulator which is suitable for this. You need real hardware, either an Electron with E2P or PiTube (I have tested it on both). It doesn't run on a BBC. This means the target user base is very small, probably in single figures!

This version remains black and white, but it brings a *lot* of new features to the Electron, including:

- All the ship types, including Thargoids
- Suns
- Planets with craters or latitude/longitude lines
- Interior views of space stations.

Elk Tube Elite v100.zip

(96.88 KiB) Downloaded 133 times

[davidb]

Sounds impressive!

If there's a "killer application" for the Electron Tube then Elite is probably it.

[danielj]

Good work!

Does it work like the beeb-tube version with a display client on the I/O and everything else on the parasite?

d.

[jms2]

Yes, thats exactly how it works. The code on the parasite side is actually the same as the BBC version, with two non essential changes:

- The sound effect when you hit something cannot be recreated easily on the Electron, so I changed it a bit.
- For speed, I reduced the angular resolution of planets (the Elk version already does this).

All Tube communications use OSWRCH, OSRDCH and OSWORD.

[Pernod]

As far as I know, there is no emulator which is suitable for this.

It works in MAME! This is configured with Electron, AP6, Pegasus 400, AP5, Acorn 6502 2nd Processor.

[rmbrowngr]

Fantastic! Going to give this a try a bit later.

Did you you also change loading and saving commanders to disk and not to tape?

[rmbrowngr]

As far as I know, there is no emulator which is suitable for this.

It works in MAME! This is configured with Electron, AP6, Pegasus 400, AP5, Acorn 6502 2nd Processor.
0181.png

Is there detailed instructions for setting Mame up from the Elk? I struggled the last time I tried this.

[jms2]

As far as I know, there is no emulator which is suitable for this.

It works in MAME! This is configured with Electron, AP6, Pegasus 400, AP5, Acorn 6502 2nd Processor.
0181.png

Ah, MAME - silly of me to forget, I even have a download of that!

[jms2]

Fantastic! Going to give this a try a bit later.

Did you you also change loading and saving commanders to disk and not to tape?

This is the full Tube version, so it should just work (I did not need to do anything). That said, it is one aspect that I have not tested.

[walkerworks]

Booted it up on my E2P this morning and it's working well, I think I'll need to read some manuals to fly this

Derek

[danielj]

I seem to recall that the original 2nd proc version didn't rely on OSWRCH etc, and implemented its own tube protocol? Would that speed things up?

d.

[jms2]

What do you mean by the "original"? There's only one version that I'm aware of, and I have simply adapted what was already there.

How the communication protocol works, in outline terms, is that the OSWORDs are handled by using unused OSWORD calls above 240. OSWRCH is used for line drawing and amounts to using certain characters as "control codes" to differentiate between ASCII characters and lines. OSRDCH is pretty standard I think, but is not used in flight mode - instead it scans the keyboard directly and returns the results via OSWORD. I think.

Writing directly to the Tube registers would indeed be faster but would be a major job. There are some easier optimisations to be had, which I'll explain if I manage to get them working!

[danielj]

What do you mean by the "original"? There's only one version that I'm aware of, and I have simply adapted what was already there.

How the communication protocol works, in outline terms, is that the OSWORDs are handled by using unused OSWORD calls above 240. OSWRCH is used for line drawing and amounts to using certain characters as "control codes" to differentiate between ASCII characters and lines. OSRDCH is pretty standard I think, but is not used in flight mode - instead it scans the keyboard directly and returns the results via OSWORD. I think.

Writing directly to the Tube registers would indeed be faster but would be a major job. There are some easier optimisations to be had, which I'll explain if I manage to get them working!

Ah, OK - I thought you'd re-implemented some of it ab-initio using the Electron version etc (and as I say, it was a hazy recollection of something someone had said at one point!) - Look forward to seeing how the optimisations work!

d.

[trixster]

This is tremendous! Nice work!

[MarkMoxon]

Fantastic! This is exctly the kind of thing I hoped my annotated source would help with. Bravo - I'm off to install MAME to see the magic for myself.

Whatever next? Atomic Tube Elite, perhaps?

Mark

[jms2]

I reckon Kees could do that. It would if anything be easier than the Atom Elite that he has already done.

[trixster]

Atomic TubeElite would be the dream

[danielj]

Atomic TubeElite would be the dream

Before world peace?

[trixster]

One step at a time!

[jms2]

I have been working on a couple of speed improvements, but without success. I'm sure they are both possible, but they are certainly harder than I thought:

1) Use a lookup table to obtain the address of the left hand byte for each display row. This ought to be easy, as there is plenty of memory for a look-up table and the benefit should be worthwhile: with the Elk's Mode 4 screen layout the mathematical contortions needed to generate the address are painful. I created a version which almost worked, but I must have made a mistake somewhere because I get loads of stray pixels generated on the screen. I can't figure out why!

2) Change the parasite code to use Electron internal key numbers rather than BBC micro internal key numbers. By jumping into the OS at &EC1C instead of &EC53, you can avoids having to translate the BBC internal key numbers, which ought to save a lot of time. However, the changes are a lot more extensive than just changing some numbers, because it's necessary to understand some bits of code which aren't covered by Mark's write up (yet).

I'm not sure it's worth the effort! However, on the plus side... I have discovered that when Tube Elite is paused, pressing Ctrl+D saves a screenshot. Don't know if that has been mentioned by anyone previously.

[MarkMoxon]

However, the changes are a lot more extensive than just changing some numbers, because it's necessary to understand some bits of code which aren't covered by Mark's write up (yet).

I'm about to start documenting the parts of the 6502 second processor version that differ from the cassette version (of which there is quite a bit!), so if it would help, I can start with the keyboard stuff - I've got to start somewhere. If there are any particular routines that you'd like me to tackle, let me know the labels and I'll make sure I cover them in the first batch.

I've recently finished merging all the applicable commentary from the cassette version into the 6502sp version source, so now it's time to document the unique aspects of the second processor version. It should be interesting...

Mark

[jms2]

That would be handy Mark.

I got unstuck in DOKEY where it started indexing into the table KTRAN, which is just some numerals cycling through 012345678 etc.

[MarkMoxon]

I got unstuck in DOKEY where it started indexing into the table KTRAN, which is just some numerals cycling through 012345678 etc.

I’m pretty sure that KTRAN gets overwritten by keypress information coming from the I/O processor over the Tube (i.e. from the Electron/BBC), as DOKEY contains an OSWORD call that I think transfers data... but this Tube stuff is all new to me, so I’m learning as I go!

I’m very nearly done decoding the second processor’s extended text tokenisation system, and when I’m done with that, I’ll document all the KTRANS-related stuff. Hopefully that will help explain what you need to do to speed that end up on the Electron Tube version...

Mark

[jms2]

Ah, so its dummy data. That makes sense.

I got to the point where I was pretty conversant with most aspects of the I/O side of the code. What I know is that lines and characters are plotted using OSWRCH, with various other jobs (including reading the keyboard) undertaken using dedicated OSWORD calls.

KEYBOARD scans the whole keyboard and fills in the keypress log. DODKS4 scans for a specific key number, although I think this is actually only used to test for the CTRL key.

OSRDCH is also used, I presume when entering text such as searching for a system name, or specifying a filename.

I haven't looked much at the parasite side. One nasty thing I found is that the code relies on the internal key numbers for f1, f2 and f3 being consecutive - but they aren't on the Electron! It's all fixable of course, but the to-do list was just getting bigger and bigger.

[MarkMoxon]

I haven't looked much at the parasite side. One nasty thing I found is that the code relies on the internal key numbers for f1, f2 and f3 being consecutive - but they aren't on the Electron! It's all fixable of course, but the to-do list was just getting bigger and bigger.

In terms of the parasite code, when it checks for function key presses, it tests the values against the variables f0 through f9, so those could be given new values pretty easily... though I think all the other key values are hard-coded rather than using variables. But you’re right, the code does rely on consecutive key values in quite a few places (e.g. the configuration section when the game is paused), so that alone might make it not worth the effort. Is converting from Electron key codes into BBC ones inefficient? I’d have thought a lookup table would be fairly quick, but I’m not familiar with the way the Electron handles keys, so I have no idea what’s involved...

Mark

[jms2]

It is done using a lookup table in rom, so not intrinsically inefficient but its just an additional step that has to be done for every internal keynumber when scanning the keyboard.

By the way, I found one place where the f keys are referred to numerically, not by using the f0, f1 etc variables!

[MarkMoxon]

By the way, I found one place where the f keys are referred to numerically, not by using the f0, f1 etc variables!

I bet! I’ve tried to keep as close to the original source as possible, and although variable use is generally pretty consistent, it isn’t perfect. I keep having to resist rewriting bits of the source to make it clearer, but I don’t want to start drifting too far away from the digital preservation aspect of the project...

Though this doesn’t apply to people using the source code, of course.

Mark

[rmbrowngr]

I don't if it can be easily changed, but in the 2nd processor version you start with a complete ship with loads of money. It would be nice, like the non-2nd processor version, to have the option to start with a basic ship and a 100 credits.

[MarkMoxon]

I don't if it can be easily changed, but in the 2nd processor version you start with a complete ship with loads of money. It would be nice, like the non-2nd processor version, to have the option to start with a basic ship and a 100 credits.

In terms of released versions, that's only the case in the Executive Edition. In the standard 6502 Second Processor version you start with the usual 100 Cr and nothing but a Pulse Laser, just like in normal Elite.

In my semi-documented 6502sp repository version, you get the maxed-out commander if you build an unencrypted version (with 'make build'), so it's easier to test, but you get the basic commander if you build an encrypted version (with 'make encrypt'). This is easy to change via the Makefile if you want an unencrypted, basic commander.

Mark

[MarkMoxon]

Oh! Sorry, you're talking about the Electron Tube version. Ignore me!

That's something jms2 can hopefully change...

Mark