BAUDOT AUDIO DECODE help

[WeeMan]

Hi All,
I am new to 6502 and at present I am currently in the middle of writing a program to decode BAUDOT RTTY via an audio input stream and display to screen on a C64. I have the bare bones of the conversion that i require to convert the incoming Baudot characters to ASCII but was wondering where I may find the bytes that are input. Does the C64 ADC have a specific address? Any help in filling in my missing blanks would be much appreciated.
Regards
Stephen.

[BigEd]

Welcome, Stephen! I'm afraid I'm not very familiar with details of the C64, but with luck someone will be along before too long.

(If you're planning to use the SID chip's paddle input, that might prove to be an interesting challenge, because it's not an analogue input in the usual sense - it's an input which measures an RC time constant, as far as I can tell. https://www.c64-wiki.com/wiki/Paddle)

[WeeMan]

Hi BigEd,
many thanks for the prompt reply. I only mentioned the C64 because at the moment I only have access to an IDE that executes the code on a windows PC 6502emulator.
Years ago I wrote 8bit code for PC but I am new to 6502 and its associated chip set and need nudging in the right direction. I must add though, I have never written communications receive programs before so it may be a steep learning curve.
Merry Christmas and All the best for 2022.
Stephen.

[GARTHWILSON]

Quote:

I only mentioned the C64 because at the moment I only [...]

Can you tell us more about the goal and how you envision reaching it. I fixed a friend's Apple II joystick input decades ago which I was surprised did not have an A/D converter, but rather did what it sounds like Ed is talking about, that the variable resistors in the joystick only changed the amount of time it took to charge up capacitors to cross a voltage threshold. After the threshold was crossed and the time noted, the capacitor would be discharged and then the cycle would repeat. I don't remember how fast it was; but it definitely was not nearly fast enough to be sampling audio. (I don't know if that's what you were thinking of doing.)

[BigEd]

This might be useful:
https://www.sigidwiki.com/wiki/Radio_Teletype_(RTTY)

For general purpose audio demodulation, it's an ADC you'd want, and you'd need to hook that up as a peripheral. But for demodulating specific signals, it's conventional to have some analogue signal conditioning which makes it easier on the 6502. At one extreme, you have circuits which detect the specific tones. At another extreme, you square off the signal and the 6502 needs only detect the changes from 0 to 1, which correspond to zero-crossings.

There's a thread here which might of interest, concerning Acorn's BBC Micro:
https://stardot.org.uk/forums/viewtopic.php?f=3&t=22935

There's every chance you can find details of the C64's cassette interface somwhere, and that might be instructive, and might even be directly usable.

[hoglet]

There's another Stardot thread that might be of interest as well:
Hoglet's Past Projects #2 - the RTTY receiver

In this project the demodulation of the RTTY signal is done in hardware, leaving the computer just to decode the serial bitstream.

Dave

[WeeMan]

Hi Guys,
first of all, many thanks for your replies, they are all of interest. My idea is to receive an audio RadioTeleTypeY RTTY signal into the host machine, demodulate the received BAUDOT code, convert the received character to ASCII and display the DECODED characters onto the screen. It would probably be easier if I had an actual 6502 machine like a BBC Master/Acorn or Oric to code with but at present using an IDE and emulator created for game development. I see that I have to create a translation table to change the received characters from BAUDOT to ASCII and then use sys calls for screen display etc but its the actual input and conversion to bytes that I am sketchy about.
I will continue my research.
Stephen.

[BigDumbDinosaur]

WeeMan wrote:

It would probably be easier if I had an actual 6502 machine like a BBC Master/Acorn or Oric to code with but at present using an IDE and emulator created for game development.

The IDE and simulator (not emulator, which would be hardware) likely would have no analog-to-digital conversion, which as the others noted, is a necessary step in decoding and displaying the incoming data stream. So at some point you are going to have to acquire a real 6502-powered computer if you wish to progress.

I recall that in the 1980s there was quite a bit of interest in getting a C-64 to do this. The details escape me, but it involved an ADC attached to the user port (aka RS-232 port), which produced a serial bit stream representing the ASCII characters. Given the relative ubiquity of ADCs these days, I'd think such a gadget would be fairly easy to build. Of course, you'd need to acquire a C-64, which won't be quite as easy. That said, in this type of application, there are machines better suited to the purpose, e.g., the BBC machines you mentioned.

[WeeMan]

BigDumbDinosaur wrote:

WeeMan wrote:

It would probably be easier if I had an actual 6502 machine like a BBC Master/Acorn or Oric to code with but at present using an IDE and emulator created for game development.

The IDE and simulator (not emulator, which would be hardware) likely would have no analog-to-digital conversion, which as the others noted, is a necessary step in decoding and displaying the incoming data stream. So at some point you are going to have to acquire a real 6502-powered computer if you wish to progress.

I recall that in the 1980s there was quite a bit of interest in getting a C-64 to do this. The details escape me, but it involved an ADC attached to the user port (aka RS-232 port), which produced a serial bit stream representing the ASCII characters. Given the relative ubiquity of ADCs these days, I'd think such a gadget would be fairly easy to build. Of course, you'd need to acquire a C-64, which won't be quite as easy. That said, in this type of application, there are machines better suited to the purpose, e.g., the BBC machines you mentioned.

Many thanks for your input "BigDumbDinosaur" much appreciated. I'm currently using Arthur Jordisons "CBM Prg Studio V3.14" so restricted when it comes to inputting audio signals. Have a great Christmas & New Year!

[BigDumbDinosaur]

WeeMan wrote:

Many thanks for your input "BigDumbDinosaur" much appreciated. I'm currently using Arthur Jordisons "CBM Prg Studio V3.14" so restricted when it comes to inputting audio signals. Have a great Christmas & New Year!

I'm not familiar with that simulator. I have fooled around with VICE, which is another popular Commodore simulator, but it too has the limitations that any simulator would have with interfacing to hardware designed to be used with an actual Commodore machine.

[BigEd]

I wish you wouldn't be so hostile with your pedantry, BDD. I'm sure it's better to welcome people.

[WeeMan]

BigDumbDinosaur wrote:

WeeMan wrote:

Many thanks for your input "BigDumbDinosaur" much appreciated. I'm currently using Arthur Jordisons "CBM Prg Studio V3.14" so restricted when it comes to inputting audio signals. Have a great Christmas & New Year!

I'm not familiar with that simulator. I have fooled around with VICE, which is another popular Commodore simulator, but it too has the limitations that any simulator would have with interfacing to hardware designed to be used with an actual Commodore machine.

The system run environment uses VICE, so somewhat limited.

[BigDumbDinosaur]

WeeMan wrote:

The system run environment uses VICE, so somewhat limited.

VICE's simulation is pretty good. Some years back, I wrote a display manager for the 80 column side of the C-128, which used some VDC trickery to manage multiple screens. I needed some way to test it and decided to try it out in VICE. VICE's simulation of the VDC was sufficiently accurate that when I was finally able to test the software on a C-128DCR no code had to be modified to work properly.

[BigEd]

Ah, yes, VICE, the Versatile Commodore Emulator (https://vice-emu.sourceforge.io) - not related to MAME, the multi-purpose emulation framework, or MESS, the Multi Emulator Super System.

It is quite normal, and in fact the majority usage, to speak of emulators and emulation when engaged in retrocomputing. (There's a minority usage too, just as valid, to speak of simulation in this case. It would be a mistake to hold that only one usage is correct, but a fairly common mistake. There's a thread on this, to try to help: Terminology: Simulator vs. Emulator)

[BigDumbDinosaur]

BigEd wrote:

Ah, yes, VICE, the Versatile Commodore Emulator (https://vice-emu.sourceforge.io) - not related to MAME, the multi-purpose emulation framework, or MESS, the Multi Emulator Super System.

Thanks for pointing out that whomever named those pieces of simulation software evidently failed to understand the distinction between emulation and simulation. Despite your insistence, the two words are not synonyms.

Quote:

It is quite normal, and in fact the majority usage, to speak of emulators and emulation when engaged in retrocomputing.

It's also quite “normal” for some speakers of English to confuse “your” with “you're” and mix up the usage of “him” and “he.” Others don't know the difference between “who” and “whom,” or that prepositions should not be used to terminate sentences. However “normal” you insist such spurious usage may be, it is still wrong, which is also the case with referring to software as an “emulator.” Emulation is done in hardware, simulation is done in software. You can refer to “red” as “green” until you're blue in the face, but it won't change reality.