Frontier Elite II - BBC and Pi Native ARM CoPro

[dudleysoft71]

As some of you may have seen in the ideas forum I've been working on a port of Frontier Elite II for the BBC Micro.

It requires the PiTubeDirect Co-processor in Native ARM mode, although it should theoretically work with the ARM7TDMI core, also due to the size of the main program it requires a hard drive of some form since the main executable is 2Mbytes (and this is the optimised version, the unoptimised version is 5Mbytes). It also loads a 500Kbyte data file as well.

I originally started it for VideoNULA only, however the game features a dynamic palette, and uses more than 16 colours, so in writing code to reduce and remap the colours I realised I could easily add support for the standard Beeb mode 2 palette, so now it supports both modes.

Up until today the game had no input so you could only watch the attract mode, but with the addition of input it's possible to start the game. However a crash in the comms screen means you cannot gain permission to launch, so far I haven't gotten off the starting planet, but have been destroyed a few times.

Some screenshots:

I posted a couple of videos on YouTube of earlier builds:
Standard Beeb attract mode

VideoNULA attract mode

And I uploaded a hard drive image for anyone with an appropriate machine to try out: https://www.dropbox.com/s/3ujj6usxpce8q ... b.zip?dl=0

[trixster]

Simply brIlliant :O

[Yrrah2]

Can’t wait..........

[marcusjambler]

hard drive image for anyone with an appropriate machine to try out

I'm currently in 'get that stuff out of the house'... decorating mode
But I should be able to sneak a run through on real hardware over the weekend

[drfloyd]

It should be incredible to run ELITE 2 on BBC master (even it is with a modern co pro)

so, which configuration will i need to run it ?

MASTER 128
Rasp Pi coPro ? Which one ?
a Gotek for transfert ?

[dudleysoft71]

Any Pi co-processor will do since it uses the native arm core, even a Pi 1 would be fast enough, although the PiZero is probably the cheapest option.
As for Gotek, I don't know what the maximum size disk it supports under ADFS, I believe it's only 800K, it may be possible to zip the files into 800K sections and re-assemble on the CF drive, I don't know how well ZIP works on a BBC, although you could use the ARM core to do it for you, I've never tried.

Although I noticed today while trying to track down the comms screen issue that it's building the ST emulation layer with debug data enabled, this is basically adding lots of line_no assignments everywhere for debugging the emulator, so if it crashes you know which line of the assembler source file is causing the problem (might be useful for me now I've re-enabled bounds checking). I first thought it was an error in one of the calls implemented in C, but I've removed all the obvious ones and it still hangs

I should be able to remove the debugging information which should make the executable alot smaller (and probably speed up compiling since it's not generatings thousands of line number references)

[trixster]

Is the mouse controllable using cursor keys or will a mouse be required?

[dudleysoft71]

I've made a new HDD image of the game, this version has shrunk the main game executable to a mere 1.6MBytes, all by removing the debug line_no definitions from the recompiled 68000 source, who knew there were 400KBytes of assignments in one file.

This version has working input, the mouse cursor can be controlled via the cursor keys and you use COPY for the left mouse button and DELETE from the right. I think it will likely crash if you try to start the game from a previous position (it's hard coded to load a DEBUG commander which doesn't exist), and I haven't tested loading a game (or saving).

Since I haven't had much chance to actually play beyond getting it working, so it's likely that there are more issues with it.


Here's the zip file:

FE2Beeb.zip

(824.72 KiB) Downloaded 29 times

Stick the files on a suitable SD card or copy the contents to a folder on another image or CF card.
Select the Native ARM Co-processor (*FX151,230,15)
And run either *FE2 for the VideoNULA version, or *FE2ULA for the standard beeb ULA version.

For the manual (you'll need it to get started) you can go here: https://www.oldgames.sk/en/game/frontie ... load/9152/ (it's 5MBytes so it's a bit big to post as an attachment here)

[dudleysoft71]

Is the mouse controllable using cursor keys or will a mouse be required?

The mouse is controlled with the cursor keys, I want to add joystick support too, but I don't have one to test, and I have a Turbo MMC in the user port so I can't use a mouse at the moment (and don't have one).
The left/right buttons are COPY and DELETE respectively.

[trixster]

I’ll try the new image this evening!

[dudleysoft71]

Okay, let me know if you find any keys that aren't working. I think < isn't working and F8, from my brief testing, but there may be more. The full list of key codes was cobbled together and then they had to come mapped to the Atari ST keycodes so there's two chances to get it wrong.

[trixster]

[dudleysoft71]

So you managed to get into space without getting blown to smithereens.

I couldn't do that before, pressed space by mistake, fired laser. Got a fine, police turn up and blow me up. Pressed F7 and launched without getting permission. Blown up again. Didn't help the game locked up in the comms menu.

[trixster]

I found in the comms menu if you press one you get clearance to depart even if the cursor doesn’t respond

I managed to hyperspace to barnard’s star but could work out how to select the station orbiting Birmingham world to set the autopilot. Then I pressed too many keys and it seemed to lock up!

Remarkable work so far though

[Yrrah2]

Got it all runnng to!
And I even found my old Frontier manual on my bookshelf!

I remember it was hard, and it is stil hard.
A lot of the keys seem to work. But somehow I cannot use the galactic map icon keys.
I can press F2 and zoom in pressing F7, but no zoom out and the other keys.

And the mouse is indeed not working. But could be because of the ARM copro? The mouse works when using the normal beeb mode.
As trixter said, the mouse freezes when you enter the communications screen (F4)
When you move the mouse with the cursor keys and press F4 again you get visually updated position of the mouse pointer.

Nice Job!!!

[dudleysoft71]

Yeah, I knew that F8 wasn't working.

I think the reason the mouse doesn't move on the comms screen is because it only updates the screen when something changes and it doesn't count the mouse as a change, the SDL version uses the PC mouse cursor so it doesn't matter, and the ST version just updates the visible screen rather than the back buffer.

I'll see if there's a way to resolve that. I think I can just make both frame buffers the same since it doesn't make sense to use double buffering on the emulated sides when it has to be converted and transferred before it displays anyway.

[trixster]

Zoom out on the galactic map is one of the normal number keys, not an F key

[dudleysoft71]

I thought the manual said zoom out was F8.

I'm toying with the idea of moving all the function keys down one, so F1 becomes F0 and so on, so they match the BBC function key layout instead of the ST and PC keyboard. Though that might confuse anyone reading the manual.

[dudleysoft71]

The mouse isn't working because it's not setup to read the mouse.

I'm not sure the best way to go about that, and since I don't have a mouse to test with it's a bit of a problem implementing it.

[Yrrah2]

Zoom out on the galactic map is one of the normal number keys, not an F key

Hmmm, the 8 key does not work for me to zoom out.

I thought the manual said zoom out was F8.

Indeed the F8 should be zoom out.

I'm toying with the idea of moving all the function keys down one, so F1 becomes F0 and so on, so they match the BBC function key layout instead of the ST and PC keyboard. Though that might confuse anyone reading the manual.

That's a good idea.
When I have selected the Galactic Map (F2) the Economy, Social Structure and orbital map function keys do not work (F7, F8, F10)
When I press F4 in this schreen I get the 'Data icon'. But then again the F7,F8 and F10 do not work.

[RobC]

I'm not sure the best way to go about that, and since I don't have a mouse to test with it's a bit of a problem implementing it.

If you want to borrow one, PM me.

[tricky]

Great work.
Is is possible to put the data on the emulator side, so that only the beeb side SW is on the beeb disc?

[dudleysoft71]

I imagine that it'll be a pain to do. The file loading is normally done via SWI calls which are routed to the Beeb via the tube. This is done by implementing them as the low level C functions for file operations, to load from the SD card it would need to implement another file system into the low level FS function.

It may be possible to implement some kind of hostfs, I imagine it would be fairly simple to modify the swi handlers for file access to be able to read files from the SD card.

[tricky]

How about just building the data into the emulator?

[dudleysoft71]

The emulator is still just a file that is loaded into memory via the host's filesystem, the arm native Co-processor is still a normal Co-processor, it just has access to almost all the Pi's memory and it runs it's code directly on the arm processor, its very fast but you still need a filesystem on the host to load the game from.

I use a 6502 launcher much like a lot of BBC games used a basic loader program, since the code needs to be run and setup on the host side its easier to do that with a small 6502 loader that runs the main game than try and copy code over to the host and execute it from a C program on the parasite side.

Doom and SpectROM use a rom which takes a *command to do their setup, I've never written a ROM so a small boot loader program is a simpler option for me. Even though they do use a ROM they are still loaded from the host's filesystem.

[dudleysoft71]

I've implemented the VSync solution, I'm not 100% sure it's solved all the issues, but since the comms screen is working without the FlagException call now I guess it means it's working.

I've also sped up the screen decompression code on the beeb side, I replaced the old code that incremented the address every byte with an indexed write and only add to the address after every block. I'm not sure what the overall saving will be it should improve frame-rates on larger changes since the main read loop will be quicker.

I've also fixed the F6 key which was using the wrong keycode in the host side, so you can now view all the information on a system.

Here's a new build with the changes in:

FE2Beeb_0.2.zip

(824.78 KiB) Downloaded 29 times

[Yrrah2]

Nice Work!!
And also the arrow keys / pointer work fine when starting to communicate to and buy and sell items.

The mouse isn't working because it's not setup to read the mouse.

I'm not sure the best way to go about that, and since I don't have a mouse to test with it's a bit of a problem implementing it.

Was thinking about the mouse. You can try SmallyMouse. Then you can use an USB mouse on the userport.
I have one installed and works great.

Cheers

P.S. guess this is a remark that is on your list I guess, but the font is not always readable.

[dudleysoft71]

I've thought about that, but currently I'm taking power for the Pi 1Mhz Bus from the user port, I've built an adaptor for the aux port I can swap over to, however I will lose the floppy drive while using the mouse. Ken Lowe is building a board that will extend the user port to give an extra power connector, so until then I won't have a mouse.

Currently the plan is to add two Key combination commands Ctrl-J for joystick mouse and Ctrl-M for mouse. I'm looking at supporting Adval 7,8 and 9 for reading the mouse. I just hope that my own interrupt code won't break the mouse reading on the host.

[dudleysoft71]

P.S. guess this is a remark that is on your list I guess, but the font is not always readable.

Yeah, the problem is the font is very small on the normal game at 320pixels, at 160 its going to be difficult to make the font much narrower. The font data is fairly simple so I am intending to try and reduce the width of as many characters as possible, lots of characters can be 2 pixels wide and the maximum will be 3 pixels, that should help a lot. Beyond that it'll be a case of editing the assembler source for the original game to move strings and to abbreviate some others.

[tricky]

Thanks, I hadn't realised native arm meant copro, I though it was an emulator that included tube support, but that would be harder. Still, how hard could SD access from the PI be

I'll stop asking RobC why he doesn't load DOOM from SD aswell!