"networking" with BASIC (questions)
Posted: Wed Nov 15, 2023 8:40 am
Understand that we'll all get a proper network solution on the X16 eventually. But this means for one X16 to talk to the one right next to it, I need a router, configure IPs, define some large read/write buffers somewhere ("large" being even the 1500 byte MTU size perhaps).
And rumors are the VIA#2 and IEC won't stay "standard" on follow-on generations of the board (as necessary cost reductions).
Still, even the VIC-20 you could use an OPEN command to get one VIC-20 to talk to another VIC-20. I never had a VIC-20 myself, so maybe OPEN really only worked across a modem-type device? Regardless, "something like that" would be nice on the X16. Ideally, TALK/LISTEN keywords would make it "dead simple" for anyone to do a little across-system communication between X16's. And it seems very niche - but say you just want a simple Checkers Game (or any simple "turn by turn" game, like card games) across a pair of X16's (I'm thinking Backgammon), without requiring both those X16 to have additional hardware.
Even if the data-exchange buffer was a hard coded max 255 bytes, and just 110 baud. Yes, as mentioned, a "proper" network solution will come - and it'll be accessed by "POKE this here and SYS xyz" magic. But as a learning or academic oriented system, the slow simple protocols are very instructive. Or even for when the "network module" becomes available, should we pick/choose an API or sort for BASIC to be able to access it? Could the network module be built, such that it could interoperate with the existing OPEN command?
But from BASIC, I'm not sure how the receive buffer is established. Ignoring all else, ideally a hypothetical approach is like:
LISTEN14,$A000,200
Define a 200 byte buffer at current bank of $A000, listening on a channel 14. This is the "receive" buffer.
TALK 14,"ABCD",50
Send the data "ABCD" on ch14. This is a blocked processed until the data is fully sent, with a timeout maximum of "50" units (jiffies, second, idk..).
Both of the above maybe can be expressed with an OPEN command?
The ZSMKIT is really great (as an example from the audio side of things), but from a complete novice it is quite a bit of a learning curve to getting there to integrate such a thing with BASIC. And while it is the necessary and better way to go, it can be intimidating to new-to-the-system folks if that were the only way to get BASIC to do sound. But we did those very nice FMPLAY and PSG keywords, etc. And that's more in the spirit of BASIC - giving novices a "taste" of computing principles without much concern about speed. Like riding a bicycle before a 650cc motorcycle.
TALK/LISTEN sort of commands weren't in the 1980s BASIC, I think for two reasons: 1) people could barely afford one computer let alone two. 2) At 1mhz, maybe the performance is "just barely there" to handle also monitoring for send/receive of any queued data. But "if we had such commands" it might be interesting to see what kind of turned based games would materialize.
And rumors are the VIA#2 and IEC won't stay "standard" on follow-on generations of the board (as necessary cost reductions).
Still, even the VIC-20 you could use an OPEN command to get one VIC-20 to talk to another VIC-20. I never had a VIC-20 myself, so maybe OPEN really only worked across a modem-type device? Regardless, "something like that" would be nice on the X16. Ideally, TALK/LISTEN keywords would make it "dead simple" for anyone to do a little across-system communication between X16's. And it seems very niche - but say you just want a simple Checkers Game (or any simple "turn by turn" game, like card games) across a pair of X16's (I'm thinking Backgammon), without requiring both those X16 to have additional hardware.
Even if the data-exchange buffer was a hard coded max 255 bytes, and just 110 baud. Yes, as mentioned, a "proper" network solution will come - and it'll be accessed by "POKE this here and SYS xyz" magic. But as a learning or academic oriented system, the slow simple protocols are very instructive. Or even for when the "network module" becomes available, should we pick/choose an API or sort for BASIC to be able to access it? Could the network module be built, such that it could interoperate with the existing OPEN command?
But from BASIC, I'm not sure how the receive buffer is established. Ignoring all else, ideally a hypothetical approach is like:
LISTEN14,$A000,200
Define a 200 byte buffer at current bank of $A000, listening on a channel 14. This is the "receive" buffer.
TALK 14,"ABCD",50
Send the data "ABCD" on ch14. This is a blocked processed until the data is fully sent, with a timeout maximum of "50" units (jiffies, second, idk..).
Both of the above maybe can be expressed with an OPEN command?
The ZSMKIT is really great (as an example from the audio side of things), but from a complete novice it is quite a bit of a learning curve to getting there to integrate such a thing with BASIC. And while it is the necessary and better way to go, it can be intimidating to new-to-the-system folks if that were the only way to get BASIC to do sound. But we did those very nice FMPLAY and PSG keywords, etc. And that's more in the spirit of BASIC - giving novices a "taste" of computing principles without much concern about speed. Like riding a bicycle before a 650cc motorcycle.
TALK/LISTEN sort of commands weren't in the 1980s BASIC, I think for two reasons: 1) people could barely afford one computer let alone two. 2) At 1mhz, maybe the performance is "just barely there" to handle also monitoring for send/receive of any queued data. But "if we had such commands" it might be interesting to see what kind of turned based games would materialize.
