How to interact with your 6502 computer?

[GARTHWILSON]

There were battery-backed SRAM systems back then, but it all cost money. My HP-71 hand-held computer from the mid-80's had an extra 160KB of RAM that I paid hundreds of dollars for back then, in addition to the price of the bare machine which came with only 17KB stock. I would have liked even more, like a quarter megabyte, but I got all my budget allowed. (Now I get half-megabyte SRAMs for the memory modules I sell for $2.50 each in quantity, including shipping. I had the high-speed digital microcassette drive which never gave me an error and went a few hundred bytes per second and had its own intelligence built in with FAT and so on, but it was really only for backup since I could keep all my files in RAM. That thing cost me $500 IIRC, and tapes that held 128KB cost $10-$15.

[White Flame]

sark02 wrote:

but I've not come across anyone (as far as I know), who yearns for those screeching tones, long wait times and tape loading errors.

I'm sure they're out there, though...

Emulator writers fall into that category, trying to exactly (and hopefully optionally) replicate every little quirk and exact timing of long processes. Obviously that's a must for software that relies on such behavior, but after that the emulators tend to go well beyond what's required.

[sark02]

White Flame wrote:

sark02 wrote:

but I've not come across anyone (as far as I know), who yearns for those screeching tones, long wait times and tape loading errors.

I'm sure they're out there, though...

Emulator writers fall into that category, trying to exactly (and hopefully optionally) replicate every little quirk and exact timing of long processes. Obviously that's a must for software that relies on such behavior, but after that the emulators tend to go well beyond what's required.

I have a ZX Spectrum emulator that can take a wav file as a tape source. I tried it once... I sampled an old tape from my collection and then fed the file into the emulator. I sat there... for minutes... as it ran in real time, making those oh so familiar sounds and displaying the stripey patterns on the screen.

Tape loading error.

[Dr Jefyll]

sark02 wrote:

Tape loading error.

Nice! The emulator works just like the real thing.

[sark02]

Dr Jefyll wrote:

sark02 wrote:

Tape loading error.

Nice! The emulator works just like the real thing.

Yeah it does!

[whartung]

sark02 wrote:

Dr Jefyll wrote:

sark02 wrote:

Tape loading error.

Nice! The emulator works just like the real thing.

Yeah it does!

Relive the glory days!

There was a game for the C64 and Atari, called Telengard -- early fantasy dungeon crawl.

It took so long to load, ala 45m, we would just leave the computer on, and not shut it off over night.

There's an Atari 800 emulator out there (who's name eludes me, and I'm simply not going to google it right now, but it's a top hit if you search), and the quirks and timing tricks they duplicate are legion. Reading the document they wrote about it just tells a) a heck of a lot about the Atari, but not only that, b) the ingenuity of the programmers pushing the machine to it's limits.

But this highlights another point, despite our fascination with these contraptions, in the end, the computers are mostly uninteresting in and of themselves. What's interesting is the problems they solve for us, or even how they solve those problems. A computer without a purpose is a combination piece of sculpture and room heater.

When my Dad passed, he had the original TRS-80 that I used to learn on ages past. I took a moment to try and at least fire it up, but I knew in my heart I couldn't take it home. For one, I would have had to ship it cross country, but, more importantly, there simply was no place for it besides locked away in a box in an attic. Even if I displayed it, it would simply be Yet Another Thing to dust. So, I sent it off to auction. Hopefully someone there bought it who could do something more with it.

[barrym95838]

My Franklin Ace 2200 is all boxed up and ready to send to cbmeeks, but I'm waiting for my parents to make their final cross-country trip when they move from California to Georgia, and I'll see if I can find a spot to stow it in their minivan. My dad is actually the original owner, but I used it during college in the late 80s as a word processor. The 24-pin Epson LQ-850 had sufficient print quality for all of my essays and reports, but AppleWriter didn't do well with proportional fonts, so I just used fixed-width. My 9-pin MX-80 generated a couple of teacher complaints in high school, so I knew it wasn't gonna fly in college.

Mike B.

[Aslak3]

sark02 wrote:

Dr Jefyll wrote:

sark02 wrote:

Tape loading error.

Nice! The emulator works just like the real thing.

Yeah it does!

Awesome! I've never tried sampling a tape as a WAV and playing it back, but I'm tempted now. Waiting 5 minutes for games to load, and the "agony" of errors with 5 seconds to go is a quintessential part of the Spectrum, and presumably other machines, experience. I will remember those distinctive tones for all time.

R Tape loading error

I don't know about the other micros, but the Speccy was AMAZINGLY fussy about how you loaded programs from tape. I remember, after a long struggle, I found a tape player that seemingly could reliably load and save programs. I kept hold of that tape player for a long time, long after we upgraded a Speccy 128K +2, which largely, but not completely, solved the reliability problems with tape loading with its built in player.

For the experience, I'm inclined to have a go at implementing a tape interface for my homebrew micro, just for the hell (and satisfaction, and plain old fun) of it.

[barrym95838]

My experiences with audio tape storage in the early 1980s, ranked by perceived reliability * performance:
1st: Apple ][
2nd: C=64
distant 3rd: TRS-80

My experiences with 5.25" floppies in the mid 1980s, ranked by perceived reliability * performance:
1st: Apple ][
distant 2nd: C=64

Mike B.

[sark02]

Aslak3 wrote:

For the experience, I'm inclined to have a go at implementing a tape interface for my homebrew micro, just for the hell (and satisfaction, and plain old fun) of it.

That would be a really interesting project, I think. If you remember, the Spectrum had a single-bit speaker/microphone. Generating a set of tones at different frequencies (single-bit square waves) would be straightforward, but I wonder how hard it would be to pick out the tones in an analog tape receive channel, given that it would be full of noise. All this without cheating by reading Dr Logan's "Complete Spectrum ROM Disassembly"

I'm sure there are well established signal analysis algorithms for this, but that's a topic I never studied, so although I can immediately imagine some trivial approaches, I suspect they'd have some underlying fundamental math error that would make them unreliable in a noisy environment.

You should definitely have a go, and blog about your progress as you go, showing your successes and failures!

[barrym95838]

sark02 wrote:

... I'm sure there are well established signal analysis algorithms for this, but that's a topic I never studied, so although I can immediately imagine some trivial approaches, I suspect they'd have some underlying fundamental math error that would make them unreliable in a noisy environment ...

Woz whipped up a quick and reliable (relatively speaking) one-bit tape interface 40 years ago. As soon as you got the play-back volume set properly it was rock-solid (relatively speaking), at least by the time it made it into the Apple ][ monitor ROM.

http://www.sbprojects.com/projects/apple1/aci.php

http://www.easy68k.com/paulrsm/6502/MON.TXT
[applicable addresses are $FCC9..$FD0B , $FECD..$FEF5 , $FEFD..$FF3E]


Mike B.

[GARTHWILSON]

I designed a tape modem for a product in the late 1980's.  The problem really is not noise.  The signal level is near saturation level of the tape anyway, so noise is well masked.  The common circuits of the day apparently were very sensitive for getting the right level, particularly that of the playback.  I did didn't even care about playback level, because I used an op amp at very high gain to amplify it to clipping anyway, then fed it into a 74HC14 Schmitt-trigger inverter to get a clean square-wave output with fast edges.  That output went into the clock input of a 74HC74 flip-flop, and also reset an RxC time constant that went through another 74CH Schmitt-trigger inverter to the D input of the flip-flop.  I used two frequencies.  At the higher frequency, then next rising clock edge would trigger the FF before the RC had had time to get charged enough to change the data at the D input of the FF.  At the lower frequency, the D input would already have changed before the rising clock edge.  The FF's output went to the 65c51 ACIA's RxD input.

I used 1200Hz and 2400Hz, which were easy to tell apart with cheap (non-precision) parts, then 300bps gave four cycles at the lower frequency and eight for the higher frequency, which proved to be plenty.  There were no glitches at the frequency change, and it didn't matter what part of the cycle it was at when the change took place.  300bps may be too slow for loading a game, but it was plenty fast for our unrelated application, and I tested for hours, with cheap tape, and never got an error.  When I doubled the rate to 600bps, I got an error every few hundred bytes.

I had worked as a repair tech at TEAC a few years earlier, and I aligned every machine when I was done with it.  I was quite familiar with the poor performance of cassettes, which might not be what you'd expect.  Dropouts are a big problem with cassettes.  These are tiny spots in the tape's magnetic coating where the output, particularly at high frequencies, drops way down.  If you play back a solid tone and watch it on an oscilloscope, you'll see the amplitude bobbling badly, even with good tape and a good machine.  This is why I chose to amplify the signal from the tape to the point that it would be clipping with any amount of real signal from the tape.

Also, at 0VU, cassettes' frequency response is terrible.  It only goes to about 4kHz.  You might look at the specs on your expensive home-entertainment cassette machine and see something like 16kHz; but that's always measured at extremely low levels, like -40VU, so as not to scare the prospective buyer away.  I used a triangle wave which is easy to produce with penny parts and not have much harmonic content, and used frequencies that were high enough that the harmonics were in the area where the tape's response naturally attenuated them anyway.

Another problem for typical cassette data circuits is that at high frequencies, the phase is all over the place because of poor tape handling in the shell and not moving the tape fast enough for the amount of flexibility of the tape itself.  If you play the left and right channels into the X and Y inputs of an oscilloscope and get a Lissajous pattern at high frequencies, what you'll see is like scribbling all over the center of the screen, because of the bad phase behavior and inconsistent output level.  The poor phase response undoubtedly contributes to the error rate in the way some cassette data circuits were designed.

OTOH, the open-reel machines gave solid, steady tones at 20kHz and 0VU.  There was no need to hide the truth by manipulating the specs.

A few years after designing the tape modem described above, I made one for home use but added the RS-232 line drivers and receivers for use with an RS-232 port (TxD and RxD only, no handshaking) on my workbench computer.  Soon after that however, I²C serial EEPROMs were coming in, with densities that competed with a cassette, and much higher speeds, and much tinier packages, so the cassette tape modem went by the wayside.  On top of that, tape machines rely on the rubber belts and idler wheels which rot, and replacement parts have become unavailable.  (The pinch roller doesn't last indefinitely either, but tends to last a lot longer than the other rubber parts.)  At TEAC we always replaced all the rubber parts on every machine we worked on, just to make sure it would last that much longer, even though the machine was normally in for something else.  Heads wear out too; but if you're not using the machine hours every week, the heads will probably long outlive the rubber parts.

[whartung]

The cassette on the PET 2001 that we used were pretty much rock solid. I won't say they never failed, but I can't think of any times we had any problems with it, and boy did we use it a lot. When the folks that donated that computers to the school, they also donated stacks and stacks of blank cassettes. These were specific for data storage, in that they were all pretty short (I would say probably a 10-15 minute cassette length). That's worked really well.

I don't recall having any real problems with my KIM-1, or my Model 100. I was disappointed with the one for the Atari. I swapped that out for a disk drive quite quickly.

[Tor]

I was writing some software for a Dragon 32 once, it took a couple of weeks and I would store the program on cassette tape every day and start from there the next day. The cassette tape was so unreliable that I always wrote to at least three cassettes, in the hope that one would be working the next day.

On the other hand I've had nearly the same experience with DAT, I used to work with an SGI Indy at home, and synchronise with work by bringing DAT tapes forth and back. It was so unreliable that I got flashbacks to my experience with the Dragon more than a decade earlier.

(The Dragon was a British clone of the TRS-80 6809 Color Computer)

[Arlet]

The cassette tape on my Atom was fairly reliable, as long as you played them back on the same recorder. Exchanging tapes with friends often didn't work, but could usually be fixed by adjusting the angle of the recording head by turning a little screw. Of course, once you started messing with that, there was no going back, as each recording was done with a different angle.

Attached schematic of analog input section for the cassette tape. They used a simple FSK encoding, and the decoder simply counted the number of cycles between zero crossings.