Jump to content
IGNORED

Unicorns season: Prince of Persia for the A8!


rensoup

Recommended Posts

1 hour ago, Nickolasgaspar said:

You are welcome and it's my pleasure.

Only the 610 and 619_bugfix  files appear to have this loading issue with my machine. All previous releases  work fine.

 

But what's the loading speeds like? The problem with the earlier releases is sector re-reads due to loading animations, resulting in loading speeds slower than standard SIO.

Link to comment
Share on other sites

10 hours ago, rensoup said:

Yeah I did mention several times in the last few pages that I added a blue screen for file not found errors, with a screenshot too... You could have saved yourself the trouble if you'd read my posts ...

I don't know why you're assuming I wasn't aware of this, and I fail to see what trouble I would have saved. It took 10 seconds to document the venetian blind effect with a photograph, and about twenty minutes to use the Turbo Freezer to figure out what was going on with the infinite loop (the location of which I didn't see documented anywhere else, and Mark thought the TF debug info worth posting).

 

EDIT: Since the game takes so long to load, a disucssion regarding 'time saving' strikes me as especially ironic, BTW. :)

10 hours ago, rensoup said:

Well, thanks for telling me that my infinite loop would not be able to carry on. 

Right. Well, after Mark took the trouble to reach out the other week via PM, I really appreciated the fact that the PoP cartridge images exposed some issues with cartridge emulation in the SIDE3 loader. Then, yesterday, when I decided to run the PoP ATRs on a freshly upgraded XE here and noticed issues which could be replicated on my own 600XL, I spoke to Mark again and we agreed that I would post some of my findings on the thread here in case the information was of any use (which it appeared it might be, judging by the fact even XXL indulged in a constructive dialogue). However, all this appears to have accomplished is to elicit snotty, supercilious responses from you which confirm that I am completely wasting my time here. If I find anything else I think might be of use, not only will I not post it here, but I won't even send Mark a PM about it. Good luck!

Edited by flashjazzcat
  • Like 1
  • Confused 1
Link to comment
Share on other sites

6 hours ago, Mazzspeed said:

But what's the loading speeds like? The problem with the earlier releases is sector re-reads due to loading animations, resulting in loading speeds slower than standard SIO.

 

10 hours ago, rensoup said:

Thanks for testing!

By older versions, you mean the 2020 ones ? not the previous not-fixed 2021 version ?

So here is a video of the loading process. As you will see at Sector 646 there is a shift in  loading speed and level of sound drops dramatically.

At Sectors 385, 91, 111, 114, 147, 363 and 364 you can see the attempted retries.

Generally I can hear noise and parasites that the screen matches FJC's. Sometimes I get a black screen.

Notice that the weird sounds  in the background are my finches singing....not my 800xl lol!

 

 

 

 

 

Link to comment
Share on other sites

2 hours ago, Nickolasgaspar said:

So here is a video of the loading process. As you will see at Sector 646 there is a shift in  loading speed and level of sound drops dramatically.

That's just XBIOS taking over

2 hours ago, Nickolasgaspar said:

At Sectors 385, 91, 111, 114, 147, 363 and 364 you can see the attempted retries.

Generally I can hear noise and parasites that the screen matches FJC's. Sometimes I get a black screen.

Notice that the weird sounds  in the background are my finches singing....not my 800xl lol!

 

Interesting... ( is it possible to copy those reports as text ? not this one but for future ones )

 

First, directory reading is quite slow... it's obvious but once you see it, it's a little scary! I'll probably look into caching the directory at some point.

 

Now, regarding crash... 

 

1. loads XBIOS.COM (from sector 637 to 646)

 

2. loads LAUNCHER.OBX (from sector 385 to 391)

 

Note: at this point it's read the full directory twice: 16 sectors, almost as much as the 2 files above together ! Need to put those on 1st directory sector...

 

3.loads POPCORE.BIN (from 461 to 560)

 

4.loads PMGOVL.BIN (from 457 to 460)

 

5.loads FONTOVL.BIN (from 370 to 379)

 

6.loads CH1.DTA (from 75 to 94)

 

7.loads CH2.DTA (from 108 to 114) 

 

PROBLEM! the file is 19 sectors long, the log reports the first 3x retries in a row at sector 114!

That file will not decompress properly... possibly decompressing past its boundaries and corrupting memory?

 

8.loads CH3.DTA (from 137 to 150)

 

9. PROBLEM! the directory is read for the next file and the log reports another 3x retry on directory sector 364 and the game reports a file not found !

 

Could it be that there's an issue with more than 1 retry  ?

 

 

btw: I don't know if you saw it but I posted another test release:

 

Quote

 

 

 

 

 

Edited by rensoup
Link to comment
Share on other sites

1 hour ago, candle said:

why anyone would ran into retry?

the only explanation there is, is software running into serial overrun situation - too busy to receive a char while doing something else

 

 

14 hours ago, rensoup said:

 

New test version, I only reduced the mouse icon because it was possibly taking a little too much time... I doubt that's the problem but I'm wondering why there are retries...

pop_DD_fastishmouse_notplayable.zip 147.67 kB · 5 downloads

 

I've been quoting myself a lot lately...

Link to comment
Share on other sites

I've just tried it on MiSTer. The game mostly loads ok, but sometimes goes into some sort of blue screen. In-game all seems fine, but I only got as far as few screens in. Much as I love PoP, I suck at it totally - it's also a good example of why I consider up-for-jump as the curse of 8-bit gaming :)

 

Overall it seems like a very nice port, the gameplay is sound and it's looking very good too (especially on my CRT).

  • Like 1
Link to comment
Share on other sites

27 minutes ago, rensoup said:

oops ? why not keep retrying ?

 

edit: so that would be the explanation... if anyone could confirm that the fastish_mouse version works ?

Just tried it on my NTSC Incognito 800 - loads fine and the demo routines made it 51 minutes before it crashed with the same blue screen/animated mouse reported earlier by myself and others.

  • Like 1
Link to comment
Share on other sites

3 hours ago, rensoup said:

That's just XBIOS taking over

 

Interesting... ( is it possible to copy those reports as text ? not this one but for future ones )

 

First, directory reading is quite slow... it's obvious but once you see it, it's a little scary! I'll probably look into caching the directory at some point.

 

Now, regarding crash... 

 

1. loads XBIOS.COM (from sector 637 to 646)

 

2. loads LAUNCHER.OBX (from sector 385 to 391)

 

Note: at this point it's read the full directory twice: 16 sectors, almost as much as the 2 files above together ! Need to put those on 1st directory sector...

 

3.loads POPCORE.BIN (from 461 to 560)

 

4.loads PMGOVL.BIN (from 457 to 460)

 

5.loads FONTOVL.BIN (from 370 to 379)

 

6.loads CH1.DTA (from 75 to 94)

 

7.loads CH2.DTA (from 108 to 114) 

 

PROBLEM! the file is 19 sectors long, the log reports the first 3x retries in a row at sector 114!

That file will not decompress properly... possibly decompressing past its boundaries and corrupting memory?

 

8.loads CH3.DTA (from 137 to 150)

 

9. PROBLEM! the directory is read for the next file and the log reports another 3x retry on directory sector 364 and the game reports a file not found !

 

Could it be that there's an issue with more than 1 retry  ?

 

 

btw: I don't know if you saw it but I posted another test release:

 

 

 

 

 

NO I didn't notice the post of that additional test release. I just downloaded it  and I will try it asap.

Those reports  can be copied as text! What I can do is copy multiple attempts as text  so we can compare them. (they will be really long but the [x#] will make the job easy)

Edited by Nickolasgaspar
text correction
  • Like 1
Link to comment
Share on other sites

15 minutes ago, Nickolasgaspar said:

(they will be really long but the [x#] will make the job easy)

Please hide them with the forum's Spoiler tag option. That will keep people from having to scroll through a giant wall of information when just browsing the thread.

  • Like 1
Link to comment
Share on other sites

1 hour ago, rensoup said:

oops ? why not keep retrying ?

 

edit: so that would be the explanation... if anyone could confirm that the fastish_mouse version works ?

Just tried it again on a different machine and different FujiNet device - my NTSC 576NUC+ beta machine with Mytek's custom FujiNet daughterboard. The game loads and runs, and just crashed after 45 minutes with the Blue Mouse of Death. 

  • Like 1
Link to comment
Share on other sites

For the record, I'm running the game now on my NTSC 1200XL+U1MB via external FujiNet. I'm also capturing FujiNet's serial debug info. It will be a massive text dump. I will post it here behind Spoiler tags, and probably also just zip up a text file of the data and post it as well once the game crashes.

  • Like 2
Link to comment
Share on other sites

1 hour ago, rensoup said:

oops ? why not keep retrying ?

 

edit: so that would be the explanation... if anyone could confirm that the fastish_mouse version works ?

A ran the following tests.

 

I loaded "pop_DD_fastishmouse_notplayable.atr" demo twice. It loaded without  any issues!

In both attempts there is only one retry at the same sector ([Disk 1] Read Sector 385 ($181) #7 in track 21 ($15) [x2])

 

I tried to load  "PoP_DD_20210619_bugfix"  6 times. Only one was successful and only after I skipped the loading of the demo!

Here are the logs. I inserted spaces at every retry so you can easily spot them. I have details in every file on what were the issues.

 

pop_DD_fastishmouse_notplayable_loading list A.txt pop_DD_fastishmouse_notplayable_loading list B.txt Prince of Persia20210619_bugfix _ A log.txt Prince of Persia20210619_bugfix _ B log.txt Prince of Persia20210619_bugfix _ C log.txt Prince of Persia20210619_bugfix _ D log.txt Prince of Persia20210619_bugfix _ E log.txt Prince of Persia20210619_bugfix _ F log.txt

  • Like 2
Link to comment
Share on other sites

1 hour ago, DrVenkman said:

For the record, I'm running the game now on my NTSC 1200XL+U1MB via external FujiNet. I'm also capturing FujiNet's serial debug info. It will be a massive text dump. I will post it here behind Spoiler tags, and probably also just zip up a text file of the data and post it as well once the game crashes

Thanks, a zip would be fine I think.

39 minutes ago, Nickolasgaspar said:

I loaded "pop_DD_fastishmouse_notplayable.atr" demo twice. It loaded without  any issues!

In both attempts there is only one retry at the same sector ([Disk 1] Read Sector 385 ($181) #7 in track 21 ($15) [x2])

 

Well it looks like that was the problem: the mouse icon being too slow which messed up the XB polling loop. I'm not sure if there's an issue with respeqt when retry errors occur...

 

You can move the mouse left and right with the stick. In the next version I will check that if it's outside a certain zone, I will stop displaying it... so hopefully that should completely avoid those crashes after 50+ minutes.

 

Thanks again for testing

 

Edited by rensoup
  • Like 1
Link to comment
Share on other sites

52 minutes ago, rensoup said:

Thanks, a zip would be fine I think.

Will do. As luck would have it, the game has been running for about 75 minutes without issue. Figures - once I actually drag my computer over to my retro-desk and start logging data ... Anyway, if/when it crashes, probably only the last few dozen sector reads will be of any interest. Much of the data being logged over USB to the modern computer is TNFS server stuff for the code running on the ESP32 board - the Tiny Network File System server program that FujiNet uses to serve up ATR, ATX, CAS and XEX file data can live on a PC, Mac, or Linux box. I've got it running on a headless Pi Zero W sitting on my retro desk.

 

EDIT: Well, the demo has now been running over 2 hours since the boot process started and no crash on the 1200XL. Got no clue why it's been able to run right now so long on this machine compared to the other two. I've captured a LOT of FujiNet serial data but it doesn't seem to matter at this point. I'll try to run this same test again later over the weekend and see if I can capture a crash from one of the other machines.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...