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?