Unicorns season: Prince of Persia for the A8!

[rensoup]

1 hour ago, snicklin said:

Just trying to catch up, but what is left to do on this game @rensoup? It seems fine to me, though I haven't played it to completion

Optimum 1X SIO loading speed obviously... we're getting pretty close though ?

 

That and attract sequence polishing... Hoping to have 2-3 more colors in the palace room (which could be quite complex).

[rensoup]

1 hour ago, Irgendwer said:

A very entertaining game and challenging in regard to sprites and programming would be "Pirate Ship Higemaru":

I wouldn't say it's that challenging (compared to something like Bubble Bobble!)

 

Maybe TIX would be interested on the art side but I'll let you handle the code side ?

[Faicuai]

2 hours ago, rensoup said:

The happy's track buffering made no difference... I guess it's not smart enough to cache the directory sectors.

Alrighty!

 

Here's the "NoDir" version from Indus/GT, all measured to Copyright screen:

• 1m:30.78s (as-is, standard DD format / sector-interleave, direct read from magnetic media).
• 0m:54.99s (Above + Track-Buffering "bF" pre-enabled, 1st-PASS)
• 0m:53.70s (Above + 2nd-PASS)
• 0m:51.50s (Above, but stopping load when switching to track 04 and then reloading from RamCharger, maxed out)
• 0m:44.40s (.ATR image read from SDrive NUXX, as provided / downloaded from first post).

So the Indus/GT now seems to show its "muscle", relatively speaking. Furthermore, it did not come that far off from .ATR SDrive Nuxx performance. ?

 

So yes, both XXL and you were correct in pointing out the clear improvements. However, I am noticing that the gains from Track-Buffering maybe not as pronounced as "Bug-Fix" version test. On the latter, I could see larger periods of time where multiple NO DISK-SPIN transfers took place.

 

 

[rensoup]

22 minutes ago, Faicuai said:

Here's the "NoDir" version from Indus/GT, all measured to Copyright screen:

• 1m:30.78s (as-is, standard DD format / sector-interleave, direct read from magnetic media).

 

Ouch...

 

that's a lot worse than Altirra:

 

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

 

and also @DjayBee 's unhappy 1050:  0:57 min

 

Is the Indus supposed to be much slower than the 1050 ?

 

26 minutes ago, Faicuai said:

So yes, both XXL and you were correct in pointing out the clear improvements. However, I am noticing that the gains from Track-Buffering maybe not as pronounced as "Bug-Fix" version test. On the latter, I could see larger periods of time where multiple NO DISK-SPIN transfers took place.

Not sure what No Disk-Spin means but track buffering would work really well with directory caching so that would explain it.

[CPUWIZ]

12 hours ago, youxia said:

Man, you must be really fun to be around IRL.

 

This thread really is cursed. Perhaps a mod needs to come up armed with garlic and a bunch of silver bullets.

 

 

 

 

 

For some reason, someone keeps un-banning him from this thread. ?

[Faicuai]

33 minutes ago, rensoup said:

that's a lot worse than Altirra:

 

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

 

and also @DjayBee 's unhappy 1050:  0:57 min

 

Well, that is NOT real performance on ROM 1.20 (and from disk resulting from direct transfer with CopyMate from .ATR to magnetic media). Funny, the per-sector writes on Copymate 3.8 are much faster than the actual reads while loading PoP.

 

Last but not least, and as far as I remember, my 1050 cannot read Double-Density disks. So I am not sure what "unhappy or non-happy" 1050 times mean, though. There should be no times, whatsoever, unless reading single-density versions that I did not catch?

 

(NOTE: no-disk-spin means exactly that: you see the "busy" light blinking on Indus/GT transferring data, but NO magnetic-media reads, at all, the disk is not rotating. Track-Buffering code on Indus/GT seems more like a sector-level cache, where you can see the drive moving at any arbitrary point of "Track N" to any aribitrary point of "Track M", no matter how distant these may be, as long as the sectors are in RamCharger buffer, which maxes out about 50KB or so of effective buffered data).

 

[a8isa1]

5 hours ago, DjayBee said:

See this post and grab the last file from the very first post of this thread. 

Test it on hardware and give feedback. 

NTSC 800XL with Rambo XL 256        Mouse                  Copyright Notice               Demo

Fujinet  1.0                                            0:36                      0:56                                   1:59

SWP ATR8000                                      0:52                      1:36                                   2:47

 

                      

[+DjayBee]

3 hours ago, Faicuai said:

So I am not sure what "unhappy or non-happy" 1050 times mean, though.

It's a Happy 1050 set to unhappy mode using Happy software (of which I was surprised that it still did read the DD disk). I do not own an unmodified drive. 

[xxl]

7 hours ago, rensoup said:

The only thing that bugs me is how Copymate reaches 1.3KB/s

copymate is a sector copier, it probably does not check the FS at all so it does not use the sector buffer and does not copy from it once, it behaves as if it is in burst mode all the time so its results should be considered as ideal not achievable in real operation. burst mode normally requires checking if the blocks in the file exceed the sector size and only then the next sector is written directly to the destination and not in the buffer.

 

 I would consider the sector copier results as maximum but not achievable in normal operation.

 

[+CharlieChaplin]

4 hours ago, xxl said:

I would consider the sector copier results as maximum but not achievable in normal operation.

 

 

Yep, otherwise I could use HSS Copy II with my Speedy 1050 for much faster reads and the built-in (mini) Super Speedy 1050 copy program that reads the whole DD/180k disk in approx. 15 seconds (thanks to lots of onboard RAM).

 

[Level42]

9 hours ago, Faicuai said:

Alrighty!

 

Here's the "NoDir" version from Indus/GT, all measured to Copyright screen:

 

 

Why are we testing Indus/GT, Happy, Speedy ? These are not original Atari legacy products and aftermarket upgrade devices....................... I thought this was all about the "original" experience ???

Edited July 19, 2021 by Level42

[+DjayBee]

40 minutes ago, Level42 said:

Why are we testing Indus/GT, Happy, Speedy ? These are not original Atari legacy products and aftermarket upgrade devices....................... I thought this was all about the "original" experience ???

Because we can. ?

[+CharlieChaplin]

1 hour ago, Level42 said:

Why are we testing Indus/GT, Happy, Speedy ? These are not original Atari legacy products and aftermarket upgrade devices....................... I thought this was all about the "original" experience ???

 

... the original experience in the 80s and early 90s (the heyday of the A8) when these drive upgrades and third party drives, as well as RAM upgrades, were widely available and used.

 

I personally use several A8 peripherals, like 1050 floppy drives with upgrades, 1010 tape drives without any upgrades, SIO2xyz devices, flash carts and other things. But not every Atarian owns that many different peripherals, so it is always nice if a developer releases his A8 program in several A8 media formats (e.g. disk/ATR image, tape/CAS image, cart./CAR image, etc.).

 

JOKE:

Of course you know that the internet was not much publicly available in the 80s, so next time to pay tribute to the original experience, please send me a letter or a pirate tape/disk with your opinion (in a demo/intro) or write to a BBS...  

 

[Level42]

38 minutes ago, DjayBee said:

Because we can. ?

Nononono, this is all about original real Atari experience only. Not a single upgrade/aftermarket/third party device should be allowed...... strictly SIO 1x speed only !

 

OK, I'll stop this now....

Let's see those extra colors in the palace scenes Rensoupp
  

Edited July 19, 2021 by Level42

[Faicuai]

1 hour ago, Level42 said:

Why are we testing Indus/GT, Happy, Speedy ? These are not original Atari legacy products

Correction.

 

When on Sept. 1984, I walked into the very-large "Disk'n Bytes" shop in South Florida, I grabbed an off-the-shelf 800XL, AND Indus/GT, being the latter an official commercial product developed, branded and sold in store-fronts nation-wide for use WITH Atari... Just like Atari 815, Percom, Rana Systems, and others.

 

Back-on-topic, now... (nobody here is testing above original SIO speeds, as times clearly indicate...)

 

 

[Heaven/TQA]

now... maybe time as come to unpack my Speedy 1050 modded 1050 and I have still some BASF 5,25'' I needed to present my VIC20 & Atari 800 Demo (Arsantica 3) at Revision...

 

Sounds fun for this week... (and I could check if my disk drive works.).

 

So which is now the one to be tested on 5,25 media? and I simply use a Sector Copier? or any fancy other tool?

[+DrVenkman]

28 minutes ago, Heaven/TQA said:

and I simply use a Sector Copier? or any fancy other tool?

At @DjayBee‘s suggestion, I have been using CopyMate 4.4 to make disks from the various ATR files in the thread.

[+DjayBee]

1 hour ago, Heaven/TQA said:

So which is now the one to be tested on 5,25 media?

Go to the very first post of this thread and scroll to its very end.

 

The last file "NoDir" is the one from Jul, 16th and the one above "DDfastestmouse" is from Jun, 27th.

 

Btw.: @DrVenkman This time I used CopyMate 3.8 XE because it can use extended memory and thus copy the whole disk in one turn.

Edited July 19, 2021 by DjayBee

[+DrVenkman]

19 minutes ago, DjayBee said:

Btw.: @DrVenkman This time I used CopyMate 3.8 XE because it can use extended memory and thus copy the whole disk in one turn.

Hmm, I don't seem to have CopyMate 3.8 XE but I do have 3.7 XE and it works as well. Just had a chance to write out the "NoDir" test version from the first post with one of my Happy 1050's and booted it up. Here are my approximate load times with my 576NUC+ beta test board and one of my Happy 1050 drives:

 

From power-on to mouse: 30.5 seconds

From mouse to text copyright screen: 59.2 seconds

From text copyright screen to graphical title screen: 1 minute, 27.4 seconds

From graphical screen to first screen of the animated intro: 1 minute, 59.6 seconds

 

All times measured from beginning of power-on, timed manually with my phone's stopwatch app.

 

[Faicuai]

11 hours ago, a8isa1 said:

NTSC 800XL with Rambo XL 256        Mouse                  Copyright Notice               Demo

 

SWP ATR8000                                      0:52                      1:36                                   2:47

 

Sounds about right, fairly close to the real times I get from "naked" reads of standard DD-interleave format + PoP ("no-dir" version), on the Indus/GT (with no SSM or Track-Buffering code uploaded to it).

 

 

[Faicuai]

50 minutes ago, DjayBee said:

CopyMate 3.8 XE because

Plus being an "auto-density virtuoso": it will detect and handle SD, ED, and DD autonomously, like a walk in the park, including media-format task, and check for format-mismatch when only writing out sector-buffer. On top of this, it will respect and use PBI-provided HSIO drivers, too (!)

 

As far as I have seen, it is the only one out-there managing the three formats, transparently.

[+CharlieChaplin]

Hmmm,

regarding the POP_no_DIR version...

 

a) mouse = animated mouse, I think,

b) copyright = Broderbund / Jordan Mechner copyright text screen

titlescreen = coloured titlescreen with mouse in the foreground

(did not stop/measure the time here)

c) intro = intro scene with palace, princess and Jaffar

d) demo = demo mode begins

 

I was so evil to turn my Speedy into a Turbo 1050 drive by using the turbo emulator program. The Turbo 1050 requires a turbo driver (that one can boot from the drive) and special turbo format (sector skew / sector interleave) to reach up to 68kBaud.  But errrmm, as I found out, XBIOS always turns off the turbo driver, which either uses page 1 or page 6. Nevertheless, I always tested four variations...

 

1) no turbo driver, no turbo format:

a) 28 seconds, b) 54 seconds, c) 1:52, d) 3:35

 

2) with turbo driver*, no turbo format:

a) 27 seconds, b) 53 seconds, c) 1:52, d) 3:35

 

3) with turbo driver*, with turbo format:

a) 35 seconds, b) 1:13, c) 2:17, d) 4:11

 

4) no turbo driver, with turbo format:

a) 38 seconds, b) 1:15, c) 2:22, d) 4:15

 

* turbo driver always gets switched off after two seconds (no matter if it uses page 1 or page 6).

 

If the Turbo 1050 uses both the turbo driver and turbo format, it reaches up to 68kBaud, but without turbo driver and with special turbo format it is very slow (slower than a normal drive). Thus, if you happen to have a Turbo 1050 or similar drive (TOMS drive, Top drive, etc.) do NOT use the turbo format, since the turbo driver gets switched off anyway. Oh and I used my smart phone to measure the loading times, so they are +- 1 second I guess.

 

Tried also two sector copy programs:

1) Copy 2000, no turbo driver, no turbo format; read entire 180k disk: 2:10

2) Track Copier by Arndt Baer, with turbo driver, no turbo format; read entire 180k disk: 1:30

3) Track Copier by Arndt Baer, with turbo driver, with turbo format; read entire 180k disk: 1:00

4) Copy 2000, no turbo driver, with turbo format; read entire 180k disk: 3:22

 

So the next test will be with the Speedy 1050 and (mini) Super Speedy 1050 and sector copy programs Copy 2000, HSS Copy II and (mini) Super Speedy copy program.

 

[+CharlieChaplin]

Okay, here I go again (on my own)...

 

the Speedy enhancements are similar to the Happy (originally they were clones, but then they changed several things), they do have a track buffer, they do have a buffer/cache for boot and dir. sectors and to reach ultraspeed they do require a hardware (e.g. OS) or software (e.g. DOS, Gamedos, Bootloader, etc.) ultraspeed driver. Thanks to the track buffer, there is no special format (no sector skewing / no sector interleave) required. If you power-on the Speedy, it is in normal mode which is somewhat faster than slow/original 1050 mode, but slower than ultraspeed. POP and/or the XBIOS does not come with an ultraspeed driver (and I have none in my OS), so I can only use normal or slow mode when booting POP...

 

1) normal mode:

a) 26 seconds, b) 52 seconds, c) 1:49, d) 3:31

 

2) slow mode (read+write slow, configured in external setup program):

a) 45 seconds, b) 1:30, c) 2:40, d) 4:42

 

I was surprised that the Speedy in slow mode is still slower than the Turbo 1050 without turbo driver (and with or without turbo format)...

 

Here are the results of several Copy programs (Copymate 3.7XE and 3.8XE do not work with Speedy ultraspeed, they only support Happy and US-doubler, it seems):

 

- Copy 2000, ultraspeed, read entire 180k disk: 54 seconds

- HSS Copy II, ultraspeed, read entire 180k disk: 36 seconds

- (mini) Super Speedy with built-in Speedy Super Copy II, read entire 180k disk: 9 seconds

   => the Super Speedy upgrade has lots of on-board RAM, thats why it is so fast!

- Copy 2000, slow mode (read+write slow), read entire 180k disk: 2:12

- Copy 2000, drive=original 1050, read entire 180k disk: cannot read disk (like a 1050)

 

[Faicuai]

1 hour ago, CharlieChaplin said:

2) slow mode (read+write slow, configured in external setup program):

a) 45 seconds, b) 1:30, c) 2:40, d) 4:42

 

That's much closer to times of Indus/GT and ATR8000, on a std. DD interleave format and cold-boot of disk.

 

The other aspect of "track-buffering" or on-board buffers is not their nominal KB capacity (eg. 64KB, 256KB), but how much of that capacity is readily usable and available during standard I/O requests over SIO (not driven by special-purpose copiers, that is).

 

As an example, the Indus/GT manages to boot about x11 DD tracks (randomly accessed) from RamCharger buffer (with ZERO disk-spin) during PoP boot-time, bringing the load-time to Copyright-screen to about 51 secs. That means about 50 KB of effective RAM space for buffering available at any time.

 

However, it seems to me that bringing the standard times from 1m:30s to 0m:51secs is much more about efficiently reading the default DD sector-interleave format, than actual use of Track/Sector buffering, in my opinion. This means some additional code / intelligence (uploadable via SIO) will be required with these drives for optimal DD performance, anyway.

 

 

 

[tjlazer]

On 7/17/2021 at 4:46 PM, Level42 said:

It is the year 2021.Wake up. 

Never understood this mentality.  Yes it is 2021 and we all use our modern machines to do stuff that is for modern times.  But we also like to play with our old vintage Atari computers like it is 1986 too.  Using it as it was back then.  Using floppy disks or Cartridges and some even tapes!  A lot of us are perfectly fine with this.  If you aren't, go back to your PC or Mac.  Not sure why you are on here.

Edited July 19, 2021 by tjlazer