Jump to content

Photo

"HardDrive" Images


19 replies to this topic

#1 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 14,493 posts
  • Location:United Kingdom

Posted Fri Mar 16, 2018 5:24 AM

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 by flashjazzcat, Fri Mar 16, 2018 5:34 AM.


#2 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Fri Mar 16, 2018 2:45 PM

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...s/DiskImageFAQ/

http://www.atarimani...y-atari_23.html

http://www.abbuc.de/...&start=0#p24978

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



#3 CharlieChaplin OFFLINE  

CharlieChaplin

    River Patroller

  • 3,089 posts

Posted Fri Mar 16, 2018 5:58 PM

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 by CharlieChaplin, Fri Mar 16, 2018 5:59 PM.


#4 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 14,493 posts
  • Location:United Kingdom

Posted Fri Mar 16, 2018 6:32 PM

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 by flashjazzcat, Fri Mar 16, 2018 6:32 PM.


#5 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,953 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Fri Mar 16, 2018 7:41 PM

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. 



#6 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,734 posts
  • Location:Bay Area, CA, USA

Posted Sat Mar 17, 2018 12:05 AM

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



#7 HiassofT OFFLINE  

HiassofT

    Stargunner

  • 1,131 posts
  • Location:Salzburg, Austria

Posted Sat Mar 17, 2018 4:26 AM

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...py_disk_formats

so long,

Hias

#8 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 14,493 posts
  • Location:United Kingdom

Posted Sat Mar 17, 2018 5:38 AM

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).



#9 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sat Mar 17, 2018 7:30 AM

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/...601-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 by TheMontezuma, Sat Mar 17, 2018 7:57 AM.


#10 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 14,493 posts
  • Location:United Kingdom

Posted Sat Mar 17, 2018 11:39 AM

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.  :)
 
Capture.PNG
 
Here we see "HardDrive", "HardDisk" and "harddisk", all alluding to "hard disk".

Edited by flashjazzcat, Sat Mar 17, 2018 12:07 PM.


#11 lemiel OFFLINE  

lemiel

    Moonsweeper

  • 279 posts
  • Location:Tychy, Poland

Posted Sat Mar 17, 2018 12:13 PM

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....hp/SIO2BSD#Inne



#12 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sun Mar 18, 2018 12:15 PM

There is nice description at the Atariki:

http://atariki.krap....rmaty_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.

Attached File  RespeQt-r4_DSDD.zip   18.09MB   72 downloads

 


Edited by TheMontezuma, Sun Mar 18, 2018 12:18 PM.


#13 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 14,493 posts
  • Location:United Kingdom

Posted Sun Mar 18, 2018 12:35 PM

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



#14 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Thu Mar 22, 2018 3:55 AM

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



#15 HiassofT OFFLINE  

HiassofT

    Stargunner

  • 1,131 posts
  • Location:Salzburg, Austria

Posted Thu Mar 22, 2018 1:46 PM

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

#16 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Thu Mar 22, 2018 2:32 PM

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?



#17 HiassofT OFFLINE  

HiassofT

    Stargunner

  • 1,131 posts
  • Location:Salzburg, Austria

Posted Thu Mar 22, 2018 3:53 PM

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

#18 HiassofT OFFLINE  

HiassofT

    Stargunner

  • 1,131 posts
  • Location:Salzburg, Austria

Posted Fri Mar 23, 2018 2:44 AM

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

#19 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Fri Mar 23, 2018 7:59 AM

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).



#20 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 14,493 posts
  • Location:United Kingdom

Posted Fri Mar 23, 2018 12:08 PM

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.





Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users