Next step, testing the PCB edition of the PSX. I’m back to using a slow, low STK500 to do some debugging. Now that the firmware is fairly well squared away, most of the debugging is either a poorly solder-pasted pin (knock-wood).
I did find a curious little 30 minute bugaboo today. While I was making sure that data was being read properly from a controller by itself, I noticed that bits were being consistently dropped. It looked as though things like button presses on the controller were toggling two bits instead of one, and, for example, the first byte that indicates button presses for things like Start, Select and the direction buttons, was always missing the least-significant bit.
It turns out that the way I am emulating requests and data transfers to the controller is particularly sensitive to timing. I’m not 100% sure what the deal is, but the controller I had been using a few days ago was okay with an 16uS clock period. Now, these two I had lying about the studio weren’t working so great with that period — when I changed the clock to a 40uS period, things clicked back into shape.
(I’m sort of wondering whether the series resistors for the firmware generated clock I’m using is too high — I ended up putting a 1.8k resistor rather than the 1k resistor I have in the breadboard prototype, just cause that’s what I had handy.)
In any case that problem got me to thinking that, as other folks have mentioned, the controllers are sensitive to timing — I may need to add one additional control register to the set up so that this timing value can be adjusted easily, rather than sticking it as a constant in the firmware.