I decided that rather than attempt to replace the soundbox, I would initially do a replacement for the NeXT keyboard and mouse combination. This is partly because the NeXT monitor bus appears to operate at around 20MHz making it that much harder to reverse engineer, and partly because I wanted to get back into practice programing MCUs (it has been a while). So, I broke out my box of PIC processors… for this, I’m attempting to use the PIC16F88, but there are options like the PIC18, PIC24 and PIC32 that are quite appealing for different reasons, not the least of which is USB support. So, I set up a little lab that looks like the following.

I have been developing a replacement for the NeXT monitor and/or soundboard for a while now because the monochrome systems rely on an N4000, N4000A, or N4000B monitor. You can get around the issue by having a non-ADB soundbox and building a video converter, but the non-ADB soundboxes are hard to find too, and older models can’t use ADB versions… and even if they could, the ADB systems weren’t fully compatible with a lot of the NeXT software.

After getting most things working on the PIC16F88 I started looking at the timing. On the NeXT side, data needs to be transmitted after the channel select signal on the clock line, and there is only a few hundred microseconds on either side to do anything. On the PS/2 keyboard/mouse side, given the relatively slow transmission speeds, reading the data takes on the order of a millisecond. Basically, unless I want to run the PIC16F88 at a high clock rate and continuously sampling pins to detect bits, and then feeding detected bits into concurrent hierarchical state machines, we’re stuck. It’s doable, but the resulting code will be dense and almost impossible to understand. I actually started to write a simple state machine to PIC assembler compiler that would generate the concurrent state machines thinking it might be a better way to go…

I started programming the PS/2 to NeXT adapter in C, which was fine. I managed to get most of the important parts prototyped, including being able to handle the PS/2 mouse and keyboard, and also sending data to the NeXT. I switched to assembly language the other day, partly to save space, and partly to make sure I have complete control over timing etc. I must say it’s refreshing… most of the programming I do is in Java, C#, PHP etc. and in most of these stacks, there’s an awful lot of ‘magic’. On the PIC, in assembly, there is no magic; it does exactly what you tell it to do, and most of the higher-level testing methodologies don’t really apply. You have to be on your game a bit, which is actually very enjoyable. Reminds me of the ‘Good Old Days’.