Fluke 8840A Faulty CPU

[essele]

I picked up a couple of faulty 8840A’s a little while ago and have just got around to having a quick look.

Both were completely blank screens, with one doing absolutely nothing, and the other clicking a relay fairly regularly.

Focusing on the first one I did a bit of prodding around and came to the conclusion that the CPU was faulty ... a quick swap with the second CPU and it all sprang into life and looks good.

So the main CPU is a Zilog Z0861108PSC and these seem available online from China at least, but a bit of googling shows that they have a 4K write-once prom, so I’m assuming I can’t just replace it?

There are some comments about potentially reading and re-writing the prom, but I can’t find anything that makes me think anyone has been successful.

Does anyone know if this is possible? Or a source for a properly programmed one?

Thanks.

On a side note, both units came with the AC option (which was a surprise), but both of them seem to drag the power rail down and cause the blank-screen relay clicking, I’m hoping it’s as simple as a shorted tantalum, but I’ll get to that later!

[bdunham7]

In a sane world your best source for a replacement Z8 CPU would be a parts unit.  I doubt they fail often.  However, as you may know--and I know from looking for parts for my 8842a--these go for stupid money.  A wrecked unit that looks like it fell out of one lorry only to be run over by another and was then scraped off the road by a vagrant goes for $50-75 USD here. 

I can't answer your question as to reading out and writing the PROM, but what did you test to determine the CPU was bad?  I had a similar problem with a different brand DMM and the "dead" ADC chip turned out to be an instability in the crystal oscillator, presumably caused by too high impedance of the crystal.  It is possible that I could have replaced the chip and the new one would shift things enough to start the oscillator, but it turned out simply replacing the crystal with a lower impedance "full-sized" AT cut model solved the problem entirely.  I just wonder if maybe you have something similar going on.  In my case, one the tests I did was to connect a 10M oscilloscope probe to a signal generator putting out the correct clock frequency sine wave  (8 MHz in your case) at 1V P-P or so and probing the 2 XTAL pins on the chip.  When I got the right one it started right up.  Just an idea to try.

[essele]

Thanks for the reply ... I initially followed the troubleshooting guide looking for display related signals on the various display chips but saw nothing.

Eventually I started looking at the CPU, I could see a valid clock, but no activity on any of the data or address lines, so it wasn’t even starting to try to read memory, so I then switched it and all was fine.

It has crossed my mind that it could have been not properly making contact with the socket, so I will try it again, but I suspect it’s dead.

[ignilux]

I have no idea if this will help you or not, but I have an 8840A that needed some TLC before earning a permanent place on my bench. Mine would be working perfectly fine for 15 minutes or so, then the screen would go blank and sometimes a relay would click. After some time of combing the forum, I found someone who had different erratic problems (I don't have the link saved unfortunately). Turns out that it's somewhat common for the solder joints on the main transformer to be cold / incomplete / cracked. I cleaned and redid all of the pins, and it's been rock solid ever since.

I'm not saying it's your problem, but it might be worth a shot before spending some cash on a new CPU.

[essele]

Thanks Ignilux, but the clicking relay issue is a separate one and that only happens when the AC module is plugged in, my guess is it's either a power supply not being up to the task (although they all check out ok) or a fault on the AC board. I do have two AC boards exhibiting exactly the same problem, but also the same problem in two different 8840A's .. so there is some investigation still to do. I will check out the transformer joints though, thanks.

The CPU issue (I think) is pretty clear cut ... absolutely nothing going on, replace the CPU and it all works. I do need to just stick the old one back just to make sure it wasn't a seating issue, but my money is definitely on a dead CPU.

[essele]

So a bit more investigation on the CPU...

The Z8611 has a 4K mask programmed ROM, so not re-programmable, so the only option using this specific device would be to grab one from an otherwise broken 8840A.

But, there are other options...

There is a Z8613 which is effectively a prototyping solution where it has a non-ROM version with a piggy-back socket for an EPROM.

There is also a 44pin version of the Z8611 which includes a ROMless pin which disables the ROM, so you could build something similar to the above.

There's the Z8681 which seems to be a romless version, so again you could build a small module that included some glue logic and an EPROM.

There is also a Z86E11 which has the EPROM built in ... although you need to jump through a few hoops to program it with a normal programmer.

Most of these seem very difficult to obtain ... the Z8681 and Z86E11 being the most available via eBay but at a bit of a premium, but still may be worth a punt. It's also not clear how easy it would be to read the contents from the original Z8611 rom to even be able to write it somewhere else.

More investigation needed...

[Paul Moir]

. It's also not clear how easy it would be to read the contents from the original Z8611 rom to even be able to write it somewhere else.

http://www.bitsavers.org/components/zilog/z8/1983_Z8_Microcomputer_Technical_Manual.pdf
Ch 8 pg 4 talks about the test mode which will allow you to execute your own code on an external ROM.  You can use that to read out the internal ROM.  Still a bit of work.

[bdunham7]

So, not to hijack a thread, but I was looking around for a parts 8840a thinking the OP and I could share--I would like a VFD, handle and maybe some bits--when I ran across this unknown (to me) option.  Anyone know what it is?

[essele]

@Paul -- thanks for the info, that's useful ... sounds like quite a lot of work, but may be fun.

@bdunham7 -- one of my units has that "option" ... I'm not sure it really is an option, I think it just takes some of the power and ground lines (that would normally feed the GPIB board) out to that connector on the back ... not sure what it's for, I had assumed it was really just a glorified blanking plate.

So I've done a bit more experimenting ... the CPU was definitely dead, swapping them around gives entirely consistent results.

The fact that both the AC boards caused the relay clicking issue concerned me, so I just jumpered the 'ac sense' pin to simulate the board being installed and I got the same behaviour ... further digging showed that it's actually the watchdog reset from the A/D which triggers if there is no activity on CS7. So at this point I'm a bit confused as CS7 is driven by U208 which is obviously fine when the AC board isn't installed... and the input for U208 is directly from the CPU, so it almost feels like a firmware issue. I might try reading the EPROM to see if I get consistent results (I think the official firmware is around somewhere as well.)

The second unit has a different behaviour (when I put the good CPU in it) ... but I haven't checked power supplies or anything yet. So I'll probably want to do a bit more digging before considering breaking for parts.

EDIT: I pulled both ROMs and checked them, the first looked OK (version 2.5, checksum 0x0006 0x6c48) although I have nothing to compare it with and can only find v2.3 anywhere online. Does anyone have a v2.5 prom they could dump?

The second one was garbage. When I put the first EPROM into the second unit it was fine, but had the same issue with the AC board, which makes me think it's still a firmware issue as it's unlikely that both units (and two AC boards) have the same hardware fault ... although I only have the one 'working' CPU, so that could also be at fault.

[xwarp]

I believe I might have 1 or 2 8840 boards in storage. I'll try to look this weekend. If I do, I'll let you know.

[essele]

Looking at the various CPU options I'm finding it really difficult to understand how you would attach an external PROM to replace the internal one without using an extra address line ... I'm sure it's possible as I've found a few comments about it, but I just can't seem to get my head around it.

So, I'm liking the Z86E40 ... it seems to be a modern version and is reasonably priced and available (Mouser and Digikey) it has a different pinout, and a few more capabilities, but it seems to be backwards compatible from a register perspective, and it has a fairly standard method for programming once you translate the pins, therefore using it in a PLCC or LQFP format you could probably build a simple board that includes the pinout for programming and then use a normal TL866 type programmer.

I'll look at this in some more detail once I get a bit more time.

[essele]

You only seem to be able to get the PLCC or DIP40 version of the Z86E40, so I've pulled together a couple of board designs based on the PLCC44, one is the actual board that would go into the 8840A and the second is the one you'd use to program it (the schematic is mostly taken from the Z86E40 data sheet.)

They were both a real pain to route, but I think they are ok.

I'm just going to check a few things (like will it actually fit in the 8840A) and go through the data sheet in a bit more detail to make sure that it stands a chance of working.

[Kleinstein]

For such an adapter board I would also include a decoupling capacitor close to the chip. One can still not populate it, but it can help to have the option.

[essele]

Thanks Kleinstein ... I've added a decoupling cap as close to the socket as I could sensibly get it.

The boards are being made now, so hopefully I should have then in about a week.

[essele]

I've just found an old 8840A/AF which also wasn't working ... and I've learnt the hard way that the bloody newer TL866II Plus doesn't actually have the capability to burn older EPROMS requiring >18V, so I had to buy a new programmer. Grrrr.

So I now have two different "working" CPU's ... one from the second 8840A and one from the 8840A/AF.

The prom from the AF (v2.5) matched one I found online, the label EPROM sticker was floating around in the device, so I assumed it was not going to work, but it seemed fine (I've burnt a new copy anyway.)

I've also found two different v2.3 images online, including one with a matching image for the Z8.

The v2.3 images didn't work with either CPU ... but that's to be expected as I understand you need a match between Z8 firmware and the EPROM.

The 8840A/AF cpu in the first 8840A didn't work with the v2.5 original image, however it did work with the newly burnt v2.5 which matched the one actually in the 8840A/AF ... which was strange since that combination didn't work in the AF, so that's either a chip seating problem, or there is another issue with that unit (one for another day.)

So now I have one complete 8840A, with a working RMS board, and it seems to be really nicely calibrated.

The second unit now has the prior "working" CPU with the original v2.5 image and it's still showing the problem with the RMS board ... so I'm no nearer to really understanding this, it could still be the CPU or the PROM since they are paired.

And I have the 8840A/AF which is now missing a CPU and PROM.

So ... I'm now fairly dependent on my adapter and programming boards. I have the v2.3 paired versions which I'm hoping I can get onto the Z8. The boards are due to arrive on Friday, so I can see the weekend being fun ;-)

The other option is to use the 'test mode' that Paul suggested to see if I can read the image from the working CPU I have, but that's going to mean rigging up a test bed with a clock, an octal latch for the address/data demultiplex, and writing some code to read the ROM and spit it out the serial port ... sounds like a great project, but a real time burner!

[essele]

Some slight progress... I’ve managed to find a disassembler for the Z8 (surprisingly hard to find a free one, finally found one as part of MAME, unidasm) and it’s really clear why the CPU code and prom code need to match ... the prom is just an extension of the CPU code, so it’s effectively a single 8K image. So even a minor difference won’t work as the location of subroutines will be different.

My boards and components arrived (very impressed with JLCPCB again, and this was my first with KiCad!) ... although the programmer doesn’t appear to work!

Just trying read I’m getting an overcurrent error if I use the TL866ii plus (set to a 13v Vpp) and if I use a GQ-4X then I get inconsistent results that aren’t all 0xFF (and it’s the same without the external 12.5v supply, so it doesn’t look like it’s latching into EPROM mode.)

I need to double check all the programming voltages and then start looking at the timings, but re-reading the data sheet has worried me as there are some errors and inconsistencies in it.

The other issue is that the Z86E40 doesn’t have a serial port (it has two comparators instead), this seems to be only used for the GPIB card, so that wouldn’t be a viable option with this solution, even if I could get it to program.

[TheDefpom]

FYI Some time ago I received a faulty 8840A / 8842A unit and found it had the WRONG AC board in it, there is a connection difference between the two units, BUT the same AC board can indeed be used in both units, you just have to modify the interconnect wiring a little bit.

I will see if I can dig that info up for you, I did note it down somewhere for my future reference, it might have even been in one of my repair videos.

[TheDefpom]

Here you go, I found it.

[essele]

Thanks Defpom - that is really interesting.

That difference is very relevant since it also impacts one of the outputs of U208 which would be effectively shorted to GND when it shouldn't be, which could well be impacting CS7 and the associated watchdog.

I have got three AC boards, one of which (the one from the AF) is fairly different looking to the other two so I will check the out.

I'm assuming that pin 1 and 8 is also just swapped on the motherboard side (because of U208) so it's likely to be a pure hardware change and not a software related issue ... which doesn't explain why swapping CPU and PROM fixed it ... which probably means it's not my actual issue, but there are enough similarities that it definitely needs to be checked.

Thanks.

BTW ... I am losing the will to live with the Z86E40 ... will spend some more time this weekend, but I'm not hopeful about even being able to program it successfully.

UPDATE: I checked all three and they are all the same, the boards match the first diagram (pin 1 connected to U803 pin 11) and the motherboards all have pin 8 directly connected to the CPU. So they would all seem to be compatible. I have now given up on the Z86E40, I have decided I hate Zilog, and I'm looking at the feasibility of a radical approach! More later.

[essele]

Further info on my radical approach ... I'm going to try sticking in a PSoC4 running a kind of Z8 emulator!

Initially I was considering a pure Z8 instruction emulator, however I don't think the performance will be there, the PSoC is 48MHz vs. the Z8 at 8MHz and the arm is pretty efficient, but for full emulation I don't think it's enough headroom to get close to native speed given the emulation complexity of some of the instructions that the Z8 handles in a very few clock cycles. [I'm not sure that performance is a particular issue in this case, so may be something to experiment with later.]

So option 2 is to re-spin the firmware and effectively translate it into C with probably some assembly if needed, although the compiler will probably be better at optimising than I would be.

I have written a simple disassembler in Perl ... stage 1 was to completely match the output of the MAME disassembler which is done (with the exception of the indexed LD instructions for which the datasheet is really vague and the MAME one seems to disagree with ... but thankfully it's not a problem.)

Stage 2 was to update the disassember to actually follow the code paths so that I could work out which bits of the firmware were code and which were data (which is the reason why the indexed LD isn't a problem!) -- this is also done.

The next step here is to update it again to isolate truly independent subroutines (i.e. ones that aren't jumped into by something else) so that they can be pulled out as separate functions, and then to start looking at detecting reads and writes to the control registers. The actual control registers look to be simple, RP is only set to 0xF0 in one place and is then followed by a load of RP relative code, the rest of the firmware uses a fully qualified read or write (for want of a better phrase.) So I'm working on having the disassembler identify RP relative access that can be fully qualified because no other code path gets in between the RP set and the access. The port access reads/writes are going to be a little more challenging and unfortunately some might need to be checked at run-time.

There is a minor issue in the keyboard interrupt code since this uses a jump table in the firmware, so I think this is probably going to have to be manually re-written in C, although I want to try to avoid this if I can so the code translation is as automated as possible to cope easily with different versions.

Other than that, from a software perspective, I think this is entirely doable. I would like to get my hands on other versions of the actual Z8 bit of the firmware.

Hardware wise ... I've looked at the PSoC capability of driving the "external bus" using pure software, and whilst I think it might work, it's a bit fraught, it's at the limits of the performance of the device (using direct register writes, none of this API rubbish), interrupts would probably need to be disabled for most of the time, and it just feels wrong.

I've put together a hardware bus component using verilog which is an approximation of the bus access process for both read and writes, mostly to see if it would fit within the available logic and it seems fine (with a fair amount of headroom), so it feels like that's the way to go. The good thing about the PSoC is that the same board could easily use the hardware or software option, and in fact reconfiguring the ports to not be address/data bus can be achieved through software so it would be possible to emulate that as well (although not needed for the 8840, other than a test mode I've found in the firmware.)

The clock is an interesting point ... the IMO on the PSoC isn't as accurate at the crystal in the 8840, which may or may not be a problem. My plan was to use the IMO to generate the 8MHz clock internally and output it on XTAL2 so it can be used by the ADC (leaving XTAL1 unconnected.) I'm not convinced timing is critical (it's not an integrating ADC as far as I can tell) so this may be fine. There are three other alternatives ... (1) an external crystal on the board, (2) an external WCO to trim against, or (3) use the 8840's 8MHz crystal directly ... I think I can put together a board where all of these are an option, I just need to make sure it doesn't screw up the routing as some of the clock inputs are right in the middle of a contiguous port on the device I'm considering.

Reset is another interesting consideration, if you use a normal pin for reset input you can choose to ignore the watchdog reset in the device which will simplify debugging.

So next step on the hardware is to put together a board, I think I can squeeze a TQFP64 in between the DIP40. Once I have a board then I can start debugging in a live unit.

Yes ... I know I'm mad.

[coromonadalix]

Im "mad"ly impressed by your tought process

I hope it will work for you, i would like to have this kind of knowledge,  i have a crazy idea for a new controller board ( arduino based / mega 2560 ) for an meter Ie: keithley 196 or an tektronix dm5120, the analog board is controlled by shift registers and the analog board values are read by somekind of a pwm signal ...

[fixitanonymous354]

Hi i have recently acquired an 8842A with the Z8613RS and have dumped the 2732 roms for the CPU and IEEE board using an Enhanced Willem.
I had to use an VCC jumper fix described on the Willem forums to get the Willem to read the ROMS but the U222 ROM matches to whats available on xDevs so i think the dumps are reliable.

U202 is rom on top of main CPU
U901 is rom on the GPIB board
U222 was the same as available on xDevs

[essele]

Thanks for these ... I’ll have a look at them in the next couple of days ... I believe there are quite a few differences between the 8840a and the 8842a, but I can’t see a reason why the same approach couldn’t be adopted.

[essele]

Making some progress...

First stab at a PSoC based board ... only done some very simple testing so far, it powers up, can be seen and programmed by the MiniProg3, and I can generate an 8Mhz clock, unfortunately the pins for the external crystal don't allow routing, so if the native 8840A crystal doesn't work I'm stuck with a PWM generated clock, but that all seems ok based on this first test.

Step 2 will be putting it on some breadboard with a crystal, then step 3 will be in the 8840A. Hopefully the native crystal will be fine. Not sure if I'll be able to power it from the MiniProg and leave the 8840 powered off for now, I suspect not.

Oh ... and yes, I will populate the decoupling caps - I was just keen to see if the MiniProg would see it!

UPDATE: just tried it in some breadboard with a random 8Mhz external crystal in the 8840A configuration (i.e. no caps, and 10M in parallel) works fine as a source for the PSoC, I can generate a much more accurate 1Mhz test signal from the ECO rather than the IMO, however pin 2 doesn't swing much (looks like 1V max) so I am doubtful if this will be sufficient to drive the ADC, but I'll try it over the weekend as it may be different with the particular crystal, or may well be sufficient.

FURTHER UPDATE: doesn't seem to work from the onboard crystal, it's oscillates but only at just under 1V, I can see the 8MHz signal getting to the ADC, but no sign of the 1MHz output. Programming whilst installed works fine, and a quick test of the 8MHz PWM output seems to work, I see a 1MHz output from the ADC and that reaches the keyboard/screen controller. So this should be sufficient to start working on the bus access bit in Verilog. I should be able to get a test program to read the EPROM or maybe even attempt to update the screen. I may consider a separate crystal for the next version, although I'm still not sure how important accuracy (or matching the onboard one) is.

[essele]

Well it's getting a bit exciting ... I've now got a working bus read capability, and I can read bytes from the U222 EPROM using my Verilog bus access module, this should also work for reading from the ADC, the Cal Memory, and the keyboard/display controller (assuming I've got the timing right.)

Next step is the write side of it .. testing that is going to be slightly harder, I guess I'm going to need to get the display to output something!

One slight worry at this stage ... because the XTAL2 pin (chosen because of the potential use of the external crystal) is not routable inside the PSoC then my only output option for an 8MHz clock is a PWM. This is then not synced with the UDB 8MHz clock that's used for the read/write logic ... not sure if it's really a problem, but it feels like something I should fix. I may just bodge another pin over to it for now so I can directly output a clock.

[essele]

And bus writing now also works :-) ... I can initialise and write to the display, and once I stopped testing with an 8840A that seems to have a broken display everything sprang nicely into life -- so it looks like this is really going to be possible. The timing all seems ok, at least with the keyboard and display controller and the EPROM, it may be a little more challenging with the ADC, I'm not sure if the reads and writes are clock dependent.

I love these PSoC devices .. that extra capability to do some clever stuff at the hardware level really makes a big difference. With my current implementation I'm at 63% UDB usage, but that's with zero optimisation, and there are quite a few things I could do if needed. It's looking like everything else can be done with software, so this shouldn't be required.

Now to focus on the translation of the firmware, there do seem to be a few register indirect accesses to firmware addresses presumably for lookup tables or preset data, so these will take a bit of manual effort ... the rest I'm hoping can be fully automated, and then I can worry about tidying later.

[essele]

A quick update...

I've spent quite a lot of time on automated code-path discovery so I can track RP, tests-followed-by-conditional-jumps etc, all with the aim of being able to automate reasonably efficient code generation, however I'm going to have to put that on hold for a bit ... there are quite a few nasties in the code that mean I need to rethink it slightly ... things like popping an extra return address off of the stack so you don't actually return from the CALL you think you should, and pushing FLAGS so you can use an IRQ handler (and IRET) as a normal CALL.

I still think this is the best approach, but I need some time to work out how best to code it ... my current solution doesn't revisit already travelled paths, which then makes it virtually impossible to properly track stack usage.

So, instead I've built a basic CPU emulator for the Z8, which should hopefully be good enough to prove the whole principle. The basic emulator is done, I'm now working on translating the register reads/writes into PSoC related code to simulate the same behaviour, then I'll need to figure out the interrupt side of things. It wasn't until I was well into this that I discovered there is also an emulator in MAME ... that was very useful in checking my logic. The MAME one isn't really focused on speed, so I've had to approach things a little differently.

I've discovered a few things that need some work...

1. The power line frequency is determined by counting how long P20 stays low, this is a tight loop and therefore dependent on execution frequency, it would actually work for me as is (since 50Hz is the slowest), however I'll need to think about how to address this for 60Hz and 400Hz line frequencies. The simplest way would be to adjust the compares in the firmware, but it will be interesting to see how far off the performance is by default (I can do an isolated test for this) and I'm not really sure how I can test 60Hz/400Hz ... maybe I can test outside of the unit and inject a signal.

2. Timer0 is used as the baud rate generator for the UART for the GPIB board. This is only ever used at a fixed 31250 baud so that can simply be hardcoded into the UART for now. It's relatively easy to translate the prescaler values into PSoC baud rates, so I could get a bit more flexible (not sure if the 8842 uses a different rate?)

3. Timer1 is used to set the ADC sampling rate, these vary depending on line frequency and slow/med/fast speed setting. So I've added a PSoC PWM module to output the timer and can translate the prescaler/initial-value settings into PSoC friendly calls.

4. Most annoyingly it seems that the ADC reads are all done using 'extended bus timing', this is a slower version of the bus interface that adds cycles to allow for slower devices. Interestingly the datasheet says it adds two cycles to the DS phase, however the timing diagram only shows one. (Did nobody ever proof read these things? There are loads of errors!) I am going to have to revisit my Verilog component to cater for this, at the moment I don't have a free control bit to switch modes, but I have a way to work around that.

5. On the interrupts ... we have keyboard, ADC, serial-in, ADC-timer ... two aren't used - the other timer (serial baud) and serial output. Serial output appears to be polled. I don't think there are any real issues here, I just need to figure out how to translate the whole priority side of things and make sure the behaviour of the various registers is the same.

Lee.

[TheDefpom]

I am genuinely impressed by your project, and I thought I was doing well decoding the ADC a few years ago in one of my first YouTube videos whilst fault checking a 8842A

[essele]

Thanks DefPom ... I'm actually really enjoying this, it's a throwback to some assembly stuff I did when I was 16 (and that was a very long time ago!)

I've just done the first performance tests and things are actually looking reasonable. I've recreated the code that does the power line frequency checks, so it's pretty simple and doesn't really involve any complex instructions, so optimising further may well be a bit of a challenge. However...

As I mentioned above the code goes into a tight loop incrementing a register pair until the power line signal changes, so I'm assuming this is timing the 'off-time' of the  'freq ref' line from the power supply, so the number increases as the frequency decreases.

The firmware looks for the following (if I'm reading it correctly):

1. If it's less than 0x200, then we assume 400Hz supply.
2. If it's more than 0x470, then we assume 50Hz supply ... I assume this would actually be the 55Hz point, well that's what I would use.
3. Otherwise it's 60Hz.

Bearing in mind I'm on a 50Hz supply at the moment, I can only currently read the 50Hz value, but I've extrapolated based on that, and I get the following:

For 50Hz I get a value of 0x578, with optimise for speed, I get 0x5c8.
For 60Hz that extrapolates to 0x48e, and 0x4d1 with optimisation ... so this would miss and be assumed at 50Hz.
For 400Hz it would be 0xAF, or 0xB9 with optimisation.

So it's actually pretty close ... obviously you would want to be well inside the values to have some margin to play with, but whilst it means that this bit may not function it shows me that the emulator is actually running at a reasonable speed. I may well have to resort to cycle counting to have a better estimate of what the actual Z8 values would work out to be ... I can then look to see if I can further optimise .. but that's a job for later.

The other thing is that it proves that my external port access to port20 is working ... and that was just two lines of code!

EDIT: I'm a muppet ... I've just been trying to work out the actual cycle count and realised that actually the emulator is running faster than the original Z8 ... it's bloody obvious because my numbers are bigger than the expected ones, therefore I manage to go around the loop a few more times! That's really good news, it's much easier to slow it down ;-).

So the Z8 manages to go round this loop in 128 clock cycles (8Mhz), therefore it can do it 62500 times a second. I'm managing 70000 and 74000 depending of whether I'm optimised for speed! So it looks like I'm between 12% and 18% faster ... these are simple instructions though, I'm sure once we're in to some of the maths ones with loads of flags this won't hold.

[essele]

I've now implemented the extended bus timing (but only for reads, since it's only needed for the ADC reads), the datasheet was actually correct, I was mixing clock cycles, machine cycles and the various other cycles they seems to have made up for the Z8.

I can read the 5 values from the ADC and they all come back and seem to be 6 bit values which is a good sign ... the actual values are a bit questionable, but I'm currently not reading them straight after the interrupt, so they could be a mix of samples or values mid-sample. I've got a plan for the interrupt mechanism and I'll use this as the first test.

I was looking again at the performance numbers ... actually I think I had misunderstood the performance of the Z8 and it's four times slower than I had thought...

The external clock (8MHz) is divided by 2 to give you the internal clock (obviously now 4Mhz), then the instruction 'cycle counts' seem to be "timing states" which pretty much seem to take 2 clock cycles each anyway (although some of the timing diagrams show it as 3.) So that actually means that an instruction taking 10 cycles on the Z8 is really 40 cycles at 8Mhz, which then gives us 240 cycles on the 48Mhz ARM to emulate the same behaviour.

This is born out by the tight loop for power line frequency detecting ... that was a 32 'cycle' loop (INCW, TM, JR), but actually working it through assuming I was right about my 55Hz cut-off we had 62500 iterations per second, which equates to 128 cycles at 8Mhz per iteration, so for 32 'cycles' on the Z8 that means it's effectively divide-by-4. So it's really a 2MHz CPU.

I've figured out a nice way of handling interrupts that doesn't require me to check something each cycle, and I think I've worked out how to map the various interrupt request, mask, and status lines.

I still need to work out how to deal with the Z8 reset line ... it's a normal GPIO for the PSoC, but since there's the potential for getting stuck with interrupts disabled I don't really want to handle it as a normal IRQ ... I think the watchdog reset might have potential here. I will also experiment with using another pin wired directly to the PSoC reset line, that way taking that pin low should reset the device, I can then optionally internally connect that pin to the Z8 reset line to give a configurable reset (experiments to follow -- not sure how often this is actually used during normal operation, presumably it's just an error condition.)

So next steps...

1. Interrupt mechanism + mapping interrupt registers.
2. Finish off the port configuration registers (inc. serial and timer configs.)
3. A debug exception mechanism for handling illegal instructions and register configs I don't deal with (external stack for example.)
4. Mechanism for timing instructions to see how close to the Z8 we can get.

Then I should be on to actual firmware testing -- exciting.

If it works then I think it will be worth building a board to try to extract the internal firmware from the Z8 so that we can get at the different versions, I only have v2.3 for the 8840, and I've got a working Z8 and EPROM that seems to be v2.5 that I'd love to extract.

[jaromir]

Great work. I'm really impressed by your progress so far.
Is there a chance you could release your work to public? I'm pretty sure that apart from being useful to folks with broken meters, it could also serve as source of knowledge to those ones being interested in how things work.

[essele]

Hi Jaromir,

Absolutely -- I fully intend to release this all once I get it working. I'm starting to put things into github, and I'll switch it to public once it's in a usable state.

Lee.

[essele]

Huge Progress...

- Implemented an interrupt mechanism (although more on this later)
- Finished off the port control stuff, and all the register read/write translation
- Added a debug mechanism to trap some stuff that shouldn't happen
- Fixed decrement-and-jump-if-not-zero instruction so it wan't increment-and-jump-if-zero (I must have been having a bad day)
- Fixed a few other instruction issues
- Banged my head against a brick wall for quite a while

... and ...

It works ...  mostly. It boots up, will accurately read DCV, DCA and Ohms, autorange works, front/rear selection works, it detects the lack of AC board (haven't tried that yet), the self tests will run (and pass) ... the calibration looks ok, so I suspect it's properly reading the existing cal ram.

How pleased am I!!!

There's still some work to do ... to get this far I've had to do some stuff in the interrupt handling that I shouldn't really have done, so I need to understand that a bit more, also some of the small buttons on the right cause an exception where it's trying to execute code at an address that doesn't exist. Then there's the serial stuff to check for the GPIB card.

I don't think the interrupts are working properly ... I don't see any timer interrupts at all, although that doesn't stop the basic functionality, the rate button doesn't do anything at the moment, so I suspect it might be related, and the execution of dodgy code does highlight I've got something else wrong somewhere, so once I find that other things may start working ok.

QUICK UPDATE:  I've fixed the bad code issue (was a mistake in the register-pair call code) so now all of the small buttons seem to work, I can change the rate, selected external trigger etc.

[TheDefpom]

nice work, well done.

[Johnny10]

Essele your talents are showing!

[coromonadalix]

Wow  im totally impressed by your work 

[essele]

Thanks for the compliments! I am feeling quite pleased with myself.

Anyway ... I've reworked the interrupt code and it seems a lot better, all of the buttons are more responsive than they were. I've tested the AC board and that all works perfectly ... which is good, because that's partly where this all started ;-)

I've done some side-by-side testing with a standard Z8 based unit and I can't see any difference.

Just the GPIB board (and hence the serial connectivity) to test now ... I need to get my USB GPIB adapter working on a bit of normal kit first so I know what good looks like. Oh, and I still should probably do something with the reset input.

If anyone feels like donating an 8842 with a faulty CPU , I'd love to get that working as well ... it may just work (with appropriate firmware) but there may be features it uses that I haven't implemented. (Just make sure the screen is ok, I wasted quite a few hours on an 8840 that turned out to have a broken VFD.)

[coromonadalix]

If your substitue cpu work,  can you add an serial port instead of the gpib ?? or an usb "rs232" port too ??

Maybe a mix of this project ??
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

thks


Would be nice to have a 8842 donnor ...

[essele]

Hi Coromonadalix,

The CPU communicates with the GPIB card using some kind of serial protocol, so there's no reason I can see why you couldn't develop a different card that provides an external serial or USB port if you wanted to. You would just need to reverse engineer the protocol which I imagine could be done fairly easily by sending individual GPIB commands and then tracking what internal serial comms happens.

You could also hack the firmware to send/receive serial data straight out of the unit, or you could add extra routines in the PSoC to so something similar, but either way that would require a lot more firmware understanding to know where to pull the data from and how to trigger state changes. It's definitely doable, but not something I'm planning on looking at.

The other interesting thing that could be done is to build a completely different interface to the display, this display output code is really easily found in the firmware and could actually be trapped quite simply in the PSoC (it's just writes to the keyboard/display controller) ... so creating something that would drive an LCD for example would be reasonably straightforward. Since I have a machine with a broken VFD I might consider this once I've got everything else working.

[coromonadalix]

Hi  essele

You have some 3.2" oled  who where used to convert an hp34401a vfd ...   made by qu1ck

https://www.eevblog.com/forum/repair/hp-34401a-dmm-with-leaking-segments/msg1572961/#msg1572961

[essele]

Further quick update...

I've been working on the GPIB side of things ... spent quite a bit of time trying to understand why I wasn't seeing any serial response from the card at the PSoC, despite being able to see the data at the card ... turned out to be an almost invisible solder bridge between the serial-in pin and GND.  It's amazing the things that burn hours!

I've done some further work on the serial emulation and there is some progress, but it's not quite right yet.

The card is detected, and I can press the local button and I get presented with the GPIB address, so there is a level of working comms. However I see some spurious behaviour which looks like the unit is responding to random/corrupted commands (although it appears repeatable on each power cycle) ... my guess at this point is either reception problems due to framing/baud mismatches, or problems with IRQ handling.

Timing looks ok on the scope, and matches the timing diagrams in the manual.

The job for the weekend will be to add some framing/overflow/underrun detection to rule that in or out, and then to re-think the way I'm doing serial interrupt handling. Fingers crossed this will all be done in the next few days.

[jaromir]

Great job, great post! Keep them coming, please.

[essele]

More battling with the serial side ... I've checked the GPIB board in a standard 8840 and it works fine, I've check the PSoC CPU in the working 8840 and that behaves exactly the same way, so I've eliminated any issues with the board or other parts of the 8840.

I was slightly worried about the timing accuracy (as per comments way back), so I tried a few different ways of generating the clock, but with no difference to behaviour, even with quite a major variation in frequency, so it doesn't seem to be that.

I've now got a protocol analyser (Analog Discovery) hooked up and I've looked at the serial rx/tx lines for both the working unit and the PSoC based one from power up ... an example of a small section (where there is a difference) is shown in the photo, the top sequence is the working one.



The data is pretty much identical, but what changes quite dramatically is the timing. I did implement one fix which actually slows down multiple byte transmissions, because the PSoC was much quicker, but that didn't change anything.

So I think there are a couple of avenues to still explore:

1. The strange lack of timer IRQ's ... there is a full ISR in the firmware but I never get a valid IRQ trigger for it. I need to recheck this, since it's doesn't feel right to me. I'm not convinced it's this problem though since that would more likely result in a lack of something happening, rather than something happening too quickly.
2. IRQ handling again (although I have redone this a few times now), but it could be a prioritisation thing where I'm allowing the receive IRQ when I shouldn't be, or a window with enabled interrupts that shouldn't be there. Again I don't think that's the case, but I will go through it again.

This has been a really interesting journey into lots of different things ... but I do want it to end soon ;-)

[essele]

I'm not sure I'm making much progress on this.

I've reworked the IRQ system yet again ... and I see exactly the same behaviour whichever way I implement them, so I'm fairly sure that the overall mechanism isn't contributing to the problem.

The timer ISR looks to be fine ... my interpretation of the code is that the ADC irq drops through into the timer ISR when needed (which makes sense given it's the timer that triggers the ADC), so the timer ISR is only likely to be called as an interrupt in specific circumstances, perhaps when external triggers are used?

I have three things to follow-up on now:

1. The two pin based IRQ's (ADC and Keyboard) have slightly different behaviour to the Z8 version because they share an interrupt on the PSoC, so I'll rework them to use DSI routing and individual interrupts. I really don't think this is the issue.

2. The serial system is slightly different because of the FIFO and the way you clear the IRQ, so I'm actually considering building a UART (at least the RX side) in the digital logic to more closely resemble the Z8 version. Again I don't think this is the issue as I think I understand the way the code interacts and I can't see how it would cause a problem.

3. The other option is that I still have a misbehaving instruction which is only used (or only a problem) in the serial code. So I'll go through the implementation again checking everything, but it does work for short period of time, which makes it feel more like a timing/IRQ issue than an instruction problem.

EDIT:  And potentially there is: 4. From re-reading the Z8 manual it seems that the interrupt mask register can't be updated unless the DI instruction has been used to disable interrupts, you can't simply write a 0 to bit 7, my implementation doesn't enforce that. Then the manual isn't clear if writing a 1 to bit 7 is ok to enable, or you have to use EI. There is a chance the firmware relies on these controls, so that's a fairly easy combination of things to test as well.

Lee.

[essele]

So I’ve implemented independent IRQs for the keyboard and ADC, no major change in behaviour, but it feels better as it’s more closely aligned to the Z8 approach.

I’ve built a UART, well actually a UAR, in Verilog ... surprisingly easy if you skip most of the error conditions ... and it seems to work ok and more closely mirrors the Z8 approach. Again no significant change. (As an aside, I never thought i’d be building UARTs in Verilog ... how cool is that???)

I’ve also rechecked all the instructions, put a load more debug in to check for strange things, and tried all the variations of EI and DI control, and nothing seems to impact the behaviour.

However ... it’s now very consistent and repeatable, so I think some of these changes have helped resolve issues.

I have then also started looking at the timer implementation since I was a bit too quick to dismiss some of the intricacies ... I’ve redone this with a proper down-counter with correct behaviour at re-load (which took some more Verilog and a reversion to the old UART for space reasons for now.)

The upshot is that I now have a rock solid external trigger (with GPIB board) setup, but there are still challenges with local trigger if the GPIB board is connected ... I’m fairly sure it’s timer related, so some more work is needed - but it’s time for a weekend of well earned gin.

Lee.

BTW - I’m intending to publish the git repository on Tuesday, maybe others can help get this over the line.

[essele]

Ok .. I've had enough for a while on this, I just can't get over this last issue.

I've even implemented a more efficient serial receiver using a datapath component so that I can fit it all in to the programmable logic, but no change in behaviour, so I think the serial side is actually a red herring (especially given the external trigger, which is over serial, seems to work perfectly.).

For the time being I've just dumped all of the code, schematic, and pcb stuff into GitHub ... I haven't tidied it much, so there are lots of remnants of debugging in there and still quite a few things to tidy.

https://github.com/essele/Fluke_Z8_Emulator

If anyone feels like getting stuck in then please let me know.

[SilverSolder]

I noticed this sticker on your meter:




 

[coromonadalix]

yep  broken sticker  loll

Keep up the good work,  hope you find the little buggar ..

[essele]

Ok ... I’ve just come back to this as I need to sort out the three broken 8840A’s that I now have, all with CPU issues.

So now I’ve implemented a firmware ‘patching’ mechanism by using an illegal instruction as a special emulator call and then patching this into the firmware in some key places, this makes it easier to do the following:

1. Replace the line freq code with native code to ensure accuracy.
2. Replace the main delay loop subroutine with a more accurate one.
3. Put test code in at specific points to better understand what is going on.

I also redid the interrupt code yet again, and spent ages decoding serial again ... both of these to no avail.

However, using (3) above, I was looking more closely at the timer, and for some reason I completely missed the fact that it sometimes configures itself to use an external clock input (the ADC signal) rather than the internal clock ... this seems to be when using external triggers. My emulator doesn’t currently support that and it just continues to run with the internal clock.

So my theory now is that, whenever you have a GPIB card, trigger signals are generated by that instead of the normal clock, and hence this then uses the timer differently. So I think with my current implementation the GPIB triggers and the timer triggers are interfering with each other ... which fits quite well with what I’m seeing.

So, I’ve reworked the timer using two cascaded TCPWM modules and I should be able to remove my custom verilog hack as a result. I just need to add support for the external clock input (which looks straightforward) and then I have a good level of confidence I might have cracked it.

Hopefully will update at the weekend...

[essele]

I've finally cracked it!

After much probing and reworking, I've managed to get it working...



I reworked the timer code, I put in "patches" to accelerate the ADC reads and the display updates, so they are handled by the PSoC and not emulated, I put in a patch to more accurately handle delays, I even put in a patch to cache the cal EEPROM to speed up that access. I also used another timer to delay the serial send and receive. None of that worked.

So, I redid the interrupt code again (probably for the 10th time now!) and now have it so that it runs with PSoC IRQ's enabled, the handlers just set an appropriate flag and then the main execution loop checks to see if an IRQ has occurred and causes the Z8 ISR to run.

That didn't work either ... at first!

So when I moved the IRQ check and ISR call so that it was after the "next instruction execution" everything started working, so I think the Z8 will actually check the interrupt status during a given instruction execution (for example the one after the IRET) and I was checking before, and therefore potentially jumping into another ISR without executing that instruction.

So everything is working ... serial comms to the GPIB card (although I still need to check GPIB actually works), remote triggering, all the self tests, running on slow, medium, and fast speeds. All looks good.

It does break again when you compile with any optimisation enabled, so there is likely some very tight timing needs, but "None" seems to do the job nicely and I'm not inclined to spend any more time on this. I'm going to get my three 8840A's up and running and then I never want to see another one ;-)

I'll update the GitHub once all is complete.

[SilverSolder]

^LOL Essele, you have to be one of the most stubborn + smart guys I've seen at work in a while!

[dtxy101]

 8)I have replaced the CPU of fluke 8840A with z86e21af1 of ST company.
Lt-48 program tool.
The bin file address should be written after offset.

[dtxy101]

z86E11

[SilverSolder]

8)I have replaced the CPU of fluke 8840A with z86e21af1 of ST company.
Lt-48 program tool.
The bin file address should be written after offset.

Sounds interesting, got some pictures of your project?

[Kjo]

Any update from essele?

[essele]

Hello ... I thought I'd summed it up nicely...

"I'm going to get my three 8840A's up and running and then I never want to see another one ;-)"

I got them up and running and then sold them.

... and I've resisted the temptation a few times when some 8840A's and 8842A's came up on eBay .. I'm working on some other things at the moment and don't plan on doing anything further with this, ever, even if my life depended on it. ;-)

Lee.

[cheapskate]

Great work essele, I hope your project gets some attention from the vintage computing community as it seems these Z8 microcontrollers were used in all kinds of inconvenient places. I managed to fix my Fluke 8840 by replacing its CPU with the East German equivalent UB8840. I got the idea from http://john.ccac.rwth-aachen.de:8000/patrick/Z8emu.htm I had to design and order a custom PCB but I made it fit and it seems to pass self tests. Now I need to figure out an issue with resistance measurements.

[giosif]

[...]
I had to design and order a custom PCB but I made it fit and it seems to pass self tests.
[...]

Would you be so kind to share the PCB design files?
Thank you!

[cheapskate]

Sure thing. I added a cutout to left side of the PCB to give better access to some test points. I hope I configured the KiCad project correctly so that you can open it. I may be placing my remaining PCBs on eBay later as I don't really have a use for them.

[coromonadalix]

will you share you code to the eevblog community ?   is the ohms measurements problem(s) hard to resolve ?

thks

[Dakkahun]

Hi.

The resistance issue is probably caused by the custom Fluke 700013 unobtanium analog switch with latches.
See these threads: https://www.eevblog.com/forum/repair/fluke-8842a-lm308a-supply-voltage-above-max-rating/msg1687820/#msg1687820   and  https://www.eevblog.com/forum/testgear/replacement-for-fluke-700013-ic-(quad-spst-analog-switch)/

By the way, what would be the best way to read the ROM from a z8613 CPU? Both the piggyback and the external chip? Would a  TL866II+ be sufficient?

[coromonadalix]

the newest tl866II+ variant is a total crap, it doesn't program 21v devices,  i would try to find the older series  or a clone of it 

or the mcumall gq-4x is a good one, sure its priced higher

[cheapskate]

The eprom FLUKE used is the 27C32 so you should be able to read it in pretty much anything. I don't have a programmer so I rigged up an Arduino to do it. I got the files for the CPU and external ROM from KO4BB, both 8842A and 8840 files are available. I have both an 8842A and 8840 to test with, and I can tell that one of the several 8840 U222 files posted is incorrect. I don't remember which one, but it is off by a few bits. The 8842A files worked but I can't verify that they are correct either.

I haven't had time to look into the resistance issue yet. It just measures open circuit all the time. Also fails self test for AC ripple. Would suck if I have an unfixable unit after getting the CPU sorted.

[giosif]

Sure thing. I added a cutout to left side of the PCB to give better access to some test points. I hope I configured the KiCad project correctly so that you can open it. I may be placing my remaining PCBs on eBay later as I don't really have a use for them.

Thank you very much!

[giosif]

Great work essele, I hope your project gets some attention from the vintage computing community as it seems these Z8 microcontrollers were used in all kinds of inconvenient places. I managed to fix my Fluke 8840 by replacing its CPU with the East German equivalent UB8840. I got the idea from http://john.ccac.rwth-aachen.de:8000/patrick/Z8emu.htm I had to design and order a custom PCB but I made it fit and it seems to pass self tests. Now I need to figure out an issue with resistance measurements.

One question, if I may: what IC did you use for the ROM?
The ROM sitting on the original Zilog CPU is 4 kB and I am not able to find a 28 pin 4 kB EPROM IC.
Or did you combine the IC ROM with the remainder of the code from the U222 IC and write that on a 8 kB ROM?

[cheapskate]

I used an 8k AT28C64 ROM. Despite having 4 extra pins the package is extremely similar to the 2732. Look at how U222 (external ROM) is wired up since it is compatible with 8k chips but ships with a 4k chip. My PCB design should also be compatible with both. I don't think it's possible to (easily) combine the ROMs onto one chip since the Z8613 only supports 4k internal ROM so you would have to move everything to the external ROM which would require a different CPU and probably software changes.

[giosif]

I see it now: pins 26, 27 and 28 are all tied to VCC and the rest of the overlapping pins have the same layout.
Thank you!

[cheapskate]

Turned out that the problem I was seeing with bad measurements wasn't electrical, the front/back selector switch was bad.  The switch is actually made up of two switch sections connected together with a small plastic piece. That coupling was damaged and the switches wouldn't move together as one unit. I superglued the pieces together and everything seems to work! Meter passes all self tests and measurements seem reasonable. I still need to replace the power line filter, electrolytic capacitors, and the screen is a bit dim, but for now I'm just glad to have a working unit.

[giosif]

Hi,

I am having issue with this adapter: I made 4 such boards and, out of them, 1 is not showing any signs of life (I need to investigate this one), but the other 3 kind of start, and the display is showing some readings, but then the display is periodically updated with random data.
Also, switching to resistance measurements sort of works but, then, if I try to switch back to VDC readings, the meter hangs.
I've created a clip showing the above behaviour:
https://youtu.be/Y1eGM1Da-GU

I am sure it is the adapter boards that have an issue and not something else in the meter because I've tried them on two 8840A and one 8840A/AF (which work fine with original CPUs) and the behaviour is the same as above.
It is true I cannot be certain these UB8840M ICs are 100% working, but having 3 of them behaving the same way is very unlikely, in my opinion.

Any suggestions where I could start looking for the problem?

Thanks!

[cheapskate]

Are you sure you burned the firmware correctly with no errors? I don't have a 2732 to test with so I think my board ought to work correctly with it but I can't verify. I have assembled 3 boards, one of which came out defective because the CPU is dead. On closer inspection, I could see probe marks that weren't caused by me. Evidently that chip was damaged decades ago and put back on the shelf. The manual includes detailed troubleshooting procedures that include waveforms one can expect from the CPU. Maybe you have a short somewhere?

[giosif]

Assuming you are referring to the FW on the adapter board (i.e. U202), yes, I am certain I burned it correctly.
That's assuming the U202.bin file from the Ko4bb web site is good in the first place (just to check, the MD5 hash of the file I have is 79cebebdf156a9b1219a6c9f26da09e0).
Just to be on the safe side, I burned the FW once again, this time on a different 2732 IC.
I also bought an AT28C64B, burned it and tried with that.
In fact, I also burned the U222 FW again (on another 2732 IC).
I tried with these new ICs in their corresponding places, but the result is exactly the same.

Another thing I did was to order another batch of UB8840M, this time from a different seller.
I put in one of these newly arrived ICs but, as expected, the behaviour is the same.

In terms of shorts, I very much doubt it as I did both a visual inspection and continuity checks.
Also, I now have 3 boards that behave the same way, so it's unlikely I shorted them the same way.

To summarize:
1. The rest of the 8840A meter is working fine (confirmed with using an original Fluke CPU IC & associated U222 IC - true, those are FW 2.5, but I don't think that matters).
2. U222 IC (i.e. 2732 burned with corresponding U222 FW 2.3) is fine.
3. On the CPU adapter board:
   3.1. UB8840M IC is good.
   3.2. 2732 IC with U202 firmware is good.
   3.3. I checked the adapter board connections are according to the schematics and it all checked out.

The only remaining parts which are left are really the 3 capacitors on the adapter board (I am using 1 x 10 uF electrolytic, 1 x 100 nF film and 1 x ceramic cap whose value I don't remember now, this last one on the 2732 IC power rail), but I doubt it they have any influence in this.

Any other suggestions, please?

[cheapskate]

I briefly checked the circuit I uploaded against the boards I got manufactured and I don't see any differences in wiring. The only change between them is the cutout on the left side for access to test points. Here are the UB8840 datenblätter I used when designing the board.

https://hjs.lima-city.de/DDR/
http://www.blunk-electronic.de/datasheet/GDR/datenblaetter_ddr.pdf

[View[+]Finder]

Hello ... I thought I'd summed it up nicely...

"I'm going to get my three 8840A's up and running and then I never want to see another one ;-)"

I got them up and running and then sold them.

... and I've resisted the temptation a few times when some 8840A's and 8842A's came up on eBay .. I'm working on some other things at the moment and don't plan on doing anything further with this, ever, even if my life depended on it. ;-)

Lee.

A disadvantage of becoming a 'recognized expert' in any domain is that one can never retire . . .

So, this question is for anyone other than Lee: is there a possibility of extracting hidden digits from the ADC? The quality of the ADC and voltage reference in the Fluke 8842a show stability nearly equal to 6.5 digit meters like the Keithley 6500 and Keysight 34465a in tests I have done. (Depending on the choice of DCV input of course.)

[bdunham7]

So, this question is for anyone other than Lee: is there a possibility of extracting hidden digits from the ADC? The quality of the ADC and voltage reference in the Fluke 8842a show stability nearly equal to 6.5 digit meters like the Keithley 6500 and Keysight 34465a in tests I have done. (Depending on the choice of DCV input of course.)

Probably not, at least not directly.  The Recirculating Remainder method is different than dual or multislope integrators which often do generate extra digits internally since they measure time.  If I understand it correctly, the ADC on the 8840A/8842A models generates the equivalent of either 19 or 20 bits, which is about 500K or 1M counts, and then displays 200K counts--so there's not enough for another digit.  An indirect method would be to use an averaging algorithm on the readings and synthesize another digit--the older 850x monster meters do exactly that to generate either a 'CAL' digit (used only for adjustment) or an extra digit in the 10 volt range (8505B/8506B).

The 8842A does have remarkable stability, especially long term because it relies on aged and characterized references and resistors rather than an oven.  However I think short term stability, tempco and noise might not be quite good enough to merit another digit.  Of course there are plenty of actual 6.5 digit DMMs that probably don't merit their last digit either.

[Kleinstein]

The 8840/8842 still use the slightly odd reciculating reminder ADC. In theory with 5 passed and 4 bits each + maybe 2 bit extra from the last pass, there my be just 6 digit resolution. The slower conversions use the average over many such conversions - so in theory they may be a 6th digit, maybe even more. However it is not clear if the linearity and noise is OK all the way to the end - DNL may be limited by the adjustment of the ADC.
I would not consider the ADC especially good - it has some merits at high speed or with sampled readings, but not that great with slow measurements and mains hum suppresion can also be tricky.
With the computer one may use medium speed and get one more digit by averaging at the computer (e.g some readings).

The reference is very good - noise wise better than the usual LM399 found in 6 digit meter, though without a oven stabilization and not as good with the TC.

[View[+]Finder]

Here’s a little experiment: connect two meters (Fluke 8842’s) to a GPIB network and feed them with a reliable 10VDC reference. Just for comparison, feed the same reference to a ’new’ Keithley 6500 meter set-up to record DCV at NPLC = 15 continuously. Then trigger the two 8842’s using PyVISA over GPIB with the ‘group execute’ command: 

 intf.group_execute_trigger(DMM8842a, DMM8842b)

Capture 10,000 observations at roughly 1-second intervals for the 8842’s and for the same time period for the 6500 (not exactly the same periodicity) and have a look at the resultant data.

The average (mean) value for measured DCV was calculated for each meter as well as for the average of each observation for the two Fluke meters. The standard deviation of the data (sigma) was also calculated as a measure of the consistency of the measurements.

As shown in the attached table, Fluke meter ‘A’ sigma was about 50 micro-volts, meter ‘B’ 40 micro-volts and the average of each observation, about 32 micro-volts. By comparison, the Keithley 6500 measurements had a sigma of 3 micro-volts.

While this is by no way an exhaustive test of the Fluke 8842, it is strong evidence of the value in a properly maintained ‘vintage’ voltmeter in comparison to a state of the art meter with a ‘one-digit advantage’ in terms of advertised precision.

From a user’s POV, the Fluke —due to its specification of voltage ranges—is capable of ‘digit equivalency’ with the 6500 in many lower voltage measurements, particularly in the under 2VDC area. And if the reference is in a double-wall, metal case with no vents or fan, how much does the lack of an on-chip heater really matter?

[Kleinstein]

The limited resolution of the 884x may already contribute to the noise.  If random enough the quatization noise from 5.5 digits (and thus 100 µV steps) would be 29 µV RMS.  With a fixed input and little other noise, the quatization noise can be higher or lower. If the meters use digital cal factors there could be additional internal rounding errors.

One might get slightly lower noise when using the medium speed (20 SPS) mode and averaging on the PC side.

[bdunham7]

Capture 10,000 observations at roughly 1-second intervals for the 8842’s and for the same time period for the 6500 (not exactly the same periodicity) and have a look at the resultant data.

The average (mean) value for measured DCV was calculated for each meter as well as for the average of each observation for the two Fluke meters. The standard deviation of the data (sigma) was also calculated as a measure of the consistency of the measurements.

As shown in the attached table, Fluke meter ‘A’ sigma was about 50 micro-volts, meter ‘B’ 40 micro-volts and the average of each observation, about 32 micro-volts. By comparison, the Keithley 6500 measurements had a sigma of 3 micro-volts.

How many digits do the readings have over GPIB?  If there are no more than displayed, then you will have what I commonly observe with these which is that at on a very stable reference with a fully warmed up meter, you either get a flickering reading that varies by one count or a steady reading with no variation.  This could be caused by a low noise level that can result in a one-digit variance when the voltage is right at the threshold between two possible values while resulting in no variation if the voltage source is far enough from a threshold. 

It might be interesting to do the same experiment with either a 1.5V or 15V reference so that both the 8842A and the DMM6500 are displaying the same number of digits.

[View[+]Finder]

The underlying purpose of the experiment--other than to just check out the 8842A meters--was to see if averaging two meters' simultaneous readings would reduce the effect of noise. It did a bit, but nothing to brag about. The published spec for the meter is 0.0030% of reading + 2 counts which is a bit over 300 micro-volts (if I did the math right). As @bdunham7 pointed out, the ticking of the 6th digit is consistent with the sigmas that I reported. Getting +/-50 microV out of a thirty-year-old meter with a 90-day spec 6X that is a testament to the quality of the design and construction and probably a bit to survivor-bias as the duds were junked years ago.

The test was done with my best meter (HP3458) and the current best reference at 10VDC (sigma ~1.7microV). The Fluke range is 2V and 20V and the 6500 is 10V and 100V, so how about 1.999V? The 2V range doesn't much above 2V and the 100V range in most modern meters is not their best spec.

[Kleinstein]

The 100 V range on modern high resolution meters is usually with a 1:100 divider and than measuring in the 1 V range. For a 5 digit or lower end 6 digit meter this is not a problem. However with the better 6 digit meters the noise of the divider alone (100 K at the lower leg) gives noise comparable to slightly higher than a good meter in the 1 V range. So the 100 V range is a bit limited and there is kind of a natural cap on how good it can be.

It can help quite a bit to have a 20 V or similar range and does not switch to the 100/200 V range so early.

The noise usually does not get much worse with age. It is only the available parts and expectations that have changed over the years. Aging may cause drift in the scale factor, especially with the high voltage and ohms ranges. The prime range (20 V for the 8840) is usually quite stable over long time.

[bdunham7]

The test was done with my best meter (HP3458) and the current best reference at 10VDC (sigma ~1.7microV). The Fluke range is 2V and 20V and the 6500 is 10V and 100V, so how about 1.999V? The 2V range doesn't much above 2V and the 100V range in most modern meters is not their best spec.

The 2V range on the 8842A is the native ADC range and thus the most accurate, so go for it.  1.9V is a calibration point, IIRC, so it should be at its best right there if you have a stable source. 

I once tested an 8842A vs my 8846A at 15.0000 volts and found them to be indistinguishable in performance at that point, although I didn't do any kind of statistical analysis.  And the 8842A spec is actually better at that point--35ppm + 2 counts  vs 38ppm + 6 counts, plus high impedance.  If my math is right, the 8842A would also have a lower spec uncertainty at 1.90000 volts-- 8 counts vs. 10. 

[View[+]Finder]

The display of my used (are there any other kind?) Fluke 884X meters range from barely visible to good enough for most uses. A recent power outage in my area led me to uncover a way to improve the visibility without any effort at all.
 
Here's what happened. I was testing an eBay Fluke 8842 with a dim display to see if it was anywhere close to being usable when the power went out. The outage lasted a couple of hours and when i was putting my lab back on line, I noticed that the mains voltage was like 100V not the usual 120V. I also found that the 8842 display was blank--nothing lit at all--however, the relays were clicking as expected when changing functions. Wierd right? After a bit, the mains voltage was back to normal and the Fluke display was sorta visible again. This led to a review of the schematics, a browse of the eevblog forum and a leap of faith for the little meter. I unplugged the meter and used an isolation transformer to see what would happen if I set the ACV switch to Japan 100V. At 100V the display was dim but as I raised the voltage to 120 the display brightened considerably. No smoke, no excess heat, just brighter. Next I put the meter back on mains and observed it closely for a while. No problems, so I tried the "100V" setting on another dim 8842 with the same positive result.

I figure the 20% over-voltage in some way compensates for the lower output from ancient voltage regulator chips in the power supply. There does not appear to be any difference in calibration of volts or amps functions. Worst case, I might have to replace the voltage regulators sometime in the future, but since the display is unobtainable, I'll make do with what I've got.

[bdunham7]

You are overdriving the VFD filament which is driven directly by the transformer.  The voltage regulators are LM78xx type and will simply run warmer (not all that good) and if you go high enough, there's a crowbar protection on the 5V supply that will blow the mains fuse.  The supply voltages on these are very stable--there's a 6800uF filter cap on the 5V line.

I'm working on an LED replacement, so don't burn your meters out in the meantime!  The mains transformer is truly unobtainium and pretty tough to replace even if you had one.

https://www.eevblog.com/forum/testgear/fluke-8840aaf-8842a-vfd-display-replacement/msg3557023/#msg3557023

I intend to get back on this project in a few weeks.

[View[+]Finder]

You are overdriving the VFD filament which is driven directly by the transformer.  The voltage regulators are LM78xx type and will simply run warmer (not all that good) and if you go high enough, there's a crowbar protection on the 5V supply that will blow the mains fuse.  The supply voltages on these are very stable--there's a 6800uF filter cap on the 5V line.

Correct. The filament will be seeing a higher voltage, however the resistance of filaments (generally) will increase as voltage increases, so the current flow should not get to burnout level. Plus, all my meters are on UPS transformer/battery boxes that keep the supply under 115V and capture surges and spikes. Yes, I'm skating on thin ice and I'm certainly not suggesting that anyone 'over-clock' their meter without considering the consequences. As for the heat generated by the LM78XX regulators, that would depend more on the current flow than the input voltage, so unless there is some reason to to expect the measurement side of the meter to work harder because of the input voltage to the transformer, the heat doesn't seem to be a problem. In any case, the max input for the 7800 series is like 35V and that is not likely as configured.

BTW, I've read the posts on pulsing VFD's to wake up the phosphors or revive the filament; most don't end well. My post was more of a "what's up with this" than a suggested cure.

The real solution is your LCD panel concept to replace the VFD altogether. And, while you are at it, might I suggest an LCD for the HP3478? There are many for sale on eBay--some might need a battery replacement--and an LCD (or even a 7-segment) would make the HP3478 a more useful alternative.

[Kleinstein]

A higher voltage can make quite some differene, as the voltage drop is often only some 30% of the voltage. So a 10% increase in the input voltage would make this a 30% increase in the heat.

Ideally there is a seires resistor that could be reduced to increase the filament voltage a little, if really needed, espeically if only for a temporary higher intensity.

The HP3478 has a LCD to start with, but often with poor contrast and without backlight. While it was not so good when new, there is relatively little aging with the LCDs.

[bdunham7]

Correct. The filament will be seeing a higher voltage, however the resistance of filaments (generally) will increase as voltage increases, so the current flow should not get to burnout level. Plus, all my meters are on UPS transformer/battery boxes that keep the supply under 115V and capture surges and spikes. Yes, I'm skating on thin ice and I'm certainly not suggesting that anyone 'over-clock' their meter without considering the consequences. As for the heat generated by the LM78XX regulators, that would depend more on the current flow than the input voltage, so unless there is some reason to to expect the measurement side of the meter to work harder because of the input voltage to the transformer, the heat doesn't seem to be a problem. In any case, the max input for the 7800 series is like 35V and that is not likely as configured.

BTW, I've read the posts on pulsing VFD's to wake up the phosphors or revive the filament; most don't end well. My post was more of a "what's up with this" than a suggested cure.

Trust me on these observations--I've gone over the 8840/42s pretty thoroughly when testing my LED display, and trying to revive VFDs before that.  You can turn up the voltage enough to make the VFD filaments visibly glow red, which they normally don't--so they definitely are getting hotter.  And I can assure you that the VFD filament voltage is the only one that is budging when you do this.  I can also tell you that reducing the VFD segment/grid drive voltages from 30 to 24 volts, which happened when I tried to run the LEDs in parallel with the original drivers, has almost no effect on the brightness.  I never burned any VFDs out since the you can only boost the line voltage so much before the power supply crowbar kicks in.  As for the regulators the heat produced is the product of the current and the voltage drop across them.  It's not what they're rated for that counts, it's what they're heat sinked for in their actual implementation.  The regulators should actually just shut down rather than roast, so I'd worry about the transformer more, or if the filter caps are weak they might decide to retire.  I found that while you can improve the VFD a bit with an overnight burn at a 15-18% overvoltage, the result is very uneven and doesn't last. 

The real solution is your LCD panel concept to replace the VFD altogether. And, while you are at it, might I suggest an LCD for the HP3478? There are many for sale on eBay--some might need a battery replacement--and an LCD (or even a 7-segment) would make the HP3478 a more useful alternative.

Of course you mean LED.  I have an HP 3478 but I didn't know that they had display failure issues?  Or do you just want something backlit and more visible?  I'm not sure how much demand there would be for that model.  It's basically a $100 meter and I don't think people will buy a better display for it unless theirs quits. Maybe I'll have a look once I'm done with this one.  Proof of concept is done, now it's just details.  And finding the parts that everyone keeps running out of!

[View[+]Finder]

Yes, LED. My mistake, different problem; different solution.

As for the display brightness, I was just reporting what I saw (and a bit of "let's see what this does"); not as part of an attempt to find a way to brighten the display. I observed the display 'off' after the return of power; dim on the 120V setting; and brighter on the 100V setting. I did the test several times, just to verify. So I left that meter on the 100V setting and it is fully functional as far as measurement and display.

You have far more experience with these meters than I, so I trust the observations I have no plans to fool around with the voltage on the display. I don't remember exactly, but my usual practice when working on meters is to test for hot spots, particularly on voltage regulators, either with a finger on a recently unplugged unit or with an infrared thermometer on a live one if there might be an issue. There was probably a finger-check in this case. I just now checked the two 8842's running the 1.999V test @bdunham7 suggested and the outside case temperature is 37C for the meter under review and 41C for the other (the 37C is on top of the 41C, no surprise there) and no hot-spots over the transformer area. Yes, it would be a sad day if the transformer got smoked; not as sad as scrapping a good meter because of a dim display, however.

I would be happy to double-check any of the voltages for interested readers as well as verify the temperature of the heat sinks and transformer.

[View[+]Finder]

The problem with the HP3478 is twofold: the calibration is maintained by a lithium battery and the display is useless in dim light. The Fluke 88xx series has neither of these problems. Both are 'closed-case' adjustable for calibration purposes. In meters 'of a certain age,' specifications matter less than actual performance. Frankly, I don't know whether the Fluke is a better meter, although the voltage reference in the 8842 seems to be held in higher regard.

How about a voltage-measure face-off? I have a GPIB network and 2 each of HP3478 and Fluke 8842. And a Python test script to trigger simultaneous readings on GPIB. What should the parameters be? Hmmm . . .

[View[+]Finder]

The test was done with my best meter (HP3458) and the current best reference at 10VDC (sigma ~1.7microV). The Fluke range is 2V and 20V and the 6500 is 10V and 100V, so how about 1.999V? The 2V range doesn't much above 2V and the 100V range in most modern meters is not their best spec.

The 2V range on the 8842A is the native ADC range and thus the most accurate, so go for it.  1.9V is a calibration point, IIRC, so it should be at its best right there if you have a stable source. 

Attached are results of a test with both Fluke 8842's at 1.9999V from an HP3245 precision source. The Keithley 6500 meter was pretty much spot on for the 10,000 observations: 1.99989765V

[bdunham7]

The 8842A is clearly superior for the vast majority of users as long as it isn't broken and has an in-cal AC Option 9 board installed.  The 3478A is limited to 300 volts (something I didn't know until it was pointed out by another member to my surprise) and the high-impedance only goes to 3 volts.  It does have some slight advantages elsewhere (AC bandwidth and 30M ohms instead of 20) but those don't make up for the shortcomings in practical use, IMO.  Measuring the filter cap voltage of a PFC SMPS may blow it up.

The calibration battery is a one-time issue and you need a recalibration if you aren't careful.  The references aren't enough of an issue to worry about for most uses, the LM199 in the HP is pretty decent, although that version is probably not as stable as the LTFLU-1 long term. I think the Fluke will beat the HP in accuracy tests, but I'm not sure most users should care.  The display does suck, but for what these sell for, it's still a good cheap meter if you can live with the limitations. 

[bdunham7]

Attached are results of a test with both Fluke 8842's at 1.9999V from an HP3245 precision source. The Keithley 6500 meter was pretty much spot on for the 10,000 observations: 1.99989765V

So which meter, A or B, is the one set to 100V mains?  They both appear to be in spec, I'd just be curious if anything changed at all if you changed the mains voltage.

Also, can you do a run at 15 or 19 volts?  I know it isn't the Keithley's best range, but since I claim that the 20V range on the Fluke is a plus, I'd just like to see how they actually compare.  I assume your precision source is compared to the 3458?

[Kleinstein]

From the input secion of the Fluke 8842/8840 the best range is the 2 V range. The 20 V range uses an additional (though likely good quality) divider behind a buffer.
The 3478 is a bit odd with the 3 V range as it's best range. As a postive side it has a 30 mV range and can thus resolve down to 0.1 µV, which can be a plus.
With only 5.5 digits the reference (LM199 vs. unheated LTFLU) is not so much the limiting factor. The Fluke is better with noise, the Lm199 is lower TC - but neihter is visible with these meters. Both have a pretty good reference but limited resolution ADCs.

[View[+]Finder]

Attached are results of a test with both Fluke 8842's at 1.9999V from an HP3245 precision source. The Keithley 6500 meter was pretty much spot on for the 10,000 observations: 1.99989765V

So which meter, A or B, is the one set to 100V mains?  They both appear to be in spec, I'd just be curious if anything changed at all if you changed the mains voltage.

Also, can you do a run at 15 or 19 volts?  I know it isn't the Keithley's best range, but since I claim that the 20V range on the Fluke is a plus, I'd just like to see how they actually compare.  I assume your precision source is compared to the 3458?

The "A" meter has the input voltage set to 100V. Nothing appeared to change when the input mains setting was changed and the meter restarted. I only tested volts and low current amps.

The precision source is an HP3245 that is calibrated (volts and amps) by a Python script with my HP3458. That makes 10V (for example) on the 3245 source show as 10V on the 3458, and all across the full range of the 3245. The 3458, in turn, is auto-calibrated on DCV daily or as needed if there has been a change in ambient conditions (I've taken steps to eliminate that effect). Finally, the 3458 is DCV calibrated monthly (with adjustment) against a 10VDC reference that runs 24/7 in a "Thermal Stability Chamber" with temperature maintained at 25.25C by a Thor2000 TEC controller. Also an ohms calibration (with adjustment) against a 10kOhm reference. It is the best I can do with what I have to work with and I believe good enough to verify 6.5 digit used gear.

The 3245 that I have does not have the HV option, so the max DCV is about 10.1V. What I have used for higher voltage reference is a combination of a LiPo battery and the best voltage source in my lab, the Keithley 230 to maintain the LiPo. The test of the Fluke 8842 would be close to 19VDC and would be monitored by the HP3458 as well. Maybe later today for overnight?

UPDATE: Results of short run (1000 obs) with longer 10,000 observations run tonight perhaps to include the 3458 . . .

[View[+]Finder]

Also, can you do a run at 15 or 19 volts?  I know it isn't the Keithley's best range, but since I claim that the 20V range on the Fluke is a plus, I'd just like to see how they actually compare.  I assume your precision source is compared to the 3458?

Voltage source was a Keithley 230 set at 19.99VDC with an 8400 micro-farad capacitor in parallel. DUT's were two Fluke 8842 meters (A & B) independently connected to the source. The source was also monitored by an HP3458 and a Keithley 6500. Ambient temperature was 25C +/-0.2C. The test comprised 10,000 observations at 2-second intervals using GPIB group command. Mean (average) and sigma (variation) were calculated from the raw data for each instrument as shown in the attached table.

Some reflection on the results: The 100V range is not where the HP3458a earned its reputation, no surprise finding lower precision than on its 10V range. The Fluke 8842 performs well on its 20V range, probably as good as it does on the 2V range. As a general-purpose precision bench meter, the Keithley 6500 excels at data collection and the ability for the user to display, analyze and export data easily over a browser interface. Far better than the Keysight competitor in that area.

UPDATE: Another run with a source of 12VDC. I was trying to stay in the 10V range of the HP3458.

[Kjo]

I am always amazed how islands of projects can co-exist with little crossover. I just found this thread after several years of working on 884X projects through the Groups.io forum for Fluke hardware. I have more than 20 of these meters and some with Z86 issues, 700013 issues and bad displays. Several years ago I too found the  UB8840 clone John.ccac built for a disk drive. That had me motivated to design such a clone for the 884X.

The posts in this thread are not absolutely clear on the ROM versions used. But it should be clear that 8840A, 8840AF & 8842A all use different ROM versions that are not cross compatible. My UB8840 clone worked with all 8842A ROMs, but not all 8840A ROMs. In fact, only the 8840A V4.0 ROMs worked flawlessly in the 8840A meters. I have a suspicion, but not confirmation, that there is a timing difference between the Z86 and UB8840 such that data transfer to the display controller is incorrect. There is likely timing differences in older ROMs that are improved in the V4.0 version.


As mentioned elsewhere, if you can find a Z86E21AF microcontroller with a glass window, it can be programmed with the complete 8K ROM, though I have only verified this with the 8840A V4.0 ROMs.

Because the 700013 quad analog switch is the most likely failure point in these Fluke meters, I have, over the last 2 years, build 5 different clones in an attempt to duplicate this unobtainium part. I began with a Microchip PIC and DG212B. This processor has 4 programmable logic blocks independent of the program counter. It worked, sometimes, in some locations. Unfortunately, some obscure timing or noise issue kept it from working universally. But it would have been a easy 2-chip solution.


I made 2 other versions using 74HC & 4000 series with single chip inverters and a DG212B. These also worked, sometimes. And were a bear to assemble.
The 5th version used a PLD and a DG212B. It is also a 2-chip version, much easier to assemble. This version was condensed onto a PCB about 30% bigger than the original IC. It works flawlessly in U301, U302 & U303. Should also work in U40X positions.

I have made this available as a kit or fully assembled in limited quantity. (I need to recover some of the expenses incurred)
https://www.hollywoodcontrols.com/phpFluke/HC700013P.php

[giosif]

Thanks for your input!
I too suspect some timing type of problem, but I don't really have proof for it.

Also, you mention v4.0 for 8840A. Did you really mean v4.0?
I am asking since the highest version I've ever seen/heard of for the 8840A is v2.5.
Could you share that FW v4.0 with us, please?

Thanks!

[Kjo]

@giosif
The only specs on the UB8840M are in mostly non-English. But to my recollection when I designed the clone the UB8840M only addresses 4K on the buffered external ROM bus. But there are a few things about the Fluke 884x firmware that I have never quite understood.
In most meters there are 2 4K ROMs. The low 4K is embedded in the MCU and the hi 4K is external. The external ROM is enabled by P22 & DM from the MCU. So the low 4K in the MCU has to use port mapping signals to read the hi 4K. But there are a few late 90’s meters that have OTP or windowed Z86E21 8K EPROM MCUs where there is no device in the U222 socket. I have 3 such meters. Two of the 3 had the Z86E21 code protect bit set. Ha Ha Ha the third I could read out the firmware as an 8K block. I split this ROM in to 2 ROMs at the 4K boundary. After writing the 2-4K images into 2732A EPROMs, I put the low in a Z8613 piggyback and the hi into U222. The 8840A booted and passed all tests exactly as the original Z86E21 did.
So there is something about the operation of the Z86E21 I am unclear on. The 4.0 firmware clearly works as 2 ROMs but also as contiguous 8K memory. These Z86E21 are STM parts, and while I can read out the ROM, my programmer will not program them. So I have to send them out to get programmed.

Back to your request. Rather than dumping the ROMs here, I put all the ROM data for all the meters I have collected on my website. Anyone can grab what ROMs are there for what ever use. Not all ROM versions have code for the U202 MCU. And remember that all 3 meters have unique, non-interchangeable firmware.
HTTPS://www.Hollywoodcontrols.com/phpFluke/HC8840A_roms.php

If anyone has ROM data that I don’t have please let me know.

Kjo KO3Y

[giosif]

Thank you, Sir!

I was able to download the v4.0 firmware.
I burned the 2 x 4K files and tried them with the UB8840M adapter and the meter works fine now. 
Strange that the exact same adapter did not work with v2.3 of the firmware, but it works with v4.0.
In any case I am happy. 

On a side note, I happen to have a Z86E21, which I burned with the 1 x 8K version of the v4.0 firmware and I confirm this one works as well (I didn't install an EPROM IC at U222, as that wouldn't be needed anymore).

[Kjo]

@giosif
Glad to worked 4 you.  I have no idea what Fluke changed in the 8840A V4.0 fw.
But it works fine. What did u use to program the Z86E21 device?
Kjo - KO3Y

[giosif]

I used a less known programmer, Micromaster LV, made by a company called Ice Technology.

[cheapskate]

I am glad you got the CPU working giosif, perhaps there was some mismatch between the 8840A and 8840AF ROMs. I am surprised that these two have different ROMs at all, since I though the AF model didn't have any hardware changes aside from the ADC board being included as standard. I have previously tried using my UB8840 adapter in my 8840A multimeter and it worked without the 4.0 hardware. I didn't test it rigorously, but it did work. 

The existence of a continuous 8k ROM that also works as a split 4k image is very intriguing. Looking at the documentation, external memory is mapped into the same address space as the internal ROM. It may be possible to use a ROMless Z8 variant like the Z8681 with an external 8K ROM since U222 socket supports 2864 devices. This would eliminate the need for an additional PCB since the Z8681 is a drop in replacement for Z8611.

[Kjo]

The 8840A & 8840AF have to use different ROMs because the rear terminals on the 8840A are just duplicates of the front 4 kelvin terminals. But the 8840AF measures 2 different voltages at the rear pair and computes the ratio of the two. I have 1 AF out of 24 meters but never have used the ratio function. The F/R switch position is sensed via S301 to pin 32 of the Z8611 on all meters. Normally the front or rear 4W sense terminals are routed to the scaler & ADC via Q303 when 4 wire ohms is selected.
I have never seen anything that indicates that the AF motherboard is significantly different. The whole meter has better noise immunity ( more screws in bottom of cover and some upgraded components) but that is it. They just figured a way to use the rear sense terms to measure a second voltage and calc a ratio. The FW measures the volts term then the reference term. The GPIB doesn’t know that there is anything different going on. The ratio is shown with DC volts units if I remember correctly.

I had a guy in Germany with a bad AF. He swore it was the U222 ROM that was bad and had tried every combination of ROM in the wild with no success. But AF ROMs weren’t wild. I looked through my collection and noticed a AF among them. I never really paid that much attention to the marks on the front. I ripped the U222 ROM for him. Took 3 weeks to get there, but he sent me a picture of the working display!

I wish I had a Z8681 for I would try that experiment. I have a bunch of other variants that all work. The V4.0 F ROMs work fine with Z8613 piggybacks (split), Z86E21 OTP 8K, Z86E21AF1 8K UV windowed and the UB8840M clone (split). There is a lot about these Z86 devices that has become obscure with time. Thankfully the hardware is robust and fairly well documented!

Kjo - KO3Y

[cheapskate]

After reviewing the schematics, it seems that using Z8681 not possible. Unfortunate, because they seem reasonably common on eBay. U202 is capable of using all 8k of the external ROM, but not in the way Zilog intended. The Z86** series can do 8, 12, or 16 bit addressing whereas an 8k device requires 13 bits. To avoid wasting 3 pins in 16 bit mode, Fluke used 12 bit mode and an extra pin that is then controlled manually. This means that it is impossible to read all 8k without the software being aware of it. At least that's what I think, based on the schematics.

I do remember seeing some activity on U222 address pin 12, device pin 2 / U202 port 06, device pin 19 while I was testing my adapter so I wonder if Fluke intended for the software to be 8k aware. I don't have a Z8681 to test with either and it is pointless to try if there is no activity on that pin, but I will investigate tomorrow.

FOLLOWUP: There is no activity on that pin.

[Kjo]

Options for a bad CPU.

I have had a number of private inquiries on this subject. I thought it worthwhile to bump this thread with a consolidated set of reliable? options.
Given the previous comments in this thread I want to make it clear to the uninitiated that the 8840A, 8840AF and 8842A ALL use different
ROM sets. You cannot interchange them! And there are multiple versions of each in the wild.

• Find a working Z0861108PCS mask ROM CPU with the correct ROM for your meter model.
  But be cautious. These mask ROM chips have a habit of failing or faulting when hot. You might
  get one that works initially but fails later.
  
• Find a Z8613RS piggyback CPU and burn a LOW 2732 EPROM to match the HI U222 you already have.
  Currently Unobtanium.
  
• Find a Z86E11F1 (4K) windowed EPROM CPU and burn the LOW ROM into it to match the HI U222 you already have.
  You may have a challenge finding a burner for a Z86E chip and the algorithm is mfgr dependent.
  
• Find a Z86E21F1 (8K) windowed EPROM CPU and burn LOW & HI ROM into it. Be sure to remove the EPROM from U222.
  You may have a challenge finding a burner for a Z86E chip and the algorithm is mfgr dependent.
  
• Find a Z86E21F1 (8K) OTP EPROM CPU with the LOW & HI ROM already in it. Be sure to remove the EPROM from U222.
  These are super rare and were only used near the end of the 8840A production run.
  
• Find one of the several Z8613RS PCB based clones that work like the piggyback CPU. Use the ROMs of your choice for the meter you have.
  Here is the one I designed based on the UB8840M clone from East Germany:
  https://www.hollywoodcontrols.com/phpFluke/HCZ8611C.php
  Not cheap to manufacture considering all of the components.
  

[ignilux]

The posts in this thread are not absolutely clear on the ROM versions used. But it should be clear that 8840A, 8840AF & 8842A all use different ROM versions that are not cross compatible. My UB8840 clone worked with all 8842A ROMs, but not all 8840A ROMs. In fact, only the 8840A V4.0 ROMs worked flawlessly in the 8840A meters. I have a suspicion, but not confirmation, that there is a timing difference between the Z86 and UB8840 such that data transfer to the display controller is incorrect. There is likely timing differences in older ROMs that are improved in the V4.0 version.
(Attachment Link)
(Attachment Link)
As mentioned elsewhere, if you can find a Z86E21AF microcontroller with a glass window, it can be programmed with the complete 8K ROM, though I have only verified this with the 8840A V4.0 ROMs.

Sorry to bump a thread that's over a year old now, but I'm thrilled to find somebody else with an 8840A that has the Z86E21 windowed EPROM CPU and firmware V4.0. I've been pulling my hair out trying to figure out how to extract the firmware from these, but thanks to Kjo I no longer have to!

@Kjo, does your 8840A with the V4.0 firmware and Z86E21 appear to have a number of other hardware improvements over the service manuals readily available on e.g. BAMA and KO4BB? Having recently completed a recap of my HP 3456A I opened the 8840A to check for any suspect electrolytics. To my surprise it looks like most (all?) of the voltage ratings of the caps in my meter are over and above what is listed in the service manual. Not sure if somebody has been in here before me, or if Fluke revised the spec themselves. This meter appears to be from the late 90s, so if these are the stock batch of caps I might as well replace them for peace of mind. If they have been replaced in the meantime then I won't bother. Cheers!

[Kjo]

There are very few versions of the manual for the 8840A (12/91 revised 5/97), and it is incomplete in terms of schematics. But you can combine it with the 8842A (12/91 revised 7/96) which is complete.
The main PCBs are slightly different, and some of the option boards are jumpered  specific to the 8840A/AF (AC Converter) and/or have different ROMs (488 card) but the schematics are the same.

But I know of no material changes to the main PCB from 1984-85 to 1997-98. Your meter may have been re-caped, but of the 30 meters I have tested, I found only 2 that needed new caps (and not all of them).
I dont subscribe to the "re-cap" everything, particularly industrial equipment. I typically measure, with a pair of HP3457A scanning system meters), AC & DC values of the 6 main input filter capacitors
and the 10 regulated DC supplies. If these meet the Fluke specs I dont tough them.
The only thing I have found that changed is the supports under the main PCB in the transformer area. Meters up to about 1988 have only a white nylon hex standoff to keep the PCB from sagging. Later
models have a machined Delrin transformer support. I suspect a known failure was de-laminating of the transformer solder joints. (I always re-solder the transformer if I poen a meter.)

kjo  KO3Y