"HardDrive" Images

[flashjazzcat]

Minor issues: another user just pointed out to me that a 2,880 sector DD ATR is identified by RespeQt as a "HardDrive" [sic] image. This is a common floppy image size used - for instance - by XF551s with 720K 3.5" mechanisms. I assume the fact that "HardDisk" and "HardDrive" are written as single words is some carry over from prior versions. I also noticed 360K DD ATRs are labelled as "QD Diskettes". Perhaps QD shorthand for DS/DD (although I can find no mention of this terminology elsewhere), but quad-density (512bps) ATRs are verbosely labelled "512 bytes per sector".

Edited March 16, 2018 by flashjazzcat

[TheMontezuma]

Minor issues: another user just pointed out to me that a 2,880 sector DD ATR is identified by RespeQt as a "HardDrive" [sic] image. This is a common floppy image size used - for instance - by XF551s with 720K 3.5" mechanisms. I assume the fact that "HardDisk" and "HardDrive" are written as single words is some carry over from prior versions.

 

720K 3.5'' ?

Then it is not that common

 

Everything different from SD / ED / DD / QD is treated as a custom disk.

.

// SD = Single density
// ED = Enhanced density
// DD = Double density
// QD = Quad density    

// Density  sides TPS SPT BPS enc  total  bytes
// SD         1   40  18  128 FM   92160  (90K)
// ED         1   40  26  128 MFM 133120 (130K)
// DD         1   40  18  256 MFM 183936 (180K)
// QD         2   40  18  256 MFM 368256 (360K)

where:
TPD = Tracks per (disk) side
SPT = Sectors per track
BPS = Bytes per sector

.

 

I also noticed 360K DD ATRs are labelled as "QD Diskettes". Perhaps QD shorthand for DS/DD (although I can find no mention of this terminology elsewhere), but quad-density (512bps) ATRs are verbosely labelled "512 bytes per sector".

 

Yes, QD seems to be a shorthand for DS/DD.

 

I understand that this is wrong, since the name Quad Density shall refer only to disks with 512 bytes per sector, correct?

Do you propose to change QD name to DS/DD for such 360K ATR Disks?

 

ATR header provides information about bytes per sector. Possible values are 128, 256, 512.

Knowing a disk size and BytesPerSector, you can derive other parameters for well knows disk formats.

 

Are the following parameters correct for a Quad Density 720K disk?

// Density  sides TPS SPT BPS enc  total  bytes
// QD         1   80  18  512 MFM 737280 (720K)

If yes, it can easily be identified.

Are there any other well knows formats?

 

What about 720K 3.5'' 2,880 sector DD ATRs ?

 

The other formats are treated as a custom disk, where:

Sides=1

TPS=1

SPT = size / bytesPerSector;

 

A few links:

https://www.atarimax.com/ape/docs/DiskImageFAQ/

http://www.atarimania.com/faq-atari-400-800-xl-xe-what-other-floppy-disk-drives-can-i-use-with-my-atari_23.html

http://www.abbuc.de/community/forum/viewtopic.php?f=3&t=3850&start=0#p24978

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

[+CharlieChaplin]

Hmmm,

 

thought I have seen 5,25" DD-Disks with 48 TPI and 5,25" QD/Quad-Disks with 96 TPI (not HD and thus usable on a 1050 or XF551).

 

720k is not nescessarily a harddisk size, could be an XF with 3,5" or a third party 5,25" or 3,5" drive (HDI, Karin Maxi, TOMS, etc.).

 

Think the name "Quad Density" for 360k disks was introduced with some german DOS programs (Bibo-DOS, Turbo-DOS) and sector copy programs (Copy 2000, Sector Copy Quad, XF551 Copy, etc.), since the vendors (e.g. Compyshop) always stated it is 4x the capacity of a single density (90k) disk, whereas most (all?) US copy programs and DOS versions used the correct name DS/DD. Read also a few articles where they wanted to name 720k "Octa Density", but since no german DOS or sector copy program (or disk drive, besides the HDI which was just an interface for 5,25" or 3,5" drives) became available that could handle 720k, it never became a standard or common name for 720k disks here.

Edited March 16, 2018 by CharlieChaplin

[flashjazzcat]

I think QD generally implies 512bps. 720KB is common enough to be listed as a default ATR floppy geometry in Altirra (when creating a new ATR). With ATRs, one must of course Intuit whether the geometry implies a HDD image or a floppy. I already do this in the U1MB PBI BIOS in order to return sensible PERCOM data for mounted ATRs, and when deciding to allow emulation of a dummy low-level format.

Edited March 17, 2018 by flashjazzcat

[+DrVenkman]

Generally speaking, it's probably a good idea to update, modernize and harmonize the RespeQt terminology to line up with how Altirra uses it, and how Jon handles things in the U1MB PBI BIOS.

 

Having said that, I don't know how active Joey Z. is these days, nor whether any pull requests in Git would be enough for his thinking to warrant at least a fractional point release if he's around.

[phaeron]

FYI, the extended image types in Altirra are derived from the SpartaDOS X formatter and aren't particularly well researched.

[HiassofT]

Yes, QD seems to be a shorthand for DS/DD.

 

I understand that this is wrong, since the name Quad Density shall refer only to disks with 512 bytes per sector, correct?

Do you propose to change QD name to DS/DD for such 360K ATR Disks?

DS/DD would describe the (XF551) format better IMHO.

 

Calling 512 bytes/sector formats QD isn't quite accurate though, if you look over to MSDOS formats you have the same physical bit length on disk as with DD - eg for 360k 9 512-byte sectors instead of 18 256-byte sectors on each track. The bit density and total disk capacity doesn't change so there's no reason to call that quad density.

 

Everyone seems to have a slightly different understanding what the term "density" means so maybe it's better to avoid the term for unusual formats, it'll always be somewhat ambiguous.

 

That being said I have no problem if you name 512 bytes-per-sector images "QD". After all, it's just a name that hasn't been used consistently before.

 

Are the following parameters correct for a Quad Density 720K disk?

// Density  sides TPS SPT BPS enc  total  bytes
// QD         1   80  18  512 MFM 737280 (720K)

 

Better make that 2 sides with 9 sectors per track. 18 512 bytes sectors would he the "HD" format on PC.

 

What about 720K 3.5'' 2,880 sector DD ATRs ?

2 sides, 80 tracks, 18 256-bytes sectors per track.

 

If you start adding percom block info for the less common formats it would be best to stick to the standard layouts. An overview is eg here: https://en.wikipedia.org/wiki/List_of_floppy_disk_formats

 

so long,

 

Hias

[flashjazzcat]

Just checked and in the U1MB BIOS I'm currently returning synthesised floppy PERCOM data for the same set as RespeQt (SD, ED, DD, DS/DD), plus 720K 80 track DS/DD (2 sides, 80 tracks, 18 sectors per track, MFM encoding). I couldn't think of any others at the time I drew up that list (some years ago).

[TheMontezuma]

Think the name "Quad Density" for 360k disks was introduced with some german DOS programs (Bibo-DOS, Turbo-DOS) and sector copy programs (Copy 2000, Sector Copy Quad, XF551 Copy, etc.), since the vendors (e.g. Compyshop) always stated it is 4x the capacity of a single density (90k) disk, whereas most (all?) US copy programs and DOS versions used the correct name DS/DD. Read also a few articles where they wanted to name 720k "Octa Density", but since no german DOS or sector copy program (or disk drive, besides the HDI which was just an interface for 5,25" or 3,5" drives) became available that could handle 720k, it never became a standard or common name for 720k disks here.

 

I'm right now visiting a small VCF in Hannover.

 

I have talked to Stefan Dorndorf (QMEG developer) and he explained me that the 360k DS/DD format was supported by Atari XF551 disk drives.

Such disk format was commonly called QD (360K = 4 x 90K):

http://www.abbuc.de/atari/94-hardware/hardwarekatalog/1601-atari-xf551

 

At the end it is only a name and since "QD" looks better than a long "DS/DD" I don't see a real reason to change that.

 

As Hias mentioned, calling 512 bytes/sector formats QD is also not fully correct.

CharlieChaplin mentioned that 720K were called OD "Octa Density".

 

Introducing this geometry would influence the PERCOM block handling, so I think it is worth to support it:

OD "Octa Density": 2 sides, 80 tracks, 18 sectors per track, 256-bytes per sector

 

We would end up with the following "well known" disk formats abbreviations:

SD, ED, DD, QD, OD

 

Otherwise we would need to use very long names to distinguish between QD and OD:

- DS/DD

- 720K 80 track DS/DD

 

EDIT:

 

Or is it better to call them:

DS/DD

720K DS/DD

?

 

QD format (or 360K DS/DD) was supported by DOS XE. Was it officially called DS/DD?

 

Perhaps the following naming convention would be more clear?

SS/SD, SS/ED, SS/DD, DS/DD, 720K DS/DD

Edited March 17, 2018 by TheMontezuma

[flashjazzcat]

When I type "quad density diskette", Google claims that:

 

A quad density disk is a 5¼" floppy disk with a storage capacity of 720 kilobytes.

If we're talking about common usage, the only place I recently saw the term QD used is on the AA forum when discussing 512bps hard disk partitions. That may be technically incorrect as well, but "QD" seems to me inherently ambiguous. I kind of like the suggested naming conventions which omit "QD" entirely, but at the end of the day things will look better if "HardDrive" and "HardDisk" are simply split into two words, and if some consistency is adopted as to which name to employed.

 

 

Here we see "HardDrive", "HardDisk" and "harddisk", all alluding to "hard disk".

Edited March 17, 2018 by flashjazzcat

[lemiel]

SIO2BSD uses another types:

• 90k or ss/sd,
• 130k or ss/ed,
• 180k or ss/dd,
• 360k or ds/dd,
• 720k or ds/qd,
• 1440k or ds/hd,
• 16m,
• 32m.

Via http://atariki.krap.pl/index.php/SIO2BSD#Inne

[TheMontezuma]

There is nice description at the Atariki:

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

It tells about the following single and double sided disk formats:

SS/SD      (90K, 128 bytes per sector,  720 sectors, 18 sectors per track, 40 tracks)
SS/ED     (130K, 128 bytes per sector, 1040 sectors, 26 sectors per track, 40 tracks)
SS/DD     (180K, 256 bytes per sector,  720 sectors, 18 sectors per track, 40 tracks)
SS/QD     (360K, 256 bytes per sector, 1440 sectors, 18 sectors per track, 80 tracks)
SS/DD 512 (180K, 512 bytes per sector,  360 sectors,  9 sectors per track, 40 tracks)
          (360K, 512 bytes per sector,  720 sectors,  9 sectors per track, 80 tracks)
SS/HD     (720K, 256 bytes per sector, 2880 sectors, 36 sectors per track, 80 tracks)


DS/DD     (360K, 256 bytes per sector, 1440 sectors, 18 sectors per track, 40 tracks per side)
DS/QD     (720K, 256 bytes per sector, 2880 sectors, 18 sectors per track, 80 tracks per side)
DS/DD 512 (360K, 512 bytes per sector,  360 sectors,  9 sectors per track, 40 tracks per side)
          (720K, 512 bytes per sector,  720 sectors,  9 sectors per track, 80 tracks per side)
DS/HD    (1440K, 256 bytes per sector, 2880 sectors, 36 sectors per track, 80 tracks per side)

All those formats are related to the Atari 8-bit computers and all were supported by existing floppy drives.
OK. Some of them were exotic, like TOMS, Karin, etc.

If you only know the disk size and the number of bytes per sector (from ATR header),
you can't (for example) say if it is a "DS/DD" or a "SS/QD" disk (both support 360K and have 256 bytes per sector).
The ATR header does not simply allow for a unique identification.

At the end it is only a name, but I agree that the naming shall be at least consistent across RespeQt.

I have built (only for Windows) a RespeQt version that identifies (additionally to SD/ED/DD):

- 360K disks as DS/DD

- 720K disks as DS/QD (naming from Atariki and sio2bsd)

The writing of a "hard disk" name is also corrected.

 

This version is built on top of the development branch and contains all features developed since r4 release.

RespeQt-r4_DSDD.zip

Edited March 18, 2018 by TheMontezuma

[flashjazzcat]

Most interesting link, and many thanks for the new build.

[TheMontezuma]

Most interesting link, and many thanks for the new build.

 

Hi,

I wondered if this "development drop" properly shows disk formats of your disks?

 

I still have doubts what is a better name for a 720K:

"DS/QD" or maybe "DS/DD 80 tracks"

 

What do you think ?

 

Regards

Marcin

[HiassofT]

I'd stick to 720k. The meaning of 90/130/180/360/720k is pretty clear in the context of Atari floppy disk formats - 360k is associated with XF551 and 720k XF551 with 3.5" mech using 80 tracks per side.

 

so long,

 

Hias

[TheMontezuma]

I'd stick to 720k. The meaning of 90/130/180/360/720k is pretty clear in the context of Atari floppy disk formats - 360k is associated with XF551 and 720k XF551 with 3.5" mech using 80 tracks per side.

 

so long,

 

Hias

 

RespeQt shows the actuall disk size in brackets, behind the format name.

 

If we could call both formats "DS/DD":

2 sides, 40 tracks per side, 18 sectors per track, 256 bytes per sector
2 sides, 80 tracks per side, 18 sectors per track, 256 bytes per sector

then they would be presented as:

DS/DD (360K)

DS/DD (720K)

 

Is it correct?

[HiassofT]

As we have no geometry information in ATR etc and setting up well known percom blocks by guessing from the number of sectors is mostly important for older DOSes the way you present it is more or less cosmetical - choose whatever you like best, 720k or 2880 sectors SD should be easily recognizable to users as well.

 

My personal preference is for short names/terms, but I'm a tech guy, not a UI expert :-)

 

so long,

 

Hias

[HiassofT]

Forgot one important thing: You should treat image size (number of sectors) and geometry as 2 different things - both in the drive emulator and in the GUI.

 

When you configure a drive via percom put (eg with the "configure drive" option in MyDOS) you have geometry information available. That could also be eg a 720 sectors SD "hard drive" setup (1 track, 1 side, 720 sectors of 128 bytes). The drive emulator then has to decide what to do with this info, accept it (and calculate the number of total sectors from it) or reject it.

 

So if you want to accept rather arbitrary geometry layouts from the percom block and show geometry info in the GUI you have to use this information.

 

Probably noone will care about the actual geometry info, except maybe a few expert users trying to diagnose some odd issues with DOSes/programs that are picky about drive geometry.

 

The important info, which is also preserved when saving and later loading an ATR is the number of sectors and the size of each sector.

 

When creating a new image you could present options to specify the geometry - but as there are practically no use cases for that it would only be confusing to users.

 

So, I'd say, best keep it simple. Leave the geometry info out, display it only on demand or display it as secondary info after/below the image size.

 

The primary info should be the unambiguous number of sectors+density and when creating new images standard options like 90/130/180/360k should be well understood by users.

 

so long,

 

Hias

[TheMontezuma]

Forgot one important thing: You should treat image size (number of sectors) and geometry as 2 different things - both in the drive emulator and in the GUI.

 

When you configure a drive via percom put (eg with the "configure drive" option in MyDOS) you have geometry information available. That could also be eg a 720 sectors SD "hard drive" setup (1 track, 1 side, 720 sectors of 128 bytes). The drive emulator then has to decide what to do with this info, accept it (and calculate the number of total sectors from it) or reject it.

 

So if you want to accept rather arbitrary geometry layouts from the percom block and show geometry info in the GUI you have to use this information.

 

Probably noone will care about the actual geometry info, except maybe a few expert users trying to diagnose some odd issues with DOSes/programs that are picky about drive geometry.

 

The important info, which is also preserved when saving and later loading an ATR is the number of sectors and the size of each sector.

 

When creating a new image you could present options to specify the geometry - but as there are practically no use cases for that it would only be confusing to users.

 

So, I'd say, best keep it simple. Leave the geometry info out, display it only on demand or display it as secondary info after/below the image size.

 

The primary info should be the unambiguous number of sectors+density and when creating new images standard options like 90/130/180/360k should be well understood by users.

 

so long,

 

Hias

 

Yes, this is what RespeQt actually does. It uses (for formatting) a disk geometry information derived from a PERCOM block if received from a DOS.

 

However when we format a disk according to the information from a PERCOM block and store the disk as ATR image, it does not preserve the geometry.

When we later open the ATR image, ResepQt knows only the number of sectors and the size of each sector and may show different disk format as originally requested.

 

I talked to Stefan and he explained me that a DOS is actually only interested in a number of sectors and a sector size.

Physical storage parameters should actually be a "private" matter of a floppy drive,

but for some reasons a PERCOM block includes also "low level" information like: "Number of Tracks" and "Sectors per Track".

This values have to provided to a floppy drive from a DOS, however a better way would be to provide an overall "number of sectors" instead (and let floppy drive handle the way how the sectors are physically stored).

[flashjazzcat]

Track info is sometimes used by an Atari DOS's formatter to determine whether a low-level format should be allowed on the volume. Single track is usually assumed to be a hard disk, IIRC. Not that one would want to low-level format an ATR, but implementing dummy low-level format functionality (which is in turn dependent on the formatter receiving appropriate floppy disk geometry) can be rather useful when you want to write a blank file system to an ATR while using a DOS which insists on first performing a low-level format.

[Kyle22]

I didn't see any 8 inch formats in that list.

2002 sectors SS/DD, 4004 sectors DS/DD.

 

Edited September 5, 2019 by Kyle22
77 Tracks, 26 SPT. Do the math. they go to 1Meg size.

[TheMontezuma]

Are such formats related to any ATARI compatible disk drive?

https://en.wikipedia.org/wiki/List_of_floppy_disk_formats

[_The Doctor__]

Yes wiki is wrong...

Atari used 5 1/4 percom quads (Starship BBS went with this x2 for initial storage and later added hard drives)

Before that 8 inch drives were in use (Turbo Twin 2000 BBS used two 8 inch SIO drives for storage)

 

recently Curt posted about the PCB and posted pictures etc.

 

as soon as I find a decent power supply I hope to bring the 8 inch SIO drive back to life.

[Jeffrey Worley]

On 3/16/2018 at 7:24 AM, flashjazzcat said:

Minor issues: another user just pointed out to me that a 2,880 sector DD ATR is identified by RespeQt as a "HardDrive" [sic] image. This is a common floppy image size used - for instance - by XF551s with 720K 3.5" mechanisms. I assume the fact that "HardDisk" and "HardDrive" are written as single words is some carry over from prior versions. I also noticed 360K DD ATRs are labelled as "QD Diskettes". Perhaps QD shorthand for DS/DD (although I can find no mention of this terminology elsewhere), but quad-density (512bps) ATRs are verbosely labelled "512 bytes per sector".

I've been curious about that QD term myself in this application.  The term was never an official one and  dates at least to my early Atari days, referring to 80-track (or 77-track) drives:

 

sssd - Single Sided Single Density (128 byte sectors, 18 sectors per track) 40 tracks are assumed.

ssdd - Single Sided Double Density (256 byte sectors, 18 sectors per track )

ssed - Single Sided Enhanced Density (also called Dual Density, or 'Density-and-a-half'  (128 byte sectors, 26 sectors per track)

QD    - Denotes 80 tracks, 18 sectors per track, double-sided, for a yield of 720kb, but which term was generically applied to any disk mechanism capable of storing this format, though these mechanisms could produce 80-track single- or enhanced-density formats as well.  So the term is sloppy and ill-suited to the task in either RespeQT, or AtariSIO (what I use and which is the root of RespeQT), from which latter I suspect RespeQT inherited the QD description.

 

Best,

 

Jeff

[+Nezgar]

I always thought of "quad density" as 5.25" DSDD, 40 tracks on each side (80 tracks total), like a double sided XF551 disk as "quad" since it double of a single sided double density disk. But indeed it would also match a single sided 80 track disk, but those were usually not 5.25".