Once I could log into the old BBS from its local console, the next job was letting a terminal connect over telnet. C-Net expected a serial modem. I needed something that could turn a TCP connection into the conversation it understood.

The first attempt used WinUAE’s serial-over-TCP support and a Hayes modem emulator on Windows. In that setup I could get C-Net the signal that allowed it to send, or the carrier signal that told it a call existed, but couldn’t get the combination it needed. It never got beyond “Answered, Hanging up”.

SerialTCP runs on the Amiga itself. It provides a virtual serial device backed by TCP, with the AT commands and modem status that BBS software expects. WinUAE supplies the network stack, and C-Net opens serialtcp.device in place of the physical serial device.

That got the modem conversation much further. An incoming connection produced RING. C-Net sent ATA, the command to answer. SerialTCP returned CONNECT immediately.

Then C-Net waited until its 50-second answer timeout and hung up.

C-Net 3 clears its input just after sending ATA. With a real modem, there is time for that: the modem has to negotiate the connection before reporting CONNECT. SerialTCP already had a TCP connection waiting. Its response arrived early enough to be thrown away with the cleared input.

The local fix adds connect-delay to SerialTCP. After accepting the answer command, the daemon holds the call pending until the delay expires, then completes the connection. I set it to 5,000 milliseconds. The new setting defaults to zero, preserving the existing timing unless it is configured.

With that delay, C-Net sees CONNECT after its input clear and proceeds to the greeting. The BBS executable hasn’t changed. The patch is in the virtual modem. I submitted it upstream on September 22 as SerialTCP PR #2; as of October 11, it is still open, not merged.

The board now has four C-Net ports assigned to four SerialTCP units. Callers use one TCP port and get the first available line. The local test with five simultaneous connections produced four login prompts and one busy message. SyncTERM also held a session, and the door menu worked over telnet for an account with door access.

The September 21 trial of the board under Amiberry in Docker, built with the same patch, passed XModem uploads and downloads. That trial turned up a second SerialTCP bug: the long runs of + characters in the board’s ASCII artwork made its escape-sequence check stall on each one, so those screens drew very slowly. I submitted that fix on September 22 as PR #1, also still open as of October 11.

September 24 update: Zmodem uploads and downloads worked on the WinUAE board, with the returned file matching the original byte for byte. The earlier Docker XModem result belongs to the guest configuration used on September 21, not the stock OS 3.1 guest that replaced it. A call from another machine on the LAN is still to test.

October 21 update: A Docker copy of the Inn on a second machine at home has since taken calls from this PC through a relay. That call worked on October 20; a call from another machine to the WinUAE board itself is still untested. The Docker copy isn’t open to the public.