[Coco] HDB-DOS error - HARD DRIVE NOT FOUND

[gene heskett]

On Tuesday, January 03, 2012 06:22:27 AM Mark Marlette did opine:

> Jim,
> 
> The contacts in the TC^3 are GOLD plated, which helps a great deal on
> the oxidation, the contacts in the MPI are flashed.
> 
> Oxidation can still occur due to dissimilar metals. As has been
> suggested. The contacts on the TC3 will appear BLACK.
> 
> So as Gene said DO NOT SCRUB. I use a white soft eraser, this will clean
> them right up.

Even that, for gold flashed contacts, could be considered a bit rough on 
the gold.  I prefer painters alcohol on a paper towel to be about as brutal 
as I should get, better yet, the toweling can be abrasive so today I would 
use the corner of a "microfiber towel".  It seems to have worked well, and 
a heck of a lot better than Freon TF back in the day when we were convinced 
that stuff was the bee's knees.  I switched to painters alky from ACE Hdwe 
for head cleaning a long time ago, cut the vcr head cleaning intervals from 
1-2 a day, to once every week or so.  Plumb blew me away at the time.  
Pinch rollers also lasted 3 or 4 times longer, only going away if the oil 
migrated to the rubber.

> Make sure to clean the ground tabs as well. So 44 pins of GOLD on the
> TC^3 or ANY Cloud-9 product that has a card edge, value-quality added .

:)
 
> 10 years gold vs 30 days for non gold based card(tin/lead) edge
> connections. If the gold is oxidized. Easy to clean.

I couldn't even get 30 days out of whatever crap the shack used for tin 
plate on the MPI's.  Maddening in fact, so I got out a 32 tpi hacksaw and 
sawed the end off the mpi board, filed it as flat and true as I could, then 
sawed the gold plated fingers off a trashed pc video card, stuck them 
together with a couple teeny drops of superglue long enough to put a dot of 
3% silver solder across the gap in the traces.  That was close to 20 years 
back up the log when my hands were a bit steadier than they are now, zero 
problems since except for the grounding ears.  I've had to clean them up 2 
or 3 times.
 
> The TC^3 is a socketed CPLD, 84 PLCC type, with the proper tool ONLY,
> pull the chip, in a vertical fashion, wipe the pin contacts of the CPLD
> on a clean sheet of paper, IE: NO printing on the paper. So if any
> oxidation comes off on the paper. You will see vertical black lines on
> the paper. Any side to side movement while applying pressure to the
> CPLD will cause the pins to bend. Don't need to tell you this is a
> REALLY bad thing to have happen. So be careful.

Haven't had to, yet.  I do have the puller, 2 of them in fact.

> These are tin based leads with matching contacts in the socket.
> 
> As the RTC is failing as well that indicates a global failure in the
> setup. Could be a failing HD but RTC would / should work as long as the
> correct driver was present on your backup floppy boot disk.
> 
> You could try a simple poke. Now this is from memory and you could check
> the manual for the TC^3 and verify but you want to POKE from DECB the
> data register of your interface, IIRC, $FF74 (default) with the bit
> position of the SCSI ID. So SCSI ID 0 = 1, SCSI ID 1 = 2, etc.....Then
> POKE the strobe typically $FF75,1. The data is irrelevant, the WRITE to
> the reg causes the SCSI bus transaction to occur. Got to love SCSI,
> simplistic are FAST..
> 
> Sorry, not trying to be vague here, as this can be a complex issue,
> troubleshooting over Email is hard. Only a few hours of sleep, actually
> pasted out, due to other CoCo projects that are being completed, PS2
> Keyboard Interface and a new SD card Interface with FATxx support. They
> both make one sleep ALOT less.
> 
> So plug the SD into a FATxx based computer, copy files(.dsk ATM) to the
> device, install in CoCo and it reads the FATxx device. SD/SDHC support
> maybe even SDXC(?), over kill for the CoCo and I currently don't have a
> SDXC device. The CoCo could careless about the FATxx, it thinks it is a
> CoCo formatted device. All the work is performed in the SLAVE uC.
> Current RAW IO on my fastest SD card is 323KBs on the dev station. That
> is over x3 times the theoretical maximum of a CoCo. We are still
> testing this. Amazing what you still can learn AFTER all these years.
> We have had some VERY interesting data / benchmarking numbers during
> the development of Gary's SD interface and our SD card interface
> product spec. Things we never tested before in SuperDriver, amazing
> driver....Now we know EXACTLY what / how to make the fastest transfers
> possible. Thanks Gary for waking us up!!!
> 
> There of course is some configuration issues that need to be worked out
> and this is NOT a product yet, but it is on the development system and
> becoming more capable each day.
> 
> Sigh....need to get ready for my day job.....Wish the CoCo could be full
> time employment with great pay and benefits.... :)
> 
> Regards,
> 
> Mark
> http://www.cloud9tech.com
> 
> 
> 
> ----- Original Message -----
> From: "Jim Hickle" <jlhickle at yahoo.com>
> To: coco at maltedmedia.com
> Sent: Monday, January 2, 2012 10:52:59 PM
> Subject: [Coco] HDB-DOS error - HARD DRIVE NOT FOUND
> 
> Any ideas why HDB-DOS reports "HARD DRIVE NOT FOUND" though all drives
> work with NITROS9?
> 
> TC^3 controller, disks are: 0 - hard drive, 5 - ZIP drive, 6 - CD-ROM
> 
> HDB-DOS and this setup worked okay a couple years ago. Now it doesn't
> find either the hard or ZIP drives. I tried running wizard.bas from a
> new copy of the HDB-DOS disk. Still doesn't find drive, but now it
> gives me 15 seconds to choose to restart, boot os9 and something about
> drives 0 through 3.
> 
> NITROS9 is working, but the weird thing is that at first it wouldn't
> boot, then things started working a bit at a time. This took place over
> about a week.
> 
> - First didn't recognize any SCSI drive.
> - Then it would boot to the hard drive from a very few of my boot
> floppies, worked with the hard disk (/s0) but trying to access the
> others gave error 246 - NOT READY, and then /s0 also gave error 246. -
> Next /s5 and /sc6 could be accessed, but only if system was booted from
> the Superdriver disk. - Eventually all drives work and system boots
> from any of the boot floppies.
> 
> Another odd thing is that only once did the system time get set from the
> clock in the TC^3. Every startup before and after put us back in
> January 1900. This evening it started setting the time, though I hadn't
> changed anything (including the floppy from which it booted).


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
"I have to convince you, or at least snow you ..."
		-- Prof. Romas Aleliunas, CS 435