IEC communications is flaky

[gardners]

Basically IEC communications fails quite often. We suspect that there is something fishy with the CPU timing at 1MHz.

See also #150 for a related problem, where badline emulation happening at the wrong time may be a contributor.

Attached are traces captured with a real C64 and the MEGA65 doing various IEC things, so that we can try to spot the difference. iec-trace-mega65-load-1541-and-sd2-iec.zip iec-trace-mega65-sd2-iec.zip iec-trace-mega65-1541-load-and-sd2-iec-load.zip iec-trace-c64-1541-2-load.zip iec-trace-c64-load-8-and-sd2-iec-load-9.zip

[gardners]

These can be viewed with pulseviewer on Linux

[gardners]

I also need to conduct pulse tests from the MEGA65 with a precisely timed loop toggling the IEC lines, to see if the resulting frequency is correct.

[adtbm]

I also need to conduct pulse tests from the MEGA65 with a precisely timed loop toggling the IEC lines, to see if the resulting frequency is correct.

Is there a tool available ? Tomorrow Dieter will come to my house and we will repeat the measurements in the "non-working" condition.

[gardners]

Not yet. But let me see if I can cook something up quickly. It really will be very small and simple.

[gardners]

Try this one. Screen will go funny when it is running, but it should toggle all 3 lines on the IEC port with 50% duty cycle at about 70KHz. Please log on real C64 and on a MEGA65. Do not have a disk drive connected for this test, as it is toggling the serial lines flat out, which might upset a connected device.

[adtbm]

Try this one.

??? what file/bitstream ?

[gardners]

iectoggle.zip Sorry, it rejected the .PRG file. Here is the .ZIP which is several times bigger :/

[adtbm]

Here are the data logger recordings for, MEGA65 : runs constant C64 : seems to crash: iectoggle.zip

C64 :

[gardners]

That funny display is correct for C64 running iectoggle, as it crudly messes with the VIC-II banking as well, which is also on $DD00.

[gardners]

iectoggle.prg does indeed toggle the line at ~70KHz on MEGA65. There is jitter if the screen is on ($1B in $D011), which is expected, but not sure if it is correctly timed. Will be interesting to try to load on MEGA65 with the screen disabled ($00 in $D011), to see if that helps the IEC, in which case, we have bad line bugs as the likely culprit.

[gardners]

My 1581 seems to have died again, so testing with an old 1541. Found a disk with "skate or die", and it seems to be loading fine: loader graphic screen appears correctly, music starts playing. This is on R3 with bitstream:

build GIT: development,766,20210201.17,5ab8bc9

Which version of bitstream did you guys test with?

[adtbm]

i am using this one at the moment mega65r3-20210203.20-develo-06000a4.bit

should i expect changes with the IEC drives ? then i'll start a test

[gardners]

With the bitstream I indicated above, I couldn't cause the 1541 to fail to load anything.

[gardners]

Now have the Pi1541 back up and running with a fresh 1970s era 7405 from my stock. It's set to device 11 at the moment, and I can do:

10 OPEN15,11,15
20 GET #15,A$: ? A$;:GOTO 20

And that seems to work fine. But if I try LOAD"$",11, it gets stuck on SEARCHING FOR $

But I'm not sure if this is a problem with the C65 ROM or not.

[gardners]

Confirmed problem happens with stock C64 ROM as well.

Next step is to try tweaking CPU speed a bit faster or slower to see if we get any clues there.

[gardners]

So, I can load a directory BEFORE having mounted a disk image, but after that, it hangs on SEARCHING FOR $ as described above. So presumably the problem is when the Pi switches to the accurate 1541 emulation that it has problems.

[gardners]

Now I am wondering what the difference between OPEN15,11,15 etc is, compared with LOAD"$",11, from a protocol perspective, since one works, but the other doesn't... It's the sending of the filename. If I use OPEN15,11,15,"I", then it also won't work.

So this means it is probably the turn-around between sender and receiver that breaks. This is a helpful clue.

[gardners]

The potential problems that come to mind are reading and writing $DD00. The 45GS02 processor always runs at full speed internally, so a write to $DD00 effectively happens 3 x 1MHz cycles too early, as it happens near the start of the 1st cycle, instead of during the 4th cycle. A similar problem occurs for reading $DD00 -- the value will be read 3 x 1MHz cycles early.

Now, in theory it feels like this should cancel out, as a connected drive would see the signal from the M65 the same amount early that the M65 will read the response from the drive, and indeed, all signals from M65 to the drive will be similarly shifted forward.

However, clearly this falls down somewhere, since it doesn't work with the Pi1541. OR the Pi1541 is not quite cycle accurate, since the turn around DOES work with a real 1541.

[gardners]

Will try adding a cycle-accurate delay to writes to $DD00 in the first instance.

[gardners]

Issue logged on Pi1541 repo https://github.com/pi1541/Pi1541/issues/209