🚀 go-pugleaf

I just finished disassembling cpmlib and have discovered that the _initexc
(offset $4718) initializes all vectors from 2-25, 32, 33, and 36-47.  It
does this by setting a counter = 2 placing that counter in d1, placing an
address in d2, setting d0=$16, and calling trap #3.  It then increments the
counter in d1, the address in d2, and calls trap #3.  In the first step,
this process continues until d1=$18.  Then d1 is set to $20 (trap #0
vector), d1 is compared to $22 and $23.  On not equal trap #3 is again
called to reset this vector.  d1 is again incremented, compared to $22 and
$23, and again on not equal the vector is reset.  This incrementing and
setting continues until all traps are reset to the default handler.  The
_initexc is called by _warmboo everytime the system is reset.  So this means
that it is not the bios which is slacking off in its job but the bdos itself
which resets the two trap vectors (trap #0 and trap #1) guaranteed not to
*ever* be reset by the bdos (see section 4.6.1 of the _CP/M-68K Programmer's
Guide_).  This means that resident system extensions, as described by DRI,
cannot work.  Isn't this surely a bug?

                           rdroya01@ulkyvx.bitnet