Commander X16

So BBS'ing on the X16 is now a thing! The ANSI support is great in the ROMTerm.

ZiModem refers to the ROM software in the Serial/Network Card itself (in reference to the author of that software, the legendary Texan Bo Zimmerman). [ and nothing to do with ZModem the file transfer protocol ]

https://github.com/bozimmerman/Zimodem


But what about getting two X16's to talk to each other? And what about those dip-switches on the card!?

First - I want to report on the 90-degree "Riser Board" to fit the card in sideways for the pizza-box style Lazer3D case (as these cards won't fit in the side-slot with that case either). I found the riser board had to be pressed quite hard to insert into the slot. I almost thought about slightly sanding the sides of the connector - but I gave it a 2nd try, and the riser board will fit into the X16 expansion slot. Just, at least for me, it was a concerning amount of pressure to do so (thankfully I did install all those spacers on the backside of the board).

As another minor nit about the riser board: the cool looking ESP and those dip switches end up "on the other side" facing down to the X16 board, so you can't access them while inserted into the riser board. That's ok, it's not like you need them often - but still, some might prefer the look. But all that said, the riser board does fit well, and the horizontal card does align nicely with the back of the Lazer3D case.


As for getting two X16's to talk to each other:

- First set them both up using the AT+CONFIG as described at the TexElec.com site (or the ZiModem github reference). This attaches the modem to your WIFI.

- I had the newest firmware, so I loaded ROMTERM.PRG and used the 921600 baud setting. Then use "ATB921600" and "AT&W" to config the devices to the highest speed.

Most BBS's have smarts to auto-negotiate the baud rate. There is a lot to this topic - in "telnet-based" BBS's versus traditional classic hardware based BBS's, and how they are managing their web connection. You take a baud rate and divide by 10 (accounting for START/STOP bits of the 8-bits of data) to get roughly the byte rate. So that's about 90Kbytes/sec which most WIFI can handle that, but BBS's still using "classic hardware" won't be able to push out their content that fast. So, be patient on those - but other BBS's may use more modern telnet-derived solutions and send much faster.

- On X16 #1, I had to initialize a "server listening port" using the ATAn command. Like so: I use port 6400 just since that's what I got used to using on the JimDrew WiModem232's.

- Use the command "ATI" to see what IP address your "network-serial-modem" has been assigned.

- Then, on X16 #2, use a dial command like this (replacing the IP with the one reported from the ATI command in X16 #1, and replacing the port with whatever you picked in the ATAn command earlier): (this is network, as in LAN, port number - not a hardware port number related to the X16)

- The "other X16" should connect on that port. I had expected ZiModem to show a "RING" result - maybe I'm still using it wrong or don't have it configured right. But I found that after the "CONNECT" message appears, then on X16 #1 just type "ATA" (with no number) to "answer" the connection - and now you are in a "streaming mode" across both systems.
NOTE: If you don't type ATA, something strange happens - the connection seems to be "uni-directional" and if X16#2 types stuff, the other system shows the value as both a symbol and then a kind of debug-mode decimal value of those symbols followed by a newline. I'm not sure if that's expected, but in any case, "answering the phone" (ATA) seems to resolve that and go into actual bi-directional mode.

- Do ALT+E in ROMTERM to disable ECHO mode while connected in the stream mode. With the speakers on, you'll hear a brief tone during any valid command that ROMTERM understands.

- When you are done typing/talking, on either X16 type "+++" and wait a moment (1 second) and the message "OK" should appear, so that serial-modem is now back in command mode (use "ATO" to exit command mode and go back to stream mode). You might press ALT+E again to enter echo mode. On X16#1, type "ATA6400" or "ATA0" (I'm not sure which one, but either of those should disable or turn off your server-listening port. On X16#2, type "ATH0" to hangup (and then also press ALT+E to toggle echo mode while in command mode).


Now what about those dip-switches and the port-setting in ROMTERM? The dip switches are labeled IO3, IO4, IO5, IO6, IO7, then L/H (low/high). The label on the back of the serial/network card shows what hardware ports those correspond to. These days, hardware (drivers) will automatically find appropriate ports to use (something that came more common around mid-1990s). Before then, we had to configure hardware devices ourselves via jumpers or dip switches to deconflict between the hardware resources they used.

Example of two X16's communicating with each other wirelessly... (LAN) The interesting thing about "classic BBS style chat" is you see the persons typing as they type it (as opposed to modern IM or text-messaging, that sends the whole message at once). In the old BBS style, you can "interrupt" the other person with your own typing, which just allows a different style of chat.

(this connection can be between any two systems with TCP/IP; didn't have to be two X16's)


I'd still like to see a UserPort wired solution someday - accepting that it will be slower since it's inline with the CPU and not "hardware accelerated" by a UART, but traditional DB25/DB9 connectors let you connect to many classic RS232 devices; and competitive gaming really needs to be wired rather than at the whim of wifi speed). Also, a cable solution wouldn't require an intermediate modern day router in the loop. [ note: the "serial side" of the network-serial card for the X16 does use an RS232 cable ]

To go beyond the LAN, you may need other router settings to open up the port you choose.

I haven't yet gotten to file transfer stuff - I don't think a solution there yet exist, until the ROMTERM implements some form of FTP.

The silkscreen labels say IO3, etc., not 103... IO, eye oh, as in Input/Output.

Ah, good catch, such a rookie mistake! I can only blame acute lack of sleep. Corrected, and Thank You

So, after issuing the ATA6400 (or whatever port number), I found you can have multiple other systems connect to that port. They'll each have their own client or session number. But then doing "ATA" to answer, you'll get bi-directional only with the last connected client.

For a wired WiModem232 (using the serial-port portions of the card):
ROMTERM (with ANSI emulation enabled) starts dropping characters at 9600 baud during scrolling of the screen.
VTERM (no emulation or screen scrolling, written in cc65) could handle 57600 baud. I don't intend to release VTERM, but just demonstrating that "baud rate" is also a function of the terminal software implementation.


The "network ports" are the same as the "serial ports" in function, but the "network ports" are connected to an internal ESP32-based emulated modem (where that modem can be configured to connect to a modern WiFi-network, hence why they are called "network ports"). For regular classic RS232, you'd use the "serial ports" (including other brand WiModem devices).