Teletext Elite (BBC Micro, BBC Master)

[mike12f]

Great work, this is amazing. The lower resolution doesn't seem to detract from the game at all, and possibly looks nicer overall? The docked text screens look much better in colour Teletext.

I wonder why more BBC Micro games weren't written in Mode 7 to gain the extra free memory (assuming memory was always such an issue limiting games).

[ash73]

Just amazing, bravo!

The trading/status screens look a lot better than the original, too.

[BeebMaster]

I must have a go, it looks really amazing!

What's next - Chuckie Egg? Frak!?

[mike12f]

Actually, there's no throttling at all - it's still running at full pelt. The underlying mathematical model is identical, and that's where most of the CPU time is spent, so swapping pixel routines for sixel routines doesn't speed things up as much as you'd think. Even the time savings from ditching the screen mode interrupt routine aren't that obvious, though it might feel a little faster? It's hard to tell.

The suns are the exception, as they are raster-based, so they use a quarter of the CPU effort compared to the normal version. Flying near to the sun still slows things down, but not as much as in the original.

Mark

Would it be possible to speed up the planet drawing routines (i.e. the circle plotter/equator plotter) if instead of transforming the coordinate system by dividing everything by 4 at the pixel plotting level, instead you divide the "radius" of the circle by 4 before it enters the circle-drawing routine. Would that reduce the number of sin and cosine calculations needed? I'm looking at this routine which has some if statements, e.g. "if radius<8" and "if radius<60"? If we do the divide by 4 before entering this routine, will those if statements kick in, and potentially save a lot of time? Or does it make no difference? I'm confused as to the logic - do smaller circles need a smaller angle step size than larger circles, (in order to make them look like "smooth" circles?), or is it the other way around? (((Edit: There might be a quick hack to do this: Perhaps just change the "if radius<8" to "if radius<8*4", and then multiply the angle step by 4? Then there's no need to edit the pixel plotting routine to remove the divide by 4 specially for the circle drawing routine)))

Also, would it be possible to speed up spaceship drawing by reducing the "visibility distances" variables for some ships/vertices as described in the deep dive on ship drawing? Now that we have lower resolution (Mode 7), surely fewer polygons are visible now?

I'm not asking you to make these changes; just discussing the mathematics / optimisation of it in theory! However if we just need to multiply or divide a few constants by 4 then maybe this is feasible to do?

[MarkMoxon]

Would it be possible to speed up the planet drawing routines (i.e. the circle plotter/equator plotter) if instead of transforming the coordinate system by dividing everything by 4 at the pixel plotting level, instead you divide the "radius" of the circle by 4 before it enters the circle-drawing routine. Would that reduce the number of sin and cosine calculations needed?

Yes, that would indeed reduce the number of calculations (for circles of radius < 240), and that would speed things up.

The key aspect is the step size (in variable STP), as you spotted:

I'm confused as to the logic - do smaller circles need a smaller angle step size than larger circles, (in order to make them look like "smooth" circles?), or is it the other way around?

The first one is right - a smaller step size gives a smoother circle, as the circle is divided into more steps, with each step being a single straight line.

This is all explained in this deep dive:

https://www.bbcelite.com/deep_dives/dra ... rcles.html

To quote the above:

"[The] routine draws a circle by starting at the bottom of the circle - or at 6 o'clock if you think of it as a clock face - and moving anti-clockwise in steps defined by the size of the step size in STP. The whole circle is divided into 64 steps and the step number is stored in CNT, so if STP were 2, CNT would be 0, 2, 4 and so on up to and including 64."

Given this, we can see that for bigger circles we end up drawing more lines. A step size of 2 gives 32 lines (64 divided by 2), while a step size of 8 gives 8 lines (64 divided by 8 ).

Each line requires the same kind of trigonometric calculation, so the way to speed up circle drawing is to reduce the number of lines that make up each circle. The number of lines in a circle is defined by the step size, so we need to increase the step size for each circle.

There are two ways I can see of doing this, along with your radius-scaling suggestion.

The easiest way is to simply double or quadruple the step size. This would best be best done in CIRCLE, as the launch and docking tunnels use the same algorithm and call CIRCLE2 directly, and we probably don't want to alter them.

The other way is to halve or quarter the radius thresholds in CIRCLE. This is very similar to your suggestion, just with the thresholds scaled rather than scaling the radius value passed to the routine.

All three options reduce the number of lines in each circle, so they would all make things faster. But does this affect circle quality? That's a good question, and I don't know - trying it out would be the next logical step. My gut feeling says that the circles would suffer and the straighter sides would be visible, but that might just be because I'm impressed by how much fidelity the mode 7 graphics have for such a low resolution...

Also, would it be possible to speed up spaceship drawing by reducing the "visibility distances" variables for some ships/vertices as described in the deep dive on ship drawing? Now that we have lower resolution (Mode 7), surely fewer polygons are visible now?

I agree, that would make sense; I would think that changing vertex visibility would be a good optimisation here. I'd probably leave the ship distances alone as the point at which the distant dot changes to a wireframe is part of the gameplay DNA of the original, but changing individual vertex distances wouldn't change this. Good suggestion!

Mark

[Diminished]

Mark,

I'm wondering if you've ever thought about looking at the NES version of Elite.

The reason I'm asking is because (AFAIK) the NES doesn't have anything like a bitmapped framebuffer -- instead, the display has to be built up by referencing a finite set of pre-defined tiles (perfect for 2D platformers -- less so for full 3D). Ian Bell remarked that the NES version of the game was actually his favourite, because of the shenanigans they'd had to negotiate in order to get the game to work on non-bitmapped hardware.

It strikes me that there might be some commonality between what B&B needed to do on the NES, and what you've needed to do here.

[scarybeasts]

Hi Stardot.

I'm delighted to announce my latest release: Teletext Elite on the BBC Micro.

This is totally spectacular

Hopefully not raining on the parade, but I believe I have a bug to report. It leads to hangs and crashes when accessing the disc in the game, e.g. to go from docked to flight.
Here:
LDA &76 \ Set the drive number in the CATD routine to the
STA CATBLOCK \ contents of &76, which gets set in ELITE3

But earlier in the load process....
\ Summary: This code accesses the disc directly (not used in this version as
\ disc protection is disabled)
...
STX &76 \ Store the drive number in &76 for retrieval in ELITE4


In fact, a bunch of other routines in the docked mode are writing to &76, such as (I think) TT134 and others.

The effect of all of this is that a "wild" byte is passed as the first byte of an OSWORD &7F parameter block, with the knock-on result that sometimes the loader attempts to load from drive 1, or the upper side of the disc (aka. drive 2). Crashes follow.


Let me know if I can help further, or if I've misread anything!


Cheers
Chris

[VectorEyes]

I just wanted to say that this whole Teletext Elite thing is a stunning achievement. Thanks Mark Moxon for all the time and effort that you must have put into it!

[MarkMoxon]

Thank you for the kind words, everyone. I'm glad you like it!

I'm wondering if you've ever thought about looking at the NES version of Elite.

The reason I'm asking is because (AFAIK) the NES doesn't have anything like a bitmapped framebuffer -- instead, the display has to be built up by referencing a finite set of pre-defined tiles (perfect for 2D platformers -- less so for full 3D). Ian Bell remarked that the NES version of the game was actually his favourite, because of the shenanigans they'd had to negotiate in order to get the game to work on non-bitmapped hardware.

It strikes me that there might be some commonality between what B&B needed to do on the NES, and what you've needed to do here.

Oooh, that's an interesting one! I'm going to have to take a look now... the correlation between sixels and pre-defined tiles is intriguing.

Another one for the list - thank you for the suggestion!

This is totally spectacular

Hopefully not raining on the parade, but I believe I have a bug to report. It leads to hangs and crashes when accessing the disc in the game, e.g. to go from docked to flight.

Thank you Chris, that is so helpful! I'm pretty sure I know what I've done wrong there - I've had a few reports of this exact issue but couldn't replicate it, and now you've done the heavy lifting for me. Brilliant!

I'm away from my computer at the moment, but should be able to look into fixing this at the weekend. Thanks so much for letting me know.

Also, a big thanks to mike12f for his investigations into the circle-drawing routine (see above). He's now sent me a super-simple tweak which I've rolled into the latest version, and which speeds up circle plotting without affecting circle quality - nice! Here's the commit:

https://github.com/markmoxon/teletext-e ... ce17440d16

You can download the latest version from the links in the first post in this thread.

If anyone spots anything else, do let me know - I'm always keen to fix bugs!

Mark

[ash73]

All we need now is the author of BeebEm to kindly give us a 80x50chr 4KB teletext mode for Christmas so we can play this in hi-res

[scarybeasts]

I'm away from my computer at the moment, but should be able to look into fixing this at the weekend. Thanks so much for letting me know.

FWIW, NOP'ing out the STA that writes to the OSWORD parameter block fixes the issue. I've been trying this by using beebjit's debugger to apply a runtime patch:

./beebjit -0 ~/Downloads/teletext-elite.ssd -mode interp -debug -commands "b 1a92 expr 'mem[0x1a92]==0xa5 && mem[0x1a93]==0x76' commands 'writem 1a94 ea ea ea;c';c"

I think the reason this STA exists is that in the original Elite retail disc, there was a really unusual setup where the disc is actually double sided. If the drive is 40T, it loads from the lower surface but if the drive is 80T, it loads (the same code) from the upper surface.
Your Teletext Elite ships in an ssd, so there is no upper surface to cater for. The only thing that might break is if the game supports being run from a second drive (drive 1). I don't think it does -- I just tried the HFE of the original retail disc.


Cheers
Chris

[tricky]

All we need now is the author of BeebEm to kindly give us a 80x50chr 4KB teletext mode for Christmas so we can play this in hi-res

There is no 4k Teletext mode on the beeb, the B and B+ have 2k and the master/compact have 1k+1k in shadow memory.
I think that the nearest you could have would be 4k mode 5 with double length scan lines.

[MarkMoxon]

I'm away from my computer at the moment, but should be able to look into fixing this at the weekend. Thanks so much for letting me know.

FWIW, NOP'ing out the STA that writes to the OSWORD parameter block fixes the issue. I've been trying this by using beebjit's debugger to apply a runtime patch:

./beebjit -0 ~/Downloads/teletext-elite.ssd -mode interp -debug -commands "b 1a92 expr 'mem[0x1a92]==0xa5 && mem[0x1a93]==0x76' commands 'writem 1a94 ea ea ea;c';c"

I think the reason this STA exists is that in the original Elite retail disc, there was a really unusual setup where the disc is actually double sided. If the drive is 40T, it loads from the lower surface but if the drive is 80T, it loads (the same code) from the upper surface.
Your Teletext Elite ships in an ssd, so there is no upper surface to cater for. The only thing that might break is if the game supports being run from a second drive (drive 1). I don't think it does -- I just tried the HFE of the original retail disc.

Thanks for the detective work, Chris! Following your clues, I have (hopefully) fixed the bug in the latest version, which is downloadable from the usual URL:

https://www.bbcelite.com/versions/telet ... -elite.ssd

NOPing out the STA would indeed work, but instead, I think I've worked out why this part of the code was breaking in Teletext Elite, while the identical code seems to work fine in the original disc version from bbcmicro.co.uk.

The Teletext Version contains various new routines in the loader, for printing the titles and drawing the Saturn in sixels. For these routines, I used the SC variable in zero page for the screen addresses to poke into, as that variable is defined in the loader source code, and is the variable that is typically used for screen addresses throughout the game.

However, what I didn't realise was that the original version's loader doesn't actually use the SC variable at all; the label is there, but instead the variable ZP is used for the Saturn's screen addresses, so the Saturn part of the loader doesn't change the value of SC at all. The SC variable is at - you guessed it - location &76, so my code was changing the value of location &76 in a way that the original version wasn't, and as &76 was then being poked into CATBLOCK as the drive number, things were going wrong.

I've therefore fixed the bug by avoiding use of SC in the loader, and instead using the ZP variable. This means that in Teletext Elite, CATBLOCK (at address &0D92) now gets set to the same value as in the original disc version from bbcmicro.co.uk.

(Interestingly, this value is &95 rather than 0, but if this works for the version on bbcmicro.co.uk, then I'm happy to keep Teletext Elite the same, though I don't know why this value doesn't crash... unless it does, of course, in which case the version of Elite on bbcmicro.co.uk will suffer from this bug too. Hmm, a mystery!)

Anyway, the updated version of Teletext Elite sems to work well for me, but then again, I was having problems getting it to crash before, so if you or anyone else gets a chance to try it out, do let me know how it goes! Fingers crossed it's fixed...

Thanks again for the analysis, without which this would have been much more of a pain to fix. I owe you one there!

Mark

[scarybeasts]

(Interestingly, this value is &95 rather than 0, but if this works for the version on bbcmicro.co.uk, then I'm happy to keep Teletext Elite the same, though I don't know why this value doesn't crash... unless it does, of course, in which case the version of Elite on bbcmicro.co.uk will suffer from this bug too. Hmm, a mystery!)

Yeah, that's a weird value for sure. It's stable in beebjit, where I was able to get the previous version to crash easily.

It probably works because the docs say:
https://beebwiki.mdfs.net/OSWORD_%267F
"The drive number specifies the drive to access. If bit 7 is set, then the previously-used drive is used, and the drive status check is skipped."
And bit 7 is set in the value &95.


Cheers
Chris

[MarkMoxon]

(Interestingly, this value is &95 rather than 0, but if this works for the version on bbcmicro.co.uk, then I'm happy to keep Teletext Elite the same, though I don't know why this value doesn't crash... unless it does, of course, in which case the version of Elite on bbcmicro.co.uk will suffer from this bug too. Hmm, a mystery!)

Yeah, that's a weird value for sure. It's stable in beebjit, where I was able to get the previous version to crash easily.

It probably works because the docs say:
https://beebwiki.mdfs.net/OSWORD_%267F
"The drive number specifies the drive to access. If bit 7 is set, then the previously-used drive is used, and the drive status check is skipped."
And bit 7 is set in the value &95.

Ah, that makes sense! Perhaps this is why the version from bbcmicro.co.uk seems to work fine in drive 1 as well as drive 0, as the OSWORD command will just inherit the drive number used to load the game, rather than being forced to drive 0. The commander file routines don’t use OSWORD (it’s only used for sound and keyboard outside of the CATD routine), otherwise presumably saving a commander to a different drive would point the CATBLOCK at the wrong drive for loading the game code. Or something like that!

Anyway, thank you for testing it out. Stable sounds like a pretty good result to me.

Mark

[Grasshopper]

All we need now is the author of BeebEm to kindly give us a 80x50chr 4KB teletext mode for Christmas so we can play this in hi-res

There is no 4k Teletext mode on the beeb, the B and B+ have 2k and the master/compact have 1k+1k in shadow memory.
I think that the nearest you could have would be 4k mode 5 with double length scan lines.

Interesting. I thought the BBC B's teletext mode only used 1k, unless my memory is playing tricks with me.

[RobC]

Interesting. I thought the BBC B's teletext mode only used 1k, unless my memory is playing tricks with me.

You are correct - the standard mode 7 is 40x25 chars and uses 1K. However, you can also have a second 1K buffer at 0x3C00 on the B and B+ which allows for a total of 2K (so 40x50 or 80x25 if the hardware could deliver it). I think this is what tricky meant.

[tricky]

Yes, it allows double buffering or an extended screen with hardware scrolling.

[BeebMaster]

Tried it now, looking great!

I really don't know how to play Elite, so after 5 minutes of me not really doing anything except pressing F-keys, it exploded and that was that!

I thought it would be nice to get some photographs of it running on Station 129 with Cub monitor, but I just couldn't get any decent pictures without glare or blurring or reflections of the striplights in here, I will have another go in the daylight tomorrow (if we get any (actually grey misty drizzly overcast gloom which we've had every day since 1784 would probably be better!))

Unfortunately it didn't actually work on Station 129 (BBC B with DNFS), it just got to the Load new commander prompt and crashed with a few red characters appearing on the screen. Possibly it (and the original as well no doubt) isn't compatible with Econet.

[MarkMoxon]

Tried it now, looking great!

Great! Glad it’s working.

Unfortunately it didn't actually work on Station 129 (BBC B with DNFS), it just got to the Load new commander prompt and crashed with a few red characters appearing on the screen. Possibly it (and the original as well no doubt) isn't compatible with Econet.

The game uses all the Econet workspace for storage, so it definitely won't run if Econet is active (both in the original version and Teletext). Is there a way of disabling just the Econet part in DNFS? I tend to *KILL the DNFS ROM on my machine to run Elite, but I have a 1770 interface with its own separate DFS ROM, so that makes it easy for me to disable Econet while leaving the disc interface working.

If you can get PAGE down to &1900, then it should run (I think). It looks great on my Trinitron CRT monitor, but I bet it looks even more authentic on a proper Cub!

Mark

[gfoot]

Great work, my first thought was to wonder if you could get it to run on a Model A! It sounds like it's still 10K short of that though.

[BeebMaster]

On the Econet front, games using the Econet workspace should still work as long as there is no network activity to overwrite the workspace. With that in mind, I tried on Station 129 again with no clock, and it works. And as soon as I turn the clock on and switch on a Master 128 station, which does a BRIDGE broadcast to the network, things start to go wrong.

Incidentally, the original machine I tried it on is Station 201, Master 128 (actually Master 512 but with co-pro disabled of course) with genuine MOS 3.50 ROM, in case it's helpful to know that it works with that MOS version.

[MarkMoxon]

Great work, my first thought was to wonder if you could get it to run on a Model A! It sounds like it's still 10K short of that though.

Yes, I did wonder about trying to squeeze it into a Model A, as switching from the custom split-screen mode to mode 7 gains 6.75K, but that’s still a long way off the 16K we’d need to save. Dropping suns and Thargoids, as in the Electron version, would save another 2304 bytes in the flight code, but we would still need around 7K of cuts, which would be pretty brutal.

Also, Teletext Elite is based on the disc version of Elite - does the Model A support the disc upgrade without itself being upgraded to Model B specs? I suppose you could leave the RAM at 16K, but that would leave hardly anything left over once DFS has claimed its chunk...

Mark

[MarkMoxon]

On the Econet front, games using the Econet workspace should still work as long as there is no network activity to overwrite the workspace. With that in mind, I tried on Station 129 again with no clock, and it works. And as soon as I turn the clock on and switch on a Master 128 station, which does a BRIDGE broadcast to the network, things start to go wrong.

That's good to know! I just tried it on mine with DNFS still enabled but with the clock switched off, and it loads fine for me too. Thanks for the explanation - it makes sense that Econet workspace is only used when the network is working.

Incidentally, the original machine I tried it on is Station 201, Master 128 (actually Master 512 but with co-pro disabled of course) with genuine MOS 3.50 ROM, in case it's helpful to know that it works with that MOS version.

That's really useful - I tried it on 3.50 in the emulators, but nothing beats a real-world test. Thanks for confirming!

Mark

[MarkMoxon]

On the subject of real hardware tests, if anyone with a Master fancies testing my conversion of the original BBC Micro Elite to the BBC Master, I would be really interested to know if it works on the real thing. I haven’t had any feedback from anyone trying it out yet, and given that Master owners are the target audience, it’d be good to know if it actually works! This is a spin-off of the work I did on Teletext Elite, so it’s really encouraging to know the latter works on a real Master.

See the thread here for details:

viewtopic.php?f=1&t=26018

Mark

[KenLowe]

The game uses all the Econet workspace for storage, so it definitely won't run if Econet is active (both in the original version and Teletext). Is there a way of disabling just the Econet part in DNFS? I tend to *KILL the DNFS ROM on my machine to run Elite, but I have a 1770 interface with its own separate DFS ROM, so that makes it easy for me to disable Econet while leaving the disc interface working.

viewtopic.php?f=3&t=20730

[scarybeasts]

It probably works because the docs say:
https://beebwiki.mdfs.net/OSWORD_%267F
"The drive number specifies the drive to access. If bit 7 is set, then the previously-used drive is used, and the drive status check is skipped."
And bit 7 is set in the value &95.

Ah, that makes sense! Perhaps this is why the version from bbcmicro.co.uk seems to work fine in drive 1 as well as drive 0, as the OSWORD command will just inherit the drive number used to load the game, rather than being forced to drive 0.

To recap... it works, so maybe leave it alone

But to be thorough, I checked the protected retail Elite disc (first release).

In an 80T drive, the game loads from the upper surface and the value $02 gets written to $0D92.
In a 40T drive, the game loads from the lower surface and the value $00 gets written to $0D92.

So I'd consider the value $95 to be "wild", but it's lucky enough to work!


Cheers
Chris

[MarkMoxon]

It probably works because the docs say:
https://beebwiki.mdfs.net/OSWORD_%267F
"The drive number specifies the drive to access. If bit 7 is set, then the previously-used drive is used, and the drive status check is skipped."
And bit 7 is set in the value &95.

Ah, that makes sense! Perhaps this is why the version from bbcmicro.co.uk seems to work fine in drive 1 as well as drive 0, as the OSWORD command will just inherit the drive number used to load the game, rather than being forced to drive 0.

To recap... it works, so maybe leave it alone

But to be thorough, I checked the protected retail Elite disc (first release).

In an 80T drive, the game loads from the upper surface and the value $02 gets written to $0D92.
In a 40T drive, the game loads from the lower surface and the value $00 gets written to $0D92.

So I'd consider the value $95 to be "wild", but it's lucky enough to work!

Just to complete the picture, I've found out why it's &95. The second part of the loader (ELITE3 in the unprotected version) draws the mode 7 four-logo "Acornsoft" loading screen. In this, location &76 is used to store the colour of the current logo, so it starts with teletext control code 145 (for red graphics) and increments through 146 (green), 147 (yellow) and 148 (blue) with each logo. It's post-incremented, so it ends up at 149, the code for magenta graphics. In hex, this is &95.

After the Acornsoft logos are drawn, the protected version overwrites location &76 with 0 or 2, depending on the track count, but in the unprotected version this routine is skipped, so location &76 stays at &95. The value of location &76 is copied to &0D92 in both versions, so this why the drive number the OSWORD block is correct in the protected version, but this weird number in the unprotected version. It's actually setting the drive number to the control code for mode 7 magenta graphics... and it still works!

I'm definitely leaving it alone.

Mark

[BeebMaster]

I took some pictures of the Cub. The daylight, such as we had today, wasn't any good either, so in the end I did it in complete darkness with only the camera flash for light. Came out all right I think:

[BeebMaster]

Here's the behind-the-scenes picture which perhaps explains the trouble I've been having!