<x-flowed>
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.
</x-flowed>
Received on Sun Nov 18 22:33:42 2001
This archive was generated by hypermail 2.1.8 : Tue Dec 02 2003 - 18:40:38 EST