Making lights blink...
My latest diversion is a Microchip PICkit2. The idea is to make something that can understand the Symbolics keyboard I have, and then connect that something to other things that can speak Apple Desktop Bus (ADB), PS/2 keyboard protocol, or USB, in roughly that order. If I can make something that takes a multi-button PS/2 mouse and a Symbolics keyboard and connects both to a MacIvory, I could be set for beautiful three-button mousing and classic keyboarding on my Lisp Machine.
I've mostly traced out the schematic of my Rev. C Symbolics slim-line keyboard (thank god for simple two-layer boards!). Rev. C has LED's in the Caps Lock and Mode Lock keys, in contrast to this picture of the similar Symbolics Rev. B keyboard. Compared to the Symbolics 3600 keyboard schematic, mine is roughly similar, but unfortunately has a 40-pin microcontroller (an Intel 8749H, a member of the MCS-48 family) soldered in. I am certain I could make something work with the simple protocol the 3600 keyboard apparently implements, but if the microcontroller does anything beyond driving the LEDs on and off based on simply counting the corresponding keystrokes, I might be sunk. I've fired off a few questions to people who can hopefully tell me that all of these are plug- and wire-compatible.
As for the 3600, it is pretty obviously a matter of pulling the reset line low to clear the counters, and clocking through the other 127 counter states to read off the switch matrix closures on the 16 X by 8 Y (I surmise that high on the output would mean the corresponding key is down.) I'm not sure how frequently I have to collect the bits to avoid missing keypresses, and what debouncing I might have to do.
The strange thing about my Rev C is that the ICs driving what I guess is the X direction are a pair of 74145 devices with what the datasheet claims are open-collector outputs, and the IC connected to what I guess is the the Y direction is a 7442 with conventional TTL outputs. That seems to mean that scanning an X column with a pressed key causes an open-collector pulling low to compete with the TTL high output on the Y row, except when the Y scan tests that line with a TTL low. What good that does is a mystery. That, and I haven't finished tracing out the part of the circuit with an LM319 comparator. The 3600 schematic drives the X columns (one low, the rest high) and muxes the Y rows (driving ordinary inputs through any pressed keys) to the readout.
[UPDATE: Seems that the keyboard protocol should be identical, so I'm going to forge ahead with the plan, and assume the circuit knows how to work itself.]
[UPDATE 2: fixed the link to the online 3600 schematic.]
[UPDATE 3: I probably should have given more explicit acknowledgment for the inspiration of the project. If I had not seen asciilifeform's schematic revealing the simplicity of the protocol, I'm sure I would have been far less tempted to start this project.]
I've mostly traced out the schematic of my Rev. C Symbolics slim-line keyboard (thank god for simple two-layer boards!). Rev. C has LED's in the Caps Lock and Mode Lock keys, in contrast to this picture of the similar Symbolics Rev. B keyboard. Compared to the Symbolics 3600 keyboard schematic, mine is roughly similar, but unfortunately has a 40-pin microcontroller (an Intel 8749H, a member of the MCS-48 family) soldered in. I am certain I could make something work with the simple protocol the 3600 keyboard apparently implements, but if the microcontroller does anything beyond driving the LEDs on and off based on simply counting the corresponding keystrokes, I might be sunk. I've fired off a few questions to people who can hopefully tell me that all of these are plug- and wire-compatible.
As for the 3600, it is pretty obviously a matter of pulling the reset line low to clear the counters, and clocking through the other 127 counter states to read off the switch matrix closures on the 16 X by 8 Y (I surmise that high on the output would mean the corresponding key is down.) I'm not sure how frequently I have to collect the bits to avoid missing keypresses, and what debouncing I might have to do.
The strange thing about my Rev C is that the ICs driving what I guess is the X direction are a pair of 74145 devices with what the datasheet claims are open-collector outputs, and the IC connected to what I guess is the the Y direction is a 7442 with conventional TTL outputs. That seems to mean that scanning an X column with a pressed key causes an open-collector pulling low to compete with the TTL high output on the Y row, except when the Y scan tests that line with a TTL low. What good that does is a mystery. That, and I haven't finished tracing out the part of the circuit with an LM319 comparator. The 3600 schematic drives the X columns (one low, the rest high) and muxes the Y rows (driving ordinary inputs through any pressed keys) to the readout.
[UPDATE: Seems that the keyboard protocol should be identical, so I'm going to forge ahead with the plan, and assume the circuit knows how to work itself.]
[UPDATE 2: fixed the link to the online 3600 schematic.]
[UPDATE 3: I probably should have given more explicit acknowledgment for the inspiration of the project. If I had not seen asciilifeform's schematic revealing the simplicity of the protocol, I'm sure I would have been far less tempted to start this project.]
Comments
Post a Comment