Serial port COM3 for file transfer (using file dialog/TCP bridge).

[cr1901]

Normally, when I have a PC with only a serial port and install media, I do a bootstrap from tcom.com or a BASIC Kermit to upload additional files to my machine.

COM2 connects to a real port (which is great!), so you can emulate a file transfer with a null modem cable connected to another serial port on your local machine. However, I'd like a simpler setup.

Would a COM3 port that is attached to a listening TCP port that sends/receives raw bytes be something you'd be interested in? I am willing to prototype this feature myself.

[dbalsom]

the idea occurred to me, and I had an idea for a TCP/IP modem using some kind of hayes commands to 'dial' IP addresses

Just noting you can already accomplish this sort of thing with the right os support, see
https://com0com.sourceforge.net/ and its com2tcp module, you can even do com->ssh with stunnel. https://www.stunnel.org/

and i believe on linux it's even easier as you can redirect a serial port with netcat.

[cr1901]

Indeed, I am on Windows. I almost mentioned com0com, but remembered that last time I used it there weren't any signed drivers (a while ago). This seems to have changed, and I'm running it fine on unmodified 64-bit Windows 10.

and i believe on linux it's even easier as you can redirect a serial port with netcat.

Do you mean socat? I don't think netcat can create serial ports device nodes, but socat can. It's been a while since I've done that. If I have a *nix system I can test this on, I will try and reply w/ results.

In any case, there's solutions for the two major classes of OS that martypc supports (*nix and Windows). So regardless of what you decide to do wrt TCP/IP and serial (I'm curious about your modem idea- custom hardware :o?), I'm not stuck.

[dbalsom]

no custom hardware, just another emulated device. similar to how the mouse is implemented - the mouse just converts mouse events from the window manager into mouse protocol bytes and sends them to through emulated COM1 serial port.

the only real advantage of having the virtual modem is being able to send it commands from inside the emulator; and reliving the experience of dialing a BBS. Consider an internal 'phone book' that maps phone numbers to IP:port. I dunno, the idea just sounded fun.

You'd want to have raw serial TCP connections as well, for applications that don't give you an interactive terminal.

[dbalsom]

In any case, the serial implementation in MartyPC is sort of barebones at the moment; i implemented just enough to get procomm plus to connect to a serial shell on a raspberry pi. If you do any file transfers i'd be curious to see how well it performs. Checkit diagnostics fails several serial port tests so I have some work to do there. The UART i'm emulating is also pretty primitive.

[cr1901]

Works for me. Is it possible to add an option to log I/O port writes to the serial port as well (just so I know the status of the port)?

[dbalsom]

sure.

[dbalsom]

@cr1901
Sorry it's been so long, but you can see from the 0.2.0 changelog i've been very busy.
0.2.1 does have a basic IO monitor

so you can at least see port reads/writes. I still need to add serial logging and redirection to files and named pipes. What has been holding me up on serial logging, is I really want a general iostream service i can inject into devices that can then request a logging stream or data stream, and the service will handle the type of stream as appropriate. Nothing too crazy, just requires some thought. I think it will be a good addition for 0.2.1

[cr1901]

@dbalsom No worries, I'm patient :P. A logging service coupled w/ I/O port status should give me enough of a picture to figure out where truncation is happening.

Note that I've been busy myself (wrote a bunch of code in a new programming language, and the language changes quickly enough that it takes appreciable bandwidth to maintain my code). But I still have my martypc checkout. I will need to add checking out serial xfers to my TODO list.

If I haven't by the 0.2.1 release, feel free to yell :P.

[dbalsom]

Still pondering the proper general approach to device logging, but I just completed a major overhaul of MartyPC's serial emulation, so I wonder if things are any better.

There's also a first pass at a serial debug window.

you can watch number go up.

[cr1901]

I've gotten the v0.2.3 branch to compile and run, but there was a perf regression for me in dc4b4f7 according to bisect. Apparently the wgpu backend chosen changed (from NVIDIA Quadro to DX12) and performance (FPS) more than halved.

I acknowledge my hardware is older (Thinkpad W520), but seeing as it worked fine before this commit, I want to investigate further.

Also, what paint program is that?

[dbalsom]

Apparently it's not just integrated video adapters that got the opengl treatement. See the workaround in release notes. Basically you want to make an environment variable:

WGPU_BACKEND=gl

Eventually I might add in auto-fallback for this. I don't know why wgpu doesn't do it itself...

[dbalsom]

oh and that's PC Paintbrush.

[cr1901]

Okay, WGPU_BACKEND=gl fixed that. Indeed, if I had read the release notes, I would've noticed the fix. But who actually reads the manual, CHANGELOG, or release notes before diving right in? :)

I'll test to see if I can do a full multi-kb xfer over the serial line this weekend- on vacation today.

[cr1901]

I acknowledge there is a lot going on in this screenshot, but I wanted to get as much on-screen as possible for future-me. It looks like at least CTTY is working with the following options in com0com and Tera Term:

Of all these, I think only the following two are absolutely required for CTTY to work:

• "Use Ports Class" must be checked in com0com setup. Ports of other types (CNCA0, CNCB0) don't seem to be enumerated.
• Flow control must be disabled in your terminal application. My own experience is that DOS doesn't assert RTS, so the terminal app will just buffer chars to oblivion waiting for CTS to go low. (However, DOS does look at its CTS before deciding to send chars).

[cr1901]

Okay, so I've tried a TCOM.COM transfer with this file. According to Windows, this file is 3,392 bytes:

I have provided TCOM.COM on this disk image (no copyright stuff on it, so it should be fine): scratch.zip. It should be drive B, and DOS 2.1 should be drive A (probably can't legally distribute that, sorry :P).

TCOM.COM is designed to read from COM2 at 300 baud, and write to either stdout or a file if redirected. I have the same setup for com0com as in my previous comment. Tera Term setup is also identical except 300 baud. I have Tera Term (COM23) and martypc's COM2 (COM22 host) connected via com0com.

From reboot, if I do TCOM > FOO.TXT and then do a "File > Send File > ckboo.txt" from Tera Term's menu, I will receive a file that's 3,241bytes long, an RX Count of 3,322, and 85 RX¹ Overruns:

I'm not sure where 3,241 comes from, but I have a good idea where the 3,322 vs 3,392 is coming from; according to wc, ckboo.txt is 70 lines. CRLF must be being rewritten to CR somewhere. Although I've mentioned prior that DOS will do CRLF rewriting, TCOM.COM uses INT 0x14, which I don't think would be subject to CRLF rewriting.

I can deterministically reproduce these results across runs of TCOM.COM with the same file, even without rebooting. According to DOS' COMP, Identical files are created, so the characters being stripped/overrun are the same between runs.

Footnotes

1. I think RX Overrun will unconditionally mark the first received after reboot as an overrun, because it's "technically correct" that the PC didn't read the port before receiving that character :). However, for my purposes I'm ignoring it. Additionally, it looks like "RX Last Byte" is only updated on overrun... or at the very least becomes 0x00 if an overrun didn't happen for the current byte. Is this correct/intended?

[cr1901]

It very well could be a com0com bug/limitation. But then I can't reliably use com0com for data transfer, and we're back at my original problem :P.

One cheat I could do is give the 8250 an input FIFO only in passthrough mode, that might help with the overruns.

If proper emulation is a concern (since 8250 doesn't have a FIFO), could the FIFO be placed in between the virtual serial port passthrough (COM22) and the start of the 8250 emulation (COM2)?

[dbalsom]

If proper emulation is a concern (since 8250 doesn't have a FIFO), could the FIFO be placed in between the virtual serial port passthrough (COM22) and the start of the 8250 emulation (COM2)?

I'd probably rewrite the serial passthrough to use crossbeam channels, and we'd just recv() a new byte once one was read out. Then no need to explicitly emulate a FIFO buffer as the bytes will just hang out in the channel. I need to move everything to channels anyway with the eventual goal of getting the core running in a separate thread from the gui.

[cr1901]

Another option for file transfer is of course "create a floppy image from a directory tree on host", and do the reverse to "extract to host". But I'd still be interested in the COM port xfer since it's a broadly applicable data xfer technique (and serial ports are fun :D).

[dbalsom]

Another option for file transfer is of course "create a floppy image from a directory tree on host", and do the reverse to "extract to host".

i aim to please

[cr1901]

Well, this solves my original problem :). I guess using virtual serial ports will just have to remain "not supported" on Windows, since it seems that com0com is dropping chars before Marty ever sees them.