Completely escaped my notice, but last September was *HUMONGOUS*’s 10th Anniversary.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.
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
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.Nathanael
On Thursday, 7 April 2022 at 13:05:13 UTC+1, Nathanael wrote: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.
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
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.
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 providesNathanael, gHUMONGOUS* CP/M Archives.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.
Mark
On Thursday, April 7, 2022 at 9:38:08 PM UTC+8, ogd...@gmail.com wrote: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.
On Thursday, 7 April 2022 at 13:05:13 UTC+1, 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
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.
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 providesNathanael, gHUMONGOUS* CP/M Archives.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.
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.MarkI 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).
On Friday, 8 April 2022 at 02:42:26 UTC+1, Nathanael wrote: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.
On Thursday, April 7, 2022 at 9:38:08 PM UTC+8, ogd...@gmail.com wrote:
On Thursday, 7 April 2022 at 13:05:13 UTC+1, 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
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.
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 providesNathanael, gHUMONGOUS* CP/M Archives.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.
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.MarkI 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).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
regards
Mark
On Friday, April 8, 2022 at 5:15:24 PM UTC+8, Mark Ogden wrote: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.
On Friday, 8 April 2022 at 02:42:26 UTC+1, Nathanael wrote:
On Thursday, April 7, 2022 at 9:38:08 PM UTC+8, ogd...@gmail.com wrote:
On Thursday, 7 April 2022 at 13:05:13 UTC+1, 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’
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.
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 siteNathanael, gHUMONGOUS* CP/M Archives.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
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.MarkI 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).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
I don't know, I haven't tried the generated files on CP/M.regardsI 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.
Mark
Does your zip utility produce CP/M-compatible ZIPs?
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.
On 4/7/22 08: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.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.
Woops. My bad. I’d taken them down a while back for something. They’re back up now.
On Sunday, April 10, 2022 at 10:18:28 PM UTC+8, Steven Hirsch wrote:
On 4/7/22 08: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 availableThere are no ISO images present under:
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.
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.
Woops. My bad. I’d taken them down a while back for something. They’re back up now.
On Sunday, April 10, 2022 at 10:18:28 PM UTC+8, Steven Hirsch wrote:
On 4/7/22 08:05, Nathanael wrote:
Completely escaped my notice, but last September was *HUMONGOUS*’s 10th >>> Anniversary.There are no ISO images present under:
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.
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.
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
On Monday, April 11, 2022 at 7:24:31 AM UTC-7, Nathanael wrote:
Woops. My bad. I’d taken them down a while back for something. They’re back up now.
On Sunday, April 10, 2022 at 10:18:28 PM UTC+8, Steven Hirsch wrote:
On 4/7/22 08: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 availableThere are no ISO images present under:
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.
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.
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.
On Sunday, April 10, 2022 at 10:18:28 PM UTC+8, Steven Hirsch wrote:
On 4/7/22 08: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. >> 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.
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.
On Sunday, April 10, 2022 at 10:18:28 PM UTC+8, Steven Hirsch wrote:
On 4/7/22 08: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. >> 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.
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?
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.
I’d forgotten to edit out my own local system values. I’ve replaced both with $(pwd).Nathanael
Not sure how I’d get that info from the environment?
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.
On Thursday, 14 April 2022 at 18:17:32 UTC+1, 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?
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?
NathanaelI had to edit in the ISO and output locations. Suggestion: Modify the script
to take these from the environment.
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
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 eachindividual 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
—nathanael
On Friday, April 15, 2022 at 8:06:41 PM UTC+8, Mark Ogden wrote:
On Thursday, 14 April 2022 at 18:17:32 UTC+1, 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?
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?
NathanaelI had to edit in the ISO and output locations. Suggestion: Modify the script
to take these from the environment.
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
On Friday, 15 April 2022 at 16:49:44 UTC+1, Nathanael wrote:individual LBR in the collection to determine what date to set for that LBR, but even that only sets the lower bound.
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
If that’s not what you’re referring to, could you clarify?
—nathanael
On Friday, April 15, 2022 at 8:06:41 PM UTC+8, Mark Ogden wrote:
On Thursday, 14 April 2022 at 18:17:32 UTC+1, 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?
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?
NathanaelI had to edit in the ISO and output locations. Suggestion: Modify the script
to take these from the environment.
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
NathanaelMark
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
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?
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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script >> to take these from the environment.
the “couple of edits” were. Anything that I need to update?
On 4/14/22 13:17, Nathanael wrote: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?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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script
the “couple of edits” were. Anything that I need to update?
to take these from the environment.
$ export ISODIR=/path/to/iso
$ export OUTDIR=/path/for/output
On Saturday, 16 April 2022 at 14:33:07 UTC+1, Steven Hirsch wrote:mlbr will reflect a date many years different.
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/isoNathanael
$ 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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script
the “couple of edits” were. Anything that I need to update?
to take these from the environment.
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,
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
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)
On 4/16/22 12:30, Nathanael wrote:
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)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 :-).
[[ -z “$buildroot” ]] && buildroot=$(pwd)
On Saturday, 16 April 2022 at 14:33:07 UTC+1, Steven Hirsch wrote:mlbr will reflect a date many years different.
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/isoNathanael
$ 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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script
the “couple of edits” were. Anything that I need to update?
to take these from the environment.
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,
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.Nathanael
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
On Saturday, 16 April 2022 at 16:32:18 UTC+1, Mark Ogden wrote:mlbr will reflect a date many years different.
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/isoNathanael
$ 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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script
the “couple of edits” were. Anything that I need to update?
to take these from the environment.
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,
file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.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.
MarkNathanael
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
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.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
Note all dates are show as GMT time.
Mark
On Sunday, 17 April 2022 at 12:03:02 UTC+1, Mark Ogden wrote:mlbr will reflect a date many years different.
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/isoNathanael
$ 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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script
the “couple of edits” were. Anything that I need to update? >>>
to take these from the environment.
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,
file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.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.
MarkNathanael
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 is probably the most accurate.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.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
Mark
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
MarkIn 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?
On Monday, 18 April 2022 at 14:06:20 UTC+1, Mark Ogden wrote:windows, mlbr will reflect a date many years different.
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/isoNathanael
$ 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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script
the “couple of edits” were. Anything that I need to update? >>>
to take these from the environment.
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
the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.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.
MarkNathanael
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
file is probably the most accurate.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.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
Mark
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
Can you give specific examples?MarkIn 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:windows, mlbr will reflect a date many years different.
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/isoNathanael
$ 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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script
the “couple of edits” were. Anything that I need to update?
to take these from the environment.
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
the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.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.
MarkNathanael
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
catalog file is probably the most accurate.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.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
Mark
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
CRCKFILE lists. But a CR/LF conversion may explain why others still don't match. I'll take a look.MarkIn 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.
MarkCan 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 -
dos2unix -idu sigmv059/*
On Thursday, 21 April 2022 at 22:36:43 UTC+1, Nathanael wrote:windows, mlbr will reflect a date many years different.
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/isoNathanael
$ 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 whatI had to edit in the ISO and output locations. Suggestion: Modify the script
the “couple of edits” were. Anything that I need to update?
to take these from the environment.
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
in the file list, then it is reasonable to assume that the dates in the LBR file are probably all invalid.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.
MarkNathanael
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 >
catalog file is probably the most accurate.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.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
Mark
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
CRCKFILE lists. But a CR/LF conversion may explain why others still don't match. I'll take a look.MarkIn 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.
MarkCan 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 -
Nathanaelsince the sizes are only given in k.
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
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'"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.
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
Nathanaeldos2unix -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 <<
You can see the dos->unix issue I noted in VOL100
I suspect the problem relates to padding
On Wednesday, 27 April 2022 at 15:31:02 UTC+1, Nathanael wrote: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.
"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
dos2unix -idu sigmv059/*
59 0 sigmv059/CABORT.ASMNathanael
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 <<
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
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.
On 4/28/22 22:59, Nathanael wrote:
I pull vol 100 from the CPMDOSGG collection, which doesn’t suffer from theI'm dealing with some family issues here, but will try to dig out those disks
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.
next week.
No problem. When it’s convenient.
The three sources which preserve vol 59 have identical (bad) CRCs.
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 ???
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, 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
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 alook 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?Nathanael
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
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,there are 7 text files that have different CRCs, otherwise all match.
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,
AndreasMarkIs 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
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’sYou say, for example, you converted it from LF to CR/LF, but all the
READ.ME?
copies of 59’s
READ.ME I’ve looked at are already in DOS format. WhatREAD.ME did you start with?
padding with a single CTRL-Z and the rest of the block from 1024 Bytes above
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’sYou say, for example, you converted it from LF to CR/LF, but all the copies of 59’s
READ.ME?
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< ====
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
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
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
On 4/28/22 22:59, Nathanael wrote:
I pull vol 100 from the CPMDOSGG collection, which doesn’t suffer from theI'm dealing with some family issues here, but will try to dig out those disks
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.
next week.
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!
Good detective work:)Nathanael
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!
I’ve only got one file left to resolve: Vol 54 TTBOOT.ASM.listings?
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
Yes, when I’m satisfied, I’ll create an ISO image for download.
On Monday, May 9, 2022 at 11:19:34 PM UTC+8, Mark Ogden wrote:
On Sunday, 8 May 2022 at 02:37:50 UTC+1, Nathanael wrote:
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.
NathanaelCopy, rename, done!
Which files remain unresolved?
It would also be good if you could create an ISO file of the cleaned-up archive.
regards
Mark
On Sunday, 8 May 2022 at 02:37:50 UTC+1, Nathanael wrote:
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.
NathanaelCopy, rename, done!
Which files remain unresolved?
It would also be good if you could create an ISO file of the cleaned-up archive.
regards
Mark
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 flagsdue to bugs in the code I haven’t bothered to fix.
https://github.com/CPMArchives/SIGMlistings?
On Tuesday, May 10, 2022 at 10:43:47 AM UTC+8, Nathanael wrote:
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
NathanaelYes, when I’m satisfied, I’ll create an ISO image for download.
On Monday, May 9, 2022 at 11:19:34 PM UTC+8, Mark Ogden wrote:
On Sunday, 8 May 2022 at 02:37:50 UTC+1, Nathanael wrote:
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.
NathanaelCopy, rename, done!
Which files remain unresolved?
It would also be good if you could create an ISO file of the cleaned-up archive.
regards
Mark
On Tuesday, 10 May 2022 at 03:59:30 UTC+1, Nathanael wrote:due to bugs in the code I haven’t bothered to fix.
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
file listings?https://github.com/CPMArchives/SIGM
On Tuesday, May 10, 2022 at 10:43:47 AM UTC+8, Nathanael wrote:
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
Yes, when I’m satisfied, I’ll create an ISO image for download.
On Monday, May 9, 2022 at 11:19:34 PM UTC+8, Mark Ogden wrote:
On Sunday, 8 May 2022 at 02:37:50 UTC+1, Nathanael wrote:
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.
NathanaelNathanaelCopy, rename, done!
Which files remain unresolved?
It would also be good if you could create an ISO file of the cleaned-up archive.
regards
Mark
Looks like the first sector of TTBOOT.ASM is corrupted, although I suspect all/most was comments
Mark
On Tuesday, May 10, 2022 at 4:09:08 PM UTC+8, Mark Ogden wrote:flags due to bugs in the code I haven’t bothered to fix.
On Tuesday, 10 May 2022 at 03:59:30 UTC+1, Nathanael wrote:
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
file listings?https://github.com/CPMArchives/SIGM
On Tuesday, May 10, 2022 at 10:43:47 AM UTC+8, Nathanael wrote:
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
.Yes, when I’m satisfied, I’ll create an ISO image for download.
On Monday, May 9, 2022 at 11:19:34 PM UTC+8, Mark Ogden wrote:
On Sunday, 8 May 2022 at 02:37:50 UTC+1, Nathanael wrote:
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.
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.NathanaelNathanaelCopy, rename, done!
Which files remain unresolved?
It would also be good if you could create an ISO file of the cleaned-up archive.
regards
Mark
Looks like the first sector of TTBOOT.ASM is corrupted, although I suspect all/most was comments
Mark
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?
On Tuesday, May 10, 2022 at 9:25:08 PM UTC+8, Nathanael wrote:flags due to bugs in the code I haven’t bothered to fix.
On Tuesday, May 10, 2022 at 4:09:08 PM UTC+8, Mark Ogden wrote:
On Tuesday, 10 May 2022 at 03:59:30 UTC+1, Nathanael wrote:
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
file listings?https://github.com/CPMArchives/SIGM
On Tuesday, May 10, 2022 at 10:43:47 AM UTC+8, Nathanael wrote:
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
NathanaelYes, when I’m satisfied, I’ll create an ISO image for download. On Monday, May 9, 2022 at 11:19:34 PM UTC+8, Mark Ogden wrote:
On Sunday, 8 May 2022 at 02:37:50 UTC+1, Nathanael wrote:
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.
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.NathanaelNathanaelCopy, rename, done!
Which files remain unresolved?
It would also be good if you could create an ISO file of the cleaned-up archive.
regards
Mark
Looks like the first sector of TTBOOT.ASM is corrupted, although I suspect all/most was comments
Mark
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?.
ZCPR.ASM. Stupid spellchecker.
On Tuesday, 10 May 2022 at 14:27:42 UTC+1, Nathanael wrote:flags due to bugs in the code I haven’t bothered to fix.
On Tuesday, May 10, 2022 at 9:25:08 PM UTC+8, Nathanael wrote:
On Tuesday, May 10, 2022 at 4:09:08 PM UTC+8, Mark Ogden wrote:
On Tuesday, 10 May 2022 at 03:59:30 UTC+1, Nathanael wrote:
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
CATALOG file listings?https://github.com/CPMArchives/SIGM
On Tuesday, May 10, 2022 at 10:43:47 AM UTC+8, Nathanael wrote:
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 -
Yes, when I’m satisfied, I’ll create an ISO image for download.
On Monday, May 9, 2022 at 11:19:34 PM UTC+8, Mark Ogden wrote:
On Sunday, 8 May 2022 at 02:37:50 UTC+1, Nathanael wrote:
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.
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.NathanaelNathanaelCopy, rename, done!
Which files remain unresolved?
It would also be good if you could create an ISO file of the cleaned-up archive.
regards
Mark
Looks like the first sector of TTBOOT.ASM is corrupted, although I suspect all/most was comments
Mark
NathanaelHey, 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?.
ZCPR.ASM. Stupid spellchecker.
The ZCPR.ASM in cpmdosgg/CPM10/1054 is fine
Mark
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
LarryYes, 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.
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.
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
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.
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 properlyfor this disk type. Picture of disk label here: https://vintagecomputer.ca/files/SIGM/IMG-3638.jpeg
Santo
On Wednesday, May 11, 2022 at 7:29:46 PM UTC+8, santo.n...@gmail.com wrote:for this disk type. Picture of disk label here: https://vintagecomputer.ca/files/SIGM/IMG-3638.jpeg
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
SantoOK, 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. :-)
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 thesedisks. 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 ofbackups 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
On Wednesday, May 11, 2022 at 10:29:28 PM UTC+8, santo.n... @ g***l.com wrote: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
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
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.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
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.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
CPMDOSgg seems to be the cleanest collection — CRCs mostly match, e.g. — suggesting its source (whatever it is) is older than the other collections.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.
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
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?
Have you considered going back to even older sources like the Thinker Toys printed documentation?
Kudos for the great project BTW
On Wednesday, May 11, 2022 at 11:51:02 AM UTC-4, Nathanael wrote: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
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
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.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
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.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
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.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
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. KudosMy 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
these disks. These disks must have been reused at some point. Here is what that looks like: https://vintagecomputer.ca/files/SIGM/IMG-3639.jpegIs 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 BTWThanks. 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
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.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
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.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
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.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
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.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
On Friday, May 13, 2022 at 7:42:49 PM UTC-4, Nathanael wrote: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
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 BTWThanks. 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
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.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
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.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
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.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
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.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
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.comrelevant. There are are several on the S100Computers.com site but others as well.
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
It might be worth posting on the S100Computers.com Google Group to see if someone has it in their collection.
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.
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.
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.
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:Hi Nathanael, what about this?
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.
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
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
NathanaelHthWhile 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.
Martin
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 suspect most of the first 128 bytes are similar to TTBIOS.ASM with the name replaced, as the remaining header is the same
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
HthWhile 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.
Martin
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
ATM) that’s not in TTBIOS.ASM. So the question is *how* similar?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
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:Hi Nathanael, what about this?
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.
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
NathanaelHthWhile 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.
Martin
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
OK, I've posted the restored SIG/M collection at *HUMONGOUS* CP/M: http://cpmarchives.classiccmp.org/ftp.php?b=cpm/Software/UserGroups/SIGMoriginal, 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.
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
Enjoy, everyone! And if you see any issues, let me know.Nathanael
--nathanael
*HUMONGOUS* CP/M Archives
http://cpmarchives.classiccmp.org/
On Saturday, 21 May 2022 at 17:53:30 UTC+1, Nathanael wrote: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.
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
Enjoy, everyone! And if you see any issues, let me know.
--nathanaelNathanael
*HUMONGOUS* CP/M Archives
http://cpmarchives.classiccmp.org/
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 Saturday, 21 May 2022 at 17:53:30 UTC+1, Nathanael wrote: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.
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
Enjoy, everyone! And if you see any issues, let me know.
--nathanaelNathanael
*HUMONGOUS* CP/M Archives
http://cpmarchives.classiccmp.org/
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
Completely escaped my notice, but last September was *HUMONGOUS*’s 10th Anniversary.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.
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
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 428 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 105:50:18 |
| Calls: | 9,053 |
| Calls today: | 10 |
| Files: | 13,395 |
| Messages: | 6,015,566 |
