Recovering Cassette Tape Records
dave06a at dunfield.com
Tue Jan 2 08:16:53 CST 2007
> On top of all this, I'm having a hard time understanding the format.
> This is a good line:
> 1 2 3 4 5 6 7 8 9 10 11 12 13
> S1 13 0000 0D 76 00 F3 7E 18 F9 7E 03 3C 00 00 48 38 00 2C 7E
> S1 means its a data record,
> 13 is the byte count,
> 0000 is the address,
> and 7E is the checksum.
> So what are the mystery bytes? How do you get 13 data bytes and still have
> a place for all of the rest? 13 is supposed to include the checksum! The
> checksum is the one's compliment of the sum of the all bytes except S1 and
> the checksum itself.
This is standard Motorola HEX format:
(From my XASM manual):
4.1.1 Motorola hex format
Data Record: 'Stnnaaaadddddddddddddddddddddddddddddddd...cc'
Where: S = 'S', indicates start of data record
t = Record type, '1'=data, '9'=end of file.
n = Count of number of bytes in record. (in ASCII/HEX)
a = Load address of data record. (in ASCII/HEX)
d = Actual data bytes in record. (in ASCII/HEX)
c = Checksum of count, address, and data. (in ASCII/HEX)
Note1: Checksum is computed as one's complement of eight
bit sum of all values from 'nn' to end of data.
Note2: Count 'nn' is three greater then the number of data
bytes in the record.
Note that the count value includes not only the checksum, but the
address bytes as well. Your record contains 10h (16 decimal) bytes
and does verify.
If it's any use to you, I can send some tools to work with this type of
data (change record size, load address, convert to binary, set fill
values etc.). I can also give you assembler/disassemblers which will
work with MHX directly.
PS: I'd like to get a copy of the data once you get it extracted.
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
More information about the cctalk