RS232: Difference between revisions

From vice-emu
Jump to navigation Jump to search
 
(132 intermediate revisions by 2 users not shown)
Line 1: Line 1:


here i will track some things regarding rs232 emulation, and perhaps fix things while at it [[User:Gpz|Gpz]] ([[User talk:Gpz|talk]]) 19:29, 25 July 2019 (CEST)
__TOC__
 
The following tries to explain how the RS232 emulation works - most of this should get moved into the Manual later
 
== Tools ==
 
To reproduce what is explained below, a few C64 programs and some host utilities are needed.
 
=== C-64 ===
 
* CCGMS (for testing Userport RS232, if you are familiar with another terminal program, that will do just as good)
* Striketerm or Novaterm 9.6 (for testing Swiftlink/Turbo232)
 
* the following is a "mini terminal" that can be used to test a RS232 connection at 1200 baud 8N1 with RTS/CTS handshaking
 
10 open2,2,0,chr$(8)+chr$(1)
20 get#2,i$:if i$<>"" then printi$;
30 get a$:if a$<>"" then printa$;:print#2,a$;
40 goto20
 
=== Host ===
 
* socat ([https://sourceforge.net/projects/unix-utils/files/socat/1.7.3.2/ Windows] binaries)
* http://com0com.sourceforge.net/ - virtual com ports for windows
* tcpser ([https://github.com/go4retro/tcpser github])
* recent VICE binaries. You can find Windows builds [https://github.com/VICE-Team/svn-mirror/releases here]. Sometimes we will upload experimental Windows binaries [https://sourceforge.net/projects/vice-emu/files/experimental%20binaries/ here].
* [https://csdb.dk/release/?id=118137 cgterm]


== using a real RS232 port ==
== using a real RS232 port ==


This works by using the device name of your OS, VICE uses physical RS232 ports.
If the RsDeviceX string matches a path to a serial device in the OS, VICE uses physical - or virtual - RS232 ports.


=== linux ===
=== linux ===


  /dev/ttyUSB0
  UserportDevice = 2
RsUserBaud = 2400
RsUserDev = 1


'''status''': '''working''' out of the box
RsDevice1 = /dev/ttyUSB0
RsDevice1Baud = 2400
 
Note: RsDeviceXBaud setting only applies for real rs232 ports. When using IP connections that setting doesnt matter


=== windows ===
=== windows ===
UserportDevice = 2
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
* the windows driver understands various options passed in the so called "mode string" after a colon after the ports name
Line 19: Line 57:


* finding out what COM port the usb adapter ended up might be tricky, you can use a tool like "Keyspan Serial Assistant"
* finding out what COM port the usb adapter ended up might be tricky, you can use a tool like "Keyspan Serial Assistant"
* if you want to connect two instances of VICE with a virtual null modem cable, try http://com0com.sourceforge.net/ instead of socat as described below
== rs232 over ip ==
The RS232 port will be connected to a TCP Socket. Note that VICE is always a client that wants to connect to a server - so for connecting two instances of VICE there is always a helper program needed! Generally this feature is ment to be used with a local helper program (which eg acts as a modem simulator) and not to connect with a remote server on the internet.
=== connecting to local modem simulator ===
A popular modem simulator is tcpser, run it like this in a seperate shell (tcpser will listen on port 6400 and expect VICE to connect on port 25232):
$ tcpser -v 25232 -p 6400 -S 2400 -l 4 -i"s5=20"


'''status''': '''working''' after some massaging of the code
And then connect to it with VICE:


== rs232 over ip ==
UserportDevice = 2
RsUserBaud = 2400
RsUserDev = 1
 
RsDevice2 = 127.0.0.1:25232
RsDevice2IP232 = 1


This works by using the IP and port you are connecting to, VICE will use a TCP socket.
$ x64sc -default -rsdev2 "127.0.0.1:25232" -rsuserbaud "2400" -rsdev2ip232 -rsuserdev "1" -userportdevice "2"


=== connect two VICE instances on the same host ===
=== connect two VICE instances on the same host ===


  socat tcp-listen:25232 tcp-listen:25231
  $ socat tcp-listen:25232,reuseaddr,fork tcp-listen:25231,reuseaddr,fork


config instance #1
config instance #1


  127.0.0.1:25232
  UserportDevice = 2
RsUserBaud = 1200
RsUserDev = 1
 
RsDevice2 = 127.0.0.1:25232
 
$ x64sc -default -rsdev2 "127.0.0.1:25232" -rsuserbaud "1200" -rsuserdev "1" -userportdevice "2"


config instance #2
config instance #2


  127.0.0.1:25231
  UserportDevice = 2
RsUserBaud = 1200
RsUserDev = 1
 
RsDevice2 = 127.0.0.1:25231


==== linux ====
$ x64sc -default -rsdev2 "127.0.0.1:25231" -rsuserbaud "1200" -rsuserdev "1" -userportdevice "2"


'''status''': '''works'''
This should be run in order:
socat -> vice instance #1 -> vice instance #2
Do not use the GUI autostart/autoload feature to load the terminal software, instead attach the tape or disk image and manually load it.


==== windows ====
Resseting the emulated machine will cause the connection to become invalid. In this case, exit both vice instances and stop socat, and start from the beginning.


'''status''': '''works'''
If you open the VICE instances in the wrong order socat will report something like this:
2022/10/30 16:05:32 socat[16803] E bind(5, {AF=2 0.0.0.0:25231}, 16): Address already in use


=== connect two VICE instances on different hosts ===
=== connect two VICE instances on different hosts ===
As said above, VICE always acts as a client and tries to connect to a "server". If one instance is running tcpser, which can act as a server and accept incoming connections, then the other instance of VICE can in principle connect to it directly. It is however recommended to also use a modem simulator on the client side.


== piping to an external program ==
== 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 ===
=== linux ===


'''status''': '''untested'''
==== "calling" a telnet BBS ====
 
$ tcpser -v 25232 -p 6400 -S 2400 -l 4 -i"s5=20"
 
UserportDevice = 2
RsUserBaud = 2400
RsUserDev = 3
 
RsDevice4 = |nc 127.0.0.1 25232
RsDevice4IP232 = 1
 
in CCGMS:
 
atdt antidote.hopto.org:64128
 
'''status''': '''works'''


=== windows ===
=== windows ===
Line 58: Line 146:
'''status''': '''untested'''
'''status''': '''untested'''


== TODO ==


* whether the "UP9600" (daniel dallmann) hack is being used seems to depend on the baudrate(?). this should be a seperate option
 
----
 
Everything below is just left as a reminder and might get (re)moved sooner or later
 
== ip232 protocol support ==
 
This is the protocol introduced by some [http://gcns.com/vice/vice.html modified WinVICE 1.19] to talk to tcpser.
 
<pre>
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
 
</pre>
 
== Signals and Pinout ==
 
{| class="wikitable sortable" style="margin:auto; text-align:center;"
! colspan="3" | Circuit !! colspan="2" | Direction !! rowspan="2" | DB-25 pin !! rowspan="2" | DB-9 pin !! rowspan="2" | Userport !! rowspan="2" | CIA
|-
! Name !! width="400px" | Typical purpose !! Abbreviation !! DTE (Computer) !! DCE (Modem)
|-
| align="left" | Data Terminal Ready || align="left" | DTE is ready to receive, initiate, or continue a call. || DTR || out || in || 20 || 4 || E || PB2
|-
| align="left" | Data Carrier Detect || align="left" | DCE is receiving a carrier from a remote DCE. || DCD || in || out || 8 || 1 || H || PB4
|-
| align="left" | Data Set Ready      || align="left" | DCE is ready to receive and send data. || DSR || in || out || 6 || 6 || L || PB7
|-
| align="left" | Ring Indicator      || align="left" | DCE has detected an incoming ring signal on the telephone line. || RI  || in  || out || 22 || 9 || F || PB3
|-
| align="left" | Request To Send    || align="left" | DTE requests the DCE prepare to transmit data. || RTS || out || in || 4 || 7 || D || PB1
|-
| align="left" | Ready To Receive    || align="left" | DTE is ready to receive data from DCE. If in use, RTS is assumed to be always asserted. || RTR || out || in || 4 || n/a || n/a || -
|-
| align="left" | Clear To Send      || align="left" | DCE is ready to accept data from the DTE.  || CTS || in || out || 5 || 8 || K || PB6
|-
| align="left" | Transmitted Data    || align="left" | Carries data from DTE to DCE. || TxD || out || in || 2 || 3 || M || PA2
|-
| align="left" | Received Data      || align="left" | Carries data from DCE to DTE. || RxD || in || out || 3 || 2 || C<br>B || PB0<br>!FLAG2
|-
| align="left" | Common Ground      || align="left" | Zero voltage reference for all of the above. || GND || colspan="2" | <small>common</small>|| 7 || 5 || N || -
|-
| align="left" | Protective Ground  || align="left" | Connected to chassis ground. || PG || colspan="2" | <small>common</small>|| 1 || shield || n/a || -
|}
 
=== nullmodem cable ===
 
{| class="wikitable sortable" style="margin:auto; text-align:center;"
! colspan="4" | DTE (Computer) !! colspan="1" | !! colspan="2" | DCE (Modem)
|-
! CIA || Userport || DB9 pin || Signal || Direction || Signal || DB9 pin
|-
| PB0<br>!FLAG2 || C<br>B || 2 || RxD || <-- || Txd || 3
|-
| PB6 || K || 8 || CTS || <-- || RTS || 7
|-
| PB4 || H || 1 || DCD || <-- || DTR || 4
|-
| PB3 || F || 9 || RI  || <-- || RI || 9
|-
| PA2 || M || 3 || TxD || --> || RxD || 2
|-
| PB1 || D || 7 || RTS || --> || CTS || 8
|-
| PB2 || E || 4 || DTR || --> || DCD<br>DSR || 1<br>6
|-
| PB7 || L || 6 || DSR
|-
| - || A || 5 || GND || --- || GND || 5
|}
 
== 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)


=== driver issues ===
=== 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
* 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
: this is partially solved for IP connections
=== commits ===
relevant commits (some that only change comments or defaults are omitted):
* [https://sourceforge.net/p/vice-emu/code/36762/ r36762] move rs232dev to shared
* [https://sourceforge.net/p/vice-emu/code/36842/ r36842] prepare ip232 protocol support, currently disabled
* [https://sourceforge.net/p/vice-emu/code/36811/ r35811] baudrate resources are no more archdep
* [https://sourceforge.net/p/vice-emu/code/36810/ r36810] cleanup, comments, use defaults for serial port that should always work, bring back the baudrate resources
* [https://sourceforge.net/p/vice-emu/code/36859/ r36859] added resources and commandline options to enable/disable IP232 protocol per rs232device
* [https://sourceforge.net/p/vice-emu/code/36987/ r36987] move rs232 related header files into the rs232drv directory
* [https://sourceforge.net/p/vice-emu/code/36988/ r36988] first step to properly emulate dtr/dcd, dcd proved working with userport rs232 (tested with c*base). dtr still needs to be checked. acia not yet working. some temporary logging left enabled.
* [https://sourceforge.net/p/vice-emu/code/36989/ r36989] according to the datasheet DCD is bit5 and DSR is bit6, not the other way around
=== commandlines ===
run tcpser to work with a bbs in vice: note that the baudrate is important, else the bbs sees "connect 38400" which will confuse it
tcpser -l 7 -tsSiImM -v 25232 -S 2400 -L log.txt -i"s5=20"
run c*base with 2400 baud userport:
x64sc -default -warp -drive8type 1581 -rsuser -rsuserdev 2 -rsuserbaud 2400 -rsdev3ip232 TestBBS.d81
run c*base with 38400 baud swiftlink:
x64sc -default -warp -drive8type 1581 -acia1 -acia1mode 1 -myaciadev 0 -rsdev1 127.0.0.1:25232 -rsdev1ip232 -rsdev1baud 38400 TestBBS.d81


=== user interface ===
== tickets ==


* a couple of typical rs232 settings should probably be configurable for at least "real rs232 port at host". (behavior of DTR, RTS...)
* https://sourceforge.net/p/vice-emu/feature-requests/70/
* <s> https://sourceforge.net/p/vice-emu/feature-requests/186/ </s>
* https://sourceforge.net/p/vice-emu/feature-requests/185/
* <s> https://sourceforge.net/p/vice-emu/bugs/262/ </s>
* <s> https://sourceforge.net/p/vice-emu/bugs/305/ </s>


== links ==
== links ==


* https://vic20reloaded.com/vic20-c64-network-gaming-winvice/ - Connecting two emulators on the same machine
* https://vic20reloaded.com/vic20-c64-network-gaming-winvice/ - Connecting two emulators on the same machine
* https://csdb.dk/release/?id=149602 - CCGMS download
* https://www.lyonlabs.org/commodore/GeckOS/index.html#slip and https://github.com/fachat/GeckOS-V2/blob/master/sysapps/slipd/csaip - using socat and slattach to connect to GeckOS inside VICE using SLIP
=== 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
[[Category:User]]

Latest revision as of 16:10, 18 June 2023

The following tries to explain how the RS232 emulation works - most of this should get moved into the Manual later

Tools

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

C-64

  • CCGMS (for testing Userport RS232, if you are familiar with another terminal program, that will do just as good)
  • Striketerm or Novaterm 9.6 (for testing Swiftlink/Turbo232)
  • the following is a "mini terminal" that can be used to test a RS232 connection at 1200 baud 8N1 with RTS/CTS handshaking
10 open2,2,0,chr$(8)+chr$(1)
20 get#2,i$:if i$<>"" then printi$;
30 get a$:if a$<>"" then printa$;:print#2,a$;
40 goto20

Host

using a real RS232 port

If the RsDeviceX string matches a path to a serial device in the OS, VICE uses physical - or virtual - RS232 ports.

linux

UserportDevice = 2
RsUserBaud = 2400
RsUserDev = 1
RsDevice1 = /dev/ttyUSB0
RsDevice1Baud = 2400

Note: RsDeviceXBaud setting only applies for real rs232 ports. When using IP connections that setting doesnt matter

windows

UserportDevice = 2
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"
  • if you want to connect two instances of VICE with a virtual null modem cable, try http://com0com.sourceforge.net/ instead of socat as described below

rs232 over ip

The RS232 port will be connected to a TCP Socket. Note that VICE is always a client that wants to connect to a server - so for connecting two instances of VICE there is always a helper program needed! Generally this feature is ment to be used with a local helper program (which eg acts as a modem simulator) and not to connect with a remote server on the internet.

connecting to local modem simulator

A popular modem simulator is tcpser, run it like this in a seperate shell (tcpser will listen on port 6400 and expect VICE to connect on port 25232):

$ tcpser -v 25232 -p 6400 -S 2400 -l 4 -i"s5=20"

And then connect to it with VICE:

UserportDevice = 2
RsUserBaud = 2400
RsUserDev = 1
RsDevice2 = 127.0.0.1:25232
RsDevice2IP232 = 1
$ x64sc -default -rsdev2 "127.0.0.1:25232" -rsuserbaud "2400" -rsdev2ip232 -rsuserdev "1" -userportdevice "2"

connect two VICE instances on the same host

$ socat tcp-listen:25232,reuseaddr,fork tcp-listen:25231,reuseaddr,fork

config instance #1

UserportDevice = 2
RsUserBaud = 1200
RsUserDev = 1
RsDevice2 = 127.0.0.1:25232
$ x64sc -default -rsdev2 "127.0.0.1:25232" -rsuserbaud "1200" -rsuserdev "1" -userportdevice "2"

config instance #2

UserportDevice = 2
RsUserBaud = 1200
RsUserDev = 1
RsDevice2 = 127.0.0.1:25231
$ x64sc -default -rsdev2 "127.0.0.1:25231" -rsuserbaud "1200" -rsuserdev "1" -userportdevice "2"

This should be run in order:

socat -> vice instance #1 -> vice instance #2

Do not use the GUI autostart/autoload feature to load the terminal software, instead attach the tape or disk image and manually load it.

Resseting the emulated machine will cause the connection to become invalid. In this case, exit both vice instances and stop socat, and start from the beginning.

If you open the VICE instances in the wrong order socat will report something like this:

2022/10/30 16:05:32 socat[16803] E bind(5, {AF=2 0.0.0.0:25231}, 16): Address already in use

connect two VICE instances on different hosts

As said above, VICE always acts as a client and tries to connect to a "server". If one instance is running tcpser, which can act as a server and accept incoming connections, then the other instance of VICE can in principle connect to it directly. It is however recommended to also use a modem simulator on the client side.

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 -i"s5=20"
UserportDevice = 2
RsUserBaud = 2400
RsUserDev = 3
RsDevice4 = |nc 127.0.0.1 25232
RsDevice4IP232 = 1

in CCGMS:

atdt antidote.hopto.org:64128

status: works

windows

status: untested



Everything below is just left as a reminder and might get (re)moved sooner or later

ip232 protocol support

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

Signals and Pinout

Circuit Direction DB-25 pin DB-9 pin Userport CIA
Name Typical purpose Abbreviation DTE (Computer) DCE (Modem)
Data Terminal Ready DTE is ready to receive, initiate, or continue a call. DTR out in 20 4 E PB2
Data Carrier Detect DCE is receiving a carrier from a remote DCE. DCD in out 8 1 H PB4
Data Set Ready DCE is ready to receive and send data. DSR in out 6 6 L PB7
Ring Indicator DCE has detected an incoming ring signal on the telephone line. RI in out 22 9 F PB3
Request To Send DTE requests the DCE prepare to transmit data. RTS out in 4 7 D PB1
Ready To Receive DTE is ready to receive data from DCE. If in use, RTS is assumed to be always asserted. RTR out in 4 n/a n/a -
Clear To Send DCE is ready to accept data from the DTE. CTS in out 5 8 K PB6
Transmitted Data Carries data from DTE to DCE. TxD out in 2 3 M PA2
Received Data Carries data from DCE to DTE. RxD in out 3 2 C
B
PB0
!FLAG2
Common Ground Zero voltage reference for all of the above. GND common 7 5 N -
Protective Ground Connected to chassis ground. PG common 1 shield n/a -

nullmodem cable

DTE (Computer) DCE (Modem)
CIA Userport DB9 pin Signal Direction Signal DB9 pin
PB0
!FLAG2
C
B
2 RxD <-- Txd 3
PB6 K 8 CTS <-- RTS 7
PB4 H 1 DCD <-- DTR 4
PB3 F 9 RI <-- RI 9
PA2 M 3 TxD --> RxD 2
PB1 D 7 RTS --> CTS 8
PB2 E 4 DTR --> DCD
DSR
1
6
PB7 L 6 DSR
- A 5 GND --- GND 5

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)

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
this is partially solved for IP connections

commits

relevant commits (some that only change comments or defaults are omitted):

  • r36762 move rs232dev to shared
  • r36842 prepare ip232 protocol support, currently disabled
  • r35811 baudrate resources are no more archdep
  • r36810 cleanup, comments, use defaults for serial port that should always work, bring back the baudrate resources
  • r36859 added resources and commandline options to enable/disable IP232 protocol per rs232device
  • r36987 move rs232 related header files into the rs232drv directory
  • r36988 first step to properly emulate dtr/dcd, dcd proved working with userport rs232 (tested with c*base). dtr still needs to be checked. acia not yet working. some temporary logging left enabled.
  • r36989 according to the datasheet DCD is bit5 and DSR is bit6, not the other way around

commandlines

run tcpser to work with a bbs in vice: note that the baudrate is important, else the bbs sees "connect 38400" which will confuse it

tcpser -l 7 -tsSiImM -v 25232 -S 2400 -L log.txt -i"s5=20"

run c*base with 2400 baud userport:

x64sc -default -warp -drive8type 1581 -rsuser -rsuserdev 2 -rsuserbaud 2400 -rsdev3ip232 TestBBS.d81

run c*base with 38400 baud swiftlink:

x64sc -default -warp -drive8type 1581 -acia1 -acia1mode 1 -myaciadev 0 -rsdev1 127.0.0.1:25232 -rsdev1ip232 -rsdev1baud 38400 TestBBS.d81

tickets

links

tcpser

windows