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

[gene heskett]

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.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis