Frontier Elite 2

[trixster]

*FX 151,230,15

Needs the 1GHz processor

[dudleysoft71]

You need to select the native arm co-processor (*FX151,230,15) for it to work, it wont run on older ARM processors.

I did try to do a build for the arm7tdmi co-processor, but it just hung, I need to debug it in more detail to find out what's failing, but if it works then you could theoretically play it in BeebEm.

[Yrrah2]

YES!!!!

Nice to see that running!
Thanks. Really nice work!

[dudleysoft71]

I've just been working on getting input working, at the moment pressing SPACE will take you to the Start position menu, but the options don't work, and pressing SPACE again hangs the game, so very much a work in progress.

[AJW]

Sorry to interrupt, what do I do with a .dat or .dsc file?

[dudleysoft71]

The .dat file is the hard drive image,the .dsc file is the description of the hard drive geometry, this can be copied into the BeebSCSI0 folder on an SD card to use with either the Pi1Mhz or BeebSCSI interface. The .dat file can also be opened in ADFS Explorer or Beeb Image to extract the files to another storage device, here's the contents of the hard drive file:

The game requires a HDD, the main executable file is 2MBytes which is larger than the largest ADFS floppy capacity, and it also loads a 500KByte data file after the main executable is loaded.

The two loaders FE2 and FE2ULA are 6502 Assembler programs that run on the host processor, setup the video mode, show the loading screen, then run the main game, unfortunately they can't check if you're using the Native ARM processor, so if you try with a different core then it's likely it will just hang when the main game overwrites whatever memory is in the core, or tries to execute arm11 instructions on a different processor.

I can't create an SD card image for the modified ADFS on a Master, if someone else could put the files into a suitable folder on an image then that would be appreciated.

[AJW]

OK thanks. I don't have hardware so will wait for anybody to advise how to run on emulator.

[dudleysoft71]

Currently there is no emulator that can run the native arm core, the closest is the arm7tdmi in BeebEm.

Hopefully I will at some point be able to create a build that works on that processor, but arm7tdmi doesn't have an fpu, which the arm11 in the PiZero does. There are likely other differences in how the arm7tdmi core interfaces with the tube IO which may also break the game.

[marcusjambler]

Cant get this running :

I put the files in BeebSCSI folder on the card in the Pi to 1MHz dongle.
Selected copro 15 on the PiTUBE dongle. ( *FX151,230,15 )
CTRL-A-BREAK to boot into ADFS
*. shows the files present
Typed *FE2.... and it hangs with fancy stripey text ( VideoNULA installed )

This Beeb has an Integra B board in if that makes a difference.

Not sure what else to try

[dudleysoft71]

Okay, not sure what the Integra B+ board is likely to do. It could be something to do with Shadow RAM, or it could subtly change the way something is loading.

Make sure FE2's load and execute addresses are FFFF2100, if they aren't then they wont be running on the host, I don't think the Native ARM co-processor would get very far trying to run 6502 code.

[dudleysoft71]

At last, the comms screen is working, turns out the menu screens aren't calling the screen flip. I use the screen flip code to send the updates to the beeb, the original SDL version uses a timer every 20ms to raise an exception on the emulated core which causes it to update the display, but there's no timer functions on the Native ARM core so I had to cheat and call it in the flip function. Luckily it also calls an Idle function, which was doing nothing since there's also no sleep either, so I've changed that to update the screen as well and the menus now work.

[dudleysoft71]

Cant get this running :

I put the files in BeebSCSI folder on the card in the Pi to 1MHz dongle.
Selected copro 15 on the PiTUBE dongle. ( *FX151,230,15 )
CTRL-A-BREAK to boot into ADFS
*. shows the files present
Typed *FE2.... and it hangs with fancy stripey text ( VideoNULA installed )

This Beeb has an Integra B board in if that makes a difference.

Not sure what else to try

Can you take a screenshot of your screen? The game takes a long time to load since it's so large (though I might have found the reason for that so I may be able to reduce the size). I don't have any experience with the Integra B board so I don't know how it might affect the Beeb.

[marcusjambler]

I've moved the Pi dongles to a standard beeb with 1770 and its running fine so perhaps Ken can work out whats tripping the other one up.
Anyway its working great now just need to transfer the VideoNULA over.

[marcusjambler]

Can you take a screenshot of your screen?

Its just the boot banner and the arm>* prompt

After which I type *FE2 (return)

Then it just stays there
The screen doesnt clear but the text palette looks to be changing every 3 or 4 scan lines

[dudleysoft71]

Can you take a screenshot of your screen?

Its just the boot banner and the arm>* prompt

After which I type *FE2 (return)

Then it just stays there
The screen doesnt clear but the text palette looks to be changing every 3 or 4 scan lines

Okay, that's definitely strange, I tried with the disk image in BeebEm with Integra B setup, and it seemed to work there alright (except the game wont run because the emulator only supports the ARM7TDMI co-processor), but the loading screen appeared. I tried fiddling with the configuration, but it still seemed to load the game.

Have you tried running *FE2ULA instead of *FE2? does it do that same thing? (except the palette changes, since it leaves the palette alone)

After it returns can you do anything else? Or is the machine frozen?

I was just putting together a new build, now that the comms menu is working, perhaps you'll have more luck with this one. If not maybe someone else here with more knowledge of the Integra B might be able to help, but FE2 is simply a 6502 executable, it sets the video mode to mode 2 (using VDU 22,2), changes the screen to 25 lines high, changes a couple of vectors (IRQV and WRCHV), then *LOADs the loading screen and then *RUNs the game, it should work on any beeb.

[RobC]

but there's no timer functions on the Native ARM core

Not sure I follow what you're trying to do but for Doom, I have an assembler function that returns the low 32-bits of the Pi's microsecond system timer e.g.:

Code: Select all

_get_ustimer:
    // set R0 to peripheral base address
        mov             r0, #0x20000000
        // set R0 to System Timer base address
        orr             r0, r0, #0x3000
        // get low 32 bits of counter
        ldr             r0, [r0, #4]
        mov             pc, lr

The peripheral base address is different for different Pi models - I think this is right for the zero and Pi 1.

[marcusjambler]

Have you tried running *FE2ULA instead of *FE2? does it do that same thing? (except the palette changes, since it leaves the palette alone)

After it returns can you do anything else? Or is the machine frozen?

Tried both FE2 and FE2ULA same issue.

It doesnt return ( CAPS LOCK' wont toggle ) only break etc unfreezes it.

[dudleysoft71]

but there's no timer functions on the Native ARM core

Not sure I follow what you're trying to do but for Doom, I have an assembler function that returns the low 32-bits of the Pi's microsecond system timer e.g.:

Code: Select all

_get_ustimer:
    // set R0 to peripheral base address
        mov             r0, #0x20000000
        // set R0 to System Timer base address
        orr             r0, r0, #0x3000
        // get low 32 bits of counter
        ldr             r0, [r0, #4]
        mov             pc, lr

The peripheral base address is different for different Pi models - I think this is right for the zero and Pi 1.

Rather there's no timer interrupt, the engine just runs the emulated ST at full whack all the time, in the main program calls

Code: Select all

SDL_AddTimer (20, &vbl_callback, NULL);

which causes a callback every 20ms which then triggers the vblank interrupt in the emulator. The problem is I can't find a way to do the same thing on the Pi Native ARM co-processor. There's an SWI that proclaims to do that, but it's just calls tube_SWI_Not_Known which isn't much use.

If you know of a way to create a regular interrupt event that my code can detect then I'd appreciate the help, would make it work more like the original, and also help with speed since it doesn't actually update the clock at 50fps.

[dudleysoft71]

Have you tried running *FE2ULA instead of *FE2? does it do that same thing? (except the palette changes, since it leaves the palette alone)

After it returns can you do anything else? Or is the machine frozen?

Tried both FE2 and FE2ULA same issue.

It doesnt return ( CAPS LOCK' wont toggle ) only break etc unfreezes it.

Okay, strange, if it had changed mode I'd have said it was a Shadow RAM issue, perhaps there's an issue with replacing the WRCHV on an Integra B? Unfortunately the game needs the vector re-directed to send the video from the co-processor to the host, otherwise I'd suggest doing *FE2GAME to see if that loads alright.

[RobC]

Rather there's no timer interrupt, the engine just runs the emulated ST at full whack all the time, in the main program calls

Code: Select all

SDL_AddTimer (20, &vbl_callback, NULL);

which causes a callback every 20ms which then triggers the vblank interrupt in the emulator. The problem is I can't find a way to do the same thing on the Pi Native ARM co-processor. There's an SWI that proclaims to do that, but it's just calls tube_SWI_Not_Known which isn't much use.

If you know of a way to create a regular interrupt event that my code can detect then I'd appreciate the help, would make it work more like the original, and also help with speed since it doesn't actually update the clock at 50fps.

Ah right, that's not something I've done. I've tended to run the video update at the end of each iteration of the main loop and use OSBYTE 19 to sync it up to the Beeb's 50Hz frame rate.

[dudleysoft71]

Rather there's no timer interrupt, the engine just runs the emulated ST at full whack all the time, in the main program calls

Code: Select all

SDL_AddTimer (20, &vbl_callback, NULL);

which causes a callback every 20ms which then triggers the vblank interrupt in the emulator. The problem is I can't find a way to do the same thing on the Pi Native ARM co-processor. There's an SWI that proclaims to do that, but it's just calls tube_SWI_Not_Known which isn't much use.

If you know of a way to create a regular interrupt event that my code can detect then I'd appreciate the help, would make it work more like the original, and also help with speed since it doesn't actually update the clock at 50fps.

Ah right, that's not something I've done. I've tended to run the video update at the end of each iteration of the main loop and use OSBYTE 19 to sync it up to the Beeb's 50Hz frame rate.

It's not how I would normally do things either, but there doesn't seem to be a way around it. The game runs at a reasonable frame rate, but the game feels sluggish because the game ticker is updated by the vsync, so it isn't getting as many as it needs per second.

I'm not sure if enabling the interrupt on Tube register 1, and sending a byte during vsync will actually make it to my game, if so I could use that to sync the game to vsync. I think then it will only send a frame if there's one waiting, so it won't matter how long it takes to upload to the beeb.

[RobC]

t's not how I would normally do things either, but there doesn't seem to be a way around it. The game runs at a reasonable frame rate, but the game feels sluggish because the game ticker is updated by the vsync, so it isn't getting as many as it needs per second.

I haven't looked at the code so this might be completely irrelevant but can you use the timer to work out how many ticks have passed and update the ticker with the requisite number of ticks?

[dudleysoft71]

I haven't looked at the code so this might be completely irrelevant but can you use the timer to work out how many ticks have passed and update the ticker with the requisite number of ticks?

I did think about that, the issue is that it's flagging an interrupt, which is being processed outside of the main code, the interrupt is handled by the recompiled 68000 code. So I would need to return to running the virtual machine and then send another interrupt after the vblank has been handled. Which is why the SDL version is generating a timer event every 20ms.

[dudleysoft71]

I haven't looked at the code so this might be completely irrelevant but can you use the timer to work out how many ticks have passed and update the ticker with the requisite number of ticks?

I did think about that, the issue is that it's flagging an interrupt, which is being processed outside of the main code, the interrupt is handled by the recompiled 68000 code. So I would need to return to running the virtual machine and then send another interrupt after the vblank has been handled. Which is why the SDL version is generating a timer event every 20ms.

I've come up with a potential solution, the R1 line will generate an escape event, I can use SWI OS_ChangeEnvironment to set the escape vector, then write to R1 from the host in vblank. That should give me a 50hz ticker in the parasite I can use to generate the vblank for the game.

[AJW]

Sunds like you need RISC OS and 6502 expertise in equal measure.