Commander X16

I would think that if someone wanted to use UDP based packets that the way to expose them to the X16 from a smart device would be to treat them exactly like a TCP stream, but each datagram would be prefixed with a length. At least for reading inbound datagrams. Writing datagrams could work the same way, it just doesn't feel right going the other direction based on first thoughts.

On 7/10/2021 at 10:15 PM, lamb-duh said:

I think tcp is overkill for most applications. I might be wrong, but I suspect most of what people will want to do is talk directly between two x16s, or between an x16 and a server that expects to be talking to an x16 (not to, for example, an imap mail server or an http server). What if instead of tcp, we had some kind of virtual phone exchange? (which would itself run on top of either tcp or udp)



I haven't thought through all the details, but here's a sketch of how it might work: 



 

IDK, this seems way overengineered. You're inventing a new network over the internet and with a SPOF. And i don't think TCP is overkill, it's just the simplest of stream connection. It's the safest bet to connect to anything. The server doesn't have to be made for x16, you could connect to any telnet, mud, or bbs already available.

 

Now i think we can all agree that x16 will NOT be handling IP and TCP itself, the hardware device will. It will present a simple end to end connection to the x16 that can send and read data as with any serial connection. Obviously configuring the router is outside the scope of this thread ? as @Scott Robison said we should all be able to do it, or ask for help, anyway it's not business of the x16 or the expansion network device.

So it looks like we have 3 possible implementation:

• 
  An expansion card, in this case the device can interact with the bus and so a memory mapped solution could be feasible, as @Zerobyte mentioned.
  


• 
  User port device. As i understand, this is an end to end connection, so at the most basic setup, this will enable only one connection to be open at a time (which could be enought actually). So in some way the x16 have to tell the device where to connect to. AT commands are a possible solution.
  


• 
  IEC device. This offer a more standardized way to access the connection as it could be mapped to already existing x16 API. Data transfer speed will be pretty slow
  

This is about outgoing connections. For incoming one, some server socket logic needs to be implemented. If there's support for more than one socket, it should be doable. The server logic will reside on the hardware device and the x16 can query wether there are new connections waiting.

1 hour ago, msx said:

... So it looks like we have 3 possible implementation:

• 
  An expansion card, in this case the device can interact with the bus and so a memory mapped solution could be feasible, as @Zerobyte mentioned.
  


• 
  User port device. As i understand, this is an end to end connection, so at the most basic setup, this will enable only one connection to be open at a time (which could be enought actually). So in some way the x16 have to tell the device where to connect to. AT commands are a possible solution.
  


• 
  IEC device. This offer a more standardized way to access the connection as it could be mapped to already existing x16 API. Data transfer speed will be pretty slow
  

This is about outgoing connections. For incoming one, some server socket logic needs to be implemented. If there's support for more than one socket, it should be doable. The server logic will reside on the hardware device and the x16 can query wether there are new connections waiting.

It seems like given that bit-banged serial will be available, it would be possible to just use a serial to WiFi converter, either something like this (Amazon listing), or like this (PiModem project page).

If going for a bespoke solution, perhaps it would be because it offers some features or some price/performance point that already existing solutions do not offer.

 

1 hour ago, BruceMcF said:

like this (Amazon listing)

... also links to the PiModem page ?

7 hours ago, msx said:

This is about outgoing connections. For incoming one, some server socket logic needs to be implemented. If there's support for more than one socket, it should be doable. The server logic will reside on the hardware device and the x16 can query wether there are new connections waiting.

I think the server process should reside on the X16 itself, or at least be possible to do such a thing. Opening an inbound socket is essentially the same as opening an outbound one, except that you tell the network stack to listen, and on which interface and port, and there would need to be an IRQ for whenever a new socket opens.

So basically this device should cover OSI layers 1-4.

On 7/13/2021 at 7:24 PM, JimmyDansbo said:

... also links to the PiModem page ?

Copy and paste glitch. I'll fix it when grades are in.

On 7/13/2021 at 3:02 AM, BruceMcF said:

It seems like given that bit-banged serial will be available, it would be possible to just use a serial to WiFi converter, either something like this (Amazon listing), or like this (PiModem project page).



If going for a bespoke solution, perhaps it would be because it offers some features or some price/performance point that already existing solutions do not offer.



 

Here's an example of what I think you meant: https://www.amazon.com/Ethernet-Converter-Adapter-Support-USR-TCP232-410S/dp/B07FM5WQKD



This an RS-232 to Ethernet Terminal Adapter. (These devices are not modems, nor do they pretend to be, though. For one, they do not have the Hayes-friendly ATD command. Instead, you have to issue a more complicated AT+ command string to make a TCP or Telnet connection.)



What surprises me is how so many retro enthusiasts don't realize this is already a thing. These terminal adapters can already do everything mentioned on this thread, and all we need to do is provide software on the Commander side to interact with the TA. 

It's worth noting that TCPSer is actually impersonating a modem, rather than a terminal adapter, so it is not a multi-channel device and can't handle multiple TCP streams, nor can it do UDP at all (that I'm aware of.) The AT+ firmware on terminal adapters is a little different in that it CAN do those things... but it's not as simple as just "Connect to server and send data." You have to request to read data from the TA's buffer and request to send using AT+ commands. 

It's actually pretty straightforward to write something like this for the Raspberry Pi... I might go ahead and write something myself, since I've put the parallel interface stuff on the shelf for a bit. 

8 hours ago, TomXP411 said:

Here's an example of what I think you meant: https://www.amazon.com/Ethernet-Converter-Adapter-Support-USR-TCP232-410S/dp/B07FM5WQKD 

That's the exact listing I had in the tab that I failed to copy the link from, $50, though this one is RS232C only and $23.

Not to be confused with one of these, which is just a plug adapter to let you extend an RS-232C interface using cheaper network cable.

9 hours ago, BruceMcF said:

That's the exact listing I had in the tab that I failed to copy the link from, $50, though this one is RS232C only and $23.



Not to be confused with one of these, which is just a plug adapter to let you extend an RS-232C interface using cheaper network cable.

That’s actually a perfect example. I have two of those with WiFi radios that I purchased to work with my Altairduino… only to find that the level converter chips in the Altairduino doesn’t work, due to a design defect on the adapter board. Since then, I have found that RunCPM is a lot more effective for running CP/M software, so the only thing the AD does now is blink for me.

Anyway, at $23, this is more cost effective than a Raspberry Pi, and while you still need a level converter, a TTL to RS-232 level converter is actually easier to get and use than the 5v - 3.3v we’d need for a Pi. (I’m pretty sure the User port will be running at 5V.)

 

5 minutes ago, TomXP411 said:

That’s actually a perfect example. I have two of those with WiFi radios that I purchased to work with my Altairduino… only to find that the level converter chips in the Altairduino doesn’t work, due to a design defect on the adapter board. Since then, I have found that RunCPM is a lot more effective for running CP/M software, so the only thing the AD does now is blink for me.



Anyway, at $23, this is more cost effective than a Raspberry Pi, and while you still need a level converter, a TTL to RS-232 level converter is actually easier to get and use than the 5v - 3.3v we’d need for a Pi. (I’m pretty sure the User port will be running at 5V.)



 

If it's industrial equipment, it might be 5v tolerant, since voltage drops with longer cable runs ... it would be fortunate if that was true, so you only have to convert voltage on the input lines.