On Saturday, 16 April 2022 at 16:32:18 UTC+1, Mark Ogden wrote:
> On Saturday, 16 April 2022 at 14:33:07 UTC+1, Steven Hirsch wrote:
> > On 4/14/22 13:17, Nathanael wrote:
> > > I’d forgotten to edit out my own local system values. I’ve replaced both with $(pwd).
> > >
> > > Not sure how I’d get that info from the environment?
> > In shell coding, environment variables are just another global variable.. So,
> > define two values, e.g. 'ISODIR' and 'OUTDIR', then have the user set those
> > before running the program:
> >
> > $ export ISODIR=/path/to/iso
> > $ export OUTDIR=/path/for/output
> > $ ./buildvol XXX
> > > On Thursday, April 14, 2022 at 9:49:46 PM UTC+8, Steven Hirsch wrote:
> > >> On 4/11/22 19:55, Nathanael wrote:
> > >>> Glad to hear the script works on someone else’s system. Curious as to what
> > >>> the “couple of edits” were. Anything that I need to update?
> > >>>
> > >> I had to edit in the ISO and output locations. Suggestion: Modify the script
> > >> to take these from the environment.
> Nathanael
> I have posted an update to mlbr on github that ignores dates set to 0xffff.
> There is still a problem in that it appears as though some of the dates have been set using a different base date rather than the DR one (or have garbage date info)
> The lbr specification can be found at https://www.seasip.info/Cpm/ludef5.html. You will see that dates should be based from the number of days since December 31, 1977. If the day value used is based on a different epoch, e.g. unix, msdos or windows, mlbr will reflect a date many years different.
>
> I also suspect that lbr files generated using LU86 have garbage date/time value. Some of these could be detected if the timestamps they represent are later than the timestamp of the lbr file itself.
>
> Note the timestamps of some of the LBR files themselves are later than the release date of the SIG/M volume catalog info, possibly indicating that the files were copied without keeping the original dates/times.
>
> Mark
Nathanael
I have updated mlbr to flag dates with invalid time information or dates > the LBR file timestamp. This will highlight most of the corrupt dates, but as with any garbage information it cannot eliminate all of them. If you see < invalid date > in the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.
A timestamp for the lbr file is always shown, if the value in the header is not set in the header or is invalid, then this will be the OS's file timestamp.

Note all dates are show as GMT time.
Mark

On Sunday, 17 April 2022 at 12:03:02 UTC+1, Mark Ogden wrote:
> On Saturday, 16 April 2022 at 16:32:18 UTC+1, Mark Ogden wrote:
> > On Saturday, 16 April 2022 at 14:33:07 UTC+1, Steven Hirsch wrote:
> > > On 4/14/22 13:17, Nathanael wrote:
> > > > I’d forgotten to edit out my own local system values. I’ve replaced both with $(pwd).
> > > >
> > > > Not sure how I’d get that info from the environment?
> > > In shell coding, environment variables are just another global variable. So,
> > > define two values, e.g. 'ISODIR' and 'OUTDIR', then have the user set those
> > > before running the program:
> > >
> > > $ export ISODIR=/path/to/iso
> > > $ export OUTDIR=/path/for/output
> > > $ ./buildvol XXX
> > > > On Thursday, April 14, 2022 at 9:49:46 PM UTC+8, Steven Hirsch wrote:
> > > >> On 4/11/22 19:55, Nathanael wrote:
> > > >>> Glad to hear the script works on someone else’s system. Curious as to what
> > > >>> the “couple of edits” were. Anything that I need to update?
> > > >>>
> > > >> I had to edit in the ISO and output locations. Suggestion: Modify the script
> > > >> to take these from the environment.
> > Nathanael
> > I have posted an update to mlbr on github that ignores dates set to 0xffff.
> > There is still a problem in that it appears as though some of the dates have been set using a different base date rather than the DR one (or have garbage date info)
> > The lbr specification can be found at https://www.seasip.info/Cpm/ludef5.html. You will see that dates should be based from the number of days since December 31, 1977. If the day value used is based on a different epoch, e.g. unix, msdos or windows, mlbr will reflect a date many years different.
> >
> > I also suspect that lbr files generated using LU86 have garbage date/time value. Some of these could be detected if the timestamps they represent are later than the timestamp of the lbr file itself.
> >
> > Note the timestamps of some of the LBR files themselves are later than the release date of the SIG/M volume catalog info, possibly indicating that the files were copied without keeping the original dates/times.
> >
> > Mark
> Nathanael
> I have updated mlbr to flag dates with invalid time information or dates > the LBR file timestamp. This will highlight most of the corrupt dates, but as with any garbage information it cannot eliminate all of them. If you see < invalid date > in the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.
> A timestamp for the lbr file is always shown, if the value in the header is not set in the header or is invalid, then this will be the OS's file timestamp.
>
> Note all dates are show as GMT time.
> Mark
I issued another minor tweak to mlbr , if the os filestamp is used for an LBR file, the time is followed by an '=' if the header timestamp is missing
or a '*' if the header timestamp is corrupt. I also did some more improvements to catch more invalid dates.

Note looking through all of the sigm sources, the lbr file timestamps indicate multiple copy dates for the individual files. Unfortunately, only a few of the files themselves have embedded timestamps. This means that the date recorded in the catalog file is probably the most accurate.
Mark

On Monday, 18 April 2022 at 14:06:20 UTC+1, Mark Ogden wrote:
> On Sunday, 17 April 2022 at 12:03:02 UTC+1, Mark Ogden wrote:
> > On Saturday, 16 April 2022 at 16:32:18 UTC+1, Mark Ogden wrote:
> > > On Saturday, 16 April 2022 at 14:33:07 UTC+1, Steven Hirsch wrote:
> > > > On 4/14/22 13:17, Nathanael wrote:
> > > > > I’d forgotten to edit out my own local system values. I’ve replaced both with $(pwd).
> > > > >
> > > > > Not sure how I’d get that info from the environment?
> > > > In shell coding, environment variables are just another global variable. So,
> > > > define two values, e.g. 'ISODIR' and 'OUTDIR', then have the user set those
> > > > before running the program:
> > > >
> > > > $ export ISODIR=/path/to/iso
> > > > $ export OUTDIR=/path/for/output
> > > > $ ./buildvol XXX
> > > > > On Thursday, April 14, 2022 at 9:49:46 PM UTC+8, Steven Hirsch wrote:
> > > > >> On 4/11/22 19:55, Nathanael wrote:
> > > > >>> Glad to hear the script works on someone else’s system. Curious as to what
> > > > >>> the “couple of edits” were. Anything that I need to update?
> > > > >>>
> > > > >> I had to edit in the ISO and output locations. Suggestion: Modify the script
> > > > >> to take these from the environment.
> > > Nathanael
> > > I have posted an update to mlbr on github that ignores dates set to 0xffff.
> > > There is still a problem in that it appears as though some of the dates have been set using a different base date rather than the DR one (or have garbage date info)
> > > The lbr specification can be found at https://www.seasip.info/Cpm/ludef5.html. You will see that dates should be based from the number of days since December 31, 1977. If the day value used is based on a different epoch, e.g. unix, msdos or windows, mlbr will reflect a date many years different.
> > >
> > > I also suspect that lbr files generated using LU86 have garbage date/time value. Some of these could be detected if the timestamps they represent are later than the timestamp of the lbr file itself.
> > >
> > > Note the timestamps of some of the LBR files themselves are later than the release date of the SIG/M volume catalog info, possibly indicating that the files were copied without keeping the original dates/times.
> > >
> > > Mark
> > Nathanael
> > I have updated mlbr to flag dates with invalid time information or dates > the LBR file timestamp. This will highlight most of the corrupt dates, but as with any garbage information it cannot eliminate all of them. If you see < invalid date > in the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.
> > A timestamp for the lbr file is always shown, if the value in the header is not set in the header or is invalid, then this will be the OS's file timestamp.
> >
> > Note all dates are show as GMT time.
> > Mark
> I issued another minor tweak to mlbr , if the os filestamp is used for an LBR file, the time is followed by an '=' if the header timestamp is missing
> or a '*' if the header timestamp is corrupt. I also did some more improvements to catch more invalid dates.
>
> Note looking through all of the sigm sources, the lbr file timestamps indicate multiple copy dates for the individual files. Unfortunately, only a few of the files themselves have embedded timestamps. This means that the date recorded in the catalog file is probably the most accurate.
> Mark
In looking through the SIGM files, it appears as though a number of the text files were converted to unix format at some point. Does anyone know the history of this?
For CP/M and MSDOS I would have expected CRLF for end of line rather than the unix standard LF only. The crck utility handles this by reintroducing the \r for the CRC calculation for text files.
However looking at the file sizes, which are rounded to up to next 1k boundary, the size of the files converted to CP/M format better match the stated file sizes.

Mark

On Wednesday, April 20, 2022 at 12:39:35 AM UTC+8, Mark Ogden wrote:
> On Monday, 18 April 2022 at 14:06:20 UTC+1, Mark Ogden wrote:
> > On Sunday, 17 April 2022 at 12:03:02 UTC+1, Mark Ogden wrote:
> > > On Saturday, 16 April 2022 at 16:32:18 UTC+1, Mark Ogden wrote:
> > > > On Saturday, 16 April 2022 at 14:33:07 UTC+1, Steven Hirsch wrote:
> > > > > On 4/14/22 13:17, Nathanael wrote:
> > > > > > I’d forgotten to edit out my own local system values. I’ve replaced both with $(pwd).
> > > > > >
> > > > > > Not sure how I’d get that info from the environment?
> > > > > In shell coding, environment variables are just another global variable. So,
> > > > > define two values, e.g. 'ISODIR' and 'OUTDIR', then have the user set those
> > > > > before running the program:
> > > > >
> > > > > $ export ISODIR=/path/to/iso
> > > > > $ export OUTDIR=/path/for/output
> > > > > $ ./buildvol XXX
> > > > > > On Thursday, April 14, 2022 at 9:49:46 PM UTC+8, Steven Hirsch wrote:
> > > > > >> On 4/11/22 19:55, Nathanael wrote:
> > > > > >>> Glad to hear the script works on someone else’s system. Curious as to what
> > > > > >>> the “couple of edits” were. Anything that I need to update?
> > > > > >>>
> > > > > >> I had to edit in the ISO and output locations. Suggestion: Modify the script
> > > > > >> to take these from the environment.
> > > > Nathanael
> > > > I have posted an update to mlbr on github that ignores dates set to 0xffff.
> > > > There is still a problem in that it appears as though some of the dates have been set using a different base date rather than the DR one (or have garbage date info)
> > > > The lbr specification can be found at https://www.seasip.info/Cpm/ludef5.html. You will see that dates should be based from the number of days since December 31, 1977. If the day value used is based on a different epoch, e.g. unix, msdos or windows, mlbr will reflect a date many years different.
> > > >
> > > > I also suspect that lbr files generated using LU86 have garbage date/time value. Some of these could be detected if the timestamps they represent are later than the timestamp of the lbr file itself.
> > > >
> > > > Note the timestamps of some of the LBR files themselves are later than the release date of the SIG/M volume catalog info, possibly indicating that the files were copied without keeping the original dates/times.
> > > >
> > > > Mark
> > > Nathanael
> > > I have updated mlbr to flag dates with invalid time information or dates > the LBR file timestamp. This will highlight most of the corrupt dates, but as with any garbage information it cannot eliminate all of them. If you see < invalid date > in the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.
> > > A timestamp for the lbr file is always shown, if the value in the header is not set in the header or is invalid, then this will be the OS's file timestamp.
> > >
> > > Note all dates are show as GMT time.
> > > Mark
> > I issued another minor tweak to mlbr , if the os filestamp is used for an LBR file, the time is followed by an '=' if the header timestamp is missing
> > or a '*' if the header timestamp is corrupt. I also did some more improvements to catch more invalid dates.
> >
> > Note looking through all of the sigm sources, the lbr file timestamps indicate multiple copy dates for the individual files. Unfortunately, only a few of the files themselves have embedded timestamps. This means that the date recorded in the catalog file is probably the most accurate.
> > Mark
> In looking through the SIGM files, it appears as though a number of the text files were converted to unix format at some point. Does anyone know the history of this?
> For CP/M and MSDOS I would have expected CRLF for end of line rather than the unix standard LF only. The crck utility handles this by reintroducing the \r for the CRC calculation for text files.
> However looking at the file sizes, which are rounded to up to next 1k boundary, the size of the files converted to CP/M format better match the stated file sizes.
>
> Mark
Can you give specific examples?

It's obvious that at least some versions passed through UNIX. The Walnut Creek CD collection did. Makes sense that some UNIX conversion may have happened. I've restored most of the files to their original CRCs as reported in the various -CATALOG or -CRCKFILE lists. But a CR/LF conversion may explain why others still don't match. I'll take a look.

On Thursday, 21 April 2022 at 22:36:43 UTC+1, Nathanael wrote:
> On Wednesday, April 20, 2022 at 12:39:35 AM UTC+8, Mark Ogden wrote:
> > On Monday, 18 April 2022 at 14:06:20 UTC+1, Mark Ogden wrote:
> > > On Sunday, 17 April 2022 at 12:03:02 UTC+1, Mark Ogden wrote:
> > > > On Saturday, 16 April 2022 at 16:32:18 UTC+1, Mark Ogden wrote:
> > > > > On Saturday, 16 April 2022 at 14:33:07 UTC+1, Steven Hirsch wrote:
> > > > > > On 4/14/22 13:17, Nathanael wrote:
> > > > > > > I’d forgotten to edit out my own local system values. I’ve replaced both with $(pwd).
> > > > > > >
> > > > > > > Not sure how I’d get that info from the environment?
> > > > > > In shell coding, environment variables are just another global variable. So,
> > > > > > define two values, e.g. 'ISODIR' and 'OUTDIR', then have the user set those
> > > > > > before running the program:
> > > > > >
> > > > > > $ export ISODIR=/path/to/iso
> > > > > > $ export OUTDIR=/path/for/output
> > > > > > $ ./buildvol XXX
> > > > > > > On Thursday, April 14, 2022 at 9:49:46 PM UTC+8, Steven Hirsch wrote:
> > > > > > >> On 4/11/22 19:55, Nathanael wrote:
> > > > > > >>> Glad to hear the script works on someone else’s system. Curious as to what
> > > > > > >>> the “couple of edits” were. Anything that I need to update?
> > > > > > >>>
> > > > > > >> I had to edit in the ISO and output locations. Suggestion: Modify the script
> > > > > > >> to take these from the environment.
> > > > > Nathanael
> > > > > I have posted an update to mlbr on github that ignores dates set to 0xffff.
> > > > > There is still a problem in that it appears as though some of the dates have been set using a different base date rather than the DR one (or have garbage date info)
> > > > > The lbr specification can be found at https://www.seasip.info/Cpm/ludef5.html. You will see that dates should be based from the number of days since December 31, 1977. If the day value used is based on a different epoch, e.g. unix, msdos or windows, mlbr will reflect a date many years different.
> > > > >
> > > > > I also suspect that lbr files generated using LU86 have garbage date/time value. Some of these could be detected if the timestamps they represent are later than the timestamp of the lbr file itself.
> > > > >
> > > > > Note the timestamps of some of the LBR files themselves are later than the release date of the SIG/M volume catalog info, possibly indicating that the files were copied without keeping the original dates/times.
> > > > >
> > > > > Mark
> > > > Nathanael
> > > > I have updated mlbr to flag dates with invalid time information or dates > the LBR file timestamp. This will highlight most of the corrupt dates, but as with any garbage information it cannot eliminate all of them. If you see < invalid date > in the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.
> > > > A timestamp for the lbr file is always shown, if the value in the header is not set in the header or is invalid, then this will be the OS's file timestamp.
> > > >
> > > > Note all dates are show as GMT time.
> > > > Mark
> > > I issued another minor tweak to mlbr , if the os filestamp is used for an LBR file, the time is followed by an '=' if the header timestamp is missing
> > > or a '*' if the header timestamp is corrupt. I also did some more improvements to catch more invalid dates.
> > >
> > > Note looking through all of the sigm sources, the lbr file timestamps indicate multiple copy dates for the individual files. Unfortunately, only a few of the files themselves have embedded timestamps. This means that the date recorded in the catalog file is probably the most accurate.
> > > Mark
> > In looking through the SIGM files, it appears as though a number of the text files were converted to unix format at some point. Does anyone know the history of this?
> > For CP/M and MSDOS I would have expected CRLF for end of line rather than the unix standard LF only. The crck utility handles this by reintroducing the \r for the CRC calculation for text files.
> > However looking at the file sizes, which are rounded to up to next 1k boundary, the size of the files converted to CP/M format better match the stated file sizes.
> >
> > Mark
> Can you give specific examples?
>
> It's obvious that at least some versions passed through UNIX. The Walnut Creek CD collection did. Makes sense that some UNIX conversion may have happened. I've restored most of the files to their original CRCs as reported in the various -CATALOG or -CRCKFILE lists. But a CR/LF conversion may explain why others still don't match. I'll take a look.
Nathanael
I suspect the text files that match the original CRC only do so because the crc tool you are using adds in a missing '\r', i.e. they are in unix format, the ones that fail are probably in \r\n and the CRC utility adds another \r making the CRC fail.
On larger text files the unix converted text files are slightly smaller, because the '\r' has been removed. This means that the size shown in the original catalogue will be larger than the file in your repository. On small files this is not noticeable since the sizes are only given in k.
If you use od -c file, you will be able to see if the file you have is unix or native CP/M or DOS format
Mark

"I suspect the text files that match the original CRC only do so because the crc tool you are using adds in a missing '\r'"

It's an interesting thought, so I ran CRCK.COM under CP/M against vol 59, and got CRCs identical to what cpmcrck gives me under Linux, so I don't think that's the issue. And "dos2unix -i" indicates that the text files in vol 59 all in DOS format. I also opened up several of the text files from vol 59 in a hex editor and verified that they all have 0D0A. So I'm not sure where that leaves me.

>> dos2unix -idu sigmv059/*

59 0 sigmv059/CABORT.ASM
83 0 sigmv059/-CATALOG.059
36 0 sigmv059/ENVIRON.DOC
813 0 sigmv059/PBASE
355 0 sigmv059/PISTB.C
113 0 sigmv059/PISTC.C
272 0 sigmv059/PISTD.C
93 0 sigmv059/PISTE.C
265 0 sigmv059/PISTF.C
6 0 sigmv059/PISTGEN.SUB
129 0 sigmv059/PISTOL.C
1248 0 sigmv059/PISTOL.DOC
176 0 sigmv059/PISTOL.H
1745 0 sigmv059/PISTOL.PAS
7 0 sigmv059/PISTSUB.SUB
193 0 sigmv059/READ.ME
192 0 sigmv059/SESSION0.DOC
377 0 sigmv059/SESSION1.DOC
62 0 sigmv059/SIG_M.LIB

On Tuesday, April 26, 2022 at 3:31:18 AM UTC+8, Mark Ogden wrote:
> On Thursday, 21 April 2022 at 22:36:43 UTC+1, Nathanael wrote:
> > On Wednesday, April 20, 2022 at 12:39:35 AM UTC+8, Mark Ogden wrote:
> > > On Monday, 18 April 2022 at 14:06:20 UTC+1, Mark Ogden wrote:
> > > > On Sunday, 17 April 2022 at 12:03:02 UTC+1, Mark Ogden wrote:
> > > > > On Saturday, 16 April 2022 at 16:32:18 UTC+1, Mark Ogden wrote:
> > > > > > On Saturday, 16 April 2022 at 14:33:07 UTC+1, Steven Hirsch wrote:
> > > > > > > On 4/14/22 13:17, Nathanael wrote:
> > > > > > > > I’d forgotten to edit out my own local system values. I’ve replaced both with $(pwd).
> > > > > > > >
> > > > > > > > Not sure how I’d get that info from the environment?
> > > > > > > In shell coding, environment variables are just another global variable. So,
> > > > > > > define two values, e.g. 'ISODIR' and 'OUTDIR', then have the user set those
> > > > > > > before running the program:
> > > > > > >
> > > > > > > $ export ISODIR=/path/to/iso
> > > > > > > $ export OUTDIR=/path/for/output
> > > > > > > $ ./buildvol XXX
> > > > > > > > On Thursday, April 14, 2022 at 9:49:46 PM UTC+8, Steven Hirsch wrote:
> > > > > > > >> On 4/11/22 19:55, Nathanael wrote:
> > > > > > > >>> Glad to hear the script works on someone else’s system. Curious as to what
> > > > > > > >>> the “couple of edits” were. Anything that I need to update?
> > > > > > > >>>
> > > > > > > >> I had to edit in the ISO and output locations. Suggestion: Modify the script
> > > > > > > >> to take these from the environment.
> > > > > > Nathanael
> > > > > > I have posted an update to mlbr on github that ignores dates set to 0xffff.
> > > > > > There is still a problem in that it appears as though some of the dates have been set using a different base date rather than the DR one (or have garbage date info)
> > > > > > The lbr specification can be found at https://www.seasip.info/Cpm/ludef5.html. You will see that dates should be based from the number of days since December 31, 1977. If the day value used is based on a different epoch, e.g. unix, msdos or windows, mlbr will reflect a date many years different.
> > > > > >
> > > > > > I also suspect that lbr files generated using LU86 have garbage date/time value. Some of these could be detected if the timestamps they represent are later than the timestamp of the lbr file itself.
> > > > > >
> > > > > > Note the timestamps of some of the LBR files themselves are later than the release date of the SIG/M volume catalog info, possibly indicating that the files were copied without keeping the original dates/times.
> > > > > >
> > > > > > Mark
> > > > > Nathanael
> > > > > I have updated mlbr to flag dates with invalid time information or dates > the LBR file timestamp. This will highlight most of the corrupt dates, but as with any garbage information it cannot eliminate all of them. If you see < invalid date > in the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.
> > > > > A timestamp for the lbr file is always shown, if the value in the header is not set in the header or is invalid, then this will be the OS's file timestamp.
> > > > >
> > > > > Note all dates are show as GMT time.
> > > > > Mark
> > > > I issued another minor tweak to mlbr , if the os filestamp is used for an LBR file, the time is followed by an '=' if the header timestamp is missing
> > > > or a '*' if the header timestamp is corrupt. I also did some more improvements to catch more invalid dates.
> > > >
> > > > Note looking through all of the sigm sources, the lbr file timestamps indicate multiple copy dates for the individual files. Unfortunately, only a few of the files themselves have embedded timestamps. This means that the date recorded in the catalog file is probably the most accurate.
> > > > Mark
> > > In looking through the SIGM files, it appears as though a number of the text files were converted to unix format at some point. Does anyone know the history of this?
> > > For CP/M and MSDOS I would have expected CRLF for end of line rather than the unix standard LF only. The crck utility handles this by reintroducing the \r for the CRC calculation for text files.
> > > However looking at the file sizes, which are rounded to up to next 1k boundary, the size of the files converted to CP/M format better match the stated file sizes.
> > >
> > > Mark
> > Can you give specific examples?
> >
> > It's obvious that at least some versions passed through UNIX. The Walnut Creek CD collection did. Makes sense that some UNIX conversion may have happened. I've restored most of the files to their original CRCs as reported in the various -CATALOG or -CRCKFILE lists. But a CR/LF conversion may explain why others still don't match. I'll take a look.
> Nathanael
> I suspect the text files that match the original CRC only do so because the crc tool you are using adds in a missing '\r', i.e. they are in unix format, the ones that fail are probably in \r\n and the CRC utility adds another \r making the CRC fail.
> On larger text files the unix converted text files are slightly smaller, because the '\r' has been removed. This means that the size shown in the original catalogue will be larger than the file in your repository. On small files this is not noticeable since the sizes are only given in k.
> If you use od -c file, you will be able to see if the file you have is unix or native CP/M or DOS format
> Mark

On Wednesday, 27 April 2022 at 15:31:02 UTC+1, Nathanael wrote:
> "I suspect the text files that match the original CRC only do so because the crc tool you are using adds in a missing '\r'"
> It's an interesting thought, so I ran CRCK.COM under CP/M against vol 59, and got CRCs identical to what cpmcrck gives me under Linux, so I don't think that's the issue. And "dos2unix -i" indicates that the text files in vol 59 all in DOS format. I also opened up several of the text files from vol 59 in a hex editor and verified that they all have 0D0A. So I'm not sure where that leaves me.
>
> >> dos2unix -idu sigmv059/*
>
> 59 0 sigmv059/CABORT.ASM
> 83 0 sigmv059/-CATALOG.059
> 36 0 sigmv059/ENVIRON.DOC
> 813 0 sigmv059/PBASE
> 355 0 sigmv059/PISTB.C
> 113 0 sigmv059/PISTC.C
> 272 0 sigmv059/PISTD.C
> 93 0 sigmv059/PISTE.C
> 265 0 sigmv059/PISTF.C
> 6 0 sigmv059/PISTGEN.SUB
> 129 0 sigmv059/PISTOL.C
> 1248 0 sigmv059/PISTOL.DOC
> 176 0 sigmv059/PISTOL.H
> 1745 0 sigmv059/PISTOL.PAS
> 7 0 sigmv059/PISTSUB.SUB
> 193 0 sigmv059/READ.ME
> 192 0 sigmv059/SESSION0.DOC
> 377 0 sigmv059/SESSION1.DOC
> 62 0 sigmv059/SIG_M.LIB

>> Text Removed <<
Nathanael
You can see the dos->unix issue I noted in VOL100
As to the issues on VOL059, I suspect the problem relates to padding the sector after the control Z that marks the end of the text file.
The files in the directory are truncated to remove the control Z and any padding. CP/M only requires the single control Z to mark the end of the text file,
everything after that can be rubbish, although with common buffer management, it may be a copy of some previously emitted data. With the -t option
the unix crck version pads to the end of the sector with Control Z.
A consequence of this is that you are unlikely to match the CRC unless you can recreate the original padding.
Even in the bast case if the data end data is a copy of previously emitted data, you would need to identify which
sector it overwrote.
For short files you could try padding with 0 after adding a control Z assuming internal buffers were initialised to zero.
Mark

> You can see the dos->unix issue I noted in VOL100

I pull vol 100 from the CPMDOSGG collection, which doesn’t suffer from the issue. There are around 80 or 90 files I haven’t been able to fix the CRCs on; particularly vols 59 and 80. None of the extant sources have provided a solution. I’m hoping Steven Hirsch might be able to run CRCs on his copies of those two vols to see if he can get good CRC values.

> I suspect the problem relates to padding

That’s my working hypothesis — that in the cases of vols 59 and 80, in particular, the padding is random garbage rather than 00H or 1AH. Brute forcing’s not an option: even vol 59’s PISTD.C, which only needs 10 bytes of padding, means 16^10 = 1.2 septillion combinations.

On Thursday, April 28, 2022 at 5:49:36 PM UTC+8, Mark Ogden wrote:
> On Wednesday, 27 April 2022 at 15:31:02 UTC+1, Nathanael wrote:
> > "I suspect the text files that match the original CRC only do so because the crc tool you are using adds in a missing '\r'"
> > It's an interesting thought, so I ran CRCK.COM under CP/M against vol 59, and got CRCs identical to what cpmcrck gives me under Linux, so I don't think that's the issue. And "dos2unix -i" indicates that the text files in vol 59 all in DOS format. I also opened up several of the text files from vol 59 in a hex editor and verified that they all have 0D0A. So I'm not sure where that leaves me.
> >
> > >> dos2unix -idu sigmv059/*
> >
> > 59 0 sigmv059/CABORT.ASM
> > 83 0 sigmv059/-CATALOG.059
> > 36 0 sigmv059/ENVIRON.DOC
> > 813 0 sigmv059/PBASE
> > 355 0 sigmv059/PISTB.C
> > 113 0 sigmv059/PISTC.C
> > 272 0 sigmv059/PISTD.C
> > 93 0 sigmv059/PISTE.C
> > 265 0 sigmv059/PISTF.C
> > 6 0 sigmv059/PISTGEN.SUB
> > 129 0 sigmv059/PISTOL.C
> > 1248 0 sigmv059/PISTOL.DOC
> > 176 0 sigmv059/PISTOL.H
> > 1745 0 sigmv059/PISTOL.PAS
> > 7 0 sigmv059/PISTSUB.SUB
> > 193 0 sigmv059/READ.ME
> > 192 0 sigmv059/SESSION0.DOC
> > 377 0 sigmv059/SESSION1.DOC
> > 62 0 sigmv059/SIG_M.LIB
> >> Text Removed <<
> Nathanael
> You can see the dos->unix issue I noted in VOL100
> As to the issues on VOL059, I suspect the problem relates to padding the sector after the control Z that marks the end of the text file.
> The files in the directory are truncated to remove the control Z and any padding. CP/M only requires the single control Z to mark the end of the text file,
> everything after that can be rubbish, although with common buffer management, it may be a copy of some previously emitted data. With the -t option
> the unix crck version pads to the end of the sector with Control Z.
> A consequence of this is that you are unlikely to match the CRC unless you can recreate the original padding.
> Even in the bast case if the data end data is a copy of previously emitted data, you would need to identify which
> sector it overwrote.
> For short files you could try padding with 0 after adding a control Z assuming internal buffers were initialised to zero.
> Mark

On 4/28/22 22:59, Nathanael wrote:
>
> I pull vol 100 from the CPMDOSGG collection, which doesn’t suffer from the
> issue. There are around 80 or 90 files I haven’t been able to fix the CRCs
> on; particularly vols 59 and 80. None of the extant sources have provided a
> solution. I’m hoping Steven Hirsch might be able to run CRCs on his copies
> of those two vols to see if he can get good CRC values.
I'm dealing with some family issues here, but will try to dig out those disks
next week.

No problem. When it’s convenient.

The three sources which preserve vol 59 have identical (bad) CRCs. Ditto for vol 80, except that CPMDOSGG also have vol 80 with different (though again wrong) CRCs. I’m interested in whether the CRCs of your version match anything we’ve already got.

On Friday, April 29, 2022 at 8:31:45 PM UTC+8, Steven Hirsch wrote:
> On 4/28/22 22:59, Nathanael wrote:
> >
> > I pull vol 100 from the CPMDOSGG collection, which doesn’t suffer from the
> > issue. There are around 80 or 90 files I haven’t been able to fix the CRCs
> > on; particularly vols 59 and 80. None of the extant sources have provided a
> > solution. I’m hoping Steven Hirsch might be able to run CRCs on his copies
> > of those two vols to see if he can get good CRC values.
> I'm dealing with some family issues here, but will try to dig out those disks
> next week.

Am 04/30/2022 05:21 AM, Nathanael schrieb:
> No problem. When it’s convenient.
>
> The three sources which preserve vol 59 have identical (bad) CRCs.

Hi, Nathanael!

Got lucky with the idea, the files must be archived in other places.

The following leads to the correct CRCs for Volume 59.

Most of the files are also in the DOSgg collection, CPM06/627!
And the CRC are correct!

But one file is missing: READ.ME

This one was really hard, until I found the READ.ME for
PISTOL V2.0 in DOSgg collection, CPM11/1114!

Inspecting the padding of this file reveals the inner working
of the editor. The buffer size must be 1024 Bytes.

So, converting READ.ME from LF to CR/LF line endings, padding with
a single CTRL-Z and the rest of the block from 1024 Bytes above....

I couldn't believe it, the CRC is correct !!!

Hth, Martin

Am 04/30/2022 08:57 PM, Martin schrieb:
> Am 04/30/2022 05:21 AM, Nathanael schrieb:
>> No problem. When it’s convenient.
>>
>> The three sources which preserve vol 59 have identical (bad) CRCs.
>
> Hi, Nathanael!
>
> Got lucky with the idea, the files must be archived in other places.
>
> The following leads to the correct CRCs for Volume 59.
>
> Most of the files are also in the DOSgg collection, CPM06/627!
> And the CRC are correct!
>
> But one file is missing: READ.ME
>
> This one was really hard, until I found the READ.ME for
> PISTOL V2.0 in DOSgg collection, CPM11/1114!
>
> Inspecting the padding of this file reveals the inner working
> of the editor. The buffer size must be 1024 Bytes.
>
> So, converting READ.ME from LF to CR/LF line endings, padding with
> a single CTRL-Z and the rest of the block from 1024 Bytes above....
>
> I couldn't believe it, the CRC is correct !!!
>
> Hth, Martin
>

Then looking into Volume 80...

Took all the files from DOSgg CPM10/1080.

Two files with wrong CRC remaining:
PINUP82.CAL
SIGHTRED.COM

Both are archived with the correct CRC on the CP/M CDROM or
the OAK archive.

Martin

P.S.:
Since it was quite easy to find the correct CRCs,
did I miss something and your problems with
Volume 59 and 80 lay elsewhere ???

Excellent work! Thanks.

I’ll take a closer look when I get home after work. I’m not sure why I missed vol 80 of CPMDOSGG, as I do pull from CPMDOSGG for other volumes. In fact I explicitly mentioned it in my post to Steven Hirsch upthread, but said there it’s got the wrong CRCs.

Thanks again.

—nathanael

On Sunday, May 1, 2022 at 1:24:47 PM UTC+8, Martin wrote:
> Am 04/30/2022 08:57 PM, Martin schrieb:
> > Am 04/30/2022 05:21 AM, Nathanael schrieb:
> >> No problem. When it’s convenient.
> >>
> >> The three sources which preserve vol 59 have identical (bad) CRCs.
> >
> > Hi, Nathanael!
> >
> > Got lucky with the idea, the files must be archived in other places.
> >
> > The following leads to the correct CRCs for Volume 59.
> >
> > Most of the files are also in the DOSgg collection, CPM06/627!
> > And the CRC are correct!
> >
> > But one file is missing: READ.ME
> >
> > This one was really hard, until I found the READ.ME for
> > PISTOL V2.0 in DOSgg collection, CPM11/1114!
> >
> > Inspecting the padding of this file reveals the inner working
> > of the editor. The buffer size must be 1024 Bytes.
> >
> > So, converting READ.ME from LF to CR/LF line endings, padding with
> > a single CTRL-Z and the rest of the block from 1024 Bytes above....
> >
> > I couldn't believe it, the CRC is correct !!!
> >
> > Hth, Martin
> >
> Then looking into Volume 80...
>
> Took all the files from DOSgg CPM10/1080.
>
> Two files with wrong CRC remaining:
> PINUP82.CAL
> SIGHTRED.COM
>
> Both are archived with the correct CRC on the CP/M CDROM or
> the OAK archive.
>
> Martin
>
>
> P.S.:
> Since it was quite easy to find the correct CRCs,
> did I miss something and your problems with
> Volume 59 and 80 lay elsewhere ???

Thanks again for the help. I’ve managed to whittle the list of non-matching CRCs down to eighteen files, most of which are on volumes 281 and 285, for which I have so far not found uncorrupted versions. So Steven, when time permits, could you take a look at your copies of those volumes if you have them, rather than vols 59 and 80? Much appreciated.

Martin, could you give more detail as to how you recovered vol 59’s READ.ME? You say, for example, you converted it from LF to CR/LF, but all the copies of 59’s READ.ME I’ve looked at are already in DOS format. WhatREAD.ME did you start with?

On Sunday, May 1, 2022 at 2:58:23 AM UTC+8, Martin wrote:
> Am 04/30/2022 05:21 AM, Nathanael schrieb:
> > No problem. When it’s convenient.
> >
> > The three sources which preserve vol 59 have identical (bad) CRCs.
> Hi, Nathanael!
>
> Got lucky with the idea, the files must be archived in other places.
>
> The following leads to the correct CRCs for Volume 59.
>
> Most of the files are also in the DOSgg collection, CPM06/627!
> And the CRC are correct!
>
> But one file is missing: READ.ME
>
> This one was really hard, until I found the READ.ME for
> PISTOL V2.0 in DOSgg collection, CPM11/1114!
>
> Inspecting the padding of this file reveals the inner working
> of the editor. The buffer size must be 1024 Bytes.
>
> So, converting READ.ME from LF to CR/LF line endings, padding with
> a single CTRL-Z and the rest of the block from 1024 Bytes above....
>
> I couldn't believe it, the CRC is correct !!!
>
> Hth, Martin

Ohhhh... :-)

I repeated the steps, and also found, that this step is not necessary.
In retrospect, I probably somehow converted the file from CR/LF to LF
without noticing and later took it as the original.

So, please ignore that step, it is *NOT* necessary.
I updated my notes.

Thanks for letting me know
Martin

Am 05/06/2022 03:58 AM, Nathanael schrieb:
> Martin, could you give more detail as to how you recovered vol 59’s READ.ME?
You say, for example, you converted it from LF to CR/LF, but all the
copies of 59’s
READ.ME I’ve looked at are already in DOS format. WhatREAD.ME did you
start with?

On Friday, 6 May 2022 at 02:58:03 UTC+1, Nathanael wrote:
> Thanks again for the help. I’ve managed to whittle the list of non-matching CRCs down to eighteen files, most of which are on volumes 281 and 285, for which I have so far not found uncorrupted versions. So Steven, when time permits, could you take a look at your copies of those volumes if you have them, rather than vols 59 and 80? Much appreciated.
>
> Martin, could you give more detail as to how you recovered vol 59’s READ.ME? You say, for example, you converted it from LF to CR/LF, but all the copies of 59’s READ.ME I’ve looked at are already in DOS format. WhatREAD.ME did you start with?
> On Sunday, May 1, 2022 at 2:58:23 AM UTC+8, Martin wrote:
> > Am 04/30/2022 05:21 AM, Nathanael schrieb:
> > > No problem. When it’s convenient.
> > >
> > > The three sources which preserve vol 59 have identical (bad) CRCs.
> > Hi, Nathanael!
> >
> > Got lucky with the idea, the files must be archived in other places.
> >
> > The following leads to the correct CRCs for Volume 59.
> >
> > Most of the files are also in the DOSgg collection, CPM06/627!
> > And the CRC are correct!
> >
> > But one file is missing: READ.ME
> >
> > This one was really hard, until I found the READ.ME for
> > PISTOL V2.0 in DOSgg collection, CPM11/1114!
> >
> > Inspecting the padding of this file reveals the inner working
> > of the editor. The buffer size must be 1024 Bytes.
> >
> > So, converting READ.ME from LF to CR/LF line endings, padding with
> > a single CTRL-Z and the rest of the block from 1024 Bytes above....
> >
> > I couldn't believe it, the CRC is correct !!!
> >
> > Hth, Martin
Nathanael
It is likely that text files that don't match the CRC are not actually corrupt. Two scenarios exist
1) The file had junk after the Control Z, which normal processing would ignore. Unfortunately, the CP/M CRC tool includes the junk in its calculation. Many of the distributed text files excluded the control Z and any characters after it. Some also converted \r\n to \n to align with Unix conventions.
2) If the files were created on later versions of CP/M or MSDOS which supported true file length, the CRCs used, may be those of the file content only and not padded to 128 bytes. The unix based crck tool always pads text files. It may be worth checking the CRC assuming a binary file - note you may need to do \n to \r\n conversion before doing this.

PS. I did a compare of all of the files on vol281 and for those which appear in the catalog file, all of the CRCs match using my perl script version of crck, which intelligently looks for text vs. binary and for unix text file formats. In vol 285, there are 7 text files that have different CRCs, otherwise all match.

Mark

Hello Mark Odgen,

On Fri, 6 May 2022 11:12:24 -0700 (PDT)
Mark Ogden <ogdenpm@gmail.com> wrote:
>
....
>
> PS. I did a compare of all of the files on vol281 and for those which appear in the catalog file, all of the CRCs match using my perl script version of crck, which intelligently looks for text vs. binary and for unix text file formats. In vol 285, there are 7 text files that have different CRCs, otherwise all match.
>
>
> Mark

Is this perl script of crck free?
Where can I get the perl script and documentation how to use it?

Best Regards
Andreas

--
University of Ulm, Germany
Dipl.-Ing. (FH) Andreas Gerlich
Open Source Project: Yet Another Z80 Emulator by AG (YAZE-AG)
www.yaze-ag.de

Am 05/06/2022 04:30 AM, Martin schrieb:
> Ohhhh... :-)
>
> I repeated the steps, and also found, that this step is not necessary.
> In retrospect, I probably somehow converted the file from CR/LF to LF
> without noticing and later took it as the original.
>
> So, please ignore that step, it is *NOT* necessary.
> I updated my notes.
>
> Thanks for letting me know
> Martin
>
>
>
> Am 05/06/2022 03:58 AM, Nathanael schrieb:
>> Martin, could you give more detail as to how you recovered vol 59’s
>> READ.ME?
> You say, for example, you converted it from LF to CR/LF, but all the
> copies of 59’s
> READ.ME I’ve looked at are already in DOS format. WhatREAD.ME did you
> start with?
>

Good news !!!

I have found the necessary conversions to get the missing files
with matching CRCs.

To keep it short and easy to reproduce,
here are my shell scripts.

VOL281_fix.sh:
==== 8< ====
FILES="CMPCODE.DOC SNOOPY.FOR ZLOAD.DOC"

# convert to CR/LF, fill with EOF to CP/M block size
for x in $FILES
do
todos <$x | dd ibs=128 iflag=fullblock conv=sync | tr \\000 \\032 >$x.fixed
done

# FORT07.DAT is special
# first part: fixed length records with CR, don't touch
dd if=FORT07.DAT of=FORT07.DAT.part1 bs=1 count=7080
# second part: text with LF, convert to CR/LF
dd if=FORT07.DAT bs=1 skip=7080 | todos >FORT07.DAT.part2
# combine, fill with EOF to CP/M block size
cat FORT07.DAT.part1 FORT07.DAT.part2 | dd ibs=128 iflag=fullblock conv=sync | tr \\000 \\032 >FORT07.DAT.fixed
# cleanup
rm FORT07.DAT.part1 FORT07.DAT.part2

# if crck is available
#crck *.fixed
==== 8< ====

VOL285_fix.sh:
==== 8< ====
FILES="BRIEF-TS.HOW BROWSE.DOC CURSOR.ASM WORD-KEY.FIX SAVEREST.ASM SAVEREST.DOC TWENTY.ASM"

# convert to CR/LF, append one EOF, fill with NUL to CP/M block size
for x in $FILES
do
( todos <$x; printf "\\032" ) | dd ibs=128 iflag=fullblock conv=sync >$x.fixed
done

# if crck is available
#crck *.fixed
==== 8< ====

On Saturday, 7 May 2022 at 01:00:28 UTC+1, Andreas Gerlich wrote:
> Hello Mark Odgen,
>
> On Fri, 6 May 2022 11:12:24 -0700 (PDT)
> Mark Ogden <ogd...@gmail.com> wrote:
> >
> ...
> >
> > PS. I did a compare of all of the files on vol281 and for those which appear in the catalog file, all of the CRCs match using my perl script version of crck, which intelligently looks for text vs. binary and for unix text file formats. In vol 285, there are 7 text files that have different CRCs, otherwise all match.
> >
> >
> > Mark
> Is this perl script of crck free?
> Where can I get the perl script and documentation how to use it?
>
> Best Regards
> Andreas
>
> --
> University of Ulm, Germany
> Dipl.-Ing. (FH) Andreas Gerlich
> Open Source Project: Yet Another Z80 Emulator by AG (YAZE-AG)
> www.yaze-ag.de
Andreas
The perl script was something that I wrote in a few minutes to initially allow me to check for different text file formats.
I have added a few comments to help others understand and posted it at

https://mark-ogden.uk/files/crck.pl

Mark

@Martin: fantastic! Thanks to some hints from Mark, I finished vol 281 this morning (FORT07.DAT didn’t need any special processing for me):

for i in CMPCODE.DOC SNOOPY.FOR ZLOAD.DOC FORT07.DAT; do
unix2dos $i
done

But I’d been working on vol 285 all day with no luck. Your converting to DOS, adding a single 1AH then padding with nulls rather than Ctrl-Zwas the secret. Fantastic. Thanks!

For i in BRIEF-TS.HOW BROWSE.DOC CURSOR.ASM SAVEREST.ASM \
SAVEREST.DOC TWENTY.ASM WORD-KEY.FIX

do
printf “%b” ‘\x1A’ >> $i
count=$(( 128 - $(ls -l $i | cut -d’ ‘ -f5) % 128 ))
[[ $count -eq 128 ]] && count=0
for (( c=1; c<=$count; c++ )); do printf “%b” ‘\x00’ >> $i; done
done

But I’m still not following your discussion on vol 59’s READ.ME.

> padding with a single CTRL-Z and the rest of the block from 1024 Bytes above

The READ.ME from vol 59 of CPMDOSGG already ends with 40 bytes of 1AH, so did you mean adding a Ctrl-Z to a different file?

I also don’t know what “the rest of the block from 1024” means.

—nathanael

On Saturday, May 7, 2022 at 5:18:29 PM UTC+8, Martin wrote:
> Am 05/06/2022 04:30 AM, Martin schrieb:
> > Ohhhh... :-)
> >
> > I repeated the steps, and also found, that this step is not necessary.
> > In retrospect, I probably somehow converted the file from CR/LF to LF
> > without noticing and later took it as the original.
> >
> > So, please ignore that step, it is *NOT* necessary.
> > I updated my notes.
> >
> > Thanks for letting me know
> > Martin
> >
> >
> >
> > Am 05/06/2022 03:58 AM, Nathanael schrieb:
> >> Martin, could you give more detail as to how you recovered vol 59’s
> >> READ.ME?
> > You say, for example, you converted it from LF to CR/LF, but all the
> > copies of 59’s
> > READ.ME I’ve looked at are already in DOS format. WhatREAD.ME did you
> > start with?
> >
> Good news !!!
>
> I have found the necessary conversions to get the missing files
> with matching CRCs.
>
> To keep it short and easy to reproduce,
> here are my shell scripts.
>
>
> VOL281_fix.sh:
> ==== 8< ====
> FILES="CMPCODE.DOC SNOOPY.FOR ZLOAD.DOC"
>
> # convert to CR/LF, fill with EOF to CP/M block size
> for x in $FILES
> do
> todos <$x | dd ibs=128 iflag=fullblock conv=sync | tr \\000 \\032 >$x.fixed
> done
>
> # FORT07.DAT is special
> # first part: fixed length records with CR, don't touch
> dd if=FORT07.DAT of=FORT07.DAT.part1 bs=1 count=7080
> # second part: text with LF, convert to CR/LF
> dd if=FORT07.DAT bs=1 skip=7080 | todos >FORT07.DAT.part2
> # combine, fill with EOF to CP/M block size
> cat FORT07.DAT.part1 FORT07.DAT.part2 | dd ibs=128 iflag=fullblock conv=sync | tr \\000 \\032 >FORT07.DAT.fixed
> # cleanup
> rm FORT07.DAT.part1 FORT07.DAT.part2
>
> # if crck is available
> #crck *.fixed
> ==== 8< ====
>
>
> VOL285_fix.sh:
> ==== 8< ====
> FILES="BRIEF-TS.HOW BROWSE.DOC CURSOR.ASM WORD-KEY.FIX SAVEREST.ASM SAVEREST.DOC TWENTY.ASM"
>
> # convert to CR/LF, append one EOF, fill with NUL to CP/M block size
> for x in $FILES
> do
> ( todos <$x; printf "\\032" ) | dd ibs=128 iflag=fullblock conv=sync >$x.fixed
> done
>
> # if crck is available
> #crck *.fixed
> ==== 8< ===

Hello Mark,

thank you for the crck.pl.

Best Regards
Andreas

On Sat, 7 May 2022 02:19:11 -0700 (PDT)
Mark Ogden <ogdenpm@gmail.com> wrote:

> Andreas
> The perl script was something that I wrote in a few minutes to initially allow me to check for different text file formats.
> I have added a few comments to help others understand and posted it at
>
> https://mark-ogden.uk/files/crck.pl
>
> Mark

--
University of Ulm, Germany
Dipl.-Ing. (FH) Andreas Gerlich
Open Source Project: Yet Another Z80 Emulator by AG (YAZE-AG)
www.yaze-ag.de

Am 05/07/2022 02:25 PM, Nathanael schrieb:
> But I’m still not following your discussion on vol 59’s READ.ME.
>
>> padding with a single CTRL-Z and the rest of the block from 1024 Bytes above
>
> The READ.ME from vol 59 of CPMDOSGG already ends with 40 bytes of 1AH, so did you mean adding a Ctrl-Z to a different file?
>
> I also don’t know what “the rest of the block from 1024” means.
>
> —nathanael
>

I try my best to explain it better :-)

There is no DOSGG Volume 59, CPM10/1059 is missing.

I found most of Volume 59 it in CPM06/627, but there,
READ.ME is missing.

I had to fix the READ.ME from SIGMV059.ARK.

As I already wrote, this file is in CR/LF format and
it is not padded with EOF.

This is the file I used.

So, hands on ...

This is the last part of the unmodified READ.ME:
000019d0 72 67 6d 61 6e 6e 0d 0a |rgmann..|

And here is the part 1024 bytes above, where I took the padding bytes:
000015d0 6c 22 20 74 6f 20 74 68 65 0d 0a 64 65 66 69 6e |l" to the..defin|
000015e0 69 74 69 6f 6e 2e 0d 0a 0d 0a 09 41 20 6e 75 6d |ition......A num|
000015f0 62 65 72 20 6f 66 20 63 6f 6e 76 65 6e 69 65 6e |ber of convenien|

So, after adding on EOF and padding with the bytes from above:
000019d0 72 67 6d 61 6e 6e 0d 0a 1a 0d 0a 64 65 66 69 6e |rgmann.....defin|
000019e0 69 74 69 6f 6e 2e 0d 0a 0d 0a 09 41 20 6e 75 6d |ition......A num|
000019f0 62 65 72 20 6f 66 20 63 6f 6e 76 65 6e 69 65 6e |ber of convenien|

The CRC is ok :-)

Am 05/07/2022 07:18 PM, Martin schrieb:
> Am 05/07/2022 02:25 PM, Nathanael schrieb:
>> But I’m still not following your discussion on vol 59’s READ.ME.
>>
>>> padding with a single CTRL-Z and the rest of the block from 1024 Bytes above
>>
>> The READ.ME from vol 59 of CPMDOSGG already ends with 40 bytes of 1AH, so did you mean adding a Ctrl-Z to a different file?
>>
>> I also don’t know what “the rest of the block from 1024” means.
>>
>> —nathanael
>>
>

Forget it :-)

Found the missing READ.ME in DOSGG CPM06/627, but named #HISTORY.018.

This file *IS* the missing READ.ME.

Copy, rename, done!

@Steven — Thanks for uploading vols 59 and 80. After looking briefly at the volumes you’ve uploaded to Dropbox, they strongly resemble CPMDOSgg, but your collection may be even earlier. In every case, yours matches the original CRCs in -CATALOG. Also, CPMDOSgg is missing a number of vols, including 59.

V59: only yours matches the original CRCs in -CATALOG.

V80: yours and CPMDOSgg both match original CRCs, but someone seems to have inadvertently mixed v80 and 81 together in CPMDOSgg.

V184-192: CPMDOSgg is the only other source. Yours is identical; both match original CRCs.

V226: CPMDOSgg is the only other complete source; both it and yours match original CRCs.

Do you know the source of your disks? Based on what you’ve uploaded, your collection seems to be more pristine than any of the other sources. Don’t lose them! :)

On Friday, April 29, 2022 at 8:31:45 PM UTC+8, Steven Hirsch wrote:
> On 4/28/22 22:59, Nathanael wrote:
> >
> > I pull vol 100 from the CPMDOSGG collection, which doesn’t suffer from the
> > issue. There are around 80 or 90 files I haven’t been able to fix the CRCs
> > on; particularly vols 59 and 80. None of the extant sources have provided a
> > solution. I’m hoping Steven Hirsch might be able to run CRCs on his copies
> > of those two vols to see if he can get good CRC values.
> I'm dealing with some family issues here, but will try to dig out those disks
> next week.

Good detective work:)

V59 is done. Only four more files to go. Thanks.

On Sunday, May 8, 2022 at 1:56:30 AM UTC+8, Martin wrote:
> Am 05/07/2022 07:18 PM, Martin schrieb:
> > Am 05/07/2022 02:25 PM, Nathanael schrieb:
> >> But I’m still not following your discussion on vol 59’s READ.ME.
> >>
> >>> padding with a single CTRL-Z and the rest of the block from 1024 Bytes above
> >>
> >> The READ.ME from vol 59 of CPMDOSGG already ends with 40 bytes of 1AH, so did you mean adding a Ctrl-Z to a different file?
> >>
> >> I also don’t know what “the rest of the block from 1024” means.
> >>
> >> —nathanael
> >>
> >
> Forget it :-)
>
> Found the missing READ.ME in DOSGG CPM06/627, but named #HISTORY.018.
>
> This file *IS* the missing READ.ME.
>
> Copy, rename, done!