QIC Tape help with CRC - Dwight?

Thu Dec 10 09:38:54 CST 2015

I'm not familiar with a XorOut? I suspect it is to correct for
a different seed values at the tail end.
Does the program let you run it backwards?
As a 16 bit polynomial, it is practical to run it forward 2^16 bit times
to get it back to the seed value.
Dwight

________________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Microtech Dart <microtechdart at gmail.com>
Sent: Wednesday, December 9, 2015 11:38 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: QIC Tape help with CRC - Dwight?

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.

Please see

http://microtechm1.blogspot.com/2015/09/kennedy-6450-tape-drive-data-format.html#CRC

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
check=0x2119 name=(none)

reveng -w 16 -p 8005 -i 0002 -x fffd -c -f Block.bin

--OR--

width=16 poly=0x8005 init=0x8001 refin=false refout=false xorout=0x7ffe
check=0x2119 name=(none)

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
check=0x26e7 name=(none)

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
check=0x62e7 name=(none)

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
hard drives?

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
before output."

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.

-AJ
http://MightyFrame.com
http://MicrotechM1.blogspot.com

On Mon, Nov 16, 2015 at 12:24 AM, Lawrence Wilkinson <ljw-cctech at ljw.me.uk>
wrote:

> 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
>> confusing
>> 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
>> knowledge:
>>
>>
>> http://mightyframe.blogspot.com/2015/08/qic-24-tape-data-block-format-decoding.html#CRC
>>
> 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!
>>
>> -AJ
>>
>> --
> Lawrence Wilkinson                          lawrence at ljw.me.uk
> The IBM 360/30 page                   http://www.ljw.me.uk/ibm360
>
>

--

Thanks,
-AJ
http://MicrotechM1.blogspot.com