On Wed, 6 Feb 2002, peter karlsson wrote:
> These dumps are broken, there are several bytes missing from them. The
> question is: did they get lost when I dumped them to tape on the PET or
> when I read them back on the VIC? Does anyone know if the clock speed
> differences can cause problems here?
If you do standard OPEN/PRINT#/CLOSE I/O, then the computer will split the
data to 192-byte blocks (or was it 187 bytes of payload; anyway, that's
what the cassette buffer is for) and record each block twice, separated
with sync pulse streams. It'd be more efficient to use the S command in
the machine language monitor, as suggested by someone. But in that case
you should definitely skip the I/O area, or the transfer might hang (it
did when I used cbmlink's memory dump command over the C2N232 device).
I see nothing wrong with your programs, but I haven't used tape I/O very
much; only enough to reverse engineer the format. Tape data files are
always rounded up to full blocks, but that shouldn't be the problem.
Each byte is followed by a parity bit, and there are block checksums, and
each block is recorded twice. You should have received a LOAD ERROR or
something. I'd say that the error is in the BASIC code, but I don't
understand how. Are there any NUL bytes in the dumped stream?
> Should I try reading the tape on my C64 or my C128, perhaps?
See the documentation files of C2N232. The C128 mode is furthest away
from the PET frequencies, if I remember correctly. The VIC-20 is already
a good choice.
If you have enough memory on your VIC-20, you could try relocating the
BASIC and reading the data in 8-kilobyte blocks and saving them to disk.
The PET doesn't know anything about tape header type 3 (absolute loading
address); you can simply relocate the data, just as with disk files.
Marko
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.1.