Here is a collection of my thought and findings from the last few years. I write my software for the Spectrum using Z88DK in C leveraging libraries to support a range of Spectrum setups. I can not claim credit for the techniques, I learned from Thomas Cherryhomes with his IRATA.online project. ESP WiFi modems are appearing for retro computers with offers to connect your old system to the internet. These are not the only option, and some Bus connected devices can connect to the "internet". So cutting through the noise are there some common abstractions that can define "standards" or at least common terminology? All these devices are aiming to provide access to TCP/IP networks, thus enabling internet access for software. Our first point needs to be these adapters are providing SOFTWARE access to the internet. Unless the device has some built-in ROM or Software delivering an application, additional software is required. So you need to know what software is available or compatible with the hardware device. Networking is dependent on both hardware and software; you need both. The hardware provides an API for software applications to use. In terms of modern networking, this would be the Socket API. BUS based network interfaces might adopt a socket API, for example, Spectranet. These devices are what could be considered more like a network card. There is a newer approach to this API using AT Commands, which has come about with retro computing a hardware approach to bridge old modem-based software over the internet in place of phonelines. The rising confusion with the "WiFi network adapter", is they obfuscate the Serial port connection and AT Commands. So lets clear the clutter and identify what these devices are. Initially, the intent was to connect to BBS systems using old Serial Terminal software. However, the approach can connect to any remote TCP/IP socket. Therefore it is possible for other uses beyond BBS systems and terminals, assuming suitable software. "Serial Internet AT (WiFi) Modem", connects to the serial port (of a computer). They realise an API based on the AT Hayes modem command set. Software applications communicate over a serial port with the device, sending AT commands to make TCP/IP socket connections. Offloading the TCP/IP stack to the "modem"; thus, the software only needs to implement the application protocol (FTP/Gopher/HTTP). "Network adapter", connects to the system BUS/IO subsystem and implements a Socket based API. Assuming here the TCP/IP stack has been offloaded to the Network adapter (Wiznet chip for example). The application only needs to implement the protocol required. Given most retro systems have only a few Kilobytes of memory, running a full TCP/IP stack on the target computer is less than desirable! What about a BUS connected device that implements AT Commands? Entirely possible, someone that likes the AT command approach to network programming. If the hardware does not use a UART or similar serial interface between the BUS and TCP/IP stack, then it would be a true hybrid. Else, if there is some form of Serial hardware, then from a software standpoint the solution is just another Serial port device and AT Modem. It is essential software developers understand the two paradigms at play here. If you plan on writing a network application, you can design the software in such a way as to make it possible to support them all. Here is a short list of points to consider when network programming or hardware building. Abstract the Transmit and Recieve routines so they can work with Socket or AT command APIs. Does the target system have more than one type of serial port? Are you support one or all with your AT Command based application. If the serial port is software-defined, then handshaking might be required for the hardware. Often serial connections with microcontroller and alike use three-wire solutions; this is not always true! Network protocols handle connections differently regard to the connection being continuous or open/closed. Telnet sessions are an example of streaming; a link is opened and held open. HTTP opens a connection data is transfered, the connection closes. Being aware of this is vital for two reasons. AT Command software will need to frequently "re-dial" connections to fetch data. Socket API software will need to empty the receive buffer when reading data. Partially reading a receive buffer when a socket closes can lose data. Data loss like this could apply to some AT Command approaches too. Encryption or lack of is a big thing to remember. To date, there are no solutions for connecting to encrypted services. HTTPS access from a retro computer is not possible. Similarly, we need to remember any applications built are vulnerable to being sniffed. Serial Internet AT Modem solutions has the advantage here in being an architecture that could quickly implement SSL. ESP chips are not the only way to create these devices.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorMe, slightly crazy engineer type. Generalist in nature, hardware or software with nonspecialist skill set. Archives
January 2020
Categories
All
|