Found a copy of DOS 1.0

[+Philsan]

Thank you very much.

 

Your manual (last page is missing) seems the same revision of this one:

http://www.atarimania.com/documents/Disk_Operating_System_Reference_Manual.pdf

[Rybags]

Yeah, Dos 3 had some good concepts but that cluster size is way too big.

[flashjazzcat]

I wonder if there was some potential patent infringement perceived at the time; just spreading the FAT out across multiple sectors and correspondingly reducing the cluster size would have made DOS 3 pretty much ideal. Did it insist on caching the entire FAT in RAM the whole time, I wonder?

[Rybags]

My guess is they wanted to reduce disk seeking by keeping it in Ram.

Though a big cluster size in theory should mean keeping the entire thing in memory for write operations at the least.

Thinking again, wouldn't a tradeoff of smaller clusters but bigger FAT even out anyway?  Or in fact save memory.

 

MS themselves stole the idea, it was in use since 1977 at least.

I thought CP/M was using it first but supposedly not.

Really, FAT is a logical way of organising a disk and I doubt a patent could go beyond being very specific about how it's implemented.

And CP/M by the time Atari's Dos 3 was out was near identical to MS-Dos with it's structure anyway, wasn't it?  - Think Atari ST's disk structure and high compatibility with MS-Dos 720K disks.

[flashjazzcat]

Yes: TOS essentially uses FAT AFAIK.

 

FAT becomes inefficient at allocating when the cluster table is spread out over a lot of sectors, so that's another reason they may have wanted to keep the whole thing in RAM. FAT in general scales badly on slower, low-resource machines (the biggest PITA being the fact that FAT16 doesn't keep a running count of free sectors in BPB, hence the lengthy pause when SDX's FATFS driver first accesses a volume; it's trawling through the entire FAT figuring out the free sector count. FAT32 at least keeps a running count, but it should not be regarded as accurate, although it's at least useful if you want something to display at the end of a directory. SymbOS - IIRC - omits the FAT free cluster count entirely in the directory listing, instead providing a special 'show free space' function in its file manager).

 

The smaller clusters don't really save on data buffer space, since you commonly wouldn't read the entire cluster in at once (although on more modern machines it makes sense to set the block size to the cluster size). I'm sure DOS 3 could have spread the cluster chain out and remained fairly efficient with a few basic optimisations, but I appreciate there were a lot of constraints at the time. Also, the overhead of extra sector IO using SIO can be pretty bad.

 

Not to wander further off-topic, but I don't think DOS-XE learned many of the lessons from prior mistakes. I may be completely wrong, but I recall that DOS-XE kept the entire cluster table in RAM as well, hard-limiting the volume size so that it can't scale easily (or at all) to handle hard disks, etc.

 

What with the downsides of FAT and other filesystems, SDFS is a pretty nice solution for the A8. Bitmaps for fast allocation, running free cluster count, and linkage/metadata completely separated from data. The sector maps are great for fast random access in either direction.

[firebottle]

1 hour ago, flashjazzcat said:

FAT in general scales badly on slower, low-resource machines (the biggest PITA being the fact that FAT16 doesn't keep a running count of free sectors in BPB, hence the lengthy pause when SDX's FATFS driver first accesses a volume; it's trawling through the entire FAT figuring out the free sector count.

Interesting. I get the long pause too when using a 2gb CF card in 8088 PC's.

[flashjazzcat]

1 minute ago, firebottle said:

I get the long pause too when using a 2gb CF card in 8088 PC's.

Yes! Now you mention it, I remember this phenomenon too when using my Dad's ancient 8088 PC back in the 90s.

[+Nezgar]

56 minutes ago, firebottle said:

Interesting. I get the long pause too when using a 2gb CF card in 8088 PC's.

2GB is insanely colossal in the context of an 8088 PC though. You'd probably do better using a number of smaller partitions for day to day use.

[thorfdbg]

On 3/22/2020 at 4:44 PM, tschak909 said:

I still want to know who specified the filesystem to SMI at Atari, so I can go up to them and thwap them repeatedly with a trout.

 

A SINGLE ENDED LINKED LIST OF SECTORS?!

 

-Thom

Well, even FAT uses a singly linked list of sectors, but centralized.

[thorfdbg]

7 hours ago, flashjazzcat said:

I wonder if there was some potential patent infringement perceived at the time; just spreading the FAT out across multiple sectors and correspondingly reducing the cluster size would have made DOS 3 pretty much ideal. Did it insist on caching the entire FAT in RAM the whole time, I wonder?

Actually, I had a prototype FMS which I never completed to full extend which worked pretty much like this. It had a "fat", but in the middle of the disk, which spread over multiple sectors, and the FMS would pull in whatever sector of it that is needed. It had also support for subdirectories - but I somehow lost interest in it.

[firebottle]

9 hours ago, Nezgar said:

2GB is insanely colossal in the context of an 8088 PC though. You'd probably do better using a number of smaller partitions for day to day use.

Fortunately, we have all the time in the world right now to wait for a command to complete.

[drac030]

13 hours ago, Rybags said:

I thought CP/M was using it first but supposedly not.

CP/M 2 maps files keeping a list of "blocks" (= clusters in MS-DOS terminology) as a part of the directory entry. When an entry is full (it can keep a number of blocks enough to store 16k of the file's data), the BDOS creates another directory entry for the same file and saves additional block numbers there. And when this one is full too, yet another entry is created and so on.

 

When one takes a look at the file systems which were in use in 70/80s, the SDFS really looks sane, clean and efficient

[+Nezgar]

So... anyone skilled in the art of disk forensics can maybe enlighten me here..

 

I've done a very high level compare of DOS 1.0 images from three different sources now( @KLund1's dump, one from AtariMania, and one from a ZIP called "Atari DOS Collection" can't remember where from, maybe pigwa), and they each compare slightly differently, with different CRC... And it's not just due to ATR headers and such. Copying to a real disk and back to a fresh ATR in RespeQt returns the same CRC32. The sectors with data are the same when seen in a sector copier. I've copied all three into files with SCP, and those all are the same size, but result in 3 slightly different compressed sizes when ARC'd, suggesting slightly different content.

 

Maybe one of more of these have been modified in subtle ways for write without verify, different number of drive buffers, open files, etc?

 

Anyhow, attached is the 'working set' of 3 DOS 1 ATR's I've been comparing.

DOS 1.zip

[tschak909]

Could we move something more unixy to the Atari? something with the ability to have multiple levels of linked lists, and/or extents?

 

-Thom

[_The Doctor__]

To add to the fun, there were two different version of DOS 1 iirc... oh and no revision number or way to know what's what by the name as they were the same...

 

common reasons are as you suggested for the differences... but also a copy to a disk that wasn't blank... or the disk was formatted and then sector copied to... blank sectors written or not written... there's a whole party to be had... but your right somebody could give it a quick look over...

Edited March 25, 2020 by _The Doctor__

[jamm]

I didn't dig very deeply into the differences, but I did do a quick binary comparison.  I think a block of sectors towards the beginning is different for the reason @_The Doctor__ mentioned: there was old data on the disk this got copied to.  There are two other interesting differences, though:

• At offset 0x1474, the AtariMania version has the message: TYPE "Y" TO FORMAT DISK 2 where the other two versions say TYPE "Y" TO FORMAT DISK 1
• At offset 0x1DB3, each version has a different error message:
  • AtariMaina: ERROR- 128
  • Klund1: ERROR- 138
  • DOS Pack: ERROR- 170

 

Other than that, the images are identical.

 

[+DjayBee]

5 hours ago, jamm said:

I think a block of sectors towards the beginning is different for the reason @_The Doctor__ mentioned: there was old data on the disk this got copied to. 

Nope these differences are a buffer for the keyboard input, another buffer for directory sectors and some $20 bytes of other data.

The buffers change when you enter a command like "C" and then "D1:FOO,D2:BAR" or just "A" for the display of the directory.

 

Codewise all three dumps are identical. The most empty buffers are on KLund1's image.

Edited March 25, 2020 by DjayBee

[+Nezgar]

12 minutes ago, DjayBee said:

Codewise all three dumps are identical. The most empty buffers are on KlunD's image.

Thanks, that means the other two were not "original" in the sense that "Write DOS File" was used at some point in the disks life.

 

Nice to know @KLund1's image is likely the most "original" dump.

 

Now I wonder about these "two different versions" that @_The Doctor__ suggested might be out there...

[jamm]

34 minutes ago, DjayBee said:

Nope these differences are a buffer for the keyboard input, another buffer for directory sectors and some $20 bytes of other data.

The buffers change when you enter a command like "C" and then "D1:FOO,D2:BAR" or just "A" for the display of the directory.

 

Codewise all three dumps are identical. The most empty buffers are on KlunD's image.

How did the buffer contents get written to disk?

[+DjayBee]

16 minutes ago, jamm said:

How did the buffer contents get written to disk?

As Nezgar wrote "Write DOS Files" writes the whole memory block including all internal working areas to the new disk. 

[KLund1]

45 minutes ago, Nezgar said:

Nice to know @KLund1's image is likely the most "original" dump.

 

The physical disk I have has no notch in the sleeve. The drive the disk came with is also unaltered. In fact, I think I was the first one inside since manufacture. Also looking at the other disks in the drive's collection, only shows purchased games, and applications. There was no 'copy' or 'utility' software.

I am 99.8 certain my copy is a genuine, unaltered copy.  

I do not have Kyoflux or anything like that. But If there are better settings for DiskWizard II or another program to get an even better copy, please let me know.

I did find the past page of the manual and scanned it. Perhaps someone could stitch them together.

 

 

img03252020_0001.pdf

[+Nezgar]

@KLund1 I am curious about the sector interleave of the original DOS 1.0 disk. Are you able to record an audio clip of that disk booting? If the disk uses the same interleave as a revision "B" 810 ROM format creates, the inter-sector delay will sound like longer periods of silence between each sector loading.

 

A Kryoflux would of course confirm that too, but an audio clip is simpler

[KLund1]

Here you go

 

 

[+Nezgar]

Cool thanks - yes, that's definitely the old 12:1 sector interleave!

[+Stephen]

49 minutes ago, Nezgar said:

Cool thanks - yes, that's definitely the old 12:1 sector interleave!

How cool is it, that we can gather SO much info from this old machine just by listening to the rhythm of the disk drive head clicks, or the SIO beeps and pauses?  It's like driving a really old car with manual transmission, manual breaks, manual steering.  You are just so connected to it, so many layers less abstraction, etc.  Very cool!