External RS-232 Interface, storage, and second screen.

[TomXP411]

1 hour ago, Scott Robison said:

I've not been thinking about this as long as you have, but it seems to me (now that I'm doing the math for the first time) that 50 KB/sec is 400000 bps, which means one bit every 20 clock cycles. I'm assuming this isn't interrupt driven. One bit per 20 cycles seems doable if all you want to do is read bits, but assuming you want to do something useful with the bits, that just seems (again, based on intuition and not necessarily logic) that is just not achievable.

Also, what you’re describing is exactly the reason I thought to build an external UART in the first place. 

The reason I chose to do this with a microcontroller is that anyone can build this with just DuPont wires and an Arduino or Raspberry Pi. But I may yet end up switching to a solution using a hardware bit shifter. That will require PCB or breadboard work, though, which defeats the purpose of this design. 

[Scott Robison]

Maybe I'm just not thinking about it. I understand why you are using an external device as the UART, but to get the X16 to read the data, it still has to process the data at some point. Is it trying to bit bang, or is it trying to do a byte at a time? My timing assumed one bit at a time, but if the interface you were attempting could do 8 bits parallel between the pi and the X16, then suddenly we're talking about something different. I was assuming (probalby due to lack of critical reading) that this serial interface was bit oriented, thus needing to read a bit every 20 cycles, but if the bits are bunched up into a byte that you read as one atomic unit on the X16 then you're up to 160 cycles per byte.

Anyway, not trying to be critical, just jumping late into a discussion trying to understand. Even when I worked for the PCBoard company back in the day, I didn't worry about serial interfaces, that was another programmers job. When it comes to the X16, I'm thinking of Commodore software bitbanged serial port or IEC, bit at a time style serial which is probably not the method you're using.

[TomXP411]

1 hour ago, Scott Robison said:

Maybe I'm just not thinking about it. I understand why you are using an external device as the UART, but to get the X16 to read the data, it still has to process the data at some point. Is it trying to bit bang, or is it trying to do a byte at a time? My timing assumed one bit at a time, but if the interface you were attempting could do 8 bits parallel between the pi and the X16, then suddenly we're talking about something different. I was assuming (probalby due to lack of critical reading) that this serial interface was bit oriented, thus needing to read a bit every 20 cycles, but if the bits are bunched up into a byte that you read as one atomic unit on the X16 then you're up to 160 cycles per byte.



Anyway, not trying to be critical, just jumping late into a discussion trying to understand. Even when I worked for the PCBoard company back in the day, I didn't worry about serial interfaces, that was another programmers job. When it comes to the X16, I'm thinking of Commodore software bitbanged serial port or IEC, bit at a time style serial which is probably not the method you're using.

I will check the OP again and make sure it’s clear, but my interface is an 8 bit parallel interface, loosely based around bidirectional SPI (which uses the same wire for data in both directions). With additional control wires for clock, data direction, signaling the buffer status, and for invoking command mode. 

** edit: clarified in the post, but please visit the link in the OP and read the draft specification. 

[Scott Robison]

13 minutes ago, TomXP411 said:

I will check the OP again and make sure it’s clear, but my interface is an 8 bit parallel interface, loosely based around bidirectional SPI (which uses the same wire for data in both directions). With additional control wires for clock, data direction, signaling the buffer status, and for invoking command mode. 

Forgive me ... these threads stretch out over such a period of time that I missed earlier context. When I think Commodore I just naturally go to bit banging serial bit delivery and don't do my due diligence.

[TomXP411]

Just now, Scott Robison said:

Forgive me ... these threads stretch out over such a period of time that I missed earlier context. When I think Commodore I just naturally go to bit banging serial bit delivery and don't do my due diligence.

?  No problem. It's understandable. I did add some specifics to the original post, but there's also a link to a Google Doc that explains the whole thing in more detail. 

 

[BruceMcF]

5 hours ago, Scott Robison said:

Forgive me ... these threads stretch out over such a period of time that I missed earlier context. When I think Commodore I just naturally go to bit banging serial bit delivery and don't do my due diligence.

Notice that the CX16 User Port has all of one VIA parallel port A and most of it's parallel port B, so there's a lot more flexibility in setting up a half duplex parallel port on the User Port.

[msx]

Hi there! I'm very interested in connecting the X16 to internet, expecially 1) using cheap off the shelf parts (esp32 or similar) and 2) with the most ease in code.

Also, i think it sould be important to have some sort of "unified interface" so that programs can take advantage of whatever kind of device is available without knowing the details. If a channel works as a modem, then it could have its own custom AT commands and behaviours, probably breaking the abstraction one way or another.

So i was wondering if it would be possible to create a "tcp socket" device, where the filename is an IP address. It would need to be managed by the microcontroller, but it shouldn't be hard at all. It would work like this:

OPEN 1, 20, 0, "142.250.184.100:80"

OPEN 2, 20, 0, "api.server.com:555"

The microcontroller will open the socket connection and associate it with the file number. Subsequent read or write will be routed to the socket, and errors can be mapped to the usual FILE_NOT_FOUND, DEVICE NOT PRESENT etc.

The only problem is that filenames are 16 character long AFAIK, so they can hold any ip address (15 chars top) but not the port. Using the secondary address as port is a problem becouse i think it's at most 128. Now an address+port is 6 bytes so it CAN be fitted in 16 char, for example using hex (C345A100:00C1), but it's pretty unelegant. It would require a conversion routine which is annoying. Perhaps someone has some suggestion (if the whole proposal makes any sense :P). 

What i'm afraid most is that different hardwares will require different setups, forcin programs to have vendor-specific code to deal with all the possible modems. That's one aspect of the 8 bit era that i'm NOT eager to revive ?

 

(I hope it's not OT but this was the most fitting post i could find)

[ZeroByte]

I think a better way would be to have a channel for socket creation / teardown, and then a file for each open socket with some arbitrary string as the socket identifier.

so in the control channel, you send some string like cmd:proto:host:port (e.g. O:T:www.example.com:80 or O:U:tftp.example.com:69)

The device would reply with the "filename" of the socket, or an error code if unable to create the socket.

commands could be O, C, L for Open, Close, and Listen. Listen would be a way to run a server on the X16 locally. Each new incoming connection would generate a new socket file and an IRQ.

 

[TomXP411]

You’re really talking about new firmware for an ESP32 or perhaps an Ethernet controller. That’s probably a topic for a new thread, since this thread is specifically about developing a serial port multiplexer, not a dedicated network interface. 

[ZeroByte]

Ah - that's what I get for just reading the latest post and not going back to the beginning and catching up.