neals@tekigm.UUCP (Neal Sedell) (08/01/86)
I have come across an error in RS's OS-9 technical manual. While writing
a ramdisk driver a while ago, I added a trace printout for each driver call.
When I tried using the regular OS-9 FORMAT command on it the PUTSTA trace
gave a function code of $12, which was (is) wrong. I hadn't implemented
any PUTSTA functions anyway so I just dismissed it and wrote my own ramdisk
format utility. Recently I picked up "The Complete Rainbow Guide to OS-9"
to see if there was anything I had been missing before I write a SASI hard
disk driver. It turns out that there is... In RS's manual section on RBF
drivers, it describes the call to PUTSTA as having the A register set to
the function code. Looking over the TCRGTOS9 driver, you have to get it
from the B register that was pushed onto the stack, as in:
LDX PD.RGS,Y
LDA R$B,X
Looking at CCDisk, it does likewise. For more confusion, SCF type
drivers (in TCRGTOS9 and CCIO) apparently do have the function code
in the A register when PUTSTA is called. I may go back and rewrite
the ramdisk driver to include the write track function so it works
with the conventional FORMAT command. In the mean time, the hard
disk driver is the first order of business.
BTW, looking through NewDisk, a call to GETSTA returns OK (carry clear)
when in fact it does nothing. I recall a discussion here a year ago or
more by James Jones regarding pipes that mentioned that if you don't
implement a function it should be flagged as an error. I therefore
propose that GETSTA be changed to:
COMB
LDB #E$UnkSVC
RTS
Speaking of NewDisk, has it been fixed for version 2.00.00? I see
the conditional assembly, but vaguely remember some talk about it
not working. What is it's state? I have the source on a disk at
home but don't want to go to the trouble of bringing it and 2.00.00
for nothing.
YABTW, I have planned on writing the driver so that the disk can be
partitioned, since I have a couple of systems I wanted to use it with.
I figure one less sector won't make any difference. Also, I had
originally intended for it to work with either a Xebec 1410 or Adaptec
4000 SASI controller, but now that I've seen the Adaptec specs, my
minimal host adapter doesn't meet all the specs (especially select
and reset hold times, and I have serious doubts about transfer
timeout of 250mS, given that OS9 is multitasking). Any comments
or requests? Speak up now, August 11 will hopefully be too late.
Neal Sedell
Disclaimer: Who, me? Disassemble RS software? Only for educational purposes!
--
{zehntel | uw-beaver | reed | hp-pcd | hplabs | decvax}!tektronix!tekigm!neals