• Please review our updated Terms and Rules here

Kennedy 6450 Tape Drive - Data Format Analysis from Microtech / Point 4 machine

firebirdta84

firebirdta84

Experienced Member
Joined
Jun 26, 2013
Messages
244
Location
Central Iowa
I've mentioned in several previous threads about trying to read data written circa 1983 in 4-track format on DC300 & DC600 cartridges. I think I may have had a breakthrough here.

Piggybacking onto my QIC-24 analysis a few months back, I believe I've found a match between the Kennedy 6450 Tape Drive and the data format on these tapes, which I believe are for a Microtech Dart / M1, which I'm told is a re-branded version of a Point 4 Mark series machine of that era.

I've created a detailed page on my site for this project: http://bit.ly/1RhcdK2

I won't re-hash everything from my page here on this post, but I'll just bring over some of the key images to see if it piques anyone's interest.

Data Block.jpg SuperimposedTracksv2.jpg MicrotechEndOfBlock.jpg

I would LOVE to know if anyone here recognizes this tape format, and mostly, is it proprietary and unique to Kennedy cartridge tape drives of this era, or was it ever used elsewhere?

Does anyone have any comment on the Filemark? It's very different from the QIC-24 standard, and my examples show a minor variation from the Kennedy documentation. And my Microtech tapes have those extra "11111"s inserted between the Sync and the Reverse Sync.

Filemarks.jpg MicrotechFilemark.jpg

Does anyone think that this is really just a documentation omission, or is this difference more significant, and maybe this is something other than a filemark?

As always, I appreciate everyone's feedback here.

-AJ
http://MicrotechM1.blogspot.com
http://MightyFrame.com
 
Last edited:
That "filemark" looks like nothing so much as a zero-length record, as reading it in either direction would look the same. So, it makes sense to me as a reasonable representation of a file mark. It wouldn't be the first time that some device used a zero-length record to denote a filemark. Isn't this very much the way 6250 GCR 9-track mag tape represents it?

Edit

Nah, not quite. The 6250 GCR format consists of a given burst (usually about 256 frames) of a certain pattern. So that's not it. It just seems to me that something somewhere uses a zero-length record for a filemark.
 
Last edited:
Chuck(G) said:
It wouldn't be the first time that some device used a zero-length record to denote a filemark. Isn't this very much the way 6250 GCR 9-track mag tape represents it?
Click to expand...

Chuck(G), thanks for this comment. This very conversation is exactly what I was hoping for here.

At first, by 6250, I wrongly assuming that you were talking about the 250Mb DC-6250 QIC cartridges, but looking deeper, that's probably not what you meant.

Referencing this wiki article on 9-track tapes https://en.wikipedia.org/wiki/9_track_tape

I see you are probably talking about talking about the reel-to-reel data tape here from the 1970s, which makes perfect sense, that an early QIC adaptation would use the same format as reel to reel.

It may very well be the same data format with the same filemark.

Do you know of any books or manuals that I can reference to confirm this similarity? I'm quite curious about this.

Is the official name (or most common name) of this format "6250 GCR"? My google searches do not reveal sources with nearly as granular information as I have dug up and referenced in my posts on my sites, so that makes a true comparison challenging.

Thanks!

-AJ
 
Just a quick update here, I believe that I have finally cracked the code on the CRC polynomial/model for this enigmatic 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
Click to expand...

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: "-x XOROUT: A hexadecimal digit string specifying the value to be added to the final shift register value before output.", but I haven't yet figured out how to integrate that value into the program I wrote to verify the CRCs on these blocks, which very closely resembles the program example shown about 1/2-way down the page for this Online CRC Calculator.

With CRC_RevEng, I did find models with no (zero, or null) 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 gotten me to this point on these projects.

-AJ
http://MightyFrame.com
http://MicrotechM1.blogspot.com
 
Last edited:
You must log in or register to reply here.
Back
Top