RDROYA01@ULKYVX.BITNET.UUCP (05/24/86)
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