Need help with Tandberg TDV 5000

User avatar
gcardinal

28 Feb 2016, 18:03

IMG_20160226_154409.jpg
IMG_20160226_154409.jpg (131.49 KiB) Viewed 9731 times
I got my hands on TDV 5000 keyboard (marked TDV 1200 on the PCB-board). It has what looks like regular PS/2 connector on the back. I tried to connect it to PS/2 port on my PC using brand new DELTACO Switchcabel PS/2 DEL-45A - but got no lights or any response on key presses.

Didnt do any other testes when connected - but I did take it apart just to do a visual inspection. Tried to take pictures of any points of interest I could spot:
https://www.dropbox.com/sh/teajwebsbuq5 ... M--ua?dl=0

I have no experience with older keyboard like this, but I do have some very basic understanding of electronics. I also have multimeter, soldering tools and 100mhz oscilloscope.

I would love to get this keyboard up and running - as all switches seems to be in great condition also all double shot keycaps are nearly mint condition.

Would greatly appreciate any help, advice or just ideas of what to try and what to do next :)

User avatar
OleVoip

28 Feb 2016, 21:22

Congratulations to this beautiful board. Normally, this should be PC compatible, except for the unusual scan codes of the special NOTIS text processing keys. If it does not talk to your PC, something must be broken.
These are the first things I would try:
With your oscilloscope, you can check the lines of the PS2 connection. The keyboard is supposed to generate the clock signal at a frequency between 10 and 17 kHz (IRRC), whenever it transmits data or receives some from the host. You can trigger this without the PC by pulling both data and clock low and releasing the clock line after at least 1/10 s; thereafter the keyboard should reply with a clock burst.
By watching the outputs of the column decoder 74HC154, you can check whether the controller actually scans the matrix; frequency should be of the order of a few 100 Hz or kHz.
edit: Come to think of it, even better than the outputs is pin 23 (A0), which should toggle with every column being checked.

User avatar
gcardinal

01 Mar 2016, 08:41

OleVoip wrote: ...
Thank you! My experience with oscilloscope is very limited, so Im not sure if I did it correctly :? but here are my results:
Spoiler:
First I connected to a switch on the board it self:
Screen Shot 2016-03-01 at 08.35.40.png
Screen Shot 2016-03-01 at 08.35.40.png (636.48 KiB) Viewed 9636 times
and got this reading:
test1-osc.png
test1-osc.png (46.74 KiB) Viewed 9636 times
After that I connected to two points and tried to press a key:
test2.png
test2.png (47.54 KiB) Viewed 9636 times
Then I connected to PS/2 lines while it was connected to PC:
Screen Shot 2016-03-01 at 08.37.24.png
Screen Shot 2016-03-01 at 08.37.24.png (783.17 KiB) Viewed 9636 times
Here I cound't see or trigger and decode anything:
test3-osc.png
test3-osc.png (37.17 KiB) Viewed 9636 times
Not sure if my setup was incorrect or trigger was to high/low - it was getting pretty late so I called it a day :| .

I kinda hope my setup was wrong and that there is data - at the same time - I never was able to see any reaction to keypresses on PS/2 lines no matter what I did.

Any help or advice will be highly appreciated!

PS: I have Rigol DS1074Z-S
Last edited by gcardinal on 16 Mar 2016, 21:41, edited 1 time in total.

User avatar
OleVoip

03 Mar 2016, 00:00

Good to see that the controller is alive and scanning. So it's still possible that it is also fine otherwise and it is the socket, the cable or the PC side which is at fault. Resistors pull the clock and data lines up to 5V so you can signal the lines simply by shorting them to ground - first the clock line, then the data line, then release clock and you should see a series of pulses on the clock line. If this doesn't work check the continuity of the traces between the ps/2 socket and the controller pins. If you really can't trigger that reply, the controller must be broken and you need to replace it.
The fact that key presses don't trigger a clock burst is not indicative, because the controller might expect an initialization command from the PC before it starts sending anything.

User avatar
gcardinal

05 Mar 2016, 22:45

OleVoip wrote: ...
Thank you so much for the advice! It was just the ideas I needed

After some googling I got to this article:
http://codeandlife.com/2013/07/15/ardui ... rd-tester/

It is about using Arduino as PS/2 keyboard tester. So I connected it as per PS/2 port specification - but got ones again nothing. After some testing with multimeter I got an idea that maybe it is not PS/2 port after all - maybe it just looks like one. So I scanned all pins on connector, to the board and traced them back to CPU. Then I created this diagram:
tandberg.png
tandberg.png (40.05 KiB) Viewed 9526 times
Compared to regular PS/2 port - all pins are swapped around.

So now with better understanding of the port on the keyboard, I connected it up to Arduino ones again and got this very promising session:
arduino.png
arduino.png (28.79 KiB) Viewed 9526 times
To say that Im incredibly happy to get this far is an understatement :D

Next step will be making a new cable, putting it all back together and trying it on a PC
IMG_20160305_223529.jpg
IMG_20160305_223529.jpg (242.34 KiB) Viewed 9521 times

User avatar
OleVoip

06 Mar 2016, 15:23

gcardinal wrote: To say that Im incredibly happy to get this far is an understatement :D
Well done, you! I must admit that I had a slight hope you could give up and I could get the board. :mrgreen:
Thank you very much for sharing your joy!
Now, it might be a good idea to leave an arduino or teensy between the keyboard and the PC, if you want to make use of the 20 ochre-coloured NOTIS keys. IIRC, the scan codes of these keys are marked by a prefix which is not understood by the PC or of-the-shelf PS/2-USB converters, so that the PC confuses them with other keys. Your arduino keyboard tester will tell you the codes.
You'll need a controller that maps the keys to other codes or directly converts to USB - unless you'd like to mess with the keyboard driver of your operating system.

edit: Oh, and may we use your images in the wiki?

User avatar
gcardinal

07 Mar 2016, 21:27

OleVoip wrote: ...
You'll need a controller that maps the keys to other codes or directly converts to USB - unless you'd like to mess with the keyboard driver of your operating system.
Yes indeed and I looked into Soarer's and TMK firmware (post here) and got answer that this keyboard with 80 xx prefix is not supported. Im not a C / C++ programmer but will give a try to modify TMK and see where I can get with it...

But I did install Soarer's on Arudino Leonardo (thats what I had) and did type on it for a while - feels like no other keyboard - definetely an uniq feeling.
OleVoip wrote: edit: Oh, and may we use your images in the wiki?
Of course, I will also make some better pictures during the weekend when lighting is better

User avatar
gcardinal

15 Mar 2016, 19:30

Had a go with TMK firmware, but was unable to get it working since I simply dont know C :(
I ended up making a new PS/2 cable and connecting it directly to PC:
IMG_20160314_234159.jpg
IMG_20160314_234159.jpg (279.12 KiB) Viewed 9378 times
And this is how my desk looks with keyboard:
IMG_20160314_235031.jpg
IMG_20160314_235031.jpg (293.34 KiB) Viewed 9378 times
I can't use extra keys, but will try my luck with Microsoft Keyboard Layout Creator...

I found a book about NOTIS-WP and now kinda understand what all the extra keys supposed to do - for the most part there is a modern shortcuts - at least for use in texteditors / webbrowsers. I will post it here as soon as I get time to translate it from norwegian to english

Edit:
OleVoip wrote: ...
edit: Oh, and may we use your images in the wiki?
I added more pictures to the dropbox

User avatar
hasu

15 Mar 2016, 21:53

your converter with tmk or soarer's firmware does work well for other keys except for 80 prefix keys ?

you will have to change matrix.c, common_keymap.h and your keymap file.

I have not enough time to write code for you but subscribed this thread to see your interesting project, keep us posted!

User avatar
gcardinal

16 Mar 2016, 21:48

hasu wrote: your converter with tmk or soarer's firmware does work well for other keys except for 80 prefix keys ?
...
Yes both soarer's and tmk work great with all other keys except for 80 prefix. but so dose plugging it directly to ps/2 port of my PC - but without converter I get as far as I can see full NKRO.

Also there is a fun feature of this keyboard where it has a piezo speaker and its possible to turn it on / off with ctrl + alt + arrow down - it makes kinda fun sound on each key press. Not annoying at all actually.
hasu wrote: ...
you will have to change matrix.c, common_keymap.h and your keymap file.
...
Okay - I will try and see where I can get with my basic C knowledge - Im sure I will get there one day

Today I discovered that key A had bad connection - so did some maintenance - opened one switch without desoldering and de-soldered another and opened it up. Super simple construction with removable diodes (!). It is possible to open switches without de-soldering and their all fully serviceable.

Made this short video:
Working just fine now - typing this post on the this keyboard now. It is really close to how "vintage" cherry mx black feel but even softer - but with kinda the same force required.

ingvarha

06 Dec 2021, 12:51

Five and a half years later ...

I contacted Hasu, main developer of the TMK converter, and provided keycodes. He added the missing code, so tmk_converter now supports the 0x80 prefixed keys. They are translated to "normal" range keycodes, so that key '^^^' is Super_L, for example.

https://github.com/tmk/tmk_keyboard/com ... 8bb3fe023f

If you have this keyboard, you still have to fix the pin layout by a converter cable. (It may be possible to make a special build of the firmware where this is fixed as well, I guess)

Ingvar

FrodeM

23 Dec 2022, 00:20

A heads-up on a project I have been having lately: Patching the firmware to natively put out recognizable-keys instead of the NOTIS special-keys. It turns out to be very doable, given you have a fresh 8751 to burn, as well as a programmer.

First of all, I have been able to read out the v2.1 firmware using this type of dumper: https://github.com/JohnDMcMaster/8051dumper . The particular chip in question is the mask-ROM plastic DIP edition. Very early keyboards usually have a ceramic DIP, the 8751 EPROM-based one with a quartz window, and those might have the protection-fuses activated. My own TDV 5010 with firmware v1.4 unfortunately has this, and the v2.1 dump I was able to make is from a friend's TDV 5010.

Making this firmware output media-keys is rather simple. There is already settings in there for defining keys with the 0xE0 prefix, so all you really need to do is to patch up to four or five data-tables. After this, the only thing remaining is really just to adjust the checksum byte at the end of the file before burning it to an empty 8751.

------------------

So, for the technical bits.

We are only really changing the scancode data in some tables here, so we don't really need to know too much how the code works. One thing to note, though, is which index in a table corresponds to what key on the keyboard itself. This overview may help:

Code: Select all

Index:	Key:
0x01	HJELP
0x02	/\/\/\
0x16	[Stroked down-arrow]
0x17	-->|
0x18	|<--
0x27	>> <<
0x2B	<> ><
0x2D	JUST
0x3B	FLYTT
0x46	STRYK
0x4B	MERK
0x4D	KOPI
0x69	ORD
0x6C	SETN
0x6E	FELT
0x6F	AVSN
0x79	SLUTT
0x7C	SKRIV
0x7D	[Sideways u-turn arrow]
0x7F	ANGRE
For the four scancode-tables, the index can be directly used as a byte-offset. This is convenient, as the tables are neatly laid out on the following addresses towards the end of the ROM:
  • 0x0D34: Base scancodes for set 1
  • 0x0D84: Base scancodes for set 2
  • 0x0E34: Base scancodes for set 3
  • 0x0E84: Keytype definitions
For the scancode sets, the content will be used as-is for the base scancode. Patching these is simple, but we need to change the fourth table as well in order to change the 0x80 prefix. This requites a bit of understanding on how the keytypes are defined. Each byte here contains primarely two groups of 3 bits, one defining if the key is a modifier, the other defining scancode structure:

Code: Select all

Keytype definitions:

76543210   <- Bit-nr.
  ||||||
  |||+++- 0 = Normal Key                      No prefix
  |||     1 = Extended Key                    0xE0 prefix
  |||     2 = Cursor navigation               (Special cases)
  |||     3 = NumPad slash                    (Special case)
  |||     4 = PrtScr                          (Special case)
  |||     5 = Pause/Break                     (Special case)
  |||     6 = Key disabled for ordinary use   No handling
  |||     7 = NOTIS special                   0x80 prefix
  |||
  +++---- 0 = Normal Key
          1 = L Shift
          2 = R Shift
          3 = L/R Alt
          4 = L/R Ctrl
          5 = Num Lock
          6 = Caps Lock
          7 = Insert
If you look up the bytes for the NOTIS keys, you will see that all of them use the bit-pattern of xx000111. This will make the firmware add the 0x80 prefix, and we want to change this to 0xE0. The 0xE0 prefix is used for the navigation-keys, which is handy since all we have to do is just changing the xx000111 to xx000001. It's also possible to do as you want here, for example if you want to make some keys into non-media keys, just plain scancodes without additional prefixes, you can use xx000000 too, or if you hit some of the extra keys on accident a lot you can permanently silence any of them with xx000110.

The checksum is located at 0x0FFF. Tandberg used a special type of checksum, where the ordinary 32-bit sum (calculated from summing all bytes in the whole binary) is expected to fold down to 0xAA. The folding process consist of adding all bytes of the checksum together, and if the result is still not within 256, the folding is then repeated on the previous result untill you get something that does add to less than 256. In effect, this will be the ordinary 8-bit sum of the binary, but with the number of 8-bit overflows added to the count as well. If you want to test this for yourself, you can try to calculate it on the unpatched binary. After patching, you need to adjust the checksum-byte so it all adds up correctly.

..In essence, if you just add the 4 bytes making up the full 32-bit sum, a valid checksums is either 0x0AA, 0x1A9, 0x2A8 or 0x3A7.

------------------

I did not mention the last table yet. This is only relevant for scancode set 3, which is seldom used. In any way, the table for this is located at 0x0B71. The format is as follows, and pay attention to the bit-endianess:

Code: Select all


76543210   <- Bit-nr. in each byte
||||||||
||||||++- Entry for Index nr. [byte-offset x 4 + 3]
||||++--- Entry for Index nr. [byte-offset x 4 + 2]
||++----- Entry for Index nr. [byte-offset x 4 + 1]
++------- Entry for Index nr. [byte-offset x 4]

10   <------- Bit-nr. in each entry
||
|+- Typematic enabled by default if 1
+-- Release (break) scancode enabled by default if 1
------------------

That was it, I hope this can come in handy for other people than me.
Last edited by FrodeM on 15 Jan 2023, 06:26, edited 1 time in total.

FrodeM

15 Jan 2023, 06:12

Quick update:

I was able to dump v1.4 as well after some trickery, and the format of the tables are exactly the same. One thing to note, the addresses are different:

0x0ACE: Default key mode for scancode set 3
0x0C7C: Base scancodes for set 1
0x0CFC: Base scancodes for set 2
0x0D7C: Base scancodes for set 3
0x0DFC: Keytype definitions

There's also a bug in the v1.4 scancode set 3 table, which causes problems with the [ ' * ] key. Other than fixing this, v2.1 fixes a few other bugs and oversights as well, so there's little point using v1.4 as a basis for your own patch.

------------------------

Otherwise, I made a patch for my own keyboard, based on v2.1. You can find this here: https://inhale.ed.ntnu.no/tdv_5000_patch.zip
DSC_2798.JPG
DSC_2798.JPG (464.95 KiB) Viewed 2436 times

Post Reply

Return to “Keyboards”