keithOK. Here’s the dealio:
I was using the MFMeditor portion of DiskMonTools on the amiga to read a raw sector. Now the darn editor won’t save to disk, so I can’t COMPARE the raw data which I’d love to do. I’m half contemplating taking some digital pictures and OCR’ing the fuqrs just so I can get some data to compare.
This is exactly one track’s, track 0, according to DiskMonTools. Don’t ask me why its not 13800, or 11xxx, etc.
The point right now isn’t so much that I’m getting one track perfectly delimited, its that what comes out of the drive is being read properly by my solution.
DiskMonTools says it’s reading 16200 bytes. My project is reading a filesize of 15892 consistently. I don’t think the data output is exactly the same each time, and that’s a problem Im going to have to address eventually.
I would rather be reading 16200, but hell i’d rather be under than over. This means my SX routines are missing some data someplace, if I had to bet, its an Interrupt problem, where a regular RTCC rollover event is happening during an edge event.
Here’s the link to the sampled file.
I think the sector header isn’t at the beginning of the file because I think the amiga starts streaming data immediately out of the drive (well, after it spins up) without regard to the position within the track.
You’re right. Amiga should start reading floppy output at once, and is being told to read the whole track and then some. This is done to be sure that every bit of the track has been read into memory.
What is your Amiga gear setup? I think I will have to use some track/sector tools, too.
Here are some maths: Amiga MFM encoded sector is 1088 bytes (together with 0xAAAA preamble and 0x4489 sync values). There are 11 sectors on a DD track, giving us 11968 bytes of data. The rest should be the gap. I don’t know if the gap is being written in the end of the track or at its beginning.
In your binary file there is a piece starting from approx. 0x1200 to approx. 0x1500 that looks very much like ~700 bytes of gap.
What I did in the first place I have started to look for 0xAAAA 0xAAAA 0x4489 0x4489 sequence. There is one in the file, starting at 0x2e30. Actually the first 0xAAAA seems as if its most significant bit has been lost (0x2AAA). I can’t find more 0x4489 0x4489 occurences, but at 0x2a02 there’s a sequence of 0xAAAA 0xAAAA 0x4489 0x4409 – again, the last long seems pretty suspicious, as if one bit has been dropped.
If I had to bet on it, yeah I’d say the 0x55 is the gap. That floppy.c indicated that the gap is made up of 0xAA’s, but I don’t think that’s the case all the time.
I noticed the 0x4409 as well, and figured that one bit got dropped there.
Now what I don’t know about the dropped bits is whether my hardware is reading wrong, whether the disk is going bad (its probably 15 years old), whether the drive is off, whether it was written wrong, etc.
My amiga setup is an A500, 68030(I think its clocked at 33mhz, but I honestly forget) w/ fpu, 3mb (1 chip, 2 fast), two external IDE drives totalling about 1.5gb, external floppy(of course), BigFoot power supply (150 watts?). I also connect my amiga to another PC via a serial cable and run PPP so the amiga can get online using amitcp stack.
I also have a spare 4 or 5 other A500’s in storage….
I’m mostly using that “DiskMonTools” software, which has a bunch of stuff including a raw MFM viewer/editor. I also use stuff like DMS without compression, etc.
You may decide the disk’s aging problem by formatting a new floppy in Amiga.
Doesn’t the DiskMonTools software complain or indicate any type of error when reading the track? if no, that could mean that all the data it gets from floppy is correct – and that includes header and data checksums as well.
I am confused with FLOPPY.C.
Seems like the floppyMfmEncodeSector just doesn’t.
What it does is some ‘pseudo MFM’ encoding which is probably suitable for emulation use, but the resulting MFM flow violates the MFM encoding rules, if I understand them correctly.
I have hacked a quick console app that would encode an arbitrary sector of data using the floppyMfmEncodeSector. The result clearly shows not only AAAA 4489 stuff, but also FF AA AA AF bytes which shall not be seen in true MFM flow.
Most of the generic MFM descriptions simply don’t apply to the Amiga’s implementation of it. The rules I’ve actually seen :
1. All flows *must* start with a 1, a low 0v signal.
2. There is never more than (1) “1” in a row.
3. 1’s are always followed by at least one zero, at most 3 zero’s.
Now that I think about it, the resulting MFM is fairly restrictive in its form. Take another look at the file I uploaded, if my setup is working, you shouldnt be seeing ANY FF’s or AF’s, or F’s period — not in the raw MFM data. An 0xF is 1111, and thats impossible.
Im certain now, especially given the fact that I’m seeing the sync’s that my low-level methods of interpreting the hardware signals is correct.
I’ve all but learned to ignore all the top MFM resources via google, including the ones from aimglobal.org, Univ of New Brunswick class (its an EE pdf) stuff from scu.edu, stuff from PC GUIDE, etc.
Tonight I’m going to compare my output with the what DiskMonTools is reporting. Either by hand or otherwise if I can get fancy, I’ll let you know.