[Coco] Utility of large MPI

Dave Philipsen dave at davebiz.com
Wed Feb 3 18:38:40 EST 2016


I know I'm kind of jumping in the middle of this conversation and I 
haven't followed it that closely as it has progressed but I just thought 
I'd interject a thought here for whatever it's worth.

I'm sure, too, that OS9 could handle a large number of serial ports.  A 
couple of things that would lessen the load on the CPU would be a way of 
consolidating multiple ports to one interrupt and a register that would 
indicate which port(s) were causing the interrupt.  Also, a buffered 
UART would probably help quite a bit. If instead of getting an interrupt 
for every single character received the CPU could get an interrupt when 
a buffer  reaches a predefined level, then the interrupt routine could 
suck multiple characters from multiple UARTs with just one interrupt.  
This is the way some modern multi-port serial cards work.

Over the last few months I have been working on an FPGA project and I've 
found that FPGAs lend themselves quite well to the task of serial 
communications.  While I certainly don't consider myself to be an expert 
with FPGAs I can tell you that even a small FPGA could handle the task 
of running multiple UARTs and interfacing them to a CPU.  The current 
design I'm working on has 9 serial ports of different flavors (some xmt 
only, some RS232, some RS485/422, etc.).  Also, since I have control of 
the design I am not constrained to a particular baud rate generator or 
divider that most common UARTs have.  I can generate practically any 
baud rate I want including non-standard ones.  One could even design a 
sort of "DMA-like" interface or a memory-mapped array such that much of 
the overhead of the serial communications could happen in hardware and 
the CPU could simply suck the data out of the array without even using 
interrupts.

Dave Philipsen


On 2/3/2016 1:40 PM, L. Curtis Boyle wrote:
> Paks might be 2, but it can definitely handle more than 2 serial ports. Bill and I had 8 of them running at work in the 1990’s (4 on one board, and two each on another board and the Eliminator).
>
> L. Curtis Boyle
> curtisboyle at sasktel.net
>
>
>
>> On Feb 3, 2016, at 1:30 PM, RETRO Innovations <go4retro at go4retro.com> wrote:
>>
>> On 2/3/2016 9:13 AM, Barry Nelson wrote:
>>>   My thoughts/ramblings.
>>>
>>>   It is fairly easy to implement a SD/MMC interface using SPI if emulating a floppy controller is not required. If floppy emulation is desired then it becomes more complex, however floppy emulation is necessary to run many pieces of software since they access the floppy controller directly. A real time clock is one thing I miss on my CoCo SDC that I had on my original Burke & Burke HD controller. An ethernet interface could be implemented fairly easily in a limited fashion using a serial to wifi chip to allow telnet, or implement the DriveWire protocol on an Arduino and use that to interface to wifi or ethernet. I think that cramming to much functionality into one device could make it too expensive though. The ethernet interface could be a separate device. I wish the CoCo SDC included a realtime clock however. I think a parallel port would be of limited use at best, a second serial interface would be much more useful, though still of limited value.
>>>
>> What about a serial interface that can do 230kbps?
>>
>> And, is compatible with the RS232Pak?
>>
>> How many rs232 paks can OS/9 handle? 2?
>>
>> Jim
>>
>>
>> -- 
>> RETRO Innovations, Contemporary Gear for Classic Systems
>> www.go4retro.com
>> store.go4retro.com
>>
>>
>>
>> -- 
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



More information about the Coco mailing list