Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: SUBMIT.COM behaviour

  1. #11

    Default

    Code:
                  A>ddt submit.com
                  DDT V2.2
                  NEXT PC
                  0600 0100
                  -d5bb
                  05BB 00 24 24 24 20 .$$$
                  05C0 20 20 20 20 53 55 42 00 00 00 1A 1A 1A 1A 1A 1A   SUB...
                  05D0 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A ........
    
                  -
                  -s5bb
                  05BB 00 1
                  05BC 24 .
                  -g0
                  A>save 5 submit.com
    So if I put 3 at 05BBh instead of 1 it uses C: as the default drive and works nicely!

    Hooray!

    At the moment, my system has the default drive hardcoded (it's a .EQU called DDRIVE in my source code) and I can't see any reason why a user might want to change this. So I will distribute it with a patched version of SUBMIT (in other words, I'm not going to set up an address in RAM to hold the DDRIVE value so it can be configured).

    I've already implemented C: as the default drive so I don't need to apply the "boot from drive other than A" patch. I have all of CP/M 2.2 (BDOS/CCP) as Z80 source (from Grant Searle's Multicomp CP/M source pack) so it is easy to alter.
    Last edited by JonB; March 15th, 2019 at 08:48 AM.

  2. #12

    Default

    Alternatively, build a CCP that fixes this by always using the current default drive for $$$.SUB, instead of drive A:. That way, whatever you use as the default drive will work for submit files. Not sure what other CCPs are available, the one I have for MMS CP/M on the H89 would probably work. Let me know if you want to pursue that. Note, the '00' in the $$$.SUB FCB actually means "create $$$.SUB on the *default* drive, not A:. Remember, the first byte of an FCB is '00' for default drive, '01' for A:, ... '10' for P:.

  3. #13

    Default

    Interesting - I'll look into it. I assume it's CCP that writes the $$$.SUB then..?

    By the way, default drive as far as my BDOS is concerned is 0 (A. Meaning by that, the drive the system expects to be able to use; the boot drive.

    Unless you are referring to the active (currently logged) drive - and then, if the submit job changes drives, it'll fail (or so I thought, when I considered this scheme).

    Correct me if I'm wrong - I'm keen to learn!

  4. #14

    Default

    Some quick CP/M terms... "logged in" is what happens when a drive is first accessed (since warm boot, etc). You can have many/all drives logged in at once. Warm boot (on CP/M 2.2) resets all drives to logged off. Then there is the current default drive. This is set using BDOS function 14 and is used wherever an FCB has '00' in the first byte (and other times). This is reset to A: on warm boot (BDOS function 13 - reset disk system). The CCP also has the concept of current drive, which is traditionally stored in location 0004h and persists over warm boots. This is what CCP shows in your prompt.

    So, the problem you are seeing is that SUBMIT creates $$$.SUB on the current default drive, which will be the same as what is in location 0004h (indirectly, via CCP passing it to BDOS function 14). But the version of CCP you have uses a "hack" to detect $$$.SUB, by depending on a legacy "feature" of BDOS function 13 to return whether or not it saw a file starting with '$' on drive A:. The fixed version of CCP that I have (this is probably the way others fixed it, too) will ignore the return value of BDOS function 13 and just check for $$$.SUB on the current default drive (which it just setup from location 0004h). This way, it finds $$$.SUB where SUBMIT.COM most likely created it.

    It's an imperfect scheme however you look at it. I don't recall what would happen if your submit file changed the default drive. It probably stopped processing the submit file.

    SUBMIT actually creates the $$$.SUB file, and the CCP "only" reads it... but it also depends on another legacy "feature" of the BDOS that allows it to truncate the file by one record. So, SUBMIT creates $$$.SUB in reverse order, so that the first command is at the end of the file. Then CCP reads the first command from the end of the file and truncates the file by one record. Next time around, the CCP will get the next command, and truncate yet again. When the file reaches zero length, it is deleted and the submit "stops".

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •