IMPORTANT DISCLAIMER !!!
It is assumed throughout this article that if you have a 9100 digital test system and are thinking about building this adapter that you are capable of doing so and prepared to take responsibility for anything going wrong. While I am using one of these units quite happily with my 9100 I cannot be held responsible for any damage caused by following the guidelines in this article. If built incorrectly it has the potential to cause damage to the 9100 and presumably (but not limited to) any devices attached to it. In particular, I cannot guarantee there are no bugs in the code, or indeed mistakes in writing up this article. If you spot anything obvious (or not so) please get in touch! Of course, this page will be updated to include bug fixes and enhancements whenever I make them.
CONCEPT
Some time ago I was able to upgrade my Fluke 9010A for a nice 9100FT. The 9100 is a completely different beast to the 9010 with considerably greater flexibility and functionality. A lot of the power of the extra functionality is however released through what was at the time (around 1989 or so?) an optional extra. The programmers station.
The programmers station basically consisted of a video card to fit inside the mainframe, either a monochrome or colour monitor and a proprietary programmers keyboard. The video card supports both the colour and mono monitors, the difference being set by a jumper block on the video card. This meant that Fluke were able to market two very different scenarios where, typically in a production environment, you would have the technicians and designers designing troubleshooting routines and these would be installed onto the basic 9100 machines for the operators to use for fault diagnosis.
I guess the purchaser thought they were onto a winner since they didn't have to buy a full-on programmers station for every operator and I guess Fluke were onto a winner since they could charge a premium for the couple of extra parts and a few massive manuals!
Years down the line though, the addition of these proprietary items can cause a major headache now that us enthusiasts can finally afford to get our hands on this kind of technology. You see, the video cards and the keyboard are nigh on impossible to get hold of now. For the video card, you may as well just make sure the 9100 unit you track down has one in it since the only way you will be likely to get hold of one otherwise is to talk extremely nicely to another collector who has a spare - and even they're pretty few and far between!
The keyboard has been a similar problem until now. You see, the unit will not even enter "Edit Mode" unless it detects the proper keyboard attached. Although the 9100 appears to have just a standard AT keyboard connector on the side, the two units are not even close. If you plug a standard PS2 keyboard into the 9100 via a PS2 -> AT adapter, all it will do is beep at you a lot. You can trick it into entering the editor since it's not overly clever but once you're in there all you can do is admire the primitive character display as the keyboards talk completely differently to the 9100 to how a PC keyboard wants to speak!
Well, that was until a few weeks ago. This has been banded about for many years on various forums so after I got my unit I tried to find out where people were with various attempts but although I even got as far as someone saying they had a prototype adapter, no one came forward with a working solution and I could see no end in sight, so determined as I always am, I set about rectifying the situation. All the "that should be pretty easy" theory in the world is never going to get you anywhere until someone actually sits down and does it!!
So here we are.
This is inspired by and based in no small part on the wonderful information and code found over at www.electronic-engineering.ch so if you're at all interested in all the gory details and theory, head on over to there and check out what there is to say there. There's no doubt that without that site, I would not have a working 9100.
CIRCUIT
*** IMPORTANT *** This version of the circuit (v1.1), incorporates important changes from the previous version please make sure you read the v1.1 update if updating to this version.
Please excuse my circuit diagram, it's the first time I've ever done anything like this. It also happens to be the first time I've ever done any assembler programming too but the less said about that, the better I should think! If you want to scrutinise the circuit carefully in order to build one of these then there is a bigger image linked in the download links below.
IC1 = PIC16F627A
C1, C2 = 33pF
R1, R2 = 10K
Q1 = 4Mhz
J1: 9100 Connector (AT / 5 pin DIN)
J1-1 Gnd (9100)
J1-2 N/C
J1-3 KBD Data (Pic to 9100)
J1-4 9100 Reset (9100 to Pic)
J1-5 +5v (9100)
J2: Keyboard (PS/2)
J2-1 Gnd (9100 / Keyboard)
J2-2 N/C
J2-3 KBD Clock (Keyboard to Pic)
J2-4 KBD Data (Keyboard to Pic)
J2-5 +5v (9100 / Keyboard)
V1.1 Update: This version has several important differences from v1.0, the most obvious of which is the fact that I have switched host devices. The reason for the switch to the 16F627A is that through the use of adapter AC162053, the target device can be debugged. In reality, this project makes no use of the other differences between the two chips and there are only a couple of lines of code that need to be changed to facilitate the different chips. The compiled downloads below were built against the 16F627A, however if you still wish to use the 16F84A, you can simply download the source code, change selected device in MPLAB IDE, then alter the define statement on line 204 and you can build yourself a version for the older MCU.
In order to facilitate in-circuit programming and debugging using the 627A a couple of changes had to be made to the circuit. I had to free up RB6 since it and RB7 are used by the in circuit debugger / programmer (ICD2) so the LEDs now live on RB4 and RB5. The most important change however comes with the connection of the 9100's reset line. As the /MCLR signal also carries the 13v VPP voltage needed for programming we obviously couldn't have that connected to the 9100. Something tells me it would have gone pop! So the /MCLR is now just tied high with a 10k resistor and our reset line from the 9100 now goes in to RB2. Apologies to anyone that built the previous version and now wants to update to this version. Obviously hindsight is a wonderful thing. With a bit of luck, any other changes from now on will only be code based.
Incidentally, from a code point of view we also have a lot less space available to us if we're going to allow debugging. The ICD needs to download a small(ish) debug executive to the device and sadly this needs to take up the entire address range from 0x300 to 0x3FF. At the moment that's fine but it won't be long before we're out of space and then I'm going to have to start doing some jiggling about for debugging. If you're up to in-circuit debugging though then I'll assume you're also up to working out what to do about that one (hint - comments!).
So, the circuit...
Just to provide a small amount of explanation in case it's at all unclear (or wrong in the diagram!), at the heart of this project is a PIC16F84A. The original website showed a PIC16F84 but my local Maplin only had the 'A' version and I wasn't able to find out what the difference was so I gave it a go and it worked. I see no reason why you couldn't use some other PIC processor as long as the include statements in the code are altered accordingly. As far as I can see there are no special features being used here at all.
On the side of the 9100 to adapter, +5v and GND are supplied by the 9100 to pins 1 & 4 of J1 and the PIC's master reset line is connected directly to the /RESET pin of the 9100 output (J1, pin 5). This signal is sent when you press the edit key on the operators keypad and it is in response to this signal that the 9100 determines if the keyboard is present or not. The output from the PIC goes into the 9100 on the keyboard data line on J1 pin 3.
On the other side (PC keyboard to adapter) you again have the +5v and GND, so the 9100 is directly powering the PC keyboard. These are connected on pins 1 & 5 of J2. The KBDDATA and KBDCLOCK lines are coming from the PC keyboard on pins 3 & 4 of J2 and go to RB0 and RA4/T0CKI. There is a 10k pullup resistor on each of these lines.
To complete the operational side of the circuit, there is a 4Mhz xtal connected across pins 15 and 16 of the PIC with each side having a 33pF ceramic disc capacitor between the pin and ground to give the correct timing on the crystal. The value of these two caps is fairly critical.
On a non functional side of things, I added an LED on each of pins 11 and 12 of the PIC (RB5 and RB6) to provide visual feedback for CAPS lock and SCROLL lock since the entire interface is one way which means that there is no way to drive the PC keyboards internal indicators without considerable extra fuss. I can quite happily live with LEDs in my circuit instead.
CODE
The theory behind all of this is pretty simple. I won't go into the technical details of how the PC keyboard talks to the adapter as that's documented well on the site I linked to above and it's also documented all over the net as well. Instead we'll take a look at the 9100 side of things.
Although Fluke did a good job of making things nice and proprietary, things are actually fairly straightforward. Incidentally, at a guess I would say that an earlier AT keyboard is probably even closer still to the 9100 programmers keyboard but I didn't have one to hand and wanted to do this with easily available parts anyway. The 9100 expects to receive mostly ASCII key presses. There are some custom keys, and some custom key codes but the standard keys at least are just standard ASCII, with a single code being sent for each press. The codes also have two stop bits and no parity. It expects to receive this data at 1200 baud. Also, when you hit the enter key on the operators keypad the 9100 sends a low pulse on the reset line and if it receives a response, it will "trip" into edit mode. It seems it is not too fussy about what it receives back. Anything will do - literally!
The PC keyboard on the other hand, sends it's data at 9600 baud. It sends a parity bit and 1 stop bit. It doesn't implement any kind of reset signal and further more it sends one code from a key press and another for a key release. At least. For some keys, it's sends two or even more codes for the key press.
Well, that seems like chalk and cheese doesn't it? Well, no, not really...
We basically have three main areas that we need to code for:
1. We need to slow things down to 1200 baud.
2. We need to handle the reset signal.
3. We need to create a custom key map and handle any other custom key codes.
Reducing the speed was no more complicated than studying the relation between the delays in the provided code for 9600, 4800 and 2400 baud (the original author stopped short of 1200 for some reason!) and rough guessing what the delays would be for 1200. Once I had it roughly right I was then able to just use the stopwatch feature in MPLAB to time the cycles and get it more or less accurate. Thankfully, the 9100 is not all that fussy about the speed. It would seem that as long as it's more or less 1200 baud then it's happy. That's kind of handy since it saved me digging out a scope or logic analyser and getting things spot on.
Secondly, the reset signal. Again, this was trivial. Just before entering the main loop of the code we throw an 'X' out to the 9100. We enable the "power on reset" delay to ensure it's not too quick about responding and just wire the reset signal up directly to the /MCLR pin of the PIC. I'm sure we could use pull up resistors and pull down resistors or all-sorts but frankly, the 9100 signal is running at TTL levels so it's already just fine and it works a treat.
Finally, the hard part. Well, swapping keys about where what was printed on the keyboard didn't match what I wanted to come out was not too hard but the rest of it was a case of diving in at the deep end. A lot of this stuff was not in the original code at all. The original code was designed to transmit ASCII data over RS232 to a dumb terminal so things like cursor keys were just not in there. Also, rather obviously, the special function keys of the 9100 keyboard weren't in there and in order to squeeze them all into the PC keyboard I had to implement the two byte codes. Not desperately easy for your first PIC / Assembler project but we got there.
Okay, so what's left?
The code below works perfectly on a GB Windows keyboard as pictured below. All the special function keys are implemented and you can do everything you need to do in the 9100 editor. One thing I have not done yet is to implement the CTRL key. As far as I can tell this is mostly just used in terminal emulation mode and maybe for a few more advanced keyboard shortcuts. I guess I'll get to implementing that later but if someone else wants to jump in, don't let me stop you!
I received a US keyboard through the post yesterday thanks to Jamma+ member Chris (HOT_DOG). Many thanks for that, and it means that I can now work on providing a key map that is correct for anyone over on the west side of the pond (other wise known as the USA). Sorry but if you need support for some other keyboard then you're either going to have to code it yourself or if you talk to me really nicely and send me a keyboard (I'm in the UK) then I may be persuaded to do it for you but I am going to have a lot of learning to do on the 9100 unit itself now that I've got it up and running. Hopefully the US one should be done in a week or so. Actually, the US keyboard is closer to the 9100 keyboard so I may use that keyboard now anyway.
Oh, there is just one small fly in the ointment here. That is that my Fusion virtual machine, caused a kernel panic on my Macbook Pro a couple of days ago and it seems that it managed to corrupt the MPLAB project that was open at the time. It hasn't set me back too far since I had mailed some code over to someone a few nights earlier but it does mean that I can't post the source up just yet. For the moment, I have a ".bin" file that is a dump of my working PIC. Just as soon as I've recovered the missing bits from the source, in compliance with the original author's notices the source will be available here as well for you to do as you wish.
DOWNLOADS
GB Layout HEX file to burn here
USA Layout HEX file to burn here
Source for v1.1 here
When burning the file to the PIC I would highly recommend you ensure that none of the CP bits are set. The chances are you may want to alter the key map to your own tastes slightly. In addition to that, the following need to be configured in your burner software (I was using the cheapo TOP2005 programmer):
FOSC0 1
FOSC1 0
WDTEN 0
PWRTE 0
Download the source code here (to follow ASAP)
Download a larger image of the circuit here
9100 SETUP
WORKING INTERFACE
THANKS AND LINKS
- Many thanks to the TTL list, without the information on that list this would have been much harder. (link to follow)
- Chris Hardy (Juno)
- Andy Welburn of Andys Arcade. There is a nice resource there on upgrading the 9100, check it out!
- Bob for selling me the 9100 in the first place
- And of course, Peter Luethi, the author of the original code