[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple II tapes backed up to wav...now what?
Nama wrote:
Living in Japan I've been searching for some time for Japanese
specific programs that were written to work on an Apple IIj plus
(which I own), and recently I found a small pile of Apple II
cassettes, and I believe some are Japanese specific. Some cassettes
are original, but most are copies. I have made digital wav files of
everything, and have used Ciderpress to convert the wav files and put
the contents on a virtual DOS3.3 floppy (.po file). Most wav files
converted ok, but a couple of the wav files were unreadable (BAD) by
Ciderpress at all settings and re-recording the wav files at different
levels did not fix the issue, so maybe they are gone forever.
All the programs are machine code except one (Planets by Programma). I
was able to load the .po file for Planets and run this in an emulator
in Applesoft basic, but how do I load and run the machine code
programs, many of which have converted as 2 or 3 separate files using
Ciderpress? I'm a little confused.
Is there any other programs that can convert wav files into something
usable for an emulator. I have tried converting the wav to aiff (or
cass file - same thing) and loading them in Virtual ]['s virtual
cassette, but nothing works and I get ERR every time.
Any advice would be greatly appreciated.
A cassette "ERR" just means that the checksum failed.
In most cases, almost all of the data is recoverable.
Start by doing a Monitor "R"ead command with a very long address range:
800.8fffR
This will read data from the tape starting at $800 and going as far
as the recording on the tape is long. If you can hear the recording,
you can Reset the machine as soon as the recorded data ends.
Then examine the data stored in memory. Since it is mostly code,
it should disassemble into "reasonable" code up until the point
of the first error.
Tape errors are usually "bit slips", in which one or more bits is
deleted or inserted into the stream. "Bit flips" are also possible,
depending on the length of a tape dropout.
Since the most probable changes are 1) the insertion of a 1, 2) the
insertion of a 0, 3) the deletion of a 1 or 0, or 4) the inversion
of a bit, it is possible to proceed by informed guessing. ;-)
Often a single bit flip will not even look strange, since it may
simply change a reasonable opcode to another (superficially) reasonaqble
opcode, or change the value of an address or constant. These errors
will be the hardest to find and fix, since they manifest simply as
bugs in the code.
Bit insertions and deletions usually result in the following code
becoming "unreasonable" gibberish, so that identifies the point where
you should try inserting a bit or deleting a bit, to see which of
those options restores order to the following code.
This involves shifting all the rest of the data in memory 1 bit left
(for a deletion) or right (for an insertion).
After you have a "reasonable" result, log your change and proceed
to the next presumed error, if any.
By working in this manner, you can recover the vast majority of
the code (or ASCII data, since it, too, has obvous "reasonableness").
The recovered data can be saved to disk and then debugged, focusing
on the logged areas where you had to make changes.
Of course, this method is a last resort. You should do everything
possible to ensure that the tape is read correctly in the first place,
as Antoine points out. Since the same data was written to both the
left and right channel tracks, but those tracks may be affected
differently by dropouts or damage, trying each track separately can
sometimes result in a good read.
Alignment (head azimuth) is also a common problem--usually on the
reading tape deck, but occasionally on the recording deck. In this
case, it is necessary to adjust the reading deck azimuth to match
each tape. This is done by locating the head alignment screw (near
one side of the head mount) and slowly adjusting it while listening
to the tape. Adjust for the most high frequencies. This will often
render an unreadable tape readable.
-michael
NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."