Hello everyone!

I have an update after testing some stuff. I'm doing this for myself, and anyone else interested.

Attached is some C++ code. I'm using 'sox' to create a synth square wave at 1000 Hz, cut 0.5ms out of it and use it for a '1', and then use padding (silence) for '0'. My packet is designed as: 10XXXXXXXX0. So the idea is that the start bit 1 triggers an interrupt (or whatever), 0 after it because I can then test the length of the 1 before it and thus every bit if desired (for baud rate), 8 data bits, then a 0 stop bit (which just acts as padding between packets honestly).

This code sends $AA as a test pattern, and then whatever else. Here I'm only sending one extra byte, a $C8 I think. And the recording part is great!

But my computer is not apparently. I can get some really nice outputs sometimes, but other times it garbles the output. Randomly losing signal. For a good while I was getting clean waves, but this morning I'm getting trash on and off. I thought it was my breadboard, but I don't think so. I sent this to my phone and played it out of the headphone jack (good thing I used a pot instead of 22K resistor!) and it comes up clean every time.

Some problems I am seeing though:

First, audio jacks sometimes give me fits sometimes anyways. I can get a ok sound from it when listening to music, but that doesn't mean my data will be great! Does your computer have a clean audio output? Does your neighbor's computer have a clean audio output? The point is that this data is delicate stuff, and a fuzzball can make a difference. Heck, even without fuzzballs, my desktop is acting randomly at times. Any thoughts on how this type of thing was circumvented in the past? If my desktop can't output correctly, golly, I can't rely on my neighbor's computer at all!

Second, the use of the pot is great... when I have it attached to a scope. I can adjust it just right, and make a clean signal. Too much and it shuts everything down, too little and it's wild. That's why I added the test byte/pattern in the beginning, so that the 6502 would know if everything is right or not right. Might end up adding a few more! I do not see any other way around this little issue, but if you have any other ideas I'm willing to hear them.

Just reporting back some findings. I was REALLY thinking this would work great, but getting these random signal interruptions this morning has been a let-down. Dang. *shrug* I guess that's why disks were so good!

Thanks everyone.

Chad

EDIT: Well, my circuit isn't working perfectly either apparently. If I try to keep a '1' signal too long it kind of fades out over time. That's something I can work around, but the above still stands. Just another update. Thanks!

EDIT2: I am replacing my C++ file with an updated one, this time my packets are only sending a nibble: 10XXXX0. The reasoning is because the circuit can't hold the '1' for more than some amount of time before it just drops to a zero. This should correct that since the longest span of 1's is only 4 now.

Also I restarted my computer and it's outputting audio better now, though every once in a while it's goofy again.

And thanks for the reply Ed.

Interesting notes, thanks. I think one of the aims of cassette interfaces back in the day would be to cope with a wide range of signal levels, although some systems needed more delicate fine-tuning of the volume knob that others. Which is to say, your minimal-complexity setup might be expected to be more finicky.

Audio is very demanding - any other load on the computer or anything it decides to do while also putting out sound might cause an interruption. We had an adventure on stardot where someone's efforts to digitise a tape were, as it turned out, introducing unwanted snippings-out because the computer couldn't keep up.

It's hopeful, then, that using a phone to play the sound is working better.

On the receiving code, you want to distinguish between tone and silence, and it would be advantageous if this detection was robust. Perhaps knowing the structure of the input will help: perhaps, for example, you could wait for 100ms of continuous tone or continuous silence before flipping the output of the detector. A bit of hysteresis.

So I've been on a bit of a quest today. Trying to make this thing reach a 74HC' without a 74HCT' in between.

Attached is what I came up with. I think this works, I have been testing it with the 'scope with various levels of the pot.

I am seeing signal degradation if I try to hold the signal high too long. I see what's coming in and out of the OpAmp and it spikes at the beginning, but trails off rather quickly. Adjusting the pot lengthens or shortens the duration of a $FF type of byte, which is bad news. Single short bursts are unaffected. The $00 type bytes seem unaffected.

Anyways, the two 2N2222 transistors step-up the signal coming out of the OpAmp from around 3V or so to 5V. I'm getting a nice clean signal on a plain ol' 74HC00 with this! Does this look right to you guys? I am extremely new to analog stuff. Looking stuff up online has helped a bit of course.

Just wanted to by-pass a whole 74HCT' chip, that was the main goal of the day. I'm a little worried about signal degradation, though that's not the transistors fault (was getting that with the 74HCT' chip too), but I'll be working with this in software and hope to report back more results soon.

Thanks everyone!

Chad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I don't mind high or low honestly, I'll be connecting it to a VIA and 'babysitting' the input. I could use interrupts, but even then either high or low is fine.

I went to the LM393 datasheet, well one of them, and I cannot find a configuration that matches what I'm trying to do. There seems to be a LOT of configurations though:

https://www.ti.com/lit/ds/symlink/lm393-n.pdf

If you give more input, I'll receive it gladly! Thank you Garth.

Chad

Hey everyone!

I got a PM from MichaelA yesterday, and he helped me with a new style, using the OpAmp as a amplifier, not a comparator. Thank you Michael, I hope you are ok with me posting about this.

Attached is what I've got going. I haven't verified with Michael if that is exactly what he was thinking about, but he did confirm the outline I used was correct.

I think the signal is more consistent, adjusting the pot does not change much besides a bit of duration, but definitely within spec. BUT, it seems to only work properly if I use the entire sine/square wave, both positive and negative. If I use only positive and 0V audio format, the pot varies the signal duration to much greater lengths, which is not good for speed purposes of course.

Can I make full sine/square waves on the desktop computer? Yes. Can I create those from a 6502 5V system (when I'm recording)? Eh. So I did some research, and made a little tester 'audio-out' circuit using a capacitor and big resistor (see attached). The problem I am seeing is that it takes a while to 'warm up', but if I have a oscillating signal and simply 'turn it on' for some time, I think I can get a signal out that would make sense to the desktop computer. Don't know how to do that yet! I had assumed that sending audio out of a 6502 was literally just putting a 10K resistor on a signal line. That is what I had seen on the Apple 1 cassette schematic, or at least how I interpreted it.

I think there are ways to create sine/square waves with both positive and negative voltages using a DAC or something, but I am very very unfamiliar with that.

So, progress, and learning! Thank you again Michael, and again I hope that posting this is ok.

Chad

Chad, allow me to point out that the two formats are the same when it comes to what actually gets recorded on the tape. That's because the record circuitry in the cassette machine has limited bandwidth -- the response rolls off above and below the audio range. More specifically, it does not include DC. Thus, you may as well AC couple the digital-to-analog portion of your interface, because the DC component of the signal is gonna eventually be removed anyway, never to be recovered.

Also let me remind you that many cassette machines (including virtually all portable, monophonic units) include an Automatic Gain Control (AGC) in the record section. The AGC is fairly slow to respond, and the gain changes it's making will tend to interfere with what you're trying to accomplish. For this reason, it's routine for KIM-1 and other cassette schemes to begin each recorded segment with 1 or 2 seconds of "NOP" information -- a header that transfers no data but establishes a consistent audio level, giving the AGC a chance to stabilize.

The KIM-1 modulation scheme never ceases to output a signal; it merely switches between a high frequency signal and a somewhat lower frequency signal (as described here). This is FSK (Frequency Shift Keying), which is quite literally a form of FM (Frequency Modulation). But AIUI your proposed system switches between presence and absence of the audio signal, and this has implications in regard to the AGC's meddlesome interference. You'll want the 1 or 2 second header to have a 50% duty cycle of "signal present" in order to let the AGC stabilize.

Also, you may run into trouble with the duty cycle -- the ratio of ones to zeros -- in the "legitimate data" portion of a recorded segment, because unfortunately the AGC will be attempting to normalize this audio, too. (FSK sidesteps this concern, because the signal is always present.)

-- Jeff

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

Jeff, very very good points.

First off, I do not plan on using a literal cassette tape. Though it would be nice to see that it would work on one! I do not know about this AGC or the FSK, but I am somewhat understanding what you are talking about.

As for the FM signal, YES! I had read that post, and looked into the Commodore Datassette in particular. One particular frequency is 1, another is 0, right?

Attached is a picture of what I think that should look like. I think I used 2000 Hz and 1000 Hz, whatever works best of course. So the picture should read out 1, 0, 1, 1, 1, 0, 0, 1, 0. Or I guess 0, 1, 0, 0, 0, 1, 1, 0, 1. I could determine 1 and 0 from the length of pulse, basically.

Now, going backwards is the tricky part. I seem to have dug myself into an analog hole here! Can I once more show the Apple 1 cassette schematic?

https://www.applefritter.com/files/imag ... c-6889.gif

Notice the "To Tape" section. It's... a flip-flop, 10K resistor, and 100 ohm resistor to ground... And that's it. I must be missing something. Jeff, are you saying that my digital signals will 'automatically' be converted into analog signals when I record? I will have to test this actually. That will determine what's really going on here.

Thank you for the post! That is very helpful information. A brand new journey, and I didn't even know it!

Chad

I note that on your schematic you’re biasing the opamp at GND. Is this intentional?
I would probably bias it at half VCC. Maybe it’s just the phase of the output that’s affected by that.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I get a small, vicarious pleasure when I see these eureka moments. Actually, given AndersNielsen's experiments with digital LEDs and better understanding of the timeline of tape standards, I think that I've been out-classed by AndersNielsen. This is also a small pleasure - and it gives me incentive to improve.

For anyone interested in LEDs and square wave modulated serial, I recommend investigating the RC5 standard commonly used for television remote controls.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Don’t be so sure - just the strange coincidence I’ve been going nuts with Don Lancaster’s books and articles over the last few weeks. Not all gold, but mostly, and usually a good read.
I guess he’s still alive and just chillin in the Arizona desert? (Hope so)

https://en.m.wikipedia.org/wiki/RC-5
I think I would’ve given a toe or two to have and understand that wiki page along with a 6502 sbc + IR LED, when I was a teenager! Sweet sweet remote control power!

If I’m not wrong the RC switch Arduino library can also decode RC5 (and a bunch of 315/433mhz protocols)
Seems nuts but I’m thinking if I can port some of it to 6502.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Hey everyone! Updates:

Garth's circuit above is great! The only issue was that I had said, "I don't care what the output is without a signal." But what I meant to say was, "I don't care if the output is low or high, as long as it is constant, without a signal." Garth modified his circuit to pull the output high when not in use, see attached.

I then made a small C++ program to combine 2000 Hz and 1000 Hz sine waves as 1's and 0's. Output is nice square waves between 0V and 5V, perfect!

Then I programmed the 6502 to read PA6 on the VIA, "babysitting" mode, no interrupts. The operation is very simple: Wait until PA6 goes low. Then count down from some arbitrary value. If PA6 goes high before the count is zero, it's a short signal. If the timer runs out, it's a long signal, but then NOP until PA6 changes back. Very simple, even in my weird and non-optimized code it was only about 33 instructions.

I was having WEIRD readings for a long while though! Every short was coming in as a short, sometimes coming in as 2 shorts. But every long was coming in as a short, long, and then another short! HUH? It took me a couple hours until I figured it out. It's not my code, it was the signal! I zoomed way in on the scope and sure enough there are little spikes right before and after every long. What I then did was when I saw PA6 change I NOP'd 16 times and that fixed it immediately.

We have mass data input!!! Super excited to see this. I think I'm going to ditch my ideas to record from the 6502 though.

Off to the next project. Thank you everyone, and a HUGE thank you to Garth! Again, I couldn't do what I do without y'all.

Chad

This looks interesting! Slightly OT, as it's FSK, but...

minimodem - general-purpose software audio FSK modem for GNU/Linux systems

Minimodem is a command-line program which decodes (or generates) audio modem tones at any specified baud rate, using various framing protocols. It acts a general-purpose software FSK modem, and includes support for various standard FSK protocols such as Bell103, Bell202, RTTY, TTY/TDD, NOAA SAME, and Caller-ID.
Minimodem can play and capture audio modem tones in real-time via the system audio device, or in batched mode via audio files.

Minimodem can be used to transfer data between nearby computers using an audio cable (or just via sound waves), or between remote computers using radio, telephone, or another audio communications medium.

-- Jeff

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

I tried out minimodem and it worked as advertised though it wasn’t easy to control at the bit level.

In other news my Simple Universal Modem made the hackaday front page. https://hackaday.com/2022/07/27/simple- ... from-tape/

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1