SUBMIT.COM doesn't work

[skx]

I suspect resolving this will involve a number of changes, but the short version is simple enough:

• SUBMIT.COM does not work under your emulator.

There is a related utility I found called "slash", source/binary available within my distribution of utilities:

• https://github.com/skx/cpm-dist/tree/master/A

The short version is that both of these utilities work the same way, they allow the submission of a number of sequential commands to be automatically executed.

SUBMIT.COM will read a text file containing commands, with optional parameter expansion. It will then generate a file $$$.SUB on A:, which should be processed the next time the CCP is reloaded.

SLASH.COM is similar, but it allows you to create the $$$.SUB file without the need for a temporary file, for example:

SLASH C:HELLO ; A:HELLO ; C:ECHO TEST

Both of these utilities should produce a file named $$$.SUB. That file will contain N 128-byte records, one record for each command. The records will be in reverse order:

• CCP will recognize the file is present when it starts.
• CCP will execute the command in the last record.
• It will then truncate the file by one record length (i.e. 128 bytes)
• Repeating until error, or the file is empty (at which point it is deleted).

I played around with fixing this but I hit a bunch of errors which both annoyed and confused me, so I think this will be better placed for you to attack if you wish!

The first issue is that the drive-reset function 13, DRV_ALLRESET, is supposed to return 0xFF if there is a $$$.SUB file present, but ast the moment you hard-code the return value as 0x00. I thought that updating that function to return 0xFF would be OK - because if the file were present it would then be processed, and in the case where opening failed the CCP would move on. But unfortunately it wasn't that simple.

If I make this change:

@@ -166,6 +166,7 @@ impl Bdos {
                 },
                 13 => { // DRV_ALLRESET - Reset disk system
                     env.state.reset();
+                    res8 = Some(0xff)
                 },
                 14 => { // DRV_SET - Select disk
                     bdos_drive::select(env, arg8);
@@ -293,4 +294,4 @@ fn get_version() -> u16 {
     and random access functions.
     */
     0x0022 // CP/M 2.2 for Z80
-}
\ No newline at end of file
+}

The end result is actually a failure to open the file:

$ ./target/debug/iz-cpm --disk-a /home/skx/Repos/github.com/skx/cpm-dist/A
iz-cpm https://github.com/ivanizag/iz-cpm
CP/M 2.2 Emulation
Press ctrl-c ctrl-c Y to return to host

Athread 'main' panicked at 'attempt to add with overflow', src/fcb.rs:162:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Running with tracing that's trying to open the file, which does exist:

[[BDOS command 32: F_USERNUM(0000)]][[=>00]]
[[BDOS command 13: DRV_ALLRESET(0000)]][[=>ff]]
[[BDOS command 17: F_SFIRST(f07a)]][[DIR start A:$$$.SUB]][[=>00]]

[[BDOS command 25: DRV_GET(f00a)]][[=>00]]
A[[BDOS command 32: F_USERNUM(f0ff)]][[=>00]]
[[BDOS command 15: F_OPEN(f07a)]][[Open file A:$$$.SUB]][[=>00]]
thread 'main' panicked at 'attempt to add with overflow', src/fcb.rs:162:18
stack backtrace:

I stopped investigating there.

However I suspect if you resolve this problem you'll hit another, I see you don't truncate files when they're closed, and so I suspect that if you return the value to indicate the SUB-file is present, and fix the opening you'll end up with an infinite loop:

1. Open $$$.SUB
2. Read the last record.
3. Close the file
4. Execute the command.
5. GoTO 2

Unless/until the truncation of the last record happens it'll just run forever, until cancelled.

[ivanizag]

I'll try to fix this. It may take some time. I never really understood how SUBMIT.COM works not tried to emulate it. It's time to learn it now. Thanks.

[ivanizag]

Fixed, hopefully. Thanks to your detailed report, starting to tackle it was easier. Several things had to be fixed and supported:

• DRV_ALLRESET to return 0xff if there are files starting with $ on A:. That is not described on the DR documentation but it's described here: https://www.seasip.info/Cpm/bdos.html
• Initialization of the field RECORD_COUNT on the FCBs when opening. It is used by CCP to find the last block.
• Update of the field RECORD_COUNT on file appends, to avoid unwanted truncation at close
• Trancation at close. Used by CCP to remove the last block.

None of that was implemented. Reading the docs I thought that they were only used internally by BDOS.

[skx]

Awesome news. Having submit makes compiling, assembling and linking code so much more pleasant.

I have to say that I love what you did, recently, with the integration tests and also present in the commits here to test the operation of the submit-commands/output. An idea which I immediately borrowed for myself - skx/cpmulator#154

[ivanizag]

Yes, having at least some integration tests was long due. I started simpler, but having commands like DIR testing for control C during execution made having all the input in just one string more complex. I don't know haw you have dealt with that. Also testing a complete snapshot of the output is probably useful to make sure there are no regressions.