DrCoolZic wrote:Here are more details.
Gunship and P47 both use what I call intra-sector bit width variation.
The Macrodos/Speedlock is the well known example of this protection: You have the first 128 bytes with a normal width, the next 128 bytes have a bit width slightly above normal, the next 128 bytes have a bit width slightly below normal, and the the last 128 bytes with a normal width. I thought that this was the only pattern possible for intra bit cell variation. But apparently this is not the case.
Note that this also explain why the STX format has been changed to allow storing timing information (originally only Macrodos was supported with internal tables).
Aufit has been tuned to detect Macrodos pattern but other intra bit-width variation. This is now fixed in latest prototype.
here are the Gunship and P47 stx generated by new Aufit prototype (note that now Aufit uses the "compress" mechanism of the STX format - sector not saved if already in track - generating files of smaller size)
They seems to work but please let me know if you find problem.
http://info-coach.fr/atari/software/Gam ... sea_compil will be soon updated with more technical details
Jeff_HxC2001 wrote:BTW about the speed variation: are you talking about the first sector on the track 1 ? I found the same speed variation on the following tracks (the tracks without sector)
SCP always gives bad CRC on all revolutions and no Fuzzy bits are detected. This means that the sector is read incorrectly but with the same content on 5 revolutions. So here there is nothing you can do here.
JimDrew wrote:SCP always gives bad CRC on all revolutions and no Fuzzy bits are detected. This means that the sector is read incorrectly but with the same content on 5 revolutions. So here there is nothing you can do here.
The image he made most certainly has different bitcell times for area in question on each revolution, of course you don't need to look at the other revolutions to know that weakbits exist. You can see that from just the single revolution.
JimDrew wrote:I wonder how you are converting bitcell times then. The data in the flux display clearly shows the minimum and maximum bitcell times WAY past 10%!
JimDrew wrote:You must not be reading my data correctly then! The longest bitcell time is 12.593us (~37% outside of the 8us norm). The shortest is 3.505us. However, the middle zone (typically 6us) has values that go back 7us and below 5us... or values in the 4us are going past 5us. In any case, those are invalid bitcell times due to being weakbits. Regardless of the cause of the weakbit (physical damage or deliberately wrong), they are still weakbits.
Brume wrote:Well, now I have a big issue with Roadwar 2000 (original disk).
- OK, let's try to read the disk with Kryoflux. Once again, it detected a faulty track #02 when reading. The .CTR file doesn't work at all with Steem, but.... The .ST file (done with Kryoflux) works fine!!!
Then I tried to convert the .RAW files with Aufit into .STX format: it doesn't work.
I also used HxCFloppyEmulator in order to convert the .RAW files into something I can read with Steem: the .STX file doesn't work, but... the .MSA runs fine!!! Hey, what happens?
DrCoolZic wrote:Jeff_HxC2001 wrote:BTW about the speed variation: are you talking about the first sector on the track 1 ? I found the same speed variation on the following tracks (the tracks without sector)
Seems like we are not using same version? On mine track 39-79 are normal Atari track and does not seems to be the case in your image?
DrCoolZic wrote:Now about speed variation Track1 is an Atari track and the speed variation is used as protection because if timing not written in STX file program do not run.
For other track it is strange. Indeed some but not all of the tracks have speed variation for example Track 2
DrCoolZic wrote:But some other "data tracks" do not have variation for example track 39 is totally flat and some are marginally flat?
JimDrew wrote:If the flux data is invalid, it is due to a weakbit (or strongbit), and that value will change on consecutive reads - as clearly shown in the image Brume provided.
Another thing - you have a VERY small decoder window. If you made the decoder window wider, perhaps 12%-15% (depending on it looking for a sync or regular data) like the WD1772 really is (not 10% as some have suggested), you might have better success with some data. I have some disks for the Amiga that are flakey (specially on the upper tracks) that needs about 23% of a window to properly decode. I use a 47% window for decoding all format that are supported. I can pull data out of thin air this way.
Users browsing this forum: No registered users and 1 guest