Jump to content
IGNORED

DOS, Disks, Density and Sector counts... education question.


kheller2

Recommended Posts

Why couldn't one create 26 double density sectors? Not enough physical media space per track?

 

Poking around the Internet I couldn't find a well articulated discussion on exactly what is different on the physical media, let alone magnetic data portion, of a SD sector vs a DD sector. The reason I'm going down this strange path of thinking was how could Atari squeeze 26 sectors for their Enhanced/Dual Density format with SD sectors.

 

I also saw that SD is done with FM, and DD with MFM. I'm assuming that ED was done with MFM but then ED disks are readable in an 810 drive which, I thought was only FM.

 

I also read that there is absolutely no difference between a SD and a DD disk when it comes to magnetic formulation. I find this a bit questionable given my experience with SD disks and that there is a major difference between DD and HD.

 

Can someone hit me with a stick and educate me?

 

Karl

 

Link to comment
Share on other sites

The formulation and coercivity may be the same, but there is also a certification rating involved. SD disks are "certified" for 3000bpi, where DD is "certified" for 6000bpi.

 

Whether they are "really" the same, or they will be unreliable, probably depends on your usage of them. It may work fine, you may have errors.

  • Like 1
Link to comment
Share on other sites

Yes, SD = FM, and ED & DD are MFM. Because ED uses MFM, its technically 'Double Density' that's why Atari initially started calling it that at first to much confusion. ED uses the same encoding as DD, but with 26 128 byte sectors per track instead of 18 256 byte sectors. With all the extra headers and sector spacing, it only yielded about 40% more usable data over SD. MFM encoding allowed those 128 data bytes to take less physical space.

 

ED formatted disks are in fact NOT readable in an 810 because the sectors are encoded in MFM, which the 810 controller cannot decode (only FM as you knew).

 

MFM allows 256 encoded bytes to take the same physical space as 128 bytes encoded in FM. This would in theory allow at most 1 more sector on the track without overwriting the first sector. The 'gap' between sectors, and between the last & first is needed to allow for RPM variations at format and writing time. A lot of SD protections which included a 'phantom' or 'double' sector would make a 19th sector with the same ID as one of the first 1-18, while ensuring that there are no missing sectors. (Also used for protection)

 

You may have been confused because using DOS 2.0 style DOS that was not designed for ED (more than 720 sectors) with a drive that DOES support ED, will at least be able to read the Directory/VTOC and the files placed on the first 720 sectors. This is why DOS 2.5 by default marks files with sector allocations beyond 720 with <> around the filenames.

 

When using DOS 2.5, which was officially modified to support up to 1023 sectors (the maximum sectors of the DOS 2.0S 10-bit sector links) meant there were still 17 or so sectors that were unusable by DOS 2.5. DOS 3 could address the full disk capacity, but the large 'cluster' allocation was wasteful on such small media (allocating 8 128byte sectors at a time) and the fatal flaw of 1 way file conversion from DOS 2 to 3 disks, not the other way around... This is where the alternate DOS's with their own proprietary or enhanced DOS-2 like filesystems like Sparta, MyDOS, DOS XL/XE, etc came in because they could use the full sector count, as well as myriads of even higher capacity drives.

 

The full capacity of a Double-Sided Double Density XF-551 could not be realized with DOS 2, 2.5, or 3. DOS XE when it finally came out was capable, and would have been wonderful if it came out at the time of and instead of DOS 3.0 with its high capacity disk support, long file names, and date stamps to name a few minor features. But by then most power users had moved on to MyDOS or SpartaDOS which already supported pretty much all known high capacity floppy drives, 16MB hard drive partitions, and time/date stamping.

Link to comment
Share on other sites

 

 

You may have been confused because using DOS 2.0 style DOS that was not designed for ED (more than 720 sectors) with a drive that DOES support ED, will at least be able to read the Directory/VTOC and the files placed on the first 720 sectors. This is why DOS 2.5 by default marks files with sector allocations beyond 720 with <> around the filenames.

 

 

 

 

What confused me was this article in Antic: https://www.atarimagazines.com/v4n3/AboutDOS.html

 

" Otherwise, this new DOS looks and acts exactly like DOS 2.0. The menu will be reassuringly familiar as there has been only one addition: Option [P] on the DOS 2.5 menu will allow 1050 disk drive users to force a single density disk format instead of the default enhanced density.

Those of you with 810 drives need not despair, this DOS is for you too. Although you will not be able to use the enhanced density feature, you can boot DOS 2.5 disks that were formatted and written in single density on 1050 drives. The way that DOS 2.5 handles this is to "hide" files from the 810 drive that cross over sector 720, which is normally the last DOS 2.0 sector. If you completely fill a DOS 2.5 disk (1010 sectors) on a 1050 and then check the disk directory at some point you will see files listed like this:

FILE1.BAS 025

<FILE2.BAS> 025

This tells you FILE1.BAS is entirely contained within the first 720 disk sectors and can therefore be accessed by an 810 drive. The file(s) with the "< >" characters around them are NOT accessible with an 810 drive because they are physically located where the 810 drive can't read them. So if you have an 810 and ask your friend with a 1050 to copy some of his files, make sure the files you want don't have <> around them!"

I've noticed a great deal of bad information published in the magazines of yore.

Link to comment
Share on other sites

Interesting, yeah, the first sentence in that article is technically correct. DOS 2.5 will work just fine with an 810, and it can read disks formatted by DOS 2.5, but only if the disk was formatted in single density, and format command will fail, only 'format single' will work.

 

The 2nd sentence that talks about accessing sectors over 720 on the 810, this is not possible. The 810 can not physically read any ED sectors. This is only applicable as a warning for files that cannot be accessed using DOS 2.0 with a 1050 (or other ED capable) drive.

Although you will not be able to use the enhanced density feature, you can boot DOS 2.5 disks that were formatted and written in single density on 1050 drives. The way that DOS 2.5 handles this is to "hide" files from the 810 drive that cross over sector 720, which is normally the last DOS 2.0 sector. If you completely fill a DOS 2.5 disk (1010 sectors) on a 1050 and then check the disk directory at some point you will see files listed like this.

  • Like 1
Link to comment
Share on other sites

And errrm, to answer your first question... it is possible to create a disk/disk-image with 26 sectors per track and 256 bytes (DD) per sector. One could use MyDOS or SpartaDOS to do that. Problem is, that this format is non-standard and can only be created and copied with MyDOS or SpartaDOS (and or file-copy programs working under these DOS versions). Think there is no FDD sectorcopy program, especially none that detects the format/density automatically, that could detect and copy such a disk/disk-image with 26 sectors per track and dd... but it is doable... (there are however a few harddisk sector copy programs, where one can input the start and end sector and the format/density manually, these should work with such a strange format).

  • Like 1
Link to comment
Share on other sites

Why couldn't one create 26 double density sectors? Not enough physical media space per track?

That's correct. There is not enough space at that density. You would need an even higher density, like "HD" for that.

 

Poking around the Internet I couldn't find a well articulated discussion on exactly what is different on the physical media, let alone magnetic data portion, of a SD sector vs a DD sector.

As already answered, the difference is the encoding, FM vs MFM.

 

I also read that there is absolutely no difference between a SD and a DD disk when it comes to magnetic formulation. I find this a bit questionable given my experience with SD disks and that there is a major difference between DD and HD.

It is only partially true that there is no difference between SD and DD at the magnetic level. The flux transition density is the same. In other words, the distance between changes of magnetic polarity, at a given cylinder, are the same. You get twice the data density, only as a result of using a more efficient and less redundant (MFM vs FM) encoding. But FM, precisely because the extra redundancy, is more reliable and can tolerate more bit shift (distortions of the flux transitions) .

 

It is very similar to MFM vs RLL. The flux density is the same. That's why most MFM hard disks could be used with an RLL controller. But only most, not really all, because RLL has even less redundancy that MFM and requires slightly more accuracy.

 

And errrm, to answer your first question... it is possible to create a disk/disk-image with 26 sectors per track and 256 bytes (DD) per sector.

I don't see how you could do that. Not with a standard drive and controller. There is simply not enough space. You can do that by increasing the density one way or the other (slower RPM, faster controller clock, etc).

Link to comment
Share on other sites

I don't see how you could do that. Not with a standard drive and controller. There is simply not enough space. You can do that by increasing the density one way or the other (slower RPM, faster controller clock, etc).

I am not disputing this, I am the farthest from a hardware guy. But how was it possible for the 1050 to do 26 sectors @ 128 bytes (as opposed to 18)? Did they basically write data at "double density" rate, but somehow manage 128 byte sectors because they only had RAM in the RIOT?

Link to comment
Share on other sites

At the disk level, more sectors = more overhead since each one has multiple extra bytes for stuff like sync, id, CRC etc. So you have more efficiency using bigger sectors.

But yeah, bigger sectors mean more buffer space needed. At the drive level as well as the computer.

Likely the choice made was to remain largely compatible with what most people already had and to keep the cost down.

 

I also think Atari were probably a bit paranoid about pushing the edge with media density. Though really by 1983 floppies were fairly reliable.

 

I'm not sure about the controllers in the 810 and 1050, but the 1772 controller in the ST is able by default to deal with 128, 256, 512 and 1024 byte sectors.

It can also do read and write track operations but since the write track command treats certain byte values as special commands it's only really useful for formatting.

Link to comment
Share on other sites

I am not disputing this, I am the farthest from a hardware guy. But how was it possible for the 1050 to do 26 sectors @ 128 bytes (as opposed to 18)? Did they basically write data at "double density" rate, but somehow manage 128 byte sectors because they only had RAM in the RIOT?

Yes, the 1050 writes at double density, only that with a smaller sector size. Why Atari did that, I don't know for sure.

 

I'm not sure about the controllers in the 810 and 1050, but the 1772 controller in the ST is able by default to deal with 128, 256, 512 and 1024 byte sectors.

Yes, both the 810 and the 1050 controllers support the bigger sector sizes. Actually the 810, besides the "standard" sector sizes, it also supports an alternate method with even more sizes. That alternate method is not compatible with the standard one.

  • Like 2
Link to comment
Share on other sites

Using "|" characters to roughly illustrate the track and sector headers and such, numbers to illustrate the actual sector data and a monospace font should help visualize the physical layout.

SD or DD track with 18 sectors of 128 bytes with FM, or 256 bytes with MFM

|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|

ED track with 26 sectors or 128 bytes with MFM
                   1                   2
|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|6|4|5|6|

As you can see, the total track length is about the same.

Technically, more user data could have fit on a track using larger sectors of 512 or 1024 bytes, as there would have been fewer inter-sector gaps/headers.

  • Like 1
Link to comment
Share on other sites

I am not disputing this, I am the farthest from a hardware guy. But how was it possible for the 1050 to do 26 sectors @ 128 bytes (as opposed to 18)? Did they basically write data at "double density" rate, but somehow manage 128 byte sectors because they only had RAM in the RIOT?

 

When "Atari Single Density" (18 sectors per track @ 128 bytes per sector) is used, the FDC (Floppy Disk Controller @ 1050 drive) is set to technical "Single Density" using FM recording at 125 KHz bitrate.

 

When "Atari Medium / Enhanced Density" (26 sectors per track @ 128 bytes per sector) is used, the FDC is set to technical "Double Density" using MFM recording at 250 KHz bitrate.

 

"Atari Double Density" (18 sectors per track @ 256 bytes per sector) uses the same setting like "Medium Density". And, just for the records, "HD" mode (5.25" and 3.5" drives) uses MFM with 500 KHz and (by MS-DOS default) 18 sectors with 512 Byte each.

 

The limitation of 18 sectors using 256 bytes each sector and "real" double density is made to make the floppy disc´s access reliable. The outer tracks (track 0) could be hold, I think, something around 22 or 23 sectors in maximum, because there´s more physical space each track than the inner track (39). In the early years some 5.25" drives exists which such special formats - some of them also change the rotation speed in relation to the track number (head position) - the legendary "Victor 1" PC made such a thing, sounds very unique :)

  • Like 2
Link to comment
Share on other sites

The Atari drives are CAV which means the physical density is more towards the centre so more chance of errors there. The amount of the track actually used as a percentage of the circumference of each track is the same regardless of track #

The C=154x drives are also CAV but vary the bitrate to allow different number of sectors at various parts of the disk. https://en.wikipedia.org/wiki/Zone_bit_recording

Though on the flipside, early 154x drives were so bad that they only used the first 35 tracks.

 

Early Apple Mac drives acheived variable density by varying the drive speed.

 

Supposedly there's more sync and inter-record bytes than actually needed being used - possibly some optimization could have been had on the outer tracks by using less - although removing several bytes per sector would barely repay the price of the data payload of an extra sector.

  • Like 1
Link to comment
Share on other sites

And, just for the records, "HD" mode (5.25" and 3.5" drives) uses MFM with 500 KHz and (by MS-DOS default) 18 sectors with 512 Byte each.

 

Actually, 5.25" HD disks typically work at 300 Kbs, not at 500 Kbs, and are normally formatted with 15 sectors, not 18. That's why the hold 1.2MB instead of 1.44MB.

  • Like 2
Link to comment
Share on other sites

  • 2 months later...

Maybe not directly linked to the topic, but anyway...

I still wonder which disk format to use for my Atari projects as ultimate standard to accomodate most users with their disk drives. I am aware 1050 is most used, but some use 810 or those with DD standard.

Currently I use single density (SD, 90K) standard to ensure most users can use my game/program disk. 130K is little more but I am not sure it is worth to forget 810 users.

 


Link to comment
Share on other sites

If you're doing raw sector access then it becomes a situation of needing to commit to a given architecture.

 

If you're using a file system and Dos or miniDos that can handle different formats then it can be more versatile.

In theory you could cater for 16 Meg disk/images.

The idea I have for that is have your files named uniquely per "smallest disk size" then have an ID file that resides on each floppy.

To detect if the disk you want is inserted, look for it's ID file. Prompt the user to insert the disk if it's not there.

 

On a 16 Meg image of course you'd likely fit the entire production, so all the ID files would be there and no need to prompt for disk swaps.

 

Of course this is a somewhat rareified example as the vast majority of Atari disk games just use raw sector access.

  • Like 1
Link to comment
Share on other sites

I think the best is 90K, even if a game requires disk swaps (please support multiple drives too!) for all users. I love my DD disk drives, but I'm happy with DD for personal use when making disk images for multiple .xex games or my own files, but maximum compatibility with 810 up is the best for .ATR releases. Also, until something is done with Xbios, please don't use it, I have nothing but trouble with those disks, even if I revert everything on my system to stock, like OS and drive speed, there are sometimes loading issues, but I don't want to have to revert my system to stock profile for a game! I know Xbios is for memory reasons, but there must be a better way!

  • Like 1
Link to comment
Share on other sites

Also, until something is done with Xbios, please don't use it, I have nothing but trouble with those disks, even if I revert everything on my system to stock, like OS and drive speed, there are sometimes loading issues, but I don't want to have to revert my system to stock profile for a game!

 

 

http://a8.fandal.cz/detail.php?files_id=7034

 

have you any problem with this demo?

Link to comment
Share on other sites

 

 

http://a8.fandal.cz/detail.php?files_id=7034

 

have you any problem with this demo?

I will check it and see...actually, that is the very first xbios .ATR I have ever gotten to load with my Warp+ OS and high-speed Happy drive set as normal! It's too bad it still forces a 1x load speed though. If that's the latest though, it would be nice to get all the games that use Xbios this version so they all load right from the start without reverting my system and jumping through hoops to get them to load. But WHY does it have to force 1x SIO speed?!?

 

But if all future Xbios games load like this, I'm happy and it totally changes my mind about Xbios use. Still...we need new version of previous releases using it!

Edited by Gunstar
Link to comment
Share on other sites

I hope now you understand that xBIOS gives you a wide range of possibilities and how it is used depends only on the programmer.


What you say about xBIOS is more or less like DON'T using knives for dinner because you can hurt yourself.

Link to comment
Share on other sites

Well, it's only natural when every time you've used a knife, you hurt yourself. This is the first time it didn't hurt. But it's not saying don't use dinner knives because you might hurt yourself, it's saying don't use that ONE PARTICULAR knife because it's dull and will hurt you!

 

But no, I really don't understand the possibilities of it, all I've heard was it's used for maximum memory to the program area. posting one demo that I am able to load up the first time doesn't explain ANY of Xbios possibilities to me, all I know is you *seem* to have changed it so it will load on other things now besides a stock OS and stock disk drive!

 

And, if it's down to how the programmers use it as to whether it works right or not only tells me it's a pain in the ass for programmers to use right! And that would lead straight back to YOU and how easy it is to use and how well documented it is for programmers to use right!

Edited by Gunstar
  • Like 1
Link to comment
Share on other sites

 

I hope now you understand that xBIOS gives you a wide range of possibilities and how it is used depends only on the programmer.
What you say about xBIOS is more or less like DON'T using knives for dinner because you can hurt yourself.

 

Something about this whole xbios situation struck me as familiar, but I just couldn't put my finger on it until now. It's like a scene from Star Wars episode 1! It goes something like this: "Xbios will work fine." "No, it won't." "Xbios will work fine." "No, it doesn't...Do you think you are some kind of Jedi waving your hands around like that? I'm Dinobulan, Jedi mind tricks don't work on me..."

 

I am only joking of course... :P

Edited by Gunstar
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...