Products > Test Equipment

Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)

<< < (71/91) > >>

joeqsmith:

--- Quote from: SilverSolder on February 24, 2021, 06:05:37 am ---The file you attached isn't cleared to all zeroes?  Here's what I see in the file, it looks interesting - note the '07' snuck in line 1 and line 9.
--- End quote ---

Yeah, my posts are not always very clear.


--- Quote ---... it appears all the bits were set (this part is cleared to all zeros). 
--- End quote ---

From the datasheet, the part is cleared to 0's from the factory rather than the more common 1's.   From the datasheet, its a 1024 bit or 128 byte part.   Note the file is 2X that.  I assume the programmer doesn't use the upper nibble and the lower nibble represents Q0..3.  All of these bits were set (programmed with a 1), except for the two locations where Q3 was left in the factory cleared state.   

Q0 routes to U24 pin 20, !CS ( ! meaning active low for the context of this message)
Q1 routes to U23 pin 20, !CS
Q2 routes to U22 pin 18, !CS
Q3 routes to U20 pin 18, !CS

So only U20 would ever be selected.  Obviously, this is not correct.  So, again I suspect the programmer has a problem with this part.  If no one has a programmer that supports it (and willing to pull the part and read it), I think the next step is make an adapter to allow the programmer to read the PROM as a different device. 

joeqsmith:
Time for a second attempt.

joeqsmith:
Keep in mind the adapter is converting the 74S287 to a 2716.    A0-A7 routes to A0-A7 and Q0-Q3 routes to Q3-Q3.  The upper nibble is hardwired to zeros.

From the schematic, U18  A5 & 6 are hardwired to ground.  A7 routed to jumper W3 which defaults to ground.

U18 A0 maps to the 8080's A11 and so on, except for A4 which is further decoded.   This allows U18 to address in blocks of 0x7FF.   

Looking at the data from the U18, we can see  the address range for each memory devices is:

U24 0x0000-0x1FFF    PROM, 2764, 8K 1FFF
U23 0x2000-0x3FFF    PROM, 2764, 8K 1FFF
U22 0x4000-0x47FF    RAM,  D4016C-2,  2K, 7FF
U24 0x4800-0x4FFF    E^2, X2804AP,  2K, 7FF

We can see that U18 is programmed to allow remapping of these ranges.  Maybe some future expansion. 

At least it makes sense now but you should double check my work.   

****
Also, I was too lazy to decode it manually and instead just wrote a quick app to map it out.   

dietert1:
In the 8502A the memory map is the same, except is has only 768 Bytes of RAM and no EEPROM. EPROM consists of 4x i2732 in one instrument, the other one has a mezzanine with lots of mask ROMs AM9218.

Meanwhile i spent some hours looking into the firmware 3.0.0 and found it perfectly obfuscated. They went to great detail trying to hide essential pieces of the workings. For example in several places they replaced the jump instruction by an indirect jump through a ROM constant function pointer. System vectors RSTn are routed through RAM function pointers with variable destinations. Also they use a reverse memcpy() to hide the base addresses of data and code structures. I guess it was all written in assembly language. There is no interpreter and i didn't see a full floating point library. I doubt it can be reverse engineered using a general tool. I used a simulator and a disassembler, both with mods to log backplane access, RAM function calls and the like. Meanwhile the disassembler knows 19 obfuscated entry points in addition to the eight system vectors.

Regards, Dieter

SilverSolder:

--- Quote from: joeqsmith on February 24, 2021, 08:44:15 pm ---
Looking at the data from the U18, we can see  the address range for each memory devices is:

U24 0x0000-0x1FFF    PROM, 2764, 8K 1FFF
U23 0x2000-0x3FFF    PROM, 2764, 8K 1FFF
U22 0x4000-0x47FF    RAM,  D4016C-2,  2K, 7FF
U24 0x4800-0x4FFF    E^2, X2804AP,  2K, 7FF


--- End quote ---

Color me impressed, that is some fancy footwork. 


An idea, coupled with @Dietert1's observation about intentional obfuscation:  could U18 be part of the obfuscation -  so the code inside the two EPROMs look like a total mess, unless the addresses are "decoded" by U18 first in order be put in the right order?

If so, perhaps by somehow applying the U18 logic to the code in the EPROMs, we can get a "clean" listing out of it?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod