Second Processor Elite for the Electron

[jms2]

I can certainly change that. Actually I left in all the additional weaponry etc because I thought it would help with discovering the new features (like the Thargoids, etc). But I know I can easily turn it off.

Another thought has occurred to me regarding speed-up opportunities. Aside from the use of a "line start" lookup table, the second processor version also uses log tables to speed up multiplication when drawing lines. This was first introduced for the C64, and it was included in the Beeb second processor version because it represented the best available solution by that point. Anyway, to make life easier I removed it and dropped in the standard Electron line plotting routine. However making the log version work on the Elk would be ideal - it just needs tweaking to account for the screen layout differences between "narrow mode 1" and mode 4.

I have done no detailed examination of how hard or easy this would be. Maybe its easier than I think.

[ash73]

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

The normal tube version is better than the exec one imo, because it doesn't have the uninterruptable 3D text on the load screen (unless you leave it for a while) which I think looks quite naff.

Try playing Elite-A, it has the tube enhancements and some nice extra features such as buying ships. You start in an Adder with 500 CR no laser and 7 tonnes cargo capacity and it takes about 250k CR to get a fully equipped Cobra MkIII...

I quite like the Master version because it's much less flickery (albeit slower) than the tube version. They must have coded a different plot routine or double buffering that didn't make it into the tube version.

There's a Commander Editor program that you can use to create whatever starting conditions you like. You can convert standard commander files to Elite-A ones, but it doesn't seem to bring the ship or equipment across, just your combat rating and credits.

[ash73]

OP - might be worth a look at the Master version to see what they did differently, maybe you can incorporate it.

Great achievement anyhow! Used to love my Elk but I missed Mode 7.

[jms2]

OP - might be worth a look at the Master version to see what they did differently, maybe you can incorporate it.

That's a good idea, and something I have given some thought to. However, I think it will be difficult on the Electron. I suspect that it was achieved on the Master by using double-buffering with the shadow ram. However, as far as I know the source code to the Master version has never been made public. Furthermore, the Electron doesn't have shadow ram (unless it is fitted with a Master Ram Board).

On the plus side, the Electron's mode 4 screen only uses 10k, so 2x mode 4 screens =20k. This is not hugely more than what the BBC client's screen mode uses - the latter is a narrow version of Mode 1 which uses 16k. So we would potentially need to find an extra 4k from somewhere. Having PAGE at &E00 will help, plus any spare memory that might be present. From memory, I doubt this adds up to 4k... but it might.

[ash73]

OP - might be worth a look at the Master version to see what they did differently, maybe you can incorporate it.

That's a good idea, and something I have given some thought to. However, I think it will be difficult on the Electron. I suspect that it was achieved on the Master by using double-buffering with the shadow ram. However, as far as I know the source code to the Master version has never been made public. Furthermore, the Electron doesn't have shadow ram (unless it is fitted with a Master Ram Board).

On the plus side, the Electron's mode 4 screen only uses 10k, so 2x mode 4 screens =20k. This is not hugely more than what the BBC client's screen mode uses - the latter is a narrow version of Mode 1 which uses 16k. So we would potentially need to find an extra 4k from somewhere. Having PAGE at &E00 will help, plus any spare memory that might be present. From memory, I doubt this adds up to 4k... but it might.

Could you do it in mode 1 and simulate double buffering by using two different foreground colours, both displayed as white? The "frame" being plotted would be set to black and then the palette switched to white when ready, and vice versa. You could use the third colour for lasers. I never really thought the tube version needed any more colour than that.

[jms2]

I can think of two problems with that, unfortunately:

1) The Electron's speed reduces even further in Modes 0, 1 and 2.
2) Where the movement of a ship causes a line's angle to change slightly (as must happen a lot), the new and old lines would overlap, so the flicker would still be visible.

The best improvement, flicker-wise, would be to synchronise the erasure and replotting with the vertical blanking interval. However, I'm pretty sure that the Tube version does not do this. I'm not exactly sure why, but I suspect that the reason is to do with the asynchronous nature of the communications between the two processors. The demand to plot a line can arrive at any time, and if the host processor doesn't deal with it immediately... well I'm not exactly sure what would happen. It's something I've always wondered about!

[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...

Just to let you know I have finished documenting the keyboard routines in the 6502sp version - you can see the results in the latest version of the repository. I think I need to write a deep dive on exactly how this works, as it can get a bit confusing (for me, anyway!), but essentially the parasite sends an OSWORD &F0 command to the I/O processor to ask it to scan the keyboard, which it does in the KEYBOARD routine. This sends back the key press information into the parasite's key logger buffer at KTRAN, which is then copied into the KL key logger so the existing non-Tube code can still work as before (though note that some parts of the parasite code also query KTRAN directly). Most of this information is either 0 or &FF to indicate whether the key is being pressed, but it also sends back the internal key number for non-primary flight keys.

Here's a list of the new routines and variables in the 6502sp version that deal with keyboards and joysticks (and Bitstiks):

Parasite:

Subroutine: DKS4
Subroutine: FLKB
Subroutine: RDKEY
Subroutine: ZEKTRAN
Variable: KTRAN
Variable: TRANTABLE

I/O processor:

Macro: DKS4
Subroutine: DODKS4
Subroutine: DOVAIE
Subroutine: KEYBOARD
Variable: KYTB

The existing keyboard routines are already covered in a deep dive on my site - the above essentially bolt onto the front of these to support the split between the I/O processor and the parasite.

Hopefully this is useful if you want to get stuck into the keyboard stuff again!

Mark

[jms2]

Excellent, thanks Mark!

Hopefully I'll get some quiet time to think about this over Christmas. I think it will be all about making several amendments to the parasite code to work around the Elk internal numbers. Nothing major I think, I just needed to recalibrate my expectations of what's involved.

[jregel]

OP - might be worth a look at the Master version to see what they did differently, maybe you can incorporate it.

That's a good idea, and something I have given some thought to. However, I think it will be difficult on the Electron. I suspect that it was achieved on the Master by using double-buffering with the shadow ram. However, as far as I know the source code to the Master version has never been made public. Furthermore, the Electron doesn't have shadow ram (unless it is fitted with a Master Ram Board).

On the plus side, the Electron's mode 4 screen only uses 10k, so 2x mode 4 screens =20k. This is not hugely more than what the BBC client's screen mode uses - the latter is a narrow version of Mode 1 which uses 16k. So we would potentially need to find an extra 4k from somewhere. Having PAGE at &E00 will help, plus any spare memory that might be present. From memory, I doubt this adds up to 4k... but it might.

I think I read (somewhere on Stardot) that the Master version doesn't actually double-buffer, but updates the ship one line at a time instead of erasing the whole ship and then redrawing it all.

[MarkMoxon]

Here’s the thread about double-buffering vs shadow RAM on the Master, where it looks like the conclusion is that it doesn’t use double-buffering, but instead has a less flickery drawing routine. That whole thread is an interesting read, as is this one, which also talks about how Elite communicates over the Tube.

Mark

[0xC0DE]

I'm part of the family now: https://twitter.com/0xC0DE6502/status/1 ... 6290073602
I couldn't get 2nd processor Elite working yet, unfortunately.
I tried the ROM version (*E2PON D) of the E2P driver and the non-ROM version.
When I start Elite (v1 by jms2, from MMFS) it hangs at the loading screen.
Any help is appreciated. @jms2: did you publish your source anywhere?

[jms2]

Wow ... a real one! They are almost impossible to find, where did you get that one Kelvin?

Which version of the ROM are you using, the original one or John Wike's latest version? It shouldn't make any difference, I'm just curious. Particularly in relation to the command *E2PON D, which is not one that I'm aware of. What does the "D" do?

I think that what you may be seeing here is an incompatibility with MMFS, as I have never loaded it via that method. I have not published my source code anywhere, but I'll upload it here - it is simply a BASIC program which assembles the host code file I.CODE. The P.CODE file is identical to the BBC version if I remember correctly.

As I have posted before, it would be nice to make the host routines faster... do you fancy giving it a go?!

Elk ELITEZ v100.txt

(17.87 KiB) Downloaded 57 times

[0xC0DE]

Wow ... a real one! They are almost impossible to find, where did you get that one Kelvin?

I couldn't believe my eyes when I saw it on the Dutch online marketplace 'Marktplaats' either

Which version of the ROM are you using, the original one or John Wike's latest version? It shouldn't make any difference, I'm just curious. Particularly in relation to the command *E2PON D, which is not one that I'm aware of. What does the "D" do?

The v2.4 software and the v3.1 ROM (loaded into SWRAM of the ElkSDPlus1). Not sure who wrote which one
The 'D' is supposed to enable DRAM refresh as I understand it.

I think that what you may be seeing here is an incompatibility with MMFS, as I have never loaded it via that method.

I was a bit lazy but will try from a real disc drive or Gotek in the near future.

I have not published my source code anywhere, but I'll upload it here - it is simply a BASIC program which assembles the host code file I.CODE. The P.CODE file is identical to the BBC version if I remember correctly. As I have posted before, it would be nice to make the host routines faster... do you fancy giving it a go?!

Thanks for uploading that. I'm so used to BeebAsm (and having no more than 1 instruction per line) that this inline asm in BBC BASIC is very slow to read and understand for me
But I can see the pixel plotting can definitely be sped up by using a table of screen addresses at the very least as mentioned by you.
It's definitely tempting to try, but no promises whatsoever And only a handful of people will be able to play it, though that never stopped me before...

[jms2]

I couldn't believe my eyes when I saw it on the Dutch online marketplace 'Marktplaats' either

Marktplaats does seem to be very good for finding old Acorn stuff...

The v2.4 software and the v3.1 ROM (loaded into SWRAM of the ElkSDPlus1). Not sure who wrote which one
The 'D' is supposed to enable DRAM refresh as I understand it.

Those are the original versions, both written by John Wike (ie, not tampered with by me). DRAM refresh will be necessary for a real E2P, as unlike my re-creation it uses DRAM rather than SRAM. This might mean you won't be able to use the more modern rom, because I disabled the DRAM refresh if I remember correctly. However I'm sure we can make a compatible version for you; one of the changes I introduced was a bugfix for (I think) *RUNning files - without it, the file would run but could never return to the command prompt. John Wike is once again custodian of the latest versions and he will know whether DRAM refresh is still supported.

[MarkMoxon]

I have not published my source code anywhere, but I'll upload it here - it is simply a BASIC program which assembles the host code file I.CODE. The P.CODE file is identical to the BBC version if I remember correctly. As I have posted before, it would be nice to make the host routines faster... do you fancy giving it a go?!

Thanks for uploading that. I'm so used to BeebAsm (and having no more than 1 instruction per line) that this inline asm in BBC BASIC is very slow to read and understand for me

I've documented the BBC Micro version of the I.CODE host code file, which might help make the inline Electron version easier to follow (see bbcelite.com or GitHub for details). I've also documented the Electron version of Elite, which might help when analysing the Electron-specific drawing routines in the I/O Processor host code.

And only a handful of people will be able to play it, though that never stopped me before...

You can run Electron Second Processor Elite on MAME, which is pretty cool... so this means anyone can play it, though of course running it on the real hardware would be even cooler. The BBC Micro versions of Elite don't work on MAME, as the 6845 emulation doesn't yet support the split-screen mode, but the Electron version of Elite uses standard mode 4, so it works fine on MAME and so does Second Processor Elite - see this earlier post for details.

So you have a bigger audience than just owners of Electron co-pros, and it would be great to see improvements in the draw speed!

Mark

[jms2]

... in relation to the command *E2PON D, which is not one that I'm aware of. What does the "D" do?

Embarrassingly, I now realise that the D parameter was in fact my own invention - I had just completely forgotten about it!
Version 3.1 of the rom is the last version that had my fingerprints on it, versions 4.x and 5.x being created by John Wike. Incidentally, the manual is contained within the rom, but you probably discovered that.

Looking back, I remember that I included the "D" function to cater for precisely this situation - ie that someone found a real E2P and wanted to run the latest bugfixed rom on it. At the time this seemed a very remote possibility, but I'm very pleased that it has come to pass!

[jms2]

Looking at John's v4.x and v5.x roms, I think they won't run on the original hardware. Certainly in the v5.x manual there is no longer a reference to the D parameter, and most of the new features won't work anyway. However I have attached a disc with this rom on it, in case you want to try.

Also on the disc is E2P Hi-Wordwise Plus, which was the raison d'etre of the E2P and the only piece of software to be written for it apart from my Tube Elite! The original E2P Hi-Wordwise Plus is lost, so this version was recreated from the BBC version by John Wike.

[0xC0DE]

@MarkMoxon @jms2 thanks for pointing me in the right direction. I know about the excellent disassembled versions of Elite of course.

@jms2: there was no file attached to your last post I think

@MarkMoxon: found a typo I think
https://www.bbcelite.com/deep_dives/dra ... rsion.html

Code: Select all

So the final calculation to find the character block containing (x, y) is:

     &5800 + ((y div 8) * 256) + ((y div 8) * 64) + 32 + (y AND %11111000)

Should be: x AND %11111000 (as you stated correctly in the text right above this part)

[jms2]

Whoops, sorry!

E2P v53 inc HIww.ssd

(32.5 KiB) Downloaded 58 times

[MarkMoxon]

@MarkMoxon: found a typo I think
https://www.bbcelite.com/deep_dives/dra ... rsion.html

Code: Select all

So the final calculation to find the character block containing (x, y) is:

     &5800 + ((y div 8) * 256) + ((y div 8) * 64) + 32 + (y AND %11111000)

Should be: x AND %11111000 (as you stated correctly in the text right above this part)

Whoops, you're absolutely right! Thanks for pointing it out, Kelvin - I've fixed it.

Mark

[0xC0DE]

Had to try a table based pixel plot, starting easy with the Elite loader
https://twitter.com/0xC0DE6502/status/1 ... 5598019586

[MarkMoxon]

Had to try a table based pixel plot, starting easy with the Elite loader
https://twitter.com/0xC0DE6502/status/1 ... 5598019586

That looks great! The Saturn looks so much better with more pixels - it's so crisp.

Interestingly, the Electron and BBC cassette versions have more pixels in their Saturns than the other BBC versions, as well as using different plotting logic, and I always prefered their much denser look. This version really cranks it up, though!

Is the table-based plotting noticeably faster?

Mark

[jms2]

Looks superb.

[0xC0DE]

and I always prefered their much denser look. This version really cranks it up, though!

I guess they didn't want the player to wait about 20 seconds on the loader screen

Is the table-based plotting noticeably faster?

It is faster but not as much as I had hoped. And I can't fully explain it yet. The new plot takes about 40 cycles per pixel, where the original one takes about 100 cycles per pixel.

Crude timing:

With the original amount of stars & planet pixels:
Org: 2.32s, New: 2.22s

With a large amount of stars & planet pixels:
Org: 19.60s, New: 18.86s

[MarkMoxon]

Is the table-based plotting noticeably faster?

It is faster but not as much as I had hoped. And I can't fully explain it yet.

I suspect the loader spends a lot more time working out where to plot the pixels, compared to actually plotting them, so the pixel-routine speed gains might not be that noticeable when surrounded by all those complex maths routines...

Mark

[jms2]

I think Mark is right - but don't be dissuaded... remember that during the game itself, the E2P does all that additional work, meaning that the full benefit of faster plotting should be obtained.

[0xC0DE]

@MarkMoxon @jms2 Exactly my (preliminary) thoughts. It's not the first time I wish I had a (hardware) 6502 profiler (or an emulator with full profiling capabilities)... And you're right: anything I can optimise on the host side should be worthwhile

[Budgie]

Is it possible to implement a flicker free version of Tube Elite for the Electron ? Sorry if this has already been discussed in the thread

[jms2]

Yes, it's certainly possible, and its something I vaguely intend to do.

Not only is the Elk version flickery, with a 320-pixel wide screen the calculations are a lot more difficult to do and so it is slow as well.

The thing about any second processor Elite is that the plotting code (which lives in the host processor) has loads of memory available to it. This is particularly true for Elk Elite, because it runs in Mode 4. This means that, in principle, you can take advantage of look up tables to increase plotting speed. So not only is a flicker-free algorithm possible, but also a general speed-up too.

The reason why I have not done either of those things is that the Elk Elite code is based on the original BASIC sources, hacked about by me to merge Electron plotting code into the Second Processor original. This was a difficult and painful process, which I did in stages, making sure that each stage worked OK before moving to the next. When I subsequently tried to optimise the line drawing, the plotting went haywire and nothing I did would fix it! So I left well alone.

Now we have Mark's excellent BeebAsm versions, it ought to be easier to try again. However I'm in no rush to start!

[Budgie]

Okay thanks. Just thought it would be a nice to have but no rush