BabelFish issue only Arduino Nano with ROM v4

[kervinck]

First report here in the user forum: https://forum.gigatron.io/viewtopic.php?f=4&t=165

Second report was a VCFB visitor who told me that:

• His Arduino Nano worked fine when he was still on ROMv3, but
• The Nano stopped working somewhere between ROMv3 and ROMv4 (he was following dev roms)
• While his Arduino Uno is still operating fine

I don't know what to make of that yet. I ordered an original Nano and can confirm the combination Nano+ROMv4 has problems detecting many keys (but not all).

My first thought is that perhaps the timing of the IN instruction has moved between v3 and v4. But inspecting the source, it's at exactly the same machine cycle within the scan line that captures it (cycle 46 of 200):

[kervinck]

The change in https://github.com/kervinck/gigatron-rom/commit/cddded9766f162b6d03b6f46cf45a1b40dd68741 holds up the data line while idle. Without it, it might be held low, and that registers as a zero. This matches the [buttonRight] code of game controller typeC, which is supported in ROMv4 but not in ROMv3.

That explains that the arrow walks to the right in the main menu.

It doesn't explain that a simple serial command such as 'R' (reset) didn't work.

[kervinck]

The reason 'R' didn't work, even if the signals on the scope are the same(!), is the [buttonState] variable in ROM v4:

In idle mode the machine was receiving zeroes due to the missing pull-up resistor (and interpreted that as a buttonRight signal coming from a TypeC game controller). When the 'R' command then starts sending its buttonStart bytes, everything looks normal on the scope. However the driver logic in ROMv4 doesn't detect the button change, because the last serial input was a zero. The driver logic can't deal with the scenario of a TypeC signal immediately being followed by a TypeB signal. The driver logic in ROMv3 worked slightly different and didn't have this side effect with mixed types of byte values.

So this explains all what was observed and reported.