2 Jan
2007
2 Jan
'07
1:02 a.m.
I'm pretty confused right now. I wrote a small basic program to dump my
cassettes into the computer.
1 IF (1 AND PEEK(61456)) = 0 THEN POKE 61441, PEEK(61457)
2 GOTO 1
61441 - ACIA DATA PORT
61456 - KCACR STATUS PORT
61457 - KCACR DATA PORT
I'm not checking if the ACIA is ready for data, because when reading at
300bps and transmitting at 9600 we should never have to.
Why am I getting strange results below? The only thing I can think of is
that it is somehow missing every other byte from the KCACR. Does anyone
see anything wrong with the basic program? All 500 lines returned are the
exact same length and they all start with 13.
1300D603EAFE3A00880C8
13000000000000000000C
...
1310452E25D34F0FEE5CC
1310C71943CF143316541
Missing every other byte? Maybe the 680 and it's basic isn't fast enough
for my program? I'm just guessing that S1 and 13 are supposed to be there...
S113_0_0_D_6_0_3_E_A_F_E_3_A_0_0_8_8_0_C_8
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.
FF-(13+0D+76+F3+7E+18+F9+7E+03+3C+48+38+2C)=7E
So 7E is the checksum. I want to know where all those bytes go! :(
Grant
2 Jan
2 Jan
3:10 a.m.
Grant Stockly wrote:
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.
FF-(13+0D+76+F3+7E+18+F9+7E+03+3C+48+38+2C)=7E
So 7E is the checksum. I want to know where all those bytes go! :(
Can't help you with the tape read problem although the speed issue as you
suggest sounds like a good guess, but as for the
byte count issue: it's 13 hex = 19 dec, which works out exactly for the line
you show when you include the address bytes (everything after the 13).
Lesson: you're up too late at night :) ...but then so am I (!) :/
1:27 p.m.
Can't help you with the tape read problem although
the speed issue as you
suggest sounds like a good guess, but as for the
byte count issue: it's 13 hex = 19 dec, which works out exactly for the line
you show when you include the address bytes (everything after the 13).
Lesson: you're up too late at night :) ...but then so am I (!) :/
Thats a big relief... With these hex characters encoded onto tape as two 7
bit ASCII chracters its easy to loose track.
Not once did I think of converting 13 to hex...
Grant
6:16 a.m.
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.
Regards,
Dave
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:
http://www.classiccmp.org/dunfield/index.html
2:26 p.m.
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.
That would be great! Just send it to my list address. I have no size limit.
PS: I'd like to get a copy of the data once you get
it extracted.
I have a memory dump of basic loaded and unitialized from 0000-1FFF, but I
want the original data extracted off the tape.
I hooked a 232 transciever and inverter up to the demodulated output from
the KCACR (right at the 1013 ACIA IC) and it wasn't 300bps. I had a 2.5ms
bit clock and it should have been around 3.3ms.
I am going crazy to the point of completely ignoring the following fact. I
have 7-8 WAV files on my computer. I started recording the second I pushed
play, which was right at the beginning of the tape. I stopped recording
when it lost the carrier.
I have 3 recordings that are 13:30 minutes long and 3-4 that are 10:17
long. The KCACR will load basic with either length, although at 13:30
minutes it is very sensitive to tape quality it seems.
I have a very nice tape deck with dc servo controlled motors. This is very
disapointing to me. It makes me cry to think about it... : ( I want a
perfect quality recording of the tape and it kills me to think I have to
hook one of my "junk" players up to the computer to get it...
I think the reason that the demodulated output is not 300bps is the KCACR
is locking onto the tape speed? The KCACR is supposed to handle a +-20%
speed variance. The bitclock must be provided to the 1013 ACIA. I don't
have the manual for the KCACR yet, so I have no idea...
My idea to get a PERFECT MITS basic sound file is to recover the S records
and generate a new sound file using the KCS.EXE program found on the web.
Comments?
Grant
6345
days inactive
6345
days old
4 comments
3 participants
participants (3)
-
dave06a＠dunfield.com -
grant＠stockly.com -
hilpert＠cs.ubc.ca