"networking" with BASIC (questions)

[voidstar]

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.

[TomXP411]

So it's true that VIA2 will not be included as standard equipment, but I think David can be convinced to leave the socket If someone built a solution that simply plugs into VIA2.

Likewise, if we have a standard solution (either as a paid upgrade or an included component), then the KERNAL would be upgraded to include the appropriate talk and listen instructions as part of the standard OPEN, INPUT#, PRINT#, and GET# command set.

This is the beauty of the channelized I/O system. In the KERNAL, there are machine language subroutines that do the real work when you run something like OPEN or PRINT# in BASIC. Part of that is a routine that looks at the channel number and dispatches the call to the appropriate device: the screen, tape drive, disk drive, SD card, printer, etc. So adding code to talk to a network device is a matter of adding a number to that list and adding in the code developed by the hardware designer.

So any BASIC code that makes use of networked I/O would simply use OPEN, LOAD, SAVE, PRINT#, INPUT#, and GET# to talk to the network interface.

What we don't have is a COPY command, to do a file copy from one device to another. This would be a useful addition to make it possible to download files directly to SD. Otherwise, you can do a BLOAD to read the file to banked memory, then use a utility to save it to SD.

For example, assume the network device is 32:

LOAD "HTTP://COMMANDERX16.COM/DOWNLOADS/SOMEGAME123.PRG",32,1
This would read the file out from the network device and load it into memory, just like you had it on your own SD card.

or something like this:

LOAD "FILECOPY.PRG" READY. RUN SOURCE FILE: HTTP://COMMANDERX16.COM/DOWNLOADS/SOMEGAME123.PRG DEST DIRECTORY: /DL PROCEED Y/N: Y 100% COPY COMPLETE. READY.

[kelli217]

Nicely chosen device number. Like when TV and movies give IPv4 addresses that contain octets with values greater than 255.