deskthority

Hi,

I've got a quite ambitious sparetime project; I'm planning to build a replacement controller board for my various "Clickies", aiming for a "one size fits them all" solution. Something in the Dulcimer direction, but I'm aiming for something that auto-adapts to either USB or PS/2. Should keep me busy till next year, I guess

I've got samples of all possible controller boards here; one of my Ms, assembled 05-02-1987 in the UK, has this controller board:

Nothing special - except for the little white 4-pin connector on the right, where the LED board is plugged in.

Here's it in all its glory:


Does anybody know the precise name of this thing?

Thank you,

Hermann

I can't answer your question, but I like your idea. Model Ms have a nice consistent physical connection to their controllers. Something I want to use for making them Bluetooth! Well, someday. That's more work still.

Are you thinking of using a Teensy and one of the existing firmwares?

No, I'm thinking of "rolling my own". For the fun of it, for educational purposes, and of course because my wheel is the roundest of them all

I want to replace the nearly 30 year old current sucker controller boards (and, if possible, before they die), so something like Soarer's Converter (which I've put to use in a 122-key Terminal Keyboard:

In the meantime, some more caps are standard PS/2; still missing the "Strg" [German "Ctrl"] ones, which don't seem to be easy to get) isn't what I want.

Dulcimer might be an interesting starting point; I'd like to add

• autodetected PS/2 or USB connection (with just a little passive adapter)
• Soarer's Converter's macro capabilities
• whatever else my programmer's mind can dream up...

Teensy isn't the way to go; as far as I can see, it's either USB or USB, unless you add a second connector.

Any reason why you want to use PS/2 at all? I don't think I've met anything that's PS/2 only lately, and I work with some really weird industrial embedded stuff I did play with an ancient early-90s laptop though today... although that didn't have PS/2, only a serial mouse!

The Teensy can do PS/2 (same as any other microcontroller); PS/2 is old-school and slow enough that it can be bit-banged quite easily with a couple of GPIO pins. In fact this is probably the way it's done 99% of the time, unless you're using one of those dedicated USB/PS/2 keyboard ICs that are in a lot of modern keyboards (interfaced to a separate microcontroller for the brains). USB, on the other hand, is rather fast and complicated, so can't be bitbanged (well, it has—c.v. VUSB—but it's a bit kludgy and borderline); that's why you have dedicated USB hardware built into the micros used on Teensys etc.

If you're going to play around with making your own PCB however, why not just chuck a bare AVR on there? It'll be a lot tidier, and you can add whatever connectors you like.

The TMK firmware mightn't be a bad start, if you don't want to write things from scratch (also fun!). It has layers/macros etc. ready to go. It looks like they have a simple PS/2 module as well; it's designed to read PS/2 (from things like trackpoints integrated into keyboards), but could probably be used as a basis for a PS/2 device instead.

That will be interesting to follow!

Have you found a source for the two membrane connectors on the controller yet? I didn't find them here in Germany so far.

What's the distance between pins on the LED connector? Isn't it just 2,54 mm, so you can use a normal angled pin header (Pfostenstecker)? That's what IBM used on other revisions.

xwhatsit wrote: ↑Any reason why you want to use PS/2 at all? I don't think I've met anything that's PS/2 only lately, and I work with some really weird industrial embedded stuff I did play with an ancient early-90s laptop though today... although that didn't have PS/2, only a serial mouse!

Because I don't only use old keyboards, but old computers, too... and I got three 4-port KVM switches here that are PS2/VGA. Replacing all that with DVI/USB would be quite costly.

xwhatsit wrote: ↑If you're going to play around with making your own PCB however, why not just chuck a bare AVR on there? It'll be a lot tidier, and you can add whatever connectors you like.

That's precisely what I'm going for.

xwhatsit wrote: ↑The TMK firmware mightn't be a bad start, if you don't want to write things from scratch (also fun!).

I'm aware of that and might pinch some ideas from it, but on the whole it's planned as an "I write as much as I can on my own" kind of experience - fun and education. Except from some little excursions into AVR-Land where I was only responsible for parts of the firmware (this and this), I haven't done anything with microcontrollers yet, and I'd like to change that.

Halvar wrote: ↑That will be interesting to follow!

Have you found a source for the two membrane connectors on the controller yet? I didn't find them here in Germany so far.

RS-Components got most of them, except for the 20-pin connector on the M-122.
Mouser got them all.
Search for Trio-Mate - that's the name of this connector type.

Halvar wrote: ↑What's the distance between pins on the LED connector? Isn't it just 2,54 mm, so you can use a normal angled pin header (Pfostenstecker)? That's what IBM used on other revisions.

Yes, it's 2.54mm, so I could do that, it should work; but I would like to stay as close to the original as possible. It's a nice one that's protected against accidentially plugging in the connector the wrong way (= mit Verpolungsschutz).

xwhatsit wrote: ↑In fact this is probably the way it's done 99% of the time, unless you're using one of those dedicated USB/PS/2 keyboard ICs that are in a lot of modern keyboards (interfaced to a separate microcontroller for the brains).

Risking a "LMGTFY" here - obviously I can't find the right incantation; do you know a name for one or more of these ICs?

Thank you,

Hermann

I forget the exact one that I've seen mentioned here on DT before (and read about indirectly here—interesting approach), but this and this are the kind of thing I'm talking about. I think they're normally referred to as a Keyboard Encoder. A very common solution to this day; you can get by with a substantially more brainless microcontroller if it doesn't have to handle the USB or PS/2 protocol itself. Not so useful for those of us who like to homebrew, as usually we want a ridiculously overpowered microcontroller so we can do fancy stuff like layers and macros and bootloaders etc.

Hmmm.
Thank you for taking the time to look that up!

xwhatsit wrote: ↑I forget the exact one that I've seen mentioned here on DT before (and read about indirectly here—interesting approach),

Yep, that's a nice one, but works on the "other end of the cable" - it relies on a USB keyboard that can fall back to PS/2.

xwhatsit wrote: ↑but this

Definitely looks nice, but according to the document it seems to enforce a specific matrix layout, which makes it unsuitable for my purposes. Doesn't support scan code set 3, doesn't have any interface to a "bigger brain" behind it.

xwhatsit wrote: ↑and this are the kind of thing I'm talking about.

Nice, but with a 16x8 matrix it's too small to accomodate the M-122. And the company doesn't exist any longer; it was bought by Semtech in 1999(!), and Semtech's current web site doesn't show anything of the kind.

xwhatsit wrote: ↑I think they're normally referred to as a Keyboard Encoder. A very common solution to this day; you can get by with a substantially more brainless microcontroller if it doesn't have to handle the USB or PS/2 protocol itself. Not so useful for those of us who like to homebrew, as usually we want a ridiculously overpowered microcontroller so we can do fancy stuff like layers and macros and bootloaders etc.

True.

The best I came up with yesterday was a Cypress chip - this one - which would take the "ridiculously overpowered" to a new level, since interfacing that to an atmega would mean to define one as SPI master and the other as SPI slave, set up a high-level protocol between them, and program them in two completely disjunct environments. Heavy stuff... I was hoping for a simpler solution.

Here's a document which I'm pretty confident you already know; it details how a Freescale reference design for the MC68HC908JB8 microcontroller tackles the task. Unfortunately, the sample code they talk about seems to have become unavailable since its debut in 2006, but I think it should be possible to implement something like that in software on an AVR with V-USB. Please correct me if I'm wrong before I invest many hours on it

Yeah those were just rough examples of the kind of thing I was talking about. You could probably find something that'd match your specific requirements if you looked hard enough.

I think it's simple enough (and significantly more flexible) to just use a standalone microcontroller, rather than a separate keyboard encoder.

Personally I'd stay away from V-USB; it's a great piece of software to be sure, but has plenty of limitations and doesn't quite achieve USB spec (although it works 99% of the time). It's cheap enough to buy a dedicated USB AVR, such as the ATmega32U2 (what I use in my ibm-capsense-usb controllers), or a ATmega32U4 etc. (more powerful, used in Teensys (Teensies?)). Just because they're USB microcontrollers doesn't mean you have to use them in USB mode; they are just a general purpose AVR micro, so you can implement PS/2 or whatever else you want. I usually have a few ATmega32U2s floating around so used one for a nixie-tube GPS motorcycle speedo; the USB interface was never used, apart from to flash the code on, and that was only for convenience...

ATmega32U4 is probably the best bet, as it's replete with GPIO pins, and the 16x8 matrix is reasonably large. I get away with using ATmega32U2s for my controllers which sometimes get used with Model F 122, because I chuck some shift registers on the PCBs for driving the 16 columns (23 on a beamspring!). Autodetecting USB should be pretty easy with the ATmega32U4 as well, as it has a dedicated D+/D- voltage sense, so you can tell if it's plugged into USB or not (and therefore switch to PS/2).

Using LUFA for the USB library, and whipping up a quick PS/2 module (it's a very simple protocol!) I'm sure you'd be able to achieve what you want to do.

xwhatsit wrote: ↑Autodetecting USB should be pretty easy with the ATmega32U4 as well, as it has a dedicated D+/D- voltage sense, so you can tell if it's plugged into USB or not (and therefore switch to PS/2).

Please excuse my ignorance, I'm new to these things (back in 2002 when I last did anything on an AVR, an FTDI chip was used; there were no USB-capable AVRs) - I can't see how this should be accomplished. Having read the ATmega16/32U4 Datasheet,

• it seems that the D+/D- pins are dedicated to USB and can't be assigned any other function. Correct? If so, how should I switch to PS/2 mode? Connect the D+/D- lines from the USB connector to another set of pins in parallel and only use that if USB is inactive?
• I couldn't find out how the functionality to "tell if it's plugged into USB or not" should work. Could you explain that in a bit more detail (or refer me to another place where I can ask dumb questions like that )?

not dumb at all, i think it´s very interesting, i´m into the do your own firmaware too and i thank you for the freescale pdf you posted earlier. I´m blowing the dust from my C books now (jaja and just reinstall my old turbo C 3.0 good memories ) to practice a little.

In that pdf i found something that may answer :

it seems that the D+/D- pins are dedicated to USB and can't be assigned any other function. Correct? If so, how should I switch to PS/2 mode?

For a low speed USB interface, D+ pin will not be continuously high for more than 4µs because of the bit
stuffing mechanism. The PS/2 interface is determined by 1ms continuously high at D+ pin while the USB
interface is determined by receiving a SETUP token.

Well that´s the software part of the recognition, but if you take a look at the schematic you would see that they impement the conectors same way you propouse, in the freescale they have wired the usb dedicated hardware and two pins for ps/2.

but after i saw this:
http://readious.blogspot.com.es/2012/11 ... agram.html

if this is true, why no to stick up with ps/2 protocol, and only change wire ps/2 or usb when needed?

DiodeHead wrote: ↑In that pdf i found something that may answer :

it seems that the D+/D- pins are dedicated to USB and can't be assigned any other function. Correct? If so, how should I switch to PS/2 mode?

For a low speed USB interface, D+ pin will not be continuously high for more than 4µs because of the bit
stuffing mechanism. The PS/2 interface is determined by 1ms continuously high at D+ pin while the USB
interface is determined by receiving a SETUP token.

Yes, but I can't see (yet) how to do this on an ATmega32U4.

DiodeHead wrote: ↑Well that´s the software part of the recognition, but if you take a look at the schematic you would see that they impement the conectors same way you propouse, in the freescale they have wired the usb dedicated hardware and two pins for ps/2.

When I look at the schematic in the .pdf, I see two connectors - one for a PS/2 mouse (described in the text as "J2 is used for PS/2 mouse connection (for future development)") , one for USB. There's no sign of any connection between the USB D+/D- lines and the PS/2 Clock/Data lines, which are presumably reserved for the PS/2 mouse attached to connector J2.

The MC68HC908JB8 can obviously do this in hardware. Quoting its datasheet: "D– and D+ are the differential data lines used by the USB module. The USB module enable bit, USBEN, in the USB address register (UADDR) controls the pin options for PTE4/D– and PTE3/D+. When the USB module is enabled, PTE4/D– and PTE3/D+ function as USB data pins D– and D+. When the USB module is disabled, PTE4/D–and PTE3/D+ function as 10mA open-drain pins for PS/2 clock and data use."
I.e., this little fellow has the capability to use the 2 pins either for PS/2 or for USB. Judging from the datasheet, this is not possible with the ATmega16/32U4, since it has dedicated D+/D- lines.

Unfortunately, apart from this clever little design trick, the MC68HC908JB8 is a rather limited device (8K flash, 256 Bytes RAM, no EEPROM) and also "not recommended for new designs", otherwise I'd be tempted to go with that. I got plenty of 6809 assembler programming practice, adapting to the 6808 format should be easy.

DiodeHead wrote: ↑but after i saw this:
http://readious.blogspot.com.es/2012/11 ... agram.html

if this is true, why no to stick up with ps/2 protocol, and only change wire ps/2 or usb when needed?

That's possibly working with one of the mentioned keyboard encoder chips that can automatically detect the type of interface they're connected to. Just wiring up a cable doesn't change the hardware/software protocol that's dancing around on these wires

You know (at least with LUFA) relatively easily if your microcontroller has enumerated and is functioning over USB. If it isn't, you default to PS/2.

The electrical interfacing if you want to share a connector and pins is somewhat interesting, but not impossible. You may be able to just hook everything up in parallel; simply tri-state the PS/2 pins when USB is active. If you're going to run the micro at 5V you will need to check if the D+ and D- are 5V tolerant; I took a quick look at the 32U4's datasheet but didn't see anything obvious. The alternative is to use a pair of MOSFETs for each line or a high-speed analogue switch to mux the lines.

You may be complicating things by trying to use the same pair of pins. If you have to swap a new cable on when using PS/2 or USB, why not just make your cable so it uses a different set of pins? If it were me I'd probably splash out on an 8-pole M8 connector and make up a pair of cables, one with USB on the end, one with PS/2, and have them use different cores.

Thanks i knew i was being too naive with my aproach, then those passive converters that look like the picture i posted dont work on older keyboards right?. But since i saw that i wanted to check with you guys.

So i think the four pin aproach is better too, two for usb and two for ps2, so you try to init both of them and the one that return init succes that´s the one you use to send data.

Arakula, I tried to find the part number but apparently it’s not that to find on the internet these days since very few people are using them. You can use a small straight pin connector that you can find with most DIP packages of microcontroller. Cut the required number of pins and then bend them a little bit so that they can fit into board at the right angle as shown in this picture.

one-stop pcb

cilek wrote: ↑Arakula, I tried to find the part number but apparently it’s not that to find on the internet these days since very few people are using them.

Yes ... I've inspected 36 pages of the Mouser online catalog but couldn't find it, before I gave up and asked ...

cilek wrote: ↑You can use a small straight pin connector that you can find with most DIP packages of microcontroller. Cut the required number of pins and then bend them a little bit so that they can fit into board at the right angle as shown in this picture.

Oh, they're available in 90° bent versions, too. No need to do that by hand

Arakula@

I have a DE layout model M, If you have 2 Ctrl keycaps, I can exchange the 2 'Strg' ones with your Ctrl, if you want, let me know.

Mat