Tracking down 1581 lock-up on R3 boards

Some folks are encountering 1581 drives locking up with certain cores on MEGA65 R3/R3A boards.  While I'm here in Germany with easy access to one of the machines and 1581 drives that is exhibiting this problem, we are taking the opportunity to try to track this problem down and fix it.

I'm fairly confident that the problem is to do with the SRQ line, that the 1581 uses for the C128 fast serial protocol.  This theory explains why only the 1581 would have the problem, because:

1. The 1541 doesn't use it, so shouldn't have problems.

2. The 1571 can use it, but powers on in 1541 mode, so is also unlikely to exhibit problems (it only switches to 1571 mode when it has seen 8 negative edges on the SRQ line).

3. The 1581 starts up in 1581 mode, where it does pay attention to the SRQ line.

The first step was to make a half an IEC cable, so that we could probe the IEC lines easily with the oscilloscope:

The next step was to fix which CIA the SRQ line is connected to in the MEGA65 core, as I had mistakenly put it on the 2nd CIA at $DD00 (where the other IEC lines are connected), instead of the first CIA, where the C65 had it.  This should mean that the M65 ROM (being derived from the C65 ROM) should correctly tri-state the SRQ line.  Which it probably does, but doesn't solve the problem.

We are currently fighting with the multi-meter, to get it to show the actual DC voltage on a probe, instead of trying to auto-centre the signal vertically, which means that the voltage drifts to "0" over a couple of seconds.  There must be a way to disable this, but we haven't seen it yet.

Anyway, digging through the schematics for the R3 and R6 boards, I was reminded that the output driver circuit for the IEC lines changed between the two, and an important difference in that circuit is the polarity of the output enable for the IEC lines: We already had DATA and CLK the right way around on the R3 target, but the SRQ line had not been flipped around to the right polarity, as can be seen in the following screenshots:

So we have a totally plausible mechanism for the problem, and I'm cooking a bitstream right now that should correct that. The fix itself is (as is often the case) quite simple:

commit 619acc8893eb593f017bfe07b32fa7082ca80501 (HEAD -> 736-hardware-iec-accel, origin/736-hardware-iec-accel)
Author: Paul Gardner-Stephen <paul@m-e-g-a.org>
Date:   Sun Aug 18 18:49:27 2024 +0930

    fix inverted SRQ en line for R3 #736

diff --git a/src/vhdl/mega65r3.vhdl b/src/vhdl/mega65r3.vhdl
index 2648a689c..e53d6725b 100644
--- a/src/vhdl/mega65r3.vhdl
+++ b/src/vhdl/mega65r3.vhdl
@@ -123,7 +123,7 @@ entity container is
          iec_atn_en_n : out std_logic;
          iec_data_en : out std_logic;
          iec_clk_en : out std_logic;
-         iec_srq_en_n : out std_logic;
+         iec_srq_en : out std_logic;
          iec_clk_o : out std_logic := '0';
          iec_data_o : out std_logic := '0';
          iec_srq_o : out std_logic := '0';
@@ -1194,7 +1194,7 @@ begin
       -- Finally, because we have the output value of 0 hard-wired
       -- on the output drivers, we need only gate the EN line.
       -- But we only do this if the DDR is set to output
-      iec_srq_en_n <= iec_srq_en_n_drive;
+      iec_srq_en <= not iec_srq_en_n_drive;
       iec_clk_en <= not iec_clk_en_n_drive;
       iec_data_en <= not iec_data_en_n_drive;
 
diff --git a/src/vhdl/mega65r3.xdc b/src/vhdl/mega65r3.xdc
index f228c5d3d..38486cf64 100644
--- a/src/vhdl/mega65r3.xdc
+++ b/src/vhdl/mega65r3.xdc
@@ -132,7 +132,7 @@ set_property -dict {PACKAGE_PIN Y19  IOSTANDARD LVCMOS33} [get_ports iec_clk_o]
 set_property -dict {PACKAGE_PIN Y18  IOSTANDARD LVCMOS33 PULLUP true} [get_ports iec_clk_i]
 set_property -dict {PACKAGE_PIN U20  IOSTANDARD LVCMOS33} [get_ports iec_srq_o]
set_property -dict {PACKAGE_PIN AA18 IOSTANDARD LVCMOS33} [get_ports iec_srq_i]
-set_property -dict {PACKAGE_PIN AB20 IOSTANDARD LVCMOS33} [get_ports iec_srq_en_n]
+set_property -dict {PACKAGE_PIN AB20 IOSTANDARD LVCMOS33} [get_ports iec_srq_en]
 
 # C64 Cartridge port control lines
 # *_dir=1 means FPGA->Port, =0 means Port->FPGA

And it looks like that has fixed it up: 

The 74 DRIVE NOT READY error is just because the disk wasn't inserted when I first tried.

We also just made sure it works both with and without an HW IEC enabled ROM, and all is fine.  Also from GO64 mode, everything seems to work.

So, bug found and fixed :)