[Coco] Becker port

[Mark D. Overholser]

On 4/21/19 7:18 PM, RETRO Innovations wrote:
> On 4/21/2019 1:43 PM, Michael Furman wrote:
>> Over the past few years I have been pitching the idea of building a 
>> hardware Becker port for real cocos to the hardware wizards in this 
>> group.  I had even proposed that it would be possible to interface a 
>> Becker port to SPI and that could open up some some possibilities.  
>> For example the ESP8266 does have a SPI access mode which as far as I 
>> know has not been has explored.  It also could be interesting to 
>> interface to a CH375 usb drive adapter. Wiznet Ethernet adapter, SD 
>> card, a lot of possibilities here.
>>

The Idea of the Becker Port has a lot of merit in the Hardware  realm.. 
Each of the above Hardware devices plus other USB devices like the FTDI 
chips...

> 
> I think the hesitation is the nature of the port.  Gary designed the 
> port as a shortcut to expose some peripherals to the CoCo3FPGA so he 
> could continue development in other areas and folks could utilize what 
> he had developed so far.

Necessity is the Mother of Invention...

> I don't know that Gary intended on it being a 
> standard of any kind.
>

Famous Last Words.....


> It has a few issues:
> 
>   * It's nonstandard.  One must use a patched OS to leverage the port.

DriveWire itself falls in this category.

>   * It sits right int he same space as the FDC and related items
>     (CoCoSDC).  Thus, it requires one to use a MPI to enable it to share
>     space with other peripherals.  Not horrid, but makes it a bit harder
>     than if it was i the upper $ff5x range or maybe $ff7x.

A Strange Choice, but Alternate I/O mappings could be designed/allowed..


>   * It doesn't offer much in the way of configuration.  Thus, one must
>     depend on the drivewire protocol (or the protocol that resides on
>     the port) to support any configuration options the endpoint device
>     might need.

Additional I/O Ports could be "acquired" to allow Configuration from the 
CoCo side, Non Standard, but so is everything else CoCo network related..

>   * It does not offer interrupts, as I recall.  Some apps needs an
>     interrupt-driven data transfer.
> 

With "real hardware" Interrupts are an Option....  Non Standard, but......

> Please understand I'm not faulting the port for its initial purpose.  As 
> a designer, I am sure Gary was focusing on other aspects of the CoCo 
> emulation and didn't want to spend a lot of time implementing a bit-bang 
> receiver on the other end of the software serial port, so this was a 
> great way to quickly bolt up a real or virtual serial port so he could 
> spend time elsewhere.
> 

It seems to, "Get the Job Done".....   Thus it has Value and Merritt......



> Jim
> 
> 

MarkO