Unicorns season: Prince of Persia for the A8!

[rensoup]

2 hours ago, Mathy said:

Hello Mario

 

 

A developer can never test his or her software on every piece of hardware.  Rensoup doesn't even have a real Atari.  So he might never find the bugs in his software.  I don't see how not telling him which bugs people run into helps in any way.

 

Sincerely

 

Mathy

 

Since we're stuck in an infinite loop until the next release I guess, I'll just repeat what I said before...

 

While it's true there were potential crash issues with PoP and a real speed issue which AA members helped uncover, the real crashes were/are due to the different storage devices/configs, not with the loader.

[rensoup]

2 hours ago, FifthPlayer said:

Thank you rensoup, TIX, miker and emkay (did I leave anyone out?) for this really wonderful port of PoP.

You forgot Vinscool who did the initial batch of tunes! And dmsc & XXL,... (full credits list is in the first post)

 

Thanks all!

[Mazzspeed]

55 minutes ago, Wrathchild said:

I'm getting a Voldemort complex ?

Not at all, what you did was fantastic. I was going to do it, but I believe developers should be able to reach out to other developers when there's an obvious issue. Ego's are what's holding the Atari community back, I've honestly never seen anything like it in any other retro community.

[shoestring]

1 hour ago, Mazzspeed said:

Ego's are what's holding the Atari community back, I've honestly never seen anything like it in any other retro community.

Still not even half as bad as what's happening in the Amiga community.

[Mazzspeed]

53 minutes ago, shoestring said:

Still not even half as bad as what's happening in the Amiga community.

This isn't really the place for such discussion TBH.

 

All I'll say is the only issue I've seen in the Amiga community is an individual that doesn't completely understand how open source works. Which was a shame, as he is a really great developer and I followed his progression right through to the end - Even I thought the whole idea was to design a device anyone could build. It was like his perspective changed once his design began to grow in popularity.

 

Edited July 14, 2021 by Mazzspeed

[shoestring]

Hence why that particular community is so fragmented.

 

Atari community doesn't really suffer from such fragmentation. Although smaller than  most others, theres still lots of cool stuff happening and getting done despite some opposition.

[Mazzspeed]

39 minutes ago, shoestring said:

Hence why that particular community is so fragmented.

 

Atari community doesn't really suffer from such fragmentation. Although smaller than  most others, theres still lots of cool stuff happening and getting done despite some opposition.

You're welcome to surmise my opinion on that. That's as much as I'm willing to say...

[xxl]

The authors of such hits as SCR or PoP will always be remembered as the ones who brought milestone games to the Atari, and the trolls making a fuss will not be remembered in a year ?

[+DjayBee]

7 hours ago, Mazzspeed said:

Ironic, as both games had something in common...

 

 

19 minutes ago, xxl said:

The authors of such hits as SCR or PoP will always be remembered as the ones who brought milestone games to the Atari, and the trolls making a fuss will not be remembered in a year ?

 

You both cannot stop.

Can you?

 

*sigh*

[zbyti]

To be retro programmer you must be utterly stubborn

[+DjayBee]

33 minutes ago, zbyti said:

To be retro programmer you must be utterly stubborn

I second that but sitting in a sandbox and destroying the other toddler's sand castle just because, is a very specific type of stubborness.

[youxia]

[rensoup]

So I finally stopped using DIR2ATR  and I'm now creating ATRs directly which allows me to bypass reading the directory for every file.

 

I tested it with Altirra (no SIO patching and accurate sector timing), loading until it reaches the intro text screen.

 

previous version: 1min 16s vs new version: 1min 01s

 

20% improvement... not bad even though I hoped it'd be better. It also saved me 200 bytes because I was able to simplify the loading code.

 

It will not report any loading error (NO blue screen), because there doesn't seem to be any error report when using XBIOS_LOAD_DATA (  @xxl C is always set ? )

 

 

I attached it to the 1st post

Quote

test release without a full directory for better loading speed (unplayable)

I'd be curious to know what the improvements are on real HW...

 

[rensoup]

I also tried looking into the rotational latency as indicated in the Altirra manual...

 

For optimum loading, the sectors should be spaced 9 to 15 units apart, so I tried it with a single file but it actually made things a lot worse.

So I'm not sure if the sectors should be 9 to 15 units apart on the same track ? Doesn't seem to make sense but you never know...

 

For instance if you have a 5 sector file starting at sector 36. Which one should it be ?

1. 36, 36+9*1, 36+9*2, 36+9*3, 36+9*4

2. 36, 36+(9*1)%18, 36+(9*2)%18, 36+(9*3)%18, 36+(9*4)%18 (making sure the sector is free of course, otherwise keep adding 1 until a free sector is found)

 

 

[Faicuai]

2 hours ago, rensoup said:

For optimum loading, the sectors should be spaced 9 to 15 units apart,

Fyi, experimented with this on Indus/GT (with SSM code uploaded first from SDX).

 

It turns out that the best, smoothest load (sector-by-sector, no sector-misses) I could get was to by formatting with SDX utility, and selecting "high-speed" (CORRECTION: STANDARd-speed format) and SDX-optimized modes, and then issuing a {X HDSC -C=700 Dn: Dm:} at command prompt (where Dn: is source .ATR with bug-fix, and Dm: is Indus/GT destination, with magnetic-media and SSM pre-loaded).

 

The final loading tests were performed OUTSIDE of SDX environment, and from a full cold-start.

 

Therefore, whatever sector interleave SDX uses on Indus/GT for standard-format speed, is the one that seems to work well, AND compatible with Indus Track-Buffering (not disrupting PoP disk-load protocol).

[_The Doctor__]

I'd just follow standard 1050 interleave on single/enhanced

xf high speed interleave on double density

 

these would seem to be compromise values that work pretty well and can be adjusted one sector or two out if the game needs more time to do a thing before a sector arrives under the head. Interleave can be tricky with custom access time. You would have to experiment slightly... remember track step forces more time as well. It may sound complicated but it really shouldn't be.

[xxl]

50 minutes ago, rensoup said:

XBIOS_LOAD_DATA (  @xxl C is always set ? )

Reaching the end of the file sets C=1. Reaching the end of the data does not, thus:

 

     jsr     xBIOS_OPEN_DEFAULT_FILE

     ldy     <dest
     ldx     >dest
     jsr     xBIOS_LOAD_DATA
C=1

 

     jsr     xBIOS_OPEN_DEFAULT_FILE

     ldy     <data_len
     ldx     >data_len
     jsr     xBIOS_SET_LENGTH

     ldy     <dest
     ldx     >dest
     jsr     xBIOS_LOAD_DATA
C=0

 

 

[rensoup]

2 hours ago, Faicuai said:

It turns out that the best, smoothest load (sector-by-sector, no sector-misses) I could get was to by formatting with SDX utility, and selecting "high-speed" and SDX-optimized modes, and then issuing a {X HDSC -C=700 Dn: Dm:} at command prompt (where Dn: is source .ATR with bug-fix, and Dm: is Indus/GT destination, with magnetic-media and SSM pre-loaded).

That's a little confusing... though it seems that there's nothing I can do on my side ?

 

1 hour ago, _The Doctor__ said:

I'd just follow standard 1050 interleave on single/enhanced

xf high speed interleave on double density

 or is there ?

 

[rensoup]

1 hour ago, xxl said:

Reaching the end of the file sets C=1. Reaching the end of the data does not, thus:

ah... so there's no way to tell if there were retry errors and the file stopped loading ?

 

(unless I always load the full file and it always reaches the end... if C was 0, I could deduce it stopped loading because of retries? )

[Faicuai]

23 hours ago, rensoup said:

That's a little confusing... though it seems that there's nothing I can do on my side ?

Yes, I know (I  revised my original comment)

 

In any case, nothing else for now on your end. Here are the #s (from last "bug-fix" .ATR)

 

A= 1:49 (SDX-normal DD format, host + Indus cold = fmt+xfer w/ CopyMate 3.8)

B= 1:40 (SDX-high speed DD format,  host + Indus cold)

C= 1:08 (A+Track Buffering pre-enabled on Indus)

D= FAIL (B+Track Buffering pre-enabled on Indus)

 

And this is without any of your recent optimizations.

 

The biggest impact seems to be file-data layout / organization / sequencing, for sure (which are all "virtualized" or hidden with help of track-buffering. Interface line-rate and SIO+file access protocol still remain the same...)

[rensoup]

32 minutes ago, Faicuai said:

A= 1:49

so that's the bugfix version without the fastest mouse ? and that's the time into the first intro screen (not into the game)?

 

hopefully the newest version should help...

[Faicuai]

58 minutes ago, rensoup said:

so that's the bugfix version without the fastest mouse ?

Yes. Chubby mouse.

 

59 minutes ago, rensoup said:

and that's the time into the first intro screen (not into the game)?

Correct.

[+DjayBee]

5 hours ago, rensoup said:

I also tried looking into the rotational latency as indicated in the Altirra manual...

 

For optimum loading, the sectors should be spaced 9 to 15 units apart, so I tried it with a single file but it actually made things a lot worse.

So I'm not sure if the sectors should be 9 to 15 units apart on the same track ? Doesn't seem to make sense but you never know...

 

For instance if you have a 5 sector file starting at sector 36. Which one should it be ?

1. 36, 36+9*1, 36+9*2, 36+9*3, 36+9*4

2. 36, 36+(9*1)%18, 36+(9*2)%18, 36+(9*3)%18, 36+(9*4)%18 (making sure the sector is free of course, otherwise keep adding 1 until a free sector is found)

 

 

 

This will not work out of the book for two reasons.

PoP's loading code is too slow to leverage the fast format and as you already expected the interleave relates to the physical track format on the magnetic disk instead of anything handled by DOS.

 

I don't know for sure if the slow loading is caused by xBios or your own code or both.
I believe that xBios at least is partially involved.
Atari DOS 2.0 introduced something called "burst mode". It uses its internal sector buffer only for transfers of single sectors. As soon as a transfer involves multiple complete(!) sectors, the sectors are read directly to their target address in RAM instead of the buffer.

From my observations xBios has no burst mode; probably to keep its code size small. I suspect this is the reason why @xxl once stressed that xBios is capable to do high-speed SIO but its potential could not be leveraged by PoP.

So for each and every sector its 253 data bytes must be moved to their target address before the next sector can be read.

When this is finished (plus whatever delay your PoP code adds), the next on-disk sector already has passed the disk drives's read/write head. Thus the drive has to wait for nearly a full rotation until the sector shows up again at the head.

 

Secondly your calculation does not work because the interleave is done by the disk drive when it formats a disk. A 1050 for example uses the 9 sector interleave you mentioned (at least for single densiyty disks). If you look at the physical distribution of the sectors on a track it is always 1, 3, 5 ... 15, 17, 2, 4 ... 16, 18. SO sector 2 is 9 physical sectors (or half a rotation) away from sector 1. The rotational delay of tehse 9 sectors is the time needed to transfer the sector's data to the Atari and the time the Atari needs to issue the next SIO call.

 

If you want to calculate the "pseudo-interleave" which you could apply to the distribution of your files on the disk, you must take the above into account.

IMHO it would be easier to create a small test program and a specially crafted disk with 34 test files as follows and have people try it out and report.

Create a small two-sector file which will be used for calibration and a 16-sector file for timing. Write this pair of files 17 times to physical tracks on the disk, each time with a different DOS-side interleave.

 

Add a test program which does this for each of the 17 file pairs:

• read small file (to get track stepping out of the timer and to calibrate)
• reset a VBI based timer (on original OS you could use RTCLOK+x)
• read the bigger file
• read the timer and print its value to the screen together with the track's number
• Ask people to report their results together with the disk drive they have used

[xxl]

8 hours ago, rensoup said:

ah... so there's no way to tell if there were retry errors and the file stopped loading ?

communication errors (apart from FS errors) can be checked in the xIOStat flag - it's not on the website because its address and name will be changed in the next version of xB - if you check the list of xB variables you've probably already guessed what its address is, but just in case I'll send it to you by PM. 

 

4 hours ago, DjayBee said:

From my observations xBios has no burst mode; probably to keep its code size small. I suspect this is the reason why @xxl once stressed that xBios is capable to do high-speed SIO but its potential could not be leveraged by PoP.

That's right, all I/O operations are buffered in xB, additionally the NOTE and POINT calculations for this FS are changed compared to DOS2 so even if burst was added to xBIOS_LOAD_FILE/xBIOS_LOAD_BINARY_FILE, xBIOS_LOAD_DATA, (which there is no place for) I don't know if it would work in expectations whatsoever so you can enable US but it's of little use if at all.

[rensoup]

17 hours ago, DjayBee said:

PoP's loading code is too slow to leverage the fast format and as you already expected the interleave relates to the physical track format on the magnetic disk instead of anything handled by DOS

Thanks for the detailed explanation!

17 hours ago, DjayBee said:

So for each and every sector its 253 data bytes must be moved to their target address before the next sector can be read.

When this is finished (plus whatever delay your PoP code adds), the next on-disk sector already has passed the disk drives's read/write head. Thus the drive has to wait for nearly a full rotation until the sector shows up again at the head.

is that 253 bytes copy that slow ?

 

I mean, the 1050 drive rotates at 288RPM, that's 5 rotations per second, that's 1 rotation per 10 frames in PAL, or 36°/frame.

 

You said that in SD the sectors are half a rotation apart so 5 frames.

 

surely the 253 bytes copy doesn't take a 5 frame ?

 

I'm wondering if double buffering would help (allows to send the next command before doing the copy) ?