These two patches add support for a (TCM3105 based) tape-port modem device as used by DIGICOM>64 (packet radio terminal program). The peripheral has 2 main modes of operation:
- Soundmodem emulating a TCM3105 IC (as used in the common Digicom or BayCom modems of the era): Generates a Bell-202 compatible AFSK signal in software and plays it out via a selectable sound-device. The receiver uses the same (or another) audio device to sample & demodulate an incoming audio signal and feeds the reconstructed digital level to the tape-port (like the real modem would do). PTT may be controlled via the handshake line (RTS or DTR) of a selectable serial device.
- AXUDP/AXIP network adaptor: The serial bitstream from the tape-port is assembled and converted back into AX.25 frames. These are then put into AXUDP (or AXIP) network packets and sent to a configured host. On the receiving side the AX.25 frame is carved out of the AXUDP (or AXIP) packet, converted into the required HDLC bitstream and fed to the tape-port. A configurable callsign filter limits which received frames are passed on to the machine (useful on busy channels).
- All functionality has been verified using DIGICOM>64: Connection and data transfer using 2 Instances back-to-back (soundmodem & network) as well as standalone unit tests.
- The soundmodem has also been successfully tested against "Dire Wolf" (a capable soundmodem - https://github.com/wb2osz/direwolf).
- Soundmodem emulation requires PortAudio (--with-portaudio)
- PTT via serial device is implemented for Unix and Windows.
- AXUDP works on all platforms, AXIP is POSIX only and requires elevated privileges (documented as such).
- Snapshot support follows cp-clockf83. Live audio/serial state re-arms on restore via the resource setter.
The patches have been developed and tested on macOS 15.7.4. The Windows code paths (PTT, COM-enumeration, winsock AXUDP) are cross-compile-verified with mingw-w64 but not runtime-tested. Patchfiles are "git format-patch" output against the VICE-Team/svn-mirror main branch as of 2026-07-05 (e163e0e); paths are prefixed "vice/".
The 1st patch provides UDP datagram support for the 'vice_network*' abstraction and is required for the AXUDP network part of the 2nd.
The 2nd patch implements the "CASCOM" device itself (I did not want to use "BayCom" as the Devs of these modems grew a company out of it): 8 new files under src/tapeport, registration, setting page, SDL menu and 'vice.texi' documentation.
Disclaimer: This peripheral has been built with significant help of AI (Claude Opus & Fable).
Skimmed over it... looks OK regarding codestyle at least (i cant judge the functionality at all).
I have some questions/requests though:
And as a sidenote, it would be cool if you could link to the software, and give brief instructions on how to use this (in VICE). I briefly played with packet radio decades ago but cant say i remember anything :-)
(btw, better don't use the git mirror for this, it usually works, but if something goes weird it may be not in sync with svn head, so using that is the better option)
Thanks for the quick response. Regarding your questions and requests:
Direct use of portaudio: From what I’m aware of, the existing sound system is playback-only and mixes machine audio into the stream. The audio processing part of the modem emulates what some hardware (e.g. a TCM3105 IC) would usually do and that’s outside the machine itself. The audio stream from the modem emulation therefore must take a distinct path from the machine audio (we don't want SID output mixed with the modem signal). Also modem audio requires a relation to wall-clock instead of emulated clock since it is consumed outside the emulated time domain (this also makes the modem only work with 100% emulation speed). Both clock domains get to exchange samples using a ringbuffer of a few tens of milliseconds length to cope with the jitter that comes from the way processing is done in the emulated clock domain.
Furthermore a kind of duplex operation is required (simultaneous input & output, including on two different devices). I do not see a way to capture audio in sound_device_t .
samplerdrv on the other hand (which uses portaudio itself) only has an 8-bit pull API, is single-consumer and the portaudio backend always opens the default input device. This seems to be catering more to actual audio sampling being done on the emulated machine, but that's not what the soundmodem requires to function properly.
The cascom modem emulation actually does things along the lines of how samplerdrv accesses audio hardware. I agree, it could be done differently to be more portable, but that would require further modification of some parts of the audio subsystem, e.g. extending the sound-driver API to gain capture support or putting a shared host-audio-stream helper into arch/shared for samplerdrv and cascom. That could be a valid future enhancement, but I would rather keep it out of the scope of this patch for now.
Without --with-portaudio the device still builds, but of course audio mode is then unavailable, network mode (and loopback) works.
I agree, one part (arch-dependent serial port handling) would need to move into arch/shared with a new archdep API (archdep_serial_control_) to be used for PTT keying over the serial control lines. Raw socket handling for AXIP would probably better live in the vice_network_* layer next to the UDP functions of patch 1, so I can remove the platform conditionals from cascom.c . If there are no objections to this I would rework the code regarding the issue and provide updated patches. The remaining conditionals in cascom.c are then only the USE_PORTAUDIO / HAVE_NETWORK feature guards (same as samplerdrv).
Sorry for not providing more info on the network protocol stuff. These are actual standards. What I referred to as AXIP is actually protocol 93 (AX.25) as defined in the IANA spec relating to the IP Protocol (v4) or IP Next Header (6) field. The encapsulation of AX.25 frames in IP is described in RFC1226. AXUDP encapsulates AX.25 frames into UDP packets instead to ease processing and routing. In Linux there’s ax25ipd who does this job.
Regarding the software: I actually build that from source since I was fiddeling around with it (to get REU support in for fun & profit ;) ) but there's a copy on the web however (including documentation as well): https://www.zimmers.net/anonftp/pub/cbm/c64/packetradio/ (there most likely are more copies floating around as well).
The content of the ZIP belongs on a disk (image). It provides the english language version of the program(s) DC64E and DC64SCCE. The one you want to start is „DC64E“. (DC64SCCE requires a board on the expansion port with a SCC IC… probably worth a future extension since this can do up to 19k2 with 2 modems). Once the program is up, you need a leading colon (:) to enter commands (upper left key on original C64 keyboard toggles this). Set a callsign (e.g. :mycall test) and either just type something without colon and hit enter (this will then be sent directly to the channel) or try to establish a connection to another station (e.g. :connect ex4mpl). This will then start the handshake and a couple of frames will be emitted before the attempt fails (if you did not manage to have another station to connect to).