Re: How do I add firmware to a card?

["mdj" <mdj.mdj@gmail.com>]

Tristan Mumford wrote:

> I see no reason why both the uC and the '811HC can't both be connected to
> the bus. Well, with one or two concessions. That a '245(That's the
> tristating bus buffer right? Headache...) be connected between the '811HS
> and the apple bus.
>
> The tristating for the '245 is controlled by the uC (perhaps also OR'd with
> an address decoder), whereas the direction (R/W) is controlled by the apple
> bus.
>
> The uC is attached directly to the apple bus via it's PSP and a few extra
> lines like a couple of address lines maybe?
>
> At this stage there are a few solutions to the uC <-> 811HS communication.
>
> #1: Cut out the '245 and do a kind of passthrough via the uC. This could
> introduce timing and pin resource issues.
>
> #2: Like #1, but keep the 245 and also have a direct BUS connection (via
> the '245) between apple BUS and '811HS.
> This is the most complex solution, but also my favourite as the uC can
> monitor the bus passively even when disabled waiting for some kind of
> enable signal. It also gets rid of the possible latency issues. However it
> still keeps the possible pincount problem.
>
> #3: Have a second '245 between the uC and the apple bus. Then reuse the PSP
> port in normal IO mode for talking to the uC.

I had envisiaged using a uC that has USB capability built in, obviating
the need for a seperate chip.

In any case, tristating the connection between the two chips seems
overkill - there are afterall 16 I/O locations, so address decoding is
all that's necessary to isolate the two.

It's a good design practice however to buffer connections from any
non-trivial card to the Apple bus. Even if your design is well within
tolerances, the buffering can allow reliable operation in a system
that's marginal due to excessive load from other high-load peripherals
(accelerators, big ram cards, etc), and the additional complexity and
cost of bus transceivers is quite low.

Matt