Last edit apr 8 2012, links fixed July 27 2015(c) Herb Johnson
Bill Beech discussed his selection of an HP 1650, and his use of it for a repair of an Intel Multibus 86/30 and 86/10 cards, during the winter of 2011-12. Sections below cover the selection of a LA and what he expected from a logic analyzer over an oscilloscope; the diagnostic process; and discussion of the "trace" produced by the LA. A companion Web page shows an annotated LA trace.
As of Jan 2012, Bill described part of his Web site dedicated to his Multibus and logic analyzer work. "I have pages for the 86/30 and the 86/12 out there. The 86/30 manual and just the schematics are available out there. Appreciate you'd take a look at it all. The picture of the Multibus extender card is there, as well. I have split the hardware out from the software and broken it into subsystems." His home page on "Old Computer Systems" provides links to all these. - Herb
See Bill's other work on my site, and links to his pages, at my site's my "home page" for Bill Beech.- Herb Johnson
Bill's Web page on his HP 1650 is one of many links on his Multibus work at Bill's Web site.
I was very careful when I decided to buy an LA. I really did the home work on it, and consulted with an ex HP engineer I worked with about the whole series. He had a great deal of insight into what they did right and wrong. This HP 1650B unit is 68000 based. [It] does timing at 100 MHz and handles state captures at 35 MHz. The 5 or 8 MHz clock on either of these boards is no problem. It will display square wave on a 100 MHz digital oscillator. In my current use, I am not pushing this against any of the limits.
The PC based LA's were interesting but for 80 data lines, they got real pricey. I like stand alone test equipment anyway. I have 80 lines of data and 5 separate clocks. I don't have ethernet, but the rs-232 printer connection works well as you saw. There are the HP-1650(*) and the 1651(*). I bought the B model 1650 because it has 80 lines vice 32 on the 1651 and it was a later model. There are 1652(*) and 1653(*) which have digital oscilloscope functions as an option. The next step up in class and price are the 16500 series where everything is an option. Those, configured for my needs, were too expensive. The 1650B is a complete analyzer. Be sure to check out the options on each. I believe the HPIB is an option on these if you care. I would like to be able to control all the test equipment but have not got to it. I do have a GPIB iSBX [multibus I/O adapter] card.
BTW, these analyzers require a 3.5" DD disk to boot and operate. I have the one for the 1650/1 here and can duplicate it. You save the config on the disk for your test jigs, as well, so that is nice. Somewhere I have software to read and write the disks on a PC. I also have the code for the reverse assembler. That tool can be configured to give you a full disassembly of the running code.
Again, I bought a 1650A analyzer with a washed out screen for the full set of cables and most of the probes. It was less than $100. I got the operational (the A also operates) B model for around $150 and that was a couple of years ago. I figure a spare board set can't hurt.
SOme months later, we discussed differences among the HP 1650-series products, and the 1630 products:
I believe all 1650 models of the HPs "could" have the IEEE-488 bus as an option. You have to check the details or the pictures for the connector. From the manuals, it appears 488 gives more capability than RS-232 on device control, but I have not needed either. I have used the RS-232 to get printer dumps of the analyzer captures, as you saw. That is important, if you need to revisit one of these machines, or document your work. As for the 1650 vice 1630 - So far, my probes have only used two 16-bit pods. For the larger Intel or Motorola processors, the problem becomes connecting the probe to the board. They aren't SIP chips. I have not figured the answer to that.
There are some more expensive LA's which have Ethernet connectivity - this one does HPIB (of course) and RS-232. I have played with the control over RS-232, but not HPIB, as yet. I am currently trying to get it to talk to a Cisco terminal server so I can import "prints" from the LA. Somewhere I have the the 8085 HP disk with the reverse assembler. It allows one to have the LA actually generate assembler source for the instructions it decodes.
In March, I borrowed a 1630D logic analyzer: bill and I talked about the differences.
The 1630 series has no internal drives, they use an HPIB or HPIL to connect to an external FLOPPY drive (no mention of external hard drives) or to a printer. The 1630 can act as a master or a slave (whatever the HPIB terminology is) so it can be driven by a controller.
The "configuration", from my brief read, amounts to a series of "press this button" text commands. I don't think your 1650 buttons match the 1630 buttons. But I read the 1630 manual ONCE, over a few hours, and it's hundreds of pages. I'm just giving a "gloss" of its operation.
Bill says: "Well, this is truly a different beast. I think the 165X are a better bet for a buy! My system boots the OS off the floppy to operate. It also saves the configurations I ask it to on the floppy."
The 1630 series, as I said, uses external HPIB drives. I'll see if any of my 3.5" HP drives work, and work with this unit. I went to Aligent's Web site, and they have utilities that apparently run on old PC's (MS-DOS? Win 3.1?) to read and write disks in HP's format, and to disect HP's data storage format also. All I know is what's said in those former HP documents and programs.
I can send you a CD of all the stuff I grabbed so far, for your amusement. A number of vintage computer owners or microprocessor hobbyists have used 1630's and have some Web pages About them. Some Web links to that stuff, and commentary I found, is in the attached text file. It's largely notes about the HPIL format and schemes. The 1630 series does not have a serial port, only HP-IB and HP-IL. I've got some HP-IB cards for PC's (ISA not PCI) if I go that route.
But my general plan is simply to use this borrowed 1631D for some period, then acquire a 1650B (serial + HPIB) series with its own floppy drive. Why spend $50, $60 for a 1630 when for $100 I can get a 1650, and avoid external floppy drives, and use a simple serial connection? That's my "logical analysis".
Bill said: I support your analysis. I went through that with the choices available several years ago and arrived at the same conclusion. Now a 165X version with a digitizing 'scope might be real handy for documenting wave forms on the busses and front panels you are messing with, especially if you can dump the waveform to your PC for inclusion in documentation. Beats the hell out of photos [of oscilloscope traces]!
IN March 2012, I asked: "How do you handle the disks that the HP 1650 series produces? can you read and write them on a PC of your's? Or do you strictly work from the Logic Analyzer? My recollection is that you can "print" serially and capture the results on your PC, I don't recall you mentioning any other connection."
Bill responded: "I had some software that would read and write a LIF format floppy. I am attempting to find it as I used it to generate the boot floppy I use now. I also found the analyzer software online. I will continue to look."
[I discussed using various methods to jam instructions into a processor, such as wiring diodes to force a code byte onto the data bus, or wiring up the CPU on the socket, to see only a NOP and so run through memory....]
The earlier series of processors - 8080/8085/Z80/6800/6809/6502 all lent themselves very well to the method of testing you outlined. I have forced data high or low, or forced very small test programs into a EPROM. I did this because I only had the scope. And it worked very well.
The newer processors with multiplexed pins are an entirely different story. This is why I purchased the LA. I need to learn how to use it correctly, which I am doing. It is telling a story that I am not completely sure is true. This is where I need confidence that the tool is telling the truth and nothing more......
I am not there at this point. It appears the first word at the bottom of the ROM is being read incorrectly. Could be simply that the wait state logic is not working correctly and I have a slow ROM. I see different numbers of wait states listed on the LA, but it may be because no pins changed state other than the CPU clock, and it does not report them all. This is NOT a confidence building result! BTW, the wait-state logic and the Ready signal generation are all in the same circuits. More pointing there?
... since the LA is seeing the reset jump just fine, I believe the best course of action is to improve my LA skills to fully see the CPU activity. It is a tool I could never afford in the day, so it is a skill set I never developed. We had on LA at work, but I never got to mess with it much. Now I wish I had taken a class on it.
[Otherwise, using an oscilloscope verus a LA, is] partly a matter of what you are used to. I was always a scope guy - could not afford a LA - but when you have multiple possible points of failure - software and hardware - the LA makes more sense. Since I am seeing the processor reading the ROM and pulling good data at the start, I will assume the board is running [resonably] right. If it weren't, then the LA would lead me to where I need the scope to see the signals. I believe the scope will be the final device I use to isolate any problems. The LA gives 1/0 indication with no idea how clean the waveform is.
In March 2012, Bill said "the LA has been a great tool [to reverse-engineer an 8085 board I'm working on]. The 'scope has been used a few times, as well. The 'scope will display time and frequency as well as voltage of a regular wave form once some markers are set to the right positions on the waveform."
Total investment with both analyzers and all the probes is right at $300. I did receive the HP 10269C POD [recently]. Interesting beast. It has a 1553 bus probe which has three coax connectors - one three-wire and two two-wire. I guess 1553 really is a serial bus like SATA. SO now I need to see what a microprocessor POD for it's costs...
I got bids for the 8086 and 8085 pods for the HP. These fools want $900 for them! I should have not bought the 10269c, either. All I need is a few 40-pin header connectors to plug in the cables from the LA. Then a few LS244's to buffer all the logic signals from the CPU, a socket for the CPU and a plug and cable to plug in the board in place of the CPU. Less than $100 dollars worth of parts, and you have a probe for a processor. Unfortunately, you have to build one for each different processor....
The 10269C is a 5 each 40-pin cable to 2 each 120-pin converter. Basically, you plug in 5 16-line cables from the LA into it, and it plugs into a "personality" module that connects to the DUT. If I had known that, I would have skipped it. If I have to build the personality module, it is just as easy to terminate what ever number of cables from the LA directly. And I will have to do that. I am trying to design a universal module that will handle any of the 40-pin DIP processors. Now that is a trip!
[HOw are you accessing the board with your LA probes, by the way?]
40-pin chip clip. I push the probes onto the necessary pins. A universal adapter, but not without causing some ringing on clock and fast switching lines. The 8086 adapter (at 390 dollars) connects the analyzer probe pins (off the 20 pin connectors) to the CPU through some TTL logic which reduces the loading. I will eventually build one of these.
I [also] have a really exceptional Multibus extender card [as linked on my Web site]. It is shown in several of the 80/10 photos. Since I currently use the multibus exclusively for power, the effects of the extender are minimal. Signals on the multibus all looked clean on the three board set when operating, as well, even with the CPU in the extender.
I did a bit more searching to find the cable sets than I did to find a good LA. [But later, Bill describes how he built his own cables.]
I had to solder 0.025 pins on the 40-pin chip clip because the original pins were a bit large to take the push-on connector at the end of the pod wires. BTW, a lot of those push on connectors get torn off the wires, but there are push on connectors that can be used to repair them.
I just connected an 80-wire PATA IDE cable to one of the pods. It is the proper connector, but the shell is a little short, and would not seat into the HP connector without some work on the HP connector. If the ground side of the cable is identical to the HP cable, that might be a good low noise high speed cable to use. Even a regular 40-wire might be good. Might take a little work on the LA end; [but on trying it,] I had to push the connector in deeply in the analyzer and the pod socket. It works just fine on the 8086.
The pods are just connectors which terminate a shielded wire in two pins. The shield goes to the ground side (can't put the terminal into the connector wrong - its keyed) and the center goes to the push on connector through an 89.7K resistor! I suspect we have a 90K/10K divider feeding input to the LA. 10K is in the LA.
In later conversation, Bill added: The probes are really a non-issue. The push on connectors connect to the gripper pins if you go that way. I use the clipchip as it makes it one pretty substantial probe. And since I now know the hardware involved, reconstructing probe sets will be fairly easy,
I have even figured out how to build one probe for ALL 40-pin DIP chips which can be "configured" for each individual processor. Lying flat on your back with NO movement for 14 hours does have advantages.
The high and low of what I am saying here is we can build wire and chip interfaces quite easily for this family of LA with stuff we probably have in the junk box.
- Bill
Dec 25th: I have been trying to run down problems on both of my boards. The old eyes are a problem trying to see very [narrow] pulses on the 'scope. I assumed there were no transitions on certain of the 8086 lines and the ROM select line. I put probes on both chips and connected various lead from my 1650B logic analyzer - specifically, the first three status lines, all 16 data/address lines, reset and ready. Ready is going low and the processor halts (86/30) or runs wide open (86/12). The 86/12 will also halt if the timeout jumper is pulled. The 86/30 responds the same with or without the jumper.
Anyway, what this is all telling me is the processor is starting to run the ROM program but failing in some manner. That probably means my ROM code, which is my 8086 conversion of my 8080 monitor, is not operating as I would like. I will stare at the code while I continue to scan the [paper] Intel documents [I recieved into PDF files].
[I asked if the narrow pulses were "glitches", logic race conditions that cause brief unintended logic changes. Sometimes glitches are caused by DC power lines with bad bypass caps.]
The transitions on the scope are all nice square waves. It was just that some were pretty short. Power at various places on the board appears to be clean on the scope. I am aware of the failure of capacitors over time - especially electrolytics - this is a major item on the reworking of the old radios. .... I look at the supply voltage when I add untested boards and I do check for shorts on the supply lines before I put them in the card cage. But you never really know until power is applied. Then I can scope the supply lines in a few places.
Dec 28: I assume the board is operating, at least to an extent. This is proven on the 86/30 simply by the ALE LED lighting for a short period after reset. I use the LA to find the problems. I am not looking for glitches - I am watching actual address and data fetches, with wait states, etc, all output on the LA. All the [8086 CPU] state information is there. I see exactly what the processor is seeing, and I see where it reads bad data and goes west. Then it becomes a matter of isolating the problem.
[later:} So I have hooked up the logic analyzer. I am seeing the ROM enable signal and good data reads from the ROM. I am trying to get the LA to allow me to see more than one pod - 16 bits - simultaneously. Back to the fine manual. Essentially, I want the LA to show me all the signals of interest on the 8086. I have the test equipment but have not learned how to use it.
I found the base module for my LA to support the actual microprocessor pods. I have not found any cheap pods, as yet, The base module comes with a 1553 bus probe.
Dec 29: So far, I have found a mistake in generating the ROM which caused part of the initial far jump to not be written. Corrected that, and the system is jumping to the beginning of the ROM image and running into an unknown problem. Eventually, the program goes off to unimplemented memory, where the processor no longer gets a READY signal, and the processor halts, as it should. [It halts because] every read or write to a valid address (I/O or memory) returns this ready signal or the failsafe timer generates it. The failsafe on the 86/30 is NOT doing this, so there is one hardware problem to run down. The 86/12 does generate a failsafe, so it bounces around unimplemented memory with abandon. The ROM generation for it also suffers the same problem as for the 86/30.
[again] it appears the first word at the bottom of the ROM is being read incorrectly. Could be simply that the wait state logic is not working correctly and I have a slow ROM. I see different numbers of wait states listed on the LA, but it may be because no pins changed state other than the CPU clock, and it does not report them all. This is NOT a confidence building result! BTW, the wait-state logic and the Ready signal generation are all in the same circuits. More pointing there?
Another benefit of the chipclip is that I can move the probe between boards without problems.
Dec 29: Again, since I am actually monitoring the address, data and state at the processor, I can see the the 8086 reset, do the read of FFFF:0, 2, 4, and 6 (yes, it prefetches before it figures out it has to jump to fc00:0). At FC00:0, there is a jump around the a copyright notice. It is getting confused there. Might be the EPROM is not fast enough - there does not appear to be any wait states. I configured the board for 3 wait states on a ROM read.
[On reset] the cpu resets CS to FFFF and ip to 0, thus the first instruction is fetched from FFFF:0. All 8088 and above machines expect ROM at the high memory address. RAM is always low address.
Dec 30: [I asked if the ROMs were rated too slow for the board.] I have the original 200 ns ROMs I pulled from the board. I have erased them and will reprogram a pair of them (8086 is a 16-bit machine). But in reality, the read set up time is many clock cycles on the LA. It does catch a change of the address lines about 80 ns into the cycle, then the address is correct. It says each machine cycle is 200 ns, so my 5 MHz setting is correct.
[I asked about corrosion on IC pins in sockets, causing logic faults.] There is evidence of corrosion on all pins, jumpers, and socketed chips. Maybe I need to pull all the socketted chips and give the board a good cleaning. And then start again. I believe I will do that.
[Later:] I put erased ROMs and then ROMs with 0 at the jump address. The CPU is seeing all bits as 1 or 0 as expected. I believe we can accept that the data path between the CPU and the ROM is good. And some addressing seems to work. I pulled the jmp short and copyright notice from the start of ROM. The CPU now goes west when it tries to follow a call into a space 700 bytes up the ROM. Going to look at the ROM address lines and see what is happening.
[As for RAM,] I don't have faster than 200 ns 2764As here. I have 128, 256, etc but have not looked at the speed. The default jumper was for 2 wait states but the manual and schematics show settings for 0-3. I am currently on 3. [On cleaning the board; I used a] good old eraser for those gold contacts. But all I am relying on the [backplane] to provide at this point is just power. That is all good. Board cleaned up good, but I have one extension connector to the second RAM card that came off the MB. Going to be a bear to put it back on. Going to have to think about that. [Later he wrote:] Repaired connector. No shorts and no problems.
Jan 2: I am now much more confident in the LA. I made some test ROMS to verify we could read all 0's and all 1's. The program now runs until the the first attempt to write to RAM - saving the return address from the first call on the stack. I get no READY signal [from RAM access]. The RAM setup is complicated by the sheer number of jumpers and the lack of good documentation in the HRM. This is the first time I have been unhappy with an Intel [hardware manual]. But the scope and the diagrams will show me the way through. I hope to get the "printer" interface working to the HP 1650B so I can include the latest LA data.
The first instructions in low ROM actually set up all the segment registers as required. The far jmp only loads the CS and IP. I know it is set up since I can see the bytes being read by the CPU that I wrote to do exactly this. And it is failing when it tries to write the return address on the stack [on CALL], not on RET.
Jan 3: Well, it is a matter of training and accepting the analyzer is telling the truth. I have identified the exact failure mode for this problem. The current problem is the 8284 not setting READY on a RAM write. It is obviously an error in the address path through the multiple decoders for RAM. And I really believe it is a simple jumper installed incorrectly or missing altogether.
I connected the LA to the serial port on the Windows box and "printed" the LA output. I commented it and placed a few key labels and bit combinations which come from the data sheet for the 8086. I read hex and binary and can follow the bit patterns. What you see here tells the WHOLE story. [link to trace1.rtf, see "logic analyzer trace below]
Jan 9th: 8284 is operating correctly. It is not getting the proper ready input from the RAM. ROM read is working correctly. I need to trace the address lines through the various decoders and logic gates that should generate the signal. I know it is missing from a pin on the 8284. I plan to work backwards from there to see what the deal is. It is still my belief that I am actually not addressing the RAM because I have a jumper or jumpers in the wrong places.
I shorted a couple of pins together while scoping the ready situation, and it ran further. I will return to that and see if I can actually make it work. ...But I don't want to take [further cut-up] measures that will harm the board until I am SURE a component must be replaces. These multilayer boards are a bitch to replace parts on. But I will socket anything I have to replace!
I am still betting I have the RAM misconfigured. The Manual is less than useful in this case.
Jan 16: While I was messing with the HP I was also playing with the 86/30. If you will look at the schematics it's sheet 2 of 16 ... on the 86/30 page.
It appears the address latch for A12 is locked high on pin 12 of U47, even though the input to pin 13 of U47 (74S373) is low. That is the correct value for anything in the ROM, but not the low RAM. I traced the signals from the READY lines backwards and found that A12 did not change on the ROM and RAM address decoders. This line is only used in a few places, and they are all properly connected, so I have to believe the output of the S373 has failed. It is an address line to decode the high nibble of the 1 MB address space.
I will have to buy some 74S373's to fix it. Then I have to carefully cut the chip off its pins, so I can remove each one. I will socket the location.
Jan 20, the debug: I had traced the problem to the A12 line held high. I then watched the input and output on that register in U47 and saw output not following input. Ah, I have it! So I carefully dremel off the old IC and pull each pin, carefully, then put in a socket. I only had 74LS373's so I put one in and found A12 still hung. Damn! So I pulled U46 and U45, the address decoder PALS. No hang! I replaced U46 and still good. I put in U45, and it hung again. So I have a bad address decoder. I find the logic description in the manual, but not the actual code used to program it, so I will have to stumble through compiling another decoder and placing it in a GAL.
BTW, pulling the address decoder PALs causes the CPU to run constantly. What I expected.
Mar 18: The Zendex [8085 single-board card] is alive! This is a ROM monitor which only uses the onboard RAM, ROM and I/O. Next step is to get it using the 64KB external RAM card. The monitor just came up using the 354 serial board. I have some more work to finish the clean up of the monitor program. I developed another [logic analyzer] capture program that is triggered by the first fetch from a selected memory address. Came in handy in following the processor to it's next failure!
march-April 2012: Bill continues to have problems making the Intel 64K card work with the Zendex CPU board. We discussed some kind of Multibus logic probe connections. - Herb.
Bill: I have the zendex computer on the test bench, as well. Still trying to hunt down the lack of a ready signal from the Intel RAM card. When I use the iSBC 80/10 processor, the ready line gets really hammered. I have compared wired pins on the two CPU boards to see if there were some other pin used to talk to/from it besides the pins I expected. No joy. And I am running the processor at 2 MHz (slow).
I may need to make a logic analyzer probe for the multibus itself, to see what is happening. Right now, the ready line stays high (multibus is all negative logic) regardless of what the processor does.
Herb: About a Multibus logic probe. If I were building that bus probe, I'd take a blank or stripped Multibus card and build a terminator/probe on it.
Bill: The card cages already have terminators. The multibus appears to use 220/330 ohm resistors to hold the lines at about the TTL threshold.
card cage brings the entire bus out to a multibus plug on the top to allow stacking card cages for more slots. I just plus a connector into it and push the LA probe wires on where necessary, just as I did with the chip clips. If in need to make a more permanent one, I can just attach a small board to the edge connector to do the level translation and provide 40-pin connectors for the LA. Remember, each 40 pin LA connector provides 16 logic lines and one clock.
Herb: A reasonable active terminator for TTL or tri-state, would be a series resistance of several hundred ohms on each line, all connected to a common voltage source held at about 3V. That sets up a small amount of current whether the line is logic high or low; and a logic high condition but one easily brought "low"; and low impedance. Open collector termination is usually not necessary, there should already be a pull-up among the boards in use - if not put one on the terminator.
A whole discussion of S-100 bus termination is on my Web site at this link.
Bill: I use active termination on my S-100 stuff.
I connected the LA to the serial port on the Windows box and "printed" the LA output. I commented it and placed a few key labels and bit combinations which come from the data sheet for the 8086. I can read hex and binary and can follow the bit patterns. What you see there tells the WHOLE story.
Label > ADDR DATA STATE Time
Base > Hex Hex Bin Rel
RR SSS
SD 210
TY
-0016 00000 0000 100000110111 200 ns
-0015 00000 0000 100000110111 200 ns
-0014 00000 0000 100000110111 200 ns
-0013 00000 0000 100000110111 200 ns
Your "state" columns reasonably show RST, RDY and the three 8086 "State" pins. But there's a few columns not defined. I see bits go high and low. Are they hooked up, or are those random bits, or what?
Here are the definitions (left to right on the STATE binary column):
RESET READY /INTA ALE /BHE /RD HOLD HLDA /WR /S2 /S1 /S0
I connected all those other pins, but since the 8086 is in maximum mode, the CPU does not generate those signals. They are generated from S0-S2 in a 8288. /INTA, /BHE, HOLD and HLDA are valid, but are not occuring in the current situation. A16-A19 represent S3-S6 when not at T0. Clock is 5 MHz cpu clock (CLK). I sample on the falling edge of the clock.
[herb: I read the LA's output and here's my extraction of Bill's code from the LA's view of it:
> FFFF:0 00EA ;long jump > FFFF:2 0000 > FFFF:4 00FC > FFFF:6 0000 > > FC00:0 00B8 > FC00:2 8E40 > FC00:4 B8D0 > :6 0100 > :8 E08B > :A C88C > :C D88E > :E B1E8 ;e8 07b1 which is the relative call. > 1:0 BB07 > 1:2 ????? > > FC7C:2 32FA ;This is the code at address fc00:7c2 is fa 32 > ??????? > >
[Herb says: "Now I look at your code snippet and compare. Well, I'm not sure what I'm seeing past your CALL instructions, as you say it's prefetching or losing RDY. Looks like the DATA may be hi/lo byte or lo/hi, a little confusing, but I think it's all "there".]
It is an Intel processor - but the LA places the bytes in order. Notice S2-S0 now show a memory write with no ready signal returned. Processor will wait for the READY forever.
Contact information:
Copyright © 2015 Herb Johnson