Going great guns on a Prince of Persia port...

[kieranhj]

Hello all,

At ABUG over the weekend I declared my intentions to attempt a port of Prince of Persia to the BBC Master. I've been doing plenty of research on the source thus far and have a very (very) early prototype of a MODE 1 plot routine that works directly using the Apple II sprite data. It's going to be a long and slow journey (not least because I am very busy with work at the moment) but I will post my progress here for general support, encouragement and hopefully some help along the way.

First prototype attached. It is designed for the Master but should load on any machine with 1x 16K swram + page at E00. Eventually this will be Master only because of the 128K memory requirements.

Enjoy!

[Rich Talbot-Watkins]

You're braver than I am. There's a lot of data to try and fit in there!

Have you seen Prince of Persia on the Amstrad CPC?



I would recommend going for MODE 2 resolution graphics so you can make use of the extra colours. The animation is already so detailed that the lower resolution is hidden by the intricate movement. Looking forward, I'd even say it would be a superb candidate for creating graphics in 16 colours (resorting to the closest RGB colour on standard hardware) which could then make the most of RobC's Palettemate in the future! I assume all the CPC graphics are available somewhere?

[trixster]

Would it be worth chatting to the c64 chaps on lemon64 forum? They might be able to give some advice.

[oss003]

Wow ...... this is a real challenge .....

Greetings
Kees

[Prime]

Wow ...... this is a real challenge .....

Does that mean we'll see an Atom version at some point.......

Cheers.

Phill.

[oss003]

Wow ...... this is a real challenge .....

Does that mean we'll see an Atom version at some point.......

That's even a bigger challenge ....... first have to finish Thrust ......

Greetings
Kees

[Dave Footitt]

Best of luck

Good to chat with you this weekend too!

[kieranhj]

You're braver than I am. There's a lot of data to try and fit in there!

Have you seen Prince of Persia on the Amstrad CPC?

I would recommend going for MODE 2 resolution graphics so you can make use of the extra colours. The animation is already so detailed that the lower resolution is hidden by the intricate movement. Looking forward, I'd even say it would be a superb candidate for creating graphics in 16 colours (resorting to the closest RGB colour on standard hardware) which could then make the most of RobC's Palettemate in the future! I assume all the CPC graphics are available somewhere?

I must admit I haven't checked out the CPC version so not aware if the gfx are already available. I will take a deeper look at this though as it is nice & colourful. Choosing which mode is a big decision, so would appreciate your thoughts.

I have been working from the original Apple II source on GitHub and my intention was to try and port this as directly and cleanly as possible to preserve the original gameplay. Given that it is all in 6502 and very well structured for the era (29 discrete code modules, all reasonably well documented and with a clean jump-table interface between each one) in theory it should be "relatively" easy to insert a set of BBC plot routines to replace the Apple II hires functions. Squeezing it all into RAM is a different matter, that we'll come to.

The Apple II screen is 280x192 pixels in hi-res mode which has 6 "artefact" colours in a weird 7 pixels per byte format. You can only have 4 colours per byte (2 are always black & white) and only change colour every 2 pixels. I wrote a small tool to extract the sprites from the original source files so I can convert these to something convenient (see example png attached.) Because of the Apple II hi-res limitations, all the sprites are 4 colours maximum, so MODE 1 would seem to be the ideal target to get a nice clean hi-res Beeb look.

However from a memory POV this is tough. Apple II has 2x 8k screens for double buffering. An equivalent 280x192 MODE 1 screen would be 70x192x2 = 26.25k so we've already lost 10.25k. The Apple II version uses up the entire 128k of RAM, which is configured in 2x 64kb contiguous banks. Even on a Master it is hard to piece together that much memory and will require a great deal of bank switching.

I thought about MODE 5 potentially, since colours only change every 2 pixels giving an apparent horizontal resolution of 140, as this would halve the memory requirements. Yet because of the weird way the Apple hi-res screen works you can see individual colour pixels, so not sure it would look as good. It also complicates the plot routines as each background piece is 28 pixels wide, which is nicely divisible as 7x MODE 1 bytes but in MODE 5 they would be 14 pixels wide which is more awkward.

I hadn't really thought about MODE 2, I would need to get hold of the CPC sprite data and see what I could make of it. It would introduce the added complication that all x coordinates in the game are 0-279.

After extracting the Apple II sprites, I ran the numbers and turning the 7 pixels per byte format into 2bpp MODE 1 would bloat the data by 50-66% depending on the sprite set. This blows out the memory requirements before we even start. The extra kicker is that the POP sprites can all be displayed on any pixel alignment, but there's no way we can store 4x copies of the MODE 1 sprites. POP handles this internally by having lookup tables to rotate the Apple II sprite data (since it is effectively just 1-bpp.)

I decided my next step was to write a simple (albeit slow) sprite plot routine that draws directly from the Apple II data as a test (attached in previous post.) This way I keep the same memory overhead and drawing functions but "just" replace the Apple II hi-res module to plot the data to the Beeb screen.

During gameplay POP requires ~30k for the player sprites, ~13.5k background tiles, ~6k for enemy sprites on each level ~= 49.5k which will comfortably fit in Master swram. More difficult is the approximate 48k of game code (at least according to the POP technical documentation.) I reckon I can piece together ~30k from various (non-contiguous) addresses around the Master but that doesn't include the additional buffers required etc.

So yeah, a challenge for sure. The level plot routine is well documented, I figured if I could get this up & running to display each screen from each level that would be a good next step. If I can then get the sprite frame animation code going I would have enough to spur me on to come up with a cunning solution to the memory issues. Maybe..!

[Rich Talbot-Watkins]

My initial instinct is always to choose colours over resolution, if it's a choice between MODE 1 and MODE 2. Isn't there some funny thing anyway where the Apple II essentially doubles up pixels when displaying different colours?

If you were to go with a 70 column wide MODE 2 * 24 lines, that's a 13k screen which is probably on the right side of acceptable. Although double buffering would be nice, I feel like it's not necessary, as for the most part there's only one moving sprite, and occasionally two.

One thing to consider would be a routine like Exile's which unpacks 2bpp graphics to MODE 2 with specified colours, and can optionally flip them and position them at a one pixel offset. That would help with the memory requirements. I'm not sure how PoP performs occlusion, but (not considering trying to make full use of all 16 colours via Palettemate for the moment) the top bit of the screen bytes (i.e. colours 8-15) could be used to specify tiles in the foreground.

One 'advantage' of reducing the horizontal resolution to 140 would be that at least it fits in a single byte - could potentially simplify some of the code, unless the full horizontal resolution is still required. Going back to the weird Apple colour handling, I wonder if it basically treats it as if it were a 140 wide screen anyway? From my vague understanding of the hardware, the colour depends on whether the pixel is at an odd or even position, so I assume a sprite would alternate between different colours if it moved pixel-at-a-time.

I hadn't realised that the CPC version was actually an official release, so I guess the graphics / code aren't in the public domain, never mind that the CPC's a Z80 beast anyway.

[RobC]

Really excited that this is happening - I'd looked at it briefly but decided that I didn't have the skills.

Any version would be great but something in mode 2 using my VideoNuLA would be fantastic (but I'm obviously biased )

In terms of memory, I wouldn't be put off even if it needs SWRAM and ROM. If it's only conveniently playable in an emulator, so be it.

Also, if you haven't seen it before, there's a routine called GFX Ripper at Retrospec: http://retrospec.sgn.net/game/gfxrip. It claims to be able to rip Amstrad graphics from a snapshot (although I've only been able to get it to work for other machines).

[kieranhj]

Really excited that this is happening - I'd looked at it briefly but decided that I didn't have the skills.

Any version would be great but something in mode 2 using my VideoNuLA would be fantastic (but I'm obviously biased )

In terms of memory, I wouldn't be put off even if it needs SWRAM and ROM. If it's only conveniently playable in an emulator, so be it.

Also, if you haven't seen it before, there's a routine called GFX Ripper at Retrospec: http://retrospec.sgn.net/game/gfxrip. It claims to be able to rip Amstrad graphics from a snapshot (although I've only been able to get it to work for other machines).

Thanks for the link, I've not heard of that before.

I presume your NuLA can program the palette in MODE 1 as well? So even if it was four colours we could at least get an accurate Apple II blue & orange?

I am currently combing the Apple II source to detail the existing memory map (and learning about the Apple II banking system in the process) to figure out where all this might be crammed on the Beeb. It will absolutely need a minimum of 64K swram which is why I was most likely to target Master only. I guess I could make it 128K swram only but that would be pretty restrictive!

On to Rich's points. I understand the coordinate system for sprites is 0-255 in x with 140 pixels representing the width of the screen (58 pixels are off screen left & right) so this could lend some possibility to using MODE 2/5. The background tiles are handled differently and would definitely be inconvenient at 14 pixels (at least in MODE 5.)

The POP sprite routine already handles flipping, masking and clipping of the Apple II sprite data. There are 10x3 background "pieces" on the screen, each piece is drawn using painters algorithm (back to front) to get the correct effect, with various layers employed to allow the sprites to be behind pillars etc.

Original Apple II POP runs at ~11 fps apparently so thankfully doesn't rely on high frame rate, it does use double-buffering however. Individual pieces can be flagged for redraw as sprites move so plotting is quite expensive. As you say, it might be possible to do something "clever" to avoid this on a Beeb in MODE 2.

Finally, yes the Apple II hi-res screen is technically 280 b&w pixels with an effective resolution of 140 coloured pixels, but you can kinda see individual hi-res pixels. It's weird. See: https://en.wikipedia.org/wiki/Apple_II_graphics. However I do like the hi-res look and always hanker for MODE 1 games. I haven't committed myself either way yet as still in exploratory phase.

[RobC]

I presume your NuLA can program the palette in MODE 1 as well? So even if it was four colours we could at least get an accurate Apple II blue & orange?

Yes - the colours in any mode (including mode 7) can be chosen from the 4096 colour palette. The big advantage in mode 2 is that you get 16 genuine colours rather than 8+8 flashing.

[sbadger]

Just recieved Issue 3 of Eight Bit magazine about Amstrad CPC and saw PoP and thought must mention it, (and now just seen RichTWs post to the same)

<goad>the Amstrad's only got 64k ram and even some schoolboy coder managed...</>

[kieranhj]

Just recieved Issue 3 of Eight Bit magazine about Amstrad CPC and saw PoP and thought must mention it, (and now just seen RichTWs post to the same)

<goad>the Amstrad's only got 64k ram and even some schoolboy coder managed...</>

I know where you live, remember?

[hexwab]

Looking at the CPC version, it's 160x200x4bpp, so an extra 20 pixels horizontally, plus a status line at the bottom. The graphics seem to be stretched from the Apple II version, as the screen layout is identical and yet it takes more horizontal pixels. Hence it's not quite half the resolution (4/7) of the Apple II. http://www.jordanmechner.com/downloads/popsource.pdf says "Since all the character movements throughout the program are specified according to the 140-wide coordinate system, we would like to keep the character's X-coordinate on a 140-wide screen for all the different conversions. The character's position could then be mapped to the actual screen width for that machine--320,512, 640, or whatever--at the time the character is drawn." suggesting the author was expecting conversions to use non-multiples of 280 horizontal pixels.

It runs on a 64K machine (appears not to require 128K) and I don't think it uses double buffering (based upon a memory dump from an emulator). Maybe the CPC is sufficiently faster than the Apple that it can draw everything in vblank? If the CPC can do it, the Beeb almost certainly can.

This may or may not help you make a decision, but data is good, right?

Me, I'm voting for MODE 1 with 320x192 stretched graphics. Sure, more colours are nice but the Beeb has terrible colours (modulo NuLA, but nobody has one of those). Unless you use fancy tricks to make use of the extra bit per pixel there seems no reason to use MODE 2 on a vanilla Beeb. Go for extra resolution any day.
Maybe you could steal the graphics from the CGA version, which is also 320x192x2bpp (with full resolution colour)? Attached is a CGA screenshot and Beeb conversion for playing around with the palette.



Tom.

[Elminster]

Me, I'm voting for MODE 1 with 320x192 stretched graphics. Sure, more colours are nice but the Beeb has terrible colours (modulo NuLA, but nobody has one of those). Unless you use fancy tricks to make use of the extra bit per pixel there seems no reason to use MODE 2 on a vanilla Beeb. Go for extra resolution any day.

Although a mode 2 RobC NULA version would be awesome for demoing at shows and would help shift lots of NULAs.

But I guess ideally a version open to people with a standard machine would be ideal.

Two version maybe? Bare bones version and awesome version (NULA, BeebSID/OPL, Pi Tube etc. )

[Rich Talbot-Watkins]

Anyone fancy doing a mock up using the Amstrad graphics as a starting point to see what it could look like in MODE 2 with the standard colours? I can imagine that the Beeb's garish palette doesn't lend itself well to this game...


Hard to know what to change that grey floor for. I guess some kind of stippled combination.

It's surprising that they changed the graphics to span the entire screen (160 pixels) on the CPC, so each tile is 8 columns instead of 7. The CPC uses a 6845 CRTC so shrinking the screen is not only possible (like on the Beeb) but also helps to save a bit of memory. But maybe with the lower resolution, they were able to get better looking graphics that way.

I definitely don't think double buffering the entire screen would be necessary on the Beeb, but it might still be too slow to plot two sprites without flicker during VBlank, particularly if they needed to be unpacked from 2bpp, or mirrored/offset on the fly. I would probably take the approach of copying the bounding rectangle to a back buffer, plotting the sprite there, and then block copying it to screen during VBlank. Apparently it has 3 or 4 frames per update, so this is more than enough time to do this.

[kieranhj]

Thanks for the thoughts & suggestions everyone! I'm sure John could make an awesome mock up of a MODE 2 version but that will be an even more crazy amount of work to redo all the graphics. Other ports have taken the PC CGA sprites as a source and converted these.

The original Apple II version runs at ~11Hz so if we can get the Beeb version running in 3 frames then we'll be ahead at 12.5Hz.

I've spent a couple of days combing the Apple II memory map, which I think looks roughly like this:

Code: Select all

main ram
-----
$0000 - ZP vars and locals at $e8
$0100 - Stack
$0200 - Apple II Input Buffer (Vars = total 17 bytes) 
$0300 - Apple II Vectors (Small arrays and some vars = 48 + 9 = 56 bytes)
$0400 - $07FF = I/O devices?
$0800 - chtab3 (kid) - main (5985 = $1761 bytes)
$2000 - 3FFFF = hi-res page 1
$4000 - $5FFF = hi-res page 2
$6000 - chtab1 (kid) - main (9165 = $23cd bytes)
$8400 - chtab2 (kid) - main (9189 = $23e5 bytes)
$a800 - chtab5 (kid) - main (6134 = $17f6 bytes)
-----
$C000 - $CFFF = 4K I/O DEVICES
-----
$d000 - rw18 (something to do with disc loader)
$d000 - peelbuf1 (presume size = $600)
$d600 - peelbuf2 (presume size = $600)
$e000 - hrtables (YLO & YHI, SHIFT, CARRY, MIRROR etc. = 192*2 + 16*128 + 7*6 + 6 = 2288 bytes)
$ea00 - unpack.s module, includes gameeq.s, eq.s
$ee00 - hires.s module, includes hrparams.s
$f880 - master.s module, includes eq.s, gameeq.s
-----
2k system + 16k screens + 30k kid sprites (48k main mem) + 4k disc buffer + 12k rendering code & buffers (main l.c.) = 64k

auxmem
-----
$0000 - ZP vars and locals at $e8
$0100 - Stack
$0200 - Apple II Input Buffer?
$0300 - Apple II Vectors?
$0400 - grafix.s module, includes eq.s, gameeq.s, soundnames.s
$0e00 - tables in EQ.S (dense - $488 total)
$1290 - frameadv.s module, includes eq.s, gameeq.s, bgdata.s <- included after jump table
$2000 - topctrl.s, includes eq.s, gameeq.s, seqdata.s, movedata.s, soundnames.s
$2800 - framedef.s (animation frames) (1200 + 200 + 450 + 192 = 2042 bytes)
$3000 - seqtable.s (animation sequences)
$3a00 - ctrl.s, includes eq.s, gameeq.s, seqdata.s, soundnames.s, movedata.s
$4500 - coll.s, includes eq.s, gameeq.s, seqdata.s, soundnames.s, movedata.s
$4c00 - gamebg.s, includes eq.s, gameeq.s
$5400 - auto.s module, includes eq.s, gameeq.s, seqdata.s, soundnames.s, movedata.s
$5e00 - redbufs (redraw buffers) (60 bytes unused then 250 bytes = 310 bytes total)
$6000 - bgtab1 (max 9185 = $23e1 bytes)
$6000 - chtab6 (princess in cutscenes) (overlaid)
$8400 - bgtab2 (max 4593 = $11f1 bytes )
$9600 - chtab4 (guard) (max 5281 = $14a1 bytes; top = $ab00)
$9f00 - chtab7 (princess in cutscenes) (overlaid)
$ac00 - imlists (image lists) (200x4 + 100x4 + 20x5 + 46x8 + 46x11 + 20x12 + 32x5 = 2574 bytes = $a0e)
$b600 - mobtables
$b6f0 - savedgame
$b700 - blueprnt (blue print) - $900 size (runs up to $c000)
-----
$C000 - $CFFF = 4K I/O DEVICES
-----
$d000 - ctrlsubs.s, includes eq.s, gameeq.s, movedata.s, seqdata.s, soundnames.s
$d400 - msys (music system ii)
$d900 - specialk.s, includes eq.s, gameeq.s, soundnames.s, movedata.s
$dfd8 - version.s (text string = 28 bytes)
$e000 - subs.s, includes eq.s, gameeq.s, seqdata.s, movedata.s, soundnames.s
$ea00 - sound.s
$ee00 - mover.s includes eq.s, gameeq.s, seqdata.s, movedata.s, soundnames.s
$f900 - misc.s, includes eq.s, gameeq.s, seqdata.s, movedata.s, soundnames.s
-----
1k system + 23k game code & data + 19k sprites + 2k level + 3k buffers (48k aux mem) + 4k music + 12k more game code (aux l.c.) = 64k

So, yeah, again a lot of code & data. Some complications to consider - two lots of zero page (hmmmm) and seems like the Apple has the ability to read & write from different memory banks.

After some pondering, my preferred approach is going to be MODE 1 but at original resolution (280x192) single-buffered. If double-buffering is essential then this will have to drop down to MODE 5 (140x192). As there is a clean separation between game + rendering code (aux + main mem in the original) I am thinking to put game code in SHADOW RAM + MOS RAM and leave the rendering code + buffers in main RAM below the screen. This would give me at least 24k of contiguous game code & data to play with. All sprites etc. will be in sideways RAM. Something like this:

Code: Select all

beeb mem
-----
&0000 - ZP
&0100 - stack
&0200 - vectors
&0300 - system
&0400 - buffers x 1k
&0800 - sound
&0900 - buffers x 1k
&0D00 - NMI
&0E00 - rendering code + buffers
&3D80 - screen
-----
&8000 - swram bank 1 - player sprites
&8000 - swram bank 2 - player sprites
&8000 - swram bank 3 - background + level
&8000 - swram bank 4 - enemy sprites + ?
-----
&C000 - MOS
-----
shadow ram = 20K
&3000 - &8000 = game code + data
-----
mos ram = 4K
&8000 - &9000 = more game code?!
-----

I will need to load files from disc between levels so not sure about the extra filing system RAM on the Master at &C000 - &E000. Does anyone know exactly how this is used and whether any of it can be stolen without interfering with file load?

[tricky]

As I mentioned at aBUG, what do you think about mmfs only? Otherwise, I guess JGH would be a good place to start to find the minimum memory to leave untouched.
The c64 requires a particular add on.
If you draw top-down, you will have about a frame and a half.
I was also thinking about the NuLA, if you did end up with mode 2, you could use a flash colour and its identical nonflash and then use one as a highlight colour on the NuLA, but I guess, a second set of graphics will be a small addition in comparison to all the coding

[Rich Talbot-Watkins]

Some observations: the CPC version, while colourful, seems to have much more choppy animation - I suspect the reason it fits in 64k is because they dropped half the animation frames.

The Apple II version essentially does run in 4 colours (despite 6 being available, albeit with some peculiar limitations). It seems like black/white have a resolution of 280 pixels, while other colours are limited to 140.



I do like the high resolution of the characters, and certainly for porting purposes it'd be a lot easier to be able to use the same graphics. That being the case, there are undoubtedly some ways to make things a bit smaller.

Here's the Bank0 file loaded into screen memory:



There's a fair bit of redundancy there - half of it just looks like empty space (with the top bit set). I wonder if some kind of run-length encoding scheme to reduce the runs of empty space would be worthwhile. Presumably the sprites are stored row by row, while run length encoding would be best done column by column, so maybe that's not an easy option. The 1bpp Apple format is already saving you 3 bytes per pixel row, so that's a nice saving. But it really feels like there must be a reasonable way to compress that sprite data a bit more.

Given that the character sprites look like they are entirely 2 colours + transparency, is there any need to store that top bit at all? Not that it would help to fit a row into 3.5 bytes instead of 4! Or at least maybe the top bit could be used to indicate that this byte is repeated again. Might be worth processing that data blob a bit to see if anything worthwhile comes out of it.

[vanpeebles]

Different hardware but I had the gameboy version back in the day, and it was amazing. So if that can pull it off, the Master should walk it

[enthusi79]

Would not the C64 version be reasonable to consider?
https://www.c64-wiki.com/wiki/Prince_of_Persia
While it does use extensive cartridge memory for some speed code to handle bitmap gfx I believe it's coder would be willing to help with certain things.
There is a blog, too:
http://popc64.blogspot.de/

[Dethmunk]

I took up the challenge of a BBC Micro Mockup of P.o.P Check it out..... Hope you like it

[FourthStone]

Love it!

[Dethmunk]

Did a comparison with other 8bit/16bit versions.... the BBC wouldn't be doing too badly against the others... Actually the BBC version could have the Yellow flooring of the Master System version, to give it more colour. Not sure what colour scheme the NES version was going for.. LOL

[kieranhj]

I took up the challenge of a BBC Micro Mockup of P.o.P Check it out..... Hope you like it

This looks awesome John! I had set my sights on using MODE 1 (single buffered because of memory) since this is closest to Apple II hi-res screen but this is making me think again. Curiously PoP only uses 4 of the 6 possible colours in hi-res at any one time but the palette looks a lot better in orange than either BBC red or yellow.

The Apple II hi-res screen is weird as although there are technically 280 pixels across, the colour resolution is effectively 140 pixels so a lot closer to MODE 2. I didn't want to have to remake all the sprites or even convert them to BBC pixel format if I didn't have to, but then if there is offer of help then this becomes a lot less daunting...

I just moved house this week so am surrounded by cleaning products and cardboard boxes, but I will take another look back at the PoP source when I am back on the train commuting next week. Thanks for the inspiration!

[Dethmunk]

Well Hi-res Mode 1 could work... I prefer more colour, but the resolution would be nice.

[Dethmunk]

Here's a quick and dirty Mode 1 style Titlescreen too...

[tricky]

I had to zoom in and check the pixels as I couldn't believe it was mode 1. Amazing

[Dethmunk]

Its a pretty quick and dirty digitization through Image2BBC, I added the text and tidied a few pixels up. I would probably spend and fair bit of time tidying it up more for proper artwork for a game.