PiDP-8/I Software

The current software appears to simply sample the GPIO pins at convenient instants down in the core of the PDP-8 simulator's main loop. Since there is no hardware debouncing, this means any switch bouncing may or may not be seen by the switch scanning code.

The switch scanner is clearly fast enough to see such bouncing: many times now, I have been single-stepping through a program, and find that a single press of the Cont switch in single-instruction mode sends me many instructions forward. I've also observed multiple media mounts when toggling Sing Step with the DF switches set.

It is possible that the Pi's GPIO pins have some hysteresis built in, so that this could be fixed in hardware by adding a suitable cap in each of the switch paths, but I don't think we want to ask everyone to mod their kits just to get reliable switch action.

It is possible to debounce switches in software, but the naive way to do that involves putting delay loops inline with the switch reader, which would also put those delays into the middle of the PDP-8 simulator core, throwing off its timing and slowing it down greatly any time a switch changed state.

Instead of building up a complicated state machine to delay switch state change reaction until after the contacts stop bouncing, I propose that we do the [front panel extraction] and put the delays there. Since the front panel handler can run asynchronously from the simulator, delays there shouldn't matter. And, even if we do end up needing to build up some kind of state machine within that app (say, because the delays cause some problem in the SimH front panel API communication) it will be easier if we aren't intermingling it with the PDP-8 simulator's dispatch code.

Closed by [07882c14fe]