[Coco] A hint for NitrOS-9, MPI, and "hard drive" PAK

[Gene Heskett]

On Thursday 19 December 2013 10:43:40 Robert Gault did opine:

> Many years ago I wrote a Basic09 utility to graphically display a floppy
> drive's RPM. Just recently I was booting NitrOS-9 using Roger Taylor's
> Drive Pak and my rpm program crashed NitrOS-9. This is the same code
> that works when booting NitrOS-9 from my scsi hard drive.
> Let's make it very clear that the problem was NOT Roger's Drive PAK.
> Well this bug drove me crazy for about a week. Finally I found out what
> was wrong and I expect that any user of a "drive" PAK regardless of
> make is likely to run into the same bug.
> 
> My Coco system is a Coco3, MPI, two scsi Hard drives, DistoSCII in
> slot4, hard drive interface in slot3, RS-232 PAK in slot2, and a Drive
> Pak in slot1. Recently I've had the slot selector set to #1 and have
> been booting NitrOS-9 from the Drive PAK.
> Well when I booted from the hard drive, the MPI selector was set to
> slot4 which made the floppy controller active. When booting from the
> Drive PAK with the selector in slot1, the floppies had not yet been
> used.
> Hmmm, my program POKEs the floppy controller but if that has not been
> initialized either by hardware or software ....
> 
> Well adding a single line to the Basic09 program let the program work
> correctly regardless of where the MPI selector was set during the boot
> process: SHELL "iniz /d0"
> 
> This is not something you would expect to be required, and I never
> needed it when booting from the scsi hard drives even though both
> kernel and OS9Boot were on the hard drive and not a floppy. I still
> don't understand why the above line is needed as OS-9 does not mess
> with the MPI unless a driver requires it. Still with the recent
> interest in ROM and Drive PAKs, if you have unexpected crashes with
> previously working programs, keep the above in mind.
> 
> Robert

Thanks for the heads up. And I am out of the drivewire business until I can 
get my coco3 fixed, I've apparently blown something in the bitbanger 
circuitry while trying to make inetd actually work.

Most will recall that I've long ago converted my system to run on an old AT 
power supply, which puts a true + and - 12 volts into the com circuitry in 
the coco which usually limps along on +-8 volts or so.  The extra voltage 
seems to have overheated and destroyed something in the bitbanger when it 
was being asked to handle, non-stop because of some sort of an error loop, 
something over 1000 packets a second according to the server, which was 
echoing 10: Unk API back at the coco just as fast, and taking from 10 to 
97% of one core of a phenom 4 core cpu to do it here on this machine.  I 
let it run that way for a couple days, so an overheating related failure is 
quite possible.

And somehow, despite owning 2 copies of the coco3 service manual, I can't 
find either in my "midden heaps" here or in the basement.  They'll turn up 
eventually, but...  I am out of business in the meantime.
 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Win98 error 003: Illegal ASM instruction. If your modem worked properly, 
the
FBI would have been called.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.