• Please review our updated Terms and Rules here

SUBMIT.COM behaviour

JonB

JonB

Veteran Member
Joined
Jan 26, 2014
Messages
1,652
Location
South Herefordshire, UK
Reading the CP/M manual entry for SUBMIT.COM: http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch1.htm#Section_1.6.7

I see it is supposed to write the $$$.SUB file to the active drive but then on the next warm boot the BDOS only reads from the default drive (a:).

This is intended to allow you to set a command up on a removable disk that gets auto-run when that disk is booted (from a:).

This behaviour is not helpful in a situation where you have multiple fixed disks, because it means that you can't run a SUBMIT job from any drive other than a:.

I see the BDOS selects a: when processing a SUBMIT job. It would be easy to comment this out (so that it read the $$$.SUB from the active drive), but if a job changed drives the thing would break. The only way out that I can see is to make SUBMIT write the $$$.SUB file to the default drive (a:).

Is there any other way to achieve this? I don't want to have to start disassembling SUMBIT.COM for a fix..

(And incidentally, the Montezuma CPM SUBMIT I posted a couple of years ago doesn't work on this system - Superbrain +iUDE - either.)
 
JonB said:
Reading the CP/M manual entry for SUBMIT.COM: http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch1.htm#Section_1.6.7

I see it is supposed to write the $$$.SUB file to the active drive but then on the next warm boot the BDOS only reads from the default drive (a:).

This is intended to allow you to set a command up on a removable disk that gets auto-run when that disk is booted (from a:).

This behaviour is not helpful in a situation where you have multiple fixed disks, because it means that you can't run a SUBMIT job from any drive other than a:.

I see the BDOS selects a: when processing a SUBMIT job. It would be easy to comment this out (so that it read the $$$.SUB from the active drive), but if a job changed drives the thing would break. The only way out that I can see is to make SUBMIT write the $$$.SUB file to the default drive (a:).

Is there any other way to achieve this? I don't want to have to start disassembling SUMBIT.COM for a fix..

(And incidentally, the Montezuma CPM SUBMIT I posted a couple of years ago doesn't work on this system - Superbrain +iUDE - either.)
Click to expand...

At the time, there were many replacements for the SUBMIT command written to remedy this. E.g. SUPERSUB (http://www.classiccmp.org/cpmarchives/cpm/Software/WalnutCD/lambda/soundpot/p/supersub.lbr) or DO. You should be able to find them in one of the various CP/M software collections.
 
Also.. I do have SSUB v1.1 on here but it doesn't work, either.

example

e: supersub dd

does nothing, leaves $$$.SUB in E: (as does SUBMIT).

I tried with the standard floppy only boot and Supersub still doesn't work (when run from B: with the submit file also on B:), so it's not due to my BIOS or BDOS tweaks.
 
So, the real work for SUBMIT is done by the CCP. Each time you warm boot the CCP will check for $$$.SUB and continue executing from it. However, CCP has a "cold" and "warm" boot entry point, and if your BIOS does not differentiate (always jumps to cold boot entry) then I think you'll get this behavior. At least it's a good idea, lacking facts to the contrary.
 
Oh, just realized you were creating $$$.SUB on drive E: ? That has been problematic on many versions, as I recall.
 
I checked CCP source code, and cold vs. warm start does not make a difference for $$$.SUB. However, stock DRI CCP for 2.2 does not seem to work for $$$.SUB on the default drive (if not A: ). I seem to recall fixing that in custom versions of CCP, and perhaps DRI also fixed it later on.
 
That's what I am looking for John, thanks... Only thing is, my BIOS defines a default drive which is not A:, becasue I have a uIDE connected (to my Superbrain). So what I need is for it to create $$$.SUB on the default drive (which is normally A:, agreed). However, for my implementation I wanted A: and B: to remain as floppies and have C: - P: as uIDE partitions, with C: being the "default drive" that the BDOS uses instead of A:.

I guess I will need to get the source file for Submit and fix it?
 
JonB said:
That's what I am looking for John, thanks... Only thing is, my BIOS defines a default drive which is not A:, becasue I have a uIDE connected (to my Superbrain). So what I need is for it to create $$$.SUB on the default drive (which is normally A:, agreed). However, for my implementation I wanted A: and B: to remain as floppies and have C: - P: as uIDE partitions, with C: being the "default drive" that the BDOS uses instead of A:.

I guess I will need to get the source file for Submit and fix it?
Click to expand...

You should just be able to patch SUBMIT.COM and the CCP (?BDOS) to use drive C: for $$$.SUB. In SUBMIT.COM, the drive to use is at address 05BBh (0 for default, 1 for A:, 2 for B: etc).

Application Note 10 (CPM22APN.10, "Booting CP/M on Drives Other Than Drive A") may also be relevant here.
 
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:
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:.
 
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!
 
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".
 
You must log in or register to reply here.
Back
Top