Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!noah.arc.CDN!kenw
From: kenw@noah.arc.CDN (Ken Wallewein)
Newsgroups: comp.os.cpm
Subject: Debugging a new BIOS
Message-ID: <581*kenw@noah.arc.cdn>
Date: 26 Jan 88 17:13:00 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 48


  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