What's going on in the workshop?

Category Archives: HP 16500A/B

One of my HP 16500B logic analysis systems has a 16534A digital oscilloscope module installed. The module has a great specification: two channels, 2Gsamples/sec, 500MHz analogue bandwidth, and 32k record length. I would find it a really useful debugging tool, if it worked properly. Sadly it doesn’t.

Though it displays a trace successfully, and the controls work, it won’t trigger. The only way I get a trace is by auto-trigger. In this case the trace isn’t synchronised, so it’s impossible to catch a particular event at a particular time. Here it is displaying a square wave (well, it’s nearly square – I hadn’t adjusted the probe compensation so it’s a bit curvy on the top and bottom). Adjusting the trigger level just doesn’t make any difference.

The service manual for the 16534A isn’t very helpful. It describes roughly what the self-tests do, and how to run the self-calibration procedure, but has no detailed circuit information. The self-test reports a ‘D/A’ failure:

and the self-calibration procedure fails on the Trigger and Hysteresis sections:

The service guide describes the D/A test like this:

Test DAC This test verifies the correct operation of the D/A convertor on the board.
Both the offset and trigger level D/A convertors for each channel are set to a reference
level and then changed. The logic trigger IC is programmed to detect the changes. The
detection of a correct trigger indicates that the D/A convertor is operating normally.

It seems clear that the offset D/A converter is working, since the offset control works and moves the trace up and down as it should. However, the trigger level control doesn’t seem to be doing what it should. I had a look at the board, looking for components likely to be the DAC or trigger IC. Unfortunately, the semiconductors on there seem to be mostly either standard ECL logic, trivial things like op-amps, or magic custom HP chips with dozens of pins. One exception was this:

It’s an AD96687 from Analog Devices, which is a dual high-speed comparator with ECL outputs. If I was designing a high-speed trigger circuit using 1994-vintage components, I might use a device like this. I’ve had a look at all its pins with the power switched on and a signal applied and tests running, and none of them seem to change at all. One noninverting input is stuck at +5V, and the other inputs are near ground. One set of outputs isn’t even showing valid ECL logic levels, but it may be unused and thus have no load resistors on it.

Maybe it’s a red herring and nothing to do with the triggering at all, but I’m suspicious that I never see anything change. Without more circuit information, it’s hard to get much further, sadly.

In part 6, I established that something was stopping the floppy disc drives in my 16500A working when I changed the ROMs to software version 00.02. Thanks to the help of some on the hp-agilent-equipment Yahoo group, especially Glen Slick, I have determined that there’s an important difference between early CPU boards running 00.00 and later ones running 00.02: the floppy disc controller chip has changed!

The old board has an FDC9793 and the new one a uPD765 (or at least its Zilog equivalent). There are pictures of all the boards here. Now, I started to wonder, could I somehow fit the uPD765 to my board? It seems crazy and would only make sense if it wasn’t possible to exchange the whole board. So I started investigate. As luck would have it I have a functional 16500B with a logic analyzer plugin, so I could have a look and see what was going on around the disc controller on my CPU board. I wired up the relevant pins of the FDC9793.

Examining the logic analyzer trace, it seems that the CPU is trying to read something from the disc controller, which is at least a start.

It’s reading from what would be the status register repeatedly, as if waiting for some condition to be true. It gets a value of 0x04 every time, which is presumably not what it wants. It does this at the right stage of the self-test. I thought this was promising, since it is at least addressing the chip. Might it be possible to wire one in place of the other? Their pinouts are different. Comparing them, using their datasheets:

FDC9793

uPD765

1

RESET

I

active high

2

nWE

I

nRD

I

3

nCS

I

nWR

I

4

nRE

I

nCS

I

5

A0

I

D/nS

I

data/nStatus register select

6

A1

I

D0

I/O

7

D0

I/O

D1

I/O

8

D1

I/O

D2

I/O

9

D2

I/O

D3

I/O

10

D3

I/O

D4

I/O

11

D4

I/O

D5

I/O

12

D5

I/O

D6

I/O

13

D6

I/O

D7

I/O

14

D7

I/O

DRQ

O

DMA request

15

STEP

O

Step output

nDACK

I

DMA ack

16

DIRC

O

Direction (high=in, low=out)

TC

I

end of DMA transfer

17

EARLY

O

write precompensation

IDX

I

index pulse

18

LATE

O

write precompensation

INT

O

interrupt output

19

nMR

I

master reset

CLK

I

8MHz

20

GND

GND

21

+5V

WCK

I

write clock

22

nTEST

I

tie to +5V

RDW

I

read data window

23

HLT

I

input, head engaged

RDD

I

read data from data sep

24

CLK

I

1MHz in

VCO/SYNC

O

enable VCO

25

RG

O

read gate to data sep

WE

O

write enable

26

RCLK

I

read clock from data sep

MFM

O

MFM/FM

27

nRAW READ

I

raw data from drive

HD

O

head select

28

HLD

O

head load

US1

O

unit select

29

TG43

O

track greater than 43

US0

O

unit select

30

WG

O

write gate

WDA

O

write data

31

WD

O

write data

PS1

O

precompensation shift (early/late/normal)

32

READY

I

ready

PS0

O

precompensation shift (early/late/normal)

33

nWF

I/O

write fault/vfo en to data sep

FLT/TR0

I

track 0/fault

34

nTR00

I

track 0

WP/TS

I

write protect/two side

35

nIP

I

index pulse

RDY

I

drive ready

36

nWPRT

I

write protect

HDL

O

head load

37

nDDEN

I

double density

FR/STP

O

fault reset/step

38

DRQ

data req, open-collector

LCT/DIR

O

low current/direction

39

INTRQ

interrupt req, open-collector

nRW/SEEK

O

indicates seek/read/write mode

40

+5V

There are some important differences here. Firstly, the uPD765 expects an 8MHz clock where the FDC9793 used a 1MHz clock. That’s not a good start. The uPD765 includes drive and side select logic, but the FDC9793 doesn’t. The two also differ a lot in how they handle things like write precompensation signals, and the uPD765 effectively multiplexes various signals too.

At this point I think the swap is just too difficult. It becomes cheaper and easier to swap the whole CPU board, if I can find one, or simply upgrade the whole machine to be a 16500B.

As part of my quest to upgrade my HP 16500A logic analyser’s memory, I’ve found out more than I ever expected about the various versions of the 16500A CPU board. I’ve been fortunate to have the help of the good people of the [hp_agilent_equipment] Yahoo! group. My most recent stumbling block has been that installing ROM version 00.02 in my (early) 16500A stops the floppy disc drives working.

Glen Slick, from the above group, was kind enough to send me high-resolution scans of the two 16500A CPU boards he has. That makes three known versions, and here I’ll post pictures of them and attempt a description of the differences.

16500-66503 with 1MB RAM

This is the board from my machine. It has 1MB RAM in 8 TMS44C256-12N DIL chips, and the floppy disc controller is a Standard Microsystems FDC9793. The ROMs contain software version 00.00. For completists, I have put images of the V00.00 16500A ROMs here.

16500-66507 with 2.5MB RAM

This is one of Glen’s boards. It has 2.5MB RAM fitted as 20 off TC514256AZ-10 1Mbit ZIP chips, and the floppy disc controller is a Zilog Z0765A (which seems to be compatible with the very common uPD765 as found in the original IBM PC). The ROMs contain software version 00.02. It also has three extra programmable devices with labels on them. The details of their encapsulation mouldings look very similar to PALs elsewhere on the board, but why don’t all the PALs have labels on them? The labelled ones are:

16500-80006, U86, by the floppy drive connector at the bottom

16500-80007, U104, top right

16500-80008, no designator visible, next to the floppy controller IC

16500-66510 with 4MB RAM

This is another of Glen’s boards. The part number (66510) seems to be on a sticker. The only noticeable difference, other than the RAM chip complement, from the 66507 board is that the chip top right is labelled 16500-80013. It has 4MB of RAM as 8 off TC514400AZ-80 4Mbit ZIP chips. The ROMs contain software version 00.02.

In part 5, upgrading the software on my 16500A’s CPU board to version 00.02 resulted in a self-test failure, which wasn’t fixed by downgrading back to 00.00. I’ve just had a look to see why that was happening.

The front panel is connected to the backplane by a 10-way connector. I traced out the pinout of the connector:

+5V power

+12V power

+5V power

+12V power

Ground

Data

Ground

Data

Ground

On/off switch, ground to switch system off

There was no activity at all on pins 6 and 8, the data pins, even during self-test. I traced them through to the CPU board via pins 59 and 60 of the CPU board’s backplane connector, and thence to U90 pins 18 and 19. This is an HP custom chip. There seemed to be activity on many of its pins, but nothing on those two. Poking around, I found that two of its pins are connected to a nearby ceramic resonator which clearly wasn’t resonating. Aha! Got it. One of the pins of the resonator had broken. I soldered it back together and now the self-tests pass!

But there’s a fly in the ointment. V00.02 software doesn’t seem to be able to access the floppy disc drives, simply reporting ‘No Disc’ for both of them even when they’ve got discs in.

Looking at the floppy disc connector with a scope, the ‘drive select’ pins are definitely active. It seems that the pinout of Sony 3.5″ floppy disc drives changed at some point. The details are here:

It seems that the ‘disc change indicator’ has moved at some point in the history of Sony disc drives. Maybe the new software is expecting to see the ‘disc change’ indicator before it tries to switch the drive motors on? Grounding pin 34 doesn’t seem to make any difference. The disc controller is an FDC9793. Looking up the data sheet on it, it doesn’t have any means of indicating whether a disc is in or not. Without a schematic, it’s going to be very hard to figure out how the software determines it.

Following on from part 4, I’ve now tried a newer software version in the 16500A’s EPROMs. Finding a couple of good 27C256s with 200ns access time took a few minutes, but there were no problems with the programming. So, I put them in the CPU board, reinstalled it in the mainframe, and switched on:Oh dear. That’s not good. Without HIL (which is the socket for mouse and keyboard on the front), front panel (which I assume is the spinner knob) or touchscreen, the machine isn’t a lot of use. Must be a compatibility problem with the new software version, I think to myself. Swap in the old ROMs – and the problem is still there. Check the wiring to the front panel, all looks good.

This is annoying. I wasn’t expecting new faults with the hardware. When I next get time to spend on it, I’ll do the obvious checks for bent pins and so on.

Having worked out the wiring for a 4MB SIMM to the 16500A CPU board in part 3, I got out the mod wire and soldered it all together.

It all went together quite easily. The pins, even on the SIMM, are so much further apart than modern surface-mount components that I’m used to dealing with. Notice the red wire running along the row of chips on the SIMM: that’s nOE, where I had to lift pin 16 of each chip and wire them together because the original SIMM tracks grounded them. I also cut the track joining all the pin 3’s (nWE) of the chips together, half way along the SIMM, so that the upper four chips had a separate nWE from the lower four, again because that’s the way the CPU board expected them.

Having checked and double-checked the wiring, I plugged the board into the mainframe and switched on. Much to my amazement, I heard the sound of the floppy drives seeking almost immediately. It was running! Once the monitor had warmed up, I could see that the mainframe was booting absolutely normally. It passed all its self-tests. But, did it recognise the extra memory? With some trepidation I stabbed the screen to select test mode and looked at the bottom line of the display:

Oh dear. Just 1MB then. Serves me right for trying to make a silk purse out of a sow’s ear. I suspect ROM version 00.00 (what kind of a version number is that?) doesn’t support more than this, since later 16500As had a different ROM version and more memory. Just for kicks, I popped in the test disk and tried the proper memory test:

At least the new RAM works as well as the old stuff did, even if it isn’t any bigger. I haven’t broken it, but I haven’t improved it either. I also tried loading the 16550A module software, just in case it was somehow able to find the extra RAM even if the rest of the system didn’t know about it, but it still reported that there wasn’t enough space.

I think my next quest will be to find a copy of the later ROM and program a couple of EPROMs with it. A quick Google search for ‘16500A ROM’ reveals this site:

I’ve worked out the wiring of the SIMM to the CPU board. Unfortunately, the OE signal on the SIMM is hard-wired to ground, which is annoying. I’ll have to lift the legs (pin 16) of each of the RAM chips and hand-wire them together.