On Sunday, May 15, 2022 at 5:35:17 PM UTC+8, Martin wrote:
> Am 05/15/2022 02:47 AM, Nathanael schrieb:
> > Thanks for the attempt. Unfortunately, it has the same corruption.
> >
> > FYI, for IMDU files, I use Dave Dunfield’s IMDU, then cpmtools to extract the files:
> >
> > imdu SIGM54.IMD SIGM54.RAW -b -e -d
> > cpmcp -f IBM-3740 SIGM54.RAW 0:*.* ./
> >
> >
> > On Sunday, May 15, 2022 at 12:10:12 AM UTC+8, santo.n...@gmail.com wrote:
> >> Nathaneal,
> >> Try this archive. I don't know how to work with extracting files from IMD archives but I hope this has the file you are looking for.
> >>
> >> https://vintagecomputer.ca/files/SIGM/SIGM54.IMD
> >>
> >> Santo
> >> On Saturday, May 14, 2022 at 12:24:42 AM UTC-4, Nathanael wrote:
> >>> On closer inspection, vol 54’s TTBOOT.ASM and TTCBIOS.ASM are not Thinker Toy software, but independent patches by Jack Burge; so I don’t think tracking down Thinker Toy documentation is going to turn anything up.
> >>>
> >>> It’s pretty clear what’s missing is just a few lines of comment at the top of the file, so the actually utility of the file isn’t impacted. But it’d be nice to get it cleaned up anyway.
> >>>
> >>> Putting out a call on th S100 forum sounds like a good idea, though.
> Hi Nathanael, what about this?
>
> We create a preliminary fix until the original finally appears.
>
> The beginnings of TTCBIOS and TTBOOT are very similar.
>
> The content of TTCBIOS.ASM from line 2 to the end of the corruption
> fits perfectly into most of the first sector of TTBOOT.ASM.
>
> Now, we only need to find a nice replacement for the (I assume) single
> line before containing the filename.
>
> We have 21 Bytes available...
>
> What about this:
> 1) We replace the TAB before the filename with SPACEs
> 2) We put the remaining byte as a SPACE after the filename
>
> The idea for this came from real life situations.
> It often happens that a TAB gets replaced by SPACEs,
> also a trailing SPACEs could remain after changing
> the filename from TTCBIOS.ASM to TTBOOT.ASM :-)
>
> 0000: 3B 20 20 20 20 20 20 20 54 54 42 4F 4F 54 2E 41
> 0010: 53 4D 20 0D 0A
>
>
> Putting everything together, the first sector looks like this:
>
> 0000: 3b 20 20 20 20 20 20 20 54 54 42 4f 4f 54 2e 41 ; TTBOOT.A
> 0010: 53 4d 20 0d 0a 3b 0d 0a 3b 0d 0a 3b 0d 0a 3b 20 SM ..;..;..;..;
> 0020: 20 20 20 20 20 4f 72 69 67 69 6e 61 6c 20 63 6f Original co
> 0030: 64 69 6e 67 20 62 79 3a 20 20 54 68 69 6e 6b 65 ding by: Thinke
> 0040: 72 20 54 6f 79 73 0d 0a 3b 09 09 09 20 20 20 20 r Toys..;...
> 0050: 52 69 63 68 6d 6f 6e 64 2c 20 43 41 0d 0a 3b 0d Richmond, CA..;.
> 0060: 0a 3b 0d 0a 3b 20 20 20 20 20 20 20 50 61 74 63 .;..; Patc
> 0070: 68 69 6e 67 20 74 6f 20 6d 69 6e 69 6d 69 7a 65 hing to minimize
>
>
> Hth
> Martin

While it's a worthy undertaking in its own right, I feel like presenting a speculative reconstruction is outside the scope of the project, unless we can manage to come up with something that matches the original CRC.

However, I note that the opening two lines of TTBOOT.ASM:

ER.LOG although it may be
; physically appended to it)...Note: You must type I/O-CAP<cr>

are repeated in I_O-CAP.ASM, lines 104 and 105.

Given that the current file is 2304 bytes, or exactly 18 records, it's safe to assume the first record has gone missing, which means we have 128 bytes to fill in.

I have completed a first-pass manual inspection of all volumes, so I'm going to declare v1.0 of the SIG/M Restoration Project complete. Doesn't mean I won't continue to tweak it now and again (and feel free to raise any issues), but at a slower pace.

Again, for anyone who may be interested, I've posted the BASH script and support files at https://github.com/CPMArchives/SIGM. I will also put the cleaned up collection up at *HUMONGOUS*, and create an ISO for ease of downloading.

Thanks, everyone, for your help.

--nathanael
The *HUMONGOUS* CP/M Archives
cpmarchives.classiccmp.org

On Monday, 16 May 2022 at 16:54:04 UTC+1, Nathanael wrote:
> On Sunday, May 15, 2022 at 5:35:17 PM UTC+8, Martin wrote:
> > Am 05/15/2022 02:47 AM, Nathanael schrieb:
> > > Thanks for the attempt. Unfortunately, it has the same corruption.
> > >
> > > FYI, for IMDU files, I use Dave Dunfield’s IMDU, then cpmtools to extract the files:
> > >
> > > imdu SIGM54.IMD SIGM54.RAW -b -e -d
> > > cpmcp -f IBM-3740 SIGM54.RAW 0:*.* ./
> > >
> > >
> > > On Sunday, May 15, 2022 at 12:10:12 AM UTC+8, santo.n...@gmail.com wrote:
> > >> Nathaneal,
> > >> Try this archive. I don't know how to work with extracting files from IMD archives but I hope this has the file you are looking for.
> > >>
> > >> https://vintagecomputer.ca/files/SIGM/SIGM54.IMD
> > >>
> > >> Santo
> > >> On Saturday, May 14, 2022 at 12:24:42 AM UTC-4, Nathanael wrote:
> > >>> On closer inspection, vol 54’s TTBOOT.ASM and TTCBIOS.ASM are not Thinker Toy software, but independent patches by Jack Burge; so I don’t think tracking down Thinker Toy documentation is going to turn anything up.
> > >>>
> > >>> It’s pretty clear what’s missing is just a few lines of comment at the top of the file, so the actually utility of the file isn’t impacted. But it’d be nice to get it cleaned up anyway.
> > >>>
> > >>> Putting out a call on th S100 forum sounds like a good idea, though..
> > Hi Nathanael, what about this?
> >
> > We create a preliminary fix until the original finally appears.
> >
> > The beginnings of TTCBIOS and TTBOOT are very similar.
> >
> > The content of TTCBIOS.ASM from line 2 to the end of the corruption
> > fits perfectly into most of the first sector of TTBOOT.ASM.
> >
> > Now, we only need to find a nice replacement for the (I assume) single
> > line before containing the filename.
> >
> > We have 21 Bytes available...
> >
> > What about this:
> > 1) We replace the TAB before the filename with SPACEs
> > 2) We put the remaining byte as a SPACE after the filename
> >
> > The idea for this came from real life situations.
> > It often happens that a TAB gets replaced by SPACEs,
> > also a trailing SPACEs could remain after changing
> > the filename from TTCBIOS.ASM to TTBOOT.ASM :-)
> >
> > 0000: 3B 20 20 20 20 20 20 20 54 54 42 4F 4F 54 2E 41
> > 0010: 53 4D 20 0D 0A
> >
> >
> > Putting everything together, the first sector looks like this:
> >
> > 0000: 3b 20 20 20 20 20 20 20 54 54 42 4f 4f 54 2e 41 ; TTBOOT.A
> > 0010: 53 4d 20 0d 0a 3b 0d 0a 3b 0d 0a 3b 0d 0a 3b 20 SM ..;..;..;..;
> > 0020: 20 20 20 20 20 4f 72 69 67 69 6e 61 6c 20 63 6f Original co
> > 0030: 64 69 6e 67 20 62 79 3a 20 20 54 68 69 6e 6b 65 ding by: Thinke
> > 0040: 72 20 54 6f 79 73 0d 0a 3b 09 09 09 20 20 20 20 r Toys..;...
> > 0050: 52 69 63 68 6d 6f 6e 64 2c 20 43 41 0d 0a 3b 0d Richmond, CA..;.
> > 0060: 0a 3b 0d 0a 3b 20 20 20 20 20 20 20 50 61 74 63 .;..; Patc
> > 0070: 68 69 6e 67 20 74 6f 20 6d 69 6e 69 6d 69 7a 65 hing to minimize
> >
> >
> > Hth
> > Martin
> While it's a worthy undertaking in its own right, I feel like presenting a speculative reconstruction is outside the scope of the project, unless we can manage to come up with something that matches the original CRC.
>
> However, I note that the opening two lines of TTBOOT.ASM:
>
> ER.LOG although it may be
> ; physically appended to it)...Note: You must type I/O-CAP<cr>
>
> are repeated in I_O-CAP.ASM, lines 104 and 105.
>
> Given that the current file is 2304 bytes, or exactly 18 records, it's safe to assume the first record has gone missing, which means we have 128 bytes to fill in.
Nathanael
I suspect most of the first 128 bytes are similar to TTCBIOS.ASM with the name replaced, as the remaining header is the same Unfortunately this leaves 5 characters unaccounted for, although cr/lf may account for at least 2 characters.
Mark

All the work done is fantastic.

For the purist recovery means restoration to an extreme certainty. Restoring to something that works is not good enough.

I agree it's best to leave it as is since it is easy to edit and use if desired and easy to see it's incomplete, so no one is fooled into believing it's a complete history.

The point of the full archive has multiple uses:

Much is still useful.
It is history and as a digital document should be restored to as close as historically correct as possible.
It is a window into both the individual's that wrote the software and the group think of the time.

We can look back 50 years and see what ideas were lost and what ideas we have achieved since. in a hundred years I hope the archive still exists whether this one file gets restored or not.

Again a fantastic job and a reminder those of us that have CP/M software and documentation it is a duty to preserve it via appropriate archives.

Randy

> I suspect most of the first 128 bytes are similar to TTBIOS.ASM with the name replaced, as the remaining header is the same

Seems reasonable, however as noted in my previous post, there’s the bit that doesn’t occur in the TTBIOS header but rather seems pulled from I_O-CAP.ASM. There’s also that bit referencing cp/m 2.2 (from memory; I don’t have it in front of me ATM) that’s not in TTBIOS.ASM. So the question is *how* similar?

Mark Ogden wrote:
> On Monday, 16 May 2022 at 16:54:04 UTC+1, Nathanael wrote:
> > On Sunday, May 15, 2022 at 5:35:17 PM UTC+8, Martin wrote:
> > > Am 05/15/2022 02:47 AM, Nathanael schrieb:
> > > > Thanks for the attempt. Unfortunately, it has the same corruption.
> > > >
> > > > FYI, for IMDU files, I use Dave Dunfield’s IMDU, then cpmtools to extract the files:
> > > >
> > > > imdu SIGM54.IMD SIGM54.RAW -b -e -d
> > > > cpmcp -f IBM-3740 SIGM54.RAW 0:*.* ./
> > > >
> > > >
> > > > On Sunday, May 15, 2022 at 12:10:12 AM UTC+8, santo.n...@gmail.com wrote:
> > > >> Nathaneal,
> > > >> Try this archive. I don't know how to work with extracting files from IMD archives but I hope this has the file you are looking for.
> > > >>
> > > >> https://vintagecomputer.ca/files/SIGM/SIGM54.IMD
> > > >>
> > > >> Santo
> > > >> On Saturday, May 14, 2022 at 12:24:42 AM UTC-4, Nathanael wrote:
> > > >>> On closer inspection, vol 54’s TTBOOT.ASM and TTCBIOS.ASM are not Thinker Toy software, but independent patches by Jack Burge; so I don’t think tracking down Thinker Toy documentation is going to turn anything up.
> > > >>>
> > > >>> It’s pretty clear what’s missing is just a few lines of comment at the top of the file, so the actually utility of the file isn’t impacted. But it’d be nice to get it cleaned up anyway.
> > > >>>
> > > >>> Putting out a call on th S100 forum sounds like a good idea, though.
> > > Hi Nathanael, what about this?
> > >
> > > We create a preliminary fix until the original finally appears.
> > >
> > > The beginnings of TTCBIOS and TTBOOT are very similar.
> > >
> > > The content of TTCBIOS.ASM from line 2 to the end of the corruption
> > > fits perfectly into most of the first sector of TTBOOT.ASM.
> > >
> > > Now, we only need to find a nice replacement for the (I assume) single
> > > line before containing the filename.
> > >
> > > We have 21 Bytes available...
> > >
> > > What about this:
> > > 1) We replace the TAB before the filename with SPACEs
> > > 2) We put the remaining byte as a SPACE after the filename
> > >
> > > The idea for this came from real life situations.
> > > It often happens that a TAB gets replaced by SPACEs,
> > > also a trailing SPACEs could remain after changing
> > > the filename from TTCBIOS.ASM to TTBOOT.ASM :-)
> > >
> > > 0000: 3B 20 20 20 20 20 20 20 54 54 42 4F 4F 54 2E 41
> > > 0010: 53 4D 20 0D 0A
> > >
> > >
> > > Putting everything together, the first sector looks like this:
> > >
> > > 0000: 3b 20 20 20 20 20 20 20 54 54 42 4f 4f 54 2e 41 ; TTBOOT.A
> > > 0010: 53 4d 20 0d 0a 3b 0d 0a 3b 0d 0a 3b 0d 0a 3b 20 SM ..;..;..;..;
> > > 0020: 20 20 20 20 20 4f 72 69 67 69 6e 61 6c 20 63 6f Original co
> > > 0030: 64 69 6e 67 20 62 79 3a 20 20 54 68 69 6e 6b 65 ding by: Thinke
> > > 0040: 72 20 54 6f 79 73 0d 0a 3b 09 09 09 20 20 20 20 r Toys..;...
> > > 0050: 52 69 63 68 6d 6f 6e 64 2c 20 43 41 0d 0a 3b 0d Richmond, CA..;..
> > > 0060: 0a 3b 0d 0a 3b 20 20 20 20 20 20 20 50 61 74 63 .;..; Patc
> > > 0070: 68 69 6e 67 20 74 6f 20 6d 69 6e 69 6d 69 7a 65 hing to minimize
> > >
> > >
> > > Hth
> > > Martin
> > While it's a worthy undertaking in its own right, I feel like presenting a speculative reconstruction is outside the scope of the project, unless we can manage to come up with something that matches the original CRC.
> >
> > However, I note that the opening two lines of TTBOOT.ASM:
> >
> > ER.LOG although it may be
> > ; physically appended to it)...Note: You must type I/O-CAP<cr>
> >
> > are repeated in I_O-CAP.ASM, lines 104 and 105.
> >
> > Given that the current file is 2304 bytes, or exactly 18 records, it's safe to assume the first record has gone missing, which means we have 128 bytes to fill in.
> Nathanael
> I suspect most of the first 128 bytes are similar to TTCBIOS.ASM with the name replaced, as the remaining header is the same Unfortunately this leaves 5 characters unaccounted for, although cr/lf may account for at least 2 characters.
> Mark

On Thursday, 19 May 2022 at 08:01:23 UTC+1, Nathanael wrote:
> > I suspect most of the first 128 bytes are similar to TTBIOS.ASM with the name replaced, as the remaining header is the same
>
> Seems reasonable, however as noted in my previous post, there’s the bit that doesn’t occur in the TTBIOS header but rather seems pulled from I_O-CAP.ASM. There’s also that bit referencing cp/m 2.2 (from memory; I don’t have it in front of me ATM) that’s not in TTBIOS.ASM. So the question is *how* similar?
> Mark Ogden wrote:
> > On Monday, 16 May 2022 at 16:54:04 UTC+1, Nathanael wrote:
> > > On Sunday, May 15, 2022 at 5:35:17 PM UTC+8, Martin wrote:
> > > > Am 05/15/2022 02:47 AM, Nathanael schrieb:
> > > > > Thanks for the attempt. Unfortunately, it has the same corruption..
> > > > >
> > > > > FYI, for IMDU files, I use Dave Dunfield’s IMDU, then cpmtools to extract the files:
> > > > >
> > > > > imdu SIGM54.IMD SIGM54.RAW -b -e -d
> > > > > cpmcp -f IBM-3740 SIGM54.RAW 0:*.* ./
> > > > >
> > > > >
> > > > > On Sunday, May 15, 2022 at 12:10:12 AM UTC+8, santo.n...@gmail.com wrote:
> > > > >> Nathaneal,
> > > > >> Try this archive. I don't know how to work with extracting files from IMD archives but I hope this has the file you are looking for.
> > > > >>
> > > > >> https://vintagecomputer.ca/files/SIGM/SIGM54.IMD
> > > > >>
> > > > >> Santo
> > > > >> On Saturday, May 14, 2022 at 12:24:42 AM UTC-4, Nathanael wrote:
> > > > >>> On closer inspection, vol 54’s TTBOOT.ASM and TTCBIOS.ASM are not Thinker Toy software, but independent patches by Jack Burge; so I don’t think tracking down Thinker Toy documentation is going to turn anything up.
> > > > >>>
> > > > >>> It’s pretty clear what’s missing is just a few lines of comment at the top of the file, so the actually utility of the file isn’t impacted. But it’d be nice to get it cleaned up anyway.
> > > > >>>
> > > > >>> Putting out a call on th S100 forum sounds like a good idea, though.
> > > > Hi Nathanael, what about this?
> > > >
> > > > We create a preliminary fix until the original finally appears.
> > > >
> > > > The beginnings of TTCBIOS and TTBOOT are very similar.
> > > >
> > > > The content of TTCBIOS.ASM from line 2 to the end of the corruption
> > > > fits perfectly into most of the first sector of TTBOOT.ASM.
> > > >
> > > > Now, we only need to find a nice replacement for the (I assume) single
> > > > line before containing the filename.
> > > >
> > > > We have 21 Bytes available...
> > > >
> > > > What about this:
> > > > 1) We replace the TAB before the filename with SPACEs
> > > > 2) We put the remaining byte as a SPACE after the filename
> > > >
> > > > The idea for this came from real life situations.
> > > > It often happens that a TAB gets replaced by SPACEs,
> > > > also a trailing SPACEs could remain after changing
> > > > the filename from TTCBIOS.ASM to TTBOOT.ASM :-)
> > > >
> > > > 0000: 3B 20 20 20 20 20 20 20 54 54 42 4F 4F 54 2E 41
> > > > 0010: 53 4D 20 0D 0A
> > > >
> > > >
> > > > Putting everything together, the first sector looks like this:
> > > >
> > > > 0000: 3b 20 20 20 20 20 20 20 54 54 42 4f 4f 54 2e 41 ; TTBOOT.A
> > > > 0010: 53 4d 20 0d 0a 3b 0d 0a 3b 0d 0a 3b 0d 0a 3b 20 SM ..;..;..;...;
> > > > 0020: 20 20 20 20 20 4f 72 69 67 69 6e 61 6c 20 63 6f Original co
> > > > 0030: 64 69 6e 67 20 62 79 3a 20 20 54 68 69 6e 6b 65 ding by: Thinke
> > > > 0040: 72 20 54 6f 79 73 0d 0a 3b 09 09 09 20 20 20 20 r Toys..;...
> > > > 0050: 52 69 63 68 6d 6f 6e 64 2c 20 43 41 0d 0a 3b 0d Richmond, CA...;.
> > > > 0060: 0a 3b 0d 0a 3b 20 20 20 20 20 20 20 50 61 74 63 .;..; Patc
> > > > 0070: 68 69 6e 67 20 74 6f 20 6d 69 6e 69 6d 69 7a 65 hing to minimize
> > > >
> > > >
> > > > Hth
> > > > Martin
> > > While it's a worthy undertaking in its own right, I feel like presenting a speculative reconstruction is outside the scope of the project, unless we can manage to come up with something that matches the original CRC.
> > >
> > > However, I note that the opening two lines of TTBOOT.ASM:
> > >
> > > ER.LOG although it may be
> > > ; physically appended to it)...Note: You must type I/O-CAP<cr>
> > >
> > > are repeated in I_O-CAP.ASM, lines 104 and 105.
> > >
> > > Given that the current file is 2304 bytes, or exactly 18 records, it's safe to assume the first record has gone missing, which means we have 128 bytes to fill in.
> > Nathanael
> > I suspect most of the first 128 bytes are similar to TTCBIOS.ASM with the name replaced, as the remaining header is the same Unfortunately this leaves 5 characters unaccounted for, although cr/lf may account for at least 2 characters.
> > Mark
Nathanael 
The start of TTBOOT.ASM is a corrupted sector. It wouldn't assemble as the lines are neither comments or 8080 assembly code. If you look at where the second sector starts it matches TTCBIOS.ASM
Mark

Is there a repository of the fixed archive or just the corrupted archive to be fixed?

Randy

Thank you.

I haven't put up the restored archives yet; was hoping to do that today, but some last minute details took longer than expected. Should go up tomorrow.

Meanwhile, if you can't wait and can run a BASH script, you can download the script from Github (see upthread for the link) and build everything yourself.

--nathanael

On Wednesday, May 18, 2022 at 10:51:05 PM UTC+8, Randy McLaughlin wrote:
> All the work done is fantastic.
>
> For the purist recovery means restoration to an extreme certainty. Restoring to something that works is not good enough.
>
> I agree it's best to leave it as is since it is easy to edit and use if desired and easy to see it's incomplete, so no one is fooled into believing it's a complete history.
>
> The point of the full archive has multiple uses:
>
> Much is still useful.
> It is history and as a digital document should be restored to as close as historically correct as possible.
> It is a window into both the individual's that wrote the software and the group think of the time.
>
> We can look back 50 years and see what ideas were lost and what ideas we have achieved since. in a hundred years I hope the archive still exists whether this one file gets restored or not.
>
>
> Again a fantastic job and a reminder those of us that have CP/M software and documentation it is a duty to preserve it via appropriate archives.
>
>
> Randy

OK, I've posted the restored SIG/M collection at *HUMONGOUS* CP/M:
http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/UserGroups/SIGM

The ISO (258mb) is at:
http://cpmarchives.classiccmp.org/downloads/sigm.iso

If you want to build the collection yourself, the current version of the BASH shell script (I imagine I'll continue tweaking it, at least for awhile) is at:
https://github.com/CPMArchives/SIGM

Note that the script sets file and directory dates to the original release date of each volume; however, when uploading the collection to *HUMONGOUS* CP/M all file dates were reset to the time of upload. Dates inside the ISO and the ARKs are still the original, so download the ISO if you want the original dates, or download the BASH script and build the collection yourself.. On my system it takes about five minutes -- probably faster than downloading the ISO.

Enjoy, everyone! And if you see any issues, let me know.

--nathanael
*HUMONGOUS* CP/M Archives
http://cpmarchives.classiccmp.org/

On Saturday, 21 May 2022 at 17:53:30 UTC+1, Nathanael wrote:
> OK, I've posted the restored SIG/M collection at *HUMONGOUS* CP/M:
> http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/UserGroups/SIGM" rel="nofollow" target="_blank">http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/UserGroups/SIGM
>
> The ISO (258mb) is at:
> http://cpmarchives.classiccmp.org/downloads/sigm.iso
>
> If you want to build the collection yourself, the current version of the BASH shell script (I imagine I'll continue tweaking it, at least for awhile) is at:
> https://github.com/CPMArchives/SIGM
>
> Note that the script sets file and directory dates to the original release date of each volume; however, when uploading the collection to *HUMONGOUS* CP/M all file dates were reset to the time of upload. Dates inside the ISO and the ARKs are still the original, so download the ISO if you want the original dates, or download the BASH script and build the collection yourself. On my system it takes about five minutes -- probably faster than downloading the ISO.
>
> Enjoy, everyone! And if you see any issues, let me know.
>
> --nathanael
> *HUMONGOUS* CP/M Archives
> http://cpmarchives.classiccmp.org/
Nathanael
Many thanks for doing this, you have done an excellent job.

With the complete set, I did a check for any compressed files are actually corrupt even though the CRCK checksum matches. There are a small number that appear to have been corrupt when the original CRCK checksums were created
Those I have found are
VOL116
APZCPR2.LBR, the azcpr2.ins file is corrupt, looks like LBR file was truncated
VOL123
ODMP.LBR the squeezed odmp.dqc file is corrupt
VOL160
SPRITE.LBR the squeezed sprite.mqc file has an invalid CRC, but force expanding the file seems to give a good file
VOL220
MXO_XE12.AQM the file has an invalid CRC. Forcing the expansion, gives what seems to be a truncated file
VOL233
CLEANUPC.LBR the squeezed file xc.cq has an invalid CRC, Forcing the expansion it looks like the file may be ok
VOL293
TURBUTIL.PQS (actually an LBR file), the squeezed file screen.dqc has an invalid CRC and appears to be corrupt
VOL295
UNARC12.LBR, the squeezed file unarc.zq0 has an invalid CRC, however forced expansion seems to give a valid file
VOL298
LT21.LBR, crunched file unc.dzc has an invalid CRC, however forced expansion seems to give a valid file
VOL306
PACK10.LBR, the crunched file pack10.zz0 has an invalid CRC. The file appears to be corrupt

Mark

On Sunday, May 22, 2022 at 5:25:05 AM UTC+8, Mark Ogden wrote:
> On Saturday, 21 May 2022 at 17:53:30 UTC+1, Nathanael wrote:
> > OK, I've posted the restored SIG/M collection at *HUMONGOUS* CP/M:
> > http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/UserGroups/SIGM" rel="nofollow" target="_blank">http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/UserGroups/SIGM
> >
> > The ISO (258mb) is at:
> > http://cpmarchives.classiccmp.org/downloads/sigm.iso
> >
> > If you want to build the collection yourself, the current version of the BASH shell script (I imagine I'll continue tweaking it, at least for awhile) is at:
> > https://github.com/CPMArchives/SIGM
> >
> > Note that the script sets file and directory dates to the original release date of each volume; however, when uploading the collection to *HUMONGOUS* CP/M all file dates were reset to the time of upload. Dates inside the ISO and the ARKs are still the original, so download the ISO if you want the original dates, or download the BASH script and build the collection yourself. On my system it takes about five minutes -- probably faster than downloading the ISO.
> >
> > Enjoy, everyone! And if you see any issues, let me know.
> >
> > --nathanael
> > *HUMONGOUS* CP/M Archives
> > http://cpmarchives.classiccmp.org/
> Nathanael
> Many thanks for doing this, you have done an excellent job.
>
> With the complete set, I did a check for any compressed files are actually corrupt even though the CRCK checksum matches. There are a small number that appear to have been corrupt when the original CRCK checksums were created
> Those I have found are
> VOL116
> APZCPR2.LBR, the azcpr2.ins file is corrupt, looks like LBR file was truncated
> VOL123
> ODMP.LBR the squeezed odmp.dqc file is corrupt
> VOL160
> SPRITE.LBR the squeezed sprite.mqc file has an invalid CRC, but force expanding the file seems to give a good file
> VOL220
> MXO_XE12.AQM the file has an invalid CRC. Forcing the expansion, gives what seems to be a truncated file
> VOL233
> CLEANUPC.LBR the squeezed file xc.cq has an invalid CRC, Forcing the expansion it looks like the file may be ok
> VOL293
> TURBUTIL.PQS (actually an LBR file), the squeezed file screen.dqc has an invalid CRC and appears to be corrupt
> VOL295
> UNARC12.LBR, the squeezed file unarc.zq0 has an invalid CRC, however forced expansion seems to give a valid file
> VOL298
> LT21.LBR, crunched file unc.dzc has an invalid CRC, however forced expansion seems to give a valid file
> VOL306
> PACK10.LBR, the crunched file pack10.zz0 has an invalid CRC. The file appears to be corrupt
>
> Mark

Yes, there are some corruptions that appear to have crept in prior to the original release. Since the goal of this project has been to restore files to their "original" condition (as per their CRCs) fixing these corruptions is beyond its scope. However, with the restoration complete, it can now serve as the foundation for further work.

Also folks should be aware that there's an issue with later library utilities falsely reporting corruption in earlier LBRs. This is due to the later utilities expecting CRCs in the LBR headers where earlier utilities just left random garbage.

--nathanael

On Sunday, May 22, 2022 at 5:25:05 AM UTC+8, Mark Ogden wrote:
> On Saturday, 21 May 2022 at 17:53:30 UTC+1, Nathanael wrote:
> > OK, I've posted the restored SIG/M collection at *HUMONGOUS* CP/M:
> > http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/UserGroups/SIGM" rel="nofollow" target="_blank">http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/UserGroups/SIGM
> >
> > The ISO (258mb) is at:
> > http://cpmarchives.classiccmp.org/downloads/sigm.iso
> >
> > If you want to build the collection yourself, the current version of the BASH shell script (I imagine I'll continue tweaking it, at least for awhile) is at:
> > https://github.com/CPMArchives/SIGM
> >
> > Note that the script sets file and directory dates to the original release date of each volume; however, when uploading the collection to *HUMONGOUS* CP/M all file dates were reset to the time of upload. Dates inside the ISO and the ARKs are still the original, so download the ISO if you want the original dates, or download the BASH script and build the collection yourself. On my system it takes about five minutes -- probably faster than downloading the ISO.
> >
> > Enjoy, everyone! And if you see any issues, let me know.
> >
> > --nathanael
> > *HUMONGOUS* CP/M Archives
> > http://cpmarchives.classiccmp.org/
> Nathanael
> Many thanks for doing this, you have done an excellent job.
>
> With the complete set, I did a check for any compressed files are actually corrupt even though the CRCK checksum matches. There are a small number that appear to have been corrupt when the original CRCK checksums were created
> Those I have found are
> VOL116
> APZCPR2.LBR, the azcpr2.ins file is corrupt, looks like LBR file was truncated
> VOL123
> ODMP.LBR the squeezed odmp.dqc file is corrupt
> VOL160
> SPRITE.LBR the squeezed sprite.mqc file has an invalid CRC, but force expanding the file seems to give a good file
> VOL220
> MXO_XE12.AQM the file has an invalid CRC. Forcing the expansion, gives what seems to be a truncated file
> VOL233
> CLEANUPC.LBR the squeezed file xc.cq has an invalid CRC, Forcing the expansion it looks like the file may be ok
> VOL293
> TURBUTIL.PQS (actually an LBR file), the squeezed file screen.dqc has an invalid CRC and appears to be corrupt
> VOL295
> UNARC12.LBR, the squeezed file unarc.zq0 has an invalid CRC, however forced expansion seems to give a valid file
> VOL298
> LT21.LBR, crunched file unc.dzc has an invalid CRC, however forced expansion seems to give a valid file
> VOL306
> PACK10.LBR, the crunched file pack10.zz0 has an invalid CRC. The file appears to be corrupt
>
> Mark

Oh, yes. Specifically wrt Vol 295's UNARC12.LBR, there was a discussion about that a couple of years back, around May '20.

A question I keep forgetting to ask:

I'm setting file dates to the release dates specified in each volume's -CATALOG, where that information is available. However early volumes lack a release date. From reading through the old SIG/M newsletters, it appears that official release dates were set to that month's SIG/M meeting. In most cases, however, I haven't been able to find that information, so I've arbitrarily set the dates to the 15th of the release month.

Does anyone know where I might find a list of SIG/M's monthly meeting dates, particularly between Oct '80 and Dec '81?

--nathanael

Updates:

* Minor changes to release dates for a few earliest volumes.
* Fixed some issues with various SIG/M.LIB file renamings and datings.
* Cleaned up all of the CRC false flag issues.
* Lots of internal clean-up and comment updates which don't affect end results.
* Online archive and ISO will be updated soon.

I think I'm getting close to satisfied. As usual, if you notice anything, let me know.

--nathanael

On 07/04/22 14:05, Nathanael wrote:
> Completely escaped my notice, but last September was *HUMONGOUS*’s 10th Anniversary.
>
> I’ve finally completed my clean up of the SIG/M disks. I focused on four things: complete, clean, uncorrupted, and "original”. None of the known sources had all volumes; many of the filenames were corrupted; and several hundred files didn’t match their CRCs. I’ve cleaned out all of the accretions (e.g., WILDCAT.BBS), restored "illegal" characters in filenames, and fixed all but a handful of the CRC problems. My goal was to produce something as close to "original" as possible.
>
> The collection is available in LRB, ARK and IBM-3740 disk image formats at http://cpmarchives.classiccmp.org/ftp.php?b=cpm%2FSoftware%2FUserGroups%2FSIGM.

The restoring of illegal filenames makes sense in a SSSD disk image, but
on the .LBR ? Granted, the unarchivers of today rename automatically
illegal filenames, but in past was not so discerning (years ago, I dealt
with an unexpected .COM directory, guess what was the cause ? ;-) )

Best regards from Italy,
dott. Piergiorgio.

On 07/04/22 14:05, Nathanael wrote:
> Completely escaped my notice, but last September was *HUMONGOUS*’s 10th Anniversary.
>
> I’ve finally completed my clean up of the SIG/M disks. I focused on four things: complete, clean, uncorrupted, and "original”. None of the known sources had all volumes; many of the filenames were corrupted; and several hundred files didn’t match their CRCs. I’ve cleaned out all of the accretions (e.g., WILDCAT.BBS), restored "illegal" characters in filenames, and fixed all but a handful of the CRC problems. My goal was to produce something as close to "original" as possible.
>
> The collection is available in LRB, ARK and IBM-3740 disk image formats at http://cpmarchives.classiccmp.org/ftp.php?b=cpm%2FSoftware%2FUserGroups%2FSIGM.
>
> I’ve encapsulated everything into a BASH shell script which is available at github.com/cpmarchives. Have a look there if you’re interested in all the details, or you can run the script to recreate everything yourself.
>
>
> Nathanael, gHUMONGOUS* CP/M Archives.