Diagnostic file with extra byte in header

[lildevilx]

Hi @Danitegue

While testing the PCBRW, we notice there was a few files our processor is getting an error with. Taking a quick look, it seems like the program is saving an extra byte of hex at the beginning of each file created. specifically "1A" on every new file created.

I've notice this in DI and HS files

Examples: DI - Correct format

Brewer health test started at 23:17:02 on 06-20-2018
Turning lamps off
Motor 4 to step  256
Motor 5 to step  0
Motor 1 to step 0
Motor 3 to step  250

DI - Incorrect format

Brewer health test started at 06:21:39 on 07-16-2018
Turning lamps off
Motor 4 to step  256
Motor 5 to step  0
Motor 1 to step 0
Motor 3 to step  250

HS - Same extra byte

************************************************************
  HS Scan of (1) Internal mercury lamp
************************************************************

oddly enough the B and D files are not affected.

[Danitegue]

Hi lildevilx,

This is the famous end of file character... problematic for some DOSBOX versions. The noeof.exe is in charge of deleting them. In PCBRW this noeof.exe is emulated through python code, with the Brw_functions.py.

I suppose you are using the --shell="python %BRWFUNCT_DIR%\Brw_functions.py" option in the launchers to redirect all the SHELL calls, as it is indicated in the readme, not?

I suppose this can happen because: a) the noeof.exe emulation (through Brw_functions.py) is not removing properly the end of file characters of certain files. (But it would be strange, since it is working fine with the B and D files.) b) A shell command like SHELL COPY FILE1+FILE2 FILE3 can be taking the end of file character of and old system FILE1 that contains an eof, and adding it to the final FILE3. In this case, could you identify the contents of the FILE1 and FILE2 before this concatenation?

[lildevilx]

correct im using the options in the launcher as indicated in the readme file.

I also attached an example of file1 and file2 for your reference, I noticed inside the DUM.txt (originally DUM.dta) only had the 0x1A at the end of the file where HS19818 had it at the start and the end. So i'm not really sure what would be the thing that adds 0x1A in.

HS19818.txt DUM.txt

[Danitegue]

Ok, I think I have solved it, the function that emulates the SHELL COPY FILE1+FILE2 FILE3, was doing it in a byte per byte way. So if these end of file bytes were in the FILE1 and FILE2, they were being copied to the FILE3, and a final file with two end of file characters would be possible.

I have modified the Brw_functions.py, shell_copy function, in order not to copy these characters never to the final files, since they are not needed.

Try it please. If you enable the -debug=True in the launcher, you will see what is Brw_functions.py doing, trough the pcbasic log file (--logfile=%LOG_DIR%\pcbasic_brewer_log.txt)

[lildevilx]

Hey,

Looks like that did the trick! I'll let you know if I run into any other issues.