[comp.os.cpm] Stack in the BIOS, and the SB180 format

RALPH@UHHEPG.BITNET (05/03/88)

Date:  2-MAY-1988 19:56:16.05
From: Ralph Becker-Szendy RALPH AT UHHEPG
To:   0::"info-cpm@simtel20.arpa",RALPH
Subj: Stack in the BIOS, and the SB180 format
Hi

I am writing my own BIOS. So far it has been quite easy (thanks to a real
smart disk controller), and the BIOS has been structurally simple.

Now the BIOS is growing (for example interrupt-driven buffered IO, and several
switchable disk drivers) and getting more complicated; that involves several
layers of subroutines in regular BIOS routines and interrupt service routines.

So far I simply ignored the problem of having enough space on the stack when
the BIOS is called; the bios will just never need more than 4 bytes for itself
(two levels of subroutines), so I just assume that whenever the BIOS is called
(regardless whether from the BDOS or from an user program) there are at least 4
bytes left on the stack, and never ran into a problem. Now I may have to use up
to 30 or 40 bytes on the stack, and I'm getting scared. So, here is the
question: Is there any generally accepted rule about how much stackspace should
be available when the BIOS gets called ? If no, what can one usually get away
with ? What are your experiences ???

I know that I can keep a seperate BIOS-internal stack, and switch stacks
whenever the BIOS is called. That is awkward (for example, it gets confusing
when one BIOS routine calls another one, or even worse, an interrupt-service
routine calls a BIOS routine !) and time-consuming (that is particularly bad
for interrupt-service routines).

Second part of the question (quite unrelated to part one): Could a kind soul
tell me about the details of the 5 1/4" disk formats usually used by:
- Heathkit H89
- Byte/Micromint SB180
- Kaypro portable.
I want ALL THE DETAILS (SD/DD, # tracks, # sectors, sector length, SS/DS,
side bits set on which side, directory length, sector skewing).

As usual, answers directly to me, i'll write a summary.

Thanks a lot in advance !

Ralph Becker-Szendy                                     RALPH@UHHEPG.BITNET
University of Hawaii / High Energy Physics Group              (808)948-7391
Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822

cwwj@ur-tut (Clarence Wilkerson) (05/04/88)

I will send you some turbo pascal fragments documenting
the h89 formats. If you have the actual DD h89 disk, all this
information is written out on the first sector of the disk
in a manner similar to the BPB of an MSDOS disk. You will
probably not be able to read a disk you wrote elsewhere on
an H89 unless this block is present. The default is SD SS.
The other gotcha is that the 177x controller used on a H89
is not completely compatible with the 765 clone on the SB180.
The incompatiblity is said to arise from the index hole and how
soon data can appear after the hole. According to this theory,
the 177X controllers can write sooner after the index, and the 765
attempting to read this disk cannot recover from the registering the
passage of the index hole to get the first sector.
  Depending on your bios, the index hole may not need to be observed,
so one solution that works sometimes on a PC is to cover the index
hole of the disk. I changed the format program on my H89 to write
more filler bytes before the first sector of data..
 In the other direction, I have observed no problems except that 
pc disks are formatted with no physical skew factor, so the h89
reads them more slowly than its own which have a physical slew
which is invisible after the format.
Clarence Wilkerson