For those who like pretty pictures, here's the logic analyzer trace after I got it working. The two yellow dips in the middle were the problem children. If you draw a line straight down the middle of them you may note that the first 5 lines (from top to bottom) are "00011" ($03) representing VERA register $9F23 aka "DATA0" for both. The bottom 8 lines are 0010_0000 ($20) for the first and 0110_0001 ($61) for the second. Those are the correct values; previously it was reading $20 for both.
The more astute viewers may notice unusual spikes on D7 and WE_N appears to be asserted for the entire trace. D7 isn't working and I think it needs to be recalibrated. WE_N was "asserted" the whole time because the probe fell down out of position and I didn't notice ?♂️
Progress is slow, but steady. Tonight I was able to list the contents of an SD card - which happened to be blank.
I've not yet stress-tested it to see if I can repro the SD card issue shown in the update video from August. Being built on a breadboard with an extra dose of stray capacitance on every single pin, I've not had luck running stable at 8MHz, but 4MHz seems to work okay.
Additionally, I have built an Arduino Nano based keyboard buffer that has fixed the keyboard issue - at least, it has for me. Even at 8MHz, KERNAL did not miss the single keystroke I was able to hit before it went haywire. We can say with certainty that the keyboard problem is entirely one of timing. Here is the 4MHz key-smashing test video I shared on Discord:
The Breadboard16 looks substantially less clean than it did before with numerous fixes, reworks, and outright kluges.
Between the main board and the PS/2 connector in the lower right is the Arduino Nano key buffer that allows my USB to PS/2 keyboard adapter to work at 4MHz. Above and right of that, up against the multimeter, is the world's first third party X16 peripheral with two banks of 8 LEDs corresponding to $9F60 and $9F61 (assuming it is plugged it into the /IO3 select line). VERA and the SD card socket are on the left side. The unplugged component on the top half of the VERA breadboard is the DAC waiting its turn for integration testing. Resting above the two breadboards, posed just for this photo, is the assembled but not yet programmed or tested ATTiny and RTC board containing the power, reset, and NMI buttons. It will be exciting to get that working as my "reset switch" is currently the blue wire draped across the ROM (in the ZIF socket). To the upper right, the "reset switch" disappears under the YM2151 test rig waiting to get rebuilt onto the top half of the VERA breadboard.
I have another quick update for this thread on progress with the SD card issue: The short version is: I've never seen my "Breadboard16" fail to recognize an SD card as seen in the update video from last August.
VERA will usually not come out of reset if an SD card is plugged in, but this is an electrical problem between the SD card SPI lines and the FPGA configuration flash SPI. (The v4 VERA fixed this by adding a digital switch that disconnects the SD card from the SPI bus until after the CDONE signal from the FPGA.) In fact, @Frank van den Hoef's VERA design and FAT32 code has been remarkably reliable (as long as files are named using only uppercase, that's a limitation of the original CBM code though). I've asked @Michael Steil about his SD card experience as well and he also has never encountered this issue.
I livestreamed my youngest playing both FlappyX16 and Chase Vault on my Breadboard16 compatible hardware to a small audience on Discord tonight which included @ZeroByte (author of FlappyX16) and @SlithyMatt (author of Chase Vault) and we all learned a bit about the differences between the hardware and the emulator and flagged some interesting corner cases for follow up (notably that the emulator significantly overestimates the available work units for sprite rendering in the hardware).
In any case, I've emailed David Murray about the details of his SD card because at this point I'm suspecting the problem is his card more than the X16 hardware or software. Hopefully it doesn't end up in his spam folder!
we all learned a bit about the differences between the hardware and the emulator and flagged some interesting corner cases for follow up (notably that the emulator significantly overestimates the available work units for sprite rendering in the hardware).
I would like to add that upon further investigation, we realized that it was not a sprite work units issue, but a sprite priority issue.
Namely, the VERA code draws sprites with the opposite priority as stated in documentation and as implemented in the emulators.
Documentation/Emu behavior: Sprite 0 on top of all sprites, then sprite 1, etc.....
VERA verilog behavior: Sprite 127 is on top, then 126, etc....
For all those not on Discord here are before (current VERA design) and after (VERA design w/ my sprite priority fix) photos rendered on real hardware (with hand-drawn red circled areas where sprites were hidden because the scoreboard background sprite was rendered on top of them):
