Rick Dangerous and The Great Escape (PitTubeDirect and ARM7TDMI)

[dudleysoft71]

Since starting work on my beebScreen library I've been looking at porting various older games to the BBC micro. I've added some simple support for MODE 1 to the library, it's not as advanced as the Mode 2 support since it doesn't support colour remapping and dithering, however it still allows for porting of older games that don't rely on as many colours.

Today I'm releasing the first two ports:

Rick Dangerous and The Great Escape

Rick Dangerous

Rick Dangerous is a classic game, it's incredibly hard and frankly often completely unfair, it requires you to memorise the position of traps and hazards, often these are completely invisible until you trigger them.

This is a port of XRick, which as the name suggests started out for x-windows, the version here is the Mode 1 version, there's a mode 2 version with NULA support, but the lower resolution and the tricky nature of the game make spotting hazards even more difficult.

The game uses the standard BBC keys Z,X,* and / to move. Holding RETURN (fire) and pressing directions do the following:
FIRE + LEFT/RIGHT - Punch.
FIRE + UP - Fire your gun.
FIRE + DOWN - Drop Dynamite. (Note Dynamite hurts you too and often sends blocks flying which can also kill you)

There are a couple of cheat keys for this game though.

F7 - Give infinite ammo
F8 - Invunerability.

Screenshots:

The Great Escape

The Great Escape is about escaping from a German Prisoner of War camp, I never really worked out what to do in the game, but it was originally released on everything except the BBC Micro.

This version is based on Dave Thomas (Spanners) excellent C port of the original spectrum version, I was discussing the game with him at the last ABUG dev night, and he game me a few pointers as to how the port worked which enabled me to very quickly get a version up and running.

The menu music is broken, I added very simple code that counts the speaker bit transitions that come out the engine, and update the frequency of channel 3 every 50th of a second based on how many times the bit changed, this works for the ingame sounds which are fairly simple sounds, but the music doesn't quite work.

The game doesn't recognise all the keyboard keys, I've programmed it to recognise Z,X,*,/ and RETURN as a kempston joystick, so to start the game first select 2 from the main menu (KEMPSTON), then press 0 to start the game.

Screenshots:

As you can see both of these games are running fine in BeebEm, if you want to play them then you need to enable the ARM7TDMI co-processor under the hardware menu, both games fit on a DFS floppy disk image so you can simple load the disk image and boot the disk (once the ARM7TDMI co-processor is enabled)

[spanners]

[Grasshopper]

I was sufficiently intrigued by the port of Rick Dangerous to download the Windows version of BeebEm to give it a go.

Unfortunately, there appears to be a bug in the version of BeebEm that I downloaded (4.17) that causes the emulator to become unusably slow when the ARM7TDMI co-processor is enabled. I think it’s the same bug that’s detailed here:

https://github.com/stardot/beebem-windows/issues/86

Fortunately, the suggested workaround of setting the FPS to 50 appears to work reasonably well, and at least makes the game playable.

With regards to the game itself, it looks very nice indeed. Unfortunately, it’s just too hard to be rewarding to play. That’s not a criticism of the port. All version of the game are the same. So I ended up using the invunerability cheat to do some sightseeing.

Am I right in assuming that the graphics are rendered entirely by the BBC’s regular 6502 processor? If that’s the case, then it’s very impressive. It could almost be a NES game. The only thing that gives away the fact that it’s running on a BBC Micro is the slightly garish palette. It makes me wonder what types of games could have been written for the BBC had the machine been supplied with more RAM.

[dudleysoft71]

Am I right in assuming that the graphics are rendered entirely by the BBC’s regular 6502 processor? If that’s the case, then it’s very impressive. It could almost be a NES game. The only thing that gives away the fact that it’s running on a BBC Micro is the slightly garish palette. It makes me wonder what types of games could have been written for the BBC had the machine been supplied with more RAM.

No, the graphics are rendered on the Pi and then they are sent over the tube using delta compression. I believe it should be possible to do a bbx native version, but it'll be a lot more work, certainly the game was ported to all the other micro computers of the day.

The colours are actually the way they are because it's using the PC CGA palette, I've also done a VideoNULA version that runs in mode 2 that uses the Atari ST palette, however it's much harder to play because of the lower resolution.

[RobC]

Excellent stuff Two brilliant games

(For anyone with a NuLA and Pi co-pro, the CPC version of Rick Dangerous plays pretty well under the emulator and makes good use of the 16 colour mode 2.)

[lovebug]

looking good

after seeing this im so tempted to try writing regular 6502 version of rick dangerous for the standard beeb

[Grasshopper]

after seeing this im so tempted to try writing regular 6502 version of rick dangerous for the standard beeb

It would be very interesting to see whether it's possible. But I suspect you'd rapidly run into memory problems unless you choose to use multiple banks of sideways RAM. Rick Dangerous is quite a large game, although somewhat repetitive.

Also, in terms of gameplay, I think there are better games than Rick Dangerous from that era. If you want an example of a fun game that was ported to pretty much every platform apart from the BBC Micro, then I'd say that Ghosts'n'Goblins would be a better candidate.

Or maybe one of the Castlevania games. There's even a decent version of Castlevania for the ZX Spectrum.

[Grasshopper]

No, the graphics are rendered on the Pi and then they are sent over the tube using delta compression.

By "delta compression" do you mean that only the parts of the screen that are changed are sent over the tube, or is it more sophisticated than that?

[dudleysoft71]

Pretty much just runs of changed bytes, along with either a skip of N bytes, or a new start address, since the host isn't very fast all of the leg work is done on the second processor.

Ultimately everything is sent as commands via the VDU fifo, I've tried to keep the number of cycles per byte as low as possible on the host, but even so there's a limit of about 4k of changes per frame.

The coprocessor builds the entire buffer of commands first, then just sends the whole lot as a complete stream, this means the ARM7TDMI coprocessor can keep ahead of the host's processing, which probably wouldn't be possible if it was doing the delta compression at the same time, obviously the Pi doesn't have this issue.

The Great Escape also has a quirk that the coprocessor's frame buffer is only 4bit, so that has to be converted to an 8bit buffer before conversion to the beeb (4bit is a future potential feature but will require a whole new set of screen conversion functions to work).

[tom_seddon]

looking good

after seeing this im so tempted to try writing regular 6502 version of rick dangerous for the standard beeb

I dug into the Spectrum version a few years ago with this in mind, and it was all looking pretty feasible on the B, with disk loading. I hacked a Spectrum emulator to ignore the attribute RAM, and the game still looked fine (albeit now just black and white), so my plan was a 256x192 mode 4. The Spectrum version's tile system looked a bit inconvenient for the 6502, with multiple 1K buffers, but I think the Beeb's sheer CPU bhp would make it work...

The mode 1 screen grab here looks awesome though! So, maybe require 1 bank of sideways RAM (not an onerous demand in 2021), and that's the memory issue sorted. Twice as many bytes to copy around though. Maybe that would be a problem.

(I did initially look into the C64 version, because of course that has a 6502. But it turned out the game ran in character map mode, and made quite heavy use of the C64's sprites... not such a good fit for the Beeb. I found the C64 code a bit impenetrable as well. The Spectrum version by contrast was quite easy to follow.)

Also, in terms of gameplay, I think there are better games than Rick Dangerous from that era.

Yeah. Rick Dangerous as supplied is actually pretty tedious by modern standards. I was figuring I'd probably end up making it an infinite lives game, where there'd either be a time limit, or you'd be scored based on how quickly you got through it. There's nothing wrong with a game that's mostly based around memorizing the sequence of actions to perform, but maybe it doesn't have to be quite so annoying.

--Tom

[lovebug]

i might pull the graphics from the version uploaded in this thread and try an experiment

[dudleysoft71]

i might pull the graphics from the version uploaded in this thread and try an experiment

Your best bet is to download the source for xrick, it contains two sets of graphics, the PC cga graphics and the Atari ST
graphics, it would be an easier place to start than trying to extract from a binary file. I did think of doing this myself. I was going to write an exporter that converted and exported the data ready for the beeb directly from the original source files.

[lovebug]

i might pull the graphics from the version uploaded in this thread and try an experiment

Your best bet is to download the source for xrick, it contains two sets of graphics, the PC cga graphics and the Atari ST
graphics, it would be an easier place to start than trying to extract from a binary file. I did think of doing this myself. I was going to write an exporter that converted and exported the data ready for the beeb directly from the original source files.

ah ! thanks for the tip, i didnt know of the open source xrick

I did write a program to display screen fulls of data from the arm version and it got boring very quickly lol

i'll check out xrick, thanks

[Grasshopper]

I've tried to keep the number of cycles per byte as low as possible on the host, but even so there's a limit of about 4k of changes per frame.

Really? That actually sounds like quite a lot of data to me.

If you assume that sprites are 32*32 pixels (which is pretty big by BBC Micro standards), and you’re using a 4 colour screen mode, then you’d need to transfer 256 bytes to draw a single sprite. In a worse case scenario, you’d also need to transfer another 256 bytes to restore the background image at the sprite’s original location. So you could theoretically move up to 8 large sprites per frame. That's quite impressive, and would certainly enable the majority of NES era games to be ported.

I think you’d struggle to draw 8 large sprites per frame if the sprites were being rendered solely using the BBC’s primary 6502 processor.

The main downside to your approach is dealing with scrolling which I notice is pretty slow on Rick Dangerous. But on most games, smooth scrolling is a nice-to-have rather than a necessity.

[RobC]

The main downside to your approach is dealing with scrolling which I notice is pretty slow on Rick Dangerous. But on most games, smooth scrolling is a nice-to-have rather than a necessity.

In my Amstrad CPC emulator, I simply hook into the Beeb's hardware scrolling when the CPC scrolls the screen. So, it's possible to transfer the screen data across the TUBE and use hardware scrolling.

[Grasshopper]

In my Amstrad CPC emulator, I simply hook into the Beeb's hardware scrolling when the CPC scrolls the screen. So, it's possible to transfer the screen data across the TUBE and use hardware scrolling.

Wait. You’ve written an Amstrad emulator for the BBC Micro? That’s completely insane (but in a good way). And after a bit of googling, I see you’ve written a Spectrum emulator for the BBC Micro as well!

I’m impressed. Do they run at full speed, and are they fully featured? I did find a couple of youtube videos, but they’re a couple of years out of date.

Also, have you considered writing emulators for other machines in the Acorn 8-bit range? I think they’d be a better fit given they have similar keyboards and hardware. It would be very cool indeed if a regular BBC Micro could emulate a Master, Electron, or even an Atom.

[dudleysoft71]

I've been working on adding RGB2HDMI support to beebScreen, I've added this support to a mode 2 version of Rick Dangerous.

Here's a new build of Rick Dangerous on an ADFS disk image with support added, you can boot it directly from the disk image or run it
via

Code: Select all

*RICK -HDMI

I haven't got the hardware to test this, and obviously none of the emulators support it, so I need people to test it for me.

[RobC]

Wait. You’ve written an Amstrad emulator for the BBC Micro? That’s completely insane (but in a good way). And after a bit of googling, I see you’ve written a Spectrum emulator for the BBC Micro as well!

I’m impressed. Do they run at full speed, and are they fully featured? I did find a couple of youtube videos, but they’re a couple of years out of date.

Also, have you considered writing emulators for other machines in the Acorn 8-bit range? I think they’d be a better fit given they have similar keyboards and hardware. It would be very cool indeed if a regular BBC Micro could emulate a Master, Electron, or even an Atom.

They run at a reasonable speed (on a Pi co-pro!) - certainly well enough to play some games. There's a bit of slowdown when a lot is happening on screen but it's generally okay. I've also written a ZX81 emulator and a Jupiter Ace emulator and James/Duddleysoft has done a Gameboy emulator which is excellent.


Sound emulation is the hardest part - the Speccy's on/off beeper is pretty hard to match with the Beeb's sound chip but sound is acceptable on most games (e.g. the speech in Ghostbusters is intelligible). I think the CPC sound is a bit better (as it's closer to the Beeb's sound chip) but it's not perfect.

Joysticks work but the emulation is in no way complete and it's buggier than on PC-based emulators (partly because I wrote them as a bit of fun rather than as serious projects and partly because sending screen data over the TUBE adds some constraints).

I have thought about writing a M128 emulator and an Atom emulator but haven't got round to it yet.

[dudleysoft71]

I realised last night that I'd made a silly mistake with the RGB2HDMI version, it was using the MODE 2 dither code to convert the screen rather than the NULA converter, I've done an updated build which uses this converter now. it should run the same as the previous version in all other respects.

I forgot to add that this version also supports normal VideoNULA mode by calling with

Code: Select all

*RICK -NULA

as well as

Code: Select all

*RICK -HDMI

for the RGB2HDMI version, as well as the standard MODE 2 with dithering.

[dudleysoft71]

I was hoping to get some feedback if the RGB2HDMI mode works, I cannot test it myself since i don't have one.

I've been working blind, if it works then there are more ports that are ready to go but I don't really want to release them unless I know that the feature is working.

[hoglet]

I was hoping to get some feedback if the RGB2HDMI mode works, I cannot test it myself since i don't have one.

I can try this tomorrow....

[Lardo Boffin]

I've also written a ZX81 emulator and a Jupiter Ace emulator and James/Duddleysoft has done a Gameboy emulator which is excellent.

A gameboy emulator?!?! Sounds interesting.

[hoglet]

I was hoping to get some feedback if the RGB2HDMI mode works, I cannot test it myself since i don't have one.

Does this look right?
https://www.youtube.com/watch?v=oSd1zsFmimM

I've been working blind, if it works then there are more ports that are ready to go but I don't really want to release them unless I know that the feature is working.

Pretty good for a first attempt!

[dudleysoft71]

I was hoping to get some feedback if the RGB2HDMI mode works, I cannot test it myself since i don't have one.

Does this look right?
https://www.youtube.com/watch?v=oSd1zsFmimM

I've been working blind, if it works then there are more ports that are ready to go but I don't really want to release them unless I know that the feature is working.

Pretty good for a first attempt!

Okay, I'm impressed that worked as well as it did, guess that means I'll post the updated versions of DOOM, Quake, and Elite: TNK with the RGB2HDMI code added, Frontier will take a bit more work, I can't simply slot in BeebScreen into that one.

[hoglet]

Okay, I'm impressed that worked as well as it did, guess that means I'll post the updated versions of DOOM, Quake, and Elite: TNK with the RGB2HDMI code added, Frontier will take a bit more work, I can't simply slot in BeebScreen into that one.

Have you thought about releasing a single ADFS hard drive image that contains everything?

You could even add a simple DudleySoft Menu...

[dudleysoft71]

Okay, I'm impressed that worked as well as it did, guess that means I'll post the updated versions of DOOM, Quake, and Elite: TNK with the RGB2HDMI code added, Frontier will take a bit more work, I can't simply slot in BeebScreen into that one.

Have you thought about releasing a single ADFS hard drive image that contains everything?

You could even add a simple DudleySoft Menu...

I was in the process of creating a menu system to put on my own HDD to launch all my projects but I think a simpler menu would suffice for a general image, perhaps something in BASIC, I'd like to be able to save the video option though, so you just choose a game and it will pass the correct parameter to setup the correct video mode.

I could definitely do an image with them all, obviously it would have to be the shareware versions of DOOM and Quake since those are still being sold, and obviously I can't distribute ROMs with the GameBoy emulator, and Sierra's AGI games are a bit of a minefield (I believe Activision owns a lot of them, except for Leisure Suit Larry which for some reason seems to be Codemasters?)

[Lardo Boffin]

I was hoping to get some feedback if the RGB2HDMI mode works, I cannot test it myself since i don't have one.

I've been working blind, if it works then there are more ports that are ready to go but I don't really want to release them unless I know that the feature is working.

Looks amazing but appears to be slightly chopped off at the top?

[hoglet]

Looks amazing but appears to be slightly chopped off at the top?

I think that's expected, because the first line is where the RGBtoHDMI palette command is placed.

It might be less noticable if everything else was moved down by one line (i.e. you would then loose the bottom line).

Dave

[BigEd]

Is that palette command only needed for a few frames after a mode change?

[hoglet]

Is that palette command only needed for a few frames after a mode change?

No, unfortunately it needs to be present on every frame, otherwise the rendering falls back to treating the data as MODE 0.

What's currently implemented for the in-band signalling is very much a proof of concept. The more comprehensive protocol, which Ian sketched out in this post, didn't ever get implemented. At the time there wasn't a great deal of interest, and there were lots of other features that were more pressing.

If there is sufficient demand, it would still be possible to implement this, and I could probably be presuaded to have a go. Most of the heavy lifting is already in place thanks to Ian. The missing piece is the more sophisticated command processor.

Dave