A 'retro' BASIC 'system'

[TerryRitchie]

Well, awhile back, I got a wild hair. And well, that hair got me to building an old Z-80 CP/M machine, starting on a second one, and buying an old IBM PS/2 8560. Why you are probably asking... Other than, 'I can', I have no idea. Anyway, the 8560 (80286) is running DOS and I'm setting it up as a file-server via RS-232 to the two Z-80 CP/M machines. I have been writing a bunch of Z-80 assembly code for the CP/M machines to talk to the 8560. I'm writing the file-server code in good 'ol BASIC. Archaic as hell I know, but it is a good challenge....

One thing that does have me sorta stumped is how to have the file-server code 'poll' the open comm ports (old 16bit BASIC only supports two of them), to see if a command has come in. If there is nothing pending, then go to check the next one. Kind of like INKEY$ for a comm port. Of course, I'd love it if there was a 16 bit version of QB64 Phoenix. Anyway, Michelle

Cool project first off! I love doing this kind of retro computing too.

Good 'ol BASIC was always a bear to get working with COM ports correctly. Back in the very early 90's my father wanted a custom program to poll his Heathkit weather station for information. You would send the Heathkit a formatted command and it would return the information based on that command. Sending the information out the COM port with GWbasic and QuickBasic (QBASIC) worked just fine and the Heathkit would respond as expected. But getting the GWBasic and/or QuickBasic timing to work correctly with COM ports (specifically the 8250 UART) was a nightmare (which is what I assume your IBM has). Using the 16550 UART was a bit better, but still had many of the same timing issues. 16550 UARTs were typically found on upgrade serial ISA add-on cards or those ISA 16bit Super I/O cards that had dual COM ports, a printer port, a game port, a floppy port, and either one or two IDE hard drive ports.

I eventually wrote the software in Borland Turbo Pascal 3.01 with no timing issues whatsoever.

I don't believe I've ever seen a GWBasic/QuickBasic program successfully utilize the COM port for direct communication (other than using a connected modem and issuing the appropriate AT commands). If I remember correctly when investigating this back in the day (on CompuServe no less) it was because Microsoft's BASICs had a flaw (or was very poorly written, don't remember for sure) in they way they buffered data coming in to the port. If your program was not monitoring the COM port continuously the buffer would fill and then subsequent data would get missed (or something to that effect).

I know there were many libraries written for QuickBasic that included COM port routines and I'm assuming this is why. Here is a site that contains many of the more common libraries used back in the day:

http://annex.retroarchive.org/cdrom/smsw...index.html

Here is another site but these libraries seem to be geared more toward graphics but worth a look:

https://www.qbasic.net/en/qbasic-downloa...aphics.htm

One of these may be able to help.