[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slot 'extender' dev cable

mdj wrote:

On Feb 2, 2:45 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:



The danger is that it will inevitably alter the risetimes and
falltimes, and add several nanoseconds of delay.  You may wind up
with your design being dependent on these timing modifications,
and being marginal when directly inserted into an Apple II.



Hopefully, several nanoseconds won't bother this design, which is
effectively an asynchronous, buffered two way communications setup -
so there's really only a couple of transceivers and latches, and a
tiny bit of address decode logic.


Odds are that it will work fine.  Just do it!



Done, and she works :-) Now to see if the supply current to the slot
can cope with a charge pump :-)


As long as the current is within specs (and even if it's a little
heavy) it should work.  In addition to the 0.1uF, you will want to use
an electrolytic--maybe a tantalum--cap near the pump to decouple the
current spikes.


Of course, if your timing design is conservative, that wouldn't
be a problem--but it's sometimes hard to know.  ;-(



Well, when the CRO shows up I'll see if I can measure the propagation
delay of the cable. I'll let everyone know.


The cable delay will be just a little more than 7ns per foot,
the speed of light on wires being what it is.  ;-)  The effect
on rise and fall times will be small but perceptible for 2-3 feet
of good quality cable.

I'd recommend liberal use of 0.1uF decoupling capacitors on the
card, since the cable represents a modest amount of inductance.



I always do this as a matter of course - anyone who doesn't is asking
for trouble, IMHO.


Hear, hear.


And the safest thing to do is examine all your critical timings
both with the cable (during development) and witout the cable
(when you think you're done).



Indeed. I beginning to notice that my hardware designs are greatly
affected by my software oriented brain, and in particular my penchant
for generic and reusable modules. In software this leads to needless
indirection, in hardware to small component redundancies. It's ironic
that while I greatly admire minimalism in hardware design, I'm
reticent to practice it myself ;-)


...a classic "optimization" tradeoff.  ;-)

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."