Hi,

I haven't looked into this in detail, but is it possible to use the tape interface (I am using an AIM65) to communicate with another device, but by removing the analog section?

It all starts and ends at the 6522 VIA, so it's ultimately digital.

What I am thinking is when I do a save (or restore) to/from tape that I hook in a digital device to save the data, instead of using tape. From the AIM65's perspective, it will think it is using its normal tape routines, but I have changed it at the interfacing end. I figure it won't be quick, but this is not an issue for me, where hooking in tape decks etc is problematic.

It looks do-able.

For a commercial product in the late 1980's I designed a modem to put serial data on cassette that we could make with about a dollar in parts, and it connected to the 65c51. I made one for home too, but the price, density, and speed of solid-state EERPOM or flash memory have put tape out of business-- even though I do like tape recorders, for reasons I don't totally know. The unfortunate thing about tape recorders today is getting replacement rubber parts, since the rubber belts and wheels rot. I fixed about a thousand tape recorders when I worked at TEAC in the early 1980's, and we normally replaced the rubber parts even if that's not what the machine was in for, just to extend the life of the machine that much more.

For 65-related stuff, it would be good to get on the 6502.org forum which is more likely to have someone knowledgeable in AIM-65 and has more traffic. This forum is kind of a sister forum that was formed for non-65 material.

I hear you about tape being a pain! Still, your best alternative may be to stick with audio but get a more modern device -- a memo recorder, perhaps, or maybe some of the portable music players let you both record & playback -- I don't know.

I have experience with the KIM-1 microcomputer, and the AIM's tape interface probably works on the same principal. The KIM uses frequency shift keying (FSK), and the "digital" signal at the peripheral pin is, in a sense, already audio. The pin outputs a rectangular wave which varies between two different audio frequencies -- a bit like Morse code, except there's no silence interspersed. The point is, for the computer to transmit one bit, the result on the peripheral pin is a bunch of successive transitions at the appropriate frequency. http://en.wikipedia.org/wiki/Frequency-shift_keying

You could digitally capture those transitions then reproduce them later, but it'd be inefficient, storage-wise, since each bit has gotten blown up, so to speak, by being encoded as FSK.

OTOH, storage is practically free these days. Also I certainly won't dissuade you from trying your own approach -- there's good fun and good educational value when you get off the beaten track! Good luck, and keep us posted (here or on 6502.org).

cheers,
Jeff

What my cheap modem did was also FSK, working more or less this way:

• The ACIA data output was used to connect or disconnect another resistor in an RC relaxation oscillator circuit, changing the frequency by a factor of about 2:1, allowing for a lot of slop in parts tolerances. The output was a triangle wave, close enough to a sine wave for the purpose, fed directly to the tape recorder.
• The tape recorder's output was amplified to clipping and then a capacitor was discharged during one half of the cycle, and the capacitor would charge up during the other half. If the half-cycle was short (ie, the higher frequency), the capacitor voltage would not reach a threshold on a schmitt-trigger input before the other edge latched it into a flip-flop. If the half-cycle were long (ie, the low frequency), the capacitor had time to charge up to the other state and get latched into the flip-flop. The flip-flop's output went to the ACIA's data input.

Since the tape recorder's output was amplified to severely clipping anyway (to turn it into a square wave), it could tolerate tape dropouts. How much speed error it could tolerate depended on how many bits per frame you used.

Here's a diagram taken from Appendix E of the KIM-1 User Manual. http://archive.6502.org/books/kim1_user_manual.pdf

The time taken to transmit a zero is the same as the time taken to transmit a one. Also, zeros and ones both begin with a period of high frequency and end with a period of low frequency. However, the change from high to low frequency occurs comparatively late for a zero, and occurs comparatively early for a one. As I said earlier, sending a single bit involves a bunch of transitions on the peripheral pin.

Nice work! Did your scheme also use multiple cycles of audio for each bit? -- I'm not sure I fully understand your explanation.

-- Jeff

Wow, that's a lot of pulses for a single bit.

Yes, I was thinking I should dig up a schematic-- although what I did at work used digitally controlled cassette transport directly, so the computer also controlled the transport, rather than requiring the user to push the right buttons when needed; so I also had the electronics to go directly to and from the tape heads which was rather simple since we weren't after low-distortion music. IIRC, I used 1200 and 2400 Hz, which proved 100% reliable for 300bps (the speed I used) and rarely gave an error for 600bps. I could have used higher frequencies for faster data if it were necessary, but not more than 4800Hz, as cassette frequency response is terrible at high record levels. When I worked at TEAC and was always repairing and aligning tape recorders, the open-reel machines' frequency response was always measured at 0VU, whereas cassettes' frequency response was measured at levels that were hardly above the noise level because marketing wanted you to think this cassette machine's frequency response was as good as the open reel's-- which was very misleading. Get them up to 0VU and the frequency response would start falling off at 5kHz or less. Get them up to +5 or +10 and it got even worse. The open reels' reponse was much more linear across the range of recording levels. Anyway, 1200Hz for 300bps mean you had 4 cycles for the 0, and 2400Hz meant 8 cycles for the 1.

Yes, but you're not stuck with that. In "The First Book Of KIM" by Jim Butterfield, Stan Ockers and Eric Rehnke, there's a utility by Mr Butterfield called Hypertape which writes out files to cassette at triple the speed noted above. Nevertheless the files are readable by the standard KIM-1 firmware. (He notes that, were he to abandon compatibility for standard readback, further speed increases would be possible).

The KIM-1 readback circuit uses a Phase Locked Loop (PLL) -- see the schematic on page 31 of the User Manual. And the ROM listings show the read and write routines. I expect similar documentation (schematic & code) are available for the AIM-65.

-- Jeff

I found it, but it's a poor-quality photocopy with light pencilled-in notes, so it would need to be re-drawn to make it intelligible here.

I forgot to mention that the transport also had an optocoupler that watched alternating black and silver stripes behind one of the reel tables so you could do a tape counter in software as well; and since the computer could control all the cassette transport functions (FWD, FF, REW, STOP) by energizing solenoids, we had an intelligent tape setup, unlike the home computer things that required the operator to press PLAY or REC at the right time, and which couldn't do their own seeking, like look up something in a FAT and then spin out to it and drop into PLAY at the right place for example. Ours could do all that.

The tape modem I made for home did not have the rec/play electronics integrated, but had a line driver & receiver so I could plug it into RS-232. I seem to have exhausted the places to look for that diagram. I apologize that I'm not doing very well tonight. I could trace the breadboard since I do know where that is; but if I had to do it again, I might use an 8-pin microcontroller now.

Tape modems are discussed further at http://forum.6502.org/viewtopic.php?f=4&t=82.

The Compukit did something similar, but perhaps not as minimal - "uses the time-constant of a monostable" - see page 5 and more of the manual
http://www.compukit.org/images/8/8e/Compukit-manual.pdf
which includes schematics.

A constant time per bit is a good approach for a UART-driven tape interface, of course. I think machines like the KIM-1 and Compukit all adhered to the Kansas City a.k.a. CUTS standard, which made them more interoperable.

I think the Apple 1, and II, and the much later ZX Spectrum from Sinclair, used a single-transition per bit with different bit times to distinguish 1 from 0. They would be faster, and perhaps a little less robust. The Apple 1 cassette interface can be found in the short manual at
ftp://ftp.apple.asimov.net/pub/apple_II ... ssette.pdf

A software "UART" is easily able to deal with this kind of modulation. A hardware UART or ACIA, not so much.

Cheers
Ed

The discussion about using actual tape is darn interesting -- it really is! -- and it supplies us with necessary background information. But let's remember the OP's goal is not to reinvent the tape interface but to hack it (or replace it with an alternative system, perhaps). So, if tape isn't used, what would the storage medium (and its recorder/player) be? Here are a few prospects. Other suggestions welcome!

• Use some sort of modern-day audio recorder. There'd be no new wiring required other than a patch cable, perhaps. I haven't researched the market, but I know cheap memo recorders can be bought; also fairly high-class portable devices used by musicians and audiophiles (example: the Zoom http://www.zoom.co.jp/). For our purposes we'd want a low-end music recorder or a better-than-average memo recorder. Or maybe an utterly average memo recorder would suffice. Unfortunately it's doubtful that memo recorders are equipped with mic and headphone jacks.
  
  
• Use a host PC -- but how to interface to it? From the peripheral pin on the AIM65, a simple circuit (or a microcontroller) could translate that signal into a UART-type character stream fed to the host. One possible encoding would use just two characters (wasteful, but no matter). One character would mean, "I've just had a transition, and it arrived soon after the one before." Its partner would indicate a transition that arrived comparatively late after the one before. I'm just thinking out loud here!
  
  
• (post-script) the host PC has mic & headphone jacks. And there's software available that'll let it emulate an audio recorder.
  
  
• Use an SD card, or one of the cheap, tiny serial EEPROMs. There are (at least) two ways this could work. Either the AIM65 bit-bangs straight to the memory (and thus requires its own code), or the AIM65 continues to believe a cassette is there, and a microcontroller grabs the bit stream (as in the PC example above).

The cassette replacement is an appealing project, but there's clearly more work to be done. We haven't heard back from the OP, so I'll send a PM in case these recent posts got overlooked.

-- Jeff

Hi,

I'm still here. Just been mega busy at work and come home and just eat then sleep.

I will be going through the posts in more detail. Yes, I got an alert from Garth's reply but no others.

I've just finishing up the last bits that need sorting on my expanded AIM65. I just finished successfully testing the 6551 ACIA interface and I am happy, as the expansion has worked flawlessly. I am just in the process of finishing off the labels for the various outputs and attached the breadboard for some serious development work. I can throw some pics up if you are interested.

The challenge with using the tape interface is the same as a replacement display - which I am investigating at the moment - is to use the existing hardware and software of the AIM. I can change the monitor code and things like that but it can change the addresses of known subroutines, which will crash existing programs that use these AIM65 subroutines.

I was thinking of using maybe a microcontroller which would connect to the actual pin outs of the 6522 device itself, and bypass the analog circuitry. I'd have to program the smart stuff in the microcontroller to save (possibly to a serial eprom) and also load. I could store a lot of software on such a eprom, but I think the AIM software is expecting a dumb serial input. That is, when you search for a program the tape will run and the AIM will not load until it finds the program name it is seeking. On a small 5minute cassette that is okay but it will take some time if I have a lot of software on a 2Mb eprom

So, need to think about this one. But, that was my general idea.

That sounds interesting. A digital memo recorder would work and if it accepted mic and spkr jacks. Though, as you say, they may be thin on the ground. Maybe some older 2nd hand units which I can open up and have a peek... see if I can also use the remote control line of the AIM.

It is interesting and giving me food for thought.

Hi,

Sorry for long delay in replying, but work and home life have been busy. We are getting a large rear house extension being done. Well, it's almost done now and just the furnishings are to be finished.

Anyway, that's been keeping me busy, and a part of the extension is a small workshop area for my electronics gear so I don't need to use one of the bedrooms.

While I am still eager to see what I can do with the tape interface on the AIM65, I found a number of old systems I forgot about. It was like going back in time. I discovered I have 3 AIM65s, and have got 2 of them working with all the LEDs, which I took from the 3rd "donor" unit. I can try and find the DL LED units for the AIM but they are hard to find and not cheap, so figured I may need to rig up a new display. Thinking of using normal 14 seg LEDs on a carrier board, controlled by a AVR or something similar.

And then I saw my old 990/189 TI University Board, and it needs some TLC. So I felt sad for it and have ordered some 9980, 9901 and 9902 chips. I got the UNIBug hex dump, so I may try and get it restored over the Xmas break.

And then... it just rolled on as I dug through stuff I haven't looked at for 20 years... 2650 systems, SC/MP LCDS, STD bus, S100 bus, Exorciser (and old Motorola Micromodule gear)... storage boxes full of processors, peripheral and memory chips... and so on.

So, I haven't run away from here and I still have plans... but crikey... I just got knee deep in old tech that needs some loving.

Sounds like a great collection to dig through.

It looks like Avago Tech make a DL1414 compatible display module - maybe that will work in an AIM65?
http://www.avagotech.com/pages/en/led_d ... hdlg-1414/
http://uk.mouser.com/Avago-Technologies ... ?P=1z0zlfz

Hi,

Yes, a lot to go through and sort out. It will take time.

The 1414 looks interesting as I can't get any of the original 1416s anymore. Well, you can get them but they are with the large surplus companies. Most don't want to know you unless you are buying $1000 lots, and one company I found does sell single items to hobbyists, They had 23 of the 1416s in stock, at a rather ridiculous sum of $349USD per device!

Same for the SC/MP processor. One company had over 1200 in stock and they were some stupid price. I don't get it. It's not like anyone will design something new based off an old defunct processor, so no one is going to come along and want to buy 1000 chips. Furthermore I doubt there would be enough (for example) SC/MP systems around which need service and thus make financial sense to purchase a huge amount of these chips. Why not sell them cheap to the hobbyists, or else the stock will sit there for decades taking up room and not bringing any profit.

Oh well, that's my rant.

Back to the AIM65 display... as it appears the DL1416 is out of the question, it comes down to using something like the 1414 or use a microcontroller to run dumb 16seg LEDs. The AIM sends out the ASCII code, 2 bit address and a /WR pulse to load the data into the 1416. I will check the datasheets to see if the 1414 will accept these signals. The 1414 doesn't have some of the control signals of the 1416 and also the blank pin, but I need to check if this will be an issue. In any event, due to different pin outs I will have to make a carrier board for the new display.

Alternative is to use a microcontroller running dumb 16seg displays. Doing this with no code changes to the AIM means I will need to have a fast processor as it will need to determine which AIM LED is being addressed and convert the ASCII data to enable the LED to display it properly. I figure to have the /WR and /CS pins create an interrupt to determine the LED (1 of 20, as per AIM display) then suck in the ASCII code (from the AIM) and then use a look up table to send to the LED display to show the value. As there is a bit more work here I think a faster microcontroller may be needed so it doesn't miss any incoming display data from the AIM.

Time, alas, is my enemy, so I will just have to add this to the ever growing list of things to be done to keep some of these old girls running.

Edit: I could use a 20char LED display I suppose. Never gave that much thought but it could be a viable option and reduce the amount of processing required to convert the outgoing 1416 signals/char to the new LCD. Hmmm, I will check this out,

In the interim, hope you all have a safe and wonderful Xmas & new Year.