Model II keyboards

[kb2syd]

I have at least 2 model II computers without keyboards. Has anyone figured out the serial protocol yet and made a PS/2 adapter?

I have a couple of keyboards we can test with.

Alternatively, anyone want my extra model II computers sans keyboard? Make an offer, figuring on you arranging pickup or shipping from 07461.

Kelly

 

[dfnr2]

The Unified Retrocomputer Keyboard Project might be an option for an authentic-feeling replacement.

If you don't need an exact match to the original cutout, then you could use either the classic or Sol-20 layout, and replace the small parallel out routine with a bit-bang serial out routine. I'd be happy to help with that.

If you want an exact replica, it looks like you could start with the "classic" layout, and modify it slightly to get a faithful reproduction of the Model II keyboard. You'd need to create a keymap for the Model II, which would also be pretty easy, and I'd be happy to help.

Forum post with photo of a "classic" keyboard

Forum post with photo of a Sol-20 keyboard:

The key "classic" keycap set should cover all the main keypad except the 1.5x ESC and 2x ENTER keys (the classic set has a 1x ESC and 1.5x RETURN), plus the keypad keys. The Sol-20 keycap supplement has the numeric keypad keys, but also a lot of expensive extra keys that would be superfluous to the Model II. Given sufficient interest, a Model II keycap supplement could be ordered as a package from Signature Plastics, and the cost is not terrible if you get a group buy of 10 or 20 sets.

[edited for clarity]

 

[kb2syd]

I don't care about layout. I'm concerned with the serial bit-bang routine and handshake. I can I help you help me?

 

[pski]

There is ongoing work on a USB to M2 keyboard adapter. The individuals involved say it's close. I am eagerly awaiting it as well!

 

[kb2syd]

There is ongoing work on a USB to M2 keyboard adapter. The individuals involved say it's close. I am eagerly awaiting it as well!

It would make the two I have without keyboards at least usable again. I've got two more with keyboards I think. Maybe three. My basement is a wreck and my wife is getting grumpy about it. Don't blame her.

 

[bladamson]

This is something that is on my project list, too.

The timing diagram for the keyboard serial protocol is on page 65 of the Model II technical reference manual, and the scancodes that the various keys produce are listed on page 136, although it is not clear to me how the CAPS keycodes work, as one would think they'd be the same as the shifted codes for most keys. It's also unclear to me whether key repeat is handled by the keyboard hardware or the OS. Both of these could be figured out through experimentation fairly trivially once the bit banging protocol were written, though.

I doubt that it would be a completely trivial 1-weekend project, but I don't think it'd be too crazy. It's very similar to how the PS/2 keyboard protocol works, except that it's unidirectional which simplifies things immensely.

One would probably need to refer to the 16/6000 manuals to get codes for the keys that are not present on the MII keyboard as well.

My idea was to hack up something on an ESP32 module, using the FabGL library, to read a PS/2 or MII keyboard, as well as output to VGA, and present itself on the backplane side with the same IO port and memory interface as the Tandy video/keyboard card (although I am sure that the wait states it generated would be different than the Tandy card, especially for video memory accesses, so it might not be 100% compatible with really tightly timed stuff that directly hits the hardware). Note that I'd be *reading* the MII keyboard in this case, but I 'spect that it would be fairly easy to reverse it. As for the reading of PS/2 or USB keyboard data, all the code for that already exists in various Arduino libraries.

In the case of just doing keyboard conversion without messing with video as well, I 'spect that could be done with a lot of the same code, probably with just a $4 ESP8266 module and a TTL buffer and a couple of resistors for converting between 5v and 3.3v.

But I have many things ahead of this on my Model II project list, so who knows when/if I'll get 'round to it.

Anyway, sorry for going on at length with a non-answer! It's just something I've been thinking about too, as I tool around on tractors and work on fence all day, looking forward to when I can go home and fool with old computers. :3

 

[dfnr2]

I don't care about layout. I'm concerned with the serial bit-bang routine and handshake. I can I help you help me?

Looking at page 65 and schematic on p. 72 of the manual, the serial protocol is very simple:

- 
if /BUSY line is high, then
    grab a code from the buffer

    loop for 8 bits:
        set DATA line to LSB of output code
        toggle clock line
        shift the code right one bit

    toggle a STOP pulse on the DATA line

The /BUSY line is set high as soon as the TRS-80 reads the received byte from the shift register, so not much latency.

The codes seem to be (almost) standard ASCII, not keyscan codes as suggested in another post. The nonstandard part is that CAPS sets bit 7, which ASCII doesn't use as it's a 7-bit code. But the lower 7 bits (0-6) seem to behave as normal ASCII. Also, in addition to normal CTRL codes, the CTRL key seems to send special extra-ASCII codes for some keys, like the number keys on the main keyboard.

Shift and CAPS are handled by the main keyboard.

I do have a question about the LOCK key. Does it work by locking either CAPS or SHIFT when pressed together with one of those keys? It doesn't matter if you don't care about reproducing the layout, but I am curious.

If you're interested in building up a keyboard, PM me and I can set you up with a kit. I don't mind writing a serial out routine and fixing up a keymap for the non-standard ASCII superset.

I'd suggest going with the classic ASCII layout, as it can do everything the model II keyboard can do, even the special extra-ASCII codes (for CAPS and CTRL), as each keymap can be set separately. The F1 and F2 keys on the keypad are just CTRL-A and CTRL-B, according to the manual, p. 136. The Sol-20 keyboard might be a nice option, but with the expanded keycap set and more key switches, it ends up being more expensive than the classic layout.

If there's enough interest, I wouldn't mind at some point creating a PCB for a precise Model II keyboard replica. But I'd need someone to measure the distance between the main keyboard section and the keypad.

 

[lowen]

As pski said, there is work being done by people with deep knowledge of the hardware. (No, I'm not one the the people working on this).

The protocol, while pretty simple, is NOT quite as simple as it first appears. The receiving device on the video/keyboard card needs to be carefully studied as to what kind of signals it responds to in order to for it to actually work. Hint: it's edge-triggered, not level-sensitive, and the tech manual shows it; two lows back to back can't be sent as a solid low, there must be an edge.

Kelly, check the discord, as much of the discussion about this device has happened over there.

 

[shank]

i have one in beta. the standard model II/16 emulation is complete and if you have xenix 3.3 then it will operate the virtual consoles. we're also working on the tandy 2000 keyboard emulation for xenix 3.3 which offers some increased functionality.

if you're willing to take a beta product, DM me your info along with the machine type (model II, 12, etc...).

we've dropped ps/2 keyboards in favor of USB.

 

[lowen]

THESE are the droids you want.

 

[iv@trsvax]

i have one in beta. the standard model II/16 emulation is complete and if you have xenix 3.3 then it will operate the virtual consoles. we're also working on the tandy 2000 keyboard emulation for xenix 3.3 which offers some increased functionality.

Since the II/16 emulation allows virtual consoles on 3.3 (via key macros which we've defaulted to console switching for ALT-n and ALT-Fn), the 'increased functionality' of which he speaks is basically the ALT key and other extra keys the II/16 keyboard does not have.

 

[dfnr2]

This is something that is on my project list, too.
. . . although it is not clear to me how the CAPS keycodes work, as one would think they'd be the same as the shifted codes for most keys.

The CAPS codes are just the regular ASCII uppercase codes--what you'd expect with a normal CAPS key--but with the 0x80 bit also set.

It's also unclear to me whether key repeat is handled by the keyboard hardware or the OS.

REPEAT is handled in the keyboard.

Does the Model II keyboard have autorepeat, or does it only use the REPEAT key?

I doubt that it would be a completely trivial 1-weekend project, but I don't think it'd be too crazy. It's very similar to how the PS/2 keyboard protocol works, except that it's unidirectional which simplifies things immensely.

It's not really like a PS/2 keyboard. It's really an ASCII keyboard that adds a few extra-ASCII codes, and clocks out the byte via a clock and data line, rather than a parallel port and strobe.

Mating a PS/2 keyboard would involve tracking state of the modifier keys and mapping keycodes codes to the extended ASCII character set produced by the keyboard.

However, modifying the existing ASDF keyboard firmware to support this keyboard would take less than an hour, maybe a full hour to clean up the keymaps. Getting an accurate hardware replica would extend it to a weekend project, but getting special keycaps would take a couple of months. I certainly would be happy to help is someone wants to try getting a keyboard working with their Model II.

The whole point of the unified keyboard project is to make it easy to make replacement keyboards for retrocomputers, and then gather them in one place, with a common hardware/software base.

Dave

 

[dfnr2]

The protocol, while pretty simple, is NOT quite as simple as it first appears. The receiving device on the video/keyboard card needs to be carefully studied as to what kind of signals it responds to in order to for it to actually work. Hint: it's edge-triggered, not level-sensitive, and the tech manual shows it; two lows back to back can't be sent as a solid low, there must be an edge.

The protocol diagram seems to indicate that the protocol would be exactly as simple as the schematic suggests, no more or less. The keyboard clocks the bits into a TTL shift register ('164). The keyboard sets value of the data line when the clock is high to avoid generating a premature interrupt, per the protocol. The "Stop" bit toggles the data line high with the clock line held high, asserting the /IRQ signal which is cleared when the register is read by the processor. The /IRQ signal also serves as the /BUSY signal.

The timing is not critical, other than ensuring that settling times and TTL propagation times are met.

I included the pseudocode of the protocol a couple of posts ago. The working code would be about the same size.

Dave

 

[dfnr2]

. . . the tech manual shows it; two lows back to back can't be sent as a solid low, there must be an edge.

Not quite. For example, if 0xff were sent, then the DATA line would stay high the whole time. I don't think 0xff is a valid code, but 0x7f is, and the DATA line will remain high for all but one clock cycle, not counting the "STOP" pulse.

The diagram indicates that any low-to-high data line transition has to happen while the clock is high. The clock line doesn't need to be high for the first data bit to be set because the data line is high, and can either have no transition or a high-to-low transition, neither of which will trigger an IRQ.

The Clock and Data lines map to the clock and data lines of the shift register, but have reverse function for the /IRQ latch, so a low-to-high transition on the data line latches the state of the CLOCK line to the Q output of the 7474, which is drives the /IRQ and /BUSY signals. That's how the STOP bit at the end of the transmission works.

So, to explicitly include the timing in the pseudocode:

if /BUSY line is high, then
    grab a code from the buffer

    loop for 8 bits:
        set DATA line to LSB of output code
        toggle clock line high   --> clock the shift register
        set DATA line high      ---> clock the flip flop, latching /IRQ, /BUSY high
        toggle the clock line low
        shift the code right one bit

    set DATA line low       --> clock the flip-flop, latching the /IRQ and /BUSY low (active)
    set DATA line high      --> return DATA line to initial state for next transmission

Dave

 

[lowen]

Note that you posted while I was composing this reply; I'm using my phone, and have been typing and editing for over an hour, it feels like...but I have learned, especially when composing a lengthy reply on my phone, to refresh the thread in another tab, so I have seen your updated pseudocode, and have trimmed my reply down somewhat since you did address the timing constraint that makes the protocol not as simple as it first appears. I'm still going to go ahead and elaborate just a bit, since I overgeneralized about back-to-back lows and edge transitions.

The protocol diagram seems to indicate that the protocol would be exactly as simple as the schematic suggests, no more or less.

Well, the "NOT quite as simple" remark I made was about a not quite obvious constraint on the presence and timing of rising edges in the data line's stream. Any time level-sensitive and edge-triggered inputs are mixed on one signal the logic can become non-obvious, and here we have two such signals, the data and the clock for the keyboard.

The clocking is rising edge for both U6 and U17; you need to make sure your data line (which rising-edge clocks U17) doesn't have a rising edge while the keyboard clock (level-sensitive data input to U17) is low anywhere in the bitstream other than the stop bit, and so the protocol diagram shows a controlled rising edge after each low level on the data line for every time clock is high.

Failing to account for the restriction on the timing of any rising edges in the data line could cause a false trigger of U17 and thus the IRQ. Edit: this wording is clumsy; there was more here before some edits. "Trigger" here should be read as "latching the state of a low clock to the output driving BUSY and KBIRQ."

Now, if you can constrain all rising edges on the data line to happen during a high level on clock you might be able to do it without the "return to high during high clock, if data is low" dance; regardless, this is a non-obvious timing restriction that does warrant a non-cursory look at the schematic and at the spec sheets for both U6 and U17 to prevent spurious IRQs and corrupted keystroke data.


The project you mention looks really neat, if you want a vintage look and feel. I've been following your progress for quite a while now, and I'm pretty confident you could make this relatively simple serial protocol work.

The converter I mentioned is to be able to use any standard (yes, and boring) USB PC keyboard; I have a couple older PS/2 Model M's I plan to use with a PS/2 to USB converter with one. I honestly don't want to duplicate the Model II layout; there are keys in the "wrong" places relative to what my touch-typing fingers are used to! Edit: when I'm using a real keyboard; I don't think I'll ever get used to typing on a phone-y touch screen.....

But I can see the appeal of your project, for sure.

 

[dfnr2]

. . . Note that you posted while I was composing this reply . . .

The protocol diagram seems to indicate that the protocol would be exactly as simple as the schematic suggests, no more or less.

Well, the "NOT quite as simple" remark I made was about a not quite obvious constraint on the presence and timing of rising edges in the data line's stream. Any time level-sensitive and edge-triggered inputs are mixed on one signal the logic can become non-obvious, and here we have two such signals, the data and the clock for the keyboard.

Looking back, my reply seems a bit snarky. In my defense, I was recovering from surgery yesterday afternoon (nothing too serious) and was moderately medicated. I just woke up (in pain but unmedicated) and to my eyes, my own words seem a bit prickly, even though that was not the intent (I was trying to reference the quote about something being "as simple as possible, no more"). My apologies You clearly understand what's going on (and the word "trigger" seems perfectly accurate to me as well).

I do think it's important to be able to interface USB/PS2 keyboards to old machines, as they are ubiquitous and in most cases, much more pleasant to use than the original keyboards.

Dave

 

[lowen]

... I just woke up (in pain but unmedicated) and to my eyes, my own words seem a bit prickly, even though that was not the intent (I was trying to reference the quote about something being "as simple as possible, no more"). My apologies

First, I hope you get well soon! Second, no need to apologize to me, I didn't take any offense; no worries. But thank you for your graciousness.

You clearly understand what's going on (and the word "trigger" seems perfectly accurate to me as well).

Well, honestly I hadn't looked at it in that much detail before; I just remember seeing it written about by shank, who has had way more experience than I with this hardware, in another forum; while I don't remember the exact words, I remembered the gist of it, which led to my oversimplified remark about two lows in a row, which was both incomplete and not quite correct.

Anyway, this thread spurred me to actually understand what was really going on for myself, and it was fun to re-learn a logic paradigm from long ago when my digital logic instructor cautioned the class to always take a closer look when edge-triggered and level-sensitive inputs are intermingled, as, in his words, "thar be dragons." With synchronous FPGA designs it becomes even more necessary, especially when interfacing to asynchronous systems like many vintage computer circuits.

So I should be thanking you for a mentally stimulating and fun discussion.

I do think it's important to be able to interface USB/PS2 keyboards to old machines, as they are ubiquitous and in most cases, much more pleasant to use than the original keyboards.

Dave

There's room for both, certainly!

And I certainly have had my share of times where my writing has come across as snarky; again, no worries here.

 

[shank]

there's another thread on this forum from a year or so ago that i talk about my ps/2 version, if you want to look for it. the protocol looks very simple--and it is. keep in mind that today we do things quite differently than in the 80s. if you come at this thinking the timing diagram looks so similar to SPI, as an example (by this i mean the modern way we deal with serial data now--of course this isn't spi), then you'll go down the wrong track. it's a fun project and i wish you good luck with it! you can do an emulation easily with a microporcessor (my first version used an arduino uno) up to a raspberry pi which is what the current version is using.

my intent was/is to replace the keyboard with a modern one, and this works quite well. a retro style keyboard sounds fun, but isn't what i was after.