In article <[EMAIL PROTECTED]>, Andy McFadden <[EMAIL PROTECTED]> wrote:
> CiderPress looks for DOS, ProDOS, Pascal, CP/M, and RDOS filesystems in > "DOS", "ProDOS", and "physical" sector ordering every time you open a > disk image. If the file has a helpful extension (like ".do"), it knows to > try that first. However, until it successfully identifies a filesystem, it > can't know the sector ordering, which is why for disks with no recognizable > filesystem (like games with custom loaders) it will ask you to choose one. > Because sector 0 is always in the right place, finding a DOS 3.3 VTOC isn't > sufficient... we know it's DOS 3.3, but we don't know what order the > sectors are, so it's necessary to examine the rest of the catalog track. > Which gets even more fun when you deal with 32-sector images on 800K disks. > > Some formats, such as 2MG, are kind enough to tell you the order. Others, > like ShrinkIt, are always ProDOS-order. In general, though, you have to > keep poking at it until something looks familiar. Then how do you determine the sector interleaving on a blank Apple CP/M disk images (no files ever written to the disk, no CP/M system on the system tracks)? Such a disk will have all bytes in each and every sector set to hex E5. Perhaps in such a case you just assume DOS 3 sector order, since that's what works best with those Apple II emulators which also emulates a Z80 ? -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://www.stjarnhimlen.se/ http://home.tiscali.se/pausch/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In comp.sys.apple2 Paul Schlyter <[EMAIL PROTECTED]> wrote: >> CiderPress looks for DOS, ProDOS, Pascal, CP/M, and RDOS filesystems in >> "DOS", "ProDOS", and "physical" sector ordering every time you open a >> disk image. > Then how do you determine the sector interleaving on a blank Apple CP/M > disk images (no files ever written to the disk, no CP/M system on the > system tracks)? Such a disk will have all bytes in each and every > sector set to hex E5. Perhaps in such a case you just assume DOS 3 > sector order, since that's what works best with those Apple II emulators > which also emulates a Z80 ? I scan the volume directory and look for weirdness. If the disk were completely empty there'd be nothing to scan and I'd get the wrong answer, but since CP treats CP/M as read-only it's not like you'll miss out on anything. :-) I would have preferred to examine blocks in the boot area (the first 3 tracks), but it looks like AE and Microsoft had different implementations. The saving grace with CP/M is that it does allocations in 1K blocks, it appears to start allocating from the front, and it doesn't fill the entire "catalog track". This means that the first file you create will have data on the catalog track itself. So if you load the entire catalog into memory, scan it, and find anything other than valid entries and 0xe5 values, you know you have the order wrong. (If the files stored in the catalog track happen to be filled with 0xe5 or look like valid catalog entries, then you're in trouble. In that case, having the correct label on the disk image is essential, or you're going to have to use "query image format" to override the automatic detection.) Overall the CP/M code in CiderPress is the weakest of the filesystems, since nobody ever wrote a "Beneath Apple CP/M". (Oddly enough, there is the equivalent of a "Beneath SSI RDOS".) There are some bit fields in the catalog entries that I still don't understand. Fortunately I was able to find some large text files and compare the output on an Apple II to the output from CP to verify that all was well. -- Send mail to [EMAIL PROTECTED] (Andy McFadden) - http://www.fadden.com/ CD-Recordable FAQ - http://www.cdrfaq.org/ CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/ Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Andy McFadden <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > It's similar. Sectors have a physical order (by default written straight > from 0 to 15) and a logical order (skewed around). The mapping between > them is fixed for each filesystem, and is different for DOS, Pascal/ProDOS, > and CP/M. (It happens that logical sector 0 is mapped to physical sector > 0 in all established formats, which means that you'll see track 0 sector 0 > at the start of every disk image regardless of ordering.) When I wrote the routine in ProBlock to copy a disk to a file, I never proposed the file as a standard type because I thought the file format should include header information to deal with some of these variations first. I knew about the variations between DOS and ProDOS, but I never even considered CP/M or Pascal. One thing I did have in mind to add as a feature is a block/sector list to support sparsely populated disks. Often many of the sectors or blocks on a data disk will be unused and copying them into the archive file is just a waste of space. Also, it would be helpful to have information about the physical media format. For example, ProDOS would automatically recognize the 1 Meg memory area or my Laser 128 as a slot 5 ram disk (/RAM5 ?). Before I started any heavy programming work with HyperC, I would copy the disk image from my 5.25" or 3.5" drive to the ram disk because the speed of ram access *far* exceeded the speed of a 5.25" drive or 3.5" drive. The downside is that a literal block-by-block copy from one disk to another, e.g. the floppy to the ramdisk, would leave the target disk thinking it was only the size of the source disk, vis the ~1024 K actually available. This could be fixed easily enough by copying only the populated blocks from the 5.25" disk or 3.5" disk and setting the used block map of the ram disk. I think its time for a new DSK format that includes at least these features: - support for 256 byte, 512 byte, and 1024 byte blocks - a used-block map for supporting sparse disks - other information such as the date the media was formatted, original name of the volume, etc. The new format would be a super-set of other formats and the embedded information would help eliminate many of the problems of dealing with archived media from 4+ different operating systems (DOS 3.3, ProDOS, Pascal, CP/M, etc.) However, I haven't spent much time thinking about support for copy-protected disks of the era. I'm not sure there is a good way to deal with those. Any thoughts? Any recommendations for other features to be added to the new format? - Mike Steve Conrad 810 Main Henrietta, MO 64036 816-494-5692 http://sasha91.0pi.com www.fortunecity.com/rivendell/stonekeep/600 It is no secret (nor should it come as any surprise) that humankind's most noble impulses often surface during the most trying of times, that human spirit rises to the challenge when faced with adversity, that human strength is born from human failings...Is it any wonder, then, that the SDF-1 crew became a tighter family after the fortress had been exiled than it had before? From the log of Captain (later Admiral) Henry Gloval -- Apple2list is sponsored by <http://lowendmac.com/> and... / Buy books, CDs, videos, and more from Amazon.com \ / <http://www.amazon.com/exec/obidos/redirect-home/lowendmac> \ Support Low End Mac <http://lowendmac.com/lists/support.html> Apple2list info: <http://lowendmac.com/lists/apple2.html> --> AOL users, remove "mailto:"; Send list messages to: <mailto:[EMAIL PROTECTED]> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive: <http://www.mail-archive.com/apple2list%40mail.maclaunch.com/> Using a Mac? Free email & more at Applelinks! http://www.applelinks.com
