Re: ROM dumping woes (was: Re: Swedish CBM 3032)

From: Marko Mäkelä (Marko.Makela_at_HUT.FI)
Date: 2002-02-06 18:24:56

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.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail 2.1.1.