1200-Baud Archeology 211
jamie found this singularly geeky article on reconstructing Apple I BASIC from a cassette tape. It claims to offer the first confirmed perfect dump (BIN) of the 4096 bytes of this venerable interpreter. Terrific fun for the whole family. "The Apple I is extremely rare. Only 200 were built, and less than 100 are believed to be in existence. Neither Steve nor Woz own an Apple I any more, and neither does Apple Inc. The cassettes are even rarer, as not every Apple I came with one... So here is how to decode the signal. Let us first open the audio file in Audacity and look at the waveform... It is now time to write a small program to measure and dump the width of the pulses."
Alternative tools (Score:5, Interesting)
Re:Alternative tools (Score:5, Interesting)
Yes - I thought this too - the article's slashdotted at the moment but the summary makes me think he made a mountain from a molehill. In the Sinclair Spectrum world, loading Speccy tapes on to a PC, and encoding them in a useful format (TZX) has been a solved problem for years.
All these tape formats were physically pretty similar when it comes to how they were encoded, and the same techniques could have been used by looking at any home computer emulator that loaded stuff from tape even if the details were different.
Re:Doing it the hard way (Score:5, Interesting)
Yes. But a few people did some very magical things with tapes before the became obsolete. I saw a demo of a turbo tape system on an Atari 800XL which could load games "faster than a disk drive". Actually it about tied, but that was still impressive. The disk drive could probably managed 9600 baud sustained.
The modulator / demodulator was lump of potted electronics I could easily fit in my hand. Potting compound was a blank gunk you applied to electronics you didn't want people to tamper with, in this case to stop people seeing the components used. But whatever they were they could modulate and demodulate data at around 9600 baud. This was in the 80's back before DSPs too, so whatever circuit was used must have been made of Op Amps, transistors and passive components.
I never worked out how it worked. Though I can imagine exploiting the stereo nature of the tapes to send one carrier and phase shifted signal might work. Phase modulation is easy and demodulation is too if you have the carrier. Still phase modulation at 9kbaud+ would be a tight fit on an audio tape. I don't think things like QAM would be possible given the size of the package, the selling price (about twenty English pounds, or $40), and the primitive nature of 80's technology.
Electron ROM Ripping, ol' school (Score:5, Interesting)
Very interesting (Score:3, Interesting)
I have a TI-99/4A that has been dead for nearly two decades, along with several hours worth of data stored on cassettes. I would love to recover the data off of those tapes. Most of it is the type of stuff a 10 year old would write in TI BASIC (and Extended Basic!), and it would really bring back some fond memories and certainly some good laughs.
Are there any generic utilities that can extract binary out of low-baud modem audio files? With the advantage of performing various audio processing and analysis in a non-linear, non-realtime manner, certainly data could be extracted by modern software that not even the actual legacy computer could decode.
Re:Teach it! (Score:5, Interesting)
I think that at least the basic interpreter should be taught to the new generations.
To rain on the parade, I wonder if there is a copyright violation in posting the code online un-edited. How long is copyright nowdays?
It's something we need to address in this age of IP property where the market has expired years ago but the copyright is in force for many more decades.
Re:Doing it the hard way (Score:3, Interesting)
Re:Doing it the hard way (Score:1, Interesting)
The computer I designed and built around 1981 did 9600 bps with some TTL logic i designed myself. The format used was Manchester II, very simple to encode and decode if the clock can be recovered (the difficult part) for the decode phase. I think I used less PCB space than what was needed for the common 300 bps Kansas City format.
Nick Hodge Says (Score:4, Interesting)
Apple Inc does own an Apple I
It is actually owned by Apple Computer Australia, and on loan and display at the Powerhouse Museum in Sydney.
For many years, it was under a glass box in the foyer of the Apple Australia offices.
Re:Alternative tools (Score:3, Interesting)
Actually, If I remember right (digging back oh, nearly 30 years into the recesses of my mind), the C-64 had a fairly unusual tape format, unlike almost everyone else, just like their disk drive was unique (everyone else used a fixed number of sectors/track, where Commodore used a variable number, with more sectors/track as you moved out, to get more data on the disk)
QAM (Score:3, Interesting)
Still phase modulation at 9kbaud+ would be a tight fit on an audio tape. I don't think things like QAM would be possible given the size of the package
Quadrature amplitude modulation was in use in the 1960s: it's just two AM carriers out of phase by 90 degrees. The color encoding in NTSC and PAL used QAM.
Re:Doing it the hard way (Score:5, Interesting)
The computer I designed and built around 1981 did 9600 bps with some TTL logic i designed myself. The format used was Manchester II, very simple to encode and decode if the clock can be recovered (the difficult part) for the decode phase. I think I used less PCB space than what was needed for the common 300 bps Kansas City format.
When the Atari sent data to the tape it had an internal modulator. But IIRC the demodulator was in the tape deck. And in any case you could output data to the disk drive, when it was a selectable baud 0-19200 rate and not modulated. So it seems like the turbo tape interface could use custom software to get 9600 baud TTL data to or from the tape and do its 9600 modem baud magic internally with a handful of components.
Tapes are stereo, so you could send the clock one one channel and the phase shifted clock (the signal) on the other.
You need an oscillator and a phase shifter made out of an XOR gate to modulate. Shifted single goes on one channel say left, unshifted one on the other, say right
To demodulate you use a phase detector made out of an XOR gate to compare the phase of the two channels.
This would be analogous to Manchester BPSK coding, except that you use one of the two audio channels to store the carrier so you don't need to spend expensive electronics regenerating it.
So something like this seems plausible. Unfortunately I didn't know enough about electronics back in the Atari days to try it.
Re:Memories (Score:5, Interesting)
Tape, yes. But do you remember 45rpm floppy 7" "records" that came with magazines? Or programs broadcast over the radio late at night?
I've just written this article, coincidentally:
http://mark.tranchant.co.uk/2008/07/a-unique-generation [tranchant.co.uk]
Re:Alternative tools (Score:5, Interesting)
Didn't the Apple I use PSK instead of FSK encoding for the tape audio?
I though instead of Shifting frequency they shifted phase which is quite a but harder to detect than frequency shift.
BTW: Computer Tapes worked great to load software across Ham radio. 2 meter radio, I would load a game from a friend across the city over 2 meters by simply patching audio from the rig to the computer.
Luckily the C64 had a very slow bitrate (even the floppy drive was slow as hell) for it's storage tapes so it worked great.
Re:Very interesting (Score:4, Interesting)
http://www.cs1er.com/ [cs1er.com]
Amazed it actually works (Score:5, Interesting)
The interesting thing about this article is:
This could have been done so much more easily :)
Re:Alternative tools (Score:5, Interesting)
There used to be a Dutch radio program in the 80s called "NOS Hobbyscoop" that had their own basic interpreter for many computers of the day. (MSX, Acorn, Sharp MZ, etc.)
They actually broadcast computer programs every week on medium wave AM. They'd count down, you start the cassette recorder and you had some new programs.
Fun for the whole family, even if a bit painful on the ears!
Why they didn't use MESS? (Score:3, Interesting)
MESS emulates the Apple I, can read WAVE files, and the entire source code is available. :)
I miss my old CoCo3, but I hated cassette tapes. The saddest thing is that Audio Cassettes were designed to be lousy as a data storage media - they used two sides (interference), and were created to record just human voice. The only other option were floppy drives, and back then they were expensive and/or overpriced ($200 and up) which is equivalent to $400+ now in 2008. Most drives had to include the entire controller I/O inside the unit, and probably also a disk OS.
Re:Alternative tools (Score:5, Interesting)
No. It's FSK, but it used a constant number of zero crossings per bit, rather than a constant bit period. So, to decode it, you count the average time between zero crossings rather than the number of zero crossings in a fixed time window.
On the plus side, it seems like the Woz scheme has some benefits. If you assign the shorter bit period to the more common bit value (likely, '0'), you shorten your average recording length a little. On the minus side, if you get an extra zero crossing in there (say, due to noise that wasn't filtered away by a Schmitt trigger or other hysteresis somewhere), recovery may be awkward.
BTW, the C64 floppy drives were slow as heck, but that had nothing to do with the bitrate for its media. There's some goofy history there, involving bugs in the shift register on the VIC-20's PIA, the decision to use CPU control loops instead to determine the bit period when communicating between the drive and the machine, and then the greater cycle-stealing period of the VIC-II as you get to the C64 throwing a monkey wrench in the works. The fast-load carts worked by restoring the native CIA hardware shift register to get rid of the CPU-controlled bit shifting to read bits from the floppy, restoring its speed to performance levels similar to the old IEEE-488 based bus they used back in the Commodore PET era. But that's a different story for another day.
--Joe
Re:Alternative tools (Score:5, Interesting)
here in brasil, UFRGS (federeal university of rio grande do sul) broadcasted test programs using stereo FM. one chanel would broadcast audio, the other encoded text to be decoded by an MSX computer and displayed on screen. the idea was to make talk radio accessible to def people.
Re:Alternative tools (Score:4, Interesting)
Probably the most elaborate scheme I've seen so far is the Mattel Electronics Keyboard Component [spatula-city.org]. It encodes everything into blocks of 32 10-bit words, each protected by a 5-bit detect-2-correct-1 Hamming code. The 32 words are then re-interleaved as 15 32-bit words. Each 32-bit word gets prefixed with a 5-bit framing header. That's prefixed by a block of zeros and a special 64-bit sync pattern per block. (I believe the whole sync structure was about 256 bits long.) The whole shebang is then Manchester encoded and put out to tape. Furthermore, the drive had a carrier-detect signal that it supplied in addition to the Manchester decoded bits.
The net result is a fairly robust protocol. Because the 32 data words were interleaved, dropout errors would get spread among multiple words. Thus, a burst error would show up only as 1 or 2 bit errors in each individual word. In addition, if a given word shows up as non-correctable, it was sometimes recoverable by flipping bits based on where the carrier was lost and trying again.
Other nifty aspects of its design: There was an additional pre-header on blocks that was recorded at (I think) 1/3rd the normal carrier frequency. This allowed the drive to detect interesting headers while fast-forwarding or rewinding. Since the drive was computer controlled, it allowed for fully automatic operation, including hardware seeks.
What was the bit rate? Well, I believe the raw bit rate for data bits coming off the tape was about 3000 bps. Factoring in encoding overhead, though, I'd say the final throughput was less than half that. A quick calculation suggests a nominal throughput around 1200 baud, give or take.
--Joe
Re:Alternative tools (Score:3, Interesting)
There used to be a Dutch radio program in the 80s called "NOS Hobbyscoop" that had their own basic interpreter for many computers of the day. (MSX, Acorn, Sharp MZ, etc.)
They actually broadcast computer programs every week on medium wave AM. They'd count down, you start the cassette recorder and you had some new programs.
Very interesting - that may be the first instance of P2P!
Re:Teach it! (Score:5, Interesting)
Of course I would! But this gets sticky. I gave away the Apple I schematics and monitor ROM (256 bytes to replace a front panel with a keyboard) but only a couple of copies of the BASIC, which I also intended to be in the open domain. I don't know if I ever gave away the completed Apple I BASIC because by then it was virtually the same for the Apple ][ (now completed) as well. We took the steps to retain the copyright for BASIC on the Apple ][. Any steps we took for the Apple I would be in the gray. I can't believe that it matters to Apple at all anyway.
Re:Alternative tools (Score:3, Interesting)
What really got me hooked on the ][ was the release of Sabotage and Sneakers in 1981.
Heh, I liked SABOTAGE so much I first repackaged it as a SYS file to run it under ProDOS, then a full disassembly of it, which led to removal the last bit of copy protection in it (intended to prevent memory dump cards, it would periodically test the data in the second text screen's screen holes and go into a memory-wiping loop, which also prevented going into the Apple IIgs Control Panel to adjust the processor speed).
I had intended eventually to upgrade the game to use Apple IIgs graphics, a saved high score list, and include day, night, and weather cycles. Unfortunately, even with a complete disassembly of the code, a lookup table for the new screen memory and new raster sprites, I never got myself a real assembler to make the final product (the new sprites required more memory than the original, so memory would have to shift to accommodate them).
If anyone knows of a free cross-assembler for Mac OS X to compile 65c02/65c816 assembly source, I'll dig out my old disks.