The last time I worked on this I printed the description that Fluke gave
for generating their signature (from one of the 9010A manuals), here it
is again...
----------------------------------------------------------this..-----------------------
More on this - reading the 9010A Troubleshooting Seminar - Student
Workbook # 805663 (1985), I find a reference to Rom Signatures. "To
develop a ROM signature, the data is 'compressed' into a 4 digit
hexadecimal number by passing all the ROM data through a two-stage CRC
type of signature algorithm"
----------------------------------------------------------and
this...
I belive the Fluke version is possibly based on some of the
original
articles that were in BYTE circa 1983. I'll need to research that a
bit
more.
Kev
----------------------------------------------------------and
this...
The Operators Manual states:
"Rom Signature is a four-digit HEXADECIMAL number that is a
shorthand representation of the data obtained in an area of ROM memory.
The ROM signature is obtained by successively dividing the data in ROM by
a binary number (they DON't say what the @!$%#$@% number is! - JR). The
resulting signature identifies the data from which it is obtained, and
provides a convenient way of" (....blah blah, no other description
of the process)."
-------------------------------------
John :-#)#
At 09:29 AM 20/06/2003 -0400, James S. Bright wrote:
Yes, my current working theory is that it
starts with the seed and then runs through a loop and performs various
algebraic expressions on the data as it reads it. It may be similar to a
CRC calculation, but not exactly like it.
The seed that we have was derived from
empirical tests (somewhat a long process, but we've been able to decode
signatures up to 17 bytes... almost 18 bytes). A good friend of mine who
is an experienced software archiecture is helping me--when we were
initialize analyzing the initial data he was decoding it quick that I
could capture test cases. At any rate, since the seed that we're using
were calculated from the raw empirical data, it might not be the actual
number in the code. There are likely other initializations that occur.
It doesn't suprise me that 01 00 00 00 ... 08
doesn't have the same signature as 08 00 00 .. 01.... depends on exactly
how the calculations are done.
JB
--James Bright
www.QuarterArcade.com
Restored Arcade Games for your Home