ulticopy making read errors with some real 1541-II

[JiBud]

I have two 1541-II on from 1988 with belt drive and one from 1990 with direct drive motor. The new one with direct drive is making random reading errors "-" during disk reading. The other disk utilitities (from carttridge) are working fine and making disk image without any error. All test with mechanics are passing OK. It must be some timing issue.

[JiBud]

speed of disk is 300.7 rpm 3-5 errors per disk reading

[JiBud]

the floppy disk created in this drive is readable without error in another (belt) drive, and ulticopy reads it without error Tested on FW 3.2 and 3.7 with same result. Can anyone verify this problem with direct drive mechanics?

EDIT: It is about ultimateII+

[GideonZ]

I think you arw suggesting to implement retries. Am I right?

[JiBud]

Hi,

Retry will probably solve the problem, because I am getting errors on different track/sector when I am re-reading disk again.

In next week I will have another "direct disk" drive and want to check if it is common problem for this type of drive.

 

I also checked what happened when I swapped mechanics (keeping same electronic board). ->Then I was getting random errors on both mechanics. By changing floppy disk from different manufacturer the problem was fixed only on belt drive mechanic.

I don’t know why it is problem only on direct drive mechanic + Ulticopy. For example demo BIBA3 by Arise is working only on direct drive mechanic = I think it has “faster” step motor, which is able follow higher pulse switching.

You can hear higher frequency sound of head during movement. My belt drive mechanics in this BIBA3 demo fast loader is not able to follow stepping commands.

 

I was looking on ulticopy.asm source code, but I am not familiar with reading principle. It may be very simple to solve it, for example by inserting some NOP or more attempts.

Jiri ---------- Původní e-mail ---------- Od: Gideon notifications@github.com Komu: GideonZ/1541ultimate 1541ultimate@noreply.github.com Datum: 5. 11. 2020 10:54:30 Předmět: Re: [GideonZ/1541ultimate] ulticopy making read errors with some real 1541-II (#187) "

I think you arw suggesting to implement retries. Am I right?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub (https://github.com/GideonZ/1541ultimate/issues/187#issuecomment-722269918), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ARSXIYB65RJV7U5BNRT64UDSOJY5BANCNFSM4TGB6QMQ) . "

[JiBud]

I checked your routine and there are alredy #100 attemps for reading sector -line 298 in ulticopy.tas I will do more tests

[GideonZ]

First, it needs to be figured out whether the disk read or the data transfer to the Ultimate is faulty. Do you have an oscilloscope? If so, you could measure the SRQ line, and observe its timing against DATA and CLOCK. The SRQ line shows when the data is sampled, at least, when the first two bits and the second two bits are sampled of each byte. This should be exactly in the middle of the bit in the beginning of each transfer block of 128 bytes, but it may drift apart during the transfer of a block. If the drift causes the sampling moment to be too close to the transitions of DATA and CLOCK, the clock frequency offset is just too much and the transfer blocks need to be cut into smaller chunks.

If the disk read goes wrong, this can only be solved by adding retries. There is a retry mechanism, but it only works for reading any block form the disk. This is how ulticopy works: It creates a list of blocks that it expects on a track. Then it starts reading and checks if a block header indicates a block that has not yet been read. If so, it reads it, and transfers it to the ultimate and removes it from the list. The retry comes into play when the blocks found on the track are not in the expected block list. For example, all blocks except block #7 are read; so the list now contains only #7. Then it tries 100 times to compare a block header to #7. When this fails, which would be like ~5 revolutions, it is said that block

7 is not on the track.

So, this retry mechanism does NOT cover read errors, checksum errors and transfer errors. Once the block is in the ultimate application, it is decoded and verified. There is no way to tell the drive code to retry reading a track, YET.... I think this should be added. For example, by not sending "M-E" for a whole disk, but rather for a specific range of tracks.

[JiBud]

Thank you for explaining the reading mechanism. I saw nice reading routine from Linus Åkesson who created on fly GCR decoding, including a checksum. (https://www.linusakesson.net/programming/gcr-decoding/index.php) -but this part could eventually be done in the ultimate + we also have to check the transferred data. But in this case, the ultimate need to request the data again in case of a checksum error. -So you can ask user RETRY / SKIP / CANCEL. I think it should ask when error is detected, not on the end and then go back for retry. -to use same principle as it is in some copy program.

I only have 1ch oscilloscope, so I can't compare more signals :-( The problem will be 99% during reading, not during transfer, because when I replaced the mechanical drive, it solved the reading errors.

[markusC64]

JiBud's speculations are plausible, in fact I've seen many flux dumps (not from 1541) where some sectors are only readable now and then, from 5 rotations stored e. g. 2 rotations ok. Such things happen. And I have a disk that my 1571 can read without errors, but another drive (actually a PC drive) gets read errors - sporadic ones (ome rotations are ok, other are broken) and one permanent error.

[GideonZ]

The ultimate is now not able to request data to the ulticopy routine in the drive. That's basically the fundamental problem of not having retries. I'll add the function to request certain tracks only, so that single tracks can be requested when they have failed after the initial copy.

Regarding your remark:

The problem will be 99% during reading, not during transfer, because when I replaced the mechanical drive, it solved the reading errors.

I agree that reading is more likely to fail. When you say: "When I replaced the mechanical drive", do you mean to say that you kept the electronics the same, e.g. the same board? Because if that is the case, you're absolutely right. Swapping boards with the same drive may reveal communication errors.

I calculated that the crystal offset can be almost 1000 ppm. This seems like an insane amount. But I do remember splitting up the transfer in blocks of 128 bytes, as it did fail on some drives with 256 byte blocks. Note that every byte is transferred in 45 us time. The sampling accuracy must be better than +/- 4 us, as the minimum time data is on the bus is 8 us, and we start sampling in the middle, supposedly. In other words, one block of 128 bytes spans 5760 us. When the sampling was already 1 us off to begin with, there are 3 us to 'give away', which is 3 / 5760 = 868 ppm. In practice probably a little less. Of course, we could always try to reduce the block size to 64, to double again the time margin. For the time being, I suppose 868 ppm is more than enough.

[JiBud]

yes, keeping same electronics board - so it is not transfer issue in my case

I have two 1541-II drives: A fine (electronics A + mechanics A) -all the time working with ulticopy, never failed B problematic (electronics B + mechanics B) every time getting 3-7 errors during disk imaging via ulticopy, but fine with another SW

I did combination: electronics A + mechanics B - disk read error starts here, even if created new fresh floppy disk electronics B + mechanics A - working fine if I am using "better" quality disk

electronics A has Motorola head amplifier chip electronics B has Sanyo head amplifier chip

you can see a drive pic here http://www.oldcomp.cz/viewtopic.php?f=31&t=9065 and my test with drives here (sorry it is in Czech lang) http://www.oldcomp.cz/viewtopic.php?f=31&t=9063

this weekend I will have another 1541-II and can do another tests - will try to get 2ch oscilloscope

[GideonZ]

Retries will be the solution, based in your findings. :-)

[JiBud]

drive C with Sanyo amplifier and Sankyo mechanics -most quiet and reading 100% with ulticopy

another new combinations: electronics C + mechanics B - disk read error starts here, even if created new fresh floppy disk electronics A + mechanics C - working fine electronics B + mechanics C - working fine

it proves the fault is in meachanics B not in IEC transfer -making 1-7 random errors per disk and need retry function, which is not visible in another SW it must be signal from head

---

Gideon and others Thanks a lot for the best C64 cartridge! There is nothing better