I give up, I am way too frustrated by this stupid signature crap so I am going to dive into my 9010 and see if I can figure out how it is doing it. I first have to figure out if it is in the pod or the base unit, when the signature is being generated I see lots of activity on the pod data buss, so I am assuming the process is handled inside the stupid base. I am going to also see if I can figure out mathematically the difference between the fluke signature and the regular checksum by reading a small bit of data and then doing a checksum on the same bit of data, then extrapolating it from there. I suspect that the unit is taking each data line and adding it up, then the next data line...and summing them all together or in series. Gah. digging into it tonight, perhaps I can report out later this evening what I fine. Any suggestions? I am NOT an assembly language person...I can read it a bit, I understand the process, but I have not programmed with the stuff more than a few lines. If someone wants to disassemble the ROM in the base unit, the images are on ftp://www.flippers.com/public and I found a nice Z80 disassemble called DZ80 http://www.inkland.demon.co.uk/dz80/index.htm heh, heh... John :-#)# 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.
Good luck, you'll need it! The code had to have been written in some crappy compiler like PL/M or something. It's a nightmare to try to unravel. To help you along, here;'s a starting point: The calculated 'checksum' signature is stored in location 0xF345 and 0xF346 once it has been calculated. I got to the point where I had to reverse engineer the command protocol between the mainframe and the pods, that's when I finally had to give up. Dave ----- Original Message ----- From: John Robertson <jrr@flippers.com> To: <techtoolslist@flippers.com> Sent: Wednesday, November 07, 2001 7:21 PM Subject: Cracking the 9010A ROM signature generator
I give up, I am way too frustrated by this stupid signature crap so I am going to dive into my 9010 and see if I can figure out how it is doing it. I first have to figure out if it is in the pod or the base unit, when the signature is being generated I see lots of activity on the pod data buss, so I am assuming the process is handled inside the stupid base. I am going to also see if I can figure out mathematically the difference between the fluke signature and the regular checksum by reading a small bit of data and then doing a checksum on the same bit of data, then extrapolating it from there. I suspect that the unit is taking each data line and adding it up, then the next data line...and summing them all together or in series. Gah. digging into it tonight, perhaps I can report out later this evening what I fine.
Any suggestions? I am NOT an assembly language person...I can read it a bit, I understand the process, but I have not programmed with the stuff more than a few lines.
If someone wants to disassemble the ROM in the base unit, the images are on ftp://www.flippers.com/public and I found a nice Z80 disassemble called DZ80 http://www.inkland.demon.co.uk/dz80/index.htm heh, heh...
John :-#)#
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.
Some early results...my math is just horrible so I'm going to need some help here... I hooked up the Fluke to some RAM and started generating a table, here are the results or a two byte ROM signature with the first byte being fixed at "00" and the second byte cycling from "00" to "1F" 0000 - 00/00 For location 00 & 01 0081 - 00/01 [0000 0000 0000 0001 gives 0000 0000 1000 0001 (note that odd ALWAYS has a 1 on the end) 0040 - 00/02 [0000 0000 0000 0010 gives 0000 0000 0100 0000 (note that mirrored bit) 00C1 - 00/03 [0000 0000 0000 0011 gives 0000 0000 1100 0001 0020 [0000 0000 0000 0100 gives 0000 0000 0010 0000 (and so on....) 00A1 0060 00E1 0010 0091 0050 00D1 0030 00B1 0070 00F1 - 00/0F 0008 - 00/10 0089 - 00/11 0048 - 00/12 00C9 - 00/13 0028 00A9 0068 00E9 0018 0099 0058 00D9 0038 00B9 0078 - 00/1E 00F9 - 00/1F And a few extras 93D0 - FF/00 9351 - FF/01 9390 - FF/02 9311 - FF/03 ..... 93AF - FF/FE 932E - FF/FF Any ideas? Note that the order is reversed for the bytes, so that 00/01 (0000-some unknown math function- 0001) creates 1000 0001, and 00/02 (0000-some unknown math...- 0010) yields 0100 0000. Note that if the numbers are odd then the result is odd. Even gives even. Help!!! John :-#)# At 06:08 PM 11/07/01, you wrote:
Good luck, you'll need it! The code had to have been written in some crappy compiler like PL/M or something. It's a nightmare to try to unravel. To help you along, here;'s a starting point: The calculated 'checksum' signature is stored in location 0xF345 and 0xF346 once it has been calculated. I got to the point where I had to reverse engineer the command protocol between the mainframe and the pods, that's when I finally had to give up.
Dave
----- Original Message ----- From: John Robertson <jrr@flippers.com> To: <techtoolslist@flippers.com> Sent: Wednesday, November 07, 2001 7:21 PM Subject: Cracking the 9010A ROM signature generator
I give up, I am way too frustrated by this stupid signature crap so I am going to dive into my 9010 and see if I can figure out how it is doing it. I first have to figure out if it is in the pod or the base unit, when the signature is being generated I see lots of activity on the pod data buss, so I am assuming the process is handled inside the stupid base. I am going to also see if I can figure out mathematically the difference between the fluke signature and the regular checksum by reading a small bit of data and then doing a checksum on the same bit of data, then extrapolating it from there. I suspect that the unit is taking each data line and adding it up, then the next data line...and summing them all together or in series. Gah. digging into it tonight, perhaps I can report out later this evening what I fine.
Any suggestions? I am NOT an assembly language person...I can read it a bit, I understand the process, but I have not programmed with the stuff more than a few lines.
If someone wants to disassemble the ROM in the base unit, the images are on ftp://www.flippers.com/public and I found a nice Z80 disassemble called DZ80 http://www.inkland.demon.co.uk/dz80/index.htm heh, heh...
John :-#)#
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.
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.
If anyone wants them I have some emulator execution trace capture files of the IO_LEARN sequence. Somewhere within this listing the 'calculation' is performed. The capture, IIRC, is MANY loops within loops but I believe it's all there. The above mentioned capture file is 125Kbytes long, there's ALOT of information in it. There are some other trace capture files I saved too, just say the word and thier yours. Dave ----- Original Message ----- From: Mike Coates <mcoates@mame.net> To: <TechToolsList@flippers.com> Sent: Thursday, November 08, 2001 5:55 PM Subject: Re: Cracking the 9010A ROM signature generator
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.
Sounds useful to me - if you want to send it to me at mike@the-coates.com shouldn't be too big zipped, but what the heck, if it's helpful!
If anyone wants them I have some emulator execution trace capture files of the IO_LEARN sequence. Somewhere within this listing the 'calculation' is performed. The capture, IIRC, is MANY loops within loops but I believe it's all there. The above mentioned capture file is 125Kbytes long, there's ALOT of information in it. There are some other trace capture files I saved too, just say the word and thier yours.
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.
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.
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.
I've got two 9100A units. One with v3.0 OS and programmers option and the other with v4.1 OS. I also have a 9132 unit, a -003 Parallel I/O module and a number of PODs. Thanks, -Chris --- Kev <KKlopp@erols.com> wrote:
Could we get a definitive head count of 9100 equipment owners/users & what they have?
I've got 1 9110FT w/programmers option running V6.0 OS 1 9132 unit (68HC11, 80188, 80186 modules) 1 -003 option with clips
I'm interested in writing test programs & learning the ablilities of this unit.
Looking to swap Parts libraries & any programs that may be stored on your drives/floppies (in an effort to see more programming examples).
Thanks, Kev
__________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
I have: (1) 9100FT (dead, no OS) (1) 9100A (dead, no OS) <sniff> (1) keyboard unit and mono monitor (3) -003 units (and lots of adaptors, calibration units, plus more -003's on the way) (1) 32 bit adaptor setup for 68020 with 2 9132's and a sync (1) 32 bit adaptor setup for 80386 with 2 9132's and a sync Pods: Z80, 6502, 8031, 6802/08 Plus the normal host of 9010A equipment
Could we get a definitive head count of 9100 equipment owners/users & what they have?
I've got three 9100s (I believe one of them is a 9100FT), a clock module, pods, probe and one extra module that I'm not sure about. Sorry I don't have more detail - they are in storage since I primarily use 9010s instead. I have the same concerns as John: I don't want to become dependant on it since we haven't figured out the hard disks yet (or has someone?). I know one of mine has a bad power supply that I haven't been able to find parts for (and there aren't any schematics in the manuals that cover it) and I believe another one has a bad hard disk. One of them is known good, but since I don't have a programmers keyboard I don't seem to be able to do much with it above and beyond what the 9010 can do (it does have the programming software option and video card, just no keyboard). I'd love to participate in these discussions more than I have been. Hopefully I'll be able to contribute something useful here in the next few months. Alex ---- http://www.elektronforge.com ayeckley@elektronforge.com
participants (7)
-
Alex Yeckley -
Chris Loggans -
Corey Stup -
David Fish -
John Robertson -
Kev -
Mike Coates