QIC Tape help with CRC - Dwight?
microtechdart at gmail.com
Thu Dec 10 01:38:17 CST 2015
Just a quick update here, I believe that I have finally cracked the code on
the CRC polynomial/model for this enigmatic Kennedy 64XX QIC tape format.
Here are the core findings:
For both 4096 and 8192-byte data blocks:
width=16 poly=0x8005 init=0x0002 refin=false refout=false xorout=0xfffd
reveng -w 16 -p 8005 -i 0002 -x fffd -c -f Block.bin
width=16 poly=0x8005 init=0x8001 refin=false refout=false xorout=0x7ffe
reveng -w 16 -p 8005 -i 8001 -x 7ffe -c -f Block.bin
(For 4096-byte data blocks only?)
width=16 poly=0x8005 init=0xbffe refin=false refout=false xorout=0x0000
reveng -w 16 -p 8005 -i bffe -c -f Block.bin
(For 8192-byte data blocks only?)
width=16 poly=0x8005 init=0x5ffc refin=false refout=false xorout=0x0000
reveng -w 16 -p 8005 -i 5ffc -c -f Block.bin
CRC_RevEng was a BIG help, once I got more comfortable using it.
Has anyone here ever seen models like this for CRCs in any other media
storage tech? Maybe CRCs on open reel tape (if they had any?), or CRCs on
My grasp on CRC math and formulas is still at the novice level, however. I
am thrown by the fact that the derived model requires an XorOUT parameter
value in order to work properly on both the 4096 and the 8192-byte blocks
found on these tapes. My self-written program that decodes these tapes
doesn't have the ability to input an XorOUT value, mostly because I don't
really understand what it means.
I read in the CRC_RevEng Users Guide:
<http://reveng.sourceforge.net/readme.htm> "-x XOROUT: A hexadecimal digit
string specifying the value to be added to the final shift register value
I did find models with no XorOUT value required that work either for the
4096-byte blocks, and a different one for the 8192-byte blocks. I created a
work-around in my program by selecting a different model based on the size
of the block being analyzed.
Does anyone here have any insight as to why these models will consistently
work for one, but not the other, and vice-versa?
Again, thanks everyone for the great knowledgeable input. Your shared
knowledge has goten me to this point on these projects.
On Mon, Nov 16, 2015 at 12:24 AM, Lawrence Wilkinson <ljw-cctech at ljw.me.uk>
> Ah, I thought you were writing a specific program, but if you're
> just documenting things then specifying the CRC polynomial and
> the init value as all-ones should be sufficient.
> The corresponding init parameter of reveng is "-i ffff".
> On 15/11/15 23:52, Microtech Dart wrote:
>> Lawrence, Dwight & Chuck...thank you!
>> The revelation that I can append 84CF to the 512-byte data block and the
>> 4-byte block address, is golden, and this works!
> The other thing to point out is that if you append the CRC to
> your original block, the resulting CRC should be 0000.
> e.g. 84 CF FF FF gives 0000
> This means there's no need to do a specific 'CRC check', but
> after your data block you keep feeding the CRC bytes in and
> then check that the result is 0000.
>> It would have taken a lot longer for me to figure out on my own that this
>> was a work-around, and at least one working interpretation of the
>> text I was quoting from the manuals.
>> I don't grasp all of the rest of what you shared fully, but now I at least
>> have an example of something that works to play with, and from there, I
>> hope to get more comfortable with this procedure, and write some programs
>> that do this checking to validate each block I read with my Universal QIC
>> reader system.
>> I've updated my web page about QIC-24 decoding CRC section to include this
> When specifying a CRC it's always good to provide a short
> example that can be used to validate an implementation - it
> doesn't need to be a whole block, but just 10 or so bytes
> together with the resulting CRC.
>> Thank you again!
> Lawrence Wilkinson lawrence at ljw.me.uk
> The IBM 360/30 page http://www.ljw.me.uk/ibm360
More information about the cctalk