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

Got a programming project in mind? Tell everyone about it!
User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Starting a Prince of Persia port...

Post by kieranhj » Tue Nov 28, 2017 12:47 pm

crj wrote:I don't see any reason that would necessarily be true? Other schemes might be a bit fiddly, but they're certainly possible.

And there's no rule that says you can't have data pertaining to more than one sprite in the same byte.
Rich Talbot-Watkins wrote:My €0.02 - PoP is all about the character sprite and animation. It was pretty much the USP back in the day. It seems like a heinous crime to halve the vertical resolution (particularly since the horizontal resolution has already been compromised!). Have you thought about making different compromises, e.g. to the scenery graphics instead? Or indeed is there some way to compress those (particularly since they don't need to be plotted as part of the animation cycle if you use the pixel bit 3 as foreground flag thing). Would that claw back enough?
I do not disagree with any of the above! For my own sanity and need to press on with the port (and the ever growing list of non-graphics related things that need to get done) I am going to pause any further investigation into sprite compression. I have a not ideal but scaleable and easily reversible solution in place for now that gives me more than enough RAM to complete the work (he says optimistically.)

Having committed to double-buffering, I have some refactoring work to do to enable the gameplay code + data to reside in two different SWRAM banks. I have a plan for this thanks to the handy jump tables (effectively a DLL system) but if that doesn't work then it will be back to the drawing board anyway!

I'll give everyone an update when there is something interesting to see (like a cutscene) or hear (like some music!) As always, thanks for the ideas, suggestions and general encouragement.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Starting a Prince of Persia port...

Post by kieranhj » Wed Nov 29, 2017 2:07 pm

Heh. I got a small mention in this month's Retro Gamer magazine. I wish they'd just ping me - I'm not that hard to get hold of!!
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
Lardo Boffin
Posts: 1309
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: Starting a Prince of Persia port...

Post by Lardo Boffin » Wed Nov 29, 2017 3:51 pm

After folllowing this thread for some time I finally got round to getting a copy of Prince of Persia for my Apple IIe. Its awesome! It also doesn’t make my eyes hurt to look at unlike many other Apple games...
29B7F843-639C-4712-9488-D2B82AE78D08.jpeg
I am seriously looking forward to the Beeb version!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

User avatar
Lardo Boffin
Posts: 1309
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: Starting a Prince of Persia port...

Post by Lardo Boffin » Wed Nov 29, 2017 4:44 pm

If you need any comparisons doing between the Beeb and Apple versions and no-one else has volunteered let me know. Although it may be a while before I can test the later stuff as I am still figuring out the controls!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

User avatar
jbnbeeb
Posts: 425
Joined: Sat Apr 03, 2010 8:16 pm
Contact:

Re: Starting a Prince of Persia port...

Post by jbnbeeb » Wed Nov 29, 2017 5:29 pm

kieranhj wrote:Heh. I got a small mention in this month's Retro Gamer magazine. I wish they'd just ping me - I'm not that hard to get hold of!!
Yep just flipped to the homebrew section and there it is (I always go to that section first!) Cool that you got a mention.

Ages ago I got a mention with a WIP of biplane (sadly no review for the finished game) -- and like you the first I knew was when I opened up the magazine :) Still - it's a nice surprise isn't it? :)

Thanks for the continued updates.
I'm going to ..
ABUG Cambridge Sept 7th-9th Sept 2018
Image

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Starting a Prince of Persia port...

Post by kieranhj » Wed Nov 29, 2017 5:35 pm

Lardo Boffin wrote:If you need any comparisons doing between the Beeb and Apple versions and no-one else has volunteered let me know. Although it may be a while before I can test the later stuff as I am still figuring out the controls!
I don't have an Apple II (yet!) but from the code it appears to default to joystick control. You can select keyboard with ctrl-K and then I think the default keys are J/L/I/K for left/right/up/down and U/O for up+left and up+right. Apple key is Action.

I managed to get an Apple II emulator up & running so have seen it with my own eyes, as it were. I only ever played it on PC as a kid. :D
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Starting a Prince of Persia port...

Post by kieranhj » Wed Nov 29, 2017 5:38 pm

Since the port is getting some interest from a variety of places, I have created a landing page on our Bitshifters site: https://bitshifters.github.io/posts/pro ... -beeb.html

From now on the latest WIP for you all to try will have a consistent location rather than a new crazy name each time: https://bitshifters.github.io/jsbeeb/?d ... del=Master

I will continue to post updates and RFC's here, of course, and will let you know when there is a new WIP worth checking out. :)
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
Lardo Boffin
Posts: 1309
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: Starting a Prince of Persia port...

Post by Lardo Boffin » Wed Nov 29, 2017 10:17 pm

kieranhj wrote:
Lardo Boffin wrote:If you need any comparisons doing between the Beeb and Apple versions and no-one else has volunteered let me know. Although it may be a while before I can test the later stuff as I am still figuring out the controls!
I don't have an Apple II (yet!) but from the code it appears to default to joystick control. You can select keyboard with ctrl-K and then I think the default keys are J/L/I/K for left/right/up/down and U/O for up+left and up+right. Apple key is Action.

I managed to get an Apple II emulator up & running so have seen it with my own eyes, as it were. I only ever played it on PC as a kid. :D
Thanks - I had googled and found the controls but could not get my stupid fingers to use them properly! I suffered many a fall into a spike laden pits...
And having finally kind of got my head round running around and not dying I now have to figure out how to finish off the guards! Argh! Made it to level 2 though. Then there are two guards in a row. Doh!

I think the keyboard layout was very much an afterthought in this on the Apple - having the action key so far away from the rest of them makes life difficult in the extreme. Maybe user definable keys for the Beeb?
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Starting a Prince of Persia port...

Post by kieranhj » Thu Nov 30, 2017 8:43 pm

Lardo Boffin wrote:I think the keyboard layout was very much an afterthought in this on the Apple - having the action key so far away from the rest of them makes life difficult in the extreme. Maybe user definable keys for the Beeb?
It's on the feature suggestion list! I have added everything that I am aware of which is outstanding or bugged to the issue list on the GitHub page: https://github.com/kieranhj/pop-beeb/issues. Everyone is welcome to post any specific problems or requests directly there.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Starting a Prince of Persia port...

Post by kieranhj » Thu Nov 30, 2017 9:05 pm

No new build to share but just a quick note that my crazy "DLL" scheme worked for transparently spreading gameplay code across multiple SWRAM banks.

Because the code already has a jump table interface between code modules, I moved all of these to main RAM (above PAGE, below SHADOW) and changed the jmp opcodes to macros:

Code: Select all

\*-------------------------------
\* auto.asm
\*-------------------------------

.AutoCtrl JUMP_A AUTOCTRL, AUTO_BASE, 0
.checkstrike JUMP_A CHECKSTRIKE, AUTO_BASE, 1
.checkstab JUMP_A CHECKSTAB, AUTO_BASE, 2
.AutoPlayback JUMP_A AUTOPLAYBACK, AUTO_BASE, 3
.cutcheck JUMP_A CUTCHECK, AUTO_BASE, 4

.cutguard JUMP_A CUTGUARD, AUTO_BASE, 5
.addguard JUMP_A ADDGUARD, AUTO_BASE, 6
.cut JUMP_A CUT, AUTO_BASE, 7
Where JUMP_A macro looks like:

Code: Select all

MACRO JUMP_A name, base, index
{
    \\ Preserve X
    STX DLL_REG_X

    \\ Load function index
    LDX #(base + index)

    \\ Call jump function
    JMP jump_to_A
}
ENDMACRO   ; 3c+2c+3c = 8c + 7b overhead per fn call
And the jump_to_A function contains:

Code: Select all

.jump_to_A
{
    \\ Preserve A
    STA DLL_REG_A

    \\ Remember current bank
    LDA &F4: PHA

    LDA #6          ; hard code this aux A = 6
    STA &F4: STA &FE30

    \\ Load function address
    LDA aux_core_fn_table_A_LO, X
    STA jump_to_addr_A + 1

    LDA aux_core_fn_table_A_HI, X
    STA jump_to_addr_A + 2

    \\ Restore registers before fn call
    LDX DLL_REG_X
    LDA DLL_REG_A
}
\\ Call function
.jump_to_addr_A
    JSR &FFFF
{
    \\ Preserve A
    STA DLL_REG_A

    \\ Restore original bank
    PLA
    STA &F4:STA &FE30

    \\ Restore A before return
    LDA DLL_REG_A

    RTS
}   ; 3c+3c+3c+2c+3c+4c+4c+4c+4c+4c+3c+3c+6c+3c+4c+3c+4c+3c+6c = 69c overhead
So a hefty per-function call cycle overhead (and not insignificant per stub memory overhead) but the game seems to run OK! I guess the increase in CPU speed is enough to compensate for this and likely that the screen plot routines are dominating the frame time anyway (and are resident in main RAM.)

This only works if (non-sprite) data is either permanently resident (e.g. in HAZEL) or only accessed through a code interface - fortunately the animation frame data and sequence tables are accessed this way so can be grouped with the corresponding module.

Because the gameplay functions can be called from main RAM or from either SWRAM bank arbitrarily, the original bank has to be replaced by the caller otherwise we can return into the wrong place when these can chained together. Also there are instances where the sprite data is temporarily paged in to check the size of frames for collision detection etc. so this needs to be handled carefully.

Later on, once the memory map settles down, any function calls between code modules within the same SWRAM bank can be made direct rather than indirected through the DLL stub to save unnecessary cycles.

Obviously if you were writing a Master-only game from scratch you wouldn't add such an unnecessary overhead but it seems to be working OK and gives me lots of flexibility to continue moving code around and porting the remaining functions etc. The original Apple II code makes a nice clean separation between gameplay & rendering and uses a similar interface (main vs aux RAM) but even includes some similar extra stubs for those occasions when the game needs functions that are in an inconvenient place in RAM. It looks like Jordan ended up doing quite a bit of juggling towards the end of development as there are a few functions that are in the "wrong" code module.

Final quick question to the group - for simplicity's sake, I am thinking of changing the SWRAM handling to be hardcoded to the Master default banks 4,5,6,7 - does anyone have a reason why I shouldn't do that? At the moment there is a SWRAM check at boot and the game will barf if less than 4 are detected. It uses "slots" numbered 0-3 which will typically map to banks 4-7. Given this is Master only, would anyone have a setup with 64K SWRAM but not in banks 4-7? It would be weird to use the internal ROM slots then add the SWRAM back in a cartridge, for instance.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
trixster
Posts: 650
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

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

Post by trixster » Wed Jan 31, 2018 9:13 am

It must be time for an update, surely!?! :D
A3020 | A3000 | A420/1 | BBC B + 128K RAM/ROM + 20K Shadow + Pi0 + VideoNuLA
Master Turbo + DC + BeebSID | Atom | A4000 060 | A3000 060 | A1200 060 | A500
Atari Falcon 060 | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

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

Post by kieranhj » Wed Jan 31, 2018 9:49 am

trixster wrote:It must be time for an update, surely!?! :D
Haha! You beat me to it. Whilst I haven't posted an update in a couple of months, I have been diligently plugging away during my daily commute and added / ported:
  • Energy meters (although they look a bit wonky at the moment)
    Hit FX
    Game timer
    Princess cutscenes
    Attract sequence including title screens and self-playing demo level
But, more importantly, I have enlisted help so I have simonm porting our Bitshifters music player & converting great sounding SMS VGM tunes and Dethmunk has started work on redrawing the sprites for MODE 2. I have to say that the results are looking pretty damn amazing, even better than his original target / inspiration image that encouraged me to go down the MODE 2 route (instead of MODE 1) in the first place:
pop-beeb-dethmunk-sprites.png
Amazing new Dungeon sprites from Dethmunk!
It barely looks like a Beeb to my eyes - more like an CPC given how amazingly colourful it is. These are hot-off-the-press imported this morning. :D

There is still a stack of work to do but the end is vaguely in sight. Memory and frame-rate continue to be a constant battle but for now I want to get the rest of the functionality in & finished before the final optimisation phase. I will post a new level 1 WIP when I get chance, hopefully later today. My goal is to get the full game completed and released (at least in Beta test form) by Easter...
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
Lardo Boffin
Posts: 1309
Joined: Thu Aug 06, 2015 6:47 am
Contact:

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

Post by Lardo Boffin » Wed Jan 31, 2018 10:01 am

Blimey that looks good. =D>
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

User avatar
tricky
Posts: 2849
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by tricky » Wed Jan 31, 2018 12:54 pm

Wow, that looks great and not at all like mode 2 :)
Just what you need for a motivational boost.

User avatar
Lardo Boffin
Posts: 1309
Joined: Thu Aug 06, 2015 6:47 am
Contact:

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

Post by Lardo Boffin » Wed Jan 31, 2018 1:38 pm

I’m assuming those of us who are not members of the ‘Master race’ can never expect to see this on a beeb model B no matter how expanded it is?
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

User avatar
danielj
Posts: 6650
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

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

Post by danielj » Wed Jan 31, 2018 2:01 pm

That looks glorious! :)

d.

User avatar
Matt Godbolt
Posts: 181
Joined: Mon Jul 31, 2006 10:02 am
Location: Chicago
Contact:

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

Post by Matt Godbolt » Wed Jan 31, 2018 2:15 pm

Cripes mate that looks fantastic!

User avatar
Dethmunk
Posts: 189
Joined: Fri Jul 01, 2016 12:29 pm
Location: Guildford
Contact:

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

Post by Dethmunk » Wed Jan 31, 2018 9:51 pm

Enjoying this so far.... :-) Hope people like the graphics work. Keiran is certainly knocking it out of the ball park. Shaping up to be yet another stella BBC Micro Classic release. :wink: =D>

Another bit of cheeky graphics work...
Image
Last edited by Dethmunk on Thu Feb 01, 2018 6:30 pm, edited 1 time in total.
Image

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

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

Post by kieranhj » Wed Jan 31, 2018 10:52 pm

Lardo Boffin wrote:I’m assuming those of us who are not members of the ‘Master race’ can never expect to see this on a beeb model B no matter how expanded it is?
Unfortunately not. The original used the full 2x 64K banks on Apple II. The Master version needs all 4x 16K banks of SWRAM (64K) plus SHADOW RAM (20K) for the double-buffering plus ANDY (4K) for the music/sfx and HAZEL (8K) for level data and lookups. There is ~40K of sprite data + ~48K of code+tables + ~40K of screen buffers = ~128K.

Even with a fully expanded Model B (I have 64K SWRAM in mine) lack of proper/standardised SHADOW RAM makes it tough.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

tom_seddon
Posts: 216
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

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

Post by tom_seddon » Thu Feb 01, 2018 12:45 am

Dethmunk wrote:Enjoying this so far.... :-) Hope people like the graphics work. Keiran is certainly knocking it out of the ball park. Shaping up to be yet another stella BBC Micro Classic release. :wink: =D>
I'm going to coo solely over the graphics for a moment, if that's OK ;) - screen grab looks awesome. I had to double check that it was really just using the normal BBC palette. Amazing stuff :) I'm really looking forward to playing this!

--Tom

User avatar
Lardo Boffin
Posts: 1309
Joined: Thu Aug 06, 2015 6:47 am
Contact:

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

Post by Lardo Boffin » Thu Feb 01, 2018 6:59 am

I think I may have to get a Master for this one! And find some space to put it...
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

RobC
Posts: 2324
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

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

Post by RobC » Thu Feb 01, 2018 9:30 am

This looks amazing - can't wait to play it :D =D>

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

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

Post by kieranhj » Thu Feb 01, 2018 9:46 am

RobC wrote:This looks amazing - can't wait to play it :D =D>
The sprite engine supports any 3 colours per sprite from palette of 16 in MODE 2 so the NULA version will look unbelievable.. (more like 16-bit I reckon other than the low resolution.) But first things first, so we're getting the vanilla RGB game looking awesome (and finished.)
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

RobC
Posts: 2324
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

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

Post by RobC » Thu Feb 01, 2018 11:12 am

kieranhj wrote:The sprite engine supports any 3 colours per sprite from palette of 16 in MODE 2 so the NULA version will look unbelievable..
Brilliant - John's graphics already look amazing!

User avatar
danielj
Posts: 6650
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

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

Post by danielj » Thu Feb 01, 2018 3:44 pm

It should, theoretically, work on a B+ 128k too, shouldn't it?

d.

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

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

Post by kieranhj » Thu Feb 01, 2018 3:54 pm

danielj wrote:It should, theoretically, work on a B+ 128k too, shouldn't it?
How many B+ 128K's actually exist?! I'm guessing there are more Masters? Regardless, alas, unfortunately not.

The 12K of contiguous RAM would appear to be more useful than ANDY + HAZEL on the Master but then HAZEL has the advantage of being paged in above the SWRAM area at &C000 so available to code running from those paged banks. I am taking advantage of that property for permanently resident data, most notably &900 bytes of level data.

In addition you can't display one SHADOW RAM bank whilst writing to the other one on a B+ only a Master. From the NAUG:
bplus shadow.png
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

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

Post by crj » Thu Feb 01, 2018 4:56 pm

Lardo Boffin wrote:I think I may have to get a Master for this one! And find some space to put it...
Well, if my project actually works, and one of the possibilities it opens up is to let a model B to behave like a Master, and the Prince of Persia port drives a few more sales in my direction, I won't complain. (-8<

User avatar
lurkio
Posts: 1781
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

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

Post by lurkio » Thu Feb 01, 2018 5:54 pm

Matt Godbolt wrote:Cripes mate that looks fantastic!
kieranhj wrote:The Master version needs ...
Looks fantastic! Will you be keeping an eye on JSBeeb compatibility too, Kieran? Don't know if this applies to PoP, but one sticking point might be write-access to disc, which JSBeeb still doesn't support -- although if Matt were to find the time to implement it, it would benefit another recent game, White Light, too. (Hint, hint!)

:?:

User avatar
Lardo Boffin
Posts: 1309
Joined: Thu Aug 06, 2015 6:47 am
Contact:

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

Post by Lardo Boffin » Thu Feb 01, 2018 6:08 pm

crj wrote:
Lardo Boffin wrote:I think I may have to get a Master for this one! And find some space to put it...
Well, if my project actually works, and one of the possibilities it opens up is to let a model B to behave like a Master, and the Prince of Persia port drives a few more sales in my direction, I won't complain. (-8<
Sounds like an interesting project. :D
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Viglen twin 40/80 5.25" discs, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master, Datacentre + HDD, pi co-proc

User avatar
kieranhj
Posts: 726
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

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

Post by kieranhj » Thu Feb 01, 2018 6:18 pm

lurkio wrote:Looks fantastic! Will you be keeping an eye on JSBeeb compatibility too, Kieran? Don't know if this applies to PoP, but one sticking point might be write-access to disc, which JSBeeb still doesn't support -- although if Matt were to find the time to implement it, it would benefit another recent game, White Light, too. (Hint, hint!)
Don't worry, whilst I develop on b-em, I test on jsbeeb pretty much every day when sharing WIP's with my co-collaborators. The only compatibility issue I'm aware of is that it doesn't work with a DataCentre at the moment (discovered at ABUG) almost certainly because I'm trampling all over HAZEL. I have a DC so will debug this towards the end of the project once the memory map has settled down.

I haven't implemented the save game yet but is on the list. It will likely work in the same way as the Apple II version so a single file overwritten on the game disc (no filename entry) so will require write access (and error handling :?).
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

Post Reply