30 December 2009, 02:31 | #81 | |
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
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. Last edited by Supamax; 31 December 2009 at 22:42. Reason: typos |
|
30 December 2009, 02:35 | #82 | |
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
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 |
|
30 December 2009, 08:42 | #83 |
(Amigas && Amigos)++
Join Date: Sep 2005
Location: Anrea
Posts: 999
|
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. |
30 December 2009, 15:11 | #84 |
Registered User
Join Date: Feb 2008
Location: New York / USA
Posts: 361
|
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 |
30 December 2009, 16:25 | #85 | |
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
Quote:
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. |
|
30 December 2009, 18:02 | #86 |
Registered User
Join Date: Feb 2008
Location: New York / USA
Posts: 361
|
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 |
30 December 2009, 18:10 | #87 | |
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
Quote:
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). |
|
30 December 2009, 20:39 | #88 | |
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
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)... 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 Last edited by Supamax; 30 December 2009 at 21:00. Reason: typo |
|
30 December 2009, 20:55 | #89 |
Registered User
Join Date: Feb 2008
Location: New York / USA
Posts: 361
|
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 |
30 December 2009, 20:56 | #90 | ||
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
Quote:
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. Quote:
I only wish to remove erroneous checksums from the list you are maintaining in this thread. |
||
30 December 2009, 21:14 | #91 |
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
@ 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" Last edited by Supamax; 05 January 2010 at 01:32. |
30 December 2009, 21:35 | #92 |
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
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.
|
30 December 2009, 22:32 | #93 | |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,918
|
Quote:
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. Last edited by Jope; 31 December 2009 at 14:13. Reason: fixed the partno for the superkick floppy |
|
31 December 2009, 14:05 | #94 |
Registered User
Join Date: Feb 2008
Location: New York / USA
Posts: 361
|
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 |
31 December 2009, 16:08 | #95 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,918
|
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 Last edited by Jope; 31 December 2009 at 16:41. |
31 December 2009, 16:35 | #96 |
The 1 who ribbits
|
all this time stamp stuff becomes irrelevant if the write protect tab is on & has never been off
|
31 December 2009, 16:41 | #97 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,918
|
|
31 December 2009, 16:47 | #98 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
I have same original disks and only KS 1.1 checksum matches..
|
31 December 2009, 17:01 | #99 |
Registered User
Join Date: Feb 2008
Location: New York / USA
Posts: 361
|
Is it the 1.2 stuff that doesn't match? Because there were at least 4 different public revs of that...
Rodney |
31 December 2009, 17:09 | #100 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
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 |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Amiga Workbench 2.1 Disks Original | mr_magnell | request.Apps | 4 | 21 August 2013 11:42 |
original amiga 3.1 roms and workbench disks | alienkidmj12 | request.Apps | 1 | 10 March 2012 17:25 |
ORIGINAL Workbench (any version) | Supamax | request.Other | 1 | 09 January 2009 22:10 |
Workbench 3.1 - original disk contents | Bloodwych | support.Apps | 7 | 04 December 2007 18:18 |
Problem with original Workbench 1.3.2 | mindtilt | support.Apps | 0 | 18 January 2006 01:42 |
|
|