[Coco] 6 Chip ^809 Computer -> Kipper SBC

RETRO Innovations go4retro at go4retro.com
Sun Mar 15 09:26:36 EDT 2015


On 3/15/2015 6:12 AM, Gene Heskett wrote:
>
> I assume that the Coco 3 will not let you map out $ff00-$ffff using
> the GIME memory mapper (if so, then you'd not be able to get back to
> the registers to map them back in).  So, I think this is all you need
> to do to get your new PIA in place.
> I don't think you can use the gime for that. IIRC reading someplace where
> the top page was inviolate.
And I assume that as well.  Thus, you can be guaranteed that no 
additional logic is needed
> The delays in the additional decoding will allow some narrow noise to get
> to the /CS lines on the OEM PIA's.  Because of that, we'd have to get
> our address from a point in parallel with the on board 138's inputs.
The onboard '138 is already delayed by SAM (or GIME, in a Coco3), so 
you're fine.  However, modern logic can get you 7ns guarantees, so 
that'd be my recommendation.
>   
>
> Some google searching says the 74HC138 is 1/10 the power, and about 16ns
> delay.  Also available as HCT, rated at the same 16ns.  Thats 4ns slower
> that the LS family. Now if /SLENB was held down and had to wait on the
> extra 138 function being non-Y0 to release it, that 4ns is a shrug.  But
> somehow we have to leave the other PIA alone for $FF20, so it gets more
> complex.  I think...  Too early here.  Way too early.  But certainly
> food for thought.
74F or ALS or a half dozen other families get you the speed you need, 
but I really don't think it's an issue.  If you look at the 6821 data 
sheet, it's output buffers don't come online until quite a ways after 
the start of the cycle, so the chance two devices will be on the bus is 
minimal.

Jim


More information about the Coco mailing list