EF3 write hangs

[dikdom]

Writing a full disk image still fails (hangs) in fast mode. When using the 'kernal' switch with the ef3usb.exe then the d64 transfer is OK, completes successfully. Can it be possible that the USB transfer is stable now but the fast image write code in floppy is not OK? Interestingly when the kernal mode is selected the C64's border is striped for a moment on each sector but not in the fast mode.

Using with (C=) factory IEC cable and a calibrated to 300RPM floppy drive ("1541C") and a freshly formatted (well, several times) floppy disk. Using latest KFF version (v1.32) and latest ef3usb.exe I just've grabbed from github.

BTW: the 'il' (interleave) switch doesn't work with the kernal switch. I think the kernal write could be speed up a little with some smart interleave (now it writes from sector 0 to sector 20/18/17 one by one) also..

[KimJorgensen]

Have you tried this with KFF version v1.24? It would be nice to know if I have broken something since the issue (#22) was fixed or if there is indeed another problem.

[dikdom]

Now I've tried (v1.24p) but write also fails in TURBO mode, and properly transfers image in KERNAL mode. The READ image also fails in TURBO mode and passes in KERNAL mode... (I've written a disk image to disk in KERNAL mode, read it back also in KERNAL mode, compared and matches).

In TURBO mode (read) the PC console hangs at: 'Transferring image from C64. T: 2 S: 1' while on the C64 console the asterisk is missing from t2 s1 (there are two '*' are missing from the t2 column. The s0 and s1)

BTW#2: reading back in KERNAL mode is painfully slow, again, some speedup could be achieved with interleaving.

[KimJorgensen]

Thanks for testing. I have just successfully written 4 disks in turbo mode with KFF v1.32 and do not have any issues. However, I do have the same problem if I use a NTSC C64 so maybe there is a problem with the write code as you suggested.

[KimJorgensen]

Do you have access to another disk drive? I just retested with a 1541-II drive without any problems but I don't have a 1541C drive. Maybe the drive code doesn't work correctly with that version?

[dikdom]

Hm. I tried with an old style 1541 (pull-down lever? What is the terminology for that?) and I managed to transfer 3 d64 images within 1m40s each without any error. So the conclusion is that the 1541C drive's firmware is not compatible with the fast transfer of the EF3...

Can you ask them to fix this issue? :) EDIT: I need to investigate this a bit further. I have another 1541C and it worked properly. As soon as put back the first 1541C the transfer freezed again. I have to figure out what is the difference between my 1541C drives. Probably the ROMs but it is interesting anyway.

[dikdom]

No idea... These are the two 1541C's. The ROMs match, the large gate arrays match. 6522 vs 65SC22 but those should be identical.. (the one with 65SC22P freezes)

[UffeJakobsen]

@dikdom I would suspect the G65SC22P - it is a CMOS version of the original NMOS 6522. The G65SC22P CMOS version cannot drive as much current as the original NMOS 6522 - that could create timing issues when tight code (such as a fastloader) gets close to the limits...

[dikdom]

Yeah, probably. But still, I don't get it. Commodore had MOS, his own chip fab, why did it use VIA chips from different source?

[UffeJakobsen]

It doesn't look like a repair job - so I think it is safe to say that the G65SC22P ICs are from the original assembly of the drive. MOS had limited production capacity - so I would guess that other sources were pulled in during some kind of supply shortage. I've also seen CBM use both Rockwell and UMC 6502 CPUs in their own floppy drives.

[dikdom]

Okay, kind of mistery solved. Now we somehow should find an other drive equipped with this G65SC22P and check if that fails too... Let me close this issue.