Do you want me to remove them images ? Cw
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Simon Owen Sent: 08 March 2001 10:15 To: sam-users@nvg.ntnu.no Subject: RE: Disk image formats Stuart Brady wrote: > BTW, what needs to be done to convert a sad file to a dsk and vice-versa? Use Aley's 2SAD program, which can convert to DSK or SAD (versions 1 and 2) ftp://ftp.nvg.ntnu.no/pub/sam-coupe/utils/disk/2sad.zip Alternatively, create a new DSK file in SimCoupe, mount both images and do a disk copy between them :-) > Dsks appear to be simple raw 819200 byte (800k) files. DSK files are that fixed at that size because they're always 2 sides x 80 tracks x 10 sectors x 512 bytes. The blocks of sector data are ordered: side 0 track 0, side 1 track 0, side 0 track 1, etc. SAD files have a 22 bytes header, which contains a rather large text signature and some geometry information. You can specify the number of sides, number of tracks per side, number of sectors per track and the bytes per sector. The SAD data order is different from DSK images, so you can't just chop the header from a 2:80:10:512 SAD image; instead it uses: side 0 track 0, side 0 track 1, side 0 track 2, etc. > So what's a sad version 1 and a sad version 2? Is version 2 *exactly* the > same, but gzipped? Indeedely-doo! > >And finally, SDF seems to be nice, but official format haven't been > >introduced yet. And - more sadly - the .SDF creator is not available. > > What does SDF do (which SAD doesn't do)? Though SAD provides some geometry control, it's a regular format used for the whole disk. So if you specify 1024 bytes per sector, that applies to every sector on every track. SDF represents a lower-level view of the disk, allowing more flexible control of what's in each track. So you can mix sector sizes within tracks, have unformatted tracks, and generally format up anything that you'd be able to do on a real SAM. It can also store deliberate disk errors, and allow tweaked ID FIELD values - the sorts of things that copy protected disks require. The overall SDF goal is to have a single disk image that can be used for any SAM purpose, as you can do with a physical floppy disk. The only trouble is that SDF still hasn't been finalised... There are SDF disk images of Prince of Persia and Lemmings on Chris White's web-site, but they're early test versions that I'd not really planned on releasing. I'll continue to support reading them in SimCoupe, but will only write/create newer format files. I've been discussing disk formats with an Atari ST emulator author, in the hope that we could used a shared disk format to represent disks for the same floppy controller. One technique often used by ST games was to store small amounts of data in the inter-sector gaps or data fields - something not covered by the original SDF format. The only way to read this hidden data is to use the 'diagnostic track read' command to read a raw track. To cover software examining any part of this raw track data we'd need to store the full ~6250 bytes for each track, which works out at 1MB of data. This diagnostic track read command seems like an ideal way to scan disks to create an image of each track - something that should hold all the data we need! Unfortunately, there's a weird quirk with the floppy controller that causes certain values stored on the track that gets the MFM decoding part of the controller out of sync, so anything read from that point on seems like garbage. So the data read using this command will be different (maybe in a predictable way?) from that read using the normal sector read commands, etc. So for the perfect disk image we'd need to keep the current ~960K of regular data, and also store the 1MB of raw track data just in case something needs it. I'm not actually aware of any SAM software that would require it, but it's something I'd like to have covered if we need it! Almost 2MB for a disk image is a bit much for general use, so I'm thinking of having it as an optional tagged field in the SDF image format, so the 960K version will be a 'normal' image (all these images can be compressed with gzip of course). I've disabled some of the SDF code in the latest SimCoupe while I continue to ponder what to do, but it's still on my mental ToDo list to be finished off 'soon'. If anyone has any thoughts on the subject I'm open to suggestions... Si
