# Board migration
Ugh, getting my Teensy off of the perfboard was a mess. I didn't have any headers on hand so I had simply soldered the microcontroller board directly to the perfboard. I tried snipping all of the pins near the perfboard but I obviously couldn't get to the ones down the middle of the Teensy, so I ended up taking a miniature angle grinder to the perfboard. Copper and fibreglass dust galore! Ugh. Lesson learned.
On the new pcb, I've installed proper headers so that I can (theoretically) pull the Teensy out again, and I also transplanted the two 34-pin box headers. Using a temporary mount, I've placed the board within the console enclosure along with the dual-voltage power supply I had hacked together earlier.
In the process of designing an orderly layout for the pcb, I had reassigned a couple of the Teensy pins. I've also reassigned the corresponding constants in my Teensy code, so it "should" work. 😀🤞
Except of course, it doesn't. 😖
The keyboard is all screwed up; parts of the keyboard (corresponding to distinct demultiplexers) are completely nonresponsive, while others report many, many simultaneous keypresses. Also, for some reason, the VFD is no longer working consistently; posting a stream of identical characters shows a few percent of seemingly random deviations (either other characters are printed, or there are changes in brightness, cursor style, or other behaviour normally caused by some of the special byte values). This indicates either line noise or poor signal timing, but I am doubtful that the new signal path has introduced line noise and the signal timing hasn't changed so I am somewhat confounded.
But then again, it's hella late so I shall proceed by sleeping on it.
# Keyboard bliss
Mystery partially resolved: It seems two signals didn't make it from the Teensy to the ribbon cable socket. I don't blame the pcb manufacturer for this; I must've damaged the solder pads on the back of the Teensy where the signals originate. No big problem though, this is one reason why I wanted every trace on the board to have at least one additional pad: so that I could simply remap the signals from those pads to proper pins and install two patch wires from the new Teensy pins to the ribbon connector. Ta dah, now the full keyboard works beautifully (except, of course, that as a keyboard it's really not all that great to type on 🤭).
# VFD parallel data woes
So that resolves the keyboard. But what of the VFD? The switch to high-speed parallel implies setting the data bits and then (momentarily) setting WR active ... but whenever WR is set LOW, the display goes into a flickering state as if it's being continuously reset (as opposed to only once when receiving a Reset signal). This does not seem to be in line with the datasheet:
Alas, the 1-page data sheet for the NEC FC20X2JA (with 2x20 characters) merely mentions "many control commands are available" but does not provide further details. It does say this about timing, though:
Since the Arduino platform and the Teensy 3.5 doesn't provide nanosecond precision, I'm just going to wait a microsecond for each of those.
Alas, I have tried a zillion different approaches including asking the hivemind, but no matter what I do, setting WR active seems to perform a reset instead of a byte read. I have yet to find a way around this.