It's been a while since I last looked at this, and some others have been attempting it as well. Just curious if anyone got any further and forgot to post results?

I have a nice Arium ML4400 logic analyzer so if anyone has some suggestions I'd be happy to take this up again.

John :-#)#

At 06:31 PM 10/06/2002 -0700, John Robertson wrote:

It is on Spies:

http://www.spies.com/arcade/.TE/9010CourseNotes.pdf

Note that AL does NOT want anyone posting links to his site on any newsgroup....

John :-#)#

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 (this is new info for us!) of signature algorithm"

I recommend that any student of the 9010A print this booklet out and read it thoroughly. I am constantly finding neat tid-bits that are not nearly as well covered in the Operators Manual. For example - how the probe interfaces with the UUT. If you use the synchronize function then the probe ONLY shows activity during valid Read/Write periods. Also the Probe pulse can be synchronized with the R/W.

A lot of other useful training is there.

ftp://www.flippers.com/Fluke

I can send copies of the Workbook to anyone that needs one. I believe it is about 12 megs....My space is limited on my server

John :-#)#

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.

-- 
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9 
Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
                 www.flippers.com 
"Old pinballers never die, they just flip out"