HP3478a Upgrade : Replace 8048 uP/assembler  with  daughter board/uC/C - Page 1
Forum section: electronics / projects

author: dazz1
author_rank: Frequent Contributor
timestamp: December 21, 2022, 02:01:16 am
content: HiI have just purchased a late model? 1989 HP3478a from e-bay. It's going to take a while before it get delivered to me in my country, but in the mean time I have been looking for hacks and mods to improve this vintage piece of test equipment goodness.I found posts from one of the original HP3478a design team members herehttps://groups.io/g/HP-Agilent-Keysight-equipment/message/103951.In his post he says that RAM memory cost and space prevented storing cal data for both 4 and 2 wire modes. I am thinking that with existing open source knowledge and the lower cost of memory, it might be practical to modify HP3478A code to store 2 and 4 wire cal data. Although 4-wire mode is the more precise measurement method, 2-wire is much more commonly used. The benefit of this improvement to 2-wire cal would be seen far more often than the 4-wire mode.With projects like the one to add a relative functionhttps://www.eevblog.com/forum/testgear/hp-3478a-rom-modification-relative-mode/there should be enough knowledge to modify the ROM code to store 2x sets of cal data.With this project to upgrade to FRAMhttps://www.eevblog.com/forum/projects/3478a-fram-modification/increasing memory is achievable.Unfortunately, I don't have any experience with the CPU, the related assembler, MAME etc. I am just throwing this idea out there.I am also looking at the circuit diagrams and just wondered about the replacement of very old components with newer low noise, low leakage, low offset devices. I think this would be quite difficult to do because it would require some really good test equipment to confirm any improvements. If someone has the test equipment, they would not need to improve the HP3478A. A bit catch-22.

author: Kleinstein
author_rank: Super Contributor
timestamp: December 21, 2022, 10:25:43 am
content: If the 2 wire resistance mode needs good accuracy, one should use the relative function. Than there should be little need for a separate cal constant.So the ROM mod for the rel mode can make sense.Much of the analog function is inside the hybrids. It looks like the ADC is more limited by the timing / resolution and not that much from the analog part. So I don't see much options for an easy improvement. If at all one could consider a lower noise OP-amp for the input, but that is about it. Not sure if the amplifiers noise is actually relevant. If at all maybe in the 30 mV range.The 3478 is a nice, often relatively cheap meter, but due to the custom hybrids nothing to fiddle with. At some point a new build from scratch could be easier than trying to improve on an old circuit / design.A first step would anyway be an analysis of the actual performance, so check the input currents, noise and maybe linearity (to some degree).

author: dazz1
author_rank: Frequent Contributor
timestamp: December 21, 2022, 10:54:45 am
content: HiPerhaps swapping out the voltage regulators for modern equivalents might reduce noise which might improve overall measurement performance.This type of mod would require before and after testing to see if there was any real benefit.

author: Kleinstein
author_rank: Super Contributor
timestamp: December 21, 2022, 12:38:23 pm
content: The voltage regulation looks quite normal. A modern 7805 is not better than an old one with HP specific number. The supply regulation should not be a significant contribution to the overall noise, especially not at the 5.5 digit level. It would be good to check for supply ripple, in case the filter caps are bad, but that is about it with the supply. Chances are the old caps are still OK.It is quite some time that I have use a 3478, but I don't remember it to be a specially noisy meter, more like rather good for 5.5 digits.I am afraid the ADC noise is to a large part set by the digital control part and quatization noise and thus not much to improve there. Not sure if the PC interface gives out more than the 5.5. digits, but there may not be much extra internal resolution as the timing via µC could be relatively slow.So a first step is to see if there is much noise beyond the quatization.

author: niconiconi
author_rank: Frequent Contributor
timestamp: December 21, 2022, 04:59:50 pm
content: Quote from: dazz1 on December 21, 2022, 02:01:16 amA potentially interesting idea that doesn't require any hardware modification is attaching an external microcontroller with some buttons and an LCD. Talk to the instrument via its HPIB/GPIB port. You can add whatever custom measurement modes you need.

author: Miti
author_rank: Super Contributor
timestamp: December 21, 2022, 05:40:15 pm
content: Take a look at this project. You may find it interesting and satisfying most of your needs.BTW this instrument with this improvement became my workhorse in the lab.https://www.eevblog.com/forum/projects/project-extending-hp3478a-functionality/

author: dazz1
author_rank: Frequent Contributor
timestamp: December 22, 2022, 08:15:33 am
content: Quote from: Miti on December 21, 2022, 05:40:15 pmThat is a long topic. I will have a read.The relative featurehttps://www.eevblog.com/forum/testgear/hp-3478a-rom-modification-relative-mode/msg2055250/#msg2055250looks good and is sort of what I had in mind. Reverse engineering assembler to make this sort of mod is quite an achievement.I am not looking to turn a 5.5digit meter into something it isn't. I understand the HP3458a shares a lot with the HP3457a 7.5 digit multi-meter so just maybe it is practical to achieve something slightly better than 5.5 digits. I like taking old tech and making mods with new tech.

author: fenugrec
author_rank: Frequent Contributor
timestamp: December 23, 2022, 03:21:07 am
content: Quote from: dazz1 on December 21, 2022, 02:01:16 amUgh, writing code for the 8048... No fun, would not recommend. I feel bad for the original 3478 firmware developpers; what a nightmare it must have been.Challenges include :- limited instruction set- C compiler absolutely not an option- limited address space. Even crossing 256-byte boundaries is not to be taken lightly.- 3478a's ROM has very little space left in it. It was a pain to fit in the relative mode hack. There are a few "windows" left but it needs creative hooking and trampolining. See the code for my ROM patches...Regarding 2w + 4w cal, there are 3 "unused" slots in the cal RAM. It might be possible to store separate 2W/4W constants for the lowest ranges where it makes the most difference, and keep common constants for the upper ranges.All that said, over the past few years I've been thinking on and off about bolder objectives.First train of thought was to literally emulate most of the ROM in a modern mcu, with a few manual hooks to extend or replace functionality. For example, inserting an illegal opcode in the display functions could pause emulation, and provide an easy way to drive any kind of display.I tried a proof-of-concept by stripping down a standalone MCS-48 emulator, compiled with a test jig, for an ARM cortex-M0 (stm32F072 in this case). Turns out the M0 core is very ill-adapted for this kind of task. It takes around 180 to 280 clock cycles per MCS48 opcode - this would require the host core to run at > 100MHz , and would leave very little CPU time for external functions. Haven't tried an M4 core; it would be better but not radically so. It's just too much state to maintain in the GP registers, which means a lot of load+modify+store to RAM, which takes a lot of cycles. Plus, lots of conditional jumps means many additional cycles. It's so far from being viable that I set this project aside.Next: there are "modern", fast 8051 mcus, and it's no accident that the MCS-51 has a very similar architecture to the MCS48. So there is a possibility of porting the original firmware. I have the original ROM mostly mapped out by now, with very few mysteries left. However, there are many shortcuts and tricks that do not map 1:1 to the 8051 architecture. As I mentioned above, the ROM is crammed tight, and also uses lots of hardcoded stuff, so my feeling is this would need a lot of tweaking to even get the code to assemble for a 8051. And with all that effort it would still only be a butchered, reverse-engineered assembly "blob".Finally, a sledgehammer solution that is only now starting to look reasonable, after spending some time improving8048 support in Ghidra:1- make sure all the code is decompiled cleanly, or at least sane disassembly : done. Ghidra does a great job on a large fraction of the code base; my annotated disasm already covers some of the remaining difficult spots.2- identify time-critical code : I can only think of 2 tasks; serial comms with the analog CPU, and serial comms with the display. Both are slow by modern standards, and should be easy to port to a modern mcu.3- export all "clean" C functions from ghidra : these would be compiled as-is. The BCD math routines will look absolutely disgusting but should be functionally equivalent.4- examine and manually adjust the more problematic table-read functions. I think a bit of ghidra scripting could help here. These tables are for things like locating entries in the CAL RAM, handling keypresses, GPIB commands, printing strings, etc.5- implement stubs for the IO : easy, especially if we give up the DIP switches, GPIB and the CAL RAM.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 23, 2022, 07:59:19 am
content: HiMaybe the way to go is, as you say, to replace the factory microprocessor with a daughter board. The daughter board would contain a modern CPU, ROM, RAM, nvRam (FRAM).That would make the HP3478a address lines redundant except for A0-A2 for GPIB controller (U506, U503) and the switch settings (S501).It would get rid of the Li battery.By installing the microprocessor and memory on a daughter board, the factory ROM/RAM can be removed. The attached drawing identifies the U501 microprocessor on the digital side that would be removed/replaced. The factory ROM/RAM that could optionally be removed have red crosses. The remaining active address lines are highlighted in green.Replacing the CPU with a daughter board would probably be easier and faster than trying to squeeze more code into the factory system.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 23, 2022, 08:11:17 am
content: HiI quick rummage around Google reveals that the Keil C compiler runs on the 8051 family. Writing stuff in C would be a lot easier than assembler. Lots of people know C. Not so many know assembler.Using an 8051 family micro-controller may not be the best solution but it is a good place to start. The voltages and timing should be compatible.

author: uski
author_rank: Frequent Contributor
timestamp: December 23, 2022, 10:43:57 am
content: I think the approach of emulating the CPU is good, but I would do it in an FPGA instead of in a microcontroller.https://github.com/freecores/t48You could then add another softcore in the FPGA to add whatever you want. If you want a display you could control it from the FPGA too.And maybe you could use the FPGA to add even more stuff (USB, pulse measurement capabilities, ...)

author: Kleinstein
author_rank: Super Contributor
timestamp: December 23, 2022, 11:30:22 am
content: To work easy with the old 5 V hardware one may have to use an older µC. They may still accept standard TTL and thus 3.3 V CMOS levels and this way allow also for a more moder µC with 5 V tolerant pins.I see little advantage in a FPGA, as the digital side part is more like math and non time critical interface handling. So something for a µC and not so much for a FPGA.Rewriting the SW is still quite some effort with a likely still only moderate improvements.Replacing the ADC side µC would be more tricky as the code may need accurate timing - that part may have some justification for a FPGA. Still it would be quite some effort - more like building your own ADC version. In this case it would likely be better to also replace the old HW alltogether.

author: fenugrec
author_rank: Frequent Contributor
timestamp: December 23, 2022, 01:46:55 pm
content: Quote from: dazz1 on December 23, 2022, 07:59:19 amMost mcus contain all of the above, and sometimes EEPROM (if not, an external I2C/SPI EEPROM is a few pennies extra)QuoteThat is not even debatable. The only part that needs "read-only" assembly knowledge is to port a few areas of the original ROM. With 8051 experience you already know most of the msc48 instruction set.QuoteI don't think that will be necessary. Many 3.3V mcus have 5V-tolerant pins, and regular push-pull GPIOs putting out close to 3.3V should be plenty enough for TTL levels. In total I count 28 IO pins required for complete control:Code:nameqtylevelnotes(bus)3TTLALE, ~RD, ~WR : output only, could be 3v3D0-D785Vdata/addr bus to latchesP10-P1785Vkeypad matrix; could be 3.3V with minor tweaksP20-P2345VCS latchP24-2525VLCD (PWO, clk2)P271TTLTX to analog isoT01TTLclock for GPIB ICT115VRX from analog isoINT15Vasync TRIG from GPIBbut with a bit of creativity only 13 of them need either a resistive divider, or be 5V-tolerant (Dx, P20-P23, T1),QuotePossible, but at least it's not at all a full rewrite - many of the functions would be simply be disassembled+ decompiled + recompiled.Advantages are :- no lithium battery- separate 2W/4W cal- easier to manage calibration- opens the door to more practical interfacing than GPIB (even a simple UART would be an improvement)- easier to add math functions etc- could support any type of display@uski : yes, I remember seeing that T48 core, and it would definitely be cool, but an FPGA project with this amount of integration is much less approachable IMO. And definitely beyond my HDL skill that never progressed past "oh wow I made a shift register".I also have a feeling that a device big enough to hold 2 softcores, glue, some RAM+ROM, and at least 30 IO, is unlikely to have 5V-tolerant IO ? Sure, we can throw 74x244/245 buffers at it... doesn't seem as elegant. And definitely not easy - we don't see a lot of DIY projects this complex, for a reason...

author: dazz1
author_rank: Frequent Contributor
timestamp: December 24, 2022, 02:30:58 am
content: HiI think the starting point here is to define the problem. The problem is to be able to enhance the features and capabilities of a fundamentally good instrument. It has to be cost effective (cheap) to do.I see there are potentially three streams of effort here:1. Upgrade the analog front end.2. Modify/upgrade the hybrid ADC logic/digital software.3. Upgrade the digital controls side of the meter.It might be possible to replace key analog components with newer versions with less drift, noise, leakage and offsets etc.It may be possible to modify the ADC control software to enable measurements to better than 5.5 digits.I think the easiest upgrade is to rewrite the digital control code in a high level language (C) as an open source project. That will allow people to add features without the existing limits.In order to contribute, people will need to know how the existing meter digital controls work. This requires someone to:Map the I/O pins.Document the control signalsDocument the messaging/signalling protocols.I am reasonably sure fenugrec knows most, if not all, of this stuff. It may just need some effort to document better it for others to easily follow and contribute.The next step would be to define a feature priority list based on:Must have,Should have,Could have,Must not have.THEN choose the hardware and tool chain that is capable of achieving all of these, with space and capacity to spare. The software development environment is probably more important than the hardware. This includes not needing any special hardware to program the new hardware. I think the recipe for success includes making it as easy as possible for people to contribute effort, rather than just relying on one person.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 24, 2022, 06:57:02 am
content: HiJust renamed the thread to better reflect where this is going.

author: robert.rozee
author_rank: Frequent Contributor
timestamp: December 24, 2022, 08:00:41 am
content: just an idea... what if you retained the existing processor and ROM, but nop'ed out all the high-level code and just kept the code needed to drive the ADC and other low-level stuff. then add an auxiliary processor (on a daughterboard that also has the 8048 relocated to it) to run the display, front buttons, comms, and high-level functionality?this would allow dividing the job into:- rip out redundant code from the 8048 ROM and add in a small 'dispatcher' for the retained pieces of code;- design C code for the auxiliary processor to implement high-level functionality and instruct the 8048;- design PCB to lift 8048 out of its socket and accommodate the auxiliary processor (plus possibly modified 8048 ROM).cheers,rob :-)

author: uski
author_rank: Frequent Contributor
timestamp: December 24, 2022, 08:32:09 am
content: Quote from: Kleinstein on December 23, 2022, 11:30:22 amI think I was not clear, and/or you misunderstood. I am not saying the actual features of the meter should be reimplemented inside an FPGA.I am saying that one could use an FPGA to emulate the T48 CPU used inside the meter, which would then allow to expand it.This would give access to more program space, and other additional possibilities.The level conversion to/from 5V is not a problem and very easy to achieve.Practically, I am not sure it is worth going to that level of effort, but... sometimes people want to have fun, and this is one way to have fun

author: dazz1
author_rank: Frequent Contributor
timestamp: December 24, 2022, 09:23:29 am
content: HiMy shallow analysis of the manuals indicates there is a second uP on the analogue side that drives the ADC. Just maybe there is the possibility of modifying the code, and upgrading the analogue circuits to extend the digits. This would be difficult.On the digital side, the 8048 doesn't have a lot to do and most is not time-critical. This is where I see the maximum benefit at least effort. Rewriting the 8048 code into C will require no small effort, but it would be far more accessible to more people. More developers are likely to be interested in a project written in C, than trying to decipher and modify someones assembler on an ancient 8048.Designing/building a daughter board as a plug-in replacement for the 8048/RAM/ROM/nvRAM, regardless of micro-controller choice, would be relatively easy.Economically, it makes no sense to upgrade an ancient instrument as proposed. There is no challenge in just going out and buying a new multimeter from the latest catalogue.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 27, 2022, 08:30:12 am
content: HiI have worked my way through the service manual to identify the pins that would need to be read or driven from daughter board that replaces the 8048 control microprocessor. The results are attached.The existing ROM/RAM can be left in place and ignored.The next step is to document the protocols. I know others have already figured these out so that will be a big help.

author: fenugrec
author_rank: Frequent Contributor
timestamp: December 27, 2022, 02:03:09 pm
content: Quote from: dazz1 on December 27, 2022, 08:30:12 amWR is marked "NC" but is required, as you correctly noted for writing to the GPIB controller.I was missing PROG in my earlier list. So, 30 GPIO required.I count 153 "functions" in the disassembly; I have looked at + named 97 of them, although many are not ready to be recompiled as-is because of very non-C "calling conventions" (i.e. passing 2 args in registers, but also returning 2 values in 2 other regs, setting F0 flag, etc.). So they will all need to be looked at again to establish definitely the input + output params, as well as any affected global state. For the internal data RAM it's easy enough to identify and label in Ghidra, but some areas of the code use e.g. F0 between a few functions as an additional bool flag.I would instead focus on just porting the decompiled code with as little modifications as possible at this state. A thorough understanding of the protocols is not necessary for this, although a few LA captures of e.g. the isolated data link could be useful to validate timing. Look at functions isol_synctx and isol_syncrx in my disasm for that. But I very much recommend to also start using ghidra.i.e. what would you prefer working with :Code:undefined check_calentr_a()assume DBF = 0x0undefined A:1 <RETURN>byte R2:1 cVar3 XREF: CODE:0207(W)check_calentr_a XREF: selftest:0694(c)CODE:0204 c6 1e JZ LAB_CODE_021e verify checksum at a=addrCODE:0206 a8 MOV R0,ACODE:0207 ba 0b MOV cVar3,#0xbCODE:0209 b9 00 MOV R1,#0x0CODE:020b bb 0f MOV R3,#0xfLAB_CODE_020d XREF: CODE:0212(j)CODE:020d 80 MOVX A,@R0CODE:020e 18 INC R0CODE:020f 5b ANL A,R3CODE:0210 69 ADD A,R1CODE:0211 a9 MOV R1,ACODE:0212 ea 0d DJNZ cVar3,LAB_CODE_020dCODE:0214 80 MOVX A,@R0CODE:0215 18 INC R0CODE:0216 5b ANL A,R3CODE:0217 47 SWAP ACODE:0218 aa MOV cVar3,ACODE:0219 80 MOVX A,@R0CODE:021a 5b ANL A,R3CODE:021b 4a ORL A,cVar3CODE:021c d9 XRL A,R1CODE:021d 37 CPL ALAB_CODE_021e XREF: CODE:0204(j)CODE:021e 93 RETRorCode:byte * check_calentr_a(byte *param_1) {byte *pbVar1;byte cks;byte count;/* verify checksum at a=addr */if (param_1 != (byte *)0x0) {count = 0xb;cks = 0;do {pbVar1 = param_1;cks = (*pbVar1 & 0xf) + cks;count = count - 1;param_1 = pbVar1 + 1;} while (count != 0);param_1 = (byte *)~((pbVar1 & 0xf | pbVar1 << 4) ^ cks);}return param_1;}

author: coromonadalix
author_rank: Super Contributor
timestamp: December 27, 2022, 02:57:35 pm
content: Is there any say stm32 dev board or other with lots of power, fpga based dev board(s) that could be snatched inside the meter ?? you could gain usb interface etc ...I do understand all of this, it's a very good projectBut eventually a 5.5 digits meter will have it's limits ?? No ?

author: Kleinstein
author_rank: Super Contributor
timestamp: December 27, 2022, 06:21:01 pm
content: There is not real need for a specially powerfull µC. The 8048 to replace is only running quite slow and nur having that much memory. Even with more code needed in C compared to ASM, I would not expect to need more than some 32 kB, maybe 64 kByte due to overhead from a HW interfacing library. Especially with the likely rather slow interface and DC I see no need for much computations to be done.One would likely need some 30 GPIOs with some 22 or so of them 5 V tolerator (the keyboard and maybe a few more output only functions could get away without it).So the RP2040 likely has to few pins. Chances are low that the pinout of a blue pill or similar would fit. So one would likely need a small cusom PCB. For the start a prototype board may be OK, just using the RX/TX to the ADC part and than an USB/RS23 interface instead of GPIB. So one could in theory start with something like a Blue pill / STM32 nucleo.Chances are a STM32 or similar ARM µC with 64 pin (maybe 48 - but could be close with extra function like USB and thus extra pins) case should be OK.I looks like the STM32F0 and STM32G0 sereis are available again.For the SW side it's 2 different ways:A) start very close to the original SW and more or less do a ASM to C conversion and only than add on thisB) understand the interfacing protocoll and than more or less do your own firmware, not looking at the old code, but more the the manual for the required functions.The SW made the 2nd way may also be usefull with a different front end, e.g. if the 5.5. digits are not enough. For many uses a good 5.5 digit front end is not that bad. A simple DIY analog front end and different display would not be that complicated either.

author: fenugrec
author_rank: Frequent Contributor
timestamp: December 29, 2022, 01:30:51 am
content: QuoteYes. This is about making the 3478 (probably the 3468 too with minimal effort) easier to repair, calibrate, and communicate with. I don't think it's realistic to try to extract 6.5digit performance out of the 3478 front-end.Quote from: Kleinstein on December 27, 2022, 06:21:01 pmIndeed. A) is what I've been mainly looking at recently. It would be easier to maintain compatibility with the original GPIB protocol (I'm not interested in programming anything GPIB-related from scratch), and should guarantee that the offset+gain calculations are identical to the stock firmware.I think B) could maybe produce some initial results faster, but it would need a lot more analysis of the original .asm code, which so far nobody else seems to have done (at least publicly).Agreed that mcu choice and performance is not critical, for a rewrite. Emulation is more demanding. My ROM estimates are close to yours, about 16kB for a minimal feature set (and no USB stack), 32k for probably most use cases. Would definitely pick a family that has pin-compatible replacements with at least 64k just in case. And with a minimal amount of care, the firmware can be written in a very portable way that would work on any mcu with enough GPIOs, a few timers and UART, and whatever host interface, USB/UART.The most elegant packaging would be a DIP40 PCB with the 8039 pinout, and an mcu on it. A 8x8 QFN44 is pretty much the largest that can fit on such a PCB. If level translators are required, layout becomes much more challenging.

author: Miti
author_rank: Super Contributor
timestamp: December 29, 2022, 03:05:04 am
content: Please forgive me if I see this as a futile exercise. I think Kirill’s extension and Luke Mester’s software is all this meter needs. If you need more, get a used 34401, Fluke 884x or newer instruments. Just an opinion.

author: fenugrec
author_rank: Frequent Contributor
timestamp: December 29, 2022, 03:11:29 am
content: Quote from: Miti on December 29, 2022, 03:05:04 amAs with many projects : it is.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 30, 2022, 06:26:09 pm
content: Quote from: robert.rozee on December 24, 2022, 08:00:41 amI have considered your suggestion. My thoughts are that it would require detailed and complete understanding of the asm code in the ROM. It would also require a EPROM programmer, something many will not have. I suspect it would be quicker, easier and better to discard the existing ROM code and start from scratch. The disadvantage with this approach is that it would require a C/Python version of the existing ROM code to be written just to restore the original standard functionality. The advantage is that it would be much easier to modify and enhance code in a high level language.Adding a daughter board in place of the existing 8048 cpu would allow the existing ROM and nvRAM to be ignored. That would simplify the hardware modifications. A modern micro-controller will be programmable via a USB port. Not needing specific programming hardware will reduce the cost.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 30, 2022, 06:54:29 pm
content: Quote from: Kleinstein on December 27, 2022, 06:21:01 pmAt this early stage, it is only necessary to determine that at least one uC is available to do the job.I think a daughter board that is a plug-in substitute for the 8048 should also include I2C, SPI and usb.Quote from: KleinsteinReplacing the 8048 with a modern uC makes both ways practical, either as part of a development roadmap (A then B) or as separate parallel projects (A and B). This is a really important feature of this proposal. It would be an enabler for multiple project strategies.Quote from: KleinsteinI have low expectations about any upgrade to the hardware front end. The design is now decades old and some upgrades may be possible. My initial research indicates that the ADC integrating capacitor is the key component and dielectric absorption (DA) is the key parameter. This was known at the time. It is entirely possible that the design includes compensation for DA, so replacing the existing capacitor with an improved component may degrade meter performance if the compensation is left in place. Making these sorts of design changes would require far better test equipment than I have or need.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 30, 2022, 07:10:35 pm
content: Quote from: Miti on December 29, 2022, 03:05:04 amTime and money spent on upgrading in instrument that is now decades old is wasted by any sensible economic measure. That also applies to the Kirill and Luke Mester projects. Rationally, it makes sense just to buy a better meter, new or used. Rationally, you shouldn't be wasting your time reading this post. Just an opinion.One of the great benefits of open source development is that it allows individuals to build on the work of others to achieve something much better. I am looking at the OLED upgrade by xyphro here:https://www.eevblog.com/forum/testgear/hp3548-hp3457-oled-display/https:/www.eevblog.com/forum/testgear/hp3548-hp3457-oled-display/msg3985580/#msg3985580It would be a great companion project, especially if the OLED upgrade included an I2C interface to the daughter board.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 30, 2022, 07:19:24 pm
content: Quote from: fenugrecThis is exactly what I have in mind. A plug-in replacement for the existing uP. That would be the only hardware mod required. Well within the capabilities of most. The existing ROM/RAM can be left in-place and simply ignored.Quote from: fenugrecIt would only be a challenge if the layout attempted to remain within the 40pin foot print. There is plenty of room to allow the daughter board to extend well outside the DIP40 package size.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 30, 2022, 08:20:21 pm
content: HiIn looking at the feasibility of replacing the digital side uP, I have identified the serial interface to the analog side uP as critical for success. I want to dis-assemble the analog uP code to get a complete understanding of how it works. It is the core feature of the meter. To start with, I needed a dump of the binary code. Thanks to fenugrec who pointed me to this link:http://www.ko4bb.com/getsimple/index.php?id=download&file=HP_Agilent/HP_3478A_Multimeter/HP_3478A_DMM_EPROM-HP_3478A_Analog_8049_2301A05291.binI installed Ghidra and attempted to disassemble the binary. The report said no instructions found. I am probably doing something wrong.Has anyone run Ghindra against the analog side 8049 binary?

author: DC1MC
author_rank: Super Contributor
timestamp: December 30, 2022, 08:48:12 pm
content: No Ghidra, but from another thread I've used DASMX (working nicely under wine on Linux) and the assembly file is pretty understandable, have a look.Cheers,DC1MCEDIT: linkhttps://csdb.dk/release/?id=200357

author: dazz1
author_rank: Frequent Contributor
timestamp: December 31, 2022, 03:53:16 am
content: Quote from: DC1MC on December 30, 2022, 08:48:12 pmHiThanks. That is useful. I has been 30 years since I last worked with assembler so I have a bit of relearning to do.Are you able to confirm whether the binary source you used is the same as the one I linked in above?I just want to have another go with Chidra

author: DC1MC
author_rank: Super Contributor
timestamp: December 31, 2022, 04:29:38 am
content: Yes, the binary is from the link you've posted. I'll try making one with Ghidra as well, for reference.EDIT: I've made one with the latest Ghidra (what a cumbersome program), I guess its strength is the whole interactive graphical, C-function builder stuff, bottom line is it works and produces results, have a look.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 31, 2022, 07:06:57 am
content: HiI ran Ghidra on the binary again and I got the same output you posted. I now need to figure out how it works. I anticipate that many sub-routines will refer to specific ports. That by itself will help point toward the purpose of each routine.

author: retiredfeline
author_rank: Frequent Contributor
timestamp: December 31, 2022, 07:28:42 am
content: Just to add that for my 8048 projects I used the ASXXXX assembler athttps://shop-pdp.net/ashtml/asxxxx.phpwhich has extensive features, but maybe the code you hope to extract isn't that complex.

author: dazz1
author_rank: Frequent Contributor
timestamp: December 31, 2022, 08:12:57 am
content: HiI have just watched a Ghidra tutorial video, taken a quick tour of both Ghidra and the HP3478 code. Ghidra may not be the best, easiest to learn or run, but I will just go ahead and use it. Ghidra will do the job.The analog uP code doesn't have too much to do and looks relatively straight forward. It needs to do at least:operate the hybrid ADC,read and parse commands from the digital side uP,write output to the digital side,handle and report errors and,switch measurement modes.I don't have much spare time to spend on this, so I expect it will take me longer than anyone thinks it should.

author: retiredfeline
author_rank: Frequent Contributor
timestamp: December 31, 2022, 11:20:57 am
content: The 8048 is small enough that makes reverse engineering the code easier, e.g. only 64 bytes of RAM, 8 (or was it 4) levels of subroutines, only a couple of interrupt vectors, hardly any peripherals, only the IO ports and timer. Oh and a couple of testable input pins.

author: fenugrec
author_rank: Frequent Contributor
timestamp: December 31, 2022, 04:23:07 pm
content: for mcs-48 in ghidra : there are currently a few bugs / limitations that have fixes pending a merge hopefully soon :https://github.com/NationalSecurityAgency/ghidra/pull/4825- mcs48 ROMs larger than 2kB was nearly impossible to analyze (should be irrelevant for the analog CPU dump)- MOVP and JMPP opcodes were broken but less severely. I think the disasm still looks ok, only the decompilation was invalid.If you want to work on the digital ROM, don't even waste your time without the above patchset.I don't mind sharing my ghidra project but there's no easy way to collaborate on a database, unless maybe we can tryhttps://www.ghidra-server.org/It's absolutely overkill, and a huge software package with a serious learning curve, but the greatest advantage is simply labeling functions, RAM data, and finding cross-references. C decompilation is icing on the cake, really makes it easy to see at a glance what a function is up to.But... are you thinking of reimplementing the analog CPU side ?

author: DC1MC
author_rank: Super Contributor
timestamp: December 31, 2022, 04:34:33 pm
content: IMHO, the analog side should be left alone, what needs to be decoded is the communication protocol, so the digital side could be kicked out and replaced with an Arduino or similar that is easy to program. this is the only tough nut, controlling the display and keyboard should not be a problem.As far as I can see there is exactly one link per direction between the digital and analogue part (page 154 from here:http://www.arimi.it/wp-content/Strumenti/HP/Multimetri/hp-3478a-Service.pdf).The communication is either asynchronous, like a standard UART, or some type of semi-duplex synchronous, where one side "clocks" the data out of the other. In any case, not rocket surgery IMHO, unfortunately I don't have a device, but I would scope at P27 (pin38)(TP7) and and T1 (pin30) at the digital side MCU, I would use T1 as the clock source and P27 as data (they'll switch places).More EDIT: P2 seem to also hold the calibration for the ADC, on the first 6 bits (P20 to P25), P27 is our output and I have no clue if P26 is used for something. the analogue side doesn't have the interrupts active at all, it seems that there is only one infinite loop and the analogue side is the slave that responds on digital side requests.

author: Miti
author_rank: Super Contributor
timestamp: December 31, 2022, 09:12:41 pm
content: Quote from: dazz1 on December 30, 2022, 07:10:35 pmI didn't mean to touch a nerve, I just expressed an opinion, I apologize if it was misinterpreted.If you really want to know my approach to useless projects in general is ... Ok, let's do it!Quote from: dazz1 on December 30, 2022, 07:10:35 pmI disagree, Kirill's project adds important functionality in a very non invasive way, Luke's program allows us to save, upload and edit the calibration constants.Quote from: dazz1 on December 30, 2022, 07:10:35 pmNow that is a very interesting project, thanks for the link!. I may make one for my 3478A, even though my backlight project is not too bad.https://www.eevblog.com/forum/testgear/hp3478a-backlight-my-version/msg1505830/#msg1505830

author: dazz1
author_rank: Frequent Contributor
timestamp: January 01, 2023, 02:01:16 am
content: Quote from: MitiLets not. If upgrading obsolete old equipment is rationally futile, then debating about it is even more so. I enjoy upgrading obsolete old tech by adding some new tech.Quote from: MitiI agree with your disagreement. I see their work as complimentary and compatible with what I am looking at doing. We are just approaching the problem from a different angle. Neither is right or wrong, just different.I am also looking at enhancing the GPIB command set to the point that one of the first things I will need is a GPIB<>USB adapter.Quote from: MitiI was also planning on doing the LED backlit mod until I saw the OLED version. When combined with a I2C interface that bypasses the limitations of the HP LCD driver, it would open up doing and displaying things that would otherwise be too difficult.I have attached a document which is effectively my feasibility study. I wrote this so if I took on the project, I would know if it could be achieved, and how. It will take a lot of work but once that is done, it will be a simple and easy upgrade to replicate. The document is heavily truncated to fit within the file size limits of this site so if you think there is something missing, you will probably be right. I am not yet committed to doing this mod but I thought there might be some interest on the forum. If it was implemented, it would expand the range of possible enhancements to local and remote functionality.

author: Miti
author_rank: Super Contributor
timestamp: January 01, 2023, 02:18:55 am
content: Quote from: dazz1 on January 01, 2023, 02:01:16 amI meant let’s do the project, not let’s debate about its usefulness.Happy new year!

author: dazz1
author_rank: Frequent Contributor
timestamp: January 01, 2023, 03:40:39 am
content: Quote from: MitiYes, lets do the project.Lets all have a good year.

author: dazz1
author_rank: Frequent Contributor
timestamp: January 01, 2023, 10:15:14 pm
content: HiAfter a lot of thought, I have decided to suspend further work on this project. I have too much stuff happening in my life to be confident that I could finish this project. I think the only thing worse than not starting something is to not finish something that has been started.The upgrade of the HP3478A is exactly the sort of project I like doing. It is definitely achievable but it will take more time than I will have. I will review my decision in about a year. In the mean time, there is nothing stopping anyone else following this path.

author: dazz1
author_rank: Frequent Contributor
timestamp: January 04, 2023, 06:59:56 pm
content: HiToday this link arrived in my email inbox.It demonstrates a similar concept of a drop-in daughter board as a replacement for a Z80. As with my proposal, the daughter board runs a modern micro controller to achieve features not possible with the original. In this case, a Z80 emulator.https://hackaday.io/project/188682/gallery#e3178d20b932f30dee4ce75fe509be1a

author: DC1MC
author_rank: Super Contributor
timestamp: January 04, 2023, 07:26:29 pm
content: The project is without any doubt totally feasible, the problem is that is an extreme niche project, the (very) few owners willing to "hack" their 3478 of the already small total number of working 3478. And (at least in EU) is not a cheap device, for the price one gets to acquire a working 3478 he can get a modern desk multimeter that has all the software bells and whistles, including graphical displays.Im pretty sure that you'll not find 10 people willing to spend, let's say 25EUR each to push this project, and after looking at the assembly code there, there is a "cool, let's have a look" phase, followed pretty soon of "eh well, it starts to look like work, won't make you famos and is tedious, let's drop it".Personally I don't have this device, but I do have a number of Datrons, and I'm considering for a long while to do something similar, but is another ultra-niche thing.So basically phase 1 of the project is to document the serial protocol between digital and analogue domains and then in phase 2 decided what do you want to improve/add/replace. Phase 2 is really the simple phase, once we reach it, adding functions is not a big deal.But I'm really curios if there is any 3478 owner willing to commit enough to open his device and hook wires, scopes, logic analyzer and stuff, and also spend time. i'm not holding my breath tough

author: dazz1
author_rank: Frequent Contributor
timestamp: January 04, 2023, 11:43:58 pm
content: HiHistorically new tech becomes throw-out tech before becoming collectible. My current project is to build an electronic driver for an ancient Italian flip clock, originally driven by 48V bipolar pulses on the West German Telecom network. Right now it is just a useless wall ornament but old enough to be highly collectable. The driver will display time on the clock based on either a NTP internet server or my Synchronome pendulum master clock designed in the 1920s, all via wifi. The need to finish the clock driver project has driven my decision to suspend work on the HP3478A processor upgrade. Both projects are highly niche.There is enough information already in the public domain to be able to do the HP3578A project without breaking out logic analysers, oscilloscopes etc. Phase 1 will just take time and effort. From my perspective, it doesn't matter if anyone follows my upgrade. I won't benefit or profit by it.The Datrons must also be now in the collectable stage of their life.

author: dazz1
author_rank: Frequent Contributor
timestamp: January 06, 2023, 07:56:39 am
content: HiPerhaps the wider interest for this project will come from any item that is running the 80xx microprocessors. This might include the iconic 8051. There is probably a lot of 80xx based equipment out there running undocumented and unsupported assembler. A drop-in replacement that includes its own RAM/ROM/USB/I2C and programmable in modern C/Python etc might be a solution for someones problem.

author: Kleinstein
author_rank: Super Contributor
timestamp: January 06, 2023, 08:25:30 am
content: There is no need to replace 8051 µCs. There are plenty of compatible (mainly 8052 like) versions with many variations of internal RAM / ROM and also higher speed.Though a bit tricky for the compiler there are C compilers for the 8051 type µCs, likely because of the popularity of the µC. Python is anyway not that good idea for a µC - just not for the typical µC tasks.The 3478 firmware is not really missing important parts and AFAIK no major bugs. So the incentive is low for a more minor upgrade with quite some effort (extra HW and new to develop software).There might be an interest if one could add a relative function (the main point missing) to the existing software. So that a simple swap of the ROM would be sufficient. This would however need some luck (enough spare space in the ROM). The main point would be understanding the old code - maybe a project for a bored individual who needs a challange. Adding the extra function is than likely the smaller part - if there is space.

author: fenugrec
author_rank: Frequent Contributor
timestamp: January 06, 2023, 03:12:46 pm
content: Quote from: Kleinstein on January 06, 2023, 08:25:30 amThat is already done. Despite publishing the info and a patched rom, I'm not aware of anyone else even trying the patch.

author: dazz1
author_rank: Frequent Contributor
timestamp: January 09, 2023, 06:23:32 am
content: Quote from: fenugrec on January 06, 2023, 03:12:46 pmHiLooking more closely at the pinouts of the 8039 and 8051, they are incompatible. Bad idea that I hadn't researched before posting.Designing a daughter board to replace 8039 on the digital side would not be excessively difficult.Rewriting the firmware in a high level language would require the most effort. It looks like Ghidra could be a big help with that process.I am thinking that Ghidra would be helpful fully understanding the ADC code running on the analogue side. There maybe some gold nuggets in that knowledge that could possibly enable more capabilities.This would be one of those projects that never quite gets to 1m subscribers.

author: fenugrec
author_rank: Frequent Contributor
timestamp: January 09, 2023, 01:40:56 pm
content: Quote from: dazz1 on January 09, 2023, 06:23:32 am1 milli-subscriber is probably realistic