*HUMONGOUS* 10th Anniversary and SIG/M Restoration

[Nathanael]

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.

[ogd...@gmail.com]

Nathanael
Browsing your BASH script I notice that you rename files post creation of lbr files. I am not sure whether you are aware but he current version of mklbr supports renaming files as they are included by providing the stored name as part of the recipe. This allows for _ to / mapping and for more obscure mappings e.g. reserved filenames in Windows and illegal Windows/Unix filename characters. It also supports adding explicit file and library time stamps. The README.md file on my github site provides details.
Mark

[Nathanael]

I was not aware of that feature. That will simplify my script. Thanks.

To clarify, then, to rename SIG_M.LIB to SIG/M.LIB, an entry in the recipe file would look like:

SIG_M.LIB?SIG/M.LIB

Is that correct? (I’m not at home ATM, or I’d just try it myself).

[ogd...@gmail.com]

That should work, if not let me know and I will investigate why not and fix it.
Note the rename is optional and can be omitted if not needed.

I have a corresponding mlbr tool, also on github, that takes a lbr file and can extract it, expanding compressed files within it and optionally recreating it as a zip file. In this tool an info file is produced that records any files that were renamed to avoid illegal names or clashes. It will also extract embedded dates and comments from the compressed files if present. I have used this to highlight corrupt lbr files, including compressed content errors.
regards
Mark

[Nathanael]

I updated the script and did some very brief testing with good results. Will play around with it some more this weekend. mlbr doesn’t seem to mind if source and target names are the same, which makes the scripting dead simple.

Does your zip utility produce CP/M-compatible ZIPs?

[Mark Ogden]

I don't know, I haven't tried the generated files on CP/M.
As it stores directory information, it may not.
regards
Mark

[Steven Hirsch]

There are no ISO images present under:

http://cpmarchives.classiccmp.org/downloads

A README mentions an alternate site:

http://cpm.jenandcal.familyds.org/downloads

But I'm unable to connect to that URL.

[Nathanael]

Woops. My bad. I’d taken them down a while back for something. They’re back up now.

[sc...@mischko.com]

There is a README there at this time which says:
Due to space issues, all files have been removed from downloads/ and links updated to point to http://cpm.jenandcal.familyds.org/downloads.

Scott

[Steven Hirsch]

On 4/11/22 10:24, Nathanael wrote:
> Woops. My bad. I’d taken them down a while back for something. They’re back up now.

Thanks. A couple of edits later I'm able to generate the volumes. Thanks for
your work on this! I was given a massive lot of 8" diskettes that include
SIGM. Wasn't looking forward to imaging them. This is a lot simpler.

[Nathanael]

Yes. A while back I was running into space issues, so I removed the downloads material and pointed it to my backup copy on my home server. Looks like space issues have been resolved, so I’ve moved everything back up to the main site.

I’ll delete the README.

[Nathanael]

Could you do a favor for me?

There were hundreds of files in the extant sources whose CRCs no longer matched the values recorded in -CATALOG. This seems mostly to do with the CP/M 128-byte sector size issue. Original CRCs were generated against files that retained the extra padding, which was lost as the files passed through other file systems, resulting in mismatching CRCs.

There’s code in my script which pads files out to 128-bytes using 1AH. In most cases, this seems to have restored the proper CRCs, but there are a few dozens files that still don’t match. Particularly volumes 59 and 80. At a guess, this is because for those files, the extra padding consisted of something other than 1AH.

Could you run a CRC check against your copy of volume 59 or 80 and see if they match the CRCs in -CATALOG?

[Nathanael]

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?

[Steven Hirsch]

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’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?

[Mark Ogden]

Nathanael
I appreciate that most CP/M systems did not support date/time but some did, which lbr and some of the compression formats supported.
If you use mlbr, it will show any embedded dates or in some cases the comment fields that contain text date information.
It is probably not worth saving the files with these dates, but it may be of historic interest to some, so adding listings could be of interest.
Note if there are date/times (except those in comments) then mlbr will use these to set the timestamps of extracted files as follows
1) if in date/time is in a compressed file, this is used
2) else if in the lbr header time/date is set for a file, this is used

On a separate note, lbr files should have padding to 128 byte boundaries for the included files and if CRC is being used, the padding (1Ah) will be included in the calculation.
The lbr header's own CRC is calculated specially, in that it is calculated with the CRC initially assumed to be 0 then updated with calculated value

Mark

[Nathanael]

Sorry, not sure I’m following you. I don’t touch any of the LBRs in the SIG/M collection, so whatever internal information they contain is preserved as-is. I use mlbr to build the SIGMVxxx.LBR files in LBR/ only. I suppose I could examine each individual LBR in the collection to determine what date to set for that LBR, but even that only sets the lower bound.

If that’s not what you’re referring to, could you clarify?

—nathanael

[Mark Ogden]

Nathanael
When an LBR file is created it will record timestamps associated with the files on the disk, or no timestamps if the system did not support them.
Some compressed files, contain a timestamp of when the compressed file was created, which is likely to give a more accurate view.

If you use my mlbr utility it will show the timestamp of any compressed file, if it exists and use it to set the timestamp of any extracted file.

regards
Mark

[Nathanael]

I’ve been playing around with this for a couple of hours and getting some odd results.

For many of the LBR files in SIG/M mlbr returns rather strange dates. Take as an example BYTYPE86.LBR on vol 229:

APC-DATE.LBR 1985-05-17
!! apc-date.lbr library CRC is missing
apc-date.lbr 18688 Library - 2157-06-06 08:04
date4.pas 6400 Stored - 1982-05-25 17:41
date4.cmd 12160 Stored - 2144-10-27 17:56

APCSERIO.LBR 1985-05-17
!! apcserio.lbr library CRC is missing
apcserio.lbr 16256 Library - 2157-06-06 08:04
serialio.a86 13056 Stored - 1978-01-03 00:00
terminal.a86 3072 Stored - <no date record>

The CRCs of both LBRs match the listing in -CATALOG.229, so the files themselves seem to be intact.

[Steven Hirsch]

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

[Mark Ogden]

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]

On Saturday, April 16, 2022 at 9:33:07 PM UTC+8, Steven Hirsch wrote:
> $ export ISODIR=/path/to/iso
> $ export OUTDIR=/path/for/output

Doh. I thought you mean deriving them automatically from the environment. Yeah, setting environment variables is easy enough. I’ve updated the script as follows:

[[ -z “$iso_loc” ]] && iso_loc=$(pwd)
[[ -z “$buildroot” ]] && buildroot=$(pwd)

[Nathanael]

I know earlier releases of LU didn’t support CRCs and left garbage in the CRC field in the lbr headers. Wouldn’t one expect something similar for dates, since few people ran systems that supported them anyway.

If it were just a matter of using a different epoch number, you should see consistency, at least, in file dates, even if the dates are wrong.

[Steven Hirsch]

Yeah, that'll work. FYI: it's sort of customary to use all uppercase on
variables expected in the environment. But, I'm one of those Unix graybeard
types :-).

[Nathanael]

“it’s sort of customary to use all uppercase”

Yeah, I know. But that’d require me to do a find-and-replace. Twice. Just don’t know if I’ve got that kind of time :)

[Mark Ogden]

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

[Mark Ogden]

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

[Mark Ogden]

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

[Nathanael]

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.

[Mark Ogden]

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

[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'"

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

[Mark Ogden]

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

[Nathanael]

> 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.

[Steven Hirsch]

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.

[Nathanael]

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.

[Martin]

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

[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 ???

[Nathanael]

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

[Nathanael]

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?

[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

[Mark Ogden]

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

[Andreas Gerlich]

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

[Martin]

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< ====

[Mark Ogden]

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

[Nathanael]

@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

[Andreas Gerlich]

Hello Mark,

thank you for the crck.pl.

Best Regards
Andreas

[Martin]

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 :-)

[Martin]

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!

[Nathanael]

@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! :)

[Nathanael]

Good detective work:)

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

[Mark Ogden]

Nathanael
Which files remain unresolved?
It would also be good if you could create an ISO file of the cleaned-up archive.
regards
Mark

[Nathanael]

I’ve only got one file left to resolve: Vol 54 TTBOOT.ASM.

After that, I’m going to focus a bit more on volume content. For example, there are numerous instances where a volume contains a file, like CRC.COM or USQ.COM, which isn’t listed in -CATALOG.xxx. How strictly should I adhere to the -CATALOG file listings?

Yes, when I’m satisfied, I’ll create an ISO image for download.

[Nathanael]

Oh, and I’m keeping the build script updated on GitHub just in case anyone can’t wait for the ISO :) and wants to build it themselves. Currently the script still flags around 20 CRC mismatches, but except for TTBOOT.ASM, they’re all false flags due to bugs in the code I haven’t bothered to fix.

https://github.com/CPMArchives/SIGM

[Mark Ogden]

Nathanael
Looks like the first sector of TTBOOT.ASM is corrupted, although I suspect all/most was comments
Mark

[Nathanael]

Oddly, it appears zero.ASM is similarly corrupted, yet its CRC matches that in -CATALOG.054. So the corruption appears to go all the way back to the original.

Hey, Steven — when you’ve got the time, if you’ve got a copy of vol 54, could you take a look at the files to see if your copies are corrupted?

[Nathanael]

.
ZCPR.ASM. Stupid spellchecker.

[Mark Ogden]

Nathanael
The ZCPR.ASM in cpmdosgg/CPM10/1054 is fine
Mark

[Nathanael]

Yeah, it is. I was looking at the wrong one. So it’s just TTBOOT.ASM. I’ve so far been unable to locate a replacement.

[ldkr...@gmail.com]

I have a copy of SIGM in /home/larry/jonv/repositories/Walnut_Creek_CPM/WalnutCreek/SIMTEL/SIGM/VOLS000/VOL054/
February 2 1982 hat has the following crc:

Sig/M Volume 54 Z80 Command Processor Replacement
Capture CONIN and CONOUT Onto Disk
2.2 Bios For Thinker Toys

-CATALOG.054 contents of Sig/M volume 54
released February 2, 1982

index name size crc description

54.01 BDOSLOC .ASM 2K EB D4 Z80 Command Processor
54.02 DISK .DIR 1K 5C CE CCP 2.2 Replacement
54.03 READ .ME 6K D7 AB /
54.04 SIG/M .SUB 4K 15 86 /
54.05 ZCPR .ASM 51K 7A 46 /
54.06 ZCPR .DOC 45K 94 B7 /
54.07 ZCPR .HLP 15K 26 9D /
54.08 ZCPR .WS 40K A2 C2 /
54.09 I/O-CAP .ADD 1K 74 31 Capture CONIN and CONOUT
54.10 I/O-CAP .ASM 19K A2 1A onto a disk file
54.11 TTBOOT .ASM 3K C9 01 2.2 Bios for Thinker Toys
54.12 TTCBIOS .ASM 7K B5 80 /
54.13 TTSDDJ .HLP 4K 93 E8 /

Copyright (c) 1982 by Sig/M-Amateur Computer Group
of New Jersey Inc., Box 97, Iselin NJ, 08830-0097


Larry

[Nathanael]

Yes, 0catalog..054 records C901 as the CRC, but unfortunately the actual file on the image has a CRC of 7A37 and exhibits the same corruption.

[santo.n...@gmail.com]

I have a local copy of the SIGM archive. I've zipped it up and put it here: https://vintagecomputer.ca/files/SIGM/

You can find TTBOOT.ASM in there if you still need it. I assume it is complete.

Hope this helps,
Santo

[Nathanael]

Thank you for the effort. What you have appears to be a duplicate of the SIGM content from the Walnut Creek CD. Unfortunately, TTBOOT.ASM exhibits the same corruption.

[Nathanael]

I’m in the process of manually verifying that only files that appear in -CATALOG and/or CRCKFILE listings are included in the rebuilt volumes. After that, I think I’m going to call this done.

As to file dates, where the -CATALOG.xxx lists a release date, I’ve used that. Some volumes specify only the month; others give no date at all. Often it seems as if the volume release dates corresponded with the ACGNJ monthly meeting. Does anyone have info available on what those dates were?

[santo.n...@gmail.com]

That is unfortunate. Worst case scenario, I have the "SIG/M Volume 54" 8" disk from 02/19/81, if needed. I would just have to re-create my 8" disk archiving set up (which is a bit painful to set up) and figure out how to configure ImageDisk properly for this disk type. Picture of disk label here: https://vintagecomputer.ca/files/SIGM/IMG-3638.jpeg

Santo

[Nathanael]

On Wednesday, May 11, 2022 at 7:29:46 PM UTC+8, santo.n...@gmail.com wrote:
> That is unfortunate. Worst case scenario, I have the "SIG/M Volume 54" 8" disk from 02/19/81, if needed. I would just have to re-create my 8" disk archiving set up (which is a bit painful to set up) and figure out how to configure ImageDisk properly for this disk type. Picture of disk label here: https://vintagecomputer.ca/files/SIGM/IMG-3638.jpeg
>
> Santo

OK, now that just brings up too many questions. To begin with, the date. According to -CATALOG.054, volume 54 was released to February 1982, yet your disk label is dated a year earlier. Why? By my info, in February ‘81 ACGNJ was releasing volume 10.

What’s the provenance of your disk set ? Are they originals? How many volumes do you have?

It’s a big ask, I know, but if there’s anyway you could image what you’ve got as time permits, IMD images of original discs would be the Holy Grail of what I’m trying to do here.

Thanks for posting that image. I am tantalized. :-)

[Nathanael]

One more question. Is that a TRS-80 Model IV I see in the background?

[santo.n...@gmail.com]

I had to sort through the disks but unfortunately, I only have 227 8" disks with a small number missing and some duplicates. They are a backup with various labels and of disks have two disk archives on them. I should set up a CP/M system to check these disks. These disks must have been reused at some point. Here is what that looks like: https://vintagecomputer.ca/files/SIGM/IMG-3639.jpeg

These disks came from Canada Remote Systems who was originally Toronto RCP/M. They ran a large BBS and had their own CP/M archive that I have posted here: https://vintagecomputer.ca/files/Canada%20Remote%20Systems%20CPM%20Archive/. I have a couple of backups of this; one on CD and one on ZIP disk. You can see the SIG/M backup was dated July 4, 1983 if the first disk is accurate. Unfortunately, there must have been another box of disks that I didn't get.

Yes, that is a TRS-80 Model 4 next to the box. I also have a NEC APC with 8" drives and I think I have CP/M 86 for it but that computer needs work :(. I wonder if I could have used that to browse these disks?

I will look into my 8" archiving system. If I recall, my Adaptec SCSI controller (with the better floppy controller) died so I may have some issues setting it up. It might take me a bit to get that going.

Santo

[Nathanael]

>Toronto RCP/M

I seem to have the same collection at *HUMONGOUS* CP/M here:

http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/TorontoRCPM/CDR

Before you put a lot of work into this, let’s see if it’ll be worth the effort.

There are currently six sources that I’m aware of for the SIG/M. The best known is the Walnut Creek CD. Unfortunately, it’s also by far the most corrupt — filenames have beeen altered, passage through UNIX at some point has left file names altered, many text files converted to UNIX format, and weird stuff with / in the file name, and a whole bunch of files that don’t match original CRCs.

CPMDOSgg seems to be the cleanest collection — CRCs mostly match, e.g. — suggesting its source (whatever it is) is older than the other collections.

I’d ideally like to get my hands on IMD disk images of original copies of the SIG/M disks, or disks that were duped from them. From your description it sounds like what you have isn’t anything like that — just archive disks made by someone at Toronto RCP/M. So getting IMDs may not be necessary. But if there’s a chance the source of your images is older than CPMDOSgg, copies of the files (zipped up, perhaps) could still prove useful. Case in point is vol 54’s TTBOOT.ASM.

My first machine was a Model IV. I stilll miss it.

[Bernard Oates]

On Wednesday, May 11, 2022 at 11:51:02 AM UTC-4, Nathanael wrote:

Is it possible that TTBOOT.ASM was never copied to the SIG/M vol 54 disk correctly? If the corrupt/missing first sector is purely comments it may have been just not noticed and/or disregarded until recently. Have you considered going back to even older sources like the Thinker Toys printed documentation? Boards of that era often included source listings in their manuals and it may have not been transcribed properly into the SIG/M collection ever. Possibly that might give clues as what is missing. Kudos for the great project BTW. Great historical value and importance

[Nathanael]

> Is it possible that TTBOOT.ASM was never copied to the SIG/M vol 54 disk correctly?

Except that TTBOOT.ASM’s CRC (6E2F) doesn’t match the value in -CATALOG.054 (C901), indicating that what we have isn’t what the original CRC was generated against.

> Have you considered going back to even older sources like the Thinker Toys printed documentation?

Is that available somewhere? I haven’t been able to find it.

> Kudos for the great project BTW

Thanks. It began a couple of years ago when I was trying to chase down Vols 184-192, which were missing from every source I had at the time.

[Bernard Oates]

On Friday, May 13, 2022 at 7:42:49 PM UTC-4, Nathanael wrote:
> > Is it possible that TTBOOT.ASM was never copied to the SIG/M vol 54 disk correctly?
> Except that TTBOOT.ASM’s CRC (6E2F) doesn’t match the value in -CATALOG.054 (C901), indicating that what we have isn’t what the original CRC was generated against.
> > Have you considered going back to even older sources like the Thinker Toys printed documentation?
> Is that available somewhere? I haven’t been able to find it.
> > Kudos for the great project BTW
> Thanks. It began a couple of years ago when I was trying to chase down Vols 184-192, which were missing from every source I had at the time.

> On Friday, May 13, 2022 at 9:17:43 PM UTC+8, * wrote:
> > On Wednesday, May 11, 2022 at 11:51:02 AM UTC-4, Nathanael wrote:
> > > On Wednesday, May 11, 2022 at 10:29:28 PM UTC+8, santo.n... @ g***l.com wrote:
> > > > I had to sort through the disks but unfortunately, I only have 227 8" disks with a small number missing and some duplicates. They are a backup with various labels and of disks have two disk archives on them. I should set up a CP/M system to check these disks. These disks must have been reused at some point. Here is what that looks like: https://vintagecomputer.ca/files/SIGM/IMG-3639.jpeg
> > > >
> > > > These disks came from Canada Remote Systems who was originally Toronto RCP/M. They ran a large BBS and had their own CP/M archive that I have posted here: https://vintagecomputer.ca/files/Canada%20Remote%20Systems%20CPM%20Archive/. I have a couple of backups of this; one on CD and one on ZIP disk. You can see the SIG/M backup was dated July 4, 1983 if the first disk is accurate. Unfortunately, there must have been another box of disks that I didn't get.
> > > >
> > > > Yes, that is a TRS-80 Model 4 next to the box. I also have a NEC APC with 8" drives and I think I have CP/M 86 for it but that computer needs work :(. I wonder if I could have used that to browse these disks?
> > > >
> > > > I will look into my 8" archiving system. If I recall, my Adaptec SCSI controller (with the better floppy controller) died so I may have some issues setting it up. It might take me a bit to get that going.
> > > >
> > > > Santo
> > > >Toronto RCP/M
> > >
> > > I seem to have the same collection at *HUMONGOUS* CP/M here:
> > >
> > > http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/TorontoRCPM/CDR
> > >
> > > Before you put a lot of work into this, let’s see if it’ll be worth the effort.
> > >
> > > There are currently six sources that I’m aware of for the SIG/M. The best known is the Walnut Creek CD. Unfortunately, it’s also by far the most corrupt — filenames have beeen altered, passage through UNIX at some point has left file names altered, many text files converted to UNIX format, and weird stuff with / in the file name, and a whole bunch of files that don’t match original CRCs.
> > >
> > > CPMDOSgg seems to be the cleanest collection — CRCs mostly match, e.g. — suggesting its source (whatever it is) is older than the other collections.
> > >
> > > I’d ideally like to get my hands on IMD disk images of original copies of the SIG/M disks, or disks that were duped from them. From your description it sounds like what you have isn’t anything like that — just archive disks made by someone at Toronto RCP/M. So getting IMDs may not be necessary. But if there’s a chance the source of your images is older than CPMDOSgg, copies of the files (zipped up, perhaps) could still prove useful. Case in point is vol 54’s TTBOOT.ASM.
> > >
> > > My first machine was a Model IV. I stilll miss it.
> > Is it possible that TTBOOT.ASM was never copied to the SIG/M vol 54 disk correctly? If the corrupt/missing first sector is purely comments it may have been just not noticed and/or disregarded until recently. Have you considered going back to even older sources like the Thinker Toys printed documentation? Boards of that era often included source listings in their manuals and it may have not been transcribed properly into the SIG/M collection ever. Possibly that might give clues as what is missing. Kudos for the great project BTW. Great historical value and importance

As I recall, Thinker Toys was an early form of the George Morrow company's S-100 board so it might be found buried in the documentation on S100Computers.com

http://www.s100computers.com/Hardware%20Folder/Morrow/History/History.htm

I was digging around and noticed there was a code listing in the Disk Jockey S-100 FDC board which looked kind of similar. If there are clues in TTBOOT.ASM as to what hardware it is specifically meant for that might provide help on what documents are relevant. There are are several on the S100Computers.com site but others as well.

It might be worth posting on the S100Computers.com Google Group to see if someone has it in their collection.

[Nathanael]

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.

[santo.n...@gmail.com]

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

[Nathanael]

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:*.* ./

[Martin]

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

[Nathanael]

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 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

[Mark Ogden]

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

[Randy McLaughlin]

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

[Nathanael]

> 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]

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

[Randy McLaughlin]

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


Randy

[Nathanael]

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

[Nathanael]

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/

[Mark Ogden]

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

[Nathanael]

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

[Nathanael]

On Sunday, May 22, 2022 at 5:25:05 AM UTC+8, Mark Ogden wrote:

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

[Nathanael]

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

[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

[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.

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.

[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.