Phillips PM3394 Combiscope firmware wanted.

[grumpydoc]

So, I have EHT's CPU card from his Phillips 'scope which won't boot - Fluke PM3394 Microprocessor Fault

Turns out the problem is corrupt/faulty flash ROMS, if I put the ROMs from one of my spare CPU cards into his it boots just fine. Move his ROMs into my 'scope and it doesn't.

I can re-flash new ROMs for him but I don't have the right firmware image - his originally had the extra maths package and I don't have a 3394 with that option. I have a 3394A and 3394B with extra maths but the firmware from those 'scopes won't do because a) they switched to SMD flash chips and the only way to read them would be to unsolder them - which I'd prefer not to do and b) even if I got the code it probably won't run on a 3394 CPU card because the hardware is different.

Does anyone have a 3394 and the ability to dump the two 28F020 flash chips - if so would they be willing to do so and send me the images, or the ROMs themselves and I can copy them.

The corrupt image is dated 1993-06-12 but I don't think that it has to be exactly that version, mine (which lack the extra maths stuff but boot) is dated 1992-04-12

It would be much appreciated by EHT, I am sure

[grumpydoc]

No one? 

[HighVoltage]

Sorry to say, I have only PM3394B left in my lab. All the older models are gone.

[grumpydoc]

I thought that might be the case.

Given that even the B models are now more than 20 years old we are starting to get into the territory of worrying about flash endurance, especially as the inside of the 'scoope is warm if not exactly hot. It might be a good idea to start thinking about making backups of the firmware. Sadly they changed the design significantly for the "A" switching to SMD parts and allowing for up to 4x 28F020 (the most I have mounted on a board is 2x 28F020 and 1x28F010).

Thankfully I do have a copy of the basic firmware to flash so with luck EHT should be able to get the 'scope up and running.

I'm beginning to think buying one of these http://www.ebay.co.uk/itm/Enplas-TSOP32-TO-DIP32-A-IC-Programmer-Adapter-for-TSOP32-TSSOP32-package-/282227617550 and carefully desoldering the chips might be the best long term plan.

[HighVoltage]

One of my customers might still have an original PM3394 in use. I will have a look when I am visiting him in about a month time and if so, give him a 3394B loaner. I will keep you updated, if I am successful.

[grumpydoc]

One of my customers might still have an original PM3394 in use. I will have a look when I am visiting him in about a month time and if so, give him a 3394B loaner. I will keep you updated, if I am successful.

Very kind, sir - definitely above & beyond. Let me know if you have any luck.

[EHT]

Yes, much appreciated! Thank you both very much for your efforts.

I can see keeping a backup of the flash memory for these models would be beneficial for the user community. Btw, I notice the scope I have acquired didn't have the batteries installed; perhaps the flash can get corrupted powering the scope off without the battery backup...

[grumpydoc]

Yes, much appreciated! Thank you both very much for your efforts.

I can see keeping a backup of the flash memory for these models would be beneficial for the user community. Btw, I notice the scope I have acquired didn't have the batteries installed; perhaps the flash can get corrupted powering the scope off without the battery backup...

Shouldn't do - the 5V backup just preserves the RTC and SRAM for the current 'scope settings.

[EHT]

I found the attached PDF doc via a search, and also looked at the svc manual (snippet attached).

It describes Philips programming the scopes externally via RS232, including from empty. That would make sense especially for the models with the chips soldered in: "Embedded software and calibration data can be loaded/exchanged with dedicated PC software that is exclusively available in manufacturing and service.". Pretty rubbish that the flash fills up after saving 10 cals and needs to be reflashed by Philips! Another reason backup would be useful. If we knew how to program via RS232, then it would make a much easier process for others to backup/restore.

As you say, Grumpydoc, the battery is only protecting the session state in RAM. I suggest that means the CPU could corrupt the flash if it is turned off while writing, theoretically at least (e.g. enterprise grade SSDs & RAID controllers have protection against this).

[grumpydoc]

It describes Philips programming the scopes externally via RS232, including from empty. That would make sense especially for the models with the chips soldered in: "Embedded software and calibration data can be loaded/exchanged with dedicated PC software that is exclusively available in manufacturing and service.". Pretty rubbish that the flash fills up after saving 10 cals and needs to be reflashed by Philips! Another reason backup would be useful. If we knew how to program via RS232, then it would make a much easier process for others to backup/restore.

As you say, Grumpydoc, the battery is only protecting the session state in RAM. I suggest that means the CPU could corrupt the flash if it is turned off while writing, theoretically at least (e.g. enterprise grade SSDs & RAID controllers have protection against this).

I have previously looked for the mysterious PC program but I think that it was never released outside Philips, looking at the firmware I can see that as well as the documented commands there appear to be  "CF", "DW", "EM", "EO", "EX", "PF", "QC" and "QF" but what they do or what parameters they might take is anybody's guess.

[HighVoltage]

I have previously looked for the mysterious PC program but I think that it was never released outside Philips, looking at the firmware I can see that as well as the documented commands there appear to be  "CF", "DW", "EM", "EO", "EX", "PF", "QC" and "QF" but what they do or what parameters they might take is anybody's guess.

I know a guy who has the software but is very tight about it and will not make a copy, although these instruments are now 20+ years old. He was the chosen one that continued the official service for "PM" instruments, when Philips stepped out of it. May be one of these days I will convince him to make a copy and hand me the manual.

[CJay]

It describes Philips programming the scopes externally via RS232, including from empty. That would make sense especially for the models with the chips soldered in: "Embedded software and calibration data can be loaded/exchanged with dedicated PC software that is exclusively available in manufacturing and service.". Pretty rubbish that the flash fills up after saving 10 cals and needs to be reflashed by Philips! Another reason backup would be useful. If we knew how to program via RS232, then it would make a much easier process for others to backup/restore.

As you say, Grumpydoc, the battery is only protecting the session state in RAM. I suggest that means the CPU could corrupt the flash if it is turned off while writing, theoretically at least (e.g. enterprise grade SSDs & RAID controllers have protection against this).

I have previously looked for the mysterious PC program but I think that it was never released outside Philips, looking at the firmware I can see that as well as the documented commands there appear to be  "CF", "DW", "EM", "EO", "EX", "PF", "QC" and "QF" but what they do or what parameters they might take is anybody's guess.

I wonder if the Phillips FTP server still exists...

It used to hold all sorts of gems like alignment software for high end computer monitors that was 'restricted' to service agents

[grumpydoc]

I have previously looked for the mysterious PC program but I think that it was never released outside Philips, looking at the firmware I can see that as well as the documented commands there appear to be  "CF", "DW", "EM", "EO", "EX", "PF", "QC" and "QF" but what they do or what parameters they might take is anybody's guess.

I know a guy who has the software but is very tight about it and will not make a copy, although these instruments are now 20+ years old. He was the chosen one that continued the official service for "PM" instruments, when Philips stepped out of it. May be one of these days I will convince him to make a copy and hand me the manual.

Given that I've been looking at the CPU card & firmware on these 'scopes again and also have been playing with a cheap USB LA (one of the 8ch 24MHz saleae clones) I find my myself motivated to look at reverse engineering the firmware once more.

The 8ch LA is not really enough but it piqued my interest enough to get a better USB LA - this time a 16Ch 400Mhz DSLogic Pro (probably a clone given the price) which is plenty to start by mapping the address decode PAL.

The PAL is arranged with 10 inputs A₁₄ and A₁₅ from the CPU, 4 lines from CPU port 1 labelled SELA₁₅ - SELA₁₈, two further bits from port 1 labelled PROGENLT and TEXTENLT,  the CPU INST output and EA

It generates chip selects for the RAM and two ROMs, address bits 15-17 for the ROMs (A₀ through A₁₄ for both the ROM & RAM come from the CPU), and some further select signals (IOCS and TXTCS).

This the basic scheme would seem to be to split the 64k CPU address map into 4 16k chunks and to expand the ROM address space to 20 bits. However as the ROM & RAM chips see A₀ - A₁₄ direct from the CPU they are probably mapped in 32k chunks. However as "INST" is an input so RAM could be mapped at the same address as ROM, or they could use that to map I/O space over ROM.

1024 input combinations was always going to be too much to map by hand but a 16ch LA would be fine to cover most of the inputs (only really need the clock and the final carry out so I know when the count rolls over to all bits 0) and 8 outputs - all I need then is a clock signal and a few 74xx191's (which I know I have in the parts bin) to generate the inputs.

I'll see if I can do that this weekend (if the new LA turns up).

The "A" and "B" boards are completely different - a PLS 173 is used, the address inputs go from A₁₂ to A₁₅ so potentially there is much finer grained control over the memory map (though the ROM & RAM still have to be 32k contiguous) and the outputs do not include the expanded address lines for the ROM, just various chip selects.

[grumpydoc]

I wonder if the Phillips FTP server still exists...

It used to hold all sorts of gems like alignment software for high end computer monitors that was 'restricted' to service agents

If it was ftp.philips.com then there is an IP address but no FTP server

ftp.fluke.com answers but does not allow anonymous log in.

[EHT]

I have previously looked for the mysterious PC program but I think that it was never released outside Philips, looking at the firmware I can see that as well as the documented commands there appear to be  "CF", "DW", "EM", "EO", "EX", "PF", "QC" and "QF" but what they do or what parameters they might take is anybody's guess.

I know a guy who has the software but is very tight about it and will not make a copy, although these instruments are now 20+ years old. He was the chosen one that continued the official service for "PM" instruments, when Philips stepped out of it. May be one of these days I will convince him to make a copy and hand me the manual.

That is tantalizingly close. The firmware which supports this must be in the Microcontroller's ROM given that it would appear than blank Flash ROMs can be programmed. As such, it must be pretty simple. I guess there is a front-panel key combination that puts it into RS232 programming mode, then some simple terminal commands to allow upload, download and verification of the Flash ROM firmware. Rather than seeking the original software, if we could find out how to enter the programming mode and what the commands to be sent on RS232 are that would do the trick.

[CJay]

I'd be tempted to try and read the 80C196 EPROM to decipher the bootloader if it's unprotected, I don't *think* it's possible to do the 805x EA trick on the 'C196 if it's been read protected (BICBW) which is a shame.

[grumpydoc]

I'd be tempted to try and read the 80C196 EPROM to decipher the bootloader if it's unprotected, I don't *think* it's possible to do the 805x EA trick on the 'C196 if it's been read protected (BICBW) which is a shame.

Might not be that easy without being willing to sacrifice the CPU board.

I just realised that the CPU only samples EA at reset so it isn't that easy to jump in and out of the mask ROM code - it presumably sets up the memory map then toggles EA and probably then executes a RST instruction - so, at that point, there must be ROM mapped at address 2080H

My plan, once the new LA arrives was to snoop the address bus to find out where execution starts - might not need that if I know where the entry vector is and how the address mapping works.

[grumpydoc]

OK, well, my new LA has not turned up so am annoyed about that. However managed to pull the programming from the address decode PAL in the 3394 usng the little 8ch Saleae clone and multiple captures.

The memory map is not quite as I anticipated but for anyone who might be working on these 'scopes in the future here it is for reference.

Philips/Fluke PM33xx Combiscope memory map:

0000H-3FFFH	ROM bank 0 1st 16k
4000H-7FFFH	Normal operation (EA=0) Data reads & writes (INST = 0) RAM Instruction fetches (INST = 1) ROM bank 0 2nd 16k Mask ROM operation (EA=1) RAM
8000H-BFFFH	Data reads & writes (INST = 0) PROGENLT=0 - ROM (1st 16k of current bank) PROGENLT=1 - RAM Instruction fetches (INST = 1) Banked ROM (1st 16k of current bank)
C000H-FFFFH	Data reads & writes (INST = 0) PROGENLT=0 - ROM (1st 16k of current bank) TEXTENLT=0 - CURCON memory (?) Neither of above  - I/O Instruction fetches (INST = 1) Banked ROM (2nd 16k of current bank)

SMF does not appear to do nested tables terribly well 

Port 1 bits 0-3 (SELA15-SELA18) select the bank address - SELA18 just switches between the two ROMS. The bank address is not passed through for any access in the first 32k of the processor address space.

RAM physical addresses are swapped - the 16k mapped from 4000H-7FFFH is the top 16k of the RAM and the area mapped from 8000H-BFFFH is the bottom 16k of the RAM.

The I/O space is further decoded by the 74LS183 D1016 which produces various write strobes and by a couple of OR gates for the UFO read strobe and OPTCSLT (wherever that goes).

The raw CSV for the PAL truth table is attached in case anyone either needs to program a new part or check the above.

http://www.wild-pc.co.uk/docs/3394-addr-decode-pal-csv.csv

At some point I'll look at the 3394A/B PALS.

[grumpydoc]

I'd be tempted to try and read the 80C196 EPROM to decipher the bootloader if it's unprotected, I don't *think* it's possible to do the 805x EA trick on the 'C196 if it's been read protected (BICBW) which is a shame.

The (probably) bad news is that the chip configuration word in the ROM image sets the protection bits to prevent the on-board ROM being read or written. A bit academic since we really need to know what is coded into the CCB in the mask ROM but I'll bet it is the same value.

What's the 805x EA trick?

[CJay]

You could, on a lot of the older 805x chips, persuade the chip to copy internal ROM out from a 'protected' chip by diddling with the EA pin to between external and internal, from a quick read of the 80C196 it appears you can only alter the state at reset which would prevent that.

[grumpydoc]

You could, on a lot of the older 805x chips, persuade the chip to copy internal ROM out from a 'protected' chip by diddling with the EA pin to between external and internal, from a quick read of the 80C196 it appears you can only alter the state at reset which would prevent that.

That would be too easy!

Anyway given that we know the memory map and it should be possible to guess at what hardware initialisation is being done so I "just" need to reverse engineer the code. Sensibly it is probably not worth it but the task has got under my skin. However I'm sure there are still a decent number of these 'scopes in the wild as a steady trickle turn up on ebay.

All I need now is an 80C196 assembler & disassembler.

I have an assembler - well it compiles so we'll see whether it runs OK in a while.

But I can't find a decent open source disassembler - just some (rather expensive) commercial offerings. Radare2 has some support for mcs96 but it is very bare bones  - it just prints the instructions without even any decoding of the operands.

Mame can emulate the 80C196 but it is hardly general purpose and it doesn't have hooks to print disassembled listings. However between its CPU definition, the Radare2 header listing the instructions and the users guide there is a reasonable amount of information about the machine code.

I've started to write one but I'd rather not have to do that to be honest.

Anyone know of an available disassembler (needs to be open source and compilable on Linux)?

[EHT]

How about this one: IDA - https://www.hex-rays.com/index.shtml

Cross-platform and they have a free non-commercial version. It appears the free one supports 80196:

https://www.hex-rays.com/products/ida/processors.shtml
https://www.hex-rays.com/products/ida/gallery/80196.shtml

Good luck!

[grumpydoc]

How about this one: IDA - https://www.hex-rays.com/index.shtml

Yes, I loked there.

It seems I missed the freeware but I finally spotted the link, thanks.

However it looks to be a very old windows only version - I tend to prefer Linux as a development environment.

I've started writing one now, coming along nicely.

[EHT]

Oh. It said elsewhere that they build Linux, OSX & Windows versions.
Also it says "INTEL 80196 (comes with source code)".

Maybe you would need to download the code and compile it, if not at least you should have some useful code for the 80196 instructions there?

[grumpydoc]

Oh. It said elsewhere that they build Linux, OSX & Windows versions.
Also it says "INTEL 80196 (comes with source code)".

Maybe you would need to download the code and compile it, if not at least you should have some useful code for the 80196 instructions there?

I can only find a windows exe for the freeware version. I probably will download it when I get home and see if any useful info can be harvested.

There is also an evaluation copy but TBH it won't be much use  - it only does x86 and arm and only "structured" binaries such as ELF.

I doubt that the "source code" is any more than a few extensions and/or plugins but I didn't see the claim that the 80196 version came with any - do you have the link to the page?

[grumpydoc]

Nope - freeware version only does x86 and ARM, some bits of files for other architectures (but not 80C196) are lying around in the install but it did not offer me those processors when I asked it to disassemble the ROM image.

The demo has had everything except arm/x86 stripped out.

[grumpydoc]

Well, Hex Rays isn't going to come up with the goods without me parting with $$.

Luckily the users guide has basic information about the instruction set and opcodes and mame http://www.mamedev.org has an 80196 emulator which provides very good documentation by dint of reading the source code. So after only took a couple of hacking sessions I have a basic disassembler, I have almost all the instructions/addressing modes done with the sole exception of handling the FE prefix which makes mul & div operations signed.

Current output is looking like this

3590            fa              di
3591            a1 00 01 18     ld 18, #0100
3595            00 01           skip 01
3597            a1 00 5c 18     ld 18, #5c00
359b            a1 00 58 34     ld 34, #5800
359f            a1 53 53 32     ld 32, #5353
35a3            c2 35 32        st 32, [34]+
35a6            89 00 5c 34     cmp 34, #5c00
35aa            d7 f7           jne 35a3
35ac            a1 00 5c e8     ld e8, #5c00
35b0            01 ea           clr ea
35b2            a1 00 5c 34     ld 34, #5c00
35b6            a1 41 41 32     ld 32, #4141
35ba            c2 35 32        st 32, [34]+
35bd            89 00 60 34     cmp 34, #6000
35c1            d7 f7           jne 35ba
35c3            b1 16 03        ldb 03, #16
35c6            11 08           clrb 08
35c8            11 13           clrb 13
35ca            11 09           clrb 09
35cc            11 12           clrb 12

The above is where the code goes on reset (the reset vector just contains a jump to 3590H). It seems to be filling from 5800H to 5BFFH with the value 53H and the area from 5C00H to 5FFFH with 41H. The 1k from 5800H to 5BFFH is obviously the stack but why initialise it? The usual reason for doing so with a known pattern is to check that you did not overflow it but that's mainly of use during development, not production.

If they left stack dev/debugging code in the final image perhaps they left other useful stuff - maybe even the ability to reflash the code; one can hope

I also wonder slightly whether any of this was generated by a compiler rather than being written in assembler, for instance the sequence

clrb 08
clrb 13
clrb 09
clrb 12

does not strike me as something one would write - why do the 4 individual byte clears when

clr 08
clr 12

would do the same thing, even if they are used as 8 bit values later?

Unfortunately just deciphering the instructions does not make a terribly useful disassembler - I need to teach it how to generate and use a symbol table and how to figure out what is likely to be code and what data (by traversing what can be reached from known entry points) and how to spot strings etc. It also need it to generate something that can be used as input to the assembler. I need to come up with some test code to make sure that the output is correct and ideally get to the point where i can do binary -> disassembler -> assembler -> binary produces the same output as input. That lot should take me at least until the weekend and my currently abandoned Z80 board project deserves a bit of time as well. Looks like I'm going to be busy even without all the c**p I need to do for work.

[grumpydoc]

Turns out one of the copies of the firmware that I have includes the maths package after all.

However it does not have the GPIB support - I'm slightly surprised that this was not done with one version of the firmware just detecting what hardware was present but it does mean that it is not possible to upgrade one of these 'scopes by installing the missing GPIB hardware unless one also installs a copy of the firmware with GPIB support.

[HighVoltage]

Interesting.
So, you think they had a separate FW for each option that was added?
That must have been a lot of FW versions.
 

[grumpydoc]

Interesting.
So, you think they had a separate FW for each option that was added?
That must have been a lot of FW versions.

From what I've seen the presence or absence of the maths package and GPIB support would lead to at least 4.

Originally I thought the maths package "must" be quite large and be the reason that EHT's 'scope had the larger ROMs but, on reflection, it might be the GPIB support which, after all, needs not just the hardware drivers but also the whole SCPI interpreter as well.

In the 512k ROM (GPIB + MP) about 48k is blank.

In my 384k of ROM neither of which have GPIB  I have 40k blank in the image without the maths package and 34k in the one with - so the extra maths stuff might only be 6k. Not implausible as it will presumably be DSP code (the DSP doesn't seem to use/have mask ROM so at present I'm assuming the main CPU copies code into the DSP program RAM at start-up).

That suggests the SCPI interpreter could be just over 100k - which seems a lot, to be honest. We'll know if I ever disassemble the ROMs (however that is going to be a long term project).

I don't know how easy it was to get the service manual when these 'scopes were new but I guess Phiips would not have wanted it to be trivial to just slap the missing GPIB hardware onto the CPU board - I'll bet the cost of the option was a lot more than the parts.

[CJay]

Phillips used to try to compartmentalise their business but if you had an account you could usually get away with ordering anything you could find a part number for, most service manuals were free to Phillips account holders, you'd order it as 'first issue' and a few days later it'd turn up in the post FOC.

Obtaining the part numbers for service manuals could be an art form in itself but a Viewdata account was useful as you could browse their 'catalogue' and find all sorts of wonderful things, it was also often beneficial to be able to banter with the people on the tech support lines as they'd be able to provide all sorts of 'forbidden fruit', it's how I found the I2C alignment software for monitors for instance.

They were excellent at supplying parts but some things were 'modules' and you just could not get anything other than the whole, which spawned a lucrative trade in module refurbs by companies like MCES (Manchester Colour Engineering Services) who would repair TV Tuners, video heads, satellite TV LNBs etc...

[HighVoltage]

Philips was amazing in those days.
When I was at the university, they had even really good engineering text books (free of charge), explaining their technology, including the basis for calculations and manufacturing. One could learn so much from those text books, because it reflected the Philips production line.

Too bad they were bought by Fluke.
 

[SaabFAN]

Interestingly, for the previous scopes (PM3320-Series), the firmware did include all options but activated FFT-Functions and most likely what kind of device one was owning (PM3320, PM3320A, PM3323, PM3340) was encoded somewhere else. I haven't been able to figure out where, however. The most likely place would be one of the PAL-Chips.

Btw. I constantly get the feeling the Philips T&M-Instruments were more or less an attempt to sell their in-house developed test equipment than an actual attempt at getting into the T&M-Market. And when it became cheaper to just replace than repair the market for T&M-Equipment went down enough to send that Department on the "Philips Way": Develop something, perfect it, then sell it (often enough an entire part of the company) to the highest bidder and invent the next great thing.

[lunacyworks]

Has anyone had any updates? This thread went dead with the finality of the matter.    I ask as I will be inheriting one of these scopes this week. Was hoping to use it as a project in one of my STEM classes.

It seems it would be a great concept to archive or even reserve engineer the firmware.

[shakalnokturn]

It kind of follows over here:
https://www.eevblog.com/forum/repair/fluke-philips-pm3394a-combiscope-preventive-maintenance/

[grumpydoc]

The main thing from my point of view is the reverse engineering of the ROM code - but it's gone a bit back burner again.

I need to tweak/beef up the handling of data symbols and tables etc, not sure how much I can do heuristically (probably not much), it's not helped by the fact that the code has a lot of computed jumps so the usual heuristic of following jumps & calls from known entry points only finds a small amount of the code.

I'll post the listings when I'm happy with them - but only about 75% of the way to that point at present.