Tarbell DD controller troubleshooting
Rich Cini: ...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 of reset. -------------------- 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. Herb Johnson retrotechnology.com -- Herbert R. Johnson, New Jersey in the USA http://www.retrotechnology.com OR .net
Thanks Herb. I don't mind being lectured a bit :-) I do like throwing these questions out there in case someone has seen it before. Just trying to not re-create the diagnostics wheel as it were. On the one board (#1) I did trace back the chip select on port access and I can see that the board is being selected properly. I need to put the analyzer on the bus buffers to see if the right bit pattern is there. I tried swapping the bus buffers and the floppy chip and there's no change. So, more work to do there. On the other board, "not letting it reset" means that with no TDD inserted the CPU resets and I get the monitor. With it inserted, it doesn't. The #1 board, when inserted, doesn't do this. It's also a recent phenomenon because it worked previously. I guess I'll work back from the reset line and see if it's a shorted buffer chip or something. Always appreciate it, Herb. Sometimes it's just the nudge in the right direction I need. Rich Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: vcf-midatlantic <vcf-midatlantic-bounces@lists.vintagecomputerfederation.org> on behalf of Herb Johnson via vcf-midatlantic <vcf-midatlantic@lists.vintagecomputerfederation.org> Sent: Friday, August 11, 2017 11:45:04 AM To: vcf-midatlantic Cc: Herb Johnson Subject: [vcf-midatlantic] Tarbell DD controller troubleshooting Rich Cini: ...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 of reset. -------------------- 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. Herb Johnson retrotechnology.com -- Herbert R. Johnson, New Jersey in the USA http://www.retrotechnology.com OR .net
Rich Cini said "not letting it reset" means the S-100 system works without the board, but doesn't work with the non-working board inserted. Rich, I think that means the board crashes the bus, not necessarily that it screws up reset. On the "no data on select" board; I think you are telling me, you confirmed chip-select on say the FDC chip is properly enabled. But you say changing bus buffer chips and the FDC chip doesn't change your results. It may be inconsistent bus timing. S-100 bus timing depends on the specific CPU board (and front panel) versus the board under test. If you've never used a Tarbell DD board in that S-100 box, and two don't work, and the data you read is a persistent incorrect value; mismatched timing is a possibility. S-100 control/status signals also depend on chip delays and even R/C circuits which age poorly. I see your point in using a bus analyzer, to look at all relevant signals. I look at signals with a 2-channel oscope, one channel often on the bus clock or other timing source. For home-gamers reading this: note that I'm saying that S-100 is not a single, consistent "standard". S-100 cards don't all play well with each other. I claim three flavors of "S-100" bus, on my Web site; early Altair, S-100 MITS/Altair/others, and IEEE-696. "It worked previously" points to corrosion problems too. Look for TI brand chips which have blackened pins; they seem to fail after a period of recent use. I chased this down with my Ithaca Intersystems repair. That happens across S-100 cards with socketed chips. http://www.retrotechnology.com/restore/ith_feb16_repairs.html Rich, contact me privately for further discussion. Chasing chips is boring for many people; they can read your results on your Web pages. herb -- Herbert R. Johnson, New Jersey in the USA http://www.retrotechnology.com OR .net preserve, recover, restore 1970's computing email: hjohnson AT retrotechnology DOT com or try later herbjohnson AT retrotechnology DOT info
participants (2)
-
Herb Johnson -
Richard Cini