ACIA RS232 emulation does not handle carrier detect
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
Menu
▾
▴
#262 ACIA RS232 emulation does not handle carrier detect
I would still love to see RS232/ACIA emulation work properly via Telnet so we can run BBS's in vice.
Says if you map it to a physical com port everything including carrier detect works. But it does not. Depending on how the carrier is checked it will either show it is on full time or if it is off full time.
If I can be of any assistance I would be glad to help. If someone has it working I would love to know about it. If I thought the Linux version worked properly I would just set up a Linux system to run it.
moving to bugs
it would help if you could give a defined testcase
I've been getting notifications on this so maybe it is being looked at.
Ex. I have a PC running the software BBSServer which is basically a modem emulator that will allow you to telent into a BBS. On real hardware, everything works fine including carrier detect. In vice, carrier detect does not change once you connect to another system. It is very easy to test, Novaterm for the C64 shows when there is a carrier or not present. On real hardware, it shows it is off and you connect to a BBS it shows it is on. With vice, depending on if you have it set for inverted carrier detect or not, it will either show on all the time or off all the time. I know there are quite a few of us that would love to run a BBS to be accessible via telnet but do not want to run it on real hardware. If we could get a viable solution to carrier detect across the net in vice that would be completely awesome. I would love to re-live my teenage years by telnetting into BBS's and such again. Thanks for your time.
I know this is an old bug report, but I can attest to this. I currently run 2 BBS'.. One runs with Swiftlink emulation, and one with Userport Emulation, but do not detect carrier, it is either on all the time or off all the time.. On real hardware the software runs fine, carrier detect is correct. I can attest to this happening in both TCPSER and BBSSERVER. If you need any logs or need someone to test fixes I am willing to test or supply anything. I can also send you a test setup of the entire package if needed in both BBSServer or TCPSER.. This happens in every version to the latest.. Thanks for looking into this..
Last edit: Al DeRosa 2019-06-18
kinda missed this ticket. i am looking at rs232 things atm, progress is tracked here: https://vice-emu.pokefinder.org/index.php/RS232
still badly looking for test cases that do not involve running a BBS program
please test again with a recent build, there were a couple of improvements
After testing, multi punter transfers no longer work.. Up to R40835 everything was perfect. Punter/Xmodem single transfers were fine, and Multi Punter were fine. Now you get 1 file transferred and the 2nd file is all bad blocks.. This is using ACIA, not user port. Something got broken somewhere.. :( Reverted back to 40835 and all is well...
It'd really help if you could find a less complex test case.... can the problem be reproduced using two instances of VICE and using Novaterm, for example?
Hi GPZ.. Not sure if you mean me or the original poster.. I am using a BBS program and downloading from the same BBS program via a different instance of vice. They are using vice on both, if you would like I could test novaterm on 2 different instances and see what happens, let me know if that is the case.. :)
yes, please. even better if you'd use two instances of striketerm (as that starts up quicker)
even more betterer if you find a testcase that is even simpler (but i cant think of what that would be either)
Last edit: gpz 2021-10-14
Preliminary testing.. Using Swiftlink (ACIA) uploading from 1 instance of Striketerm to a 2nd instance, both using TCPSER latest version, doesn't work currently at 120 retries of block 1 of 9 block file. No blocks or bytes received on the downloading side.. Tomorrow evening I will try the userport side and also the pre 036 changes.
I did a test using 2 instances of CCGMS 2021 (with Turbo232 driver at 19200bps selected) using socat on linux.
Transferred 3 files using multipunter, 177 blocks total all went through perfectly 0 errors, 0 retries.
Just in case, I transferred a single file using punter right after that, it also completed without errors.
Can you guide me on how to setup 2 TCPSER instances to talk to each other and VICE?
(Edit, nevermind, I figured it out)
Last edit: Durandal 2021-10-16
LOL I was just replying when I saw the edit.. LOL Only difference I can see is you are using socat and I am using TCPSER which as you know is more modem like..
just to say it again: when using tcpser, use IP232 - and use the latest tcpser :) Also, its probably a good idea to try 1:1 connection (like with socat/netcat) too - because if one works but not the other, perhaps the problem is even located in tcpser.
edit: plus the very same setup should be tested with both acia and userport
Last edit: gpz 2021-10-16
btw (slightly offtopic :)), there'a a special VICE version of tcpser:
https://github.com/go4retro/tcpser/tree/vicekludge
no idea what is different, also i guess you know that "kludge version" already.
Last edit: Querino 2021-10-16
never heard about this, or what that "kludge" would be. it should work with the regular one IMHO
https://github.com/go4retro/tcpser/commit/054a8ff2b143fb4ae4ac1a179760f7fab0f0366e
some reconnection problem. i dont touch that area of the code :)
ok, found again where i read about it:
https://sourceforge.net/p/vice-emu/bugs/1356/#9c95
yeah... this stuff shouldnt cause problems with file transfers though, once its connected it doesnt matter :)
I havent managed to transfer any file using TCPSER, tried with both FozzTexx's version and that vicekludge one.
FozzTexx's logs a lot of NVT command parsing messages and eat CPU time when connected to other local instance.
The vicekludge version doesn't do that, but in both versions the results are the same:
With IP232 ON (as it should be), multipunter outrights cancels on the receiving end when using CCGMS. With Striketerm the receiver shows a mangled filename and 'hangs' there.
With IP232 OFF: In both CCGMS and Striketerm the filename is received correctly, but the first block fails constantly (as expected, VICE is not filtering the incoming IP232 commands from TCPSER, resulting in duplicated $ff chars)
perhaps tcpser needs some specific way the handshake lines are setup? ppl are using this kind of setup for their BBSs, so it probably worked before =)
Was able to test some more, I tested the User Port and it worked perfect uploaded and downloaded 5 files same test set up as I used in my prior testing. I then tested the R408035 version of Vice from before the changes and both User port and ACIA worked perfect transferring 10 files each time.. Hope that all helps, what it tells me is something broke in the ACIA setup during the changes... Then again I am not ML programmer..
As for the Kludge version that was created because the socket was not releasing fast enough for TCPSER to connect to it twice in succession, that issue which I was having with Image BBS has been corrected as I have edited the RS232 routines in Image BBS to fix the problem and the latest vice 1.1.4/1.1.5 works perfect with it now...
I will say this, I haven't used multi transfers as I can't figure out how to set it up in Striketerm as of yet...
Just figured out multi transfers, they are not working in ACIA but they work with my BBS.. Go figure...
Reverted aciacore.c to the previous version (R40434) and it didnt make any difference for me, still cant get to transfer a single block with punter while using TCPSER
Last edit: Durandal 2021-10-16
I will assemble in Linux with the aciacore.c file and test via my BBS, I can't get multi transfers to work at all with striketerm. User port multi transfers work as you can see from the attached picture.. I will test with my BBS and the older aciacore.c tomorrow.. I will report my findings tomorrow..