1. Forum
  2. Usenet
  3. COMP.OS.CPM

  • Xsub Active

    From Jack Fenton@21:1/5 to All on Fri Feb 3 18:38:16 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Douglas Miller@21:1/5 to All on Fri Feb 3 20:20:12 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Douglas Miller@21:1/5 to All on Fri Feb 3 20:38:05 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jack Fenton@21:1/5 to Douglas Miller on Fri Feb 3 21:18:35 2023
    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 ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From fridtjof.martin.weigel@gmail.com@21:1/5 to Jack Fenton on Sat Feb 4 05:00:29 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Douglas Miller@21:1/5 to All on Sat Feb 4 04:51:07 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From fridtjof.martin.weigel@gmail.com@21:1/5 to fridtjof.ma...@gmail.com on Sat Feb 4 05:05:19 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Douglas Miller@21:1/5 to All on Sat Feb 4 05:49:13 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From fridtjof.martin.weigel@gmail.com@21:1/5 to Douglas Miller on Sat Feb 4 07:18:51 2023
    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?!?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jack Fenton@21:1/5 to fridtjof.ma...@gmail.com on Sat Feb 4 19:03:17 2023
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jack Fenton@21:1/5 to Jack Fenton on Sun Feb 5 08:22:50 2023
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jack Fenton@21:1/5 to Lawrence Nelson on Fri Feb 17 20:55:57 2023
    On Friday, February 17, 2023 at 8:26:28 PM UTC-8, Lawrence Nelson wrote:
    On Sunday, February 5, 2023 at 11:22:53 AM UTC-5, Jack Fenton wrote:
    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!
    If you are running NZ-Com why not use a Zsystem tool like ZEX instead of SUBMIT (unless you are having TPA issues)? That way XSUB is no longer an issue. ZEX has a very clean way of handling user console input.

    Lars
    Yes, I'm using ZEX now. Just a bit of a learning curve but I think I've got it worked out. NZ-COM is very nice. I built my own ZCPR3 system back in the 80s after getting Richard Conn's book. NZ-COM improved on the concepts quite a bit. The old
    floppies disks and S100 bus boards were fun to work with but they were very clunky. The mice got to my old system so I had to get rid of it. Now I do everything with either MyZ80 under DOSBOX or under SIMH. It was amazing what could be done with these
    old 8 bit systems. I did a little fixing of wp.com today. Just had the source code but it was for BDSC 1.5 and I couldn't get a good compile so I converted to BDSC 1.6 and got it working. WP.C was a poor mans word processor (not WYSIWYG) that it looks
    like someone put together that could not afford Wordstar. Having lots of fun with this stuff. Also I'm playing around with 22NICE running under DOSBOX-X using 4-DOS. Learning a lot but not quite sure what I will do with all this ancient knowledge.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence Nelson@21:1/5 to Jack Fenton on Fri Feb 17 20:26:27 2023
    On Sunday, February 5, 2023 at 11:22:53 AM UTC-5, Jack Fenton wrote:
    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!

    If you are running NZ-Com why not use a Zsystem tool like ZEX instead of SUBMIT (unless you are having TPA issues)? That way XSUB is no longer an issue. ZEX has a very clean way of handling user console input.

    Lars

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)