RS232

From vice-emu
Revision as of 23:57, 26 July 2019 by Gpz (talk | contribs) (→‎windows)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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.

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
  • all of the above pre-configured for a) a standard userport modem at 2400 baud and b) a swithlink at something like 38400 baud

I need more info on this magical WinVICE 1.19 that someone patched and released, and then kept the sources for himself.

  • who made it, can we track down the source?
  • what were the exact changes? (some ACIA related fix?)

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

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.

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:

atdtantidote.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:

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

ip232 protocol

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

TODO: (optionally!) support this protocol

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
 nn = 1      DTR = true
 nn = 255    literal 0xff
other   ->   unchanged

notes

driver stack

rsuser.c    -> rs232drv.c -> rs232.c -> shared/rs232dev.c
aciacore.c                              rs232net.c

links

windows