improve RS232/Swiftlink Emulation to work over TCP/IP
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
Menu
▾
▴
#1777 improve RS232/Swiftlink Emulation to work over TCP/IP
I have posted this before and did some work with Spiro but have since lost contact with him
The RS232/ACIA emulation has improved greatly in v2.2 It still can not detect a carrier when using Jim Brain's TCPSER to communicate over the internet. Now I do understand it is a bit of a hack which makes it not "True" emulation but there are still many of us who like to play with BBS programs and such and it would be great if we could run them inside of Vice. Maybe have a checkmark option to use a hacked version so it communicates with TCPSER that way it expects.
There is a patched version of Vice 1.19 that works correctly with TCPSER but as you know, it is quite out dated. I would love to be able to use the newer version of the program with my projects.
I would be more than happy to provide any information you may need. Most of my programming on the C64 deals with BBS/Terminal programs so I am sure I can get you the information you may need.
As always, thank you for providing such a great program.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
Sorry, I posted that as anonymous, I can be reached at: jbrown1289@gmail.com
this is actually not a bug, the "real" rs232 emulation on the real physical com port works fine (including DTR/CD etc)
the problem is that the protocol used between vice and tcpser is not elaborate enough to support those control lines.
(moving to feature requests)
i am trying to fix this right now... the status is being tracked in the wiki: https://vice-emu.pokefinder.org/index.php/RS232
GPZ I am working on putting together a package for you of Image BBS v1.2b with both User Port and Swiftlink Emulation, just so you know. Image works with v3.2 albeit with some changes. DTR does NOT work, DCD does NOT work, I have it set up with reverse DTR and escape codes to hangup. If a user "drops carrier" it sits in limbo until the software times out, because the system still thinks Carrier is present. I can give you also my setup in v3.2 to look at.. The v1.19 package will include everything needed to run Image BBS. I never ran it on v1.19 so I don't know how simple it will be to get it to work as it should out of the box on real hardware. Another note, I use BBS Server v1.14 which shows DSR has constant traffic, on real hardware DSR is never lit.. If you need any info on any of what I have done please get back to me and I will forward all info... Also if you would like a run down of how I currently have 3 WinVice instances running Image BBS v1.2, v2.0 and v3.0 on 1 PC with WinVice v3.2 and BBS Server drop me an email at bucko219@gmail.com and I can forward or explain my setup.. Hope I can be of some help to you..
sounds good, the more testcases the better. to make it easiest for testing, please install on d81 and put the "boot" file first, so the image can be easily autostarted. i need step by step instructions on what to do when the bbs started too, i never used one (as a sysop)
You just made my day.. I will provide all on d81 images.. I was told you would need .d64 images and putting these BBS' on d64 images is like trying to fill a 2 lb box with 5lbs of stuff.. I will get it set up in the next few days...
Hi GPZ, attached is a Image BBS v1.2 setup to use, unzip the file to your c:\ Drive and read the docs for setup. I will work on a 19.2k swiftlink file tonight or tomorow night. This one is very simple to test with as the docs will show.
If you need me to test any files please let me know. I can test both Userport and Swiftlink modes very easily..
Last edit: Al DeRosa 2019-08-25
no need to include winvice or tcpser, btw. i have that, and i am on linux anyway :) what i need are precise instructions to reproduce whats wrong, so i can see if my supposed fixes actually work
Sorry about that.. The instructions for logging on the BBS are included in the zip file. As for what is wrong. If you log on with any version other then the v1.19 hack for Windows, at any time if you drop carrier the BBS does not see the change in carrier and it waits for the BBS to time out. DCD is not being detected. In order for me to get the Image BBS to run on any other later version I need to reverse DTR, so DTR is not going HIGH like it does in v1.19. If you do not reverse DTR the BBS will answer incoming calls but never connect, then sending the AT commands trying to reset to the user trying to connect. Last but not least when you log off the BBS DTR is supposed to go LOW to drop carrier, the software does request DTR to go low as it works on real hardware, in all versions including the 1.19 hack it does not go low. It stays HIGH (at least in v1.19 hack) In the other versions DTR does not change thus never dropping carrier. My workaround for that has been using escape codes to drop carrier. DTR functions properly on real hardware. One last comment, as I am sure you already are doing, all of this needs to be done from a term program "dialing" in via Telnet to the system. Everything acts the same way with Swiftlink cartridge also. I will upload a d81 of a system running Swiftlink hopefully tonight or tomorrow night.
Last edit: Al DeRosa 2019-08-26
Attached is the swiftlink setup for Image BBS all of the info for User ID password etc are all the same, just the swiftlink setup has been enabled. The Swiftlink emulation has more issues then the User port, as said above the User Port with v1.19 works perfect except for lowering DTR to drop carrier.. The Swiftlink emulation in order to get the BBS to answer you must reverse DTR, DCD never changes, it stays at a 0 in TCPSER, if the user drops carrier the BBS waits to time out before resetting. Testing is simple. In Image BBS to reverse DTR at the main idle screen you hit SHIFT T to put a checkmark in the upper right hand corner of the screen that means DTR has been reversed. Log on from your term program of choice and when you get to the user id question drop carrier. You will see the BBS just sits there until the idle time has expired. DCD never changes. For the BBS to drop carrier upon logoff you need to use ESCAPE codes instead of DTR. Real hardware does work with DTR.
Now start over, do NOT reverse DTR upon bootup. When you try to connect to the BBS via your term program, the BBS answers, but never makes a connection.
I know I am jumping around. If I did not make sense in this or my User port testing please ask questions. I will be more then happy to explain what I have done more throughly.. Hope these disks help...
Last edit: Al DeRosa 2019-08-28
thanks again... i wont be able to look at it this weekend... maybe next :)
in r36988 i have added some support for DCD at least, and only for userport rs232. i have tested with c*base (because i am more familiar with that) so far - would be great if you could do the same with imagebbs :)
No problem testing it, just please explain how I can get a compiled copy of r36988 all I can find is the trunk directory and I am not well versed in compiling Vice as I just use the Nightly's or release versions..
ok, well, just wait until a new build shows up on https://mega.nz/#F!HklwlAZS!vDiSevLlzGQUQL6wOmvhUg then :)
Ok.. I can do that... Thanks...
I'll build a windows version using trunk for you. I assume you don't require ffmpeg for testing?
Thanks Compyx.. I appreciate that.. No I don't need ffmpeg, just the main file to boot up winvice with disks. I can test the DCD on Image and report back...
I've uploaded x64 Gtk3 and SDL2 bindists here: https://sourceforge.net/projects/vice-emu/files/experimental%20binaries/
They were built with --enable-debug, so they might spit out quite some debug info on the terminal, which might help us with tracing problems.
Let me know if they work.
Thank you.. I do appreciate it.. I will download and test it tonight and have some results soon after...
Cool :)
Ok I ran the tests to see how it would go.. DCD is detected on call connect, and drops when you drop carrier. Still need to reverse DTR to get connected (v1.19 does not need to) I know DTR is not fixed so dropping carrier nothing happens. The only other strange part is it will only connect at 300 baud and because there is a baud difference between between TCPSER and the BBS program nothing is transmitted to the term program.. Only other thing I had issues with was GTK version wouldn't stay running it kept crashing and closing. I used the SDL version.. If you want me to try anything else just let me know..
I think the problem we are seeing here isnt only located in VICE - also tcpser seems to misbehave... i will write a test program for tcpser next, and then try to fix it. That said, i couldnt make 1.19 to work at all for some reason
Doing some more testing this morning.. DCD at the moment is working fine.. It's a bit slow on the carrier dropping but is showing carrier detected when connected, When dropping carrier it resets the BBS as it is supposed to.. I am going to take it another step further later and instead of using TCPSER will try BBS Server v1.4a plus a null modem cable to see how that works. In my testing the com port designations do work correctly as it see's the com ports now. DTR as we know is not fixed so I won't get into that.. Suffice to say DCD is working correctly with TCPSER at least in the SDL model. When I test BBS Server later I will respond with more info. On a personal note, DCD correction is a huge plus here! At least for Image BBS dropping carrier has been an issue with my BBS' since I went Vice especially with the Networking setup. So far so good.. I will respond back later with more details as I come across BBS server testing..