Summary: the apple1's basic.zip cassette image, while tricky to load, can
be loaded. Just wait until somewhere around 5 seconds into the tape before entering the read command E000.EFFFR, and it should load properly; the Monitor prompt "/" should reappear around 36 seconds into the tape.
Now that the apple1 cassette interface is working again in MAME 0.185, there's another apple1 cassette issue to deal with: its BASIC cassette images. The apple1 software list has two of these catalogued: basic.zip, which was the first one catalogued in MESS, and basica.zip, a newer image catalogued on February 4, 2012 (by this change
basic.zip is supposedly verified to be an image of one of Apple's original BASIC tapes. However, people have lots of trouble loading it; within the past week or so someone in the Shout Box reported having difficulty. More such reports can be seen in this 2012 thread
. Quoting a comment from that thread:
The results are the same as the rest. I used the debugger to see what went into memory. There was a large number of FF followed by random data.
This sort of failure turns out to have a specific cause. It's not a bug in the driver as such, since the driver is functioning as designed, but rather an issue with the signal quality in the cassette image. (However, it is a weakness of the driver that it is more sensitive to such signal quality issues than the original interface was.)
Anyway, it turns out that you can
get the basic.zip image to load correctly. You just have to avoid following a certain normal habit. It's typical to be cautious, to type out the read command (E000.EFFFR) in advance, start the tape playing, and then immediately hit Return on the read command. This will guarantee
that you get the bad load described above!
What you need to do is to wait
after starting the tape playing before hitting Return on the read command. If you watch the tape counter and wait until anywhere from 2 seconds to 8 seconds into the tape before hitting Return, the image will load properly. Too soon, and you will get the bad load mentioned above; too late, and you will get a different sort of bad load, since the tape will reach the data section before the interface is ready to read it. You will know the image has loaded properly if the Monitor prompt "\" returns about 36 seconds into the tape, just before the end. Of course you can also verify the read afterward by examining the E000.EFFF memory block in the Monitor; just checking the start and end of the block should be sufficient.
(By the way, I wouldn't recommend following this procedure for all tape images, just this particular problematic one.)
The source of this problem is that the tape image in basic.zip comes from an actual recording of less than ideal quality.
The standard Apple I tape image format, as created by the interface's write routine, has a 10-second square-wave header, which the read routine uses to synchronize with the tape signal, followed by a single short "sync-bit" cycle that marks the start of data, followed by the data itself. The interface's read routine first detects a signal transition, waits for about 3.5 seconds, and then synchronizes with the header square wave signal and monitors it, timing each half-cycle. It's looking for a short half-cycle, which it will interpret as the first half of the sync-bit cycle. It then waits one more half cycle, without timing it, before starting to read the cycles which represent data bits.
Because the routine only checks for a short half-cycle and doesn't confirm that the entire cycle is short, this means that if the input header waveform is asymmetric enough, the routine will mistake a short half-cycle in that header for the start of the sync bit. If it does this, it will wait for the next half-cycle, even though that half-cycle is long, and will then begin reading what it thinks is "data". Since this is still within the header, whose cycles are long like the cycles for data "1" bits, the read routine interprets the remaining header as a long series of 1s, and it starts filling the memory block with FF bytes. Once the actual recorded data is reached, the read routine is already thoroughly confused about its position in the image. The result is garbage.
The recording in basic.zip is susceptible to just this condition. During the first several seconds of the recording, while still inside the header, there are several drops in sound level as well as DC wobbles of the mean away from zero. These produce some asymmetric cycles which, while still of normal length, have short half-cycles. If the read routine is started as soon as the tape begins, it will manage to skip several of the worst of these during its initial 3.5 second wait, but eventually it hits one 5 seconds in, triggering the faulty read. This read stops 32 seconds in, well before the data has ended.
Here is a closeup in Audacity of the offending part of the waveform, and a simulation of the square wave generated from it by the driver. (The top waveform is the left channel, since the driver expects a mono input and thus only uses the left channel. The bottom waveform was produced by repeatedly overamplifying (with clipping) the top one by a huge factor and finally applying a hard limit to the overamplified signal. That's not what the driver does, but the result is close enough.) The portion misinterpreted as the sync bit is selected (highlighted in dark gray). It is just short enough to fall within the read routine's upper limit for a sync bit half-wave.
As I said, this problem can be worked around by merely waiting before invoking the read command, but a better solution would be nice.
Simply discarding basic.zip would be a bad idea, at least until we know better whether both catalogued BASIC images are legitimate. The two images, while similar, are not identical. There are a few substantial differences which can be found by doing a byte-for-byte comparison (in fact, I used the Apple I Extended Monitor for the comparison after loading both images in different memory regions). I don't know whether these differences have any real significance, or whether one of the BASIC images may just be a hack of the other, but at present it seems prudent to keep both.
We could edit the header portion of the WAV in basic.zip to remove the early glitchy part and replace it with a copy of the later part. That would certainly produce a cleaner, more reliable image, though it would obviously alter a possibly historical image. More aggressively, we could just use the driver to write a new version of the loaded image and save that instead.
But there's a deeper issue here with how the driver handles the input signal. Right now it simply uses the sign of the input value, so it flips on any zero crossing, no matter how small or short-lived, and it assumes the signal is centered on zero. This isn't how the original hardware worked: the input went to an analog circuit which suppressed any extended DC offset fluctuations and had other filtering and noise-rejection effects. Discussing that, and how MAME might deal with it, is probably better left for a different thread.