Hi, it has been long time since I've looked at this but is there a way to get rid of "Xsub Active" (remove xsub from memory) other than doing a cold boot? I guess it isn't hurting much of anything but using up somewhere just below the BIOS.

As far as I can tell, XSUB should unload itself when it finishes with the submit file (and it gets deleted) - "$$$.SUB". But, there were vendors that customized or made their own version of xsub, so this might not be the official version. It could also be that something about your CP/M setup or BIOS version could be preventing it from detecting/deleting "$$$.SUB".

BTW, XSUB resides below the CCP and in order to do that it needs to assume the length of the CCP. If your system is using a custom CCP that is not the standard length of 0800H then you could be running into problems related to that (unless your XSUB was special-built for that system).

So, more information would help.

I'm finding conflicting information about XSUB. The CP/M 2.2 manual says:

The XSUB program remains in memory and prints the message "(xsub active)" on each
warm start operation to indicate its presence. Subsequent SUBMIT command streams
do not require the XSUB, unless an intervening cold start occurs.

Which suggests it can only be unloaded by a cold boot. However, the source code shows that if the $$$.SUB is gone when it tries to read a command/line it will unload itself. But the source code is not clear just when it intercepts the bdos calls and when it passes them through. The answer is probably in the build script, which I have not located. This detail is important in order to know how the CCP behaves when XSUB is active, and whether/when XSUB will detect that $$$.SUB has been deleted.

On Friday, February 3, 2023 at 8:38:06 PM UTC-8, Douglas Miller wrote:
> I'm finding conflicting information about XSUB. The CP/M 2.2 manual says:
>
> The XSUB program remains in memory and prints the message "(xsub active)" on each
> warm start operation to indicate its presence. Subsequent SUBMIT command streams
> do not require the XSUB, unless an intervening cold start occurs.
>
> Which suggests it can only be unloaded by a cold boot. However, the source code shows that if the $$$.SUB is gone when it tries to read a command/line it will unload itself. But the source code is not clear just when it intercepts the bdos calls and when it passes them through. The answer is probably in the build script, which I have not located. This detail is important in order to know how the CCP behaves when XSUB is active, and whether/when XSUB will detect that $$$.SUB has been deleted.

Yes like PIP and other utilities, it was probably written in PL1. I know a cold boot fixes it and it looks like it actually resides in low memory below the CCP and not in high memory near the BIOS.

The mystery continues ...

XSUB was written in assembly, and is not very complicated. It also was not part of the original distribution, but was more of a "hack" added later. There were plenty of disclaimers associated with it. One place you can get the source (there are many) is:

https://github.com/durgadas311/MmsCpm3/blob/master/dist/cpm2/cmd/src/xsub0.asm
https://github.com/durgadas311/MmsCpm3/blob/master/dist/cpm2/cmd/src/xsub1.asm

The two parts are the loader/relocator (0) and the actual RSX (resident system extension) (1). I need to see if I can find the original DRI build scripts to explain some of it.

On Saturday, February 4, 2023 at 12:18:37 AM UTC-5, Jack Fenton wrote:
> On Friday, February 3, 2023 at 8:38:06 PM UTC-8, Douglas Miller wrote:
> > I'm finding conflicting information about XSUB. The CP/M 2.2 manual says:
> >
> > The XSUB program remains in memory and prints the message "(xsub active)" on each
> > warm start operation to indicate its presence. Subsequent SUBMIT command streams
> > do not require the XSUB, unless an intervening cold start occurs.
> >
> > Which suggests it can only be unloaded by a cold boot. However, the source code shows that if the $$$.SUB is gone when it tries to read a command/line it will unload itself. But the source code is not clear just when it intercepts the bdos calls and when it passes them through. The answer is probably in the build script, which I have not located. This detail is important in order to know how the CCP behaves when XSUB is active, and whether/when XSUB will detect that $$$.SUB has been deleted.
> Yes like PIP and other utilities, it was probably written in PL1. I know a cold boot fixes it and it looks like it actually resides in low memory below the CCP and not in high memory near the BIOS.
>
> The mystery continues ...

XSUB goes resident, and stays resident in CP/M 2.2. Digital Research published a patch DEXSUB.COM which
removed XSUB from memory.

On Saturday, February 4, 2023 at 8:00:30 AM UTC-5, fridtjof.ma...@gmail.com wrote:
> On Saturday, February 4, 2023 at 12:18:37 AM UTC-5, Jack Fenton wrote:
> > On Friday, February 3, 2023 at 8:38:06 PM UTC-8, Douglas Miller wrote:
> > > I'm finding conflicting information about XSUB. The CP/M 2.2 manual says:
> > >
> > > The XSUB program remains in memory and prints the message "(xsub active)" on each
> > > warm start operation to indicate its presence. Subsequent SUBMIT command streams
> > > do not require the XSUB, unless an intervening cold start occurs.
> > >
> > > Which suggests it can only be unloaded by a cold boot. However, the source code shows that if the $$$.SUB is gone when it tries to read a command/line it will unload itself. But the source code is not clear just when it intercepts the bdos calls and when it passes them through. The answer is probably in the build script, which I have not located. This detail is important in order to know how the CCP behaves when XSUB is active, and whether/when XSUB will detect that $$$.SUB has been deleted.
> > Yes like PIP and other utilities, it was probably written in PL1. I know a cold boot fixes it and it looks like it actually resides in low memory below the CCP and not in high memory near the BIOS.
> >
> > The mystery continues ...
> XSUB goes resident, and stays resident in CP/M 2.2. Digital Research published a patch DEXSUB.COM which
> removed XSUB from memory.

DEXSUB.COM is 128 bytes (1 record). I do not have the source around, but here is the HEX file. Save as DEXSUB.HEX, then LOAD DEXSUB

:100100000E09110D01CD05000E00C305000D0A28D2
:10011000585355422044454143544956415445445F
:100120003B205E50205455524E4544204F464620B9
:100130004946204F4E292400000000000000000026
:1001400000000000000000000000000000000000AF
:10015000000000000000000000000000000000009F
:10016000000000000000000000000000000000008F
:10017000000000000000000000000000000000007F
:00000001FF

Here's the (disassembled) source to DEXSUB.HEX:
===================; Supposedly, this program de-activates XSUB without cold boot.

CR equ 13
LF equ 10

bdos equ 5

reset equ 0
fprint equ 9

org 0100h

mvi c,fprint
lxi d,deact
call bdos
mvi c,reset
jmp bdos

deact: db CR,LF,'(XSUB DEACTIVATED; ^P TURNED OFF IF ON)$'

end
==================At first glance, it may not be clear how this deactivates XSUB. But if you look at the CP/M 2.2 BDOS you see that BDOS function 0 ("reset") does a direct jump to the BIOS warm boot function (does NOT jump to 0000, which was altered by XSUB). This depends on the BIOS doing a traditional warm boot, where it reloads the BDOS and CCP from disk and (most importantly) regenerates the page 0 jumps, which would effectively eradicate XSUB.

On Friday, February 3, 2023 at 11:20:13 PM UTC-5, Douglas Miller wrote:
> As far as I can tell, XSUB should unload itself when it finishes with the submit file (and it gets deleted) - "$$$.SUB". But, there were vendors that customized or made their own version of xsub, so this might not be the official version. It could also be that something about your CP/M setup or BIOS version could be preventing it from detecting/deleting "$$$.SUB".
>
> BTW, XSUB resides below the CCP and in order to do that it needs to assume the length of the CCP. If your system is using a custom CCP that is not the standard length of 0800H then you could be running into problems related to that (unless your XSUB was special-built for that system).
>
> So, more information would help.

CP/NET came with its own version of XSUB -- XSUBNET. My R loader accomodates "normal" or CP/NET
CCP to determine if it is safe to allow RET to CCP from transient program. See

https://github.com/ratboy666/r
I've wondered if there is an easier approach?!?

On Saturday, February 4, 2023 at 7:18:52 AM UTC-8, fridtjof.ma...@gmail.com wrote:
> On Friday, February 3, 2023 at 11:20:13 PM UTC-5, Douglas Miller wrote:
> > As far as I can tell, XSUB should unload itself when it finishes with the submit file (and it gets deleted) - "$$$.SUB". But, there were vendors that customized or made their own version of xsub, so this might not be the official version. It could also be that something about your CP/M setup or BIOS version could be preventing it from detecting/deleting "$$$.SUB".
> >
> > BTW, XSUB resides below the CCP and in order to do that it needs to assume the length of the CCP. If your system is using a custom CCP that is not the standard length of 0800H then you could be running into problems related to that (unless your XSUB was special-built for that system).
> >
> > So, more information would help.
> CP/NET came with its own version of XSUB -- XSUBNET. My R loader accomodates "normal" or CP/NET
> CCP to determine if it is safe to allow RET to CCP from transient program.. See
>
> https://github.com/ratboy666/r
>
> I've wondered if there is an easier approach?!?

Yes, for me, I will need to figure out how to modify it for my system which is actually running NZ-Com with ZSDos Extensions so the CCP is certainly it's own thing here. NZ-COM uses XSUBZ instead of XSUB and yes, it seems to stay resident. I guess the developers replicated the original issue the Digitial Research originally designed but never patched the update and DR did.

I assembled and ran the program but although it reported XSub no longer active, the process of restoring the vectors is probably different as I'm still getting the message "XSubz Active" with every warm boot. Not a big deal but thanks for all that answered!

I found my issue was I was running a shell on my NZ-Com systems so it was keeping XSUB active. So I have to exit the shell and XSUBZ will properly terminate automatically if there is no $$$.sub in the A0: area on this disk. I was running LSH.

On Saturday, February 4, 2023 at 7:03:19 PM UTC-8, Jack Fenton wrote:
> On Saturday, February 4, 2023 at 7:18:52 AM UTC-8, fridtjof.ma...@gmail.com wrote:
> > On Friday, February 3, 2023 at 11:20:13 PM UTC-5, Douglas Miller wrote:
> > > As far as I can tell, XSUB should unload itself when it finishes with the submit file (and it gets deleted) - "$$$.SUB". But, there were vendors that customized or made their own version of xsub, so this might not be the official version. It could also be that something about your CP/M setup or BIOS version could be preventing it from detecting/deleting "$$$.SUB".
> > >
> > > BTW, XSUB resides below the CCP and in order to do that it needs to assume the length of the CCP. If your system is using a custom CCP that is not the standard length of 0800H then you could be running into problems related to that (unless your XSUB was special-built for that system).
> > >
> > > So, more information would help.
> > CP/NET came with its own version of XSUB -- XSUBNET. My R loader accomodates "normal" or CP/NET
> > CCP to determine if it is safe to allow RET to CCP from transient program. See
> >
> > https://github.com/ratboy666/r
> >
> > I've wondered if there is an easier approach?!?
> Yes, for me, I will need to figure out how to modify it for my system which is actually running NZ-Com with ZSDos Extensions so the CCP is certainly it's own thing here. NZ-COM uses XSUBZ instead of XSUB and yes, it seems to stay resident. I guess the developers replicated the original issue the Digitial Research originally designed but never patched the update and DR did.
>
> I assembled and ran the program but although it reported XSub no longer active, the process of restoring the vectors is probably different as I'm still getting the message "XSubz Active" with every warm boot. Not a big deal but thanks for all that answered!