RS232

here i will track some things regarding rs232 emulation, and perhaps fix things while at it. It may also serve as documentation on how all those RS232 things work. Gpz (talk) 19:29, 25 July 2019 (CEST)

• for all first tests i will use some version of CCGMS, and regular user-port rs232 emulation at 2400 baud.
• for ACIA tests i will use novaterm or striketerm.
• if not explicitly testing two instances of VICE, i will use cgterm as the "calling" end

WANTED

I need more / better testcases. Right now i am using CCGMS, but that will hardly do for more than a few basic checks. what i am looking for is:

• some (terminal?) program that shows the various modem control lines (dtr/dtd rts/cts CD etc) on screen in realtime
• a minimal c*base setup that lets me reproduce c*base related bugs
  • detailed description of the supposed problems with c*base
• other problematic programs/scenarios
• all of the above pre-configured for a) a standard userport modem at 2400 baud and b) a swithlink at something like 38400 baud

To make this page more complete, more examples of real-world usecases would be nice.

Tools

To reproduce what is explained below, a few C64 programs and some host utilities are needed.

C-64

• CCGMS (if you are familiar with another terminal program, that will do just as good)

Host

• socat (Windows binaries)
• tcpser (use the FozzTexx fork until the changes are merged back into jim brains repo)

using a real RS232 port

This works by using the device name of your OS, VICE uses physical RS232 ports.

linux

RsUserEnable = 1
RsUserBaud = 2400
RsUserDev = 1

RsDevice1 = /dev/ttyUSB0
RsDevice1Baud = 2400

status: working out of the box

windows

RsUserEnable = 1
RsUserBaud = 2400
RsUserDev = 1

RsDevice1 = com6
RsDevice1Baud = 2400

• the windows driver understands various options passed in the so called "mode string" after a colon after the ports name

COMx[:][baud=b][parity=p][data=d][stop=s][to={on|off}][xon={on|off}][odsr={on|off}][octs={on|off}][dtr={on|off|hs}][rts={on|off|hs|tg}][idsr={on|off}]

• finding out what COM port the usb adapter ended up might be tricky, you can use a tool like "Keyspan Serial Assistant"

status: working after some massaging of the code

rs232 over ip

This works by using the IP and port you are connecting to, VICE will use a TCP socket.

TODO: check if DNS lookup works ([https://sourceforge.net/p/vice-emu/feature-requests/186/ Domain name support in RS-232 settings})

connect two VICE instances on the same host

$ socat tcp-listen:25232 tcp-listen:25231

config instance #1

RsUserEnable = 1
RsUserBaud = 2400
RsUserDev = 2

RsDevice2 = 127.0.0.1:25232
RsDevice2Baud = 2400

config instance #2

RsUserEnable = 1
RsUserBaud = 2400
RsUserDev = 2

RsDevice2 = 127.0.0.1:25231
RsDevice2Baud = 2400

linux

status: works

windows

status: works

connect two VICE instances on different hosts

status: untested

piping to an external program

This is the unix way to talk to external programs.

Piping will be used when the first character of the device "file" name is a "|" (pipe) character.

Note: when the external program is netcat (or "nc") without further options, the result is equivalent to using "rs232 over ip" as described above.

linux

"calling" a telnet BBS

$ tcpser -v 25232 -p 6400 -s 2400 -l 4

RsUserEnable = 1
RsUserBaud = 2400
RsUserDev = 4

RsDevice4 = |nc 127.0.0.1 25232
RsDevice4Baud = 2400

in CCGMS:

atdt antidote.hopto.org:64128

status: works

windows

status: not implemented

TODO: a windows replacement for arch/shared/coproc.c:fork_coproc() must be implemented (this is non trivial unfortunately) and then hooked up in rs232-win32-dev.c in the same way it is on unix. once done define grep for COPROC_SUPPORT and adjust the respective places (preferably removing it)

some pointers:

• https://support.microsoft.com/en-au/help/190351/how-to-spawn-console-processes-with-redirected-standard-handles
• http://www.cs.rpi.edu/courses/fall01/os/CreateProcess.html
• https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
• https://docs.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-createpipe
• https://gist.github.com/code-disaster/44ae4e176feafb0f703810d261c1e1fe
• https://github.com/BeRo1985/pasvulkan/blob/d5fb20b6f358edc20015569d51535a0436862bc5/src/tools/projectmanager/UnitExternalProcess.pas#L27

notes:

• the code is somewhat prepared
• we should probably create another thread which monitors the launched external process, closes the pipes when the child dies, and perhaps other things

TODO

• whether the "UP9600" (daniel dallmann) hack is being used seems to depend on the baudrate(?). this should be a seperate option

driver issues

• handling of DTR and RTS seems to be completely missing. rs232dev_set_status, rs232dev_get_status, rs232dev_set_bps apparently are not called by the layer above

user interface

• a couple of typical rs232 settings should probably be configurable for at least "real rs232 port at host". (behavior of DTR, RTS...)

WinVICE 1.19

a supposedly "fixed" version of WinVICE 1.19 has been floating around, which apparently contains two changes:

• ACIA fix (whatever it is about)
• support for the ip232 protocol

this is here

ip232 protocol

This is the protocol introduced by some modified WinVICE 1.19 to talk to tcpser.

tcpser->vice ip232.c:ip232_write

0xff nn ->
 nn = 0      DCD = false     
 nn = 1      DCD = true
 nn = 255    literal 0xff
other   ->   unchanged

vice->tcpser ip232.c:ip232_read

0xff nn ->
 nn = 0      DTR = false      note: the original patch sends 0 on rs232 reset
 nn = 1      DTR = true       note: the original patch sends 1 on rs232 connection established
 nn = 255    literal 0xff
other   ->   unchanged

TODO: (optionally!) support this protocol

NOTE: this is partially implemented now

• userport handles DCD

tcpser

tcpser seems to be buggy too:

• when sending 0xff, x the respective codes appear in the output. this should not happen, they should directly translate into DTR status. when using an IP connection DTR=0 should disconnect.
• somehow using the common "+++ATH" doesnt disconnect the "modem" when using ip232

notes

driver stack

rsuser.c                   -> rs232drv.c              -> rs232.c              -> shared/rs232dev.c
rsuser_read_ctrl (WIP)        rs232drv_set_status (ok)   rs232_set_status (ok)   rs232dev_set_status (TODO)
rsuser_write_ctrl (WIP)       rs232drv_get_status (ok)   rs232_get_status (ok)   rs232dev_get_status (TODO)
.
aciacore.c                                                                       rs232net.c
acia_get_status (ok)                                                             rs232net_set_status (WIP)
acia_set_handshake_lines (ok)                                                    rs232net_get_status (WIP)

links

• https://vic20reloaded.com/vic20-c64-network-gaming-winvice/ - Connecting two emulators on the same machine
• https://csdb.dk/release/?id=149602 - CCGMS download

tcpser

• http://www.jbrain.com/pub/linux/serial/ - original tcpser source
  • https://github.com/go4retro/tcpser - current repo
  • tcpser readme has some info on DTR issues
• https://github.com/geneb/tcpser - genebs fork of Jim Brain's tcpser serial port to TCP/IP bridge.
• https://github.com/FozzTexx/tcpser - FozzTexx fork of Jim Brain's tcpser serial port to TCP/IP bridge (including genebs changes)
• http://gcns.com/vice/vice.html - patched WinVICE 1.19
  • https://csdb.dk/release/?id=181437 - patched WinVICE 1.19 on csdb

windows

• http://com0com.sourceforge.net/ - virtual COM ports
• https://www.xanthium.in/Serial-Port-Programming-using-Win32-API
• https://github.com/xanthium-enterprises/Serial-Programming-Win32API-C