Jump to content
TomXP411

External RS-232 Interface design

Recommended Posts

Posted (edited)

Those are the sorts of things I don't know about.  Thank you.

 

 

 

Edited by rje

Share this post


Link to post
Share on other sites
Posted (edited)

Hi, I was also looking for possible options of network connectivity for X16 and stumbled upon this thread.

I read the design doc and very liked it.

I'm not very knowledgeable with hardware, but I would want to share some of my thoughts on the software part of it:

I would make the transport layer between x16 and the external card as abstract and general purpose as possible:
* I would make port numbers purely logical (e.g. 0-255), not bound to any particular physical ports on the external card (e.g. Arduino).
* I would not require to provide parameters like transfer rate from X16, if it's not strictly required for establishing connection between the X16 and the card.
* x16 should not need to know how actual transport between the external card and outside world is implemented (HTTP, USB, COM etc.).

As a programmer I would want:

To have an external card (Arduino or Raspberry) with modern Linux and modern networking stack (Wi-Fi, Ethernet, HTTPS, OpenSSL etc.), and ability to write a server app using any modern programming language (C++, Go, Python etc.) which would listen for incoming connections from the X16, and make requests to outside services using modern protocols (HTTP, SSH, FTP, SMB etc.) with all encryption, authentication, compression etc.

The choice of logical ports between X16 and the server implementation on external card would not be predefined and up to the server implementation, application level protocol also could depend on particular server implementation.

Examples of use cases:

Raspberry Pi with Wi-Fi, connected to internet.

A server application which listens to logical port 100 from X16, as input it accepts URL string, as output it returns binary stream of downloaded file.
On X16, code just opens the port, sends URL strings, reads the incoming byte stream. X16 doesn't know how the actual protocol implemented.

A server application on port 110 provides a lightweight binary protocol for remote file management to X16 (list files, read file, write file, copy file, delete file etc.), and works as a client for SMB or FTP protocols, and makes it possible to access network files from X16.

A server application on port 112 provides primitive telnet protocol to X16 which is being converted to secure SSH connection to outside system.

A server application on port 115 could bridge a game in X16 with the game server in internet.

Edited by kostrse

Share this post


Link to post
Share on other sites
Posted (edited)

Those are some good notes. I'll address them:

13 hours ago, kostrse said:

I would make the transport layer between x16 and the external card as abstract and general purpose as possible

The connection is currently broken down into an Address and a Data channel. The Address channel is used to select the active port and to control serial parameters. The Data channel is completely transparent, so you can shove through whatever data you want - text, binary data, or even data meant to be UDP or TCP payloads. 

13 hours ago, kostrse said:

* I would make port numbers purely logical (e.g. 0-255), not bound to any particular physical ports on the external card (e.g. Arduino).

Port numbers are entirely at the discretion of the external hardware (ie Arduino). There's nothing in the design or specification that requires port 1 to be the USB port or port 2 to be a serial port or anything like that. If you use an Arduino Mega, there is plenty of room to have several ports of different types, including USB, RS-232, SPI, and TTL serial to a network interface. 

i do NOT plan to directly support a network transceiver, so this should not be used for TCP/UDP data. Instead, you would need to build a smart device externally to handle that. The preferred method at this point would be an ESP32 or ESP8266 running an AT firmware (aka a modem emulator.)

13 hours ago, kostrse said:

* I would not require to provide parameters like transfer rate from X16, if it's not strictly required for establishing connection between the X16 and the card

The purpose of this interface is to connect to RS-232 devices. Other layer 1 protocols, such as I2C or SPI are compatible enough at the data layer, but you should still send the RS-232 initialization sequence, to ensure that if the connection is to an RS-232 device, the UART is configured correctly. Having said that, I expect there to be a default connection speed, which will be 9600,n,8,1 in my reference driver. 

Having said that - SPI connections will simply ignore the parameters that don't make sense for it. SPI does not have a "baud rate", but it does have a maximum speed cap, so I plan to add some basic SPI parameters into the protocol later. I'll probably also work in some way to set the I2C address to allow sub-addressing on an I2C connection. 

13 hours ago, kostrse said:

To have an external card (Arduino or Raspberry) with modern Linux and modern networking stack (Wi-Fi, Ethernet, HTTPS, OpenSSL etc.), and ability to write a server app using any modern programming language (C++, Go, Python etc.) which would listen for incoming connections from the X16, and make requests to outside services using modern protocols (HTTP, SSH, FTP, SMB etc.) with all encryption, authentication, compression etc.

The choice of logical ports between X16 and the server implementation on external card would not be predefined and up to the server implementation, application level protocol also could depend on particular server implementation.

That's a perfectly reasonable use case. In fact, it's one of my expected use cases - using a Pi as an external UART is exactly the kind of this this standard is designed to for.

However, the reference firmware will run on an Arduino Mega, which has 4 serial ports. What you do with it is up to you, but 0-3 should generally be used for RS-232. Use other port numbers as you wish. The important thing is that your software should allow the user to set any port number, and the software should always have the ability to set all of the standard parameters, to allow for any Layer 1 transport to the communication device. (ie: a terminal program needs to set not only baud rate, but should also be able to set SPI speed and I2C channel, in the event someone makes a network modem that runs over SPI.) Never expect that a communication device will run on just the Layer 1 you expect.

If you want to support additional standard protocols and port numbers, it's reasonable to create a list of suggested port numbers for specific purposes. For now, I want to keep that loose, and if you always allow the user to pick a port number and communication parameters, there should be no conflicts with this use case.

 

Edited by TomXP411
  • Like 1

Share this post


Link to post
Share on other sites

As a side note, I'm moving away from the idea of patching the KERNAL to use device 2, and I plan to remove all of that from the documentation (or add it as an addendum.) 

Instead, the reference driver will be accessed via a SYS command, with a jump table at $410. 

$410: Read status from device (updates the buffer counts)
$413: Send a byte 
$416: Read a byte
$419: Send a parameter to the device (parameter in $403, data in $404-40F)
$41C: Read a parameter from the device
$41F: Send a BASIC string
$422: Receive data into a BASIC string

This routine should be fairly small, and I expect to provide binaries assembled for various places in the $400-800 block and at $A000. 

 

Share this post


Link to post
Share on other sites
58 minutes ago, TomXP411 said:

As a side note, I'm moving away from the idea of patching the KERNAL to use device 2, and I plan to remove all of that from the documentation (or add it as an addendum.) 

Instead, the reference driver will be accessed via a SYS command, with a jump table at $410. 

$410: Read status from device (updates the buffer counts)
$413: Send a byte 
$416: Read a byte
$419: Send a parameter to the device (parameter in $403, data in $404-40F)
$41C: Read a parameter from the device
$41F: Send a BASIC string
$422: Receive data into a BASIC string

This routine should be fairly small, and I expect to provide binaries assembled for various places in the $400-800 block and at $A000.

Why $403-$424? Has somebody yelled dibs on $400-$401?

Share this post


Link to post
Share on other sites
6 hours ago, BruceMcF said:

Why $403-$424? Has somebody yelled dibs on $400-$401?

0400 to 0402 is likely a JMP vector. 

Share this post


Link to post
Share on other sites
7 hours ago, BruceMcF said:

Why $403-$424? Has somebody yelled dibs on $400-$401?

I’m using $400-40F for data and control structures. To use the interface from BASIC, you poke values into the $400-40F range, then SYS the routine. 

  • Like 2

Share this post


Link to post
Share on other sites

So out of curiosity, why not just design an expansion card and stick it straight on the data / address bus? There is plenty of space in the IO area for the chip and something like the SC28L92 only has 4 registers lines so technically it could fit into half of one of the available expansion ranges. 

This is the chip I chose for my project and I intend on using it with the X16 as well once I get mine 🙂

Share this post


Link to post
Share on other sites

Because I want something anyone can assemble with off the shelf parts in a few minutes. My design uses no proprietary parts and can use just about any commonly available microcontroller board. 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use