Cartridge Port I/O for $DF page has unreliable read behavior (that does not affect $DE page)

[idun-project]

Test Environment (required)

• Platform: MEGA65R6
• Core Commit: 03b24c6
• ROM Release: 920409

Describe the bug
I am working on native support for the idun-cartridge for the Mega65. Current testing is using the GO64 mode to work out communications with the cartridge. Most of the communication works fine because it uses the $DExx IO1 page as a bi-directional "pipe" between the Mega65 and the cartridge. In fact, it works so fine that I can boot and run modern Linux on the Mega65.

The problem is with the secondary bi-directional communication that uses the $DFxx IO2 page. I believe that writes to that page are working correctly, but when reading the data back from IO2, the CPU will sporadically read a NUL (0) byte when a NON-ZERO byte is placed on the data bus. This seems to happen roughly once per full page read. Like I said, no such bad behavior occurs with reads from the $DExx IO1 page.

To Reproduce
Steps to reproduce the behavior:

1. Grab your idun-cartridge :)
2. Grab my (very slightly modified) source for the cartridge software from GitHub
3. Log into the cartridge using ssh and run make, make test and make install for the cartridge source
4. Boot to the Linux prompt and run the eram test program. You will see failures for all of the "rdwr" tests. I believe the failure is caused because the computer cannot read back what it wrote to the cartridge reliably. There's a NUL (0) byte at an address that should be NON-ZERO.
   NOTE: No failures with same cartridge software on C64, C128, C64 Ultimate, OR the latest C64 core for the Mega65.
   see: Compatibility with the Idun Cartridge for the C64/C128/Ultimate MJoergen/C64MEGA65#204

Expected behavior
It should work like other Commodore computers with the same cartridge port signals and timing.

Additional context
I would think that the problem is reproducible with other cartridges that use $DFxx IO2 for bi-directional communications. A SwiftLink style cartridge setup to use IO2 might provide a decent test case too. A simple terminal program capable of running in either native or GO64 mode could be used to exchange data over serial port with another computer. Perhaps someone has already experimented with that kind of setup? Or, I could probably rig something up myself as an aid for troubleshooting this bug.

A cursory look to see if there are obvious timing or bus sampling differences that would cause $DFxx IO2 to possibly exhibit such behavior while $DExx IO1 is completely fine would be a good starting point for this. If there's nothing in the core that could explain that, then I probably need to go one level deeper to figure out why the idun-cartridge timing for IO1 reads would be more "forgiving" than for IO2 reads. In other words, the problem might be that ALL IO reads have a timing issue, but the issue is so slight as to make it only manifest something like 0.4% of the time and only when reading from IO2.

[lydon42]

Did you try this with the dedicated C64 Core? GO64 Mode is not supposed to be C64 compatible.

[idun-project]

@lydon42 Thanks for the reply. I clarified in the report that Idun also works perfectly with the Mega65 C64 core patches I previously communicated to that project.

[idun-project]

@lydon42 Also, here is a very brief excerpt from the very long troubleshooting that was done with Idun for the C64 core. This highlights the root cause of the Mega65's cartridge port signalling not being consistent with what a cartridge would expect it to provide.

The timing-critical cartridge-port address/select/control outputs are now registered in main.vhd before they reach the physical connector. In other words, the cart should no longer see raw combinational mux transitions. It should only see values after the FPGA logic has had a full clock cycle to settle.

The symptom I described in this issue sounds eerily similar to what was going on with the C64 core. NOTE While not yet investigated or proven, a similar problem will undoubtedly make it very hard for anyone to design cartridge port hardware for the Mega65 core (for both native and GO64 modes).