Andrew Collier wrote: > For protected disks, I think the main advantage of using a > standard disk image format over sdf would be the existance of > other tools to do the disk transfers.
SDF was a convenient solution at the time, but was never really designed to be a permanent format (the lack of header shows it as far from finished!). It's soon to be replaced by a suitable alternative, after which support for SDF will be phased out. About the only "public" images using it are Lemmings and Prince of Persia, and I'll gladly provide replacements when the time comes. My current favourite to replace SDF is the Russian FDI format, as used by some Spectrum emulators. Like SDF it's relatively high-level, and covers all the usual custom formatting tricks that are required for protected SAM titles. Details can be found here: http://www.worldofspectrum.org/faq/reference/formats.htm#FDI I added basic FDI support to SimCoupe last night, but it still have to enable custom disk formatting from within the emulator itself. I've yet to create any SAM images in the format, working with some downloaded sample images instead. > if the original disk was protected I think it is historially more > important to maintain the same protected format disk, than to hack > it onto a standard disk image even if that may be more convenient. That's my feeling too :-) > I guess this boils down to two problems, > a) how to get the Sam to read the image files, and > b) how to get the Sam to transfer a given image file onto > a real floppy disk (or other media). Both of these depend on the non-SAM facilities you have available - I'm hopeful most people can do everything without using a real SAM. Reading and writing standard-format disks is pretty well covered now. DOS = Aley's SBK.EXE, Win9x = Edwin's DiskImage Manager, NT4/W2K/XP = Dave's+my SamDiskNT. Linux users can read/write DSK images through /dev/fd0u800 or through /dev/fd0 with the correct parameters. AFAIK, Mac users have never had a working solution, mainly because USB floppy drives are generally limited to 720K and 1.4MB disks, and not SAM's 800K format. Things are more complicated with protected disks: - DOS programs tend to access the floppy drive through the BIOS, which gives simple sector-level access only. For true protected disk support you'd need to drive the disk controller directly, like Teledisk does. Besides writing something from scratch, about the best solution I can think of is to use Teledisk to create a .td0, and convert that to a FDI image (easy). DOS support isn't so much of an issue anymore I suppose, and Teledisk isn't an option unless you have an ancient PC handy to run it on! - Win9x suffers from much the same problem as DOS, with BIOS-level sector access done through some legacy interfaces. To handle disks at a lower level would probably require a completely new VxD, as driving it directly from user-mode would be too slow and unreliable. This is very unlikely to be written, especially as MS are phasing Win9x out and moving users to W2K/XP. - W2K/XP are covered by my new floppy driver, which gives the ability to read/write almost all SAM disks. I'll extend the new SamDisk (mentioned on the list recently) to add FDI support. Unfortunately, NT4 support is not possible due to differences in the floppy architecture - this shouldn't affect many people though. - The Linux kernel has built-in support for low-level floppy access through raw IOCTL commands. Though not written yet, this would allow a utility with the same level of control as the W2K/XP solution above. - MacOS has virtually no chance of supporting protected disks... until someone creates USB version of something like the CatWeasel! Users not covered by the methods above will have to rely on SAM-side support to read and write disks. It's not a completely trivial process, but anyone dealing with real SAMs should be up to the job. Here's how it currently works in my existing MakeSDF utility (as seen by only a couple of you): To create an SDF image on the SAM: - boot the MakeSDF utility disk on the SAM - insert your copy-protected floppy in drive 1 - insert a formatted target floppy in drive 2 (or disk swap when prompted on 1 drive systems) - press a key and wait for the disk to be scanned and written to the target floppy - create an image of the target floppy on your PC - run a small utility to extract a final SDF image from the target floppy image The target disk is a normal disk format, so you still need a method to transfer those - Mac users will need access to one of the other solutions. By changing the final extraction utility to create FDI images, we have half the SAM-side solution already. The contents of the target floppy are an intermediate format understood by only MakeSDF and the extraction utility. It uses RLE compression to squeeze the contents into a special file on the target disk. I've currently no solution for writing SDF images back to real floppies on the SAM, but it'd be pretty much the reverse of the scanning process above. I shied away from adding write support to MakeSDF, as SAM software copying has always been a sensitive issue on the list. Adding it for this legitimate use would still mean it could be abused, of course. > a. I don't have an IDE interface so I don't know exactly what > the SAM will be able to read. Is there software to make it > understand an ISO filesystem? I don't think so, but that's what a couple of the Spectrum solutions do already. As well as writing to a CD as normal, you can also write the ISO image to the start of a CF/HDD device, or put it on an empty FAT-format HDD (where it will be found close to the start, just after the boot sector and FATs). I'm sure it wouldn't take more than a small BASIC program using BDOS to read a standard-format disk image from an ISO filesystem into a BDOS record. Copy-protected images are out of course, unless you're transferring an intermediate MakeFDI image, which MakeFDI sources from a BDOS record (let's avoid that complication for now!). > dsk.gz would involve someone poting gunzip to the Sam. If they're going on a CD, there should be enough space to have the entire archive in uncompressed DSK format. Still, if anyone fancies writing gunzip for the SAM they're welcome to! I hope I've covered my view of the floppy/protection side, but I'd welcome any comments either on or off the list... Si
