DOS I vs DOS II: Burst Mode demonstration

[tschak909]

#Atari8bit in this video, I give a concrete example of how burst mode, introduced in Atari DOS II, vastly improved I/O performance, by writing two BASIC programs, which write and read a graphic to and from disk and memory.

 

[+Nezgar]

Neat stuff. Might be interesting to combine DOS I use with the  810 Rev "B" ROM under full 810 drive emulation, as the theory was the 13:1 interleave better accomodated the inter-sector lag of DOS I non-burst mode.

 

Using a Rev C 810 (with 9:1 interleave) with DOS I would probably blow revs for every 1 or 2 sectors.

[tschak909]

1 minute ago, Nezgar said:

Neat stuff. Might be interesting to combine DOS I use with the  810 Rev "B" ROM under full 810 drive emulation, as the theory was the 13:1 interleave better accomodated the inter-sector lag of DOS I non-burst mode.

 

Using a Rev C 810 (with 9:1 interleave) with DOS I would probably blow revs for every 1 or 2 sectors.

absolutely.

 

-Thom

 

[+Allan]

Great video.

 

I know DOS III is looked down upon, but since it was created by Bill Wilkinson it would be interesting to see an analysis of it and why it was bad and the possible positive aspects of it. In his Antic podcast interview, he talked about this.

[_The Doctor__]

DOS III had an early bug that turned everyone off to it, and there might have been some memory usage concerns By the time some of it was addressed it was over and replaced...

[tschak909]

basically DOS 3 utilized a file allocation table bitmap with 8-bits per entry, thus the need to cluster 8 128 byte sectors together into a single allocation unit, in order to make the bitmap fit, so any file took a minimum of 1024 bytes, rather than a minimum of 128 bytes. This pissed a lot of people off.

 

The further breaking out of copy functions to their own tools also proved to be an annoyance to some.

 

Then there was the issue that DOS 3's utilities went out of their way to rigidly define valid input and make very short sighted assumptions (only disks could possibly have a filename to copy!)... 

 

It all added up to a FMS that was awkward and, from the user's perspective, offered nothing better.

 

-Thom

[thorfdbg]

15 hours ago, Allan said:

I know DOS III is looked down upon, but since it was created by Bill Wilkinson it would be interesting to see an analysis of it and why it was bad and the possible positive aspects of it. In his Antic podcast interview, he talked about this.

DOS III wasn't really bad. The file management was actually much better in the sense that you had an absolute seek to byte possbility - and not only sequential access as Dos II and Dos I had. The only problem was that its allocation unit of 8 sectors was too large to be practical. The user interface tried to guide the user much more than Dos II more than Dos II did. Not necessarily bad, though it was a bit clumsy. DOS III was essentially FAT ported to 128-byte sectors.

[Rybags]

Yes, relative NOTE/POINT rather than absolute was a much better idea but the problem is that in itself had potential for incompatibility.

The reality is that a filing system on small capacity random access media will just about always have annoying overheads one way or the other.

Having pointers as part of the payload is an annoyance though is probably better in file recovery situations.

Big clusters - bad idea.  If they'd gone 256 bytes then it might have been a different story.

[+Nezgar]

The biggest issue with DOS 3 in my mind was that although it came with a utility to transfer files from DOS 2.0 to DOS 3, it didn't include one to go the other way! Hotel California. (You may come, but you may never leave)

 

With the release of DOS 2.5, it included "COPY32.COM" to finally liberate your files from the clutches of DOS 3.....

[ClausB]

On 4/11/2021 at 1:26 PM, tschak909 said:

#Atari8bit in this video, I give a concrete example of how burst mode, introduced in Atari DOS II, vastly improved I/O performance, by writing two BASIC programs, which write and read a graphic to and from disk and memory.

 

About that video: why are there so many drive head crunch sounds?

[+Stephen]

3 hours ago, ClausB said:

About that video: why are there so many drive head crunch sounds?

Altirra has the option to use sounds for the emulated drives.  I assume each "crunch" happens when the head would seek back after reading the file.  While I think it's a neat option to have, I am eternally grateful for the ability to not use it!

[+Nezgar]

5 hours ago, ClausB said:

About that video: why are there so many drive head crunch sounds?

I believe @tschak909 is running Altirra's Full Drive Emulation of an 810 drive with Rev C ROM. The "clunks" after a few seconds idle time is the virtual sound of the 810 seeking the head to track 39 before spinning down. The 810 has no track 0 sensor, so by seeking to track 39 the noisy "grinding" to track -1 to recalibrate the head position can be avoided most of the time. Normally the grinding is only heard on read errors, and way more often on Apple's Disk ][...

[tschak909]

The default 810 emulation under Altirra (if you set the drive type to 810) makes these assumptions.

 

I was just trying to set up something of a correct test for the demonstration, so that at least sector timings were correct and you could see the difference between traditional CIO and burst mode CIO operations very clearly. I turned on the drive sounds because well, why not?

 

-Thom

 

[phaeron]

3 hours ago, Nezgar said:

I believe @tschak909 is running Altirra's Full Drive Emulation of an 810 drive with Rev C ROM. The "clunks" after a few seconds idle time is the virtual sound of the 810 seeking the head to track 39 before spinning down. The 810 has no track 0 sensor, so by seeking to track 39 the noisy "grinding" to track -1 to recalibrate the head position can be avoided most of the time. Normally the grinding is only heard on read errors, and way more often on Apple's Disk ][...

AFAIK the 810 firmware does not recalibrate when coming out of idle, it retains the current track and seeks directly to the track containing the requested sector. The 810 specifications don't give the motivation behind parking the head, but it may be to place it above the least risky track. The 1050 doesn't do this and leaves the head at the last position, and there are warnings in several places to never power the 1050 on with a disk in the drive.

 

[+Nezgar]

1 hour ago, phaeron said:

AFAIK the 810 firmware does not recalibrate when coming out of idle, it retains the current track and seeks directly to the track containing the requested sector. The 810 specifications don't give the motivation behind parking the head, but it may be to place it above the least risky track.

You are correct that the 810 does not recalibrate when coming out of idle. From my own observations though, it will only do a calibration at power-on, and when a read-error is encountered. I think it's a smart way to mitigate more regular loud recalibrations. Plus turning off the drive while the head is parked at track 39 results in a "quiet" calibration for the seek to track 0 on when powered back on. The 810, especially the original revision prior to the grass valley upgrade set, would cause a surge on the write head that could corrupt sectors if a disk was inserted, so we can fairly confidently assume this was a contributing factor in the firmware design....

 

1 hour ago, phaeron said:

The 1050 doesn't do this and leaves the head at the last position, and there are warnings in several places to never power the 1050 on with a disk in the drive.

The 1050 does, however, have additional circuitry to block output to the write head for a short period of time when turned on, so it is basically safe to turn on the drive with a disk inserted. I have at least never personally caused a bad sector from doing so with a 1050. This is documented on page 1-9 of the 1050 field service manual:

Edit: although rereading the above now, it seems this is more to protect the computer than a disk....?

 

I do recall it was basically guaranteed to corrupt a sector if you turned on an ATR8000 with a disk inserted in the drive from the short period of time I used one...

[+kheller2]

17 hours ago, Nezgar said:

The biggest issue with DOS 3 in my mind was that although it came with a utility to transfer files from DOS 2.0 to DOS 3, it didn't include one to go the other way! Hotel California. (You may come, but you may never leave)

 

With the release of DOS 2.5, it included "COPY32.COM" to finally liberate your files from the clutches of DOS 3.....

 

And then there was DOS 4.0....

discuss amongst yourselves.  

[+Stephen]

4 minutes ago, kheller2 said:

 

And then there was DOS 4.0....

discuss amongst yourselves.  

I bet the Atari has the record of most DOSes for an 8-bit machine.  1.0, 2.0, 2,5, 2.0D 2.6f, Rainbow DOS, DOS 3, DOS 4, DOS XL, DOS XE, all the disk based Sparta, then cart based SDX.  Oh - I forgot (as I try to) MyDOS series.  Smart DOS.  Holy crap - it's like that guy in Forrest Gump babbling on about shrimp.

 

I got my 1050 in 1984, it came with 3.0 so I had nothing to compare too.  When I discovered copy parties, I quickly moved to 2.5 and remained there until I got US Doubler, moved on to Sparta DOS 3.2 and never looked back.  All of the menu DOSes look like little Fisher Price toys.  I'm 100% on SDX now.

[tschak909]

I like every FMS, and have spent time working them out.

 

My odd little favorite is OS/A+ version 4. It was something that if the MEMLO wasn't so insane, it would have been an incredible FMS for larger floppies. (and it was the first FMS that did relative NOTE/POINT that actually worked, and could support disks up to 16 megabytes, if you configured the drive table by hand)

 

-Thom

 

[tschak909]

(honestly, would love somebody to disassemble the init program on OS/A+ 4 and see if we could make a version that supported more than 180K and 360K floppies)

 

-Thom

 

[+bf2k+]

Nice and informative video.