Re: Tape images for the Apple II anyone?

["Michael J. Mahon" <mjmahon@aol.com>]

Linards Ticmanis wrote:
> Michael J. Mahon wrote:
>
> > If you want the tape images, then .wav files or (apparently) *good* .mp3
> > files are the way to go.  CiderPress can extract the programs and data
> > from cassette audio files to disk images.
>
>
> There's really nothing that would stop .TAP images, common in the 
> Commodore emulation world, to be usable for Apple II as well. You need 
> to preserve half-waves on the Apple I think, like for the Commodore 
> C16/Plus4 systems.

The critical thing to preserve on Apple tapes are the zero-crossing
times, since that is what the Apple cassette input detects.

As Andy has pointed out, however, older tapes which are not readable
from their zero crossings can still be decoded by using a variety of
peak-to-peak (in time, not amplitude) frequency detection.

If one were preserving real tapes, you would want to use algorithms like
CiderPress uses to decode the recorded data, then re-generate a file
with the correct zero-crossing times (presumeably since that is what
an emulator that read tape images would be looking for).

> The file format could easily be extended to handle 
> Apple tapes, and it should be a pretty quick fix for most emulators to 
> support them. Plus, they're much shorter than WAVs and can be "cleaned 
> up" so they compress well. The file format has a simple header followed 
> by single bytes, each giving the length of one individual wave (or 
> half-wave), in units of 8 CPU cycles IIRC. That proved to be exact 
> enough for all known fast-loaders and copy protection schemes. Longer 
> pauses are indicated by a zero byte, followed by an 48 bit number (three 
> bytes) giving the length of the pause in CPU cycles.

Such a representation would be primarily useful if emulators began to
support it.  In the absence of that support, then I suppose this is just
a proposal for data compression.

> The clean-up process consists of adjusting all lenghts, which tend to 
> vary a bit through tape speed variations and such, to the theoretically 
> exact values. The program "FinalTAP" can do this automatically for many 
> common Commodore fast-loaders and copy protection schemes.

Another even more compact format would be to simply represent the stream
of data records as decoded bytes separated by "silence" and "prefix"
durations.  To my knowledge, all Apple tapes were written by the Apple
Monitor's cassette write routine.

Put another way, if you assume that the amplitude variations and wow on
the cassette are meaningless, then you may as well simply save the data
and use it to regenerate the "tape" when it is needed.  (If, on the
other hand, the vagaries of the tape medium are considered worth
preserving, then only a reasonable quality audio recording will
accomplish that.)

Most emulators take this approach with disk images.  They run the RWTS
code on a synthetic stream of nibbles created from the actual decoded
data bytes in a .dsk image.

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."