NeXT
NeXT timing dilemma
13/02/12 12:18
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…
Ultimately, I think the cleanest solution is to have multiple PIC processors… maybe 2 PIC12F683 or somesuch, one to handle keyboard/mouse and one to handle transmission to the NeXT. I can run a serial connection between the PICs at a high enough speed that we should be able to handle receiving data in the time window available on either side of data transmission to the NeXT.
Ultimately, I think the cleanest solution is to have multiple PIC processors… maybe 2 PIC12F683 or somesuch, one to handle keyboard/mouse and one to handle transmission to the NeXT. I can run a serial connection between the PICs at a high enough speed that we should be able to handle receiving data in the time window available on either side of data transmission to the NeXT.
PIC Assembly
19/01/12 10:41
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’.
The Power Of Pullups
12/01/12 23:42
Hacking away on the PIC16F88 trying to get it to talk to the NeXT host machine, and I kept getting very long rise or fall times for the signal when twiddling the TRIS bits. I also saw some very unusual signals on the clock line. It finally occurred to me that as an open collector bus, with no keyboard attached, the lines would float without the addition of pullups. I added two 10k resistors, and lo and behold, deterministic timings! With that I was finally able to start sending data to the NeXT machine.
I never claimed to be an electrical engineer… but even so.
I never claimed to be an electrical engineer… but even so.
NeXT Keyboard Bus
02/01/12 18:49
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.
Nestled under the display is a NeXTStation Color (not the Turbo because I’m working with non-ADB). In the far background is a machine I used to repair NeXT MO drives. On the right you can see the breadboard I’m using, and behind that, the NeXT soundcard for a non-ADB system. This allows me to flip between machines on my KVM, and the NeXT slab. I bought some connectors from DigiKey that match the NeXT keyboard, and have breakouts from the NeXT to the breadboard. This allows me to easily attach a scope/logic analyser to the keyboard to see what’s going on. I actually use 2 different LA/MSO, the MSO19 (http://www.linkinstruments.com/mso19.htm) which is very nice, though the sample window is a bit small, and the Chronovu (http://www.chronovu.com/) which has a nice big sample window. I also have a bus pirate and started out with an OpenBench Logic Sniffer (http://dangerousprototypes.com/) but found that for my purposes, especially in reverse engineering the monitor bus, it’s too limited.
I started my investigation by reading what someone before me has done (NeXT keyboard bus on 68k.org), because I don’t see the need in repeating effort unecessarily! This appears to have all the information needed, but it didn’t seem to match what I was seeing. Given how long ago this was done, and how little time was spent on it, it’s quite a nice bit of reverse engineering, but it is inaccurate. By adding power to the NeXT keyboard and then hooking up my scope/LA, I could see that it needs some signal from the host in order to transmit data: it depends on a clock from the host, whereas the PS/2 devices generate their own clock. This is what things looks like when the host is turned on and a key is pressed:
The red line is the clock line, and the orange line is the data line. The bit width is about 50us, and there appears to be 9 bits in the clock line, and 16 bits in the data line. The clock line is interesting… we might almost call it a device selection line, because over a longer window, you can see this pattern:
The clock like flips back and forth between two basic patterns, and guess what, mouse data is transmitted after the pattern with 2 bits set, and the keyboard data is sent after the pattern with one bit set. If there is data in neither, then an empty data packet is sent. Apart from missing the need for, and the importance of the clock/device selection line, the information on the keyboard/mouse that degs reverse engineered so long ago seems fairly accurate. Over time I will generate a complete protocol specification, but the next step (NeXTStep?) is to use the above to a) connect a NeXT keyboard and mouse to a PIC16F88 and read data from them, b) to connect a PIC to the NeXTStation and send data to it, then c) to close the loop and connect a PS/2 mouse and keyboard to the PIC, and to send that data to the NeXTStation. For people with a soundbox, step ‘c’ will allow them to connect a PS/2 mouse and keyboard, and a VGA display, to a NeXT non-adb system.
Eventually this effort might also lead to USB, PS/2 and ADB devices being adapted to non-ADB NeXT machines. ADB support is interesting only because it’s an option for Turbo systems only, and because of the incompatibility of ADB devices with some software on the NeXT.
Nestled under the display is a NeXTStation Color (not the Turbo because I’m working with non-ADB). In the far background is a machine I used to repair NeXT MO drives. On the right you can see the breadboard I’m using, and behind that, the NeXT soundcard for a non-ADB system. This allows me to flip between machines on my KVM, and the NeXT slab. I bought some connectors from DigiKey that match the NeXT keyboard, and have breakouts from the NeXT to the breadboard. This allows me to easily attach a scope/logic analyser to the keyboard to see what’s going on. I actually use 2 different LA/MSO, the MSO19 (http://www.linkinstruments.com/mso19.htm) which is very nice, though the sample window is a bit small, and the Chronovu (http://www.chronovu.com/) which has a nice big sample window. I also have a bus pirate and started out with an OpenBench Logic Sniffer (http://dangerousprototypes.com/) but found that for my purposes, especially in reverse engineering the monitor bus, it’s too limited.
I started my investigation by reading what someone before me has done (NeXT keyboard bus on 68k.org), because I don’t see the need in repeating effort unecessarily! This appears to have all the information needed, but it didn’t seem to match what I was seeing. Given how long ago this was done, and how little time was spent on it, it’s quite a nice bit of reverse engineering, but it is inaccurate. By adding power to the NeXT keyboard and then hooking up my scope/LA, I could see that it needs some signal from the host in order to transmit data: it depends on a clock from the host, whereas the PS/2 devices generate their own clock. This is what things looks like when the host is turned on and a key is pressed:
The red line is the clock line, and the orange line is the data line. The bit width is about 50us, and there appears to be 9 bits in the clock line, and 16 bits in the data line. The clock line is interesting… we might almost call it a device selection line, because over a longer window, you can see this pattern:
The clock like flips back and forth between two basic patterns, and guess what, mouse data is transmitted after the pattern with 2 bits set, and the keyboard data is sent after the pattern with one bit set. If there is data in neither, then an empty data packet is sent. Apart from missing the need for, and the importance of the clock/device selection line, the information on the keyboard/mouse that degs reverse engineered so long ago seems fairly accurate. Over time I will generate a complete protocol specification, but the next step (NeXTStep?) is to use the above to a) connect a NeXT keyboard and mouse to a PIC16F88 and read data from them, b) to connect a PIC to the NeXTStation and send data to it, then c) to close the loop and connect a PS/2 mouse and keyboard to the PIC, and to send that data to the NeXTStation. For people with a soundbox, step ‘c’ will allow them to connect a PS/2 mouse and keyboard, and a VGA display, to a NeXT non-adb system.
Eventually this effort might also lead to USB, PS/2 and ADB devices being adapted to non-ADB NeXT machines. ADB support is interesting only because it’s an option for Turbo systems only, and because of the incompatibility of ADB devices with some software on the NeXT.
NeXT Soundbox Replacement
26/11/11 01:09
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.
The ultimate goal is to build an adapter that will plug into the DB19 monitor cable, and which will provide VGA/DVI and PS/2 or USB keyboard and mouse support. Wouldn’t it be fun to have a NeXT cube connected to my KVM? Given that the monitor bus protocol isn’t really documented, and what information is available is inaccurate, this will be a fun project.
The ultimate goal is to build an adapter that will plug into the DB19 monitor cable, and which will provide VGA/DVI and PS/2 or USB keyboard and mouse support. Wouldn’t it be fun to have a NeXT cube connected to my KVM? Given that the monitor bus protocol isn’t really documented, and what information is available is inaccurate, this will be a fun project.