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

[Ed Minchau]

6 hours ago, BruceMcF said:

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

0400 to 0402 is likely a JMP vector. 

[TomXP411]

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. 

[jbaum81]

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 ?

[TomXP411]

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. 

[TomXP411]

Good news! I just found a GIthub repo of various chip emulators, including 6502 and 6522 emulations

https://github.com/floooh/chips

I'll probably load this up on a Raspberry Pi or two, which should give me a good starting point for testing. 

In fact, the more I think about it, the more I like the Raspberry Pi for this kind of interface. The Pi Zero is cheap, and it can support wireless and even act as an external storage device and second screen! So with a simple file manager, you could copy files onto the computer from USB or the network.

 

[TomXP411]

Update: I played around with two Pis today, and I have got them communicating. I started out using Python to test communication and make sure I could get data moving back and forth. That works fairly well, although I'm limited to around 100 characters per second that way. Python is just too slow to do a reliable job. 

I've also done some simulated SIO testing on the CX16 emulator, and I get roughly 50KB/sec that way. (kilobytes, not kilobits.) Quite frankly, that's faster than the internal SD card reader, and I'm giving more thought to turning this into a general purpose I/O module, with disk storage, network connectivity, and serial port access all in one unit. 

 

 

 

[TomXP411]

Well, some more experimentation and research leaves me disappointed. I can only seem to get a few KB/sec out of the Pi using the GPIO pins in C. I can reliably read the pins at low data rates, but as soon as I get  the rates up to where I want them to be (50KBbytes/s or more), the software just won't drive the pins fast enough on the transmit side, and I keep dropping clocks on the receive side. 

So I'm going to go back to using an Arduino or a Pi Pico as a server/SPI slave. Fortunately, I've got MCU boards coming out my ears right now: Adruino Mega, Grand Central Teensy 3.5, Teensy 4.1, and Pi Pico.

The Pico is promising, as it has multiple channels that can be used for hardware UARTS, including SPI modes. If that works reliably as a slave and client at the same time, I can still use it as an external SD card reader and comm hub...

[Scott Robison]

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.

I know, that's basically what you said (that it isn't achievable by saying it isn't working). I'm just trying to do the math to see if I understand.

With a real 16550A or some such, with a 16 byte buffer that can signal an interrupt at some point so that you only have to process a batch of data (say 8 bytes) you would only have to read every 1280 cycles, but having to bit bang puts a lot more demands on the system.

 

[kelli217]

4 hours ago, TomXP411 said:

I can only seem to get a few KB/sec out of the Pi using the GPIO pins in C. I can reliably read the pins at low data rates, but as soon as I get  the rates up to where I want them to be (50KBbytes/s or more), the software just won't drive the pins fast enough on the transmit side, and I keep dropping clocks on the receive side. 

Yeah, I believe @Lorin Millsap mentioned something about that limitation of using the high-level libraries quite some time ago.

[TomXP411]

19 minutes 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.



I know, that's basically what you said (that it isn't achievable by saying it isn't working). I'm just trying to do the math to see if I understand.



With a real 16550A or some such, with a 16 byte buffer that can signal an interrupt at some point so that you only have to process a batch of data (say 8 bytes) you would only have to read every 1280 cycles, but having to bit bang puts a lot more demands on the system.



 

50kBps is easily achievable with an 8 bit parallel SPI interface. Remember this interface is parallel, so that’s one baud unit per 160 clock cycles, or roughly 32 instructions per baud unit. That should be eminently achievable on the Commander side when the Commander is driving the clock. 



the issue seems to be that the software that multiplexes the GPIO pins on the Pi is just not optimized for speed, and since the hardware transceiver can’t act as an SPI slave, the Pi is no longer in consideration for this use.