SUBMIT.com doesn't work

[skx]

Now I'm using the CCP which is lightly modified from the z80-playground version, and I recall that had issues with SUBMIT.com so it might be I need to make changes there.

[skx]

I created a file, "H.SUB":

$ cat A/H.SUB
a:HELLO
c:echo steve

I ran SUBMIT H, which produced $$$.SUB:

00000000: 0c43 3a45 4348 4f20 5354 4556 4500 2420  .C:ECHO STEVE.$ 
00000010: 7374 6576 650d 0a1a 1a1a 1a1a 1a1a 1a1a  steve...........
00000020: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
00000030: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
00000040: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
00000050: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
00000060: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
00000070: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
00000080: 0741 3a48 454c 4c4f 0024 4556 4500 2420  .A:HELLO.$EVE.$ 
00000090: 7374 6576 650d 0a1a 1a1a 1a1a 1a1a 1a1a  steve...........
000000a0: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
000000b0: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
000000c0: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
000000d0: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
000000e0: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................
000000f0: 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a 1a1a  ................

• i.e. A list of 128-byte records.
  • First byte is the length of the input.
  • Then the contents of the input-buffer
  • Contents are reversed

Running with the default CCP:

$ cpmulator -cd  ~/Repos/github.com/skx/cpm-dist/ -directories  

A>A:HELLO
A>

• TLDR: CCP loads and echos the input, but doesn't process it.
  • Did process the last record, before the first.
  • Did not delete the file.

Running with CCPZ:

$ cpmulator -ccp=ccpz -cd  ~/Repos/github.com/skx/cpm-dist/ -directories  
A$A:HELLO

Hello, World!

A$A:HELLO

Hello, World!

A$A:HELLO

Hello, World!

A$A:HELLO

Hello, World!

A^C

• TLDR: CCPZ just repeatedly rexecutes the file over and over again, without removing it
  • It starts from the last record.

[skx]

So for the moment I'll focus upon CCPZ, because that does read, echo, and execute the input.

However it started at the last record, and didn't proceed to the first. (The records are produced in reverse order).

I suspect it should truncate the file (before?) so that it works in reverse, always removing the record of the line I've got. That could be what I'm missing.

Need to trace the F_OPEN, F_READ, F_CLOSE calls to verify, and look at the source.

[skx]

Looking at the source-code to CCPZ I see the following code:

    LDIR
    LD  HL,SUBFS2   ;PT TO S2 OF $$$.SUB FCB
    LD  (HL),0      ;SET S2 TO ZERO
    INC HL      ;PT TO RECORD COUNT
    DEC (HL)        ;DECREMENT RECORD COUNT OF $$$.SUB
    LD  DE,SUBFCB   ;CLOSE $$$.SUB
    CALL    CLOSE

It seems my suspicion was correct:

• The CCP opens the file.
• It leads the last record.
• It decrements the record count.
• It closes the file.

The result of that should be that the file is processed in reverse order, however I do not truncate the file on close - so we always process the last record again, and again, and again....

[skx]

I think I've managed to fix the truncation, such SUBMIT.COM works.

First of all create a test-file, which invokes two binaries on different drives:

A>type test.sub

P:HELLO
C:ECHO MOI, KISSA!

Now run the thing:

A>submit test.sub

A$P:HELLO
Hello, world.
I am alive!

A$C:ECHO MOI, KISSA!
MOI, KISSA!

The problem I have is that cross-drive stuff seems difficult. I can't make a compiler run, I get weird output from the file. It almost looks like there is an issue with the $$$.SUB that gets created - instead of having three records it has only one:

A>type comp.sub

C:
CC $1
AS $1
LN $1.O C.LIB

But then:

A>submit comp echo

A$C:
C>      

So it ran the "C:" but nothing else. And of course changing drive screwed up further processing:

= ADDR == HEX =============================================== ASCII ============
  0100    0f 4c 4e 20 45 43 48 4f 2e 4f 20 43 2e 4c 49 42     .LN ECHO.O C.LIB
  0110    00 24 4c 4e 20 24 31 2e 4f 20 43 2e 4c 49 42 0d     .$LN $1.O C.LIB.
  0120    0a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a     ................
  0130    1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a     ................
  0140    1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a     ................

So one step forward, two steps sideways.

Am I missing something obvious?

[skx]

Using an external helper to test this - it's looking like only two commands work.

Here's the helper:

#!/bin/sh
#
# Write a $$$.SUB file using the commands specified in the argument.
#
# Usage:
#    submit.sh 'CC ECHO' 'AS ECHO' 'LN ECHO.O C.LIB'
#
perl -e 'print join("\n", reverse @ARGV)' "$@" | \
    perl -ne 's/[\r\n]//g; printf "%-128s", chr(length($_)).$_.chr(0)' > '/home/skx/Repos/github.com/skx/cpm-dist/A/$$$.SUB'

So whos fault is the "two command only"? Not sure yet.