CBMSTUFF FORUM

Full Version: SuperCard Pro Flux Image format (.scp)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8
I don't see man_Other or its corresponding disk sizes documented in the v1.8 specification at https://www.cbmstuff.com/downloads/scp/s..._specs.txt

Is there a newer version of the specification?
ACK! I didn't push the updated info. I just updated the date and pushed it. Make sure to clear your cache.
Aha! Much better! Thank you.

Now, let me disclose that I'm primarily focused on imaging 8" floppy diskettes at the moment, and maybe you can guess what my next question will be... Wink
There is no difference really between 3.0", 3.5", 5.25", or 8" drives as far as tracks go. What did you have in mind?
Oops, I'm sorry I was slow to reply. My next question is: What disk type value should I use for an 8" drive? None of the defined disk_* values for man_Other appear to be applicable to me. If you decide to add values for 8" drives, I'd recommend at least having distinct values for single-sided vs. double-sided 8" disk drives, since 8" media and drives have "sidedness" as determined by the index hole location, unlike any of the 5.25" or 3.5" formats that I'm aware of.

In any case, I suggest adding a disk_Other value to prepare for the next person who wanders in with a new drive type for which the SCP file format would be a good fit.
The 2nd nibble defines the storage size.  What is the storage size of you 8" disk?
Hmm, I didn't get a new-post notification for your reply despite being subscribed to this thread.

I am working under the assumption that the disk_* values under the man_Other category refer to the kind of physical drive used to image the media, possibly without prior knowledge of what's on the disk. If I'm not mistaken, I'd interpret the existing definitions as:
  • disk_360  => 5.25" DD drive
  • disk_12M  => 5.25" HD drive
  • disk_720  => 3.5" DD drive
  • disk_144M => 3.5" HD drive
I believe that the common 8" disk drive distinctions (among Shugart-interfaced drives that can be connected to an SCP with an adapter) are:
  • single-sided, 77 tracks
  • double-sided, 77 cylinders
SS and DS 8" drives use distinctly different media, with DS drives commonly being able to detect when SS media is inserted and alert the controller with a bus signal (much like 1.44M 3.5" drives can tell DD vs. HD media apart). There was also 8" media made with index hole windows for both SS and DS drives so that either kind of drive could use it, but I don't know if such media would behave consistently when moved from one kind of drive to another. With that kind of media, you can't infer ahead of time whether the data will be SS or DS.

I'm not aware that it was common to refer to 8" media and drives by their nominal capacity like it was for 3.5" and 5.25" media/drives, so I don't know what capacities would make sense. I've generally seen 8" media referred to generically as SS or DS, or less generically by manufacturer-specific drive+format designations like RX01 or RX02 by DEC, or Type 1 or Type 2 or Type 2D by IBM. It was even common to mix FM and MFM on the same disk; I believe it was customary for track 0 side 0 to be FM with 128 byte sectors regardless of the formats on other tracks,. And then DEC used FM sector headers with MFM sector data on their RX02 drives to make things more interesting. It makes sense to me to define disk_* values for 8" SS and 8" DD drives, since those are distinct physical drive types. 

In any case, I'd recommend defining a disk_other value, because I'll bet that somebody shows up with a distinctly different drive type that none of us have seen before. A distinct "none of the above" value seems like a good idea to me, since you've clearly put in a lot of thought towards making the SCP file format extensible for broad use.

As an aside, I've recently used my SuperCard Pro to image and archive some software for the TRS-80 Model II line of computers which was previously thought to be lost, after finding it in a large box of dusty old 8" diskettes that were apparently store demo copies at some long-dead Radio Shack Computer Center. It'll find its way to a public archive eventually. Three cheers for SuperCard Pro!!
The disk type is only for an interface to identify the disk type to the user (if that is desired). It is never actually used to determine the disk format. I was trying to just define 'something' to make a user interface easier for people supporting the SuperCard pro image file format. This is one reason that PE Tools creator wanted me to add the footer.

I will make a new disk type.

Glad you were able to archive some 8" stuff! What interface are you using to connect the drive to the SuperCard pro hardware?
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.
Well, let me know if you need anything on my end. I am always happy to add and mod things are necessary.
Pages: 1 2 3 4 5 6 7 8