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

[rick ulland]

Forgot to say, a buffer is ~1500 bytes.  Worried about reach vs grasp, etc.

-rick


On 6/11/2022 8:34 PM, rick ulland wrote:
> 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.