How do I Interface a PS/2 Keyboard without Modern Techniques?What was the first commercially available computer with ECC memory?How fast is memcpy on the Z80?Z80 and video chip contending for random accessZ8410 DMA chip as GPU?How do Z80 Block Transfer instructions work?Why do only the low 7-bits of the R register increment?Why do C to Z80 compilers produce poor code?Which Z80 opcodes can I use without a stack?Why does the Z80 include the RLD and RRD instructions?What Video Chips/Video generation techniques are usable for the Z80?How costly is it to put things on the stack with the Z80?

Is there anyway, I can have two passwords for my wi-fi

Telemetry for feature health

If Captain Marvel (MCU) were to have a child with a human male, would the child be human or Kree?

Sound waves in different octaves

How to get directions in deep space?

In One Punch Man, is King actually weak?

Do I have to know the General Relativity theory to understand the concept of inertial frame?

Can I cause damage to electrical appliances by unplugging them when they are turned on?

When and why was runway 07/25 at Kai Tak removed?

Would a primitive species be able to learn English from reading books alone?

Why didn’t Eve recognize the little cockroach as a living organism?

Can I say "fingers" when referring to toes?

Why would five hundred and five be same as one?

Alignment of six matrices

Are Captain Marvel's powers affected by Thanos breaking the Tesseract and claiming the stone?

Is there a reason to prefer HFS+ over APFS for disk images in High Sierra and/or Mojave?

If the only attacker is removed from combat, is a creature still counted as having attacked this turn?

Check if object is null and return null

Pre-Employment Background Check With Consent For Future Checks

Why is the principal energy of an electron lower for excited electrons in a higher energy state?

I'm just a whisper. Who am I?

Mimic lecturing on blackboard, facing audience

Animation: customize bounce interpolation

Is there a RAID 0 Equivalent for RAM?



How do I Interface a PS/2 Keyboard without Modern Techniques?


What was the first commercially available computer with ECC memory?How fast is memcpy on the Z80?Z80 and video chip contending for random accessZ8410 DMA chip as GPU?How do Z80 Block Transfer instructions work?Why do only the low 7-bits of the R register increment?Why do C to Z80 compilers produce poor code?Which Z80 opcodes can I use without a stack?Why does the Z80 include the RLD and RRD instructions?What Video Chips/Video generation techniques are usable for the Z80?How costly is it to put things on the stack with the Z80?













5















I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO. I'd like to build a machine with straightforward I/O, that it, the design requirement: one should be able to use the computer by simply plugging a PS/2 keyboard, rather than hooking it to a RS232, USB-TTL stick or some exotic CRT terminal.



But how to incorporate a PS/2 keyboard input to my computer is unclear to me. According to my research, this problem has been solved by the following approaches.



  1. Shift Register. A simple shift register like 74HC595N should be able to translate the serial data from the keyboard to parallel, and it can be clocked by the keyboard, so it has no problem to follow the PS/2 protocol. But PS/2 is 8-bit data, 1-bit parity, not 7-bit data! Both the Z80 and the shift register can only handle 8-bit of data , so the parity bit is ignored (or requires additional parts), not elegant. I don't think parity is only for farmers, especially when bidirectional transmission is also needed for controlling Caps Locks, etc. So a parity bit is needed, also, we need to follow the timing, have some meaningful interrupts control - all of these requires extra parts, which makes it difficult to design and program (especially when routing it on a single-layer board).



  2. USART. Although PS/2 is not designed as a USART-compatible protocol, there are reports of success by simply running the USART at 12,000 bauds and connecting the DATA line to a USART interface, and handling the keymap decoding in software. It sounds convenient since the USART is general-purpose, may perform buffering, parity check, and interrupt generation. However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution.



    2.1 SPI. Obviously, putting the widely-used SPI interface in slave mode can allow the serial transmission to be clocked by the keyboard. But I think it's just another clever trick to exploit the functionality on a modern microcontroller than a standard solution. Historically, it seems a SPI controller is never used in this way.



  3. PIC, Atmel, or ARM microcontroller. It's the most common, easiest, flexible solution used in various retrocomputing projects. But to me, having a microcontroller with processing power comparable to (or greater than) the Z80 CPU defeats the spirit of a retrocomputing project. I don't have a problem of using one for inherently computational intensive tasks, such as Ethernet or Wi-Fi, but for a mere keyboard, seriously?


  4. 8042. In the original IBM PC/AT design, the underlying keyboard control sequence is managed by the 8042 connected to the Intel 8255 PIO. A 8042 is just a version of the MCS-48 (8048) microcontroller designed for interfacing peripheral devices, IBM must have written a customized firmware. It's difficult to find a 8048 today, nevertheless, MCS-51 (8051) is also a retro chip so this one can be used, too. But is there a reference implementation of the original 8042 firmware available under a free and open source license?


  5. I think there are also controllers specifically made to control inputs like PS/2 keyboards, but they typically integrates more functionalities, and I'm not aware of a chip from the late 80s. If there is one, I think I could just use that, provides it was a common design choice of that time.


Currently, I'm considering to interface the PS/2 keyboard by implementing the 8042 keyboard controller on a 8051 MCU if there's a free reference implementation available, if not, I think it should be okay for me to implement something simpler, too.



But I think programming for two separate chips makes my project more difficult, especially for the initial prototype. I must have missed something... I knew most keyboards from that era were parallel ones, not PS/2, but there must be some additional and possibly simpler methods to interface a PS/2 keyboard, are there? How was it being done historically?










share|improve this question









New contributor




比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • This is very well-researched. Thanks for the question; I'll check back later to find out the answer. ☺

    – wizzwizz4
    3 hours ago















5















I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO. I'd like to build a machine with straightforward I/O, that it, the design requirement: one should be able to use the computer by simply plugging a PS/2 keyboard, rather than hooking it to a RS232, USB-TTL stick or some exotic CRT terminal.



But how to incorporate a PS/2 keyboard input to my computer is unclear to me. According to my research, this problem has been solved by the following approaches.



  1. Shift Register. A simple shift register like 74HC595N should be able to translate the serial data from the keyboard to parallel, and it can be clocked by the keyboard, so it has no problem to follow the PS/2 protocol. But PS/2 is 8-bit data, 1-bit parity, not 7-bit data! Both the Z80 and the shift register can only handle 8-bit of data , so the parity bit is ignored (or requires additional parts), not elegant. I don't think parity is only for farmers, especially when bidirectional transmission is also needed for controlling Caps Locks, etc. So a parity bit is needed, also, we need to follow the timing, have some meaningful interrupts control - all of these requires extra parts, which makes it difficult to design and program (especially when routing it on a single-layer board).



  2. USART. Although PS/2 is not designed as a USART-compatible protocol, there are reports of success by simply running the USART at 12,000 bauds and connecting the DATA line to a USART interface, and handling the keymap decoding in software. It sounds convenient since the USART is general-purpose, may perform buffering, parity check, and interrupt generation. However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution.



    2.1 SPI. Obviously, putting the widely-used SPI interface in slave mode can allow the serial transmission to be clocked by the keyboard. But I think it's just another clever trick to exploit the functionality on a modern microcontroller than a standard solution. Historically, it seems a SPI controller is never used in this way.



  3. PIC, Atmel, or ARM microcontroller. It's the most common, easiest, flexible solution used in various retrocomputing projects. But to me, having a microcontroller with processing power comparable to (or greater than) the Z80 CPU defeats the spirit of a retrocomputing project. I don't have a problem of using one for inherently computational intensive tasks, such as Ethernet or Wi-Fi, but for a mere keyboard, seriously?


  4. 8042. In the original IBM PC/AT design, the underlying keyboard control sequence is managed by the 8042 connected to the Intel 8255 PIO. A 8042 is just a version of the MCS-48 (8048) microcontroller designed for interfacing peripheral devices, IBM must have written a customized firmware. It's difficult to find a 8048 today, nevertheless, MCS-51 (8051) is also a retro chip so this one can be used, too. But is there a reference implementation of the original 8042 firmware available under a free and open source license?


  5. I think there are also controllers specifically made to control inputs like PS/2 keyboards, but they typically integrates more functionalities, and I'm not aware of a chip from the late 80s. If there is one, I think I could just use that, provides it was a common design choice of that time.


Currently, I'm considering to interface the PS/2 keyboard by implementing the 8042 keyboard controller on a 8051 MCU if there's a free reference implementation available, if not, I think it should be okay for me to implement something simpler, too.



But I think programming for two separate chips makes my project more difficult, especially for the initial prototype. I must have missed something... I knew most keyboards from that era were parallel ones, not PS/2, but there must be some additional and possibly simpler methods to interface a PS/2 keyboard, are there? How was it being done historically?










share|improve this question









New contributor




比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • This is very well-researched. Thanks for the question; I'll check back later to find out the answer. ☺

    – wizzwizz4
    3 hours ago













5












5








5








I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO. I'd like to build a machine with straightforward I/O, that it, the design requirement: one should be able to use the computer by simply plugging a PS/2 keyboard, rather than hooking it to a RS232, USB-TTL stick or some exotic CRT terminal.



But how to incorporate a PS/2 keyboard input to my computer is unclear to me. According to my research, this problem has been solved by the following approaches.



  1. Shift Register. A simple shift register like 74HC595N should be able to translate the serial data from the keyboard to parallel, and it can be clocked by the keyboard, so it has no problem to follow the PS/2 protocol. But PS/2 is 8-bit data, 1-bit parity, not 7-bit data! Both the Z80 and the shift register can only handle 8-bit of data , so the parity bit is ignored (or requires additional parts), not elegant. I don't think parity is only for farmers, especially when bidirectional transmission is also needed for controlling Caps Locks, etc. So a parity bit is needed, also, we need to follow the timing, have some meaningful interrupts control - all of these requires extra parts, which makes it difficult to design and program (especially when routing it on a single-layer board).



  2. USART. Although PS/2 is not designed as a USART-compatible protocol, there are reports of success by simply running the USART at 12,000 bauds and connecting the DATA line to a USART interface, and handling the keymap decoding in software. It sounds convenient since the USART is general-purpose, may perform buffering, parity check, and interrupt generation. However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution.



    2.1 SPI. Obviously, putting the widely-used SPI interface in slave mode can allow the serial transmission to be clocked by the keyboard. But I think it's just another clever trick to exploit the functionality on a modern microcontroller than a standard solution. Historically, it seems a SPI controller is never used in this way.



  3. PIC, Atmel, or ARM microcontroller. It's the most common, easiest, flexible solution used in various retrocomputing projects. But to me, having a microcontroller with processing power comparable to (or greater than) the Z80 CPU defeats the spirit of a retrocomputing project. I don't have a problem of using one for inherently computational intensive tasks, such as Ethernet or Wi-Fi, but for a mere keyboard, seriously?


  4. 8042. In the original IBM PC/AT design, the underlying keyboard control sequence is managed by the 8042 connected to the Intel 8255 PIO. A 8042 is just a version of the MCS-48 (8048) microcontroller designed for interfacing peripheral devices, IBM must have written a customized firmware. It's difficult to find a 8048 today, nevertheless, MCS-51 (8051) is also a retro chip so this one can be used, too. But is there a reference implementation of the original 8042 firmware available under a free and open source license?


  5. I think there are also controllers specifically made to control inputs like PS/2 keyboards, but they typically integrates more functionalities, and I'm not aware of a chip from the late 80s. If there is one, I think I could just use that, provides it was a common design choice of that time.


Currently, I'm considering to interface the PS/2 keyboard by implementing the 8042 keyboard controller on a 8051 MCU if there's a free reference implementation available, if not, I think it should be okay for me to implement something simpler, too.



But I think programming for two separate chips makes my project more difficult, especially for the initial prototype. I must have missed something... I knew most keyboards from that era were parallel ones, not PS/2, but there must be some additional and possibly simpler methods to interface a PS/2 keyboard, are there? How was it being done historically?










share|improve this question









New contributor




比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO. I'd like to build a machine with straightforward I/O, that it, the design requirement: one should be able to use the computer by simply plugging a PS/2 keyboard, rather than hooking it to a RS232, USB-TTL stick or some exotic CRT terminal.



But how to incorporate a PS/2 keyboard input to my computer is unclear to me. According to my research, this problem has been solved by the following approaches.



  1. Shift Register. A simple shift register like 74HC595N should be able to translate the serial data from the keyboard to parallel, and it can be clocked by the keyboard, so it has no problem to follow the PS/2 protocol. But PS/2 is 8-bit data, 1-bit parity, not 7-bit data! Both the Z80 and the shift register can only handle 8-bit of data , so the parity bit is ignored (or requires additional parts), not elegant. I don't think parity is only for farmers, especially when bidirectional transmission is also needed for controlling Caps Locks, etc. So a parity bit is needed, also, we need to follow the timing, have some meaningful interrupts control - all of these requires extra parts, which makes it difficult to design and program (especially when routing it on a single-layer board).



  2. USART. Although PS/2 is not designed as a USART-compatible protocol, there are reports of success by simply running the USART at 12,000 bauds and connecting the DATA line to a USART interface, and handling the keymap decoding in software. It sounds convenient since the USART is general-purpose, may perform buffering, parity check, and interrupt generation. However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution.



    2.1 SPI. Obviously, putting the widely-used SPI interface in slave mode can allow the serial transmission to be clocked by the keyboard. But I think it's just another clever trick to exploit the functionality on a modern microcontroller than a standard solution. Historically, it seems a SPI controller is never used in this way.



  3. PIC, Atmel, or ARM microcontroller. It's the most common, easiest, flexible solution used in various retrocomputing projects. But to me, having a microcontroller with processing power comparable to (or greater than) the Z80 CPU defeats the spirit of a retrocomputing project. I don't have a problem of using one for inherently computational intensive tasks, such as Ethernet or Wi-Fi, but for a mere keyboard, seriously?


  4. 8042. In the original IBM PC/AT design, the underlying keyboard control sequence is managed by the 8042 connected to the Intel 8255 PIO. A 8042 is just a version of the MCS-48 (8048) microcontroller designed for interfacing peripheral devices, IBM must have written a customized firmware. It's difficult to find a 8048 today, nevertheless, MCS-51 (8051) is also a retro chip so this one can be used, too. But is there a reference implementation of the original 8042 firmware available under a free and open source license?


  5. I think there are also controllers specifically made to control inputs like PS/2 keyboards, but they typically integrates more functionalities, and I'm not aware of a chip from the late 80s. If there is one, I think I could just use that, provides it was a common design choice of that time.


Currently, I'm considering to interface the PS/2 keyboard by implementing the 8042 keyboard controller on a 8051 MCU if there's a free reference implementation available, if not, I think it should be okay for me to implement something simpler, too.



But I think programming for two separate chips makes my project more difficult, especially for the initial prototype. I must have missed something... I knew most keyboards from that era were parallel ones, not PS/2, but there must be some additional and possibly simpler methods to interface a PS/2 keyboard, are there? How was it being done historically?







z80 input-devices






share|improve this question









New contributor




比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 1 hour ago







比尔盖子













New contributor




比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 3 hours ago









比尔盖子比尔盖子

1264




1264




New contributor




比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






比尔盖子 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • This is very well-researched. Thanks for the question; I'll check back later to find out the answer. ☺

    – wizzwizz4
    3 hours ago

















  • This is very well-researched. Thanks for the question; I'll check back later to find out the answer. ☺

    – wizzwizz4
    3 hours ago
















This is very well-researched. Thanks for the question; I'll check back later to find out the answer. ☺

– wizzwizz4
3 hours ago





This is very well-researched. Thanks for the question; I'll check back later to find out the answer. ☺

– wizzwizz4
3 hours ago










1 Answer
1






active

oldest

votes


















2















I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO.




So there's a Z80-PIO? Isn't that already the solution to be used?



Not to mention, that adding another micro controller for a job the main CPU can do as well is neither simple nor true to the spirit of early systems. I mean, adding another whole computer system, even of greater performance than the main system, just for a keyboard Interface?



A Z80 with a PIO can do everything (*1) a separate system can do. In this case it needs 4 port bits. Two for receiving data/clock from the keyboard/mouse, two to overwrite these to initiate a output sequence and control output data. External two drivers for the input signal, two resistors and two transistors, as shown, may be helpful.



External circuitry for PS/2



It may be helpful if the clock input pin can be set to interrupt the CPU so a response to a key press can be handled without polling, but it'll work as well by pulling clock low and only releasing it when ready to receive a byte (*2)



Everything after that is simply bitbanging the protocol. The CPU got 5 microseconds per bit to react, which can be done on a tight looped 4 MHz Z80. Of course it will need some fine tuning, but isn't that exactly the goal of your project?




On A side note:




USART. [...] However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution




Of course it is a proper solution - all needed is to clock the USART externally. Important here, the Z80 SIO is well fited to do the required 8E1 data format. Neither a hack nor anything clever is needed - maybe except to detect the acknowledge bit on host to kbd transfers.




And further:




How was it being done historically?




This depends a lot on the machine we're talking about.



Parallel keyboards where somewhat common, when it came to ready made units to be added as component. These where either



  • hard encoded (diodes!) or

  • via a decoder circuit (think Apple II).

Serial was (in the beginning) even more common, usually when keyboards had to be complete OEM units just to be plugged in (DEC, Apple Lisa)



Home/custom build solutions for embedded keyboards operated by scanning a matrix from the main CPU



  • via some latches,

  • a PIO like port (PET),

  • some combinations of both (Tandy MC-10). Or worse:

  • By mapping the matrix as data into an address range (TRS-80 M1)


*1 - Well, next to that is, as separate controllers may be faster in some special cases - except, PS/2 is none of them.



*2 - Yes, very easy and a protocol conform way. Drawback here is that each poll will have to wait at least for 100 (better 200) microseconds after releasing the clock line to check if the keyboard wants to send at all. So not really cool.






share|improve this answer
























    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "648"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );






    比尔盖子 is a new contributor. Be nice, and check out our Code of Conduct.









    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9382%2fhow-do-i-interface-a-ps-2-keyboard-without-modern-techniques%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2















    I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO.




    So there's a Z80-PIO? Isn't that already the solution to be used?



    Not to mention, that adding another micro controller for a job the main CPU can do as well is neither simple nor true to the spirit of early systems. I mean, adding another whole computer system, even of greater performance than the main system, just for a keyboard Interface?



    A Z80 with a PIO can do everything (*1) a separate system can do. In this case it needs 4 port bits. Two for receiving data/clock from the keyboard/mouse, two to overwrite these to initiate a output sequence and control output data. External two drivers for the input signal, two resistors and two transistors, as shown, may be helpful.



    External circuitry for PS/2



    It may be helpful if the clock input pin can be set to interrupt the CPU so a response to a key press can be handled without polling, but it'll work as well by pulling clock low and only releasing it when ready to receive a byte (*2)



    Everything after that is simply bitbanging the protocol. The CPU got 5 microseconds per bit to react, which can be done on a tight looped 4 MHz Z80. Of course it will need some fine tuning, but isn't that exactly the goal of your project?




    On A side note:




    USART. [...] However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution




    Of course it is a proper solution - all needed is to clock the USART externally. Important here, the Z80 SIO is well fited to do the required 8E1 data format. Neither a hack nor anything clever is needed - maybe except to detect the acknowledge bit on host to kbd transfers.




    And further:




    How was it being done historically?




    This depends a lot on the machine we're talking about.



    Parallel keyboards where somewhat common, when it came to ready made units to be added as component. These where either



    • hard encoded (diodes!) or

    • via a decoder circuit (think Apple II).

    Serial was (in the beginning) even more common, usually when keyboards had to be complete OEM units just to be plugged in (DEC, Apple Lisa)



    Home/custom build solutions for embedded keyboards operated by scanning a matrix from the main CPU



    • via some latches,

    • a PIO like port (PET),

    • some combinations of both (Tandy MC-10). Or worse:

    • By mapping the matrix as data into an address range (TRS-80 M1)


    *1 - Well, next to that is, as separate controllers may be faster in some special cases - except, PS/2 is none of them.



    *2 - Yes, very easy and a protocol conform way. Drawback here is that each poll will have to wait at least for 100 (better 200) microseconds after releasing the clock line to check if the keyboard wants to send at all. So not really cool.






    share|improve this answer





























      2















      I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO.




      So there's a Z80-PIO? Isn't that already the solution to be used?



      Not to mention, that adding another micro controller for a job the main CPU can do as well is neither simple nor true to the spirit of early systems. I mean, adding another whole computer system, even of greater performance than the main system, just for a keyboard Interface?



      A Z80 with a PIO can do everything (*1) a separate system can do. In this case it needs 4 port bits. Two for receiving data/clock from the keyboard/mouse, two to overwrite these to initiate a output sequence and control output data. External two drivers for the input signal, two resistors and two transistors, as shown, may be helpful.



      External circuitry for PS/2



      It may be helpful if the clock input pin can be set to interrupt the CPU so a response to a key press can be handled without polling, but it'll work as well by pulling clock low and only releasing it when ready to receive a byte (*2)



      Everything after that is simply bitbanging the protocol. The CPU got 5 microseconds per bit to react, which can be done on a tight looped 4 MHz Z80. Of course it will need some fine tuning, but isn't that exactly the goal of your project?




      On A side note:




      USART. [...] However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution




      Of course it is a proper solution - all needed is to clock the USART externally. Important here, the Z80 SIO is well fited to do the required 8E1 data format. Neither a hack nor anything clever is needed - maybe except to detect the acknowledge bit on host to kbd transfers.




      And further:




      How was it being done historically?




      This depends a lot on the machine we're talking about.



      Parallel keyboards where somewhat common, when it came to ready made units to be added as component. These where either



      • hard encoded (diodes!) or

      • via a decoder circuit (think Apple II).

      Serial was (in the beginning) even more common, usually when keyboards had to be complete OEM units just to be plugged in (DEC, Apple Lisa)



      Home/custom build solutions for embedded keyboards operated by scanning a matrix from the main CPU



      • via some latches,

      • a PIO like port (PET),

      • some combinations of both (Tandy MC-10). Or worse:

      • By mapping the matrix as data into an address range (TRS-80 M1)


      *1 - Well, next to that is, as separate controllers may be faster in some special cases - except, PS/2 is none of them.



      *2 - Yes, very easy and a protocol conform way. Drawback here is that each poll will have to wait at least for 100 (better 200) microseconds after releasing the clock line to check if the keyboard wants to send at all. So not really cool.






      share|improve this answer



























        2












        2








        2








        I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO.




        So there's a Z80-PIO? Isn't that already the solution to be used?



        Not to mention, that adding another micro controller for a job the main CPU can do as well is neither simple nor true to the spirit of early systems. I mean, adding another whole computer system, even of greater performance than the main system, just for a keyboard Interface?



        A Z80 with a PIO can do everything (*1) a separate system can do. In this case it needs 4 port bits. Two for receiving data/clock from the keyboard/mouse, two to overwrite these to initiate a output sequence and control output data. External two drivers for the input signal, two resistors and two transistors, as shown, may be helpful.



        External circuitry for PS/2



        It may be helpful if the clock input pin can be set to interrupt the CPU so a response to a key press can be handled without polling, but it'll work as well by pulling clock low and only releasing it when ready to receive a byte (*2)



        Everything after that is simply bitbanging the protocol. The CPU got 5 microseconds per bit to react, which can be done on a tight looped 4 MHz Z80. Of course it will need some fine tuning, but isn't that exactly the goal of your project?




        On A side note:




        USART. [...] However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution




        Of course it is a proper solution - all needed is to clock the USART externally. Important here, the Z80 SIO is well fited to do the required 8E1 data format. Neither a hack nor anything clever is needed - maybe except to detect the acknowledge bit on host to kbd transfers.




        And further:




        How was it being done historically?




        This depends a lot on the machine we're talking about.



        Parallel keyboards where somewhat common, when it came to ready made units to be added as component. These where either



        • hard encoded (diodes!) or

        • via a decoder circuit (think Apple II).

        Serial was (in the beginning) even more common, usually when keyboards had to be complete OEM units just to be plugged in (DEC, Apple Lisa)



        Home/custom build solutions for embedded keyboards operated by scanning a matrix from the main CPU



        • via some latches,

        • a PIO like port (PET),

        • some combinations of both (Tandy MC-10). Or worse:

        • By mapping the matrix as data into an address range (TRS-80 M1)


        *1 - Well, next to that is, as separate controllers may be faster in some special cases - except, PS/2 is none of them.



        *2 - Yes, very easy and a protocol conform way. Drawback here is that each poll will have to wait at least for 100 (better 200) microseconds after releasing the clock line to check if the keyboard wants to send at all. So not really cool.






        share|improve this answer
















        I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO.




        So there's a Z80-PIO? Isn't that already the solution to be used?



        Not to mention, that adding another micro controller for a job the main CPU can do as well is neither simple nor true to the spirit of early systems. I mean, adding another whole computer system, even of greater performance than the main system, just for a keyboard Interface?



        A Z80 with a PIO can do everything (*1) a separate system can do. In this case it needs 4 port bits. Two for receiving data/clock from the keyboard/mouse, two to overwrite these to initiate a output sequence and control output data. External two drivers for the input signal, two resistors and two transistors, as shown, may be helpful.



        External circuitry for PS/2



        It may be helpful if the clock input pin can be set to interrupt the CPU so a response to a key press can be handled without polling, but it'll work as well by pulling clock low and only releasing it when ready to receive a byte (*2)



        Everything after that is simply bitbanging the protocol. The CPU got 5 microseconds per bit to react, which can be done on a tight looped 4 MHz Z80. Of course it will need some fine tuning, but isn't that exactly the goal of your project?




        On A side note:




        USART. [...] However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution




        Of course it is a proper solution - all needed is to clock the USART externally. Important here, the Z80 SIO is well fited to do the required 8E1 data format. Neither a hack nor anything clever is needed - maybe except to detect the acknowledge bit on host to kbd transfers.




        And further:




        How was it being done historically?




        This depends a lot on the machine we're talking about.



        Parallel keyboards where somewhat common, when it came to ready made units to be added as component. These where either



        • hard encoded (diodes!) or

        • via a decoder circuit (think Apple II).

        Serial was (in the beginning) even more common, usually when keyboards had to be complete OEM units just to be plugged in (DEC, Apple Lisa)



        Home/custom build solutions for embedded keyboards operated by scanning a matrix from the main CPU



        • via some latches,

        • a PIO like port (PET),

        • some combinations of both (Tandy MC-10). Or worse:

        • By mapping the matrix as data into an address range (TRS-80 M1)


        *1 - Well, next to that is, as separate controllers may be faster in some special cases - except, PS/2 is none of them.



        *2 - Yes, very easy and a protocol conform way. Drawback here is that each poll will have to wait at least for 100 (better 200) microseconds after releasing the clock line to check if the keyboard wants to send at all. So not really cool.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 24 mins ago

























        answered 1 hour ago









        RaffzahnRaffzahn

        53.2k6129215




        53.2k6129215




















            比尔盖子 is a new contributor. Be nice, and check out our Code of Conduct.









            draft saved

            draft discarded


















            比尔盖子 is a new contributor. Be nice, and check out our Code of Conduct.












            比尔盖子 is a new contributor. Be nice, and check out our Code of Conduct.











            比尔盖子 is a new contributor. Be nice, and check out our Code of Conduct.














            Thanks for contributing an answer to Retrocomputing Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9382%2fhow-do-i-interface-a-ps-2-keyboard-without-modern-techniques%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            How should I use the fbox command correctly to avoid producing a Bad Box message?How to put a long piece of text in a box?How to specify height and width of fboxIs there an arrayrulecolor-like command to change the rule color of fbox?What is the command to highlight bad boxes in pdf?Why does fbox sometimes place the box *over* the graphic image?how to put the text in the boxHow to create command for a box where text inside the box can automatically adjust?how can I make an fbox like command with certain color, shape and width of border?how to use fbox in align modeFbox increase the spacing between the box and it content (inner margin)how to change the box height of an equationWhat is the use of the hbox in a newcommand command?

            Doxepinum Nexus interni Notae | Tabula navigationis3158DB01142WHOa682390"Structural Analysis of the Histamine H1 Receptor""Transdermal and Topical Drug Administration in the Treatment of Pain""Antidepressants as antipruritic agents: A review"

            inputenc: Unicode character … not set up for use with LaTeX The Next CEO of Stack OverflowEntering Unicode characters in LaTeXHow to solve the `Package inputenc Error: Unicode char not set up for use with LaTeX` problem?solve “Unicode char is not set up for use with LaTeX” without special handling of every new interesting UTF-8 characterPackage inputenc Error: Unicode character ² (U+B2)(inputenc) not set up for use with LaTeX. acroI2C[I²C]package inputenc error unicode char (u + 190) not set up for use with latexPackage inputenc Error: Unicode char u8:′ not set up for use with LaTeX. 3′inputenc Error: Unicode char u8: not set up for use with LaTeX with G-BriefPackage Inputenc Error: Unicode char u8: not set up for use with LaTeXPackage inputenc Error: Unicode char ́ (U+301)(inputenc) not set up for use with LaTeX. includePackage inputenc Error: Unicode char ̂ (U+302)(inputenc) not set up for use with LaTeX. … $widehatleft (OA,AA' right )$Package inputenc Error: Unicode char â„¡ (U+2121)(inputenc) not set up for use with LaTeX. printbibliography[heading=bibintoc]Package inputenc Error: Unicode char − (U+2212)(inputenc) not set up for use with LaTeXPackage inputenc Error: Unicode character α (U+3B1) not set up for use with LaTeXPackage inputenc Error: Unicode characterError: ! Package inputenc Error: Unicode char ⊘ (U+2298)(inputenc) not set up for use with LaTeX