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