Hello, all. Apologies if the info I'm seeking is in an FAQ somewhere: so far, I've found little that helps. I want to know about the data format used in the Apple cassette interface (][+, specifically). All I "know" so far is that L is one cycle of 2kHz, H is one cycle of 1kHz. But actual output from the Apple seems to be fairly far off from that; and there seems to be some amount of framing (start/stop bits? parity? CRC?), which I have not figured out yet. I'd appreciate any more complete info. BTW, the reason is so that I can build a data loader based on a PIC processor (for operating the Apple without disk drives). --Benjamin Benjamin Ketcham wrote: >Hello, all. Apologies if the info I'm seeking is in an FAQ somewhere: >so far, I've found little that helps. > >I want to know about the data format used in the Apple cassette >interface (][+, specifically). All I "know" so far is that L is >one cycle of 2kHz, H is one cycle of 1kHz. But actual output from >the Apple seems to be fairly far off from that; and there seems to >be some amount of framing (start/stop bits? parity? CRC?), which I >have not figured out yet. I'd appreciate any more complete info. > >BTW, the reason is so that I can build a data loader based on a >PIC processor (for operating the Apple without disk drives). The best "documentation" of cassette format is in the monitor listing for the code that creates and decodes cassettes. The listing is in virtually all early Apple II Reference Manuals. There is a lead-in tone of 3.5 seconds of 770Hz, followed by a 1-cycle "start" mark with two 400 microsecond half-periods. Then data follows, most significant bit first, with two 250 microsecond half-periods for a "0" and two 500 microsecond half-periods for a "1". Following the data, there is a single checksum byte, which is the EOR of all data bytes, seeded with $FF. Applesoft BASIC files are preceded by a short record with the length of the program and an "auto run" flag byte. -michael Check out parallel computing for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ Jayson Smith wrote: > >"Benjamin Ketcham" wrote in message >news:1097056634.892700@yasure... >> Michael J. Mahon wrote: >> > >> > The best "documentation" of cassette format is in the monitor >> > listing for the code that creates and decodes cassettes. The >> > listing is in virtually all early Apple II Reference Manuals. >> >> Yes, I'd like to get my hands on a manual (again). I had started >> to trace the monitor code, but the info you gave below sure saves >> me a lot of time and uncertainty. >> >> > There is a lead-in tone of 3.5 seconds of 770Hz, followed by >> > a 1-cycle "start" mark with two 400 microsecond half-periods. >> > Then data follows, most significant bit first, with two 250 >> > microsecond half-periods for a "0" and two 500 microsecond >> > half-periods for a "1". Following the data, there is a single >> > checksum byte, which is the EOR of all data bytes, seeded >> > with $FF. >> > >> > Applesoft BASIC files are preceded by a short record with >> > the length of the program and an "auto run" flag byte. >> >> Thank you very much for this info! If it is available on the >> Web anywhere, I was unable to find it with my search attempts. >> I'd suggest that those who maintain Apple II FAQs (there seem >> to be more than one active FAQ) might want to include this >> info -- though I guess if I'm the only one who asked, it's >> not a very FA Q. > >Hey, with this info, I bet somebody could write a Win/Linux program to take >any standard file and convert it to a .wav of a valid Apple II cassette dump >of that file. That way you could transfer, say, ADT to an Apple via the >tape interface. Or any other binary for that matter. DOS, even? >I couldn't do it, but somebody probably could! What would be the best >sample rate for such a wav? What kind of frequency response does the >cassette hardware require? Such a transfer method could certainly work, and could be a useful addition to the "bootstrapping" repertoire. The cassette interface is not a fast data interface (!), transferring data at an average rate of 1500 bps, or less than 200 bytes per second. At this rate, a full, uncompressed disk image could require about 12 minutes to transfer. Of course, it could not be transferred in a single "record" because of memory limitations, but reliability would probably also dictate several smaller segments. DOS could certainly be transferred, after which a program could combine "segments" of an image to produce a complete disk. The waveform sent by the Apple to a cassette recorder is, of course, a square wave. The "polarity" of the square wave is indeterminate, since the Apple cannot control whether the waveform is high or low, but can only "toggle" it from one to the other. A typical cassette recorder has a record/playback frequency response of 10kHz or so, so the recorded square wave is decidedly less square when it is replayed. To allow for this, the Apple cassette input senses only the zero crossings of the signal, to recover the approximate timings of the original transitions. I haven't timed out the cassette read routines to determine exact margins, but I would expect that timing deviations resulting from discrete sampling would be tolerated up to +/-50 microseconds (since inexpensive cassette recorders can exhibit significant flutter, too). If this is so, it would suggest that 22kHz sampling would be quite sufficient for accurate reproduction, and experiment might verify that even 11kHz would work reasonably reliably. Note that popular lossy compression schemes, such as MP3, may not preserve the critical zero crossing timing, even though the recordings may "sound" to a human like the originals, so .wav files are a good starting point. -michael Check out parallel computing for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ Jayson Smith wrote: > Hey, with this info, I bet somebody could write a Win/Linux program to take > any standard file and convert it to a .wav of a valid Apple II cassette dump > of that file. That way you could transfer, say, ADT to an Apple via the > tape interface. Or any other binary for that matter. DOS, even? > I couldn't do it, but somebody probably could! What would be the best > sample rate for such a wav? What kind of frequency response does the > cassette hardware require? > Jayson. Well, this is basically what I'm trying to do. Except I am using a PIC microprocessor as an intermediary, so that the Linux system sees a plain RS-232 interface (thus other devices such as a Palm Pilot, etc., could also talk to this). However, if you are willing to bang on the parallel port and don't care about portability to non-PC platforms, then as far as I can tell, it would suffice to directly connect one of the port signal lines to the Apple cassette input (and also connect the grounds of the two systems). I have found empirically that no resistor divider or other analogue circuitry is needed, the cassette input can handle raw TTL, as produced by a PIC -- or PC parallel port. I.e., no need to convert to WAV and send with a sound card (although that should work, too). To answer your question, a pretty low sample rate should suffice, the highest *fundamental* frequency in the cassette signal is 2kHz. I have seen someone else's project, sending data from PC parallel port into the Apple via a joystick input. This would potentially give a much higher transfer rate, but the downside is that there is no ROM support so you have to enter machine code to make the Apple receive data this way. With the cassette interface, of course, the advantage is that the Apple already knows how to receive data through that channel. The work that I am doing, as usual, is open-source, so I will make my results available (is it appropriate to post such notices in this group?). What fun, working on the Apple II again after 20 years! --Benjamin ------------- > "Benjamin Ketcham" wrote in message > news:1097056634.892700@yasure... >> Michael J. Mahon wrote: >> > >> > The best "documentation" of cassette format is in the monitor >> > listing for the code that creates and decodes cassettes. The >> > listing is in virtually all early Apple II Reference Manuals. >> >> Yes, I'd like to get my hands on a manual (again). I had started >> to trace the monitor code, but the info you gave below sure saves >> me a lot of time and uncertainty. >> >> > There is a lead-in tone of 3.5 seconds of 770Hz, followed by >> > a 1-cycle "start" mark with two 400 microsecond half-periods. >> > Then data follows, most significant bit first, with two 250 >> > microsecond half-periods for a "0" and two 500 microsecond >> > half-periods for a "1". Following the data, there is a single >> > checksum byte, which is the EOR of all data bytes, seeded >> > with $FF. >> > >> > Applesoft BASIC files are preceded by a short record with >> > the length of the program and an "auto run" flag byte. >> >> Thank you very much for this info! If it is available on the >> Web anywhere, I was unable to find it with my search attempts. >> I'd suggest that those who maintain Apple II FAQs (there seem >> to be more than one active FAQ) might want to include this >> info -- though I guess if I'm the only one who asked, it's >> not a very FA Q. >> >> --Benjamin >> > > Benjamin Ketcham wrote in message news:<1097089622.859420@yasure>... > I have found empirically that no resistor > divider or other analogue circuitry is needed, the cassette input can > handle raw TTL, as produced by a PIC -- or PC parallel port. > I've had the same experience using an LM339 (?) voltage to frequency converter. I wanted to use the regular pushbutton inputs for something else, so wired it to a mini phono plug, and change one byte of code in the reader, and off it went. Works great. I do wonder how the frequency response compares with the max frequency response of a standard pushbutton input though. Mike Benjamin Ketcham wrote: >Jayson Smith >wrote: >> Hey, with this info, I bet somebody could write a Win/Linux program to take >> any standard file and convert it to a .wav of a valid Apple II cassette >dump >> of that file. That way you could transfer, say, ADT to an Apple via the >> tape interface. Or any other binary for that matter. DOS, even? >> I couldn't do it, but somebody probably could! What would be the best >> sample rate for such a wav? What kind of frequency response does the >> cassette hardware require? >> Jayson. > >Well, this is basically what I'm trying to do. Except I am using >a PIC microprocessor as an intermediary, so that the Linux system >sees a plain RS-232 interface (thus other devices such as a Palm >Pilot, etc., could also talk to this). > >However, if you are willing to bang on the parallel port and don't >care about portability to non-PC platforms, then as far >as I can tell, it would suffice to directly connect one of the port >signal lines to the Apple cassette input (and also connect the grounds >of the two systems). I have found empirically that no resistor >divider or other analogue circuitry is needed, the cassette input can >handle raw TTL, as produced by a PIC -- or PC parallel port. There is a problem with bit-banging on Windows machines--multitasking and interrupts. In order to produce precisely timed waveforms, it is necessary to gain complete control of the processor. And, for any "modern" cached processor, it is usually necessary to control a timer, since instruction execution times are not constant (depending on cache misses, etc.). For something slow, like the cassette signal, where 50 microsecond accuracy is sufficient, things are a bit easier, but a task switch would still mess up the timing and cause the "record" to be in error. >I.e., no need to convert to WAV and send with a sound card (although >that should work, too). To answer your question, a pretty >low sample rate should suffice, the highest *fundamental* frequency >in the cassette signal is 2kHz. But the timing accuracy required is still the critical issue. >I have seen someone else's project, sending data from PC parallel port >into the Apple via a joystick input. This would potentially give a much >higher transfer rate, but the downside is that there is no ROM support >so you have to enter machine code to make the Apple receive data this >way. With the cassette interface, of course, the advantage is that >the Apple already knows how to receive data through that channel. Data transfer using a pushbutton input and an annunciator output has the great advantages of 1) being full-duplex, and 2) allowing for handshaking, so that interrupts and task switches need not cause any problem. A consequence of this is that it can use higher signalling speeds reliably. Apple II Oasis is an excellent example of using an Apple connected as described as a "disk server" to a PC. >The work that I am doing, as usual, is open-source, so I will make >my results available (is it appropriate to post such notices in >this group?). > >What fun, working on the Apple II again after 20 years! Hear, hear! -michael Check out parallel computing for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/