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.