[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