10-07-2019, 02:13 PM
I'm using an FDADAP board to connect an 8" drive to my SCP. It's working nicely.
I use a Mac, so I'm presently mostly using the scp_dump program from Keir Fraser's Disk-Utilities package instead of the native SCP Windows application. I'm writing my own Python-based interface to the SCP hardware and files (and that's why I'm asking lots of questions here), but it's not ready for prime time yet. I'm not presently doing anything meaningful with the disk type value. I'm just concerned about setting it correctly since I'm writing software that interprets and creates .scp files, and I'd like to do it as correctly and compatibly as I can. I don't want to pollute the world with malformed .scp files.
I've been using Disk-Utilities to interpret the .scp files and translate them to ImageDisk files; those work at a sector abstraction level rather than a flux abstraction level, the translation process validates that I got good reads once I see the right numbers of valid sectors with good CRC, and it's a convenient archival format for most of the non-copy-protected disks from various TRS-80 systems. Disk-Utilites doesn't seem to be as good at pulling out partially damaged sectors as some of the other tools (such as HxC), but it's convenient for me to use. I hope that I'll eventually work my way towards learning how to do more advanced recovery of dodgy data from flux images of old disks. I've already had to learn about things like media baking in order to recover data from old disks that are shedding their oxide.
All of the various programs and hardware devices that I have at my disposal for diskette archival have strengths and weaknesses. Since SCP is pretty open with your published file format and SDK document, SCP is currently being sold, and it plugs into current computers, it's the most attractive option for me to build upon.
I use a Mac, so I'm presently mostly using the scp_dump program from Keir Fraser's Disk-Utilities package instead of the native SCP Windows application. I'm writing my own Python-based interface to the SCP hardware and files (and that's why I'm asking lots of questions here), but it's not ready for prime time yet. I'm not presently doing anything meaningful with the disk type value. I'm just concerned about setting it correctly since I'm writing software that interprets and creates .scp files, and I'd like to do it as correctly and compatibly as I can. I don't want to pollute the world with malformed .scp files.
I've been using Disk-Utilities to interpret the .scp files and translate them to ImageDisk files; those work at a sector abstraction level rather than a flux abstraction level, the translation process validates that I got good reads once I see the right numbers of valid sectors with good CRC, and it's a convenient archival format for most of the non-copy-protected disks from various TRS-80 systems. Disk-Utilites doesn't seem to be as good at pulling out partially damaged sectors as some of the other tools (such as HxC), but it's convenient for me to use. I hope that I'll eventually work my way towards learning how to do more advanced recovery of dodgy data from flux images of old disks. I've already had to learn about things like media baking in order to recover data from old disks that are shedding their oxide.
All of the various programs and hardware devices that I have at my disposal for diskette archival have strengths and weaknesses. Since SCP is pretty open with your published file format and SDK document, SCP is currently being sold, and it plugs into current computers, it's the most attractive option for me to build upon.