Problems with Babelfish (Arduino Nano?)

[john.cook]

I'm trying to use Babelfish to send programs, but I'm having problems.

When I use the serial monitor and send the 'Z' (Button [A]) command, it doesn't work. Neither does sending the 'L' command (it moves down but doesn't select).

I've added a call to `doLoader()` into the `setup()` function and that starts the loader, but then sending the program doesn't work – the bar flashes showing that data is received but the code doesn't run (including blinky).

`sendFile.py` has a similar result. The Gigatron is reset, the loader starts, code is sent, but it doesn't run.

I'm using the most recent code from github and a V4 ROM.
I've tried both a Nano and a Mega 2560 (using the Uno configuration) and both have do the same thing.

Another issue is that the controller passthrough doesn't work (using the Nano). Push any button has no effect on the Gigatron.

I'm thinking that the bit stream is getting out of sync but I don't know how to test this (I don't have a signal analyser).

Any help would be appreciated.

John

UPDATE
Pluggy McPlugface works fine (even with my shoddy wiring). All the keystrokes are passed through fine and Ctl-F2 loads BASIC.

[marcelk]

`sendFile.py` has a similar result. The Gigatron is reset, the loader starts, code is sent, but it doesn't run.

That's mysterious indeed. It smells like a timing issue with the Arduino, but it's weird that most stuff works ok. Let's start with the GT1 transfer: Could you test sending Utils/SerialTest.gt1 with sendFile.py and see what happens? Possibly film it. It's a test stream that draws the numbers 000..255 to the screen.

For completeness: There's one known minor bug that crept into Loader of ROMv4 (see GitHub issue #100): That causes some VGA monitors to black out for a few seconds after loading a program. The Gigaton is even unaware of this and still runs fine. What you describe is very different.

[marcelk]

The microcontrollers I've personally ever tested BabelFish on:

• Arduino Uno
• Arduino Micro
• ATTiny85

I have also tested with an Arduino Nano clone, and that never worked for me. I forgot the details, but there is some problem with clones that have the wrong USB chip.

The symptoms you describe point towards a timing issue. Some background: Bits are transferred with the horizontal sync pulse, and the vertical sync pulse provides synchronisation. At the beginning of the vertical sync pulse, the microcontroller must respond very quickly in order to catch the immediately following horizontal sync pulse (the first bit). To achieve this, BabelFish disables interrupts and momentarily halts the PS/2 keyboard (so it doesn't miss anything from there). Then it performs a busy wait on the Gigatron signals. In case of the ATtiny85, it must be fused to run at 8 MHz, otherwise its busy loop is too slow.

From sendFirstByte we see how tight this timing is:

Code: Select all

  // Wait for bit transfer at horizontal sync RISING edge. As this is at
  // the end of a short (3.8 us) pulse following VERY shortly (0.64us) after
  // vSync drop, this timing is tight. That is the reason that interrupts
  // must be disabled on the microcontroller (and why 1 MHz isn't enough).

If it misses the first bit in a frame, data gets clocked out of sync, checksums fail and nothing really loads. A correct frame with correct checksum appears as a green dot in Loader's "scanning" bar. Still it surprises me that you see stuff load. The only thing I can imagine is that sometimes the timing is ok, and sometimes it's off. If this theory is correct, I suspect that while loading the Utils/SerialTest.gt1 file, you don't see all the numbers count smoothly.

[marcelk]

Fyi, one VCFB visitor 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 suspect either a timing thingy in Babelfish, or a change in the Arduino libs (and therefore unrelated to the ROM edition)? I didn't ask if it worked again if he switched back to ROMv3. It's hard to test without the hardware.

[marcelk]

I ordered the genuine hardware so I can take a look for myself. I can now confirm there's indeed something not going smooth on the Nano. It's not related to a recent change in BabelFish, because I also tested the same version on my Arduino Uno without any issues.

But interestingly, the VCFB report that the Nano works fine on ROMv3 seems correct. So there must have been a subtle ROM change that trips over only the Nano, but mysteriously not the Arduino Uno, Arduino Micro or ATTiny85 (I just verified them all).

Interesting and mysterious... Keep you posted.

[at67]

I'm using the old version of BabelFish, (Ver1 and a specific one I built using Ver1 as a base), on the Nano just fine with both ROMv4 and DEVROM.

I haven't tried the newest version of BabelFish yet, (I haven't had the time to port over my emulator hardware control features to it yet); so I am not sure what is going on. From my singular experience it seems it's not the ROM version that is causing any potential problems/issues.

P.S. I have two genuine Nano's here and they both work correctly as described above.

[marcelk]

Thanks for checking. It only makes it weirder.

Off-topic: is there something that can't be done in terminal mode ('T' command)? If so, now would be a good time to propose an extension.

[marcelk]

I just pushed this change that appears to fix the Arduino Nano issue overhere.

Code: Select all

   #if gameControllerDataPin >= 0
     pinMode(gameControllerDataPin, INPUT_PULLUP); // Force HIGH if disconnected
   #endif

This enables the internal pullup resistor, for obtaining a well-defined input in case the game controller isn't hooked up.

However, I don't yet understand how this change can prevent the reported and observed symptoms.. So it's unlikely that this is the last word on it.

The game controller pass-through function itself is still broken. It must be fixed in a different way, as described in the other thread.

[marcelk]

In fact, everything is explicable as a combination of:

1. the misconfigured input pin (which was only active by default in the Arduino Nano config), and
2. ROM v4 doing button press detection in a different way (to support a new type of game controller)

In this situation, we literary received mixed signals and the ROM input driver got confused over that. The recent BabelFish updates in GitHub fix it all (including repairing the pass-through function that apparently broke more than a year ago). So I've closed the GitHub issue (#123) for this.

[at67]

If I understand the reasoning correctly here, the fact that I don't have any issues is that I always have a controller plugged in; thus no floating input?