HP 3468A in continual reset/init?

[Sailor]

My HP 3468A that I bought in 1983 finally died a few months ago - sort of. It looks like it is in a continual initialization loop, every segment and every annunciator is lit, and blinks about once per second. At the time I had a quick look at the supplies (don't you just love the old days, a *complete* manual with every piece of equipment ) and all was ok, so I just put it aside. Even now, I don't plan on rushing into it, but I saw it sitting in the cupboard the other day so I thought I'd ask if there is a common cause, or if anyone has had this symptom before. The manual uses Signature Analyzer numbers for trouble-shooting, and guess what I don't have...

[Sailor]

I've just got back to look at this, and my first thoughts are RomRot of the Mostek 36K control ROM. I've taken a dump of mine and I am hoping that someone else might have done the same at some time and I could compare them. One of the possible self-test errors implies that it checks the ROM, but whether it's a checksum (8?16?32) or a CRC (16?32), and whether it would be a single value over the whole 8K, or two checks of 4K, or even 4 checks of 2K (because the 'Memory Bank' segments are 2K in size), is all unknown. I can put together a program to compute those possibilities, but there is still guesswork involved, and a non-match wouldn't be definitive. Of course, a proper match would

I've hooked up my TLA715 and taken some state and timing files, but the first thing that comes out of those is that it's not stuck in a small loop anywhere - it's executing *huge* amounts of code until the hardware timer hits the RESET again (a simple 20-bit count of ALE pulses without being zero'd by keypad scanning operations).

I've run my dump through the D48.exe disassembler, but there are a couple of issues with that - one being that it naturally doesn't know about the way the 3468A handles an 8KB ROM. I'm not even sure myself how HP would have written the code.

Lots to learn. If anyone does have a ROM image, I'd appreciate a copy. All comments welcome.

Sailor

[dom0]

Is the ROM in yours socketed? I don't think any of the ICs in mine is socketed, only the input hybrid circuit is.

You'll also want to check the floating circuitry, I know mine goes into general reset if the A/D controller hangs.

[Sailor]

No, it's soldered in. I didn't want to disturb it, so I pulled the 8039 ($1.95 from Jameco) and put a socket in for that. Then I lashed up an AVR mega (an Arduino) to that socket and had it read the ROM and output IntelHex records.

That's interesting about the ADC putting it into reset - I guess it's the same timeout mechanism. But I would hope in my case that it could have output something to the display if it found a fault, 'cause that's the purpose of a self-test after all

I've just been reading the manual (again, for the umteenth time!) and it does use the word checksum in the ROM error paragraph. It's not definitive, because I've seen a lot of technical writers use the word 'checksum' wrongly, probably because they don't know what a CRC is . Still, I'll check that first.

[Sailor]

A bit of an update:
I fixed a slight problem with the D48 disassembler and now have code listings of the upper and lower 4k sections of the control ROM. I then started tracking (in the listings) execution from the time /RESET is released. That was tedious enough, but combined with the programmatically controlled hardware switching between the upper and lower 4k memory blocks (not to be confused with the 8039 internal Bank0 and Bank1 code switching, which also comes into play) it gets old very fast

I have now made an adapter/8039 that I can control from the Arduino so that I can single-step the 3468A, and that is working as of a few minutes ago. I will expand the commands so that it can do a few extra things like STEP_n instructions, STEP_UNTIL_<address>, set address breakpoints, etc. I should get some of that working tomorrow.

Coming at the ROM checksum identification from another angle (after I had gotten up to speed on the instruction set) it became apparent that it is not easy (or not as easy as it is on a modern micro) for an 8039 to compute/perform a checksum on an 8k ROM. and that it would have to make use of a specific instruction as part of such a routine, and that there would need to be certain supporting constructs throughout memory. It probably took less than an hour of examining the dumps before I was able to identify what I believe to be the ROM checking routine. In one of those quirks of life, the entry into that routine turns out to be approx another 20 instructions further on from where I stopped my manual decoding , although I'm not sure that I would have recognized it for what is was, at the time.

I'm quitting for now (the Monaco Formula 1 race is on soon )

If there is anyone else (besides Kjelt, who I've PM'd a couple of times) who has a broken 3468 and would like to follow or participate, please let me know.

[MarkL]

There's a kernel test procedure that you don't really need a signature analyzer to use.  It appears to jam a 0xff onto the data bus which is a single cycle "MOV A,R7", and also disables watchdog counter U504.

The kernel test allows the processor's PC to increment through the full address space.  The ROM may be dead, as you suspect, but you should at least be able to check that the output of address latch U508 is incrementing.

Perhaps you've already done this with the LA, but just thought I'd mention it.

With a problem like this I'd prefer to use a scope to check for indeterminate logic levels.

[Sailor]

Yeah, I'm well past those sorts of things now, thanks Mark. Apart from all my initial work with the scope when I verified that all signals on the data, address, and ports were moving ok, nothing stuck, and all levels good, I then drove the system with my Arduino/Atmega2560 i.e. with the 8039 removed. The ROM contents disassemble into 8k of what appears to be rational code, although it only takes one bad bit in the wrong place to screw everything.

There is some rational operation occurring, though. For example, the display is set to the correct configuration (all segments, annunciators, etc ON, except the top dots), and then, approximately 35msec after the release of /RESET there is a single scan of the keyboard, after which the CPU continues with whatever it is that prevents any further KB scanning, with the end result being the timeout/reset by U504.

But here's the thing - if I initiate a reset (e.g. by momentarily grounding the /RESET line) while holding one of the KB buttons depressed, the single scan of the KB turns into a never-ending sequence of scans (separated by ~ 600usec) that will continue as long as I hold the button down. U504 naturally doesn't time out, and the CPU is obviously detecting the 'stuck button' situation. So it's not totally brain-dead.

The saga continues...

[MarkL]

It seems that you like a good challenge.  If you're really into it, you could use the TLA to capture a state analysis of the pins on U502 after putting the unit in SA1, as described in section 7-D-26.

Then from the capture you could compute on a per pin basis what a signature analyzer would display.  The signature analyzer algorithm is described in HP Journal, May 1977:

  http://www.hparchive.com/hp_journals.htm

That would at least answer the question about the ROM, and now you have a signature analyzer to dig further if necessary.


And of course there's always the lazier way of picking up a used 5004A or 5006A.  They can be had for around USD$75.

[Sailor]

Thanks for that reference, in the past I've briefly (VERY briefly) considered duplicating, simulating, or otherwise deriving some benefit from the SA tests, but not knowing exactly how the SA functions, whether it both drives and senses signals, what sequences it uses, etc etc, I have never pursued the idea. I'll read that, in conjunction with one of the SA manuals (can you tell me the difference between the 5004 and 5006?) and see what I can piece together.

There are a couple of things about the SA0 and SA1 tests that I'm confused about - maybe you can help:

(...delete about a half-hour of writing here...)

Errrr, no. After labouring over my questions for quite a while and writing a page of questions, during which I had to think really hard about the way the tests worked and what they were measuring, I worked out my own answers. I really must thank you Mark, forcing me to think it through so thoroughly has been a great help.

Given that I already have a dump of the ROM, I should be able to lash up a simple Matlab script to process the file and derive the signatures - I think. And the SA0 signatures should just be the values from the bits of a binary count pattern (I think), which I can duplicate in Matlab, thereby validating my script.

But there is still the question about the difference(s) between the 5004 and 5006 - if you know.

Thanks again,

And of course there's always the lazier way of picking up a used 5004A or 5006A.  They can be had for around USD$75.

No no no, that would be cheating

[MarkL]

Given that I already have a dump of the ROM, I should be able to lash up a simple Matlab script to process the file and derive the signatures - I think. And the SA0 signatures should just be the values from the bits of a binary count pattern (I think), which I can duplicate in Matlab, thereby validating my script.

I agree on the SA0 values.  It should be a good validation.

But I don't think it's as simple as computing the CRC (that's really what the SA is doing) across all the bits in the ROM dump you have.  Whereas SA0 disables the ROM, SA1 re-enables the ROM and holds processor pin 31 (P14) low.

My guess is that the processor samples P14 at boot and, if low, goes into a loop where it reads all the locations in ROM, and probably pokes at all the other places described in table 7-D-4.

So, the ROM contents are jumbled in the with CRC of the program running and all the other probing going on in the SA1 loop.  Since you've disassembled the code maybe you can spot this loop.

I guess, in theory, you could actually do a software re-creation of the 8039 and compute the CRC of the ROM accesses, but wow... Now that's a lot of work.  The more sane approach would be to capture a state analysis on the ROM, clocked by /CE and delimited by JM503 going low and then high.  Then run that through Matlab.

But there is still the question about the difference(s) between the 5004 and 5006 - if you know.

The 5006A allows a faster clock (25MHz vs. 10MHz), and also has a qualifier input.  I don't recall ever seeing a qualifier in any HP test procedure, so it's probably if you wanted to develop your own in house SA procedures for your own products.  The 5006A also GPIB, but I think that's a weird thing to have on a piece of equipment that's almost exclusively designed for interactive use.

But the shorter answer is: For troubleshooting this old HP gear they both do the same thing.

And of course there's always the lazier way of picking up a used 5004A or 5006A.  They can be had for around USD$75.

No no no, that would be cheating

I thought the easy way might not be appealing to you!


EDIT: Fixed html quote.

[Kjelt]

If there is anyone else (besides Kjelt, who I've PM'd a couple of times) who has a broken 3468 and would like to follow or participate, please let me know.

my update: you have an email. Not good news I am afraid. 

I finally had some time today to desolder the HP ROM and make a transfer pcb to an Intel 2764A.
You can see the details in the picture. I connected the /CE of the intel to the /CE of the ROM (intel has /CE and /OE , the ROM only /CE).
Unfortunately this results in only 0xFF return values over the entire 8kB.
So next attempt from me was to connect the /OE of the intel to the /CE of the ROM, same result: only 0xFF    I am very dissapointed as you probably are to.
 
Maybe I should try a different chip, anyone a better candidate then the 2764A ( I have a batronix BX40 Bagero II programmer so can read everything in this list: http://www.batronix.com/pdf/BX40Bagero-II-DeviceList.pdf )

Or should I perhaps use an OR gate to multiplex both /OE and /CE of the Intel to the /CE of the ROM?

Another even worse explanation can be that my ROM is really dead (broken).

[MarkL]

...
Maybe I should try a different chip, anyone a better candidate then the 2764A ( I have a batronix BX40 Bagero II programmer so can read everything in this list: http://www.batronix.com/pdf/BX40Bagero-II-DeviceList.pdf )
...

You might want to try reading the MK3600 as an 87C64.

The MK3600 latches the address lines on /CE going low.  The 2764 does not do latching and just outputs whatever is on the address inputs after a lookup delay.

So, the Batronix may set /CE low and *then* set the address pins which wouldn't matter on a 2764, but would cause erroneous data to be read on the MK3600.

It's a possible explanation.  It doesn't seem likely you'd get all FF's, but it's possible depending on exactly how the Batronix is controlling the address and /CE pins.

The 87C64 is another type of latching EPROM, so the Batronix should order the changing of address and /CE pins appropriately.

[Kjelt]

You might want to try reading the MK3600 as an 87C64.

Thanks good thinking, I just tried but unfortunately the same 0xFF result.
Makes me wonder if the timing is crucial, the MKB can be as slow as 300ns twice as slow as the xxC64 chips. Set it at -35 (350ns) and that doesn't work either.
Perhaps I should do the same as Sailor did, hook it up to a 8 bit microcontroller board and program my own readout sequence. Will take some time though.

[MarkL]

...
Perhaps I should do the same as Sailor did, hook it up to a 8 bit microcontroller board and program my own readout sequence. Will take some time though.

You could also take a quick look at what's happening in the programmer with the data and address pins in relation to /CE transitions.  And make sure power is showing up on the right pins.

[Kjelt]

You could also take a quick look at what's happening in the programmer with the data and address pins in relation to /CE transitions.  And make sure power is showing up on the right pins. 

Power is correct, I checked that. All address and datalines are checked with multimeter.
I am a bit afraid using the scope on the programmer since the PC is earthed and the programmer is on the USB, I do not want to blow anything up. I am not sure what the Batronix GND on the connector is related to earth (scope ground).
Tried with an USB isolator I had laying around but then the Batronix does not work anymore, bummer 

[MarkL]

Understood on not wanting to connect the scope.  It's fine as long as you check first that the potential between the Batronix ground and the scope ground is 0V, but don't do anything you're not comfortable with.

You have a point that since the Batronix can change the function of a pin, the 2764 ground pin may not be ground all the time, but hopefully the Batronix is protected against that since it needs to handle completely shorted chips.

I'm noticing on your little diagram in the upper right of your paper that the 2764 is numbered clockwise, which is incorrect when looking from the top.  Maybe it's not wired right?

[Sailor]

Hi Mark

But I don't think it's as simple as computing the CRC (that's really what the SA is doing) across all the bits in the ROM dump you have.  Whereas SA0 disables the ROM, SA1 re-enables the ROM and holds processor pin 31 (P14) low.

My guess is that the processor samples P14 at boot and, if low, goes into a loop where it reads all the locations in ROM, and probably pokes at all the other places described in table 7-D-4.

You are, of course, quite right. I had let my thoughts (of getting the signatures from SA0) run far ahead of registering the significance of the change to the start/stop connection for SA1 Oh well, I may still be able to use my Arduino as a SA. I think the speed (16MHz) will be sufficient, given some careful assembler code, and provided the SA1 sample size (start/stop time) isn't too long (I'll capture pin states to a RAM array and post-process the CRC).

The use of S501 to ground P14 during SA1 is a bit strange, because that inherently denies *any* access (and therefore signature check) of the upper 4k of the ROM. And as it is that upper 4k that the 3468 boots into during normal operation, well ...

@Kjelt
I haven't had time yet to read your posts in detail, just skimmed them.  I (we all) would like to think that it's finger trouble in some way, total 0xff as a reality is too horrible to think about   I'll get back to this in an hour or two.

[Sailor]

I'm noticing on your little diagram in the upper right of your paper that the 2764 is numbered clockwise, which is incorrect when looking from the top.  Maybe it's not wired right?

Mark, Kjelt sent me a photo of his transition/adapter board - the ROM socket is on the underside of the board, so it's mirrored. Power, ground, and 27C64_20 --> ROM_20, etc all look OK.

I agree, it's time for the 'scope. I'd just meter the Batronix frame ground to the PC ground (without the USB isolator) and if that's ok, then clip the scope probe ground to the Batronix frame and start looking at signals. They probably won't be pretty to look at, but you'll get an idea of what's going on, and what relative voltages are on the pins.

Strange that it should be so dead...

I've had aquick look at JM503 while running SA1. It goes low for ~1msec, then high for ~20usec, then low again for more than 700msec before going high again to complete the cycle. I would like to think that the 1msec interval is the intended SA measurement window, but how is a 5004 to know? Or is the 'double window' just another symptom of what's wrong with my 3468A

[MarkL]

I'm noticing on your little diagram in the upper right of your paper that the 2764 is numbered clockwise, which is incorrect when looking from the top.  Maybe it's not wired right?

Mark, Kjelt sent me a photo of his transition/adapter board - the ROM socket is on the underside of the board, so it's mirrored. Power, ground, and 27C64_20 --> ROM_20, etc all look OK.

Oh well.  It was worth mentioning just in case.

I've had aquick look at JM503 while running SA1. It goes low for ~1msec, then high for ~20usec, then low again for more than 700msec before going high again to complete the cycle. I would like to think that the 1msec interval is the intended SA measurement window, but how is a 5004 to know? Or is the 'double window' just another symptom of what's wrong with my 3468A

The 5004 wouldn't know.  It's constantly updating its display, so it would display one value, and then flip to the other.

If you can locate the loop in the disassembled code maybe you could tell if it's flying off into la-la land, or if its doing some initialization first.


And you're right - it's also quite odd that SA1 is only checking half the ROM.  Maybe the lower half contains a ROM check routine and if that's intact it can check the rest of the ROM and display an appropriate error.  So, it's only critical that the lower half is ok.

Building an analyzer with an Arduino is going to take some really tight coding.  The 8039 with a 6MHz crystal has a minimum cycle time of 2.5us, and the PSEN width (which is the MK3600 /CE) is only 400ns.  That would be your analyzer clock for SA1.  This is all according to the data sheet, but since you have it in front of you, you can say for sure.

[Sailor]

Maybe the lower half contains a ROM check routine and if that's intact it can check the rest of the ROM and display an appropriate error.  So, it's only critical that the lower half is ok.

I think you must be right with that.

Building an analyzer with an Arduino is going to take some really tight coding.

Indeed.

I didn't bother with Matlab - it was far easier to do it in assembler on the Atmega. The code generates the correct signatures for the count patterns from SA0, so I now know that part works (but it's post-processing of captured data, not real-time). With a simplistic approach, but tight coding, the CRC shift register update takes 19 cycles. At 16MHz that is just a fraction under 1.2usec. The stack operations in an interrupt/return is slightly more expensive than simple testing of an input bit (which is the way I handle the detection of the ALE and PSEN signals in my Single-Stepper implementation). Start condition detection can be handled the same way, and the stop condition could be handled by interrupt. So it may well be do-able.

I've got a fuzzy idea floating in my brain about another algorithm that might shave a few cycles off the present 19 ... I'll sleep on it.

[MarkL]

If you can't speed up your code enough, you could try slowing down the processor clock to say 3 or 4MHz (or whatever your code needs).  You could use a function generator and feed it into XTAL1 (pin 2).  Note that XTAL1 is not TTL compatible.  With some level adjustment, you could also use one of the PWM outputs from the Arduino.  In either case, I'd lift the crystal since I don't know how happy the driver on XTAL2 (pin 3) will be with a large input signal coming at it.

I don't see anything off-hand that wouldn't tolerate a slower clock.  The only thing that might not like it is the ADC, but that's not part of SA1 and is tested in the next section.

Admittedly this is changing the test conditions, but maybe it will show the ROM contents are ok.  I'd keep in mind that if the ROM shows ok, you still might be subject to some kind of strange race condition that's developed over time at the higher clock speed.  But at least you might end up with a basis for comparison for further analysis using the TLA.

Another interesting thing would to put the unit in normal mode and see if it gets any further with a slower clock.

[Kjelt]

While at work today I remembered that a few years back I bought a cheap logic analyzer (and never really used it).
Because that is also powered with the same USB source I thought that would be ok to use it.
So here are two screenshots I just made, I used the 87C64 setting of the Batronix because indeed the 27C64 setting was wrong (good catch Mark).

A0..A6 are the address lines A0..A6
grey (A7) is the /CE of the ROM
B0..B7 are the data lines D0..D7

So as you can see the datalines keep on staying high which corresponds to the data read from the Batronix software.
I am not sure what is going on, but looking at the zoomed in (second capture) and knowing the internal sampling clock is 25MHz and the nr of samples the /OE is high is about 15,
that would correspond to about 60ns which I guess is too fast (too little time high) to work for the MKB36k ROM (pre charge time t_p=125ns).
I am sleeping 15 times (25MHz = 40ns) is 600ns which should be more then enough.

What do you guys think?

[MarkL]

...
I am sleeping 15 times (25MHz = 40ns) is 600ns which should be more then enough.

What do you guys think?

I agree - 600ns should be fine.

But I'm also seeing that the Batronix /CE pulse width (when it's low) is in the ballpark of 10000ns, which is listed as the max on the MK36000 datasheet.  Are there any adjustments for that?

I don't know what the impact would be from going over the max.  I'd expect to see at least *something* coming out of the data pins, but maybe that's the issue.

So, I assume your MK36000 also came from a 3468A?  Want to put it back in there and look at it with the logic analyzer?


(I keep calling it a MK3600... I mean MK36000.)

[Kjelt]

I am afraid that there is not enough room for a socket in the 3468a since the plastick powerswitch extension runs over it 
So I would have to make some temporary thing then. That can easily be reversed.
 I will have to see how to do that, any suggestions?
Its bedtime for now for me.
BTW, another open issue that we might discuss is with which other memory device we are going to replace the MK36000 if we have the final content. It could well be that we need a microcontroller to emulate it?

[MarkL]

I am afraid that there is not enough room for a socket in the 3468a since the plastick powerswitch extension runs over it 
So I would have to make some temporary thing then. That can easily be reversed.
 I will have to see how to do that, any suggestions?
Its bedtime for now for me.

It was just a suggestion to see if we could get some data out of the ROM.  I didn't realize it was mechanically difficult.

Do you want to post a picture of the area?

BTW, another open issue that we might discuss is with which other memory device we are going to replace the MK36000 if we have the final content. It could well be that we need a microcontroller to emulate it?

From what I see, the circuit design does not take advantage of the MK36000 address latching feature; there is a separate address latch U508.  So, I think even a 27C64 with 250ns access time or less would work fine.  But there's obviously a pin count problem, so some kind of adapter will be needed.

[MarkL]

Another thought for a replacement device would be a parallel EEPROM, such as AT28C64B.  But again, 28 pins.

[Sailor]

The MCM68764 EPROM is a drop-in replacement for the Mostek device. Again, it doesn't have internal latching for the address, but that's unimportant here.

Mind you, I haven't yet looked into actually sourcing one.

[Sailor]

BTW, another open issue that we might discuss is with which other memory device we are going to replace the MK36000 if we have the final content. It could well be that we need a microcontroller to emulate it?

Yes, replacing it with an AVR would be trivial.

[MarkL]

The MCM68764 EPROM is a drop-in replacement for the Mostek device. Again, it doesn't have internal latching for the address, but that's unimportant here.

Mind you, I haven't yet looked into actually sourcing one.

Nice.  There's a few different sources on ebay.

[Kjelt]

Still no luck reading out the ROM. I asked two friends of mine that had old programmers with dos software but neither supported this or the motorola ROM 

[Sailor]

A couple of hours ago I remembered (I think I'm suffering from RomRot too) that I have an old Sunshine Expro-60 programmer. I haven't used it for about 20 years or so, and I only came across it in my storeroom (junk room, according to my wife) when I was looking for something else. Anyway, it has a couple of disks with it (I do *some* things right) so I had a look at its device list. Sadly, the only Mostek device it knows about is a 2716, but the good news is that, if we ever get hold of known-good code then we can create copies, because it *does* know about the MCM68764

I'm not sure if I ever updated it - this page http://www.danbbs.dk/~rmadrm/expro.htm shows updated (1997 / 1998 ) Sunshine code, and some other alternative code. I'll look into that a bit later. The other thing is that I will have to find a really old machine to run it on - it seems that the processor needs to be less than 233MHz. I have one very old Digital PC which I think can be made to run, but I'll need to check its speed.

It's unfortunate that you can't find anything that can natively read the Mostek device. If I was you, at this stage I would lash up a simple oscillator and counter (on that spare spare space that you have on your adapter board). The counter only needs to be, say, 4 bits because if the first 16 locations don't show any good data, then it's pretty much shot anyway. The address setup time before /CE is listed as 0ns, so it wouldn't be hard to use the same edge to clock the counter and delay it a little (R-C plus the inverter) to make /CE. The scope will then give you a definitive answer.

[Sailor]

I don't have anything really useful to show for an investment of *many* hours. My single-step /trace /run / ... adapter works well, it's just that as soon as you give the 8039 free control, it gets into different loops (various, often repeated, but not in response to any action of mine that I can determine) The lengths of the test loops that the SA1 setup uses can be determined from the signatures that are listed in the manual - strictly speaking, the loop lengths could be (signature length + n*65535) CLK cycles, but such cases would be obvious on the scope. The loop length also does not translate exactly into an elapsed time, because although most of the instructions executed in the loops that I have observed are single-cycle, there are a scattering of 2-cycle instructions as well. However, I would estimate that they would generate less than 1% difference. I only see one loop (sometimes) that is close (~72ms estimated from signature vs ~ 74ms on the scope). It is the inconsistent nature that is annoying me right now.

I have re-visited the bus data lines, and while (like any 3-state / passive / weak-pullup bus) they look pretty terrible, they don't have any indication of being flakey. The setup times are really slack, and the hold times (out of the ROM) are aided by the 1k series resistor in the /PSEN line. I have read out the ROM contents a huge number of times, always the same. I guess I could start tightening up (reducing) my /CE time until I start to see errors, but I'm not sure that would tell me much .  I've triple-checked the power supplies and the /RESET timing.

I get the feeling that it's not going to be fixed today.

@Kjelt - Here's a thought:

1.  It is possible the ROM in my 3468A is, in fact, ok, and the fault lies elsewhere.
2.  It is possible that the ROM in your instrument is dead, but everything else is ok.
3.  Then if I can get my EXPRO working and program a MCM68764 for you, then we may learn something.


 Edit: corrected 65535 value.

[Kjelt]

Hi Sailor,

good thoughts but can you wait a bit longer?
I have a friend who is trying to get hold of a working old school programmer in the "pinnball" scene, I am waiting for an answer on that.
If that is negative than I will hook the ROM up to an 8 bit STM8 and try to read out some locations to see if the ROM is totally dead.
If the ROM is dead I will have to think about next steps, one of which might be sending it to you for free since there has already been damage (visibly repaired) in the analogue section, so status is unknown, perhaps you can get one working with two carcasses.

[Sailor]

Hi Kjelt,

good thoughts but can you wait a bit longer?

I'm retired, remember I have all the time in the world - it's not enough, but it's a lot better than the alternative...

Ok, good luck with the programmer. I searched a bit on the web this afternoon for more info, later s/ware etc for my Expro. I found a couple of good sites, but particularly that the Expro-60 is essentially the same device as the HI-LO ALL03/ALL03A, which seems to have been very popular (HI-LO are still a major manufacturer, see http://www.hilosystems.com/). So if you ask around for that unit amongst your contacts, I expect that it will also be able to handle a MCM68764.

... one of which might be sending it to you for free since there has already been damage (visibly repaired) in the analogue section, so status is unknown, perhaps you can get one working with two carcasses.

Well, that is a very generous offer, thank you. But I sincerely hope that we can in fact resurrect both of our instruments. There is still a long way to go yet.

[Kjelt]

Hi Sailor,
ok thanks for the info will check that out. 

I still can't understand the ROM content is nowhere to be found on the net.
And that for an electronics hobbie-ist apparatus. Pinnball ROMs are everywhere.
I guess the problem we now face (that the ROM is a strange duckling in the family of ROMs) is the root cause the content are nowhere to be found. 

[dom0]

The 3478A is a very similar model and the ROM is available (check ko4bb). It's probably not really compatible (the 3478A has a GPIB controller while the 3468A has that other interface), but maybe good enough to reach self tests etc.

The ROM in the 3478A is a MOSTEK MK36A45J (64K)

[Sailor]

Thanks for reminding me of the 3478, dom0. I too had similar thoughts back at the beginning of all this last year, but after looking at the schematics I discarded the idea because of the considerable differences in implementation. I still believe that to be the case, with one exception; the main processor (there are two in the 3478) still has, as you noted, an 8kB ROM. Now that I am aware of the rather unique manner that must be employed by an 8039 to perform a memory check, I will carry out a disassembly of the 3478 ROM, believing that I can identify that section of code which must be essentially identical to the 3468. If I can do that, I can visually verify the integrity of that code in my 3468 dump and try to get my single-step processor running through that test.

Again, thanks for jogging my memory.

[MarkL]

...
The lengths of the test loops that the SA1 setup uses can be determined from the signatures that are listed in the manual - strictly speaking, the loop lengths could be (signature length + n*65535) CLK cycles, but such cases would be obvious on the scope.
...

You lost me.  How does that compute the loop time based on the signature values given in the manual?  The signature could be over any number of clocked bits; it's just a CRC.

"No go" on slowing down the CPU clock idea (post #20)?

[kcbrown]

Still no luck reading out the ROM. I asked two friends of mine that had old programmers with dos software but neither supported this or the motorola ROM 

Can't tell if what I'm going to say here is so simple and obvious that it's already been tried, but ...

Is http://pdf.datasheetarchive.com/datasheetsmain/Databooks-2/Book273-103.pdf the datasheet for the device?

If so, then it suggests that you can manually check the device, as it looks like /CE can be held low indefinitely while you examine the data lines.  So you'd flip /CE high, set the address lines to something to examine, then flip /CE low, then examine the data output lines.  As long as you keep /CE low, the data lines will reflect what's at the address you specified.   Then you just examine the data from random addresses and see if you ever get something other than FF on the data lines.

It wouldn't be fast, and it wouldn't be comprehensive, but according to the timing diagram, you'd most certainly meet the minimum timing requirements that way, by many orders of magnitude.      And if there's any reasonable amount of data on the chip, then doing that should yield some values other than FF.

[Sailor]

...
The lengths of the test loops that the SA1 setup uses can be determined from the signatures that are listed in the manual - strictly speaking, the loop lengths could be (signature length + n*65535) CLK cycles, but such cases would be obvious on the scope.
...

You lost me.  How does that compute the loop time based on the signature values given in the manual?  The signature could be over any number of clocked bits; it's just a CRC.

Yes, it's commonly called a CRC, but in more basic  terms it is simply the state of a maximal-length-feedback-shift-register after some particular number of clocks with a particular (non-zero) input bitstream. Put in zeros, and the SR never changes, the result at any and all times is zero. But if you input any other bitstream including all ones, you get a non-zero result. The key there is "including all ones", which is what you have when you use your SA to check the signature on the 5V rail (or other constant non-zero rail). Because the SR is a maximal length configuration, it will cycle through all possible values before repeating. It is trivial to duplicate the 5004A SR in software, then clock it with a constant '1' input until it matches the signature that HP put on the +5V rail (there is always a signature quoted for that). Hence you know the number of clock cycles that are in 1 loop of the SA test, hence you can form a very close estimate of the actual elapsed time that you should see on the scope. In the case of the 3468A which has a one-cycle instruction time of 2.5us, the maximum loop length without repeating a signature is ~164ms. It isn't catastrophic if the loop is longer than that, but error detection becomes compromised. A properly-designed FSR with more bits (such as for CRC32 etc) allows good detection over longer bitstreams (longer test loops).


No, I haven't slowed the clock yet Mark, but its a good idea ... just need more time ... I have no idea how I found time for work before retiring


EDIT: I didn't mention it above, but you naturally have to convert HP's crazy 'hexadecimal' signatures to 'real' numbers when comparing the residues.

[Kjelt]

Can't tell if what I'm going to say here is so simple and obvious that it's already been tried, but ...

No you are absolutely right but that is my last resort since it takes time to hook it up to a 8 bit microcontroller and it might damage the device accidentally if I would mess up.
I have one last try: a colleague that might be able to help me, our luck he is ill at the moment so I have to wait and see.

[kcbrown]

Can't tell if what I'm going to say here is so simple and obvious that it's already been tried, but ...

No you are absolutely right but that is my last resort since it takes time to hook it up to a 8 bit microcontroller and it might damage the device accidentally if I would mess up.

I don't know that I would necessarily go to the trouble of hooking it up to an 8 bit microcontroller.  I would hook it up to a simple set of op amps configured for unity gain (a 74HCT244 line driver chip should work too) and then drive one LED per output.  You'll be able to immediately tell what the data value is.  You can hook up a DIP switch to the address lines along with some pull-down resistors between the switch and the address inputs, and hook a push button switch to /CE with a pull-down resistor between it and /CE (so the default for the device would be to show the data).

I suppose that might be more trouble than hooking it up to an Arduino, though, but it would give you something to play around with directly that wouldn't involve coding or worrying about timing or any of that.

I have one last try: a colleague that might be able to help me, our luck he is ill at the moment so I have to wait and see.

Here's hoping you don't have a dead EPROM on your hands...

[MarkL]

Yes, it's commonly called a CRC, but in more basic  terms it is simply the state of a maximal-length-feedback-shift-register after some particular number of clocks with a particular (non-zero) input bitstream.
...

Ah, got it.  Clever observation on the all-ones case - thanks!


On a related thought, it should be straightforward to write a SW implementation of the signature analyzer for sigrok, and LAs with decoder APIs like Saleae.  There's no need to do it real-time as long as the LA can catch all the clock transitions between start and stop.  It would be a boon for folks fixing this old test gear without having to purchase a dedicated unit.

[MarkL]

On a related thought, it should be straightforward to write a SW implementation of the signature analyzer for sigrok, and LAs with decoder APIs like Saleae.  There's no need to do it real-time as long as the LA can catch all the clock transitions between start and stop.  It would be a boon for folks fixing this old test gear without having to purchase a dedicated unit.

I thought it would be interesting to model the signature analyzer hardware in C.  I already have a 5006A, so I'm probably not going to do anything more with a software implementation.

If anyone wants to use this code as a starter for sigrok or anything else, feel free to indulge.  Attached.

[dom0]

Funny, a while ago I tried the same thing but was unable to find the polynomial they used. Glad you did!

[Sailor]

@dom0      Earlier in this thread Mark provided this link   http://www.hparchive.com/hp_journals.htm   that reveals all about the 5004A. It's a good read

On a related thought, it should be straightforward to write a SW implementation of the signature analyzer for sigrok, and LAs with decoder APIs like Saleae.  There's no need to do it real-time as long as the LA can catch all the clock transitions between start and stop.  It would be a boon for folks fixing this old test gear without having to purchase a dedicated unit.

Indeed. Or, for those who like a separate instrument for each measurement, the 5004A could be duplicated inside a $5 CPLD or FPGA. It would cost more for the LED display and the signal buffers (Start, Stop, and DUT-signal) than for the real guts of it all    Maybe there is a real cheap FPGA demo board on ebay with a LED display...

[Sailor]

Well, there's good news, neutral news, and bad news.

The good news: Following dom0's prompting me on the 3478A ROM, I obtained a copy, disassembled it, and went looking for the memory test routines. As it turned out, the code in the '78 is much less obscure than in the '68 and within a few hours I had it figured out and wrote a Matlab script that validated the checksum calculation in the '78. The checksum arithmetic is slightly unusual insofar as the carry from a byte overflow is carried forward and added in with the next byte addition i.e. the carry is 'wrapped' to what is effectively the low byte of the total sum, instead of being carried to the next significant byte (if there had been one), or simply dropped, as it would be in a normal 8-bit checksum calculation.

The neutral news: Armed with the knowledge gained above, I dived back into the '68 code, and eventually sorted out how it accesses all of memory and computes the checksum (using the same strange carry operation).

The bad news: I ran my '68 ROM dump through my Matlab script and it fails    I went back to the dump and traced through in minute detail every line of code involved in the memory test, and there I found the first (and, I am sure, not the only) ROM error. There is a 'picked' bit in a CALL address which naturally sends it off into the weeds. I can see the correct destination code there at 0x0700, but the CALL instruction takes it to 0x0710, right in the middle of something else entirely.

Hmmm... my Matlab checksum computes a value of 0x89 (should be zero). Modifying the ROM file to have the correct CALL address  reduces the checksum to 0x79. While this can't be used to draw any specific conclusions, it does point to multiple bit errors as well as multiple occurrences.

[Kjelt]

Good digital detective work there. I heard from a colleague that these Mostek ROMs are failing in other devices as well.
Perhaps this is a good time to open a new topic warning all 3468A users for this forth coming disaster and hoping that one of those users can read out his/her correct ROM and share it.
It is no longer a question of IF but WHEN will it fail 

[dom0]

Eventually all floating-gate memories will fail. By the way, these MOSTEK PROMs are floating-gate ...? Or is it another issue entirely with these specific PROMs?

[Sailor]

EXCELLENT idea Kjelt . Perhaps you would like to initiate it? It will only take one willing person to probably save many others (and themselves, when the time comes).

Edit: Actually, it would be better if several copies were obtained, just in case there are errors in unused (ie. not commonly accessed) regions.

[MarkL]

Bummer on the checksum and multiple bit errors.  But a valiant effort!

Here's an idea.  If the bits are marginal, it may be possible to vary Vcc to see if the MK36000 will read correctly.  You could take it out of circuit so nothing else gets ruined, and maybe try 4.0V to 7.0V (absolute max).  Lookout for the higher voltages coming out of the data lines if you connect it to an Arduino to read it (use series resistors).

I recovered calibration data from a flaky EEPROM in a 2465 scope with this method.


I guess the reason there's no convenient images sitting around is that the ROM has to be unsoldered to read it.  Someone with appropriate soldering skills and a reader has to be willing to do it to their working meter.  (While being careful around the NVRAM and battery.)

There's two versions of the ROM, 1818-1753 and 1818-3123.  Hopefully there's no hardware dependencies tied to a specific version.

[Kjelt]

EXCELLENT idea Kjelt . Perhaps you would like to initiate it?

Done: forum/testgear/hp-3468a-owners-unite-a-storm-is-coming! (can't get the link to work)

[intabits]

... I will carry out a disassembly of the 3478 ROM, believing that I can identify that section of code which must be essentially identical to the 3468....

Did you get anywhere with that?
I've recently scored three 3468A's, and all are in great condition.
But the LCD displays on these (and 3457, 3478) are pretty crap IMHO, and I'm looking into hacking a better display onto them.
Trying to figure out how the display is driven by monitoring the signals to it would be quite a job, but I imagine working from the ROM code might be slightly easier.
Hence my question...