Closed rhalkyard closed 4 years ago
I haven't made any changes to up2400 from its original repo. -Thom
it is important that RTS/CTS handshaking be set up, also, the modem needs to not escape 0xFF as 0xFF 0xFF (treat as raw).
Thanks; I'll double-check. I've only been able to try this under emulation with tcpser
, since my homebuilt wifi modem is unreliable garbage (which in turn is my motivation for #31 😄). I've tried tcpser
's various flow-control options, but the VICE docs are incredibly unclear as to how RTS/CTS works with all that.
Looks like the UP2400 driver change was committed by @greg-king5 in f270f52
commit f270f520a8320c670188908d670fb489340e1bb5
Author: Greg King <gregdk@users.sf.net>
Date: Fri Dec 14 00:01:03 2018 -0500
Replaced Johan's ser-up2400 driver with one that has several fixes.
* Puts the buffers in a safe place.
* Stops and closes the RS-232 device when requested to do so.
* Has some less complicated code.
If you use tcpser, PLEASE USE MY FORK, which has the IAC escaping code excised:
http://github.com/tschak909/tcpser
and run tcpser with -i "&K3"
-Thom
That seems to have done the trick, thanks!
Seems that these days everyone has their own tcpser fork! It's hard to keep track of all of them!
Three points about VICE:
I've noticed that when using the UP2400 driver, screens will often have garbage characters in places, and incorrectly-drawn or positioned, or sometimes completely missing elements - see the screenshot below.
This doesn't seem to be a protocol-decoding issue, since the same screens render fine with SwiftLink, but they always seem to render with the same corruption under UP2400. Could this be related to #28, discussing a change in the upstream UP2400 driver to fix an issue where
0x00
bytes got received as0x0D
? From commit f270f520a, it looks like the the UP2400 driver distributed with PlatoTerm has diverged from that codebase, but I couldn't find a copy of the source to examine the changes.