Re: On attempting to make the 3.5" floppy adaptor to work...

["Michael J. Mahon" <mjmahon@aol.com>]

Tristan Mumford wrote:
> Michael J. Mahon wrote:
>
>
> > Tristan Mumford wrote:
> >
> > > Michael J. Mahon wrote:
> > >
> > >
> > >
> > > > Tristan Mumford wrote:
> >
> > <snip>
> >
> > > > > I also managed to turn an 18f452 into a nice heating element. When I did
> > > > > the reshuffling I managed to short the -12v to one of its IO lines,
> > > > > which would have resulted in a nice 17v potential difference inside the
> > > > > chip. Or is it 16v. Doesn't matter anyway. Now I have something to throw
> > > > > at the neighbours cats.
> > > >
> > > > Aaaack.  ;-(
> > >
> > >
> > > I believe I measured a whopping 12ohm resistance between Vdd and Vss.
> > >
> > > Paranoia now has me keeping my finger on top of the uC the whole time
> > > it's on feeling for a temperature difference.
> >
> > Been there--even slightly burned my finger!  ;-)
>
>
> I've fried too many chips outside the kitchen for my liking. Speaking of
> which I actually did the silly thing of trying my teeth on the uC after it
> burnt out. I did this to confirm my suspicion that I had destroyed a
> ceramic packaged one.
>
> Did you burn your finger on the ROM or something different?

Yep, the ROM.  From its rate of heating, I'd say it was dissipating
about two watts, or 400mA from the +5 line!  That would be about 12
Ohms...hmmm...perhaps another universal physical constant!  ;-)

> > > > Just the other day, I found an Apple ][+ ROM (the E8 ROM) that is
> > > > a near short from +5v to ground--it also makes a nice heating element!
> > > >
> > > > This is the first time I've found a ROM with this failure mode.
> > >
> > >
> > > Was the extent of the failure isolated to the ROM? I'm surprised too that
> > > it died. Electronics don't come much more robust than a ROM.
> >
> > I was amazed.  That was the only failure, though it may have induced
> > the power supply to fail (it doesn't work).
>
>
> Yeah, that was probably it. My powersupply was taken out by a cap with a
> snapped lead shorting out something on my Z80 soft card. Whatever it
> shorted out it cooked the transistor near the Z80. I still need to replace
> this to see if it can be made to work again.
>
> Now I have the slightly more robust PC supply. Only slightly though. There
> are some things the pictures don't show that I'm truly ashamed of.

In this case, "more robust" translates to "doesn't just smoke
components, they catch fire!"

There are some advantages to a supply that current-limits at around
twice the usual load.  ;-)

> > > Glad you think so. Do you think that using a soft encoding method like I
> > > attempted is wrong? I have my doubts about it. It's just it was easy to
> > > modify my board to try it so I did.
> > >
> > > To do it I disconnected my erroneous connection of the write signal from
> > > the hex inverter and connected it to the uC. I also connected a pin of
> > > the uC to the write enable pin so I could get feedback on when it wants
> > > to write.
> >
> > How fast can the controller poll the input and produce an output?
> > The write signal should be on time within a fraction of a microsecond.
>
>
> Hmm, lets see. The uC is running at 12MHz. It can complete pretty much any
> instruction in 4 clock pulses. I think things like branches may be 6 or 8
> though. I don't remember. So best case of pure polling we have it hammering
> around in a single instruction loop. This would be because all memory in
> the PIC micros are registers, and IIRC all can be used directly in opcodes.
> Ie memory-memory architecture, but because there are no bus overheads
> because it's just a register file, and Harvard architecture so data and
> code access are done concurrently on separate busses... What was I saying?
> Best case it could realistically do it maybe 2 million times a second. I
> don't think there is any overhead for reading IO bytes. There is for analog
> pins though.
>
> My only concern is with the small delay introduced wiping out some data
> afterwards.

The real issue is providing a *consistent* small delay.  It sounds like
your polling loop will introduce a write jitter of about half a
microsecond, or one disk controller state machine clock.  That should
be tolerated by the read state machine, but it will degrade timing
margins slightly.

-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."