Path: utzoo!lsuc!ncrcan!brambo!wwg
From: wwg@brambo.UUCP (Warren W. Gay)
Newsgroups: comp.os.cpm
Subject: Re: Debugging a new BIOS
Message-ID: <252@brambo.UUCP>
Date: 2 Feb 88 04:31:04 GMT
References: <581*kenw@noah.arc.cdn>
Reply-To: wwg@brambo.UUCP (Warren W. Gay)
Organization: Bramalea Software Inc., Bramalea, Ont.
Lines: 41

In article <581*kenw@noah.arc.cdn> kenw@noah.arc.CDN (Ken Wallewein) writes:
>
>  I trying to upgrade the BIOS of my brother's California Computer Systems
>S100 system, and I've run into a bit of a snag. 
>etc... when it goes to relog
>B: it sends the heads on B: on a colision course for the spindle. Needless ...
>... Now we get to the _real_ problem: how do I debug it?!?!? ...

What I suggest is that you judicously place some calls to print "progress"
messages in various "suspect" portions of your BIOS, and re-assemble. If you
can use another serial port to dump this info (like a line printer), you might
be able to trace the approxiamte area of the problem.  From there, you might
be able to zero in on it.  Dumping to another serial port makes it easier to
get through a session without wading thru messages within the session.
 
For debugging nasty things like that I like to put tests in like
if "this data item doesn't look normal" then
    print "data item such & such is corrupt" /* hex dump even better... */
in various places in addition to the 
    "print ? BIOS call entered"
    "print ? section x of BIOS call..."
    "print ? BIOS call returning..."
     etc...
messages sprinkled about.

However if this does not help, you'll have to provide more sophisticated
debug traces with print calls etc.  You might want to add a "print_hex_byte"
to your bios to provide another tool to test with.  I see no choice, but to
wade into the code up to your eye balls.

Ever tried to trace a vectored interupt for serial i/o using Zilogs SIO
chips?  Turned out to be hardware after 3 months of pulling my hair out;
The serial i/o chips just needed a 150 ohm resister tied to +5 V on the 
system clock pin!  Without that, they worked most of the time, but not
all of the time!  Had to resort to similar methods to the above, the exception
being that I could not just dump serial data any time I wished (within the
interrupt routine).
-- 
Warren W. Gay - Bramalea Software Systems Inc...!utgpu!telly \ !brambo!wwg
                ...!{uunet!mnetor, watmath!utai}!lsuc!ncrcan /
                "Life is a compromise.  So lets be #pragma-tic."