Further digging, and watching the Fluke 9010 Training video (Fluke 9010Training1.RM minutes 40 - 46) leads me to believe that this is a mathematical function called a Pseudorandom Binary Sequence. It looks to me as if Fluke adopted HP's Signature standard of a sixteen-bit register with the feedback form of X(16) + X(12) + X(7) + 1. (One of 2048 possible feedback taps, the computer industry uses CRC-16 X(16) + X(15) + X(2) + 16 or CCITT-16 X(16) + X(12) + X(5) + 1 commonly... ) A bit hairy to dig out of the code I am sure! I think this work is done in the base unit, the pod just streams the data into it. I believe that they use a software PBSC generator that takes each BIT and pushes it through the sixteen-bit register (above)... I wonder if this is similar to how ROMIDENT works? So now I am looking at making a simple Fluke Checksum program to run like this: ---------------------------------------------------------------------- Display - Checksum Test - Select Range Display - Beginning of ROM Dis... - End of ROM Begin (Label 1) Go to 1st ROM location Add ROM byte to data memory location Increment ROM address by 1 Is this > End of ROM? If not then goto Begin Display Checksum (read Data memory location) END ----------------------------------------------------------------- At the moment I don't know how to take a Byte of data and add it to the previous one (Within the Fluke script). Have a simple script that asks for the beginning and ending address, then chugs through the ROM...just haven't figured out the additive (in the Checksum meaning) process with Fluke Script. Any suggestions? John :-#)# At 05:50 PM 11/08/01, you wrote:
The signature (I can't call it a checksum..;-) is the same no matter where the memory location is (tried 0000 & 0001, then 0154 & 0155 for example-same results) with a 6800 pod on a different test bed (Heathkit 6800 trainer) and 9010A (shop) base unit.
The first results were with a 6802 pod on an old Heathkit 6802 trainer and my 9010A that is at home.
Looks to me like the process is something like this, take the 8 bit byte, reverse the last four bits order and exchange it with the first four bits. Add a 1 to the least significant bit if odd... Shall dig around some more and try other combinations.
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 02:55 PM 11/08/01, you wrote:
I've done some dissassembly on the code for both the pod and the base, and have to agree with David, whatever it was written in had an awful compiler! - It's not easy tracking down anything, since the code is so illogical!
the code in the pod is a little more understandable, but only just, and not understanding (yet) how the pod communicates to the UUT makes ot difficult to follow as well.
My next step in the attack on understanding the code is to try and create an emulator for the pod software, at least then I may be able to trap all of the reads/writes that communicate with the pod (I need to know this for a later project anyway!) - hopefully, seeing the data transfers may help gain understanding in how the entire thing works
from your examples, it certainly follows no checksum algorithm I know of, reversing the bit pattern either needs a lookup table (which I will check for in a minute) or some nasty calculations (which again, should be obvious!). I'm going to have another troll though the 48k of code looking for anything that may implement such things.
just out of interest, does the 6502 pod (or another 8 bit pod) generate the same checksum, and secondly, does it generate the same checksum for the same data at a different address ?
To UNSUBSCRIBE from techtoolslist, send a message with "UNSUBSCRIBE" in the message body to: techtoolslist-request@flippers.com. Please direct other questions, comments, or problems to jrr@flippers.com.