[vcf-midatlantic] Tarbell DD controller troubleshooting
hjohnson at retrotechnology.info
Fri Aug 11 11:45:04 EDT 2017
...Tarbell DD controller for a machine I’m restoring and it doesn’t
respond to any manual communications with the board using the test
routines in the manual. ...Since it’s jumper-selectable for port ranges,
I’ve tried both ranges. [Says he may replace the 8208 bus transcievers -
what's a substitute?]
..A second Tarbell DD controller which won’t allow the CPU to come out
Pardon me for brief do-this suggestions, to save reading time and for
clarity. And hello to my good friend and S-100 colleague Rich Cini.
On the "can't address" board. Use an oscilloscope to look at the
chip-enable signals for the floppy controller chip and data latches. See
if the chips are being addressed when you send the IO read or write.
Then trace backward to the I/O decoding and the bus pins. Or, start from
the bus and trace "forward", your choice. Find the fault.
There's many kinds of faults which can occur on any 1970's S-100 board.
A common one is corroded IC pins and sockets. "Corrosion" comes in many
flavors, as has been discussed in the S-100 community. "Replacing the
chips" may simply clean the bad connection or remove the corroded chip;
for awhile. Look for Ithaca Intersystems on my Web site for details.
On the "stuck at reset" board. I don't know what that means. For this
you may need a "divide and conquer" strategy. Presuming your board has
socketed chips, remove the chips that access the S-100 bus, one by one;
until the board no longer "sticks" the bus. When that happens, look at
the schematic to see what function that last removed chip performed.
Then add chips back in reverse order, to confirm the "stuck". By
definition you MIGHT start with any chips on the bus reset lines.
But "stuck at reset" is a vague symptom - your alternative strategy is
to look (o-scope) at the reset lines on the bus, see if they are
actually asserted and trace back on the Tarbell board to see what's
asserting them. If those lines are OK at the bus, then you can try to
determine the exact problem by bus signals. Maybe the data lines are
jammed up, maybe it's the status or control lines, or address lines.
Rich, I have a general argument for use of diagnostic methods - like the
ones I've mentioned - over asking around for someone's list of known
failures. (shrug) but you wanted some directions and not a lecture. My
Web site has lots of examples of how I diagnose S-100 problems. Do the
same things happen on one brand and model of S-100 board? Yeah, if the
design is the problem, or if part-producers had a problem (poor sockets,
chips that rust up). Otherwise, I think an oscilloscope and a schematic,
and a working S-100 system, are your best friends. They will get you in
the ballpark on some board. Then you can ask for specific help, or
figure out the problem.
Herbert R. Johnson, New Jersey in the USA
http://www.retrotechnology.com OR .net
More information about the vcf-midatlantic