In the late 1970'ties, I had a AIM65 system, and sold some 35-40 pcs. of this fine system to HAM-radioamateurs. It was quite advanced at the time, with RM65 Piggyback, CRT-controller, Floppy-Controller for 2 x dobbeltsidet, dobbelt densiti disksystem,in all, 36 K byte RAM so it worked great with 2 PASS Assembler, PL1, Forth, Pascal, 12 K disk-oriented Basic (a copy af Commodore64 Basic), and it gave me a lot of fun .

In 1985 I changed my work, to operator on large Gunverment Computersystem, and I had to put my vintage system out in the garage, and 10 years after it went to the dump.

Few weeks ago, I had a talk with another HAM-fellow, and he had a AIM65 system he would give to me, as he heard my vintage story, so now... I am in a nostalgic periode of my 75 years old life.

The last 15 years I have my pension, worked my HAM-radio, and had a look at ARDUINO for different projects.
It had a lot of fun making a homemade 3D-printer, and measuring instrument for the HAM's, and other HAM-related projects, and now I have the AIM65 up and running, after i found a box, diip back in my garage with some ROM's EPROMS and other AIM65 related stuff.

Some HAM-friends have donated a tape-station, and now it is running fine on the AIM65, but this have started some thoughts about making a RAM-disk I/O system, based on a ARDUINO (mega) and a pair of SD-card readers. The Arduino programming in C is not a problem, and using AIM65 I/O-system for tape, it would be minimum change in the AIM65 monitorsystem, to use such a system for input and output via the tape-function in AIM65.

NOW...
I wonder, if any other eksperimentator here in this FORUM, ever had thoughts about such a system?
OR...
If any other eksperimentator here in this FORUM, would like to works with me on such a SD-card read/write system, to replace a tape recorder-based system on any 6502 vintage computer?

For any responce, use my e-mail: oz6ym(at)planker.dk
and if interested, look at my homepage: http://www.planker.dk
(sorry for my bad english, but it is NOT my born language.. )

VY 73 de OZ6YM, Palle

Welcome Palle!

That's a story - back in the very late 70's I was very impressed about the AIM65. But I didn't want to spent that much money and started with a SYM-1.

For clarity: you are aiming towards an audio recorder replacement that is capable to receive "audio" and playback "audio" so that the AIM machine requires no change? Then, yes, I have thought about something (silly) similar to replace the audio tape for my SYM. AFAIK it's not possible to use a MP3 recorder. So there is more work necessary. I have to look whether I can retrieve some informations I gathered so far this evening.


Cheers,
Arne

Welcome Palle! This is a great idea for a project - but I can't offer any prior experience of my own.

I've not done anything with stored audio myself, but it might be worth looking at the WAV file format. I've heard that if it's the right kind of WAV, it's just a header and raw PCM samples. If your device records it, you can ensure it's the right sort.

From what I read over on VFC some time ago it's not that much of a problem to use MP3, as the frequencies that are in use are low and very specific. On the other hand files won't be big even uncompressed.

I'd be inclined to tackle the audio tape problem not as an audio problem or a waveform problem but by decoding and re-encoding the waveforms for each bit. This could be more reliable as well as more dense. There's information about the three different low-level formats in the User's Guide which is available here in PDF and here online. (The PDF version is clearer but the online version is OCRed.)

There's also information on the higher-level organisation into checksum-protected blocks and into files. It might be worthwhile to work at the block level.

Here are some images from the manual, of the lowest level.

Using MP3 is a *bad* idea for this type of thing.

MP3 works by taking an FFT over a relatively long window of audio, then trying to work out what frequencies a human wouldn't notice if they were missing (or heavily quantised). Unfortunately modems, including tape-modems, work at much shorter timescales than the human ear, and are sensitive to frequencies in a very different way. Thus MP3 has a nasty tendency to destroy the encoded information, even though it still sounds like the output of a tape-modem by ear.

If you do want to keep the raw audio rather than a decoded representation of it, you could use FLAC instead, as that is lossless. It's almost certainly okay to use a low sample rate and bit depth, and monophonic of course, so that'll take up less space than CD-quality audio in any case.

Well, Chromatix did already explain the problem with MP3° precisely. And thanks to BigEd we don't need to search for information about the tape output signals of an AIM - very helpful!

If one would sample the signal directly (no knowledge of its structure) the sample rate needs to be at least 16 Ksps. We have 2400 Hz and there needs to be at least the 3rd harmonic recorded to reconstruct something that looks similar to the original. And then there is Mr. Nyquist so we need 2400x3x2=14400 sps at least. But we also need nearly no amplitude resolution as there are only two different levels. So 16 kbit/s should be sufficient for raw data.

On the other hand a single bit is encoded within ~7,5 ms. That is a data rate of 134 bit/s. In relation to 16 Kbit/s this is 120x less or requires 120x more storage

The only advantage of dealing with raw samples is that it doesn't matter what kind of source format and encoding is used. Even a KIM or an OSI "tape" should work.

I think Palle is the one who should choose which way to go.


Cheers,
Arne

______
°: Yes, MP3 would not work. I never tried this way: The output of a frequency discriminator mutes either the left or the right channel signal for a stereo record using MP3. If the signal is about 8 KHz it would be chopped on both channels with a low rate (134 times per second). I never tried but I think this would not disturbed too seriously by an MP3 encoder.

I think we can say there are two kinds of tape formats. The Kansas City or CUTS style of tape uses tones - very brief tones in the case of Acorn's BBC Micro at its faster speed. The other style of tape uses the timings of zero-crossings - the C64, the Spectrum use this method. It's a bit like a disk signal. An efficient way to deal with this type is to take the time difference between zero crossings. If you know what kind of format you're dealing with, you can then compare the time difference with a threshold, because there are only long gaps and short gaps to deal with. These are not quite the zeros and ones but they are very close to it.

These AIM65 and KIM-1 formats are something in between, if there is such a thing.

VCF, do you mean (Vintage Computer Forum)? If you're able to find a specific link that'd be great.

It's an immense simplification to speak of MP3 without noting the very large variability that's possible. I'm ready to believe MP3 could work fine or fail entirely, and it'll depend on the degrees and types of compression that are selected. But these factors may not be under one's control, depending on the method or equipment in use. In that respect MP3 presents a practical barrier, though not a theoretical one. Inexpensive consumer devices capable of encoding MP3 are usually stereo only, with fixed (and unfavorable) degrees and types of compression.

WAV format was also mentioned, which can be fairly compact if it's monaural and the sample rate and bit depth are modest. But, again, gaining access to this encoding may present a practical barrier.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Going after MP3 is kind of a waste of time though, even if it's "free".

We're talking an AIM-65. We're talking, what, 1500 baud? So, ~150 characters (bytes) per second. We see the highest frequency needed is 2400Hz, so an 8KHz sampler is more than adequate to the task (8Khz typically being used for voice, and its best to sample at more than twice the maximum frequency).

So, 32K of RAM, 150 BPS, 8Khz. That works out to about 1.8MB sample (the recording pushes the 4 minute mark).

Ok, 16GB SD Card. That's almost 10,000 recordings. Which probably counts for more recordings than the entirety of the AIM-65 ever had.

Compressing the audio doesn't make it load any faster. Storage is cheap. As someone else mentioned, you're better off decoding and encoding it (and saving out the 32K image) if you're that concerned with space.

Considering I just bought a 64 GB SD card for $39 USD, I'd say you are correct.

Anyone know what that would have cost in 1980 using Apple II floppies? LOL

_________________
Cat; the other white meat.

It would have cost "a large fleet of lorries to cart its microstored edition around in".

Dear 6502-friends...
I se that many of you have done some thoughts about my isu, and i thank you all for these comments and reply.

I to have more though about this, and by looking at the diagram of the AIM65, I also could se some problems in the software for the ARDUINO.

How could i get the filename into the Arduino from the AIM65?
1: by opening a user defined routine to start the Arduino?
2: and skip the direct tape-format?
3: Would it be better with the TTY-port, and use digital signal in stet of sound?
This will be at more stabil teknik, and better data-compressing and unlimited storage room on 32 GBYTE SD-card.
4: I also need to consider whether it might be a better solution to simply transfer data such as serial data to Arduino.

I think i make some test about this TTY-use..

I have 4 to 6 weeks waitingtime for the CHINA-post to arrive with the SD-card-readers, and next week, ( July 14 - 22 ) is hollyday-week and Camping at a HAM-meeting here in Denmark,
but I will still follow the continued dialogue here at the forum, and if any of you have constructive suggestions, they are very welcome.

Of course, I have looked at the tape system's timings, and my thoughts have shifted slightly to maybe using TTY/serial instead of tape.
I still have plenty of time to think before doing practical work.

Regards OZ6YM, Palle

Hi Palle,

I have no handbook at hands but the AIM is similar to KIM and SYM - looking there may give you some hints as well - and I know that the "file name" is part of the data when saving a "file" (actually you are saving a memory region). There is somewhere a description of the file format(s) AIM is using. One is KIM compatible IIRC, and there may be something like a "paper tape" format as well (the SYM has such). But a second way to select which record the Arduino should play back is helpful.

Using TTY instead of sound makes things a lot easier! But probably you have to write some software on the AIM to create a sort of data envelope to submit necessary information for the Arduino. Otherwise the Arduino may save the information but has no means to select what is to play back. You may also write some software on the Arduino to manage whatever the AIM is sends or receives. You can mimic a sort of tape or paper tape puncher/reader on the Arduino. Then again you need a way to manage which chunk of data is to be played back.


Cheers,
Arne