Commander X16

I've never coded up flow control for a UART, so after tons of trial and error - I think I finally got it stable with BASTERM (a serial-terminal done using BASLOAD/BASIC for X16).

Whatever I did, I was able to transfer the entire script of Bee Movie in text file form (49KB) in a continuous stream without a single dropped character. The CTS/RTS lights on the little USB/serial adapter seem correct.

Now, it can't be (easily) helped that under BASIC, we can only stream at about 200 Bytes Per Seconds. That's just the price of a constantly interpreted runtime even at 8MHz. But with all the steps now figured out, I'll do a C version next and see if we can ramp up the performance. The point was, even if I up the serial connection to 115200 (in BASIC), I can still transfer the file without error. And I no longer have to play games inserting a delay between characters when sending text files.


The spec sheet wasn't clear to me at all in how to do this. Things got so bad, I even actually turned to ChatGPT! But it wasn't really any help either. After hours of reading and walking the history of the Bell 103 to the TR1402 on up to the 2651 and 8250, and learning about 16x up-sampling and "2 of 3" hits to find start bits, I finally came across a discussion on why the FIFO interrupt hits at 14 (i.e. "almost full") instead of 16. And turns out, the slow-ness of BASIC needs even a bit longer runway!

All I know is I've gone from having to artificially add 16ms delay between characters, to now 0ms delay and use whatever baud rate, and things go without any drops.


So this VERSION3 of BASLOAD will work with both the SERIAL and NETWORK "sides" of the TexElec serial card, but will require CTS/RTS be enabled (which is fairly universal these days, so not an issue). You can keyboard-TYPE stuff without flow control (as most keyboards can't even type much past 300 or 600 baud equivalent, in terms of overall data-rate), but any kind of sustained streaming really needs an assist.


I've also added two other neat features:

- a "port scanning" mode to find which serial ports you have (another trial and error process, but I think I got it figured out)

- a "baud rate finder" feature, so if you forget or just don't know what your device was left at (and it has no display to show it), this can automatically just try them in sequence and find what works.


Hope this helps as a starting reference for some on how to program the serial card. More to come, but this was a helpful step to getting things reliable (and even in BASIC!).

Couple reference images below:

1) Bee Movie script transferred in one continuous stream, all characters accounted for. This was done by connecting across a null-modem cable over to a USB/serial adapter on a modern-day i7-based laptop, then using ZOC from the PC to "Send a Text File" at whatever baud rate (I used 115200). Press F2 at the end of the transfer, and the received bytes count should match the size of the file that was sent.

2) And example of the "port scan" and "find baud" features. Not super exciting to look at, but just showing what they *should* look like. In NETWORK mode, the baud-finder is more automatic since it uses the ZiModem. In the SERIAL mode, whatever is on the other end of the cable will have to manually respond.

Also a note: the WiModem232 from CBMStuff now have a "null-modem mode" - it basically uses Bluetooth between two near-by WiModem232's for a high speed wireless pass-thru. And those WiModem232's have now unlocked the 460K and 921K speeds (I haven't gotten 921K to work reliably yet {will try new cables}, but 230K and 460K are good). Just AT*UPDATE to grab their new firmware.

Some wireless performance notes so far:
And in some other testing (until we get a native data-streamer on X16), here is some wired serial-port performance:
ZModem has some specific timing on ACKs that are difficult to maintain across any wireless connection, but it may be OK for wired connection. Still someday I'd like to re-test with YModem across these wired connections.

And yes, it's not the host system here (286, 486, Pentium) that controls the speed, but more about what specific UART they had and "baud generator". I was using laptops (yes even a 286 laptop) and so wasn't 100% sure. I suspect the 286/486 had an 8250. The Pentium was in an IBM ThinkPad and I can't find specs on what serial-parts it had (but being late 1990s, I'd hope a 16x50 of some sort, its WinXP driver capped at 128,000 baud).

NOTE on 286: I'm thinking the reason the '286 couldn't wire over >5KBps was maybe just the overall integration (12MHz system CPU, then the speed of its hard drive and RAM chips -- in that testing, it was tasked to write the received data to the file system). Just speculating, but worried we might run into a similar wall on the X16.

My daughter happened to be around when I was testing, and suggested I try transferring The Bible across the wire! So, we did - we found a 5MB (megabyte) English version and gave it a go.

Was a good sustained test, and not a single character was dropped even when we set to 460Kbps connection (but it fell apart at 921Kbps, everything got misinterpreted -- but it's across about 16ft of cable). This gives me confidence that the CTS/RTS flow control is reliably working. This was using a C-version of what is fairly equivalent to the BASLOAD version (now attached below).

I couldn't get the find-baud feature working quite right, so that's disabled in this C version. Still an initial reference draft for testing purposes. One other difference is in this C version, I up'd the FIFO threshold from 4 to 8 - but it still didn't work at 14 (probably just overhead of the KERNAL and cc65 runtime and such). Note like most cc65 built things, this PRG you'll have to reboot to get out of - cc65 stuff doesn't gracefully return back to BASIC.

Some other testing: if the data is to be streamed to the display, there is some impact based on the screen size.

So far I don't think any approach is really taking advantage of IER (interrupt enable register). Doing so means inlining a custom ISR to monitor for the interrupt line, then buffering data to service the interrupt (as opposed to just polling on if a new character has arrived).