Well I tested 2 different controllers (mine and NightBird's one), 3 drives (including 3" or 3.5") and about 5 or 6 different disks. On each test I read the same track several times and compared the results, that's how I saw those $C2 bytes.Godzil wrote:Also, if the floppy have some defect, it is possible that the hardware try to resync (the $c2)
I haven't been further so far in the reliability of the reading, this was already a too low reliability for me Even with multiple reads and comparison it would bee complicated (because of both inserted or crushed bytes)
Exactly Sir!Godzil wrote:There is one thing I'm not sure to understand, some bytes are sometimes replaced by $C2, sometimes between valid bytes, there is some $C2 added?
Not before this weekend, but I'd say between 5 to 8 seconds, from memory.Godzil wrote:Could you measure the time needed to read the track? It may help to understand if there is some read errors.
For my culture, the FDC doc talks about an "AM" the chip is waiting for... What's an "AM"?Godzil wrote:The FDC Read Track is not 100% reliable, I suspect that nibble will read the same track multiple times, and do some check before "validate" it.
Exactly. To answer to Chema, the idea was to modify my old Savedisk/Cloaddsk tool (that created a DSK file from a Sedoric disk, by transferring it thru the tape port), so it could transfer any disk (Jasmin, Oricdos...), including the gaps that sometimes hide a protection (like for XL-Dos). The existing tool only reads Sedoric and only transfers sectors, hence losing some information.Dbug wrote:He probably want to write a program that can do a raw copy of the floppy, independently of the number of sectors, tracks, special gaps, protections, etc.
I'm not sure it could have been achieved without checking the disk format anyway, but if the track reading is not reliable, it trashes the simple and "universal" solution.