[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tape images for the Apple II anyone?



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

That's basically what I meant. The Commodore 64 hardware can detect only the low-to-high crossing, so you preserve only the times between those. For the Apple one would time the crossings in both directions, as for the Commodore 16.

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).

Sure.

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.

Of course. It's the usual Catch-22: it's worthless to create the stuff unless emulators support it, and emulators won't support it until it exists. Have to start somewhere.

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.

OK, if this is the case on the Apple then fine. On the Commodore it is most definitely not the case, most tapes had a short standard format booter, which then used its own routines for loading the rest of the tape, talking directly to the hardware. Are you sure this was not done on any Apple tapes?

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.)

Well the point of the format is to preserve everything that would be "visible" to the original Computer's hardware, but not more. Just like the idea behind nibble formats for disks (in their intention, I know most do less than that in practice).

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.

Sure. Think .nib as a model for what I wrote. The Commodore world has one tape format for "standard" tapes, .T64, which works as you describe, and one usable for all tapes, .TAP, which works as I said.

--
Linards Ticmanis