kenw@noah.arc.CDN (Ken Wallewein) (01/27/88)
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. The system has two eight-inch single sided Shugart 801s (I _think_ they're 801s). It can use physical sector sizes from 128 to 1024 bytes. It has a 4 Mhz Z80, a 64k dynamic RAM board, a 4-port serial board, and a 4-drive disk controller using a WD 1793. All boards from CCS. It started out as plain- vanilla CPM 2.2 with the BIOS from CCS. The new BIOS is written and installed; I even added ZCPR2 (I know, it's old, but it's simple, and all I want is command search paths; my brother is not very "computer literate"). However, there is a rather serious bug. Whenever the system does a warm boot while logged into B: drive (there are only A: and B:), when it goes to relog B: it sends the heads on B: on a colision course for the spindle. Needless to say, this is noisy, nerve-wracking, and rather hard on head alignments! :-(. This happens consistently when using a SSSD disk on B:; I think it happens on others formats, but not so consistently. Rebuilding the system without ZCPR2 doesn't help. In fact, I think this problem actually existed _before_ I made the changes, and that I just made it more obvious. Now we get to the _real_ problem: how do I debug it?!?!? I've tried DDT, ZSID, Z8E, ZDEBUG17, and something known as ZBUG (does anybody have any documentation on it? It's nice!). The problems it that all of these debuggers appear to use the BDOS to do their I/O, and this problem involves BDOS calls to the BIOS. Needless to say, this does bad things to the BDOS's internal stack. ZDEBUG17 might work, but I can't get it to ride through a warm boot :-(. Another complication is that, in this case, the CCP (or it's replacement) must be intact to handle the warm boot. I've whipped up a little assembler routine to fudge address 0005, etc., to keep the debuggers from overwriting it, so at least that's not a problem. I doubt if anyone could diagnose this problem from the description, unless it's common to CCS disk controllers. However, I'd really like to know how I'm going to track it down! If anyone knows of a debugger that uses BIOS calls only, I'd appreciate the information. And what the heck could be happening while relogging B: drive on a warm boot, that doesn't happen on A: drive, or on initial logging of B: drive? If you think this is tough, I've got a VAX problem... :-) /kenw
abp@j.cc.purdue.edu (Jeffrey J Wieland) (02/01/88)
In the documentation for Z8E, the author describes how to patch it to use user supplied routines for i/o. It should be relatively easy to either use BIOS calls or to perform the i/o yourself (via the Z80 ports), if you have a BIOS listing. Jeff Wieland abp@j.cc.purdue.edu
andrew@frip.gwd.tek.com (Andrew Klossner) (02/02/88)
[]
"The problems it that all of these debuggers appear to use the
BDOS to do their I/O, and this problem involves BDOS calls to
the BIOS. Needless to say, this does bad things to the BDOS's
internal stack ... Another complication is that, in this case,
the CCP (or it's replacement) must be intact to handle the warm
boot. I've whipped up a little assembler routine to fudge
address 0005, etc., to keep the debuggers from overwriting it,
so at least that's not a problem."
As long as that assembler routine is already there, teach it to
intercept the BDOS call, check to see if it's a terminal I/O request,
and let it through if not; if it is terminal I/O, do it directly (call
the BIOS or write directly to the UART).
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]wwg@brambo.UUCP (Warren W. Gay) (02/02/88)
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."