Rev 2 boards arrive and both pass bring-up

/ Byte Hamr / updated 2026-09-11 / from project_byte_hamr rev2 bring-up hardware level-shifters

What I tried

The Rev 2 boards landed 2026-04-20. FTDI serials DP0517RX and DP051FY9 both showed up. The next day I froze Rev 1 at git tag rev1, moved every design into gateware/rev1/, started gateware/rev2/ with a constraint file generated from the KiCad netlist, and added REV=rev1|rev2 to the Makefile. signal_check was the first port: SDRAM test, GPIO walking ones, bus monitor.

Both Rev 2 boards on arrival.
Both Rev 2 boards on arrival.

The thing I most wanted to see was the data transceiver. Rev 1 needed a bodge wire to invert R/W for U12’s DIR; Rev 2 does it with U7, a 74AHC1G04. The test is a loopback register at $C0C0 and a walk of 01, 02, 04, 08, 10, 20, 40, 80 through it in both directions. A failure there means U7 is bad or the polarity is wrong and the transceiver is pointed the wrong way.

The USB connector moved too. On Rev 1 it kept the IIe lid from closing, so the card could only be programmed with the top off and the DuoDisk parked somewhere else. Now it programs with the top on.

What I measured

What broke or surprised me

Nothing on the hardware. The pin changes were exactly the ones in the schematic: clock from 25 MHz at G3 to 100 MHz at F3, so every design needs a PLL; GPIO numbered by header position and not matching Rev 1; DATA_OE at B20 where Rev 1 had used GPIO12. Ninety-three signals kept their BGA sites, all of SDRAM, flash, JTAG and the Apple bus, which is why a port is mostly a constraint file.

On 04-29, debugging Smart Hamr, I suspected U7 and U12 again, and should not have. Re-ran the walk on that board, both directions clean. The fault was somewhere else.

Next

Port Smart Hamr, then decide whether to keep patching it or rewrite it from the IWM spec.