Atari Disk Speed vs C64 (stock and modded)

[Mclaneinc]

11 minutes ago, Mazzspeed said:

The Ultimate 64 can implement Dolphin DOS as well as the parallel connection virtually in FPGA via the menu, very cool stuff and totally accurate.

Shame the 1541 Ultimate can't....

[Mazzspeed]

1 minute ago, Mclaneinc said:

Shame the 1541 Ultimate can't....

Well, that would involve the physical parallel cable and interface. Furthermore, because it plugs into the user port it would muck up my WiModem!

 

The speeds I'm getting above are probably just as fast as Dolphin DOS with the parallel interface truth be told - And JiffyDOS has better commands that don't involve the use of the horrible quotation marks.

[Mclaneinc]

ha ha....In truth I'm happy with what I get from my machines, Atari and C64. Having something load at a million miles an hour is nice but its not like it was back in the day until things like DD came out and they were as I know expensive add ons as were Happy Drives. I still like the idea of stuff loading fast but sometimes I load a tape just to feel how it was back then..

Edited April 8, 2021 by Mclaneinc
Spalling..... :)

[R.Cade]

2 hours ago, Mazzspeed said:

It was a little more than that.

 

The original design was intended to make full use of the shift registers implemented in the 6522 VIA, and designs were sent off to the PCB fab with all the interconnects needed to make it happen. When the finished drive made it's way back to the engineers responsible for the improved serial IEC implementation they found all the new traces on the PCB had been removed making the 1541 actually slower than the 1540 as connected to the VIC20!

 

The excuse from the manufacturing department?

 

The PCB didn't fit in the old 1540 case that was being reused for the 1541 so the improvements had to go - Needless to say the engineers were really pissed!

 

Luckily the community examined the implementation, and now a 1541 running JiffyDOS is actually faster than the unobtanium and very rare (and desireable) SFD1001 FDD with the parallel IEEE-488 connection. It just can't hold that magic 1MB of data the SFD1001 could hold.

 

The Ultimate 64 can implement Dolphin DOS as well as the parallel connection virtually in FPGA via the menu, very cool stuff and totally accurate.

Where is this story from?  I remember it told as having the SRQ lines removed from the C64 motherboard, not the drive...

[Faicuai]

Well, time for a bit of reality:

 

Max. SIO-attached performance on the A8 may never be fully realized with existing drives. especially @ 288 rpm, 256Bytes/Sec., and even more considering SIO-overhead. The fastest I have clocked the Indus is on CP/M mode, reading BASCOM (or any other 32KB files) in about 4 secs. That is an INTERNAL throughput of 8,000 Bytes / sec, loaded directly into RAMCharger 64KB buffer. Out of that, I have not seen anything higher than 4,500 Bytes/sec from its Track Buffer. and over SIO (best-case acenario).

 

 

With a drive like SDrive NUXX (or any other equivalent unit for reading / writing .ATR images over SIO), things will change, but the classical linear-READ tests will only tell part of the story, without also considering the write-side of the equation, and then random access):

 

 

So with a simple linear read of 64KB file, you will extract about 8 KBytes/sec of effective performance out of SIO-attached Drive (16 Mbyte .ATR, 256 Bytes/sector). However, write times are lower, and these figures will NOT be attainable by the Indus/GT reach, even reading directly from its TrackBuffer on SDX.

 

Here's a more complete picture, however, once RANDOM-sector READS are considered, along the classical scenarios, all at Pokey Divisor-1, from SDrive Nuxx:

 

And the same would apply as well when reading from the local / internal PBI-drive on Incognito,  but achieving what seems pretty consistent results, on all tests including random sector reads (all CPU-driven, NO DMA involved). Final (read) results appear not being as scattered as the results obtained via SIO, and HD-driven writes will be an estimated 75% of reported read-speeds, approx.):

 

 

As for DMA transfers. it would be interesting to test not only LINEAR writes and reads (being the latter pretty straightforward), but also RANDOM writes and reads, sector-by-sector, either through OS or DOS. Talk about a more heavily-transactional operation, and much more reminiscent of what you would encounter running typical DOS operations and local-storage management (if anyone is interested on these machines beyond simple gaming, or tiny executables, of course).

 

It is yet to be seen what could be extracted from the A8 via a device carrying the supporting HW and controller to execute DMA I/O in such a similar fashion. If 105 Kbytes / sec can be achieved through OS sector-reads (with DMA OFF, either via keyboard+OS, or running in "console" mode), it will be interesting to see how much of 1,600,000 Bytes / sec. could be converted into actual, effective throughput, within a productive environment like SDX, for instance. Possibly 160 to 180 KBytes/sec?

 

 

 

 

Edited April 8, 2021 by Faicuai

[Mazzspeed]

18 minutes ago, Faicuai said:

Well, time for a bit of reality:

 

Max. SIO-attached performance on the A8 may never be fully realized with existing drives. especially @ 288 rpm, 256Bytes/Sec., and even more considering SIO-overhead. The fastest I have clocked the Indus is on CP/M mode, reading BASCOM (or any other 32KB files) in about 4 secs. That is an INTERNAL throughput of 8,000 Bytes / sec, loaded directly into RAMCharger 64KB buffer. Out of that, I have not seen anything higher than 4,500 Bytes/sec from its Track Buffer. and over SIO (best-case acenario).

 

 

With a drive like SDrive NUXX (or any other equivalent unit for reading / writing .ATR images over SIO), things will change, but the classical linear-READ tests will only tell part of the story, without also considering the write-side of the equation, and then random access):

 

 

So with a simple linear read of 64KB file, you will extract about 8 KBytes/sec of effective performance out of SIO-attached Drive (16 Mbyte .ATR, 256 Bytes/sector). However, write times are lower, and these figures will NOT be attainable by the Indus/GT reach, even reading directly from its TrackBuffer on SDX.

 

Here's a more complete picture, however, once RANDOM-sector READS are considered, along the classical scenarios, all at Pokey Divisor-1, from SDrive Nuxx:

 

And the same would apply as well when reading from the local / internal PBI-drive on Incognito,  but achieving what seems pretty consistent results, on all tests including random sector reads (all CPU-driven, NO DMA involved). Final (read) results appear not being as scattered as the results obtained via SIO, and HD-driven writes will be an estimated 75% of reported read-speeds, approx.):

 

 

As for DMA transfers. it would be interesting to test not only LINEAR writes and reads (being the latter pretty straightforward), but also RANDOM writes and reads, sector-by-sector, either through OS or DOS. Talk about a more heavily-transactional operation, and much more reminiscent of what you would encounter running typical DOS operations and local-storage management (if anyone is interested on these machines beyond simple gaming, or tiny executables, of course).

 

It is yet to be seen what could be extracted from the A8 via a device carrying the supporting HW and controller to execute DMA I/O in such a similar fashion. If 105 Kbytes / sec can be achieved through OS sector-reads (with DMA OFF, either via keyboard+OS, or running in "console" mode), it will be interesting to see how much of 1,600,000 Bytes / sec. could be converted into actual, effective throughput, within a productive environment like SDX, for instance. Possibly 160 to 180 KBytes/sec?

 

 

 

 

And likewise, the SD2IEC HDD solution communicating via the IEC serial port achieves a throughput of a little over 8000 bytes/sec. It achieves these speeds as it doesn't strictly conform to the IEC protocol and isn't cycle accurate. However, most software has been patched these days to work with the device and many newly released games have an SD2IEC release.

 

Utilities such as wordprocessors, text editors, communication programs, etc. all load fine off the device and always have. I use it as my mass storage device with everything neatly configured in directories, sub directories and partitions.

 

 

[Mazzspeed]

Where do I get that A8 RWTEST software?

[+CharlieChaplin]

5 minutes ago, Mazzspeed said:

Where do I get that A8 RWTEST software?

 

Think it can be found in several topics here at AA, but you can also download it from the developer's page: RW-Test Please note, that he uploads everything in ARCed from (you may use IZ ARC on the PC or Unarc on the A8 to unpack the archive).

 

[Faicuai]

12 minutes ago, Mazzspeed said:

Where do I get that A8 RWTEST software?

Here:

 

rwtest.exe

si224.com

 

Very little time now to pack on .ATR. Altirra Disk Explorer can be used for such purpose, with any existing .ATR

Edited April 8, 2021 by Faicuai

[+CharlieChaplin]

9 minutes ago, Faicuai said:

Here:

 

rwtest.exe 1.89 kB · 1 download

si224.com 28.74 kB · 1 download

 

Very little time now to pack on .ATR. Altirra Disk Explorer can be used for such purpose, with any existing .ATR

 

Newest Version of Sys-Info is 2.26 from March 2021.

[Mazzspeed]

Well, this is SIDE3 with no tweaks whatsoever:

 

[Faicuai]

15 minutes ago, CharlieChaplin said:

 

Newest Version of Sys-Info is 2.26 from March 2021.

Nice to see 2.25 bug/s corrected (AXLON 1MB now reports correctly in Colleen mode). 

 

Benchmarks are pretty much the same.

 

??

[Faicuai]

21 minutes ago, Mazzspeed said:

Well, this is SIDE3 with no tweaks whatsoever:

 

About right with Antic DMA operational.

 

But when interacting woth SDX, you are actually doing so wtih compatibility with OS E: device. Here's Incognito/HD on NTSC, running E: in console-mode (via XEP80 Ultra driver for SDX), no changes to either OS, SDX or anything else:

 

 

Notice that we can now clearly compute SDX overhead over OS-fired HD sector reads (1-90/105)*100, ~ 14%

Edited April 8, 2021 by Faicuai

[Mazzspeed]

47 minutes ago, Faicuai said:

About right with Antic DMA operational.

 

But when interacting woth SDX, you are actually doing so wtih compatibility with OS E: device. Here's Incognito/HD on NTSC, running E: in console-mode (via XEP80 Ultra driver for SDX), no changes to either OS, SDX or anything else:

 

 

Notice that we can now clearly compute SDX overhead over OS-fired HD sector reads (1-90/105)*100, ~ 14%

It doesn't really make that much of a difference TBH.

 

Edited April 8, 2021 by Mazzspeed

[+Nezgar]

On 4/7/2021 at 7:58 AM, Stephen said:

ICD made a device called the US Doubler (US = Ultra Speed).  It gave the drive true 180kB double density as well as upping the transfer speed to 57,600bps.

US Doubler/Happy/1050 Duplicator/Super Archiver all = ~52,000 bps. (Divisor 10) Speedy = ~55,000 bps (divisor 9)

 

On 4/7/2021 at 9:49 AM, ivop said:

I believe the Speedy upgrade reaches around 80kbps.

I believe it's 68kbps - but only with the built-in HSS Sector copier. Otherwise 55000 (divisor 9) for regular "ultraspeed" protocol use.

 

On 4/7/2021 at 11:01 AM, CharlieChaplin said:

Think the german Turbo 1050 is comparable to an Indus GT drive, it reaches 68k2 Baud with special sector interleave (known as turbo-format). I once tested both mini Speedy 1050 and Turbo 1050 and when both were set to highest speed*, the Turbo was somewhat faster in reading and writing the same disk than a Speedy; but the Speedy was so much faster in formatting the disk (Turbo 1050 was/is as slow as a standard 1050 drive when formatting), that it won the whole diskcopy speedtest.

I experimented with a Turbo 1050 replica a few years ago. Odd beast... Incompatible with ultraspeed protocol, and loads its own handler when turning on the computer with no disk inserted. It runs a 69000bps SIO rate (divisor 6), same as supersyncromesh but no track buffer. It formats an alternate sector interleave similar to a US Doubler. Interestingly, the "turbo" interleave it formats is actually read/writeable on a US doubler drive at 54000bps without blowing revs/missing any sectors, making your USDoubler operating in "ultraspeed" just as fast as a 1050 Turbo! Which means the interleave could probably have been even faster on the 1050 Turbo, but there's a lot of time wasted waiting between sectors.

 

The Turbo 1050 also formats a more optimal interleave for 1x "standard speed" SIO for both Enhanced/Dual density and double density, which I incorporated into a patched US Doubler ROM, as the 1x DD interleave in the USD ROM is actually noticibly slower than that formatted by a Percom or Happy drive....

https://atariage.com/forums/topic/158768-atari-1050-roms/page/3/?tab=comments#comment-4594602

 

Making a US Doubler format optimized "ultraspeed" disks requires updated format routines in the software on the Atari side, as those interleaves are not stored in the drive ROM. Every utility I've come across formats the recommended ultaspeed interleaves documented in the ICD US Doubler Manual, though it does document to transmit the preferred interleave prior to a format command...

[mdivancic]

On 4/7/2021 at 12:01 PM, youxia said:

I'm lucky to have Jiffy in my C64 (+SD2IEC). Also have 65XE with SIO2SD. Can't really say I "feel" any difference, both are just fast enough for me.

 

Back in the day that slow FDD speed could be a real problem though, not just inconvenience, for example ruining the Faery Tale Adventure port.

Agreed. I will not run a C64 machine without JiffyDOS. God awful slow without it plus the other features are well worth it. 

[Mclaneinc]

Mazz, what are the carts in the back other than the 1541 ultimate (no tape interface?) please..

[Mazzspeed]

1 hour ago, mdivancic said:

Agreed. I will not run a C64 machine without JiffyDOS. God awful slow without it plus the other features are well worth it. 

Totally agreed. JiffyDOS has become the defacto standard for the C64, and considering the possibility for extended commands and functionality from the devices ROM it's actually well implemented, fast and perfectly compatible. As I've highlighted, by running the S-JiffyDOS ROMs in the 1541 along with the JiffyDOS kernel in the C64 you get the structure and commands of JiffyDOS with the added speed boost of the S-JiffyDOS drivers in the 1541's ROM, and the difference is immediately noticeable. You can tweak interleave for more of a boost, but compatibility takes a nose dive.

 

Advancements like Hyperspeed and DMA transfer are remarkable, and they're achieving such speeds with the VIC-II taking bus authority due to badlines. Remove that overhead and there's even more improvements to be made.

 

Not that it matters at such extreme levels, as you're essentially loading software faster than an 8 bit processor can actually process it.

 

Exciting stuff in both camps however!

 

43 minutes ago, Mclaneinc said:

Mazz, what are the carts in the back other than the 1541 ultimate (no tape interface?) please..

OK my Friend, from left to right:

 

1: A 9600 baud user port WiModem communicating via WiFi.

 

2: An SD2IEC SD card based HDD using an SD card formatted in FAT32 with extended CMD-HD commands in firmware containing commands like '@MD' (Make Directory), '@CD' (Create Directory), '@RD' (Remove Directory), '@$' (List Directory, you also have switches for long time stamped listings as well as partition listings and the ability to narrow down listings to specifics) and many more commands not contained in base JiffyDOS.

 

3: This is the 1541 Ultimate II+, this is basically an U1MB/SIDE3 and FujiNet all in one - No C64 user should be without this device, it basically has so many features there's no way I can list them all here, however Ethernet with a hardware network stack and Swiftlink emulation is amazing. Get on a fast BBS and it flies. You don't need the tape interface as .TAP files can be loaded via DMA.

 

Not to take the spotlight off the A8. My 600XL with U1MB, SIDE3 and 64k upgrade with SDX and chroma/luma mods is my prized possession ATM.

 

Both unique and amazing machines. Similar in many ways, vastly different in others.

Edited April 9, 2021 by Mazzspeed

[Mclaneinc]

Aha, thanks for that, never seen / used that modem, the SD2IEC come in so many shapes I didn't recognise it but worked out what it was doing (pretty obvious considering the port its in  ), as for the Ultimate 1541++, I have a nice clear one here, could not be without it, just an awesome device. Didn't know you could load TAP files via DMA, I just got the tape interface to have the complete kit...

 

Like you, I see both the Atari and the C64 as complimenting machines, both are as you say, unique but share commonalities as well, two of my most fave machines ever..But then again, I love all the machines I have, each one gives me something different and amazingly in the world of gaming, some very original games across the board..

[Mazzspeed]

7 hours ago, Mclaneinc said:

Aha, thanks for that, never seen / used that modem, the SD2IEC come in so many shapes I didn't recognise it but worked out what it was doing (pretty obvious considering the port its in  ), as for the Ultimate 1541++, I have a nice clear one here, could not be without it, just an awesome device. Didn't know you could load TAP files via DMA, I just got the tape interface to have the complete kit...

 

Like you, I see both the Atari and the C64 as complimenting machines, both are as you say, unique but share commonalities as well, two of my most fave machines ever..But then again, I love all the machines I have, each one gives me something different and amazingly in the world of gaming, some very original games across the board..

Yep, I've got the tape interface. As soon as I realized I didn't really need it I just put it in the drawer and that's where it lives. Don't really want to relive the time consuming nostalgia of tapes!

[+kheller2]

On 4/8/2021 at 8:57 AM, Mazzspeed said:

It was a little more than that.

 

The original design was intended to make full use of the shift registers implemented in the 6522 VIA, and designs were sent off to the PCB fab with all the interconnects needed to make it happen. When the finished drive made it's way back to the engineers responsible for the improved serial IEC implementation they found all the new traces on the PCB had been removed making the 1541 actually slower than the 1540 as connected to the VIC20!

 

The excuse from the manufacturing department?

 

The PCB didn't fit in the old 1540 case that was being reused for the 1541 so the improvements had to go - Needless to say the engineers were really pissed!

 

Luckily the community examined the implementation, and now a 1541 running JiffyDOS is actually faster than the unobtanium and very rare (and desireable) SFD1001 FDD with the parallel IEEE-488 connection. It just can't hold that magic 1MB of data the SFD1001 could hold.

 

The Ultimate 64 can implement Dolphin DOS as well as the parallel connection virtually in FPGA via the menu, very cool stuff and totally accurate.

 

So I did a bit more reading and digging on this...

yes, there was a timing bug in the 6522 shift register that was discovered around the time the Vic20 went to production, and the chip was not fixed, so the drive communications were done with bit banging off the 6502.  A 6526 was designed for the C64 to fix that problem but the additional line was discarded during a board revision before production.  Also the VICII chip would sometimes interrupt the 6510 causing more delays and it had to be slowed down a bit more to be reliable.  

 

Supposedly this was all fixed in the C128 and 1571 ala "burst mode".  Also, supposedly, a few products were sold that re-wired that line in the c64 and new ROMs in the 1541 and the C64 made it fly.  Or use a 1571 with a C64 and some new code and that worked too.

 

 

 

[Mazzspeed]

4 hours ago, kheller2 said:

 

So I did a bit more reading and digging on this...

yes, there was a timing bug in the 6522 shift register that was discovered around the time the Vic20 went to production, and the chip was not fixed, so the drive communications were done with bit banging off the 6502.  A 6526 was designed for the C64 to fix that problem but the additional line was discarded during a board revision before production.  Also the VICII chip would sometimes interrupt the 6510 causing more delays and it had to be slowed down a bit more to be reliable.  

 

Supposedly this was all fixed in the C128 and 1571 ala "burst mode".  Also, supposedly, a few products were sold that re-wired that line in the c64 and new ROMs in the 1541 and the C64 made it fly.  Or use a 1571 with a C64 and some new code and that worked too.

 

 

 

It's easy to think in this day and age "Well how could such a miscommunication happen". But when you consider the methods of communication available back then, as well as the added pressure of deadlines, you can sort of see how it happened.

 

Yes, some variant of electronic mail did exist, but it wasn't widely used.

[Rybags]

email goes way back - the protocols and usage methods were different and the so-called official timeline says about 1973 but even before that there were ways of doing it.

[+kheller2]

7 hours ago, Rybags said:

email goes way back - the protocols and usage methods were different and the so-called official timeline says about 1973 but even before that there were ways of doing it.

Yes -- it does but it was not practically available until the mid 80s.  Most mini/mainframes had their own internal mail system but to connect company to company or university to university was expensive and rare (let alone department to department on a single corporate campus).  It wasn't like you could fire off an email to the guy doing plastic work to adjust his mechanicals.

 

 

[Faicuai]

And here's the absolute maximum we will be able to get out of SIO-attached .ATR images, still without PC-Link packet transmission, but provided here only as  a reference, since PBI-hSIO Bios is required (Divisor-0), plus support pf 512 Bytes/sec. on ATR format (possible with RespeQt PC server, for instance):

 

 

 

Edited April 18, 2021 by Faicuai