JimDrew wrote:The auto-update function needs your permission to update, which is why it asks you. It wasn't until recently that I even had v0.92 by itself. Before then we were on v0.70 which would auto-update directly to v0.92 (and now v0.93). The auto-update feature is very convenient. No need to go to our website or forum area to download anything, it happens automatically. I guess I could make an option where it doesn't ask you and just does the update.
Yes this is definitively a nice feature and yes keep it like it is (asking the user). You may also consider to always put the latest version in the download area.
When my Turrican arrives, I will look at how to extend the bit cell times from the maximum of 1.638375ms to some higher value. I do have a timer wrap interrupt that should be queuing when the bit cell time exceeds 0xFFFF. That must not be working, and I have never cared before because I have never seen any disks this way.
As I already mentioned the protection used in Turrican and some other games is very special because normally such huge time without any transition is not possible. On an unformatted track you still have transitions happening (can be up to several 100 µs) because of the noise in the head and the ACG of the read chain. This protection “fools” the read chain and result in no transitions for several ms (actually could be dome much larger than that if wanted).
I believe I have fixed the checksum issue now that was causing some image files (multiple revolutions) to not show any data.
Excellent. Now waiting for an entry in the GUI toset the number of revolutions.
You can see the raw MFM data, which is much more important that the converted data that you are use to seeing because it shows you the real flux data as it is decoded to MFM, which does not necessarily match a straight conversion to WD1772 decoded data. I see many cases (actually most cases) where there is an extra flux transition after the SYNC (4489 = A1) and the header, before the next SYNC. I am not sure if this is a bug in the WD1772 or if this is the result of the writing being turned off and back on. I know that most disk formatting routines wrote entire tracks out and sectors are written individually after finding the header. The write splice that occurs there would be something that I would expect, and apparently the sync detection in the data separator ignores any invalid flux up to where the sync begins.
I have three modules In my software to decode the data. The first module is a DPLL based on patent 4,780,844 that takes the fluxes and lock an internal clock and detect how many inspection windows to get to the next flux. Look here
http://info-coach.fr/atari/hardware/FD-Hard.php#FDC_PLL for more detail. This module is not related to the WD1772. The next module is a Data Shift Register (DSR) and Sync detector. This module takes input from the DPLL and convert the result in a stream of MFM bits. This module is again not directly related to the WD1772. I say not directly because the next module needs to provide the sync characters and when to use them. Therefore the DSR module is tailored to decode DOS/MFM bit stream. The last module is a kind of WD1772 emulator that interprets the stream of bits based on the emulated command. For example when emulating a read track command the sync detector is turned on at all time, where when emulating a read sector command the sync detector is turned off as soon as the data address mark is detected. So the same stream of MFM bits gets decoded differently depending on the emulated command.
For the sync it is true that the first A1 sync often requires a “resync” operation. In some cases it make sense in some other cases it don’t. As you mentioned for “user written” floppy disk it is a two pass operation: the disk is first formatted and in that case all bits should be perfectly positioned. But when a sector is written by the WD1772 the sector ID is detected and when the correct ID is found the write gate signal is turned on at a specific position. Of course this position cannot be guaranteed to be perfect and this is where you find so called sector write splice (one at the beginning and one at the end). So for a user written sector you will most probably always have resync but for “disc copier” written there should not be any write splice as the entire track is written “continuously” (only a write track splice exist).
All this explain why data in GAPS can be shifted by some bits. In MFM/Atari/DOS format the sync are always preceded by a sequence of twelve 0x00 bytes. Although not mandatory and not detected by the WD1772 these bytes are here to help the DPLL in locking correctly to the input stream (00 in MFM results in maximum number of flux transitions). Usually they show either as 0x00 or 0xFF when shifted by one bit….
I don't think you need multiple revolutions for fuzzy bits. I am pretty sure the WD1772 uses a window comparator for each of the 3 specific windows. Any values too far outside of these windows would have to be invalid. Can you get raw MFM out of the WD1772 controller? If so, were there any MFM editing utilities for the ST? For the Amiga, I used my MFM/GCR editor, which is somewhat like my analyzer is now. I could read/write tracks directly on the Amiga, alter data, etc... all at the MFM or GCR level, not decoded. If there is the ability to view MFM on the ST, then perhaps some test tracks can be made to check just how out the data can be and still have the WD1772 read it.
There are a lot of ways to get fuzzy bits in MFM. The WD1772 do not care at all about fuzzy bits. The DSR (also describe in the patent mentioned above) just look for presence of transition inside an inspection window. Normally in DD MFM these transitions should be at 4, 6, and 8 µs resulting in 2, 3, and 4 bit shifted in the DSR but in fact anything can happen inside reasonable limits. My definition of fuzzy bits is based on description given in patent 4,462,078. You have fuzzy bits/bytes if the same bit/byte read in different revolutions are different. This can be achieved with what I call border bits (see
http://info-coach.fr/atari/hardware/FD- ... fuzzy_bits), or transitions far above/below normal values, by having unformatted sector, No Flux areas, weak flux transitions, etc…
So yes you can sometimes predict fuzzy bits with only one revolution, and yes you can back up a track with fuzzy bits with one revolution, but this is not exactly what I describe.
Generally speaking there is no way to read the MFM information from the WD1772 and therefore there is no program to do that. With the WD1772 you can only read the decoded data but not the clock and not the MFM. Turrican uses a nice trick that allow to read the clock bits in order to check that the received flux does not contain neither data bits nor any clock bits. For that matter a sector within sector is created with a sync byte shifted by a half cell. So when you read the first sector you read the normal data bits, and when you read the second sector you read the clock bits.
You can fill flux values and write those with the SCP analyzer. By the way, I am finishing up the SDK for the SCP hardware. Since you already have the .scp image file format integrated into your program, you could read/write real disks using the SCP hardware pretty easily. You have to open the driver (I have C examples), and send it packets to turn on the motor, and step the head. The flux read routine gives you the same data that you are using in the file (raw data + the 5 seperate entries). So, it would be simple enough for you to add this support.
This is definitively something to consider
