SUBMIT file not supported because of BDOS bug

[z80playground]

In BDOS call 13 (reset disks) the system should look on the A: drive for a file called $$$.SUB. If it finds one this call needs to return 255, otherwise 0. This will then enable to submit file functionality to work in the CCP.

[gd-99]

I've been poking around this bug, and have a feeling the issue may be in the BDOS_Open_File: routine. I have implemented a method of enabling the RNGSUB flag, so that the CCP (Z80CCP) knows there is a $$$.SUB file on the A: drive. When I submit a simple SUB file, the temporary $$$.SUB gets created, the CCP reads the $$$.SUB file, then deletes the $$$.SUB file - like it should - but doesn't act on any of the submit file instructions, simply drops me back to the A: prompt.

Looking in the CCP file I see that if RNGSUB is non zero then the REDBUF: routine processes the $$$.SUB file. Early on in the process the $$$.SUB file is opened with a "CALL OPEN". Assuming the file exists, the the record count is obtained from the FCB with the "LD A,(SUBFRC)" instruction. So far as I can see when the file is opened using the BDOS call BDOS_Open_File, the record count isn't calculated and stored in the FCB record count (FCB+15) - SUBFRC.

I'm not well up on CP/M and what is in the BDOS routines so happy to be corrected if this is the way its meant to be. It just appears the routine calculates where it is in the SUB file using the record count and current record entries in the FCB.

I'm I on the right track or is this a big red fish?

Tidied up bit of the code in REDBUF: for reference.

LD DE,SUBFCB    ; OPEN $$$.SUB
CALL    OPEN
JR  Z, RB1              ; ERASE $$$.SUB IF END OF FILE AND GET CMND
LD  A,(SUBFRC)  ; GET VALUE OF LAST RECORD IN FILE
DEC A           ; PT TO NEXT TO LAST RECORD
LD  (SUBFCR),A  ; SAVE NEW VALUE OF LAST RECORD IN $$$.SUB
LD  DE,SUBFCB   ; READ LAST RECORD OF SUBMIT FILE
CALL    READ

Happy to post my scruffy code for enabling the RNGSUB flag within BDOS.

[gd-99]

Hi John, sort of getting there with the SUBMIT issue. After more - a lot - of poking around, I am fairly sure my guess about how submit works is reasonably correct. I wanted to share what I have found out in case it helps others and hopefully you can also improve my hack.

I'm using CCPZ as described in issue 70 #70 as my version is fairly vanilla. From this, I assume as submit doesn't work with this CCP, to get submit working I will need to modify your BDOS. I have a very hacky version of BDOS that mostly works when a proper $$$.SUB file is placed in the A: drive (User 0).

It does appear that the CCP reads the $$$.SUB file from the last record to the first record. I confirmed this by creating a proper $$$.SUB file using the RunCPM emulator, that can create and process submit files. Creating a properly formed $$$.SUB file this way, looking at the resulting file using a hex editor it is possible to see the first line of the original sub file is placed at the end of the $$$.SUB file. This seems to confirm the CCP reads the $$$.SUB file from last to first - odd.

In essence my hack uses your code to calculate a newly opened file size, without closing the file. This provides a file size, in 128 records, in HL. I then populate the FCB record count (RC) with the value in L. If the L value is greater than 128, I (hope - not tested yet) then I reset the record count to zero and increment the low byte extent value. This bit of code is fired off when a file is opened, as the relevant bit of code in the CCP opens the file first, manipulates FCB RC and FCB CR (current Record) and then tries reading the $$$.SUB file.

I haven't been able to create $$$.SUB files from within CPM_FAT. Using submit running CPM_FAT (on my board), produces a $$$.SUB file, but looking at the produced file with a hex editor, doesn't look anything like the $$$.SUB file produced using RunCPM. So to get this far I am using a "test" $$$.SUB file created in RunCPM, and placed on the CPM_FAT A: drive. To save a lot of swapping, I have found I can save the RunCPM file using a different name to $$$.SUB, then using the copy.com program to copy this file to $$$.SUB, then doing a ^C to get the CCP to reset and fire of processing the $$$.SUB file. Once I have ironed out the wrinkles in this hack, I will take a look at how to submit files from within CPM_FAT.

Here is a zip file of the files I have been using with a small text extract of the relevant bit of BDOS.ASM I have modified. Submit-hack.zip

This zip file should contain:

1. TS1-ED.SUB - submit file created using ED. I have only had any success submit files using ED???
2. $$$.SUB - the resulting submit file created using submit on RunCPM
3. COPY.COM - a nice copy program - source -> destination unlike pip.
4. BDOS.TXT - copy and past bits of BDOS with my hack.

It would be great if you could take a look at my hack to see if you can reproduce my success and /or offer up any improvements I can make, errors etc.

Sorry this is a bit of a long old post. If you're happy for me to keep reporting back I will post as I get further along the line.