[Coco] **JUNK** Re: 2022-06-10 Update on my CoCoIOn Ethernet Card Project

[rick ulland]

Right, the 16550 was a little piggy but you could do 4 in the 
'traditional' I/O space cause the last byte was scratch register- seven 
actual. Fast232 used ff60/68/70/78 and never stomped a GIME using Randy 
Wilson's s16550 driver + Bruce's xmode.  We beat it pretty good BITD.

The new problem, CoCoIO v1 might throw 5 IRQ from 1 slot. There could be 
2 of them. We could fungineer 3 of them. Lines at D Poll? Prolly.

-rick


On 6/11/2022 5:51 PM, gene heskett wrote:
> On Saturday, 11 June 2022 17:05:48 EDT RETRO Innovations wrote:
>> On 6/11/2022 11:27 AM, gene heskett wrote:
>>> On Saturday, 11 June 2022 09:32:29 EDT Bill Gunshannon via Coco
> wrote:
>>>> On 6/10/22 15:52, Michael Furman via Coco wrote:
>>> flaws, but I don't know how serious you could label them but its just
>>> one of the reasons I have constant railed at the lack of adequate
>>> hardware decoding in the coco's hardware. there is room from $FF03
>>> to FF1F for 7 more pieces of i/o hardware, another 7 could be
>>> shoehorned in from $FF23 to $FF3F, most disk controllers use 2 of
>>> the 4 byte blocks, the various clocks tend to use the $FF50 to $FF5F
>>> blocks, so we start at $FF60, with 3 useable blocks because the mpi
>>> poisons the last block by useing $FF7F, and the coco3 gime steals
>>> the next 16 bytes.  So we are screwed out of at least 14 i/o devices
>>> by the choice of decodeing to only $20 byte wide chip selects in the
>>> coco's.
>>>
>>> Any body who wants to expand that must first add the additional chip
>>> select decoding in the coco itself. That will involve trace cuts and
>>> such, and I've been reluctant to go down that path for obvious
>>> reasons.
>> Actually, none of that hardware modification is needed to use those
>> ranges in the IO space.
>>
>> On the cartridge port (or in an MPI), simply watch for those ranges,
>> decode them to your peripheral, and asset the !SLENB line while doing
>> so.  Asserting SLENB will deactivate both PIAs and the cartridge ROM,
>> removing them completely from the memory map.
>>
>> SLENB also de-activates the internal ROM from use as well.  I have not
>> tried it, but it looks like one could make a special DECB cart that
>> asserts SLENB when the internal ROM space is accessed (doing so I think
>> would require tracking the memory map selection).  In this use case,
>> the OS on the cart would be used instead of the one in the machine.
>> I'm not sure how useful that is, but I can see an external cartridge
>> asserting SLENB to override the IRQ/FIRQ/RESET/etc. vectors at the top
>> of the ROM space to redirect into a extenal ROM address space or
>> something.
> Are you sure, I've been under the impression that the irq vectors at the
> top of the address space, were not switched out under any conditions
> including all ram.  Have I read the docs wrong since '85?
>
>> As well, understand that the MPI offers 4 different $ff40-5f IO slots,
>> because it routes SCS to a single slot.  Thus, you can 64 IO registers
>> in the $40-5f space assuming 1 IO device does not need more than 16 of
>> those specific IO registers.  This can also be combined with the
>> ff60-7e range and the above mentioned $ff03-1f and $ff23-3f
>>
>>> The 16550 cannot be addressed adequatly in the 4 byte imterface
>>> structure defined in os9, it needs an i/o space 16 bytes wide.
>> Actually, it only needs 8 IO locations.  The 16550 uses the same
>> register structure as the 8250, and the 8250 used 8 IO registers.
>>
>> Jim
>
> Cheers, Gene Heskett.