Hi,
Just thought I'd share a project I'm starting; I expect I'll need some help with MAME internals to get this done !

Target is a popular old piece of electronic test equipment, the HP 3478A DMM. Full service manual and shematics are available, as well as a full ROM dump hosted on KO4BB . I have dumped my own unit with a logic analyzer and confirmed they were identical.

Some pics on https://sigrok.org/wiki/HP_3478A

Hardware is fairly simple, with a twist.

- Intel i8039 (MCS-48 family, already supported in MAME I believe, for some "kaypro" gadget ?) , internal OTP ROM not used
- 8kB EPROM (dumped)
- 256-byte calibration RAM, also dumped but not function-critical
- LCD display module accessed through a weird 4-signal serial link; I've identified that code in the ROM so the first iterations will have those parts patched / bypassed
- Main CPU talks to a secondary CPU on the analog side, over a half-duplex serial link. This part is of no interest to me, and will be summarily patched too.

The twist is that the 8039 has a 4kB address space. The 3478 hardware implements hardware banking, where one of the IO pins drives the A12 address line.

My partially annotated ROM disassembly along with some notes :
https://github.com/fenugrec/hp3478a_utils/tree/master/ROM_disasm

My goal isn't to have a full emulation working - a bit meaningless for a test instrument. But I'd like to have the firmware run properly and handle the UI (4x4 keypad and display) so I can move on to part 2, which is modifying the ROM to add a missing feature.

Welcome!

Banked address spaces are something we get day in day out around this place so that's not a problem. The 4-wire LCD controller sounds like possibly I2C or some similar serial protocol. Was there software for any HP computers that talked to this thing over (G/H)PIB?

ROM links for things that aren't games are almost always fine, we do a lot of work off of things available from bitsavers.org, after all.

Thanks. Do you (or anyone) have an example of a device I could refer to that implements this kind of simple banking ?

LCD : I2C wasn't very popular when these units were introduced; it's actually a clocked serial protocol that IIRC some other HP units share and I think has been documented to some extent, I vaguely remember an eevblog thread about this.

GPIB/HPIB indeed : the manuals mention an HP 85B / 9000 series computer, not sure about special software - probably not, the commands are pretty simple. That's about the extent of my knowledge of that side of things, though.

The eevblog thread about the LCD is here: https://www.eevblog.com/forum/projects/led-display-for-hp-3457a-multimeter-i-did-it-)/25/

It's for a different model, but looks like all the info is there.

Ah ! with some pointers from the folks in #mame-dev, I was finally able to compile mame and add an initial driver for this.

hp3478 git branch

So far only the CPU and hardware ROM banking are implemented; seems to work so far. Any comments ? especially on the IO port handling, I mix-and-matched code snippets found in other drivers...

next steps, ideas are very welcome :
- find a way to import my annotated disasm comments / symbols into mame's debugger so I don't go insane for the rest of this project
- patch / hook ? into ROM display functions to implement a primitive display without having to emulate the serial protocol
- patch (maybe the cheat mechanisms would be useful here ?) a few areas of the ROM that would hang waiting for unemulated hardware
- implement keypad reading and tie to a UI element, or maybe just keyboard shortcuts. Don't want to spend hours on this

You can abuse breakpoints to do some of these - breakpoint handler will execute debugger expressions (print messages to debugger window or logs, modify registers and memory &c). For example, a "bp fc4b8,1,{do cx=1;go}" will pretend that some check has actually passed.

Another example: log syscall handler entry and pretty-print its arguments (this is for GRiD Compass driver):

bpset fec9c,1,{ logerror "%% OsDskDriver "; go }
bpset feca5,1,{ temp2 = w@(ss*10+bp+0xc); temp1 = w@(ss*10+bp+0xc+2); temp0 = temp2 + temp1*10; logerror "(r = %2d) (xn %04x pBuffer %08x pos %08x length %04x mode %02x numbuf %02x intAddr %02x pOverflow %08x\n" ,w@(ss*10+bp+10) ,w@(temp0) ,d@(temp0+2) ,d@(temp0+2+4) ,w@(temp0+2+4+4) ,b@(temp0+2+4+4+2) ,b@(temp0+2+4+4+2+1) ,b@(temp0+2+4+4+2+1+1) ,d@(temp0+2+4+4+2+1+1+1) ; go }

MAME's debugger supports per-address comments, but the on-disk file format is kind of icky. You can get around it by converting your comment list to a text file of the form:

comadd 0x0, Boot
comadd 0x3, jump to secondary boot handler
comadd 0x38 IRQ

and then "source file.txt" when you start the debugger.

Thanks for the replies.


Ah yes, but can those work from within a device driver ? That's actually so ugly, I'm embarassed of even considering it. Other things I've thought of was inserting illegal opcodes and if possible trapping those. Meh.



Ok, that could work.

So, I spent the evening writing LCD emulation code I didn't want to write. It started out because I thought it would marginally simpler... still not sure about that one. On the plus side :

"TSET FLES" => SELF TEST, indeed.

What would be the simplest option to have this displayed "properly" (i.e. not in the error log !), with minimum amount of pain ? "terminal" sounds like not what I want; I saw references to 16-segment LEDs but I can't be bothered to map the entire charset to segments. There has to be a raw text renderer, I haven't found it yet...

The artwork system can do this. If you leave it how it is, eventually someone else (probably me) will hook it up. I did the Westinghouse thing we don't know the purpose of, ET3400, SITCOM, and a bunch of other things.

Granted, the artwork system would be the highest quality solution, but more trouble than I think is worth for this particular project...

Anyway, I have some medium-quality photos of the front panel and LCD segments ( ), but it doesn't seem like there's an official Artwork repo ?

I still think I'm just going to try the simplest text rendering I can find...