Emulation of RS232 VIC20 for running multiplayer games

[beamrider]

good work

I tried to get this up and running a while ago, but there was a VICE bug preventing it. Glad to know that it's now possible.

edit: have you also had it working with VICE and a real Vic-20?

[mimmosic]

@beamrider:
A mixed emulated-to-physical connection is still to try out, but it should work too.
Too bad I don't have anwifi modem to plug in for trying.

I don't have enough knowledge on wifi modems around, I noitced most of them seem to be aimed at contacting BBSes, while I need very basic and standard TCP/IP comunication. Perhaps I need some advice on models to try out.

...But a 1 to 1 communication is just achieveing what we did almost 30 years ago with the cable.

The richest goal I am aiming at is the possibility to connect a VIC to an ordinary website and build a simple and robust communication scenario to allow the development of a multi-clients app, using the website as a hub. Imagine a mmorpg where many can play, using a client running on vic-20s, it would be really cool!

Or a multi-user chatroom using a website as a central hub, acting as a directory, and clients running on vic20s and c64, emulated or not.

[groepaz]

i have started to look into this recently (and already fixed some things), progress is being tracked here: https://vice-emu.pokefinder.org/index.php/RS232 - the page also contains brief instructions/documentation how it works (C64 specific, but should work very much the same for VIC20)

[brain]

I agree with the OP that tcpser is not the right tool for this use, or at least, the OP does not need two emulated modems. But, I find it odd that no one emailed me on this, as my email address is listed on every page about tcpser...

It has been a long time since I used tcpser -D (Leif and I used it to play Modem Wars as a test), but here's the thread:

http://jledger.proboards.com/thread/932 ... rs-working

And the commands are:

tcpser parms:

server:

tcpser -d /dev/ttyS1 -p 6400 -s 300 -D: -I

client:

tcpser -d /dev/ttyS0 -s 300 -p 6500 -D"dilbert:6400" -I

Jim Brain

[LoadError]

This was interesting, fun and promising. Grazie!

[groepaz]

After toying with this issue a while... i came to the conclusion that also tcpser has bugs that make this stuff not work 100% reliable. Recent VICE has the "ip232" stuff fixed now, but that only cures part of the problem.

@brain: so the key to get feedback and you eventually looking into that tcpser pull request and/or even look at what the problems with it are... is email?

[brain]

Hehe, no, I know you are interested. And, I am slowly working through the source.

The problem is that in the intervening years, there's been patches to support Telnet, but they break the 8 bit clean approach of the original code. As well, a weird parity handling option was introduced, which I don't think is implemented correctly. On the other hand, some others have made useful bug fixes to the FoxxTezz code base, so I am trying to go through each version and pull the correct stuff into my codebase.

It's a bit tedious, but I am getting through it. And, trying to relearn the ip232 stuff Andrew put in.

So, give me a bit longer to get all patched up to current.

Jim

[groepaz]

great. the ip232 stuff is really really simple, it just introduces one escape code (see https://vice-emu.pokefinder.org/index.p ... ol_support )... the problem with fixing this detail is that BOTH ends (ie tcpser and VICE) arent working 100% correctly (also not the old 1.19), its a bit of a chicken and egg problem. i tried to write out whats wrong in tcpser here.

oh well, i wont be much of help for the rest of the stuff, network programming isnt exactly my field of expertise (quite the contrary - i try to stay in maximum distance). would be really nice to get this stuff fixed however, it has been buggy since forever

[brain]

OK, I finally had time to grok all of the bug fixes people have applied to my code over the years and get them in order:

https://github.com/go4retro/tcpser/tree/v1.1rc1

I am looking at ip232 now. groepaz, do you have a VICE build I should use for testing?

[brain]

Actually, any chance of a small test program that does not require setting up the full VICE experience?

Jim

[groepaz]

if you are on windows, nightly builds are on vice.pokefinder.org

as for "simple test program".... yeah i wish there was some - its all extremely tedious to test.

i tried coming up with testcode on the pc (ie a program that uses both "ends" of tcpser at the same time, and does sanity checks) but thanks to my non existing network-programming expertise that program had more problems than VICE and tcpser combined =P

all i can offer is the already mentioned wiki page :/

[brain]

Well, I made some changes, and I have a test program here that exercises the various items. I'd pull down the latest and try it. DCD goes high on connect and low on disconnect, and it appears to not pass those values on to the user layer.

Jim

[brain]

OK, I loaded up c*base test, and here's the latest I have:
tcpser was run with:

tcpser -l 7 -v 25232 -tiIsSmM

I initially tried the 11/19 snapshot, but 2400 bps seems horribly broken (it wouldn't even work as well as base 3.3), so I used stock 3.3 for this test. Will try others...

While BBS is loading, it starts sending random 0x80 bytes to the modem... The modem repeats those back. I checked, and a real modem does as well. This is probably because userport line is shared with something IEC related or otherwise toggling data pins.

When the BBS starts up, it waits, does an atz, then an ath0, which also works, and then prepares to receive a call. After a RING, the BBSdoes ata, and then:

Code: Select all

2019-11-18 23:23:18:25770424160:DEBUG_X:Sending text response
2019-11-18 23:23:18:25770424160:TRACE:SR->|0000|43 4f 4e 4e 45 43 54 20 32 34 30 30            |CONNECT 2400    |
2019-11-18 23:23:18:25770424160:TRACE:RS->|0000|43 4f 4e 4e 45 43 54 20 32 34 30 30            |CONNECT 2400    |
2019-11-18 23:23:18:25770424160:TRACE:SR->|0000|0d 0a                                          |..              |
2019-11-18 23:23:18:25770424160:TRACE:RS->|0000|0d 0a                                          |..              |
2019-11-18 23:23:18:25770424160:DEBUG_X:Connection status change, handling
2019-11-18 23:23:18:25770424160:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-11-18 23:23:18:25770424160:DEBUG_X:Command Mode=0, DCE status=1, Line status=2
2019-11-18 23:23:18:25770424160:DEBUG_X:Setting timer for break delay
2019-11-18 23:23:18:25770426976:DEBUG:IP thread notified
2019-11-18 23:23:19:25770424160:DEBUG:Initial Break Delay detected
2019-11-18 23:23:19:25770424160:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-11-18 23:23:19:25770424160:DEBUG_X:Command Mode=0, DCE status=1, Line status=2
2019-11-18 23:23:22:25770424160:DEBUG:Data available on serial port
2019-11-18 23:23:22:25770424160:ENTER_EXIT:Entering ip232_read function
2019-11-18 23:23:22:25770424160:DEBUG:Read 1 bytes from ip232 socket
2019-11-18 23:23:22:25770424160:TRACE:RS<-|0000|0e                                             |.               |
2019-11-18 23:23:22:25770424160:ENTER_EXIT:Exitting ip232_read function
2019-11-18 23:23:22:25770424160:DEBUG:Read 1 bytes from serial port
2019-11-18 23:23:22:25770424160:TRACE:SR->|0000|0e                                             |.               |
2019-11-18 23:23:22:25770424160:TRACE:IP->|0000|0e                                             |.               |
2019-11-18 23:23:22:25770424160:DEBUG_X:Found non-break character, cancelling break
2019-11-18 23:23:22:25770424160:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-11-18 23:23:22:25770424160:DEBUG_X:Command Mode=0, DCE status=1, Line status=2
2019-11-18 23:23:22:25770424160:DEBUG_X:Setting timer for break delay
2019-11-18 23:23:22:25770424160:DEBUG:Data available on serial port
2019-11-18 23:23:22:25770424160:ENTER_EXIT:Entering ip232_read function
2019-11-18 23:23:22:25770424160:DEBUG:Read 3 bytes from ip232 socket
2019-11-18 23:23:22:25770424160:TRACE:RS<-|0000|93 0d 0e                                       |...             |
2019-11-18 23:23:22:25770424160:ENTER_EXIT:Exitting ip232_read function
2019-11-18 23:23:22:25770424160:DEBUG:Read 3 bytes from serial port
2019-11-18 23:23:22:25770424160:TRACE:SR->|0000|93 0d 0e                                       |...             |
2019-11-18 23:23:22:25770424160:TRACE:IP->|0000|93 0d 0e                                       |...             |
2019-11-18 23:23:22:25770424160:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-11-18 23:23:22:25770424160:DEBUG_X:Command Mode=0, DCE status=1, Line status=2
2019-11-18 23:23:22:25770424160:DEBUG_X:Setting timer for break delay
2019-11-18 23:23:23:25770424160:DEBUG:Initial Break Delay detected
2019-11-18 23:23:23:25770424160:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-11-18 23:23:23:25770424160:DEBUG_X:Command Mode=0, DCE status=1, Line status=2
2019-11-18 23:23:25:25770424160:DEBUG:Data available on serial port
2019-11-18 23:23:25:25770424160:ENTER_EXIT:Entering ip232_read function
2019-11-18 23:23:25:25770424160:DEBUG:Read 1 bytes from ip232 socket
2019-11-18 23:23:25:25770424160:TRACE:RS<-|0000|01                                             |.               |
2019-11-18 23:23:25:25770424160:ENTER_EXIT:Exitting ip232_read function
2019-11-18 23:23:25:25770424160:DEBUG:Read 1 bytes from serial port
2019-11-18 23:23:25:25770424160:TRACE:SR->|0000|01                                             |.               |
2019-11-18 23:23:25:25770424160:TRACE:IP->|0000|01                                             |.               |
2019-11-18 23:23:25:25770424160:DEBUG_X:Found non-break character, cancelling break
2019-11-18 23:23:25:25770424160:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-11-18 23:23:25:25770424160:DEBUG_X:Command Mode=0, DCE status=1, Line status=2
2019-11-18 23:23:25:25770424160:DEBUG_X:Setting timer for break delay
2019-11-18 23:23:25:25770424160:DEBUG:Data available on serial port
2019-11-18 23:23:25:25770424160:ENTER_EXIT:Entering ip232_read function
2019-11-18 23:23:25:25770424160:DEBUG:Read 2 bytes from ip232 socket
2019-11-18 23:23:25:25770424160:TRACE:RS<-|0000|01 01                                          |..              |
2019-11-18 23:23:25:25770424160:ENTER_EXIT:Exitting ip232_read function
2019-11-18 23:23:25:25770424160:DEBUG:Read 2 bytes from serial port
2019-11-18 23:23:25:25770424160:TRACE:SR->|0000|01 01                                          |..              |
2019-11-18 23:23:25:25770424160:TRACE:IP->|0000|01 01                                          |..              |
2019-11-18 23:23:25:25770424160:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-11-18 23:23:25:25770424160:DEBUG_X:Command Mode=0, DCE status=1, Line status=2
2019-11-18 23:23:25:25770424160:DEBUG_X:Setting timer for break delay
2019-11-18 23:23:26:25770424160:DEBUG:Initial Break Delay detected
2019-11-18 23:23:26:25770424160:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-11-18 23:23:26:25770424160:DEBUG_X:Command Mode=0, DCE status=1, Line status=2
2019-11-18 23:23:28:25770424160:DEBUG:Data available on serial port
2019-11-18 23:23:28:25770424160:ENTER_EXIT:Entering ip232_read function

Interesting that I get 0e 93 0d 0e 01 01 01 in from the BBS, and out to the client. Then, right after this, the BBS does and ath0 and goes back to the main screen.

It's late, but I'll try nova and some others tomorrow, and some other VICE builds.

[groepaz]

stock 3.3 probably isnt a good idea - since that doesnt support ip232

and yes, its horribly broken, also in the old versions it only works (in some situations) by chance. userport rs232 seems to be more stable than swiftlink emulation. it should work in recent builds though, i didnt touch rs232 stuff since i added ip232 a while ago.

that said, problems in tcpser can probably be triggered and fixed in older VICE anyway - but you'll have to keep in mind that you will also see irritating behaviour because of the missing ip232 stuff (eg logging off from the bbs requires dtd to work), without it will hang and not recognize the dropped connection.

could you attach that test program? i could play a bit with it too

[brain]

Denial won't let me attach the files, but here they are:

Place this file in the src dir of tcpser:

https://pastebin.com/AQheNDYi

Here is the Makefile.ip232, please in same dir as Makefile

https://pastebin.com/KuijELuB

Just do make -F Makefile.ip232test to get the utility.

It re-uses a lot of the main code. Something to remember is the names are reversed in the util. When it says Virtual DTR Up, that really means the Virtual DSR is high. It's not worth it to rewrite the ip232.c code to be "directional".

You can see that the connect causes the DTR to go high.

Jim