ORIGINAL WorkBench checksums

[Supamax]

Originally Posted by rhester72

Another thought on this effort...

Would it not be enough to compare the CRC32 to _any_ original disk to _any_ downloaded ADF to achieve validation?

Case in point:

- Booting or opening any folder on a 1.x disk results in updating the .info file for the respective directory, rendering the CRC32 unique and allowing you to detect modification versus the CRC32 of the sample/original floppy

- Booting any 2.x+ disk results in the updating of the timestamp of the :T folder, see above

This is entirely theoretical at this point, but especially for some of the more rare/esoteric disks, this may be a useful way to allow for confident validation of unmodified originals without necessarily needing *two* original samples (only one plus the "from the 'net" copy).

Thoughts?

Rodney

Hmmm, I think I see your point Rodney.
I, too, noticed that WB disks (and ADOS data disks too) are subject to slight changes when booted by Amiga.
For this reason, however, I think it's better (I would say mandatory) to consider new + write-enabled (better if still shrink-wrapped) disks only.

[Supamax]

Originally Posted by prowler

The above information raises an unwelcome prospect for this thread:

After all this time, many Amiga owners have chosen to remove the battery which was powering their machine's RTC, either because of leakage or as a preventative measure, without replacing it.

While it is still much more likely that two original disks with the same checksum are indeed unmodified, an increasing number of Amiga owners cold booting their machines with the RTC effectively reset means that two or more modified disks with the same checksum is a real possibility.

Oh my God... I hope you're wrong. I mean: I hope that two different Amigas, even if both of them are without a working RTC, will modify their WB disks in different ways.

However, all the checksums received from you mates are taken from untampered disks. I'm counting on your words and I trust you, of course

[Calgor]

If you did not own the original disks since new, you have no way of knowing if those "original" disks were not the same used to make the "rare" ADFs online. It would be more likely the rarer the disks that they could be from same real disk source. Plenty of examples of this on internet.

However, if you really did own the original disk since new, it could be a valid way.

[rhester72]

Calgor,

I wasn't suggesting that at least one original, valid, in-one-of-our-hands sources isn't needed - I was merely suggesting that you probably don't need *two*.

I intend to do a bit of testing to determine things like:

- If you have no battery-backed RTC, is it possible by booting two pristine originals that you wind up with identically-modified (down to CRC32) disks? (Remember that the clock is set to the latest timestamp on any file on a floppy if the RTC is invalid/absent.)

- Let's take something like an Extras disk - what must be done to actually cause it to be modified? (Opening a folder in 1.x will do the trick, but what else?) Once modified, are timestamps updated? What are the odds one could again do the same thing in exactly the same way and produce two modified disks?

Personally, I consider the likelihood of producing CRC-identical modifications to be quite small even if deliberately attempted, but I'd like to have some science backing it up before I expect anyone to take my suggestion seriously.

Rodney

[prowler]

Originally Posted by rhester72

I intend to do a bit of testing to determine things like:

- If you have no battery-backed RTC, is it possible by booting two pristine originals that you wind up with identically-modified (down to CRC32) disks? (Remember that the clock is set to the latest timestamp on any file on a floppy if the RTC is invalid/absent.)

- Let's take something like an Extras disk - what must be done to actually cause it to be modified? (Opening a folder in 1.x will do the trick, but what else?) Once modified, are timestamps updated? What are the odds one could again do the same thing in exactly the same way and produce two modified disks?

Personally, I consider the likelihood of producing CRC-identical modifications to be quite small even if deliberately attempted, but I'd like to have some science backing it up before I expect anyone to take my suggestion seriously.

Thanks for your contribution, Rodney!

I have four Workbench 1.3.2 disks, two with identical checksums which I consider to be unmodified, and another two with checksums different both from each other and from that of the unmodified disks. All these checksums have been previously reported in this thread.

Now that I know what I'm looking for, I will have a look at all these disks in an AmigaShell to see which timestamps may have been modified on the two uncorrelated disks. I now suspect that they have probably been modified in the way that you have suggested.

If I find anything which has been modified, I'll report my findings here and maybe look for a way to restore them to their original status without actually copying the unmodified disks.

[rhester72]

If they were booted under Kickstart 1.x, you can be almost entirely assured that the .info file in / (at minimum) was modified. Copying a fresh copy of that file from an unmodified disk (with the CLONE option, I'd recommend doing this from 2.x+) _should_ do the trick, as it will copy-with-overwrite and doesn't perform wear-leveling. Other folder #?.info files may have been affected _if navigated via Workbench_, so those should be checked as well.

Rodney

[prowler]

Originally Posted by rhester72

Copying a fresh copy of that file from an unmodified disk (with the CLONE option, I'd recommend doing this from 2.x+) _should_ do the trick, as it will copy-with-overwrite and doesn't perform wear-leveling.

Thanks for the new info, Rodney!

That's the sort of thing I had in mind for restoring those disks (I'm a big fan of the command-line for that sort of thing).

Until I read your posts here, I had no idea that WB 1.x and 2.x floppies would be modified upon startup by default (being mostly a WB 3.1 user myself).

[Supamax]

Originally Posted by prowler

If I find anything which has been modified, I'll report my findings here and maybe look for a way to restore them to their original status without actually copying the unmodified disks.

How can you know their original status? I mean: how do you know for sure which exact time/timestamps they had when they were new/untampered?
Even if you compare them to another (untampered) copy you have, you cannot be sure that your modified WB had the same timestamps (originally).

You cannot even be sure that all the files' timestamps were equal (same date)...

Originally Posted by rhester72

Copying a fresh copy of that file from an unmodified disk (with the CLONE option, I'd recommend doing this from 2.x+) _should_ do the trick

How can you be sure that the "fresh copy" is equal to the one originally present on the tampered/modified disk? You can't, IMHO

[rhester72]

Supamax,

It's a question of odds.

Even -if- you were dealing with different original disks in identical machines with identical floppy mechanisms in identical world regions (ie PAL vs. NTSC) with the same Kickstart, the odds are extremely small that you will wind up with absolutely identical timestamps and modifications. Considering most people don't just insert a floppy, open a single folder (or boot it) and then eject it, the odds become almost infinite that there won't be a match, because not only does the entire configuration (including drive mech!) essentially have to match, so does the workflow!

If you don't trust the proposed methodology, I have no issue with that _so long as you can provide steps to reproduce a corner case where you can produce two identically-CRCed floppy images modified separately_ (I don't mind if you use an emulator, that actually increases your odds of success, and *reasonable* levels of accuracy are what I'm interested in as well!)

If you want to be 100% certain that bit rot didn't accidentally affect exactly the same bitcells in precisely the same way on two copies of the same floppy half a world apart, you have no choice but to go the SPS/KryoFlux route and get down to the bitcell level.

In entirely pragmatic terms, I simply don't find that necessary or desirable to achieving the goal of establishing an OS (and later application?) library that is known to be unmodified -to a reasonable degree of accuracy-.

I'm anal-retentive. I don't think the average end-user...or digital historian...is necessarily going to care whether the timestamp of a .info file was modified in an "archival backup", as it is of zero relevance. But like you, it means something to me...I'm just trying to split the difference between accuracy and pragmaticism.

Rodney

[prowler]

Originally Posted by Supamax

How can you know their original status? I mean: how do you know for sure which exact time/timestamps they had when they were new/untampered?

Don't worry, mate. I shan't do anything to my original disks until I'm sure I know what I'm doing. I intend to work on images of the disks in emulation while I am investigating the discrepencies between them.

I figure that if the suspected modified disks are "restored" by copying files with the original date/timestamps from the unmodified disks using the copy clone command and their checksums then agree with those of the unmodified disks, then it's safe to say that their original status was the same as the unmodified disks. If not, then either I have missed something else which has been modified, or their original status was different.

Originally Posted by Supamax

Even if you compare them with another (untampered) copy you have, you cannot be sure that your modified WB had the same timestamps.

Quite right, but then I will never be able to turn them into disks with the same checksums using the method I propose and, provided I work only on images of the disks in emulation, nothing will have been lost.

I only wish to remove erroneous checksums from the list you are maintaining in this thread.

[Supamax]

@ Peter and Rodney

Ok, I think I got your point. Sorry, I'm very very tired in these days...
A question arises in my (stressed by my job) mind:
what if, apart from files' timestamps, the disk FAT is modified too?
Even when cloning the original file on the modified one, are you sure that the FAT isn't changed in an unpredictable/complicated way?

EDIT

I'm reporting here a nice answer by Rodney, which explains better what he was meaning :

"Massimo,

All I meant, in the end, is that winding up with absolutely identical modifications requires two critical things:

- Exactly the same time (which, in absence of a BB clock, is determined by the "newest" timestamp in / + # of seconds it takes to boot, which will vary with Kickstart, region, drive mech, etc...not by much, but likely more than one second)

- Exactly the same workflow (if you open two folders under 1.x and I only open one, or you open only one but a -different- one than I did, or the -same- folder but -at a different time offset from boot- e.g. 20 seconds post-boot where I did mine 21 seconds post-boot, in any of those cases the CRC will be different)

So the odds of even intentionally and maliciously producing the same CRC/image _from an actual floppy_ are so small they can be ignored, unless I'm missing something.

Again, I do NOT advocate making this determination purely from images on the 'net. It requires at *least* one physical, in trusted hands, original floppy _plus_ at least one image from the 'net - if they match, you can be reasonably certain your _original_ was unmodified and thus OK.

I only jumped in to begin with to try to get away from the "we need to compare two physical originals to be sure" approach, because I really don't think you do...you need only one.

Rodney"

[prowler]

Originally Posted by Supamax

What if, apart from files' timestamps, the disk FAT is modified too? Even when cloning the original file on the modified one, are you sure that the FAT isn't changed in an unpredictable/complicated way?

When copying a file with the original time/datestamp from an original disk to another disk which originally contained the same file but which now has a modified time/datestamp and overwriting it in the process, the destination disk's FAT will only be changed in a way consistent with restoring it to its original status. I am confident of this, having recently carried out a similar disk recovery task.

[Jope]

Originally Posted by rhester72

One point of note - the original A3000 (ROM tower model) shipped with three unique 1.3 disks - SuperKickstart 1.3, Workbench 1.3 (contained modified SetClock to work with the A3000 clock chip), and Extras 1.3 (had AmigaBASIC removed due to 68030 incompatibility). I unfortunately do not have part numbers, CRCs, or even the subversion (i.e. 1.3.2) of these disks.

Rodney

I actually have these disks, as I believe my current A3000 is originally a UX version. At least it shipped with 1.3 and 2.0 disksets and they are still in the folder. I even made ADFs of them.. Now if I could only bother walking to the data cave, boot up the machine and copy them off it..

Unfortunately the previous owner has sprayed the case black, so i can't verify whether it truly is a UX version.. It hasn't got a ROM tower, but the 1.4 boot roms are still installed, since I didn't upgrade it with a CPU card.. :-)

The A3000s shipped with superkickstart disks that contained both 1.3 and some version of 2.0x. The beginning of the disk is for 1.3 and the end is for 2.0x..

a3000-kickstart-352245-02 e265a37d contains kickstarts 36.141 and 34.5

a3000-wb1.3.2-367270-01 e7edf797 contains 34.32
a3000-extras1.3-367272-01 a01b6c30 no amigabasic, as mentioned earlier

a3000-install-335603-02 1207b649 is based on wb 36.68 and the boot up banner says Amiga A3000 Software Installation Disk Release 2.6.. This disk makes both WB_1.3 and WB_2.x partitions and a Work partition + copies the OSes in there.

a3000-wb2.0-317954-02 3e62fbc0 is 36.68.. As a curiosity, the interlace bit is set in the system-configuration of the install and wb2.0 disks.
a3000-extras2.0-317235-02 47112b69 is just extras 2.0, doesn't have much in there.. tools and monitorstore.

I may have to verify the CRCs one more time for correctness, the A3000 is a bit flakey at the moment and gives read errors on the HD occasionally.

[rhester72]

Have mercy...you are right, I have confirmed that these indeed did ship precisely as you described with the UX. I have little doubt that your machine was at least at one point a legitimate UX machine, even if painted black. =)

There seems to be an extra digit in the part number for the SKS disk.

Thank you *so much* for this information!

Rodney

[Jope]

More ancient goodies from original disks:

amiga c 1.1 316169-01 5e124f8e
amiga lisp 316171-01 5eb93c55
kaleidoscope 316160-01 e1d18451
amiga kickstart 1.1 50Hz (no partno anywhere!) 70d0030a
amiga workbench 1.1 327245-02 0be0603c
amiga extras + amiga tutor + abasic 316167-01 3cbf918d


These have Finnish PCI Data-part numbers and matrix printer labels, I've had several A1000s with a similar disk set, so they are as "authentic" as people got in the 80s:

kickstart 1.2 13546 9952865a
workbench 1.2 13547 5b47ca49
extras 1.2 13548 3cbf918d
amiga tutor finnish 13549 c8a734ac

[cosmicfrog]

all this time stamp stuff becomes irrelevant if the write protect tab is on & has never been off

[Jope]

Originally Posted by cosmicfrog

all this time stamp stuff becomes irrelevant if the write protect tab is on & has never been off

But none of us know for sure whether this is true for all the original disks we have in our possession.

[Toni Wilen]

I have same original disks and only KS 1.1 checksum matches..

[rhester72]

Is it the 1.2 stuff that doesn't match? Because there were at least 4 different public revs of that...

Rodney

[Toni Wilen]

2327431c ?CRC32*extras_1.2_13548.adf
a010b4c6 ?CRC32*extras_316167-01.adf
7c45b834 ?CRC32*kaleidoscope_316160-01.adf
70d0030a ?CRC32*kickstart_1.1_pal_327244-02.adf
b57fd60f ?CRC32*tutor_fi_13549.adf
998b3fba ?CRC32*workbench_1.1_327245-02.adf
9b0c3af0 ?CRC32*workbench_33.47_13547.adf