Another interesting speed comparison.

[+Larry]

I thought that it would be interesting to do some benchmarking using several types of floppy drives and sector interleaves. In all cases, I used a 720 sector, SD disk (or image) and sector copied the disk to an APE image. As a baseline, I copied the SD disk at 1X to the APE image. In all other cases, the Black Box high-speed drivers were used.

 

Baseline: Interleave=8 2:35

Arch/Dblr 1050: Interleave=5 1:14

Happy 1050: Interleave=8 1:04 Note: Interleaves of 5 and 6 also produced identical results (track buffer).

Floppy Board: Interleave=2 0:42

Indus with Synchromesh loaded: Interleave=6 1:20 Note: Interleave=5 failed -- missed many sectors until next rotation.

APE - APE: Interleave=n.a. 0:49

 

The most interesting aspect to me was that although I have read that an Indus communicates at 81 kbs, it clearly is slightly slower than the 1050 Doubler. And of course, of the physical SIO drives, the Happy came out on top.

 

How about some of the PAL systems/drives -- Speedy, Toms, etc. -- anyone care to add some data?

 

-Larry

[Rybags]

I found that with a standard 1050 and standard formatted ED disk (possibly SD too?), that reading the track backwards was slightly faster than standard.

 

ie - read Sector 26-1, 52-27, etc.

[+Nezgar]

Not sure if anyone is still paying attention to this old thread...

 

Since I made the recent discovery of being able to see the sector interleave of disks using the Happy2Chip converter and archiver/editor I've been curious to see the interleave used on various disks and what created them. It's interesting to me that you can use it to 'fingerprint' the type of drive that was used to format a disk. I always used a Happy drive in the day, so mostly never paid any attention to interleave, since everything was always fast due to the track buffer.

 

Recently my happy board died so spent more time with a USDoubler only drive doing disk imaging until I could get some new Happy boards from AtariMax, and noticed some VERY old atari disks like Timewise, home filing manager loaded with very long times between sectors. I suspected a wacky interleave used on these very old master disks from Atari, and some old original software disks. I was able to confirm they have a sector interleave of 12 - Apparently created by the format of old Atari 810 Roms. This makes the disks load at maybe 2/3 speed?
1 8 15 4 11 18 7 14 3 10 17 6 13 2 9 16 5 12

 

Also interesting was the difference of a disk created by a stock 1050 vs a USD 1050 without ultraspeed interleave. Same interleave, but one of them would shift sector 1 by 1. maybe a slight optimization to account for track-change time?

 

1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16 18

18 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16

 

USD ultraspeed was an interleave of 3 or 4 i think

 

I'm curious what format tool you used to create all those custom interleaves?

I am going to try to see I can create a custom interleave disk using archiver/editor.

Edited May 8, 2017 by Nezgar

[+bob1200xl]

SpartaDOS Construction Set has a Custom Format command ($66). It will make any skew you like.

 

Bob

[drac030]

Here are some interleaves from different drives. The list is of course not complete...

 

http://atariki.krap.pl/index.php/Przeplot

[Rybags]

I've got an Infocom sample disk which uses some weird interleave - it reads at maybe 60% normal speed. Are their normal games like that too?

 

I also remember you could get commercial preformatted disks (Atari brand?) that had a quicker read speed (like doing the backwards read) - maybe they used a reverse order to get that slight boost?

 

Locally here, there was the Supermon OS, and he also did SuperDos which was for use with drives with the Super * modification. There was a format with skew command, not sure if you could specify a custom one, but the disk produced would only read faster on a modded drive, standard drive would see it slow down significantly. I suspect the sectors were probably grouped in order and some sort of caching going on.

[+Nezgar]

Great stuff guys!! Going to check out the SDCS $66 format command for the USDoubler, I noticed that code in another page wasn't sure about an easy way to use it.

 

I formatted SD disks using different drives/ROMs and was checking out the results with the archiver:

• Stock 1050 & Happy 1050 use the same skew: 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16 (9:1)
• USDoubler Standard Skew, same as Happy converted to CHIP 810: 17 15 14 11 9 7 5 3 1 18 16 14 12 10 8 6 4 2 (8:1 & Backwards)

I timed a full 720 sector SD read using the happy sector copier using a stock 1050: (1x/normal SIO speed)

• Disk formatted with Stock 1050 or Happy: 1m25s
• Disk formatted with USD or CHIP: 1m17s

This shows that the slightly reduced sector wait by interleaving the sectors backwards, as well as probably starting sector 1 half way through the track achieves an improvement of 8s over the entire disk.

 

Out of curiosity, I also benchmarked the happy reading these disks, at 1x/normal SIO speed with the track buffer enabled:

• Disk formatted with Stock 1050 or Happy: 1m04s
• Disk formatted with USD or CHIP: 1m04s

The track buffer eliminates any difference in performance from the skew alone, but it does show the theoretical maximum of 1x SIO with minimal inter-sector delay is only 13s faster than that achieved by the stock 1050 with skew generated by USD or CHIP.

 

Next, here is an example interleave I've seen on a number of old software titles (ie Atari Home Filing Manager, IDSI Pool 1.5) , some copied by happy, which would have reproduced the skew of the originals. (ie Grandmas house)

 

Pool 1.5: 12 7 14 3 10 17 6 13 2 9 16 5 12 1 8 15 4 11 (Skew 13)

Grandmas house: 9 16 5 12 1 8 15 4 11 18 7 14 3 10 17 6 13 2 (Skew 13)

 

Those two have the same skew, but different first sector offsets... odd.

 

For fun, I used MyCopyR to sector copy Pool 1.5 to a new disk that was pre-formatted with the USD standard skew (The fastest 1x skew). Track 12 of this disk is copy protected by means of a blank track... so I let MycopyR skip the 'bad' sectors and write everything else to the new disk. I then went into Archiver and read in only the blank track 12 from the original, and wrote that to track 12 of the new disk. Voila Pool 1.5 now loads faster in a stock drive, as well as passing copy protection since it only does a simple check that a sector on track 12 cannot be read in a timely manner. So, kinda cool to 're-skew' old software, even copy protected, to make it load faster on a stock unbuffered drive.

 

I came across an acquired disk in my collection with Indus GT utilities. The disk itself has a standard skew for the first 2 tracks, and custom skew for the rest. I've never owned or used one of these drives, but that's a great idea I presume so it can get the initial 1x boot syncromesh driver loaded at a reasonable speed before it bumps up the speed. This would be a great idea for bootable USDoubler formatted disks too, now that I think of it.. Maybe it would be fun to re-skew the 1st track or 2 of disk-based SpartaDOS before ultraspeed mode kicks in. Anyhow, the Indus disk also has some BASIC programs to format indus disks with a variety of skews, and they're all laid out in the data statements so I'll have some more info to post next.

 

Cheers! - Ryan

PS Some screenshots of the aforementioned disks from Archiver attached

Stock 1050 & Happy

US Doubler Normal & CHIP

Pool 1.5

Grandmas House Side B

Edited May 10, 2017 by Nezgar

[1050]

For further studies, if so inclined, you might look into the skew offered by

Disk Communicator from Bob Puff. During the format phase, you are

asked if you would like a high speed skew with that -- it might be a

different one yet.

http://nleaudio.com/css/Files.htm

 

And another Puff product is the US+ OS which has it's own skew patterns

too, but not so sure how you can get your hands on it.

 

Various high speed SIO routines may or may not have a dramatic

effect on overall though put rates such that one skew that is a dog

normally is the fastest of all with x flavor SIO routine. At least that's

the theory as I've been lead to believe. And always have wondered

on a mildly interested level what was hog wash and what wasn't.

http://www.horus.com/~hias/atari/#hipatch

 

IIRC SpartaDOS will load a High speed SIO routine by default where the

likes of MyDOS are not set up to use the typical old school, under rom

SIO routines that Sparta can without any trouble at all. It gets complicated

quickly is as far as I ever got with any of the above.

[lemiel]

Are these Indus utilities available somewhere to download?

[+Nezgar]

I'll post the ATR's here tonight after I image that disk.

[_The Doctor__]

my interest is still primarily what interleave gives the fastest load/write times across all drives... we already a pretty good idea what is fastest for each particular drive in their native high speed skews... This is why I like nezga/Ryans approach so much. I believe it has the best overall results across the spectrum of drives...

[Rybags]

I suspect the optimum order could be deduced by calculation using RPM and angular proportion of a sector, though isn't there extra leader at the start of the track as well as variable slack space at the end? Then at the computer end you'd need to consider SIO transmission time, a little bit for overhead. I suspect the "optimum" would end up in the middle of a sector, plus you would have to consider some error factor each way for things like RPM variance and different timing depending on stuff like Vblank NMI and DMA at the computer side.

 

Would you be able to try these orderings. This one adds 8 to each successive sector though for sector 10 it's occupied so have to add 9:

1, 10, 8, 17, 6, 15, 4, 13, 2, 11, 9, 18, 7, 16, 5, 14, 3, 12

 

This is +10 from the previous but again has to be +11 on sector 10:

1, 10, 3, 12, 5, 14, 7, 16, 9, 18, 2, 11, 4, 13, 6, 15, 8, 17

 

Re mixed skew on commercial disks - that might be a form of copy protection. You can't guarantee the same read speed with a particular sector order on all drives but you probably could guarantee that using a poorly optimized skew factor would slow a track down on all drives, though if the drive cached the entire track on the first read operation it'd probably make no difference. But the copy protection would still work - timing would be consistent for 2 mixed tracks and 2 same skew tracks if the disk was a copy without duplicating the different skew.

Edited May 11, 2017 by Rybags

[+Nezgar]

Investigated this Indus GT DOS XL Disk this evening. Some interesting utlities on it. A batch file runs GTSYNC ON, which attempts to send high speed code to the drives (I have none), Theres also a GTSYNC.OLD file there, implying this is an updated version. Also some basic program listings for adding Indus download code routines to programs I think, and some tools such as RPM check, a config util to set what I presume are PERCOM Block parameters such as sectors, sides, density. Also interesting i saw step rate. All no effect on USD or Happy.

 

GTFMT.BAS/LST is "INDUS GT Multi-Formatter Version 1.0, Copyright 1985 Vervan Software. It offers 5 interleave options for SD, 1 for ED, and 3 for DD. The actual interleave data is in the BASIC listing as DATA statements, so here they are:

 

Single Density:

• Standard Atari Format (810) 18 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16 (9:1 Same as Stock 1050 & Happy 1050 with 1 sector shift)
• Atari Fast Format (810) 17 15 13 11 9 7 5 3 1 18 16 14 12 10 8 6 4 2 (8:1 Same as USD and 1050 CHIP)
• Indus Standard (810) Format 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16 18 (9:1 Same as Stock 1050 & Happy 1050)
• Indus (810) Format for Synchromesh (Slow) 11 3 14 6 17 9 1 12 4 15 7 18 10 2 13 5 16 8 (7:1)
• Indus (810) Format for Syncromesh (Fast) 16 13 10 7 4 1 17 14 11 8 5 2 18 15 12 9 6 3 (6:1)

Dual/Enhanced Density:

• 1050 Synchronous Format 1 3 5 7 9 11 13 15 17 19 21 23 25 2 4 6 8 10 12 14 16 18 20 22 24 26 (No different than stock 1050 layout)

Double Density:

• Indus (815) Format for Synchromesh (Slow) 7 14 2 9 16 4 11 18 6 13 1 8 15 3 10 17 5 12
• Indus (815) Format for Synchromesh (Fast) 2 4 6 8 10 12 14 16 18 1 3 5 7 9 11 13 15 17

What I don't see in this list is an option that makes a 1:4 SD interleave. Inspecting this disk with Archiver shows it has a Stock 1050/Happy type standard skew on Tracks 1-3, then the following 4:1 interleave for the remainder of the disk. There is a modified version of the DOS XL format utility which includes an option 4 "Reformat boot tracks Only' - This would probably explain how they got this disk to have tracks 1-3 with a normal skew. Maybe the default format when Synchromesh is active is 4:1 and the utility provides the alternate options.

 

This disk:

Tracks 0-3: 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16 1(9:1)

Tracks 4-39: 5 10 15 1 6 11 16 2 7 12 17 3 8 13 18 4 9 14 (4:1)

 

The 4:1 skew is too tight for my USDoubler, every sector is pretty much a full rotation wait, just below the 5:1 that USD uses.

 

ATR's and Screenshots attached. (Used Omniview 80 Columns for the basic listings)

Indus GT Dos XL.zip

Edited May 11, 2017 by Nezgar

[+Nezgar]

SpartaDOS Construction Set has a Custom Format command ($66). It will make any skew you like.

 

For further studies, if so inclined, you might look into the skew offered by Disk Communicator from Bob Puff. During the format phase, you are asked if you would like a high speed skew with that -- it might be a different one yet.

 

Normally I've always just used the Formatter Built into SDX. I tried the INIT command from SpartaDOS 3.2D, and the UltraSpeed Skew format option from Disk Communicator. I can confirm they all generate the same 5:1 interleave best suited for the US Doubler.

 

These programs must be using USDoubler's $66 SIO command, supposedly allows specifying any skew along with the command, so I'm wondering if there are any pre-baked programs to enter a custom skew instead of writing it myself. These programs must have just hard coded the US Doubler Ultraspeed skew to use along with $66 format command all the time...

This is the resulting SD skew, for the record: 4 8 12 16 1 5 9 13 17 2 6 10 14 18 3 7 11 15

[ijor]

I've got an Infocom sample disk which uses some weird interleave - it reads at maybe 60% normal speed. Are their normal games like that too?

 

That was probably formatted with the older 810 ROM, or at least imitating the skew/interleave of that ROM. There are quite some many originals with that SLOOOW interleave.

 

 

Re mixed skew on commercial disks - that might be a form of copy protection.

 

I don't recall seeing something like that by design, although it is of course, conceivable. Normally what you see is just a collateral byproduct of tracks formatted with different software, and even sometimes with different hardware.

[1050]

These programs must be using USDoubler's $66 SIO command, supposedly allows specifying any skew along with the command, so I'm wondering if there are any pre-baked programs to enter a custom skew instead of writing it myself. These programs must have just hard coded the US Doubler Ultraspeed skew to use along with $66 format command all the time...

Nothing pre-baked that I'm aware of, sorry. I probably

wrote a crude something at one time but it wouldn't be

worth even trying to implement as it too would be table

driven with a need to re-compile for each table wanted.

 

BASIC with several input modes might be nice along with

standard table use too. Manual entry and interleave ratio

input and table driven versions all in one could be a good

deal of work to get done up nicely.

 

It's not a format command, it's an expanded $4F write

percom block command with additional info as to sector skew

order added to the end of a standard percom block.

 

Not sure at all which drives allow $66 command, IIRC the

happy will puke on it. It does appear the XF551 will use it

according to link below.

 

Proper and full use should require matching sector count with

desired format, but no info if this is actually checked within

various drive OS or if error results from mismatch gets properly

returned from the drive. And an issue exists with some drives

that involve the non-standard use of superfluous data field in

far too many 3rd party drives. A $4E read percom block command

sent results in a unique data field where the unused data is

often used 'in house' for lord knows what.

http://www.atarimax.com/jindroush.atari.org/asio.html#4E

 

When you clear these 'unused' data fields and write that data back,

with changes done in changing the density fields, it often

gets rejected by 3rd party drives because of the mismatch in the

'unused' data fields alone. They do accept the density change

if only that info is altered and I would further leave the step rate

to be same as read myself just to avoid this issue.

 

So for the fewest problems it would be $4E command and compare

density to desired for match, change only density fields if needed

to, then add skew order to tail of percom block and write it out

with $66 command. At that point a standard format is done.

 

MyDOS will not allow this as it will internally reprogram the

percom block during any format attempts to it's own internal drive

density tables as it was before any outside shenanigans happened.

The only way to change density with MyDOS then is to do it via the

O config menu - this fully is a bug with a PIA workaround. I suspect

highly that marslett was not aware of how to detect an SIO error

properly as I've fixed his code in this regard before and further

his thinking was that all drives MUST adhere to percom standard

religiously and none really do. Too hard headed to submit to what

actually works visa vee the read first, use supplied drive data as

is with ONLY density changes desired and get on with your life. He

could not be made to understand the real issue, so Puff came along

and 'fixed' the O config issue for him to the state as above. It's

not a full fix unfortunately. In many attempts to hammer out the

issue, marslett dropped in many segments all over the place to

wrangle this issue - the code is quite confusing because of his

'fixes' dropped in starting many versions below 4.50. So MyDOS is

perhaps not the best DOS to be doing this kind of work with. No

other DOS has this issue that I'm aware of so there should be

plenty to pick from.

[+Nezgar]

It's not a format command, it's an expanded $4F write

percom block command with additional info as to sector skew

order added to the end of a standard percom block.

 

Not sure at all which drives allow $66 command, IIRC the

happy will puke on it. It does appear the XF551 will use it

according to link below.

Yes I can confirm the happy pukes on an Ultraspeed format command from SDX, I presume the $66 command.

 

So for the fewest problems it would be $4E command and compare

density to desired for match, change only density fields if needed

to, then add skew order to tail of percom block and write it out

with $66 command. At that point a standard format is done.

Out of curiosity, I watched what is logged in RespeQt when issuing a format from SDX with 'Ultra' skew:

 

[Disk 1] Get status."

[Disk 1] Format with custom sector skewing (SD Diskette (90k))."

[Disk 1] Get PERCOM block (SD Diskette (90k))."

[Disk 1] Write sector 1 (128 bytes)."

[Disk 1] Write sector 2 (128 bytes)."

[Disk 1] Write sector 3 (128 bytes)."

[Disk 1] Write sector 4 (128 bytes)."

[Disk 1] Write sector 5 (128 bytes)."

[Disk 1] Write sector 6 (128 bytes)."

 

Compared to a 'Normal' Skew:

 

[Disk 1] Get status."

[Disk 1] Get PERCOM block (SD Diskette (90k))."

[Disk 1] Format."

[Disk 1] Write sector 1 (128 bytes)."

[Disk 1] Write sector 2 (128 bytes)."

[Disk 1] Write sector 3 (128 bytes)."

[Disk 1] Write sector 4 (128 bytes)."

[Disk 1] Write sector 5 (128 bytes)."

[Disk 1] Write sector 6 (128 bytes)."

 

Interesting i also noticed format $41 is ASCII 'F' and $66 is 'f'. RespeQt NAK's the $A1/$A2 commands for XF551 'HighSpeed' / quad formats

 

Found a post from 2011 that has a good example of how to do the XIO 66 from basic...

http://atariage.com/forums/topic/187729-xio-call-to-format-a-css-xf551-80-track/?p=2371459

I'll be playing with this...

[+kheller2]

Just a bit of information, but I believe the WST 1050 drives (vs the Tandon) uses a slighter faster step rate ROM.

[re-atari]

I came across an assembly listing on the Atari Wiki intended to make a custom disk format routine using command F on a 1050 with Speedy enhancement. Although not a direct link with this thread's subject (disk sector interleaves), the article might be an interesting read nevertheless.

 

Check out:

 

https://atariwiki.org/wiki/Wiki.jsp?page=Custom%20Disk%20Format%20Routine

 

re-atari

Edited May 12, 2017 by re-atari

[Jacques]

On 5/11/2017 at 12:11 PM, Nezgar said:

Investigated this Indus GT DOS XL Disk this evening. Some interesting utlities on it. A batch file runs GTSYNC ON, which attempts to send high speed code to the drives (I have none), Theres also a GTSYNC.OLD file there, implying this is an updated version. Also some basic program listings for adding Indus download code routines to programs I think, and some tools such as RPM check, a config util to set what I presume are PERCOM Block parameters such as sectors, sides, density. Also interesting i saw step rate. All no effect on USD or Happy.

 

GTFMT.BAS/LST is "INDUS GT Multi-Formatter Version 1.0, Copyright 1985 Vervan Software. It offers 5 interleave options for SD, 1 for ED, and 3 for DD. The actual interleave data is in the BASIC listing as DATA statements, so here they are:

 

Single Density:

• Standard Atari Format (810) 18 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16 (9:1 Same as Stock 1050 & Happy 1050 with 1 sector shift)
• Atari Fast Format (810) 17 15 13 11 9 7 5 3 1 18 16 14 12 10 8 6 4 2 (8:1 Same as USD and 1050 CHIP)
• Indus Standard (810) Format 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16 18 (9:1 Same as Stock 1050 & Happy 1050)
• Indus (810) Format for Synchromesh (Slow) 11 3 14 6 17 9 1 12 4 15 7 18 10 2 13 5 16 8 (7:1)
• Indus (810) Format for Syncromesh (Fast) 16 13 10 7 4 1 17 14 11 8 5 2 18 15 12 9 6 3 (6:1)

Dual/Enhanced Density:

• 1050 Synchronous Format 1 3 5 7 9 11 13 15 17 19 21 23 25 2 4 6 8 10 12 14 16 18 20 22 24 26 (No different than stock 1050 layout)

Double Density:

• Indus (815) Format for Synchromesh (Slow) 7 14 2 9 16 4 11 18 6 13 1 8 15 3 10 17 5 12
• Indus (815) Format for Synchromesh (Fast) 2 4 6 8 10 12 14 16 18 1 3 5 7 9 11 13 15 17

What I don't see in this list is an option that makes a 1:4 SD interleave. Inspecting this disk with Archiver shows it has a Stock 1050/Happy type standard skew on Tracks 1-3, then the following 4:1 interleave for the remainder of the disk. There is a modified version of the DOS XL format utility which includes an option 4 "Reformat boot tracks Only' - This would probably explain how they got this disk to have tracks 1-3 with a normal skew. Maybe the default format when Synchromesh is active is 4:1 and the utility provides the alternate options.

 

This disk:

Tracks 0-3: 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16 1(9:1)

Tracks 4-39: 5 10 15 1 6 11 16 2 7 12 17 3 8 13 18 4 9 14 (4:1)

 

The 4:1 skew is too tight for my USDoubler, every sector is pretty much a full rotation wait, just below the 5:1 that USD uses.

 

ATR's and Screenshots attached. (Used Omniview 80 Columns for the basic listings)

Indus GT Dos XL.zip 72.24 kB · 55 downloads

 

Having bought Indus GT, I'd like to write DOS XL 2.35 I2 back onto real disk from ATR and do so with original skew. Is there something special I should do, please?

[xrbrevin]

14 minutes ago, Jacques said:

write DOS XL 2.35 I2 back onto real disk from ATR

are you aware how to write real disks using altirra and an SIO2PC connection?

[Jacques]

2 hours ago, xrbrevin said:

are you aware how to write real disks using altirra and an SIO2PC connection?

I haven't used Altirra in conjunction with real drive, yet. Used RespeQt and VAPI 1050 in the past to load protected ATX to real Atari, etc.

Is there a way to write 2.35 I2 under Atari, together with SIO2SD for example? There's no problem for me to write ATR onto real disk, just the skew raised my eyebrows with that particular DOS and SuperSynchromesch

Maybe I could write ATR in a standard way, then boot 2.35 from my Indus, format disk under it and then simply copy the files onto disk?