Some of you may remember the Nintendo entertainement system, at least the controller pads. The main NES unit itself got some major flaws (search "NES blinking led" on Google and you'll see), but the controllers are extremely reliable and flexible.
:::Warning, technical stuff ahead.
The reason is because they're as simple as it can get. Instead of using a higly advanced programable microcontroller, the only chip inside is a CMOS 4021B Shift Register. It's capable of interfering with anything from 3v to 30v, and it's therefore TTL compatible at 5V.
In the controller, the buttons are connected to each their Parallel Data input of the shift register (8 in total). If a button is not pressed, a pull-up resistor forces the input high, but if the button are pressed, that input line goes low. Three of the controll lines (Latch input, Clock input and Serial Data output) goes to the connector, and the remaining line (Serial Data input) is grounded. VCC and GND also goes to the connector.
The transfer protocoll used by the controller is quite simple. In order to read the combination of pressed keys, the user have to pull "Latch" high for at least 50nS, then pull it low again. Then the clock line must be toggeled to poll in the bits on the Data line. In other words, It's plain old Monodirectional Synchronous Serial Data Transmittion of 8-bits with no start bits, no stop bits and no pairity bits.
:::End of technical stuff
Because of this, it's easy to make it speak to an USB port. The only thing you need is a small microcontroller that handles the USB handshaking stuff. It's even easier to just connect it to the Parallel port since all you need then are some wires and a driver.
All of the above has already been done. That's why I don't plan to try to re-design any of them. However, I got some old XT's (an early version of the PC) with a keyboard layout not really designed for gamers, and I got some NES controller pads.
The XT's keyboard totally lacks the handy arrow keys of the more recent computers. To play games, you have to use the arrows on the numberic-keypad, and it's wery easy to hit num5 instead of "down-arow" as I'm used to the more recent keyboard layout. In addition, the keyboard is quite noisy, and makes a loud "click" sound each time a key is pressed. As you understand, therse computers wasn't designed for gaming.
Because of this, I want to make an adapter I can use to connect the NES controller to the XT, and a piece of software to take over certain interrupt vectors so I can use it with many games. I know both my XT's got parallel port expansion cards, but I don't care. I want to transmitt the data through the keyboard-input!
The reason wht I choosed the keyboard port was simple. Unlike all modern computers, the keyboard interface in the XT doesn't use a microcontroller. Just like the NES controll-pad, it uses a shift register with some extra logic to tie it to IRQ1. Because of this, it need no handshaking and timing, all it needs is a program knowing what's going on, almost at least.
After some resourcing, I figured the keyboard transfer bytes to the XT in 8-bit packets. The signal format is just as with the NES controller, with the only difference that the keyboard input requires one positive start-bit. Another fact is that the keyboard port only got one Input line and one bidirectional line (can be controlled by both software and the connected device). The bidirectional line is controlling the clock input of the shift register.
By the keyboard, the Input line is used to transfer serial data. This data is syncronized with pulses (sendt from the keyboard) on the bidirectional line. It's basically the same transfer method as the NES uses with the exeption that the keyboard doesn't got a latch input and that it generates the clock itself.
Now to the problems. The clock is no problem since the line is software controllable. However, the lack of a "latch" output and the requirement of a start bit was a real problem. I started to think about it and I came up with that I had to make some logic that took care of both the start-bit and the latch signal with the clock as the only input.
The ressult was kind of clever. I took 4 D-type flip-flops (74LS74) and made a divide-by-16 frequency-divider. I connected the output from this divider to another D-type flip-flop, and made the original clock reset this flip-flop on each negative pulse. The output from this was a 1-clock pulse every 16 clock cycle, and voila, I got my "Latch" signal.
for the stop-bit, I took a last D-type flip-flop and used it as a one-bit shift register. The data from the controller is clocked through this register, and therefore delayed one clock cycle. The register is also set with an inverted "latch" signal, and there I got my start-bit.
Finally, the data is just pushed through a 74LS07 buffer so that it's compatible with the open-collector signal of the data-line.
The last thing I had to do was to write a program. Currently, all this program does is to print the input from the controller to the screen, but I'll expand it in the future.
If anybody is interested in Gerber files or schematics, feel free to make a reply. I gladly accept comments.
:::Warning, technical stuff ahead.
The reason is because they're as simple as it can get. Instead of using a higly advanced programable microcontroller, the only chip inside is a CMOS 4021B Shift Register. It's capable of interfering with anything from 3v to 30v, and it's therefore TTL compatible at 5V.
In the controller, the buttons are connected to each their Parallel Data input of the shift register (8 in total). If a button is not pressed, a pull-up resistor forces the input high, but if the button are pressed, that input line goes low. Three of the controll lines (Latch input, Clock input and Serial Data output) goes to the connector, and the remaining line (Serial Data input) is grounded. VCC and GND also goes to the connector.
The transfer protocoll used by the controller is quite simple. In order to read the combination of pressed keys, the user have to pull "Latch" high for at least 50nS, then pull it low again. Then the clock line must be toggeled to poll in the bits on the Data line. In other words, It's plain old Monodirectional Synchronous Serial Data Transmittion of 8-bits with no start bits, no stop bits and no pairity bits.
:::End of technical stuff
Because of this, it's easy to make it speak to an USB port. The only thing you need is a small microcontroller that handles the USB handshaking stuff. It's even easier to just connect it to the Parallel port since all you need then are some wires and a driver.
All of the above has already been done. That's why I don't plan to try to re-design any of them. However, I got some old XT's (an early version of the PC) with a keyboard layout not really designed for gamers, and I got some NES controller pads.
The XT's keyboard totally lacks the handy arrow keys of the more recent computers. To play games, you have to use the arrows on the numberic-keypad, and it's wery easy to hit num5 instead of "down-arow" as I'm used to the more recent keyboard layout. In addition, the keyboard is quite noisy, and makes a loud "click" sound each time a key is pressed. As you understand, therse computers wasn't designed for gaming.
Because of this, I want to make an adapter I can use to connect the NES controller to the XT, and a piece of software to take over certain interrupt vectors so I can use it with many games. I know both my XT's got parallel port expansion cards, but I don't care. I want to transmitt the data through the keyboard-input!
The reason wht I choosed the keyboard port was simple. Unlike all modern computers, the keyboard interface in the XT doesn't use a microcontroller. Just like the NES controll-pad, it uses a shift register with some extra logic to tie it to IRQ1. Because of this, it need no handshaking and timing, all it needs is a program knowing what's going on, almost at least.
After some resourcing, I figured the keyboard transfer bytes to the XT in 8-bit packets. The signal format is just as with the NES controller, with the only difference that the keyboard input requires one positive start-bit. Another fact is that the keyboard port only got one Input line and one bidirectional line (can be controlled by both software and the connected device). The bidirectional line is controlling the clock input of the shift register.
By the keyboard, the Input line is used to transfer serial data. This data is syncronized with pulses (sendt from the keyboard) on the bidirectional line. It's basically the same transfer method as the NES uses with the exeption that the keyboard doesn't got a latch input and that it generates the clock itself.
Now to the problems. The clock is no problem since the line is software controllable. However, the lack of a "latch" output and the requirement of a start bit was a real problem. I started to think about it and I came up with that I had to make some logic that took care of both the start-bit and the latch signal with the clock as the only input.
The ressult was kind of clever. I took 4 D-type flip-flops (74LS74) and made a divide-by-16 frequency-divider. I connected the output from this divider to another D-type flip-flop, and made the original clock reset this flip-flop on each negative pulse. The output from this was a 1-clock pulse every 16 clock cycle, and voila, I got my "Latch" signal.
for the stop-bit, I took a last D-type flip-flop and used it as a one-bit shift register. The data from the controller is clocked through this register, and therefore delayed one clock cycle. The register is also set with an inverted "latch" signal, and there I got my start-bit.
Finally, the data is just pushed through a 74LS07 buffer so that it's compatible with the open-collector signal of the data-line.
The last thing I had to do was to write a program. Currently, all this program does is to print the input from the controller to the screen, but I'll expand it in the future.
If anybody is interested in Gerber files or schematics, feel free to make a reply. I gladly accept comments.
