Posts: 11
Threads: 3
Joined: Apr 2022
Reputation:
0
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
Posts: 597
Threads: 110
Joined: Apr 2022
Reputation:
34
08-12-2023, 08:59 PM
(This post was last modified: 08-12-2023, 10:10 PM by CharlieJV.)
(08-12-2023, 08:52 PM)Michelle Wrote: 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
I can't offer any kind of help (I'd likely give you negative returns), but just wanted to say that sounds ultra-cool. Love to read about that kind of stuff.
Posts: 1,272
Threads: 119
Joined: Apr 2022
Reputation:
100
(08-12-2023, 08:52 PM)Michelle Wrote: 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.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 1,586
Threads: 59
Joined: Jul 2022
Reputation:
52
Hello "Meek-el-eh", although your join date precedes mine, welcome to the forums.
As close as QB64 could ever get to being 16-bit was the founder, Galleon once begged to make it compatible with Windows98. The only guy that could really tell about it further than I could is (was) our administrator Pete but he hasn't been on the forum this year yet.
Not even Freebasic could pull the stunt of being 16-bit. There is an MS-DOS "port" but even that is 32-bit and requires too much trickery for most people to put up with if they aren't completely filled with machinery a bit newer than what you revealed you have in your keep. :/
Posts: 11
Threads: 3
Joined: Apr 2022
Reputation:
0
Actually, my biggest issue is how to poll the two ports to see if there is a request to do something. Something akin to INKEY$ but for the comm port. A$=INPUT$(#1) would/should work great once there is actual data to be input. But the first byte to even indicate stuff is coming. INKEY$ would work, but it doesn't seem to work with comm ports; at least to my understanding. And the A$=INPUT$(#1) would just sit there waiting, and never check the other comm port. Well, at least what I gather from reading through the books I have. I am hoping to get some time tomorrow to test out some things.... We shall see....
Posts: 1,586
Threads: 59
Joined: Jul 2022
Reputation:
52
Can't I/O ports be used for this sort of thing?
But there's a big catch. Must use 16-bit compiler like BASCOM or Microsoft BASIC, or a competing product like Power BASIC. QB64's authors only cared about catching manipulations of the EGA "bit planes" and a couple other things. They are emulated because M$ changed everything in WindowsXP 32-bit, threw out the ports system, and also disallowed access to the ancient BIOS and MS-DOS interrupts.
What I figure is, use the I/O port to read the status. If one is extra sure there is data waiting, then use INPUT$(). (shrugs)
I should have studied better what was going on with RS-232 and other stuff with serial and parallel ports way back then.
Posts: 11
Threads: 3
Joined: Apr 2022
Reputation:
0
Testing the ports will probably be the answer. From the old BASIC-80 manual for the CP/M version of Microsoft BASIC, the INP command limited you to only 256 ports, which would not work on an IBM PC. But GW-BASIC and BASICA allow for reading up to 65,536 ports. I will need to dig through the Dual Async Adapter/A Tech Ref to find out what ports I need to query to see if there is data available.
Posts: 11
Threads: 3
Joined: Apr 2022
Reputation:
0
After a bit of testing, it appears that doing an INP(1021) for com1 and INP(765) for com2 is probably going to do it. Without any communications to the ports, the baseline value coming from those ports is 96 to indicate both 1 to indicate the transmit side is ready and waiting. If I send a character to the port from my dumb terminal, the value goes to 97 to indicate there is a character in the receive buffer.
With that, I can AND what is in the Line Status Register with '1' and if it is true then go read the actual command being transmitted to the computer. This might just work!
Posts: 11
Threads: 3
Joined: Apr 2022
Reputation:
0
One thing I did find out is that once you 'OPEN' a comm port via BASIC, you will get nothing back if you try to do an INP if the status port. At least when using GW-BASIC. I guess that is logical, but I wanted to test it anyway.
As a side note, I know these posts aren't QB64 related, but I'm not aware of any active 'old school' BASIC Forums. I apologize.... 
Posts: 1,586
Threads: 59
Joined: Jul 2022
Reputation:
52
This might be out of topic, and too heavy for the head and the pockets:
https://www.arduino.cc/
At least to create a go-between. Find out how to make the Z-80 machine respond on board. Then try the other end of the board with the IBM PS/2.
It doesn't change the fact that there will be no 16-bit version of QB64. But QB64 could be involved somewhere with the Arduino block.
Probably Charlie was going to propose something like this. There has to be a way to make ancient equipment connect, to save them a bit longer from the junkyard.
|
