Posts: 10
Threads: 2
Joined: Feb 2016
I'm writing my own SCP decoding app, initially for extracting files from TI-99 formatted DSDD disks. I believe I am able to parse the SCP files in their entirety. Now I need to figure out what I'm looking at with the flux data.
I currently contain the flux values in a byte array. One sample track of a disk has alternate low and high decimal values. If I understand the SCP format, I'm looking at 16-bit pair values in HIGH-BYTE/LOW-BYTE sequence. Does each 16-bit value represent a flux intensity in a range from 0 to 65535?
I converted the first 300 bytes to HEX values and got the following:
002E0108010901090109010901090109010901080109010901090109010901090109010901090109010901090109010901090107010A010A01090108010B0107010A0109010B01050086008200880108010A0106008700850083008500870106010B01080109010A01090108010A0107010C0107010A0107010A0109010A010801090108010A01090108010A0109010801090108010A0109
Any guess as to what I'm looking at?
Posts: 2,839
Threads: 148
Joined: Nov 2013
Each 16 bit value represents the flux duration/25ns. So, you take the value and multiply by 25 to get the total number of nanoseconds that each flux duration lasts. You have to also convert the drive speed to match the original recording speed during your conversion. That value gets converted into a 0 or 1 that is used for the FM encoding. You will notice that your values are either approximately 0x010A or 0x0085. These values are 8us and 4us. You are using a 360 RPM drive to read your disks. This is how you calculate it:
0x010A = 266
266 x 25 = 6650
6650 x 1.2 = 7980ns (7.98us)
1.2 is the value needed to convert a 360RPM value to a 300RPM value.
I know MFM and GCR quite well, but I don't really know much about FM, so you will need to figure out the encoding/decoding requirements.
Posts: 10
Threads: 2
Joined: Feb 2016
(02-15-2016, 09:10 PM)admin Wrote: Each 16 bit value represents the flux duration/25ns. So, you take the value and multiply by 25 to get the total number of nanoseconds that each flux duration lasts. You have to also convert the drive speed to match the original recording speed during your conversion. That value gets converted into a 0 or 1 that is used for the FM encoding. You will notice that your values are either approximately 0x010A or 0x0085. These values are 8us and 4us. You are using a 360 RPM drive to read your disks. This is how you calculate it:
0x010A = 266
266 x 25 = 6650
6650 x 1.2 = 7980ns (7.98us)
1.2 is the value needed to convert a 360RPM value to a 300RPM value.
I know MFM and GCR quite well, but I don't really know much about FM, so you will need to figure out the encoding/decoding requirements.
Thanks! that clears up just about everything. So in essence, there is no "level" of flux intensity, just a duration, where shorter durations represent a "0" and longer durations represent a "1." That would mean all I need to do is build a sequence of 0's and 1's from the flux data, then interpret that binary sequence using whatever encoding scheme is being used (FM, MFM, GCR), correct? I read up on FM encoding and shouldn't have too much of a problem interpreting it. It's just inefficient compared to MFM.
I suppose if I were to plot the flux durations on an x-axis graph, I'd find nearly all of them will end up near one of two points along the axis to give a visual representation of their distribution.
Posts: 2,839
Threads: 148
Joined: Nov 2013
You can use the DISPLAY FLUX button in the editor/analyzer to see a graphical representation of the flux data.
How the bits are encoded/decoded to/from FM/MFM/GCR to/from flux is different for each type of format. For example, low density MFM has 3 different duration periods, so each duration will have a bit value of either 1, 01, or 001 (4us/6us/8us). You pack the bits together to make up your MFM bytes. FM is just a 0 or 1, based on the duration. I guess with FM you have to ignore every other bit when decoding from FM to standard data. Your data is definitely FM because it only has 2 different duration periods.
Posts: 10
Threads: 2
Joined: Feb 2016
(02-16-2016, 10:30 AM)admin Wrote: You can use the DISPLAY FLUX button in the editor/analyzer to see a graphical representation of the flux data.
How the bits are encoded/decoded to/from FM/MFM/GCR to/from flux is different for each type of format. For example, low density MFM has 3 different duration periods, so each duration will have a bit value of either 1, 01, or 001 (4us/6us/8us). You pack the bits together to make up your MFM bytes. FM is just a 0 or 1, based on the duration. I guess with FM you have to ignore every other byte when decoding from FM to standard data. Your data is definitely FM because it only has 2 different duration periods.
OK. Thanks for the guidance on this!
Posts: 2,839
Threads: 148
Joined: Nov 2013
Please note, that I made a typo in my post. You have to ignore every other bit (the clock bit) when doing the decode to standard data!
Posts: 10
Threads: 2
Joined: Feb 2016
(02-16-2016, 02:49 PM)admin Wrote: Please note, that I made a typo in my post. You have to ignore every other bit (the clock bit) when doing the decode to standard data!
Ah, yes. bit vs. byte certainly makes a difference.
The confusing part for me is the base timing, which I recently learned is in units called "bit cells." I had no idea what to do with the flux durations other than relate then to themselves and not to another base standard. After looking at an SCP file of an MFM DOS disk in the HxC visual viewer did I notice that application putting tick marks at regular intervals in and around "spikes" which I believe indicate flux transitions. After reading academic papers on the subject did I learn of the term bit cell, and that's what HxC is outlining with those tick marks. But, I still needed to know the length of a bit cell so I can correlate the SCP flux durations with the bit cells needed to decode MFM. I finally found this resource, ftp://ftp.eskimo.com/home/mzenier/cd-8002-1.pdf which explains that a bit cell is 2us wide for MFM and 4us wide for FM.
Now, I may be completely overlooking some obvious fact otherwise, which is not uncommon for me sometimes, but the above knowledge has helped me to understand the encoding scheme. It makes sense to me, but I haven't tested the theory yet. I posted it here in case it helps others, too.
Posts: 2,839
Threads: 148
Joined: Nov 2013
That information is not very accurate. The bitcell time base is different for every disk format. A 1.44MB disk uses 2us/3us/4us for the bitcell times. However, the bitcell times for a 720K disk are 4us/6us/8us. A FM disk (like your TI/99-4A) is 4us/8us, with only two zones - not 3 like MFM or GCR have. Every single flux transition is known as a "bitcell", which represents the duration of the flux transition. If you look at the DISPLAY FLUX option in SuperCard Pro's editor/analyzer, you will see the number of bitcells for the track, and the index to index time. These numbers should be extremely close, and vary only by the amount of drive speed fluctuation.
There is source code available for decoding FM disks for SuperCard Pro image format, and even for driving the hardware directly. "a8rawconv" will convert Atari 400/800 FM disks, which use the same format as TI/99-4A disks. You can download the executable and source code here:
http://atariage.com/forums/index.php?app..._id=411198
|