Re: SDI a nef diskimage format ?
On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote: > attempted to format a track I knew would fail - if it formatted > correctly it would know the disk had been copied... Wouldn't this be defeated by write-protecting the disk? Andrew -- ---Andrew Collier http://www.intensity.org.uk/ --- -- r<2+ T<4* cSEL dMS hEn/CB
Re: SDI a nef diskimage format ?
On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote: > attempted to format a track I knew would fail - if it formatted > correctly it would know the disk had been copied... Wouldn't this be defeated by write-protecting the disk? Andrew -- ---Andrew Collier http://www.intensity.org.uk/ --- -- r<2+ T<4* cSEL dMS hEn/CB
Re: SDI a nef diskimage format ?
On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote: > One of the ways I was going to do protection (if I'd ever got round to it) > was buying a load of really crappy disks and writing code specific for each > disk that attempted to format a track I knew would fail - if it formatted > correctly it would know the disk had been copied... not usable on > high-volume items, but for the low-volume Sam market, it would have been > perfectly do-able :) It doesn't seem a good idea because if they are that crappy then who's to say they won't start losing real data? (I suppose there might be a market for time-limited software...) Better to buy good disks and scratch them with a pin, or something. imc
RE: SDI a nef diskimage format ?
Geoff Winkless wrote: > Why not a tagged format and tools which can handle both types? I've been fleshing out the details of a potential new format to efficiently represent any SAM disk type. It uses your suggested tagged structure, some of the tag types I mentioned recently, and Edwin's fragment idea for sparse non-empty sectors. Rather than wrapping existing image formats, it's a separate format in its own right (perhaps to replace the existing unfinished SDF?). I've written enough code to write images out to a file in the new format, to see how it handles various existing files. Writing valid images is fairly simple, but writing efficient/compact files requires a bit more analysis of what is being written. Normal disks are stored very compactly by recognising patterns in the disk format, and custom disk formats also store only non-empty tracks. Each file starts with a 4-byte header: an ASCII signature (currently "XXX" for testing) and a version byte (0x10 = version 1.0). The rest of the file is formed from tagged blocks, each with a 2-byte ASCII type and 2-byte length (all values are stored in little-endian format), followed by the specified length of data. I've currently got the following types: "TX" - null-terminated ASCII text block "PF" - pre-format details, for regular format disks "SD" - sector data to fill pre-formatted areas "TK" - custom track format+data "RT" - raw track data "EN" - file end marker "TX" : an optional field with no fixed format, most likely used for disk descriptions, copyrights, etc. "PF" : the data is an 11-byte block containing the following 8-bit values: Sides - number of sides in the pre-format block (normal=2) Tracks - number of tracks in the pre-format block (normal=80) Sectors - sectors per track for all sectors (normal=10) Size - sector size code (0=128, 1=256, 2=512 (normal), 3=1024) for all sectors Fill - fill byte to use for data areas (normal=0x00) Base - lowest sector number in track (normal=1) Start - first sector number on track 0 of side 0 (normal=1) Step - step value between ordered sector numbers (normal=1) Interleave - number of sectors to advance between consecutive sectors on a track (normal=1) TrackSkew - sector gap to the same sector number on the following track (MasterDOS=1,SAMDOS=2) SideSkew - sector gap to the same sector number on the same track of the next side (SAM=0,CP/M=1) The pre-format block is a rectangular region of tracks spanning out from track 0 of side 0 to whatever disk extent is needed. It provides a convenient way to prepare a region using a regular format pattern, without having to list each track individually. Custom data can then be filled in with "SD" tags, or tracks can be completely reformatted with "TK" tracks. The 6 parameters controlling the sector order allow almost any regular format to be efficiently represented, including regular skewed SAM formats and the Pro-Dos CP/M format. "SD" : the data begins with a single byte containing the "physical" location for the track. The lower 7 bits contain the track number, with bit 7 set if the data is for side 2 (this could use separate side and track bytes, but my thought is that 2 sides and 128 tracks is enough for any real-world disk). The location byte is followed by a 1-byte packing code for each sector present on the track, and for this reason, the track must already exist from an earlier PF or TK tag. After the packing bytes comes the sector data, stored in the order the sectors are found on the track. The meaning of the data depends on the packing code for the each sector, which are as follows: 0 = sector is filled with the default fill byte found in the PF header. This is the default for sectors in pre-formatted tracks, but when overriding the sector data in an existing track it must be supplied again explicitly. 1 = sector is filled with a single byte, taken from the sector data block 2 = sector is a fragment, using 5 bytes in the data block. The first data byte is the default fill byte for the sector, the next two bytes give an offset into the sector for the start of the fragment, and the two bytes after that are the block length. 3 = the full sector data is supplied, and taken from the sector block Additional codes and compression methods could be added quite easily, but I've left out anything more complicated to keep the format simple. It would be better to store and supply the image in a zip/gzip file, which will have compression superior to anything I could add. Zip files are probably preferred for familiarity, and have the added benefit of a built-in CRC. "TK" : the data begins with a byte for the physical location of the track (as with SD) and a byte holding the number of sectors in the track. This is followed by a block of 6-byte sector headers, and then the data block for the sectors. Each sector header holds: Track - id field track value (may be faked) Side - id field side value (may be fake
RE: SDI a nef diskimage format ?
Frans van Egmond wrote: > If one of you programming people need a Catweasel, I have a > spare Catweasel MK3 lying around that I'd be happy to loan It's probably best to avoid too much reliance on unusual hardware to create images, as it's unlikely all disks we'd want scanning would be owned by someone with a Catweasel (or access to one). Having Windows 2000/XP as a requirement doesn't seem too extreme, and the scans should contain enough detail for what we need. I can adapt the MakeSDF project for scanning on the SAM too, so users with DOS/Linux access can write transfer the normal format images of the protected disks for unpacking on the PC side. Thanks for the offer though - we might find a need for it yet :-) Si
Re: SDI a nef diskimage format ?
If one of you programming people need a Catweasel, I have a spare Catweasel MK3 lying around that I'd be happy to loan to you for the duration of this project if it does the community any good :-) Frans Simon Owen wrote: Nev Young wrote: why not create an image that is a full track image from index hole to index hole including all the inter sector guff. That should cover just about everything. It would indeed, if there was a reliable way to dump them! You'd really need all the sync marks as well as the raw track data, but even reading the raw track data is a problem... Unfortunately, the WD1772-02 controller leaves the address mark detector enabled during the diagnostic tracks reads, meaning certain patterns in the data can cause a false sync. If this happens the controller returns MFM bits instead of data bits from that point on in the track, making what you read essentially useless. I tried this method when writing the original MakeSDF scanner, before spotting the problem and working out what the heck it was doing. The PC controller allows you to read ID field headers and data, but doesn't give access to anything in the gap areas. There is a Disk2FDI program that can do it, but is a commercial program and requires 2 floppy drives. It spins both drives up and starts the read of a high-density disk in drive 1, then switches the drive-select to drive 2, with the controller then returning MFM _and_ data bits for the disk in drive 2. Very clever, but it's DOS-only and wasn't particularly reliable when I tried it a while ago. Another option is to use a Catweasel controller card, which can read just about any disk at very low level. They're not cheap though, and it's not really something most people will have access to for dumping. For now the header/sector-level scanning seems to be about the best solution, and will cope with all but one SAM disk I've seen so far :-) Si
Re: SDI a nef diskimage format ?
Simon: > Good, bad or ugly? Sounds OK. Some things I thought up for 'PC' minded format: Have a format that consists only of track fragments (sectors). Each fragment had a 6 byte header folowed by at least 4 bytes data. So the smallest fragment was 10 bytes and largers 1024 (length/4-4 in one byte). Depending on the fragments type it contains all gap types, address marks, sector data. Besides the diskinfo there are types for file formats ID , end of image marker and discription. As with the other idea, only the used or required fragments are included and each of these track fragment could be anywhere in the image.(emulator should build a ordered offset table) Standard images can have just the sector fragments and protected disks can add extra fragments to rebuild a whole track. Ugly ? As for a encapsulating format: zip dsk,sad,sdf,fdi and rename the extension. Shoot me for this one ! Edwin
Re: SDI a nef diskimage format ?
My two penneth of the disk format discussion: I like the idea of a new, all-encompassing disk format for the samcoupe.org archive (SCOA anyone?) as it will bring together many disparate formats DSK/SDF/SAD etc. into one, but it has to be able to hold the full geometry of the disk. After all, the idea is that the images in the archive should be true to the original format and IMHO there is no point implementing a new format if it cannot handle all disks, after all we might as well stick to DSK and SAD and the odd SDF for that. What we need to say is that this is "the format for the archive" and if anybody prefers to have it in DSK then they should be able to make it that way for their own needs, I am thinking of a parallel to getting a speccy .TAP file and converting it to a .Z80 because that's what you prefer to deal with but the .TAP file is the 'original format' that you take that from. Also, I think the idea of including data in the header of the format is vital - I have too may ARSE.DSK files knocking about and it will be a good method of preserving the information if authors, dates etc. in a standard and manageable way like it ID tags in MP3 files. In short: "One site to store them all, One place to find them, One format to store them all and on the Internet bind them." :-> Dan.
Re: SDI a nef diskimage format ?
Simon Owen wrote: Does the archive need to be a single format for all disks? Or could the 95% of normal format disks be kept in a simple dumped image format, with only protected disks using a different format needed to describe them correctly? I think yes, the idea of tagging extra data into a header appeals but as Geoff pointed out we could have a standard header and then store the payload as a straight DSK or an SDF image (or SDF V1.1 with Freaky Cookie Malarky mode enabled). Dan.
Re: SDI a nef diskimage format ?
Geoff Winkless wrote: On a side track (hah), has anyone else found that all their old Sam disks are completely unreadable? None comepletly unreadable, many with errors which ment I couldn't make a DSK of them at the time. Unless SamDisk2 can skip errors (I haven't got the URL to hand) they will have to stay in the old box for evermore :-( Dan.
Re[2]: SDI a nef diskimage format ?
>> On a side track (hah), has anyone else found that all their old Sam disks >> are completely unreadable? Is it likely that I had a drive that, while being >> in-spec of the other Sam drives, is out of spec enough so that the average >> PC drive can't read floppies created by it? Or is it more likely that almost >> every single one of my disks have simply degraded over time? I've found that all my bought Disks seem to have faired very well and were still readable. Some of my blank disks I had written files on, were sometimes readable in drive 1 or sometimes in drive 2, but then my two drives always seemed to be a opposite ends of calibration to each other.
RE: SDI a nef diskimage format ?
Nev Young wrote: > why not create an image that is a full track image from index > hole to index hole including all the inter sector guff. That > should cover just about everything. It would indeed, if there was a reliable way to dump them! You'd really need all the sync marks as well as the raw track data, but even reading the raw track data is a problem... Unfortunately, the WD1772-02 controller leaves the address mark detector enabled during the diagnostic tracks reads, meaning certain patterns in the data can cause a false sync. If this happens the controller returns MFM bits instead of data bits from that point on in the track, making what you read essentially useless. I tried this method when writing the original MakeSDF scanner, before spotting the problem and working out what the heck it was doing. The PC controller allows you to read ID field headers and data, but doesn't give access to anything in the gap areas. There is a Disk2FDI program that can do it, but is a commercial program and requires 2 floppy drives. It spins both drives up and starts the read of a high-density disk in drive 1, then switches the drive-select to drive 2, with the controller then returning MFM _and_ data bits for the disk in drive 2. Very clever, but it's DOS-only and wasn't particularly reliable when I tried it a while ago. Another option is to use a Catweasel controller card, which can read just about any disk at very low level. They're not cheap though, and it's not really something most people will have access to for dumping. For now the header/sector-level scanning seems to be about the best solution, and will cope with all but one SAM disk I've seen so far :-) Si
RE: SDI a nef diskimage format ?
Hi, is there a format for SimCoupe similar to Sinclair Spectrum Z80/Sna format ? Regards, Dumitru Florin Gabriel ( Zecut0r ).
RE: SDI a nef diskimage format ?
Geoff Winkless wrote: > Why not a tagged format and tools which can handle both types? If a new image format is going to be created out of all of this, it would certainly make sense to be flexible enough for both uses. A tagged format would be easy to process and nicely extensible too. Beyond a file signature, should anything else be mandatory? Having a fixed disk geometry in the header has always seemed a bit wrong to me, as real disks don't impose such limits (beyond the physical movement of the head, and the track bitstream length). Only formatted areas need be stored too, ideally with a special case for efficient storage of simple/regular formats. Descriptions and CRCs could be optional tags, and there's probably not much else that really belongs in a pure disk image (though they are easily added). A new unformatted disk would just need the few bytes for the signature itself, and perhaps an end tag, since there's no other data. A freshly formatted SAM disk would require just one tag (plus a few parameters in data) to tell it to start with a pre-formatted image with 2 sides, 80 tracks, 10 sectors/track, filler byte 0x00. A near empty disks would use the same, but would be followed by any data that is present (haven't thought about details yet). Fancier disks would contain track entries for any formatted ones, each containing a sector count and list of sector headers. The program creating/saving the image would be responsible for picking the most efficient/suitable method for storing the image, and in most cases will be the pre-formatted+data case from above. Programs reading the images would need to determine whether the stored format is suitable for their needs too, such as converting to other limited formats like DSK. This all assumes that the idea of a new archive image format is for "PC"-side storage and transfer of disks, and that images will typically be created and written on the PC-side too. There are no special considerations storing/using the images on the SAM itself, as that feels like a separate application-specific issue. Good, bad or ugly? Si
RE: SDI a nef diskimage format ?
Andy Chandler wrote: > > will cope with all but one SAM disk I've seen so far :-) > > I'm betting that was another Mr Owen creation ;-) It's actually Chris Pile's original Defender disk, which does some gap-level checking as part of the copy protection. The gap information isn't stored as part of the disk image, as it's almost never needed, and would more than double the image size. SimCoupe actually fakes the raw track data from information it knows about the sectors on the current track, so it looks pretty authentic in programs like SAM DICE. Using a tagged disk format it would be possible to include a READ_TRACK dump for just the one track needed, to hold the information Defender expects. Due to the controller bug, it wouldn't be easy to write back to a real disk using a generic image writer (unless another tag held formatting hints!). The track data would also be enough for SimCoupe to run the protected Defender image too, which would be an added bonus ;-) Si
RE: SDI a nef diskimage format ?
Dan Dooré wrote: > None comepletly unreadable, many with errors which ment I > couldn't make a DSK of them at the time. I only found the odd error too, and sometimes they'd be readable in a different drive. The only problems I've had recently is when I made the mistake of using high-density disks with the hole covered - they seemed to work at first, but go bad very quickly. > Unless SamDisk2 can skip errors (I haven't got the URL to > hand) they will have to stay in the old box for evermore :-( Just add a /e to ignore read errors: SamDisk.exe a: MyImage.dsk /e Or for SAMDOS-compatible disks, do a minimal copy of only the used areas, in the hope the bad sector was not part of an allocated file: SamDisk.exe a: MyImage.dsk /m If the image you made did have one or more bad sectors, open the DSK in Edwin's Diskimage Manager and it'll show you which files were affected (marked as "broken" IIRC). Btw, the SamDisk URL is: http://www.simonowen.com/sam/samdisk/ Si
RE: SDI a nef diskimage format ?
Simon Owen wrote: > It's actually Chris Pile's original Defender disk, which does some > gap-level checking as part of the copy protection. The gap > information isn't stored as part of the disk image, as it's almost > never needed, and would more than double the image size. SimCoupe > actually fakes the raw track data from information it knows about the > sectors on the current track, so it looks pretty authentic in > programs like SAM DICE. One of the ways I was going to do protection (if I'd ever got round to it) was buying a load of really crappy disks and writing code specific for each disk that attempted to format a track I knew would fail - if it formatted correctly it would know the disk had been copied... not usable on high-volume items, but for the low-volume Sam market, it would have been perfectly do-able :) I do remember reading about one company which used to laser holes in their disks at a specific point to do much the same thing, although I don't think this was on the Sam. On a side track (hah), has anyone else found that all their old Sam disks are completely unreadable? Is it likely that I had a drive that, while being in-spec of the other Sam drives, is out of spec enough so that the average PC drive can't read floppies created by it? Or is it more likely that almost every single one of my disks have simply degraded over time? I spent many many hours trying to get Linux to read my Sam floppies using different FDD parameters before giving up and deciding that it must simply be the disks :( G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re[2]: SDI a nef diskimage format ?
>> For now the header/sector-level scanning seems to be about the best >> solution, and will cope with all but one SAM disk I've seen so far :-) I'm betting that was another Mr Owen creation ;-) Friday, December 10, 2004, 2:41:26 PM, you wrote: Simon> Nev Young wrote: >> why not create an image that is a full track image from index >> hole to index hole including all the inter sector guff. That >> should cover just about everything. Simon> It would indeed, if there was a reliable way to dump them! You'd really Simon> need all the sync marks as well as the raw track data, but even reading the Simon> raw track data is a problem... Simon> Unfortunately, the WD1772-02 controller leaves the address mark detector Simon> enabled during the diagnostic tracks reads, meaning certain patterns in the Simon> data can cause a false sync. If this happens the controller returns MFM Simon> bits instead of data bits from that point on in the track, making what you Simon> read essentially useless. I tried this method when writing the original Simon> MakeSDF scanner, before spotting the problem and working out what the heck Simon> it was doing. Simon> The PC controller allows you to read ID field headers and data, but doesn't Simon> give access to anything in the gap areas. There is a Disk2FDI program that Simon> can do it, but is a commercial program and requires 2 floppy drives. It Simon> spins both drives up and starts the read of a high-density disk in drive 1, Simon> then switches the drive-select to drive 2, with the controller then Simon> returning MFM _and_ data bits for the disk in drive 2. Very clever, but Simon> it's DOS-only and wasn't particularly reliable when I tried it a while ago. Simon> Another option is to use a Catweasel controller card, which can read just Simon> about any disk at very low level. They're not cheap though, and it's not Simon> really something most people will have access to for dumping. Simon> For now the header/sector-level scanning seems to be about the best Simon> solution, and will cope with all but one SAM disk I've seen so far :-) Simon> Si
RE: SDI a nef diskimage format ?
Dan Dooré wrote: > (or SDF V1.1 with Freaky Cookie Malarky mode enabled). SDF has always handled the Freaky Cookie Malarky, so no need for an update! Here's a dump of the first 2 tracks of my Parallax.sdf file, showing the faked track=128 and mixed sector sizes that Cookie mentioned: 0:01 4[s=1024,t=128] 2[s=1024,t=128] 5[s=1024,t=128] 3[s=1024,t=128] 0:11[s=1024,t=128] 4[s=1024,t=128] 2[s=1024,t=128] 5[s=1024,t=128] 3[s=1024,t=128] SDF also being killed off as a format as soon as we can all decide what to replace it with (falling back on the Russian FDI if there's nothing better). Si
Re: SDI a nef diskimage format ?
[EMAIL PROTECTED] wrote: > Simon: > > Does the archive need to be a single format for all disks? Or could the > 95% > > of normal format disks be kept in a simple dumped image format, with only > > protected disks using a different format needed to describe them > correctly? > > Just Like speccy has TAP for regular format and TZX for the fancy one that > preserves the original. > I too have used disks with odd formats mainly track 5 having an extra short sector between sector 10 and the index hole. I'll probably get shot down for suggesting this but why not create an image that is a full track image from index hole to index hole including all the inter sector guff. That should cover just about everything. Nev
Re: SDI a nef diskimage format ?
Simon: > Does the archive need to be a single format for all disks? Or could the 95% > of normal format disks be kept in a simple dumped image format, with only > protected disks using a different format needed to describe them correctly? Just Like speccy has TAP for regular format and TZX for the fancy one that preserves the original. Edwin
RE: SDI a nef diskimage format ?
Simon Owen wrote: > Does the archive need to be a single format for all disks? Or could > the 95% of normal format disks be kept in a simple dumped image > format, with only protected disks using a different format needed to > describe them correctly? Why not a tagged format and tools which can handle both types? As a user I would certainly rather have an archive with a single type of disk. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SDI a nef diskimage format ?
Simon Cooke wrote: > Sector addresses which do not directly correspond to their > real location on disk SDF stores the ID fields for each sector, so faked track/head values and non-standard sector numbers are no problem. > it used 5 x 1024 byte sectors followed by 1 x 512 byte sector > to fit 11k per track, instead of the usual 10k. Mixed sector sizes are covered as part of storing the ID header+data for each sector on the track. It also preserves the sector order from the index hole, which is something Sophistry needs to run in full rather than demo mode. On W2K/XP you can use the new: SamDisk.exe /scan a: to display a sector-level dump of protected disks, including sector order and any mismatched track/head values. It won't let you image those disks just yet, but it's in the pipeline... > I think it may also have written 82 tracks. My Lemmings _appears_ to have 83 tracks formatted, but with track 82 an exact copy of track 81 (including headers). It could just be that the drive I used to image it couldn't seek to track 82, but I've got a feeling viewing it on the PC also showed the same. > Any truly generic archive format would have to support such disks. Does the archive need to be a single format for all disks? Or could the 95% of normal format disks be kept in a simple dumped image format, with only protected disks using a different format needed to describe them correctly? Si
RE: SDI a nef diskimage format ?
--- Z80 <[EMAIL PROTECTED]> wrote: > > Hi, is there a format for SimCoupe similar to > Sinclair Spectrum Z80/Sna > format ? > > Regards, > > Dumitru Florin Gabriel ( Zecut0r ). > > > Not that I`ve seen... if there was it`d have to be either 256K or in a lot of cases 512K big, plus seen as most software was disk based you`d have to have a copy of whatever disk was in drive 1 too (780K) (in case of extra loading) so snaps could/would be up to nearly 1.3 Megabytes each... Might have it`s uses though, occasionally :) (CKay) in fact mosta the time you probably wouldn`t need a copy of the disk also (but you might not know which software will reload data, or load new data, or need to write to disk...) :) It would be nice... ___ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com
Re: SDI a nef diskimage format ?
On Dec 9, 2004, at 11:13 pm, Simon Cooke wrote: Sector addresses which do not directly correspond to their real location on disk - eg. on track 4 you'd have a sector which had a sector ID of 10, and a track id of 255. (This happens in the Parallax copy protection). ooh, sneaky! Any truly generic archive format would have to support such disks. Agreed. I think the only good reason to invent a new diskimage format would be to hold disk geometries which the previous ones couldn't - and I think Simon just identified it. Cheers, Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- -- Have you lost your Marbles? http://www.marillion.com/
RE: SDI a nef diskimage format ?
Dan Dooré wrote: > I like the idea of a new, all-encompassing disk format for > the samcoupe.org archive (SCOA anyone?) as it will bring > together many disparate formats DSK/SDF/SAD etc. into one, > but it has to be able to hold the full geometry of the disk. One thing to remember though is that some games (eg. Parallax or Lemmings) use different formats invented by *cough* yours truly, which the suggested format won't actually be able to support. This includes: Sector addresses which do not directly correspond to their real location on disk - eg. on track 4 you'd have a sector which had a sector ID of 10, and a track id of 255. (This happens in the Parallax copy protection). Lemmings includes large storage disks (again, one of mine) with (IIRC) a similar scheme for sector address munging. The trick is that it used 5 x 1024 byte sectors followed by 1 x 512 byte sector to fit 11k per track, instead of the usual 10k. I think it may also have written 82 tracks. Not sure though. Any truly generic archive format would have to support such disks. Simon
Re: SDI a nef diskimage format ?
> almost certainly just uncompress the image into a record anyway, so the > reduction in file size would seem inconsequential. Thats gonna change :-) Edwin
Re: SDI a nef diskimage format ?
On Thu, 2004-12-09 at 15:15, Edwin Blink wrote: > From: Andrew Collier <[EMAIL PROTECTED]> > > > But surely this geometry information needs to be changable on a > > per-track basis? Protected disks could have different geometries on each > > track, > > This format is not for protected disks. I think SDF and FDI cover that quite > well. > Besides that it is Also impossible for a real sam to emulate protected > disks. Then, why not just use a .dsk file? For use with the CF or HD, you'll almost certainly just uncompress the image into a record anyway, so the reduction in file size would seem inconsequential. Andrew -- ---Andrew Collier http://www.intensity.org.uk/ --- -- r<2+ T<4* cSEL dMS hEn/CB
Re: SDI a nef diskimage format ?
From: Andrew Collier <[EMAIL PROTECTED]> > But surely this geometry information needs to be changable on a > per-track basis? Protected disks could have different geometries on each > track, This format is not for protected disks. I think SDF and FDI cover that quite well. Besides that it is Also impossible for a real sam to emulate protected disks. Edwin
Re: SDI a nef diskimage format ?
On Thu, 2004-12-09 at 13:24, Edwin Blink wrote: > [2] disk geometry: > bit 7 = sides: 0 for single sided 1 for double sided > bits 6-0 = tracks 1 to 127 tracks > bit 15= start sector: 0 start with 0, 1 start with 1 > bits 14,13 = sector size: 00 128 byte sectors > 01 256 byte sectors > 10 512 byte sectors > 11 1024 byte sectors > > bits 12-8 = sectors per track 1..31 sectors > > DEFAULT: value is D0CAh I only read this quickly, so I may have misunderstood what you're doing. But surely this geometry information needs to be changable on a per-track basis? Protected disks could have different geometries on each track, indeed not all the sectors in one track will necessarily be the same size. The sectore number doesn't need to start with 0 or 1, either. This scheme also doesn't seem to support sectors with CRC errors, which are used in some schemes (the Enigma ones for a start, I think). I must confess I don't necessarily see the advantage of defining a new image format over a implementing an existing standard format... Andrew -- ---Andrew Collier http://www.intensity.org.uk/ --- -- r<2+ T<4* cSEL dMS hEn/CB
Re: SDI a nef diskimage format ?
On 9 Dec 2004, at 1:24 pm, Edwin Blink wrote: I gave it some thoughts and here's what I've come up with. The Idea is to make it possible to handle it on a real SAM using CD-ROM and CF in the future. -- SDI or Sam DiskImage is a new diskimage format to replace the .DSK .MGT and .SAD diskimages. Key features are crc protection, a flexible format and smaller diskimages. Diskimage sizes are reduced by not including unused or empty sectors on a disk. Information to keep track of the sectors that are used is achieved with a minimum of overhead. I don't quite understand it all but I did read through it and it does sound like it meets all our needs - looking forward to the more techy people discussing this. Gavin
SDI a nef diskimage format ?
I gave it some thoughts and here's what I've come up with. The Idea is to make it possible to handle it on a real SAM using CD-ROM and CF in the future. -- SDI or Sam DiskImage is a new diskimage format to replace the .DSK .MGT and .SAD diskimages. Key features are crc protection, a flexible format and smaller diskimages. Diskimage sizes are reduced by not including unused or empty sectors on a disk. Information to keep track of the sectors that are used is achieved with a minimum of overhead. A SDI diskimage can be seen as just an array of sectors where the first sector (header) tells where the other (used data) sectors belong. The diskimage has following structure: +- header sector ---+ | 16 byte diskimage info| | sectormap | | discription | | [zero filed gap] | +---+ +---+ | First used sector | +---+ ... +---+ | last used sector | +---+ 16 byte diskimage info --- bytes Discription [3] 'SDI' magic number in capitals. [4] 32-bit crc. calculated from next byte onward to the last byte of the header. This crc should be used to validate the header. [4] 32-bit crc. calculated over all the data sectors in the image excluding the header. 32-bit crc are calculated in the same way as ZMODEM,ZLIB and PKZIP [2] disk geometry: bit 7 = sides: 0 for single sided 1 for double sided bits 6-0 = tracks 1 to 127 tracks bit 15= start sector: 0 start with 0, 1 start with 1 bits 14,13 = sector size: 00 128 byte sectors 01 256 byte sectors 10 512 byte sectors 11 1024 byte sectors bits 12-8 = sectors per track 1..31 sectors DEFAULT: value is D0CAh [1] empty sector value. A sector completely filled with this value is considered empty and are not included in the sector data. DEFAULT = 00h [1] image flags: bit 7 = Write Protect: When set no changes are allowed to data sectors in the image. Header info can be edited regardless of the state of this bit. To protect the header. The read only file attribute of the image file should be set. DEFAULT = 0 bit 6 = Dynamic Image: When set, disk geometry may be dynamically resized to minimum geometry or expanded depending of the changes made. For example when this bit is set and the image is formatted the a geometry is changed to a single sided disk with just one track contain one sector. when writing a non empty sector outside the images geometry then the geometry will be extended if the sector allocation map can also be extended. When this bit is clear then the geometry will not change and any sector access outside the geometry will produce an error. DEFAULT = 0 bit 5 = emulator boot preference. When this bit is set then it is prefered to always do a cold boot when F9 is pressed or BOOT is executed. DEFAULT = 0 bit 4 = reserved and should be 0 bits 3-0 = dos emulator. On the real hardware this flag can be used to decide which diskimage emulator is loaded to emulate the diskimage. 0 = no preference 1 = SAMDOS 2 = MasterDOS 3 = MASTERDOS+MasterBASIC 4 = Pro-DOS 6 = B-DOS DEFAULT = 0 no preference [1] Reserved and should be 00h [xx] sector adress map or SAM. Like in a directory slot the SAM represents which sectors are used and the position in the map determines which track and sector status it reflects. A '0' bit means that the sectors data is not included in the diskimage a '1'bit means the sectors data is included. the SAM has the same makeup as in a directory slot. starting with bit 0 for the first track and sector up on side one. Side two follows after the last sector on the last track starting with bit 0. In case of odd track or sector numbering each side may have some gap bits which should always be 0. So incase of a standard disk layout of 2 sides 80 tracks 10 sectors starting with sector 1. Track 0, sector 1 starts at bit 0,byte 0 and track 128, sector 1 starts at bit 0,byte 100 The sector allocation maps size can be calculated by the following formula: size = sides *int((tracks * sectors-per-track + 7)/8) any unused bits should be set to 0. DEFAULT SIZE = 200 (double sided 80 track 10 sector disk) [xx] diskimage discription. The diskimage
