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.
Was able to test tonight with the ACIACORE.c from 84035 and with my BBS worked like a charm.. No issues at all.. I was able to transfer a file from my BBS to another and pick up what was waiting there for me with 0 bad blocks and a total of 40 blocks.. Hope this helps.. Unfortunately my test bed I can't assemble Vice in Windows so I can't do anything other then basic testing on that..
I tested an instance of VICE using userport with another using ACIA, the problem is in the transmission line from the ACIA, reception is correct.
It seems to be skipping every other outgoing character when writing 'full speed' to the transmit register.
Now to find out why this only happens when using interrupts and TCPSER at the same time...
The problem was that the DCD line level was inverted for the ACIA emulation, but that's something that was not touched by R40836.
The network layer uses positive logic while the ACIA uses negative logic for DCD.
The network layer also never asserts DCD for direct (non-IP232) connections.
This meant DCD was only active for direct connections or, if using TCPSER, before dialling a number or answering a call.
On the software side, the routine writing characters to the ACIA Tx register checks for both DCD and Tx buffer empty with a single AND#, if DCD is up (inactive) the code thinks the Tx buffer is empty and writes another character before the previous is transmitted.
Im including a small patch that inverts the DCD line for the ACIA, and permanently asserts DCD if the selected RS232 device is not using IP232.
I've tested this using 2 local VICE + TCPSER instances, 2 local VICE instances through SOCAT and a single VICE instance connected both directly and through TCPSER to an external BBS(1).
All Multipunter file transfers completed without errors for the local tests
The external BBS tests gave lots of errors (~75%) when downloading a single file with Punter, but that may be attributed to the external BBS itself and not VICE. Despite the errors, the downloads always completed.
Note that I couldn't reproduce the original issue (1 good file transfer then errors on the next file, for me the 1st file wouldn't even begin to download when using TCPSER).
1)13th.hoyvision.com:6400
The patch works!! DCD is now correct in ACIA mode as you said. Before the fixes, I inverted carrier with TCPSER so TCPSER would show carrier present until someone would dial into my BBS then it would show not present. Now it is correct and shows No carrier (DCD:0) until someone connects.. I also transferred 19 blocks to one of my other links on my BBS Network and received 19 blocks back from that BBS with 0 bad blocks.. My opinion is commit the patch to the product unless you want to do more testing.. Great job adding in the new features and fixing up the routines..
Last edit: Al DeRosa 2021-10-20
@Durandal so is this ready to be merged?
Sorry, yes!
patch applied in r40934 - please test and confirm working so we can close the ticket :)
Working fine here, both direct connection and through TCPSER
I can't test today but the patch has worked since Durandal sent it. I am sure it will work fine when I update to latest Nightly. :) Thanks guys for the great work...
great, closing this!
We might have jumped the gun on this. I just updated my Windows machines with the latest Nightly, and transfers don't work at all.. Reverting back to a very old one I was using r39570 and transfers work fine. In Linux everything is perfect, but in Windows 1 block is sent and nothing but bad blocks afterwards.. I am going to try to build a Windows version tomorrow with none of the changes from 40934 and see if everything works... I will respond back.. I find it hard to believe it works fine in Linux but not in Windows.. Something is different with the way it either assembled or the way transfers work with Windows (not Vice)..
I tested on Win7 and couldnt replicate the problem. At least with CCGMS 2021 + TCPSER
what kind of setup are you using in windows? ie what is different vs your linux setup? we'd need all the programs involved to reproduce the problem
Last edit: gpz 2021-10-31
Sorry I haven't been able to get back to you till now. Nothing is really different other then one uses CMD HD emulation with SCPU, the other uses Lt Kernal HD emulation.. I am going to bring the one that works in Linux over to Windows and test it.. If it works with no issues, it could very well be a Lt Kernal Emulation issue.. I will test it over the weekend as I have been crazy busy this week with work...
Ewww yes. You should really test without any extra Hardware first. Also this is the first time you mention SCPU - which is again different from what others expect :)
The SCPU side works fine since the fixes.. The LT kernal one is running in Windows with an earlier nightly and runs great, when updating to the latest nightly it only has bad blocks.. I will test this weekend all options and see how it goes, and I will respond here.. :)
Did you remember to not use the invert DCD option when running TCPSER on windows with the new VICE build?
oh and... if you can actually narrow it down to lt.kernal - please open a new ticket for that (and only that) issue
Preliminary testing today, Linux To WIndows. No good.. Uploads 1 file fine then nothing but bad blocks on second file. That is CMD HD emulation SCPU Linux to Windows Lt Kernal emulation. The 2nd test, Lt Kernal Emulation to Lt Kernal emulation in WIndows, perfect. Later on I am going to test Linux regular x64sc to Lt Kernal and see what happens, and also CMD HD in Windows to WIndows. I will report back. I know I am using weird setups but I am just trying everthing that I run as wacked out as it is so the Vice software is a perfect as it can be.. I will respond back with my testing that I mentioned above either tonight or tomorrow...
It would really help if you'd remove anything like cmd hd or lt.kernal from the test setup. thats the only way we can make sure its actually the rs232 stuff.
I wish it was that easy, I will try to set up 2 different base systems (This is a BBS program) and set up a network between the two of them to test.. I am using in place setups that is why I use the add-ons, but you are right, each extra could be adding to the problem.. I will get to that in the coming days..
It would help also if you'd remove that BBS program from the setup, and use simplier software - perhaps its just that BBS program that expects some control line inverted
I will test 2 different instances with striketerm again. The reason for my comments here, are because the BBS program was working before the changes, in fact, there were no issues at all.. When Durandal did the update recently the Linux to an older nightly prior to 035 worked flawlessly, in fact it still works flawlessly, it's just the latest windows nightly when thrown into the mix, not so much. The BBS software is correct now, there was an issue last year but that was corrected.. My main thing here is to make sure everything works as it should with all software.. I will get back to you all... Happy happy joy joy! LOL
First set of tests worked as this, Ubuntu 20.04 using 1541 disk of striketerm, to a Windows with 1541 also striketerm, multi transfer first file fine second file nothing but bad blocks. Tried the opposite way windows to linux, same results. next set of tests I will run will be from Linux to Linux and Windows to Windows to see what happens.. For the hell of it I ran latest nightly in Linux to Windows r39570 and everything worked as designed.. Not sure why, I will try the other tests later today or tomorrow night and report back...