Prince of Persia

[RobC]

I wonder if a Master emulator for the Pi co-pro would be an option. It might be possible to overcome the lack of (displayable) shadow screen by getting the Pi to do the heavy lifting and only send differences across the Tube...

This isn't as outlandish as it first sounded to me. The game spends a lot of cycles when plotting the screen that don't necessarily end up changing that many screen bytes (ultimately.) E.g. every frame the player is removed and plotted (and the underlying background data saved) regardless of any movement. The game tries to avoid redrawing things that aren't necessary but it's still at quite a coarse level (10x3 blocks) and is designed to always be "correct" so will plot many things overlapping from back-to-front to achieve the perspective effect.

I've only played through level 1 so far but it does look like it might work. It's such a great game and a wonderfully polished conversion that it would be great to have it available to owners of Bs and B+s too.

I might look into it over the next couple of weeks unless someone else wants to give it a shot?

[pau1ie]

Do you have *DTRAP enabled whilst running from RAM drive?

No

I do now and, surprise, it works! Thanks!

Edit: Also works in the multi OS (3.20 selected obviously)

[jms2]

I've dusted off the Master now, and I've been suitably blown away by how impressive and beautiful it is! My two boys played it for most of the afternoon and nearly completed Level 2.

I'm running it from MMFS and, as mentioned, I needed to *UNPLUG 9 otherwise it hangs to a black screen during the loader. I can't imagine why sbadger didn't need to do this.

We did find that it crashed, once on the real machine and once on BeebEm. The crashes didn't seem to be repeatable. I can upload a savestate.

[kieranhj]

the game slowed down a lot for the duration of the music. ... then it crashed when I ran through the door that triggers the ending cinematic.

Once again, here are ZP and the stack:

Code: Select all

0100  a1 a1 90 ed f9 ee 30 a1  ......0.
0108  3d 8f 21 8c ca 8b 1c 94  =.!.....
0110  df 93 94 82 00 27 82 df  .....'..
0118  87 1e 84 02 ed ff 8c ff  ........
0120  1c 80 1d ff 51 fa 18 17  ....Q...
0128  48 18 5b 18 df 28 04 a7  H.[..(..
0130  1e 57 1d a0 24 f1 21 44  .W..$.!D
0138  21 8e 22 dc 21 44 21 8e  !.".!D!.
0140  22 dc 21 44 21 44 21 8e  ".!D!D!.
0148  22 dc 21 44 21 8e 22 dc  ".!D!.".
0150  21 44 21 8e 22 dc 21 44  !D!.".!D

Hmm, the bottom the stack here on line 0128 is calling the audio load bank routines which goes down into the disk system and eventually calls OSFILE with filename Audio4, which is consistent with exiting the level and heading into a cutscene.

I'm imagining that the slowdown you experienced was the continual crashing and re-entering through the error handler. Did you use the save game system at all (CTRL-G) during your playthrough?

I've just found and fixed a definite memory scribble that was reported by David on the Princed forum. This was due to the fact that I missed an instance in which the original source used an overloaded label for both a variable and a function name, as was permitted in the assembler that Jordan used but obviously not in BeebAsm. I will make a test build and upload it somewhere for you to try, if you don't mind playing through (yet) again sometime please?

[kieranhj]

I've dusted off the Master now, and I've been suitably blown away by how impressive and beautiful it is! My two boys played it for most of the afternoon and nearly completed Level 2.

Thank you. It is quite difficult though, they don't make them like that (hard) any more!!

I'm running it from MMFS and, as mentioned, I needed to *UNPLUG 9 otherwise it hangs to a black screen during the loader. I can't imagine why sbadger didn't need to do this.

I will add to the technical support notes for v1.1

We did find that it crashed, once on the real machine and once on BeebEm. The crashes didn't seem to be repeatable. I can upload a savestate.

Yes please! Any extra debug information is immensely helpful.

[tricky]

I am very tempted to have a go at porting it to the B+128 with my BooBip OS+30K module.
I'm convinced that enough RAM on the B would do it, but having it mapped without having to unmap anything else is attractive.
I'll probably never get around to it and as Pi copros are more common, I'll probably just wait for Rob

[kieranhj]

Once again, here are ZP and the stack:

Code: Select all

0100  a1 a1 90 ed f9 ee 30 a1  ......0.
0108  3d 8f 21 8c ca 8b 1c 94  =.!.....
0110  df 93 94 82 00 27 82 df  .....'..
0118  87 1e 84 02 ed ff 8c ff  ........
0120  1c 80 1d ff 51 fa 18 17  ....Q...
0128  48 18 5b 18 df 28 04 a7  H.[..(..
0130  1e 57 1d a0 24 f1 21 44  .W..$.!D
0138  21 8e 22 dc 21 44 21 8e  !.".!D!.
0140  22 dc 21 44 21 44 21 8e  ".!D!D!.
0148  22 dc 21 44 21 8e 22 dc  ".!D!.".
0150  21 44 21 8e 22 dc 21 44  !D!.".!D

Hmm, the bottom the stack here on line 0128 is calling the audio load bank routines which goes down into the disk system and eventually calls OSFILE with filename Audio4, which is consistent with exiting the level and heading into a cutscene.

Hmmm, I've just stepped through the OSFILE code in b-em and the stack can get at least &2E deeper than when it was called. If the call here took place when the stack was &28 then we'd overflow and presumably the load would fail. (Does anyone know the actual max stack depth from an OSFILE call BTW?)

I'm guessing the real problem is higher up with the suspicious looping call stack that's repeatedly coming back into the MainLoop. But why...

[dp11]

The 6502 co pro on PiDirectTube there is also the option of of extra banked RAM (1Mbyte)

[hoglet]

Hmmm, I've just stepped through the OSFILE code in b-em and the stack can get at least &2E deeper than when it was called. If the call here took place when the stack was &28 then we'd overflow and presumably the load would fail. (Does anyone know the actual max stack depth from an OSFILE call BTW?)

Just a thought... if the stack did overflow due to the OSFILE then it would just wrap around. The OSFILE would most likely succeed, but entries rights at the top of the stack would be trashed.

[kieranhj]

For anyone interested, I've done a quick build to fix the known scribble (not an official release!), you can test it here: https://bitshifters.github.io/jsbeeb/?d ... del=Master

Or download the image: https://bitshifters.github.io/content/w ... le-fix.ssd

I still haven't determined if this is causing the dodgy stack pattern (this was also present in the report from jms2) but is certainly bad and executing random code on occasion which may or may not result in a crash. Let me know what you find if you are able to test.

Thanks folks!

[Norbert]

Version 0.9b of my leapop level editor has support for kieranhj's BBC Master port.
- for Windows: leapop-0.9b-win32.zip (mirror)
- for GNU/Linux: leapop-0.9b.tar.gz (mirror)
There's still room for improvement, of course.

[Diminished]

Did you use the save game system at all (CTRL-G) during your playthrough?

No, I didn't.

I've just found and fixed a definite memory scribble that was reported by David on the Princed forum. This was due to the fact that I missed an instance in which the original source used an overloaded label for both a variable and a function name, as was permitted in the assembler that Jordan used but obviously not in BeebAsm.

Ouch, yeah, that's the sort of thing that is always a nightmare to track down.

I will make a test build and upload it somewhere for you to try, if you don't mind playing through (yet) again sometime please?

Sure, I can keep going. My completion times aren't good enough yet anyway. I'll stick to b-em from now on.

[Norbert]

For anyone interested, I've done a quick build to fix [...]

Let me know what you find if you are able to test.

Played through the game with pop-beeb-scribble-fix.ssd, and didn't run into a crash.
I think there was one guard who changed colors when he died, but that was about it.
Tried Ctrl+g, gave me a "disk write error!", but that's probably just my setup.
Some of the music during the princess cutscenes sounded as if maybe it was the tune that's normally used for when time has almost ran out (even though it had not) - but I'm not sure.

[sbadger]

I've been playing with a MMFS in 8 but never bothered unplugging 9. It works fine. It may be that i've *CO.FILE 8 set

This is very weird....

I've just double checked (three times) and on my Master it definitely hangs if I don't unplug DFS.

I'm also using *CONFIGURE FILE 8.

What version of MMFS are you using?

Sure, is there a way to check from the machine?

[Diminished]

OK! Four more playthroughs (on the test build this time), and it crashed on the final one. But I got the receipts!

This is a b-em 2.2 savestate:

popsavestate.zip

(145.01 KiB) Downloaded 85 times

Before I started, I had the sense to patch the emulator to allow me to save state from its debugger -- so I was able to dump the state right on the BRK, before the error handler was called.

[hoglet]

What version of MMFS are you using?

Sure, is there a way to check from the machine?

*HELP should show you.

Can you also double check with *ROMS that DFS really is present.

One last question (in case it makes a difference) is do you have a floppy drive attached?

[sbadger]

What version of MMFS are you using?

Sure, is there a way to check from the machine?

*HELP should show you.

Can you also double check with *ROMS that DFS really is present.

One last question (in case it makes a difference) is do you have a floppy drive attached?

It's v1.36, ROM 9 is there and inserted. No Floppy Drive installed.

[kieranhj]

OK! Four more playthroughs (on the test build this time), and it crashed on the final one. But I got the receipts!

This is a b-em 2.2 savestate:

popsavestate.zip

Before I started, I had the sense to patch the emulator to allow me to save state from its debugger -- so I was able to dump the state right on the BRK, before the error handler was called.

Wow! You are POP playing machine. Thank you this is very helpful.

I gave you a debug build so this crash is effectively an assert to say the game has run out of RAM to store the screen buffer behind the moving sprites - this screen on level 13 is the worst one in the entire game because of all the ceiling tiles dropping the same time. I'd painfully upped the buffer sizes as far as I could take them even though the rest of the game doesn't get close to filling the buffer. I don't think there's much I could do about this one - it won't crash in Release but will probably corrupt the screen a little bit. I might make it more explicitly not corrupt but abort the store/restore.

The save state is very helpful though as it proves the weird stack issue is still there even after fixing the memory scribble. I am busy with RL today but when I get chance I'll make another special build to assert that the code has exited the function that doesn't seem to be being exited! Quite mysterious. I'll post that as soon as it's ready to test.

Thanks again for your help.

[Diminished]

Ah, yes. I suppose it's because the tile hits the Prince. I have a bad habit of charging through these two "stone rain" rooms and trying to see if I can get past them without getting hit. Because the clock never stops.

I had a look at the stack and it did seem like it suffered from the usual corruption. So if it's not explicitly caused by running out of RAM in this room, are you suggesting that the corruption is an artifact? Something that may have happened at any time previously during gameplay, but the vestiges of the mess remain visible on the stack?

I had an idea of my own, which was to modify the emulator to constantly scan for the beginnings of the bad pattern on the stack, and then drop into the debugger as soon as it sees the first instance of it. I don't know if this would help. I guess it wouldn't catch it early enough to figure out exactly why it happens, but it might be instant enough to provide a clue as to what sort of in-game action leads to it. I'll try it if I get the chance, although I also have other things I should be doing.

[SteveF]

Tried Ctrl+g, gave me a "disk write error!", but that's probably just my setup.

The emulator you're using is probably write-protecting the disk by default. There is probably an option in the file menu to enable writes, and if you look under settings there is probably an option not to write-protect by default to save you needing to re-enable writes every time you select a new disk image.

[sbadger]

I've dusted off the Master now, and I've been suitably blown away by how impressive and beautiful it is! My two boys played it for most of the afternoon and nearly completed Level 2.

I'm running it from MMFS and, as mentioned, I needed to *UNPLUG 9 otherwise it hangs to a black screen during the loader. I can't imagine why sbadger didn't need to do this.

We did find that it crashed, once on the real machine and once on BeebEm. The crashes didn't seem to be repeatable. I can upload a savestate.

The only other thing is what position have you got the ssd on the beeb.mmb? Ive put it in pos zero 0

[Diminished]

I think I have it. Every time you die and press enter to restart the level, the stack pointer starts 6 bytes lower than it did last time the level was loaded.

Logic suggests this isn't a sustainable situation.

[hoglet]

The only other thing is what position have you got the ssd on the beeb.mmb? Ive put it in pos zero 0

That's very likely to be it - I'll confirm later.

[kieranhj]

I think I have it. Every time you die and press enter to restart the level, the stack pointer starts 6 bytes lower than it did last time the level was loaded.

Logic suggests this isn't a sustainable situation.

You sir, are a star! I will investigate this finding later on and compare against the original source. Thank you.

[Diminished]

I think I have it. Every time you die and press enter to restart the level, the stack pointer starts 6 bytes lower than it did last time the level was loaded.

Logic suggests this isn't a sustainable situation.

You sir, are a star! I will investigate this finding later on and compare against the original source. Thank you.

OK, it may only apply to certain types of deaths, maybe only when you die very early on? I'm not 100% sure. Hypothesis: the "minutes remaining" line that appears at the start of every level -- what happens if you die before it gets a chance to appear? Does that cause something to be stacked? Because if you're dozy like me and you die repeatedly at the very start of Level 7, that text won't appear -- goes straight from "Level 7" to "Press Action".

It does seem to be something along these lines though.

EDIT: scratch that, getting killed repeatedly by the guard on Level 1 messes up the stack just as well, and all the text has time to appear in this case, so it's not that; it's something else.

EDIT 2: in the 1.0 build, there's a JMP &2055 situated at &2501 which looks like the culprit, doing a jump into a routine without fixing the stack first. I tried inserting this nasty hack into b-em's m65c02_exec():

Code: Select all

if (pc == 0x2501) {
    printf ("FIXING STACK\n");
    pull(); pull(); pull(); pull(); pull(); pull();
}

Then I turned the emulator speed up to 500% in order to die and restart very quickly many times at the start of Level 7. It seems to stop the stack overflow and the game still seems to run, but I've done no proper testing, so there may be some evil side effects of just putting a bunch of PLAs in I don't know about.

[kieranhj]

EDIT 2: in the 1.0 build, there's a JMP &2055 situated at &2501 which looks like the culprit, doing a jump into a routine without fixing the stack first. I tried inserting this nasty hack into b-em's m65c02_exec():

Winner winner, chicken dinner!

This is the call to RESTART that happens in the ctrlplayer fn in topcrl.asm after the player has died and pressed action to continue.

I went back to the buildable Apple II source on GitHub (Jordan's original source as posted is not fully buildable as it has various files missing) and there is reference to a patch that was applied to the disc after the source was finished: https://github.com/adamgreen/Prince-of- ... CTRL.PATCH

Code: Select all

+++ b/obj/TOPCTRL.PATCH.S	2013-03-18 16:41:58.000000000 -0700

@@ -261,6 +261,9 @@
  jsr reloadblue
  else

+ ldx #$ff ;Reset stack pointer at level start
+ txs
+ 

  lda #" "
  jsr lrcls
  jsr vblank

So it appears this bug was present in the original source and the fix is to reset the stack pointer at the top of the RESTART function. I will make a new build shortly with this and the previous scribble fix in and that will stand as a V1.1. There are some other feature requests (mostly around compatibility with other file systems) and a couple of minor graphics bugs that were missed but these can wait for a V1.2.

Thanks again for your help tracking this down.

[kieranhj]

I`ve pushed a v1.1 build to GitHub so should now be on the POP page on our Bitshifters site: https://bitshifters.github.io/posts/pro ... -beeb.html.

This should fix the known crashes. I'll ponder the other requests and issues over the coming week.

If you experience any more crashes or other bugs please let me know and feel free to file at https://github.com/kieranhj/pop-beeb/issues

Thanks all!

[jms2]

I've dusted off the Master now, and I've been suitably blown away by how impressive and beautiful it is! My two boys played it for most of the afternoon and nearly completed Level 2.

I'm running it from MMFS and, as mentioned, I needed to *UNPLUG 9 otherwise it hangs to a black screen during the loader. I can't imagine why sbadger didn't need to do this.

We did find that it crashed, once on the real machine and once on BeebEm. The crashes didn't seem to be repeatable. I can upload a savestate.

The only other thing is what position have you got the ssd on the beeb.mmb? Ive put it in pos zero 0

Could be that... mine is in position 276!

[FourthStone]

Well how embarrassing I'd been playing the DSD which I must of downloaded a week before the official release... I thought some of the music and other things were a bit off but just thought it was limitations of the beeb.

Have now downloaded the latest 1.1 SSD and completely blown away by how much more polished it is, especially the intro cut scenes and sound effects

One little annoying bug or it may just be my misunderstanding is that forward jump sometimes just does a forward walk instead. If standing at an edge and wanting to just attempt the jump which in some situations is the only way to proceed, occasionally he will just walk instead of jump usually to his death.

It's not all the time but it seems to happen at particular locations such as on level 2 when doing a standing jump left across the chasm down to a lower platform with the guard waiting, Prince will consistently walk straight of the ledge to his death when pressing the forward jump key and standing right up to the edge. If standing a little further back sometimes he will jump and sometimes just walk of the edge.

I can perform the same jump by pressing left+jump but this combo does not always trigger at the same time so I prefer the forward jump key for these types of jumps. BTW I'm playing using beebEm 4.14

Anyway, small bug in an otherwise amazing game which I have been loving re-learning all the puzzles and hidden treasures

[lurkio]

I'm trying to get a TurboMMC- and Master-compatible version of the MMFS ROM to Chinny of the ChinnyVision channel on YouTube so that he can review Prince of Persia on his Master 128 with (I think) IFEL MultiOS.

Would anyone be up for blowing the T/MAMMFS (I think) version of MMFS to EPROM and sending it to him?



[Cross-posted here: viewtopic.php?f=3&t=10621&p=199588#p199588]