Flicker-free Elite for all versions (inc. 6502SP and Elite-A)

[MarkMoxon]

Hi.

Not long ago, I backported the flicker-free ship-drawing routines from the BBC Master version of Elite to the cassette and disc versions, as well as to the Acorn Electron version.

I have now backported the same routines to the 6502 Second Processor version, as well as to both versions of Elite-A... so that's now every single Acorn-based Elite updated with flicker-free ship graphics. If you haven't seen it before, it's worth a look!

You can get your hands on both the original and updated games from bbcelite.com:

https://www.bbcelite.com/compare/releases.html

and you can read all about how I did the backporting in this new deep dive:

https://www.bbcelite.com/deep_dives/bac ... rithm.html

Here's a video showing the difference in Elite-A's Encyclopedia Galactica, where it's a pretty obvious improvement:

https://twitter.com/i/status/1427593384886259736

and here's another showing the 6502 Second Processor version's demo with no flicker:

https://twitter.com/i/status/1428022437841719300

Enjoy!

Mark

[TobyLobster]

[0xC0DE]

Mark, I admire your dedication and hard work. That also goes for your splendid website. What do you use to create your Elite website? (tools, templates, fonts, etc).

[MarkMoxon]

Mark, I admire your dedication and hard work. That also goes for your splendid website. What do you use to create your Elite website? (tools, templates, fonts, etc).

Thanks Kelvin!

The website is essentially all my own work. The only bit that isn't is the navigation menu script, which uses mmenujs/jQuery (and I plan to ditch jQuery soon, as it isn't required these days). Absolutely everything else is 100% my work. The font is the standard monospace font that comes with your browser, so there is no custom font on the site, and there isn't a CMS or anything behind the scenes, just static HTML pages with a tiny sprinkling of PHP. It's proper old school-stuff!

The HTML, CSS and JavaScript is all hand-rolled, as is the small bit of PHP that generates the header and footer. I intentionally avoided frameworks; I have to work with those in my professional life, and this project is supposed to be everything that my job isn't. That's probably why I enjoy it! No marketing scripts, no third-party dependencies, no slow dynamic scripting, no infinite scrolling, no frameworks, nothing between my code and the browser... what a relief.

As for the content, that's a bit more involved. Underlying this whole project is a central library that contains the annotated source code for all the different versions of Elite, all rolled into one. I can build each different version of Elite from this one, single project, and each routine has just one file in this project, even if it appears in multiple versions of Elite.

I've written a number of Python scripts to convert this central library into the public-facing repositories and websites.

One script generates the GitHub repositories from the central library. So https://github.com/markmoxon/cassette-elite-beebasm is auto-generated from this library, and so is https://github.com/markmoxon/electron-elite-beebasm - they all are, in fact. The Elite-A script, for example, inserts the "Mod:" headers during this process, because it can compare the Elite-A code to the disc code, as they all live within the same library files.

I've also written a Python script to generate the website from the central library. This script takes the .asm files from the library and from the generated GitHub repositories, and generates the various source code sections, source code pages, cross-references, indexes, statistics, comparison pages, and so on.

This all means that I can update the commentary or code in just one place in the library repository, click a button, and all the repositories that contain that bit of code get updated automatically, as well as all the relevant web pages, links, stats and so on. I realised early on that the only way to support so many versions would be through automation, and I was right!

The central library itself consists of one BeebAsm .asm file for each routine, with top-level source files full of INCLUDE statements that pull in the correct routines for the individual versions. Inside each routine file there is IF...ENDIF logic that controls which code is included for each version. All this is using BeebAsm syntax - the library is just one big BeebAsm project, which is why it can be built. The logic can get a bit hairy as I have to support a lot of versions, but even though there's a lot of logic, it is only ever IF...ELSE...ENDIF logic, which is pretty easy to manage.

I might make this library project public at some point, as it's an interesting meta-project in its own right. The Python is... well, it needs tidying first, shall we say. The website generator script is over 5500 lines long now, which is probably a sign that it needs refactoring, though as I just finished annotating the last version of Elite, I guess this is where it stops growing.

It's been a fascinating project, both in the public-facing code/site and behind the scenes. Just what I needed to kill time during lockdown.

Mark

[0xC0DE]

Thanks for your detailed explanation! This is exactly what I was hoping to read and I'm pretty sure I would have taken the same approach. I'm just not sure I have the patience to write so much documentation for any of my projects though

[tricky]

What 0xCODE said. It is a good looking website that works well

[AndyGarton]

Fantastic work on all of this, thanks! I've been trying to get Elite-A to run on my (PiTubeDirect) second processor equipped Master 128. All four versions (released/released flicker free/fixed/fixed flicker free) hang on the title screen for me, when loaded from a Gotek drive. My understanding is that Elite-A should detect the second processor and run appropriately (e.g. using the extra RAM to minimise loading from disk) - is that the case please? Has anybody got Elite-A to work with a second processor, PiTubeDirect or otherwise? I've tried both the accelerated and stock version of the Tube 6502, and both crash in the same way. Elite-A does of course load fine when the co-pro is disabled.

[MarkMoxon]

Fantastic work on all of this, thanks! I've been trying to get Elite-A to run on my (PiTubeDirect) second processor equipped Master 128. All four versions (released/released flicker free/fixed/fixed flicker free) hang on the title screen for me, when loaded from a Gotek drive. My understanding is that Elite-A should detect the second processor and run appropriately (e.g. using the extra RAM to minimise loading from disk) - is that the case please? Has anybody got Elite-A to work with a second processor, PiTubeDirect or otherwise? I've tried both the accelerated and stock version of the Tube 6502, and both crash in the same way. Elite-A does of course load fine when the co-pro is disabled.

I don't have a real Master, and using emulators, I've never managed to get the Master version of Elite-A running, with or without the co-pro enabled. I'm on a Mac, and I've tried both b2 and JSBeeb, but they both hang on loading when emulating a standard Master. This is true of the orignal released version, and is just as true with the flicker-free and bug-fix versions. So the fact that you can get it running on a standard Master with the co-pro disabled is an improvement on my experience, at least!

Here's Elite-A (the version from bbc.co.uk) failing to load on a standard BBC Master on bbcmicro.co.uk using JSBeeb:

http://bbcmicro.co.uk//jsbeeb/play.php? ... del=Master

and the same problem affects the co-pro Master:

http://bbcmicro.co.uk//jsbeeb/play.php? ... asterTurbo

I'm not sure if any other emulators can run Master Elite-A - I'll try to have a look at some point.

Not sure if this is any use at all when talking about your real-world co-pro issue, but at least it's related...

Mark

[AndyGarton]

Ok thanks - when you say “Master version of Elite-A”, do you refer to a specific Master version, or just the Beeb disk version running on a Master? If the former, could you point me to where it is (on your site I assume?) please? I’ve been using the standard Beeb version; to be honest I can’t remember if I put my co-pro-disabled Master into 1.2 MOS mode (via my RetroClinic multi-OS device), sounds like I probably did based on what you said about difficulties getting Elite-A to run at all on a Master.

[MarkMoxon]

Ok thanks - when you say “Master version of Elite-A”, do you refer to a specific Master version, or just the Beeb disk version running on a Master? If the former, could you point me to where it is (on your site I assume?) please? I’ve been using the standard Beeb version; to be honest I can’t remember if I put my Master into 1.2 MOS mode (via my RetroClinic multi-OS device), sounds like I probably did based on what you said about difficulties getting Elite-A to run at all on a Master.

There is only one version of Elite-A, but the loader checks the hardware that it's running on (in terms of BBC vs Master, and co-pro vs no co-pro). As I've not managed to get it running on an emulated Master, I'm not entirely sure what it is supposed to do on that platform compared to a Beeb, but I think that the loader checks whether this is a Master, and if so it loads code to make it work with the different filing system memory map, before continuing with the rest of the loading process; when loading on a Beeb, it simply skips the Master-specific code. The game binaries for the Beeb and Master are exactly the same, for both the standard and co-pro version, so I think the only difference is the extra bit of code that's loaded for the Master.

The relevant code is in here:

https://www.bbcelite.com/elite-a/loader ... _of_3.html

It'd be really interesting to know if it runs on a standard Master with the normal Master OS...

Mark

[AndyGarton]

I see, thanks.

Just tried it - it doesn’t run with MOS3.2 or 3.5, only in “Beeb mode”, with 1.2.

So it sounds like the “Tube mode” of Elite-A will only work on a Model B with co-pro, not Master. Unless there is some PiTubeDirect specific issue, which seems unlikely considering how mature and well developed it is now.

[MarkMoxon]

Just tried it - it doesn’t run with MOS3.2 or 3.5, only in “Beeb mode”, with 1.2.

Just to be clear - is this with or without the co-pro? i.e. does Elite-A run on a standard BBC Master with MOS 3.2/3.5, without a co-pro fitted?

Just trying to work out whether the emulators are correct in their behaviour, as they don't run Elite-A on a Master, whatever the co-pro status.

Mark

[AndyGarton]

That’s with or without the co-pro enabled. It only runs under 1.2 in other words.

[MarkMoxon]

That’s with or without the co-pro enabled. It only runs under 1.2 in other words.

Thanks for confirming - so the emulators are behaving correctly, and Elite-A doesn't work on the BBC Master at all. That's really interesting!

I might have to see if I can fix that at some point.

Mark

[jms2]

Impressive work Mark!

At some point I’d like to have a go at grafting the flicker-free Electron code onto my unofficial Elk Tube version. Last time I tried to optimise the plotting it proved to be a painful experience, so it will be good to have all the hard work done for me!

[MarkMoxon]

Impressive work Mark!

At some point I’d like to have a go at grafting the flicker-free Electron code onto my unofficial Elk Tube version. Last time I tried to optimise the plotting it proved to be a painful experience, so it will be good to have all the hard work done for me!

It doesn't speeed things up, unfortunately - it just changes the order in which lines are drawn and erased, but the difference is definitely noticeable. I think it's quite an improvement, particularly on the second processor version.

if you do want to roll the flicker-free changes into your version, here's a diff between the normal and flicker-free 6502SP versions:

https://github.com/markmoxon/6502sp-eli ... 9b3fa426ab

All the relevant changes are in the elite-source.asm file; click "Load diff" to see them all in one place. That might save some time...

Mark

[jms2]

Thanks Mark.

In terms of speed, my recollection is that the 6502SP version used look up tables for various things, whereas the Electron version didn't (due to lack of memory). So the optimum solution would be Electron-style (ie full width Mode 4) plotting but using tables. In theory this is possible but I couldn't make it work! Mind you this was using the original BASIC source which is not exactly readable.

Maybe I should try it in BeebAsm.

[MarkMoxon]

Thanks Mark.

In terms of speed, my recollection is that the 6502SP version used look up tables for various things, whereas the Electron version didn't (due to lack of memory). So the optimum solution would be Electron-style (ie full width Mode 4) plotting but using tables. In theory this is possible but I couldn't make it work!

I'm pretty sure all the lookup tables in the 6502SP version are in the parasite code, rather than in the host (which is where the drawing code lives).

The main difference is that the BBC versions have the custom screen mode that makes it quicker to convert from pixel coordinates to screen address (as each character row is exactly one page in the monochrome versions and two pages in the colour versions), while the Electron has to stick to normal mode 4. You could definitely replace this calculation with lookups in the Electron's host code, though, and that might speed things up.

Mind you this was using the original BASIC source which is not exactly readable.

Maybe I should try it in BeebAsm.

That would be a lot easier!

Mark

[ajcduggan]

I suspect It doesn’t run on a master because of the disk controller chip. I abused page d00, which is normally the NMI space for the DFS. In order to do that, I had to wait until the NMI routine was disabled after loading the overlays. ISTR there is a busy wait for the 8271 to indicate that the disk has stopped spinning. If you can find that and make it depend on the master, you can probably get it to work. I never had a master, so never wrote the code for that.

The tube code was written directly to the tube hardware spec. If there were any changes in addresses, control flags, or fifo capacities on the master, it probably won’t work.

[MarkMoxon]

I suspect It doesn’t run on a master because of the disk controller chip. I abused page d00, which is normally the NMI space for the DFS. In order to do that, I had to wait until the NMI routine was disabled after loading the overlays. ISTR there is a busy wait for the 8271 to indicate that the disk has stopped spinning. If you can find that and make it depend on the master, you can probably get it to work. I never had a master, so never wrote the code for that.

Interestingly, I can't find any code in Elite-A that does anything like this - waiting for the 8271, I mean.

As for page &D, the code for the IFF scanner lives at &0D7A in Elite-A:

https://www.bbcelite.com/elite-a/loader ... index.html

This replaces the CATD routine from the original disc version, which manually updates the disc catalogue at &0E00 when saving or loading:

https://www.bbcelite.com/disc/loader_3/ ... /catd.html

That's about it as far as abusing &0D00 goes, though; Elite-A's use of page &D is really similar to the original disc version, as far as I can make out, it's just a different routine at the same address.

But the original disc version does load on a Master (albeit with a corrupted font), so it should be possible to get Elite-A working. It'll be fun trying to track down the cause!

Mark

[Eleccy]

This is amazing, all these flicker free versions. Thanks so much.

I played Elite on the electron back in the day. My version was the original in which you could only access one galaxy. I didn't know a later version fixed that bug. Looking forward to trying flicker free version out on my original hardware. Maybe i should play long enough to see another galaxy

[MarkMoxon]

This is amazing, all these flicker free versions. Thanks so much.

My pleasure!

I played Elite on the electron back in the day. My version was the original in which you could only access one galaxy. I didn't know a later version fixed that bug. Looking forward to trying flicker free version out on my original hardware. Maybe i should play long enough to see another galaxy

I don't suppose you still have your original tape? I'm trying to track down a copy of the original Electron version with the galaxy bug, but haven't managed to find it yet.

And if anyone else out there has a copy of the original bugged Electron version, do let me know!

Mark

[KenLowe]

What would it take to make Elite Econet compatible? I'm guessing it's not already.

[jms2]

And if anyone else out there has a copy of the original bugged Electron version, do let me know!

I certainly had it, and still have the box. However I doubt the tape is still in it.

[MarkMoxon]

What would it take to make Elite Econet compatible? I'm guessing it's not already.

I guess it's the usual problem - Elite takes up practically every free byte on a standard unexpanded BBC Micro, so there's nothing left over for systems that need more memory, such as DFS or Econet. The disc version of Elite got around this by breaking the code into two, but even then those two programs use up pretty much everything that’s available.

I can't remember what Econet pushes PAGE up to, but assuming it isn't a more than &1100, then in theory the disc version could be tweaked to load from Econet (I suspect Elite uses Econet's variable locations for itself, but those wouldn't be hard to move if there were room). If Econet is hungrier then that, then things could be tricky...

Might be a fun little project!

Mark

[MarkMoxon]

And if anyone else out there has a copy of the original bugged Electron version, do let me know!

I certainly had it, and still have the box. However I doubt the tape is still in it.

The search goes on! Mind you, I haven’t yet decrypted the version from Ian Bell’s site, so that might have the bug in it. So many variants, so little time!

Mark

[KenLowe]

What would it take to make Elite Econet compatible? I'm guessing it's not already.

I guess it's the usual problem - Elite takes up practically every free byte on a standard unexpanded BBC Micro, so there's nothing left over for systems that need more memory, such as DFS or Econet. The disc version of Elite got around this by breaking the code into two, but even then those two programs use up pretty much everything that’s available.

I can't remember what Econet pushes PAGE up to, but assuming it isn't a more than &1100, then in theory the disc version could be tweaked to load from Econet (I suspect Elite uses Econet's variable locations for itself, but those wouldn't be hard to move if there were room). If Econet is hungrier then that, then things could be tricky...

Might be a fun little project!

Mark

On their own, NFS 3.34, 3.60 & 3.62 push PAGE up to &1200 & ANFS pushes it up to &1900, but I don't know if any of that space can be used in the same way that the space between &1100 and &1900 can be used in DFS. Even getting Elite to work via Econet on a second processor would be cool.

[MarkMoxon]

On it's own, Econet 3.60 /3.62 pushes PAGE up to &1200 & ANFS pushes it up to &1900, but I don't know if any of that space can be used in the same way that the space between &1100 and &1900 can be used in DFS. Even getting Elite to work via Econet on a second processor would be cool.

I would think that Econet 6502sp Elite would be pretty feasible. Looking at the Elite memory map:

https://www.bbcelite.com/deep_dives/the ... 502sp.html

it looks as if pushing PAGE up to &2300 would be possible on the I/O Processor without causing too much trouble.

Intriguing!

Mark

[KenLowe]

I was having a quick look at this earlier this evening with a view to building a version that will run from Econet, and was getting myself a bit confused because the the disk directory structure that gets built from the source files didn't seem to match what was on my Elite disk image. I then realised that the disk image that I'm using is an 'All in one' version:

viewtopic.php?f=1&t=18878&p=262305

Have you considered creating a build script for this disk version? Or have you done this already, and I've just missed it?

[MarkMoxon]

Have you considered creating a build script for this disk version? Or have you done this already, and I've just missed it?

I did think about it at one point, but I felt that creating another repository containing all the source files from all the constituent versions (disc, 6502sp, Master) would be a bit of a pain to manage and keep up to date, and concluded that one repository per distinct version would be clearer and easier to navigate.

The multi-version discs contain the exact same binaries as the individual version discs, just with a menu or auto-detection program bolted on, so they don't really bring anything new to the party, technology-wise. So I didn't go for it in the end, and instead stuck to providing individual version repos that generate all the different variants of those versions. Of which there are a lot!

But if people would like a multi-format repository, then it’s certainly possible to do and probably wouldn’t be too hard to create…

Mark