I was doing some reading about 70s Atari tech and I came across a term that I was quite unfamiliar with: a bit-boffer. Turns out it's an early simplex UART with an analog tape machine on one end and a set of dedicated tx/clk and rx/clk lines.
The cassette interface was all the rage in the 70s and along with the paper tape on my ASR-33 teletype, my first mass storage for a personal computer. I built the Lancaster version but there was a local guy in our computer club that had a circuit as well which a lot of people in the DFW area used. They were a little fiddly and not necessarily universally interchangeable.
I used it to store programs from a single board computer on cassette tape and then be able to load them back for use another day. It saved a lot of typing! We didn't have a disk system and no eeprom either. Those were the old days!
Also used the SWTPC AC-30 cassette interface at work. It was pretty reliable. All of those systems used what was called the Kansas City Standard and would record/playback at up to a blazing 120 bytes/second.
The one I used worked at 300 baud. It was fun to watch the text appear on the TV monitor as the program loaded! Later, I pushed it to 600 baud, but it then showed some errors.
Correct. Surprisingly, it looks like a lot of these systems used a mono track, when they could have put a clock signal on the other track and increased I/O speed by leaps and bounds. I think larger machines did it with clock signals.
I don't recall if that was discussed at the time or not. In the 70s, stereo recorders were probably not that common. There was lots of discussion about the merits of various versions of the cassette interface at our local computer club, possibly because one of the early makers was Harold Mauch who was a member. No debate on number of tracks that I recall though. That was a while back though.
Part of the goal of my Atari projects is to add a cassette reader/writer and an associated buffer in a hole in the memory map. I was considering using a MOSFET push/pull circuit, controlling two tones, using stereo encoding, and pairing the clock signal with the data + a parity bit. Very similar to and I2C circuit. A $20 stereo voice recorder could probably do the job.
Good question, in addition to. I intend to make only upgrades that are compatible with existing hardware and software. I figured out how to make a controller with many more buttons that's completely compatible with all existing joystick titles.
If you want to teach assembly, basic, and architecture to a kid, you can't do better than a 2600.
The Kansas City Standard uses 1200 and 2400 Hz synchronized tones so the 'clock' is included, so to speak. The system I used fed square waves to the recorder. That could be improved by sending more sine wave like tones. Separating the clock and data seems a waste of time. I do not see any advantage for including a parity bit. It will slow down data transfer and without handshaking you can't ask for a repeat of flawed data.
My crude understand is that the tape systems used today have many tracks including dedicated clock tracks and have tracking and labeling systems that can quickly guide the media to the correct section, as well as allowing for a rapid count back to repeat a misunderstood word. I'm just a novice in this area though.
So far as KCS, I just need the ability to read it, I do not plan on using it to store new data. I hope to achieve speeds much higher than 2400bps by working in the range of brilliance tones.
Alright, I understand. You want to read the old standard and be able to read/write a new, modern standard. That sounds like a good project -- good luck with it!
