Image Map Image Map
Page 4 of 7 FirstFirst 1234567 LastLast
Results 31 to 40 of 64

Thread: Arduino keyboard emulator host wiring.

  1. #31


    Yep, spot on with SK6/SK7. VB is +5V, there's at least two different power rails going on in that machine because it's designed to be permanently on. In normal usage you wake it up by lifting the LCD - that's the source of the VSW signal I mentioned earlier, looking at the power schematic at the top of the analogue sheet.

    Looking at the trace again I can see what you mean about X0-X2 being scanned first, this is how it works out whether to then look at Z4 or Z5 which is important because the ABC pins are reversed. Pressing a key completes an X-Y circuit which fires KBINT and activates one channel on the 4051s so by scanning X0-X2 (1-1-0 in this case) then scanning X3-X5 gets 1-1-0 which is enough for a lookup table so it knows which key was pressed. Looking at my spreadsheet I worked out a lookup table in January, but I'll be f'ed if I can remember how I did it with just a multimeter

    (I've just realised I've pretty much retyped your explanation, but I was thinking out loud while typing and now have it clear in my head)

    I did buy an Arduino MEGA for this project ages ago, thinking I could just simulate the 24 pins of the keyboard connectors. When I worked out the lookup table realised I could maybe do it with a Nano and convert PS2 keypresses into the binary lookup table and present 6 pins to the PA's microcontroller for it to scan. Now I know it's a bit more complex, must admit I like the idea of the LS244 presenting the code to be read. - UK home computer history
    Where RIFA capacitors come to die

  2. #32


    One thing to think about. I suspect the timing of the replies to the PA are probably timing constrained. Once you start sending a key status, you may not have time enough to keep up with possible data from the PS/2 keyboard. Remember that the PS/2 keyboard will normally send any change of key status right away. I don't use libraries of code. I'm not familiar with what is out there for reading keyboards but I suspect some of them don't include the ability to throttle the keyboard. Most of the arduino libraries are written as though they were the only code running. The keyboard can be throttled. If you set the clock to 0, it tells the keyboard to hold some of the key responses in its buffer. This is quite handy if you are time slicing the code where you have some other time critical operation to deal with.
    It is kind of like saying, " Don't bother me right now, I'm busy. ". Depending on the time involved to read a single byte from the keyboard and the strobe timing of the PA, you may be able to time multiplex a single processor to do both at the same time. If not, you may find it best to use separate 2 processors. The processor speed isn't always the issue. Even the fastest processor may not be able to handle both the keyboard and watch the PA at the same time. It really depends on what is needed.
    The keyboards have a range of speeds they are allowed to run at. Since while sending bytes, the keyboard creates the clock signal, you have to catch what ever it is sending at what ever rate in real time. I suspect the PA also has timing constrains as well. Make sure you understand both before tying your self down with single processor.

  3. #33


    I'm getting to like the idea of a pair of Nanos with an extra small board for an LS244, I have a few spares of both. This machine is never going to get used and abused since there's literally nothing you can do with it in 2019 apart from enter addresses and notes. Oh, and browse the resurgent viewdata/teletext pages via a wifi modem which there is very handily an RS232 port for. I made a very basic 8 switch keyboard which provides enough keys to log in and step in/out of menus which is what's helping with the scanning tests.

    Since the PS2 side of things is complete in that it will display the keys that are pressed on the arduino serial console, adding code to build the lookup table and send it to a buffer is trivial. Now that we know (or are pretty sure we know) how the scanning operates do I really need to watch the PA that closely? When a code is put in the buffer I raise KBINT and KBSENSE which starts the PA scanning X0-X5 to receive the code from the buffer, then drop KBINT and KBSENSE after ~1ms. Looking at my test scans the timings for a complete sequence are just over 1ms but it repeats a few times. The PS2 side of things takes care of rollover etc. I'm typing out loud while thinking again

    The sequence would be:

    KBINT/KBSENSE off, LS244 outputs disabled
    Pressed key arrives from PS2 library
    Perform lookup to build the 6 byte code and send to LS244 (speed will vary for this obviously, since I'd have to lookup all 93 possible keys every time)
    Enable LS244 outputs, KBINT and KBSENSE for 1-2ms, PA does the rest.

    What's the safest way of introducing another electrical device into the circuit? This is where my understanding of current flow lets me down.


    (Oh, yesterday a former Tandata technician found me and thinks he has a complete unit with more drawings in his loft ) - UK home computer history
    Where RIFA capacitors come to die

  4. #34


    I gave it a little more thought, looking at your note as to how the signals work. The pullups on the Z4/Z5s makes more sense. Here is the sequence as I believe it now.
    All the lines from the Z4/Z5 to the keyboard are high.
    Any key is pressed
    One of the lines to the to the Z6 goes high
    This generates a KBINT
    The processor put a 0 on the pins 3 of Z4/Z5.
    The processor scans both the Z3 and Z4/Z5, looking for a time when Z3 sees a zero.
    The processor looks up the combination of Z3 and Z4/Z5 in a table.
    It waits for a key released, sees the end KBINT match the Z3 without detecting a key.
    Waits for another interrupt

    I'm thinking it might be easier to put the entire thing in a single processor and add a few ICs to look like a keyboard that are controlled by your uC. Since all the PA timings is outside of the uC, there is not conflict of timing between watching the PS/2 keyboard and the strobes from the Z4/Z5.
    Lets see if I can describe the circuit.
    Use a '240 instead of the '244. I'll describe.
    First you need a '240 for the data match. You need 2 '688s for the Z4/Z5 strobes matched ( if you get wires directly from the inputs to the Z4/Z5, you only need one '688 )
    One side of the pair goes to the Z4/Z5 strobes and the other side goes to the single uC.
    The cascaded output of the '688s goes to the enable of the '240.
    One other thing is needed. We need a way to connect the pull up of the key hit to the Z6.
    I gave this a little though and realized that you want to use a '240 instead of a '244.
    You place 10K resistors across the data in of the '240 to the outputs. These act as the pullup to cause the Z6 to detect a key hit. When the Z4/Z5's are hunting for the key that caused the Z6 hit through the Z3, it is looking for a low, not a high. That would happen when you get the match of the Z4/Z5 bits with the '688s. It would enable the '240, complementing the signal on the line going to the Z3.
    This can then be completely run from the single uC as all the time of the PA is dealt with by the ICs. The uC can keep track of the PS/2 keyboard without any issues. When idling, waiting for a key from the PS/2, one would put a invalid value on the '688s or a 1 on the cascade input of the first one so that there never was a match. The write 0's to the '240s input. When a PS/2 key is detected, Write a 1 to the bit that would be that key on the PA for the '240. Write the value for the '688s.
    You'd then wait for the key release from the PS/2 while the PA is examining the Z3 with the Z4/Z5 strobes.
    When the PS/2 key is released, first write not = to the '688s and then write all 0's to the '240. The output would not be 3state pulled low by the resistors on the Z3/Z6.
    Last edited by Dwight Elvey; April 20th, 2019 at 07:48 AM.

  5. #35


    Easter weekend all done and dusted, I hope yours was similarly fine weather wise and that you didn't damage limbs like I did!

    I can see why a '240 would be better than a '244 but I'm puzzled as to the role of the '688s unless I'm looking at the wrong datasheet - the '688 is a comparator and just outputs /P=Q if the 8 bits of one channel match the 8 bits of the other. Did you mean a '668 counter?. I was thinking of presenting the '240 outputs directly to X0-X5 at just the right point for the PA to start scanning. My reasoning is this:

    Normally on the PA pressing a key closes the switch which joins Z3/Z4, Z5 and Z6 together at the same time. This generates KBINT and starts the PA scanning X0-X5 (this isn't my uC, this is the I/O module in the PA).

    Z3 acts on its own and is scanned first with Z4/Z5 both inhibited. A hit on there raises KBSENSE according to the trace I have from the logic analyser.
    Z4/Z5 act as a pair, the PA inhibits Z5 and scans Z4 pins 9/10/11 looking for a match on pin 3, if it gets nothing it inhibits Z4 and scans Z5. Both KBSENSE and KBINT drop when it gets a hit.

    Remember I'll already have decoded the PS2 keypress on the uC and worked out the 6 digit keycode as far as the PA is concerned, and 'all' that should be needed is to have that code on the output pins of the '240. I don't need to emulate Z5 since I can provide all the correct codes to my version of Z3/Z4.

    I'll annotate the logic analyser scan of me pressing a key and upload it in a bit.

    Cheers! - UK home computer history
    Where RIFA capacitors come to die

  6. #36


    After following the schematic, I come to the following understanding
    When any key is hit, it will generate a KBINT through Z6.
    On interrupt. Z3 can be scanned to determine which pin is high.
    It still doesn't know which key it is that is struck, it just knows which group of keys that would be.
    It can the scan Z4/Z5 with 0. As to if it detects this with Z3 or Z6 I can't tell. It is immaterial Z3 is only part of the picture.
    When Z4/Z5 matches the key. The line detected by Z3/Z6 would go to zero. This is the only way the processor can know which
    key was struck.
    So, Z3/Z6 line goes high when a key is struck. Z4/Z5s address matches the key when it matches the key from the other side of the matrix.
    This causes the line going the Z3/Z6 to be 0.
    Your circuit needs to know when the value from Z4/Z5 matches the key. When it detects this, It needs to switch the state of the line it
    brought high to low.
    I think what you don't see is that Z4/Z5 both are not driving anything when the key is struck. The pull up resistors RP7 and RP8 are. It is one of those that creates the interrupt though Z6. With the keys deselected the resistor RP9 holds the lines low.
    Without the comparator you do not know when to change the state of the pin going to Z3/Z6 from high to low.
    The suggested use of the comparator and the '240 is to change the state of the line going to Z3/Z6 when Z4/Z5 match the key.
    I believe this follows what you've just said.
    The key first connects one of the leads from RP7/RP9 to Z6.
    KBINT goes active.
    The line through the key stays high until a low strobe from Z4/Z5 match with the key. The line to Z3/Z6 now detects a low and knows which key has been hit.
    How much time do you have between when Z4/Z5 match and the processor in the PA detects the key and how much time are you possibly away dealing with a PS/2 keyboard interrupt. The circuit I propose is only delayed by the time it takes the wires and gates to carry the signal. How do you propose to take the match signal from Z4/Z5 to the line going to Z3/Z6? and how much time is requires to handle a PS/2 keyboard interrupt? A PS/2 interrupt can take several 10's of micro seconds to milliseconds, depending on how the code you are using works. Both sides need to be real time operations.

  7. #37


    I think what you don't see is that Z4/Z5 both are not driving anything when the key is struck. The pull up resistors RP7 and RP8 are. It is one of those that creates the interrupt though Z6. With the keys deselected the resistor RP9 holds the lines low.

    I did type pretty much this out since the key being pressed is the only thing that can make Z3, one of Z4/5 and Z6 all active at the same time, I've only just spotted it's gone from my reply so I've no idea why I deleted it. Odd.

    I see what you mean about the comparator now, yes, makes sense, it's me that has to drive both pin 3s because without it I don't have anything on the keyboard matrix side of things for the 4051s to compare against.

    Thanks for all your help on this, it's the most complicated circuit I've pondered building. The software side of things will be interesting too but I spent many years as a coder so hopefully that'll help. - UK home computer history
    Where RIFA capacitors come to die

  8. #38


    There are other ways of dealing with things. I used the '240 because I can use it with minimal hardware to create both the key first hit and then the pull down caused by the match to Z4/Z5. I may have an issue still. I wasn't thinking about the other lines and what they were doing. They should all remain low while only the one line is pulled low. I don't think the circuit I gave you does that.
    I'll give it some more thought. The basic concept of watching the Z4/Z5 for a match still makes sense. You may be right that you only need to watch Z4 as I didn't look at things on the keyboards side. I think one '688 is still needed.

  9. #39


    I'm looking at the signals from the keyboard to Z3. If I read them right, you have mix of pins from both SK7 and SK6 from the keyboard. There are 5 from SK7 and 3 from SK6. I've not seen your table that you've ohmed out. It looks like just Z4 has enough combinations with the Z3 input to do 256 ( 8*8 ) different combinations. I just wonder why they have Z5 then? Maybe I'm missing something. I'm thinking they did both sides because of a routing problem on the keyboard. When you tell me that you can decode all the keys with just Z4, I wonder why they have Z5 at all?

  10. #40


    I gave it some more thought. Instead of the '244 or '240, you need 8 two input AND gates ( 2 ICs ) plus one or two '688s ( as your decoding requires ). The output of the 8 gates go to the Z3/Z6. One input of each gate goes to the output of the comparator. This should have an invalid value to compare to so its output state, of the comparator, is '1'. When the keyboard uC has no key to send, it writes all '0' to the ANDs. Once a key is entered, from the PS/2 keyboard, it looks up the proper Z4/Z5 strobe and writes it to the comparator(s). It then sends the correct bit to set and sets only that bit on the port to the AND gates.
    Now the PA comes to action. This created a KBINT. It scans Z3 until it finds the bit that is a '1'. It then scan a strobe across Z4/Z5 until it see Z3 go to '0'. This happened because the comparator saw a match and dropped the compare out to '0', causing the AND gate with the '1' from the uC to output '0'. The uC should have an interrupt on the comaparator output. I suspect the PA wants to see the key stable for more than one pass. Maybe a debounce count of 3 passes? That will need to be determined by experimenting. Once the uC believes it has held long enough for debounce, it drop the '1' bit for the Z3/Z6 to '0' and the writes an invalid to the comaparator and waits for the next PS/2 key stroke.
    It may hold the key for auto repeat if that is desired, as the PS/2 keyboard sends both up and down strokes of each key.
    I hope this now makes some sense.
    Last edited by Dwight Elvey; April 24th, 2019 at 05:58 PM.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts