I was excited to have this working and trying to get an x86 qemu setup so as to test serialice, while installing windows on the system itself to try a phone flasher to get a nonworking phone working.
The southbridge was strangely overheating; I moved the heatsink a little (which didn't used to be needed but, windows) and the system powered off and refused to power back on. Unexpected.
I have two boards because I thought I broke one. Later I thought I broke one again, the flash chip kept overheating, and I switched to another.
Then I learned that means the chip is in backward.
I tried my other board with the chip in the right way round, but it wouldn't boot.
I flashed one of my bios prototypes using the arduino flasher onto a chip, and it actually worked, sending its test byte over the serial line. This means the southbridge is successfully initialising the cpu, and the cpu can be used to further debug, which is great news.
I went to flash a bigger bios onto the same chip, but suddenly the arduino flasher is running into the old weird error I ran into before, not detecting a recognized chip because the data pins are grounded when it reads the ID.
I entered the firmware debug terminal that I had discovered, which thankfully worked, and it thankfully did indeed detect the presence of a chip when one was inserted.
I ran the command I added to set the pins with test values, and it seems to look like the clock pin is staying high when it should go low.
The clock pin being low was the very last pin state I tested, which is fine since you test them all.
It's a strange error, but a resolvable one.
Honestly I'm thinking the most likely problem is that I made an error setting the clock pin low in the pin test code, and didn't notice when I tested the pins last time. Finding the problems that aren't unrelated mistakes I've made is a journey through the ones that are.
I reran the test voltages, and the error remains.
The implication is that something is going wrong inside the arduino's microcontroller.