Andreas' TOSEC disk fixing project

andreas · 12 March 2003, 22:29

OK, here's a separate thread. I didn't feel well about cramming everything into That TOSEC Thread [tm]. I even didn't think this'll be such a big thing - but it will.

My aim is it to not only fulfil my motto readable under my name

, but also to get at least one working disk of a program (application or game) into TOSEC.

Since a lot of disks aren't available in their "original" form anymore (even so-called "scene releases" are usually infected by AT LEAST one virus!), I decided to fix virus-infected and/or broken disks myself (if possible) if and only if there's no alternative working dump (yet) to be found in TOSEC.
There *might*, however, exist not-yet-dumped, fully working images lying around in someone's disk boxes, and my work may, sooner or later, be in vain. But there are two reasons why I'm willing to put up with this anyway:

- it would require me to request every disk separately, as soon as I know that there's no working dump available. This would be a pain for the whole EAB if some same single person keeps on requesting stuff. No thanks.

- it may take VERY long until some new member comes to EAB who has this very disk eventually.
And I'm a bit impatient concerning this topic ... so I'm not going to wait that long!

So let's start with the first ones!

andreas · 12 March 2003, 22:34

[1] 100% fixed version of ACU Graphics Utilities Disk 13.

As another dump seems hard to get (if you can supply one anyway, let me know!), I fixed the bad version from TOSEC. (DAT = applications - compilations)

- Recovered disk structure and rehashed directory structure using DiskSalv 4. Result: only disk structure was defective (key 968 used twice), no files were damaged!

- Virus-checked disk and fixed bitmap so that it's now validated again. Found BGS9 virus sitting on block #1747 and removed it. First file in startup-sequence 'border' had been renamed by the virus program to a sequence of $A0 (dec = 160) and spaces $20 (dec = 32) and been moved to :devs.

- Re-renamed file in :devs to :c/border, deleting old file in :c ( = virus!)

[2a] Super Amiga Utilities 2 (c) 1992 Trinacia [ITALIAN].
This disk was not validated. I reversed this situation. Furthermore, command 'cd' was corrupt and spit out an Error 111 when launched. I replaced it by an identical command from my WB 1.3.

[2b] Super Amiga Utilities 3 (c) 1992 Trinacia [ITALIAN].
The TOSEC image contained a SADDAM virus and had the wrong name (was actually S. A. U. volume 3, not volume 2). I removed this virus and a fully-working, virus-free version is now in the zone!

jmmijo · 13 March 2003, 01:18

Good job Andreas

§ane · 13 March 2003, 05:00

From: Super Amiga Utilities 2 (1992)(Trinacia)(It)[v Saddam]
To: Super Amiga Utilities 2 (1992)(Trinacia)(It)[m andreas]

Nice.

Wait on a redump.

Big-Byte · 13 March 2003, 10:17

so the file Super Amiga Utilities 2 (1992)(Trinacia)(It)[v Saddam]
can go into my Files to DELETE from tosec dat then? (see my thread)

andreas · 13 March 2003, 21:45

Quote:

Originally posted by §ane
From: Super Amiga Utilities 2 (1992)(Trinacia)(It)[v Saddam]
To: Super Amiga Utilities 2 (1992)(Trinacia)(It)[m andreas]

Well you don't need to mention my name, I'm not that self-asserted that I would need that "recognition" for my work

[m] would be enough.
There aren't any hidden messages included by me in startup-sequence either

BTW: If you had read carefully, it's Utilities 3 previously containing the Saddam virus, not 2. TOSEC was WRONG here. Start up the disk and see.

@BigByte: of course!

§ane · 14 March 2003, 05:12

Quote:

Originally posted by andreas

Well you don't need to mention my name, I'm not that self-asserted that I would need that "recognition" for my work

Quote:

There aren't any hidden messages included by me in startup-sequence either

It's never about recognition when someone defaces an image. It concerns information integrity.

Quote:

[m] would be enough.

I RESPECT your commitment to 0% faulty versions. Although, I EXPECT to see the appropriate tag on ALL of those restored.

Quote:

BTW: If you had read carefully, it's Utilities 3 previously containing the Saddam virus, not 2. TOSEC was WRONG here. Start up the disk and see.

My mistake.

Quote:

You have that one without the virus on real disk?

Do not know. My only fear is that these damaged versions will be deleted or replaced and forgotten. The ball is already in motion. If ever a redump in better shape becomes available, with no reference but those modified copies, how are we to verify the entire image (sections that aren't corrupt) when the file system is arsed about on account of andreas meddling with it.

Edit: To fill some holes.

andreas · 14 March 2003, 14:26

Quote:

Originally posted by §ane
If ever a redump in better shape becomes available, with no reference but those modified copies, how are we to verify the entire image...

:theparano

I don't get this part. Please revise or put it another way so that I understand it. Sounds completely incoherent to me, and even grammar escapes me here to get the meaning.

14 March 2003, 15:26

Quote:

Originally posted by andreas
:theparano
I don't get this part. Please revise or put it another way so that I understand it. Sounds completely incoherent to me, and even grammar escapes me here to get the meaning.

If this disk ever gets redumped, how are you going to know if the redump is a proper good dump if the only reference you have is the modified version?

andreas · 14 March 2003, 15:35

Ah NOW. Thank you.
So what Sane meant was that therefore the damaged copies should NOT be deleted to have a reference object for checking. I see.

/set obtuse_mode off

HOWEVER...
@Sane, there is no filesystem "arsed" by me, but everything was left in original state as closely as possible. That is I will NOT replace non-standard bootblocks if there's no actual urge to do so. And I also don't replace commands by some other commands if there's another way: I even try to find *THAT* cd command from *THAT* version of WB with *THAT* size that was used in the original disk, avoiding any randomly available stuff just for "filling a hole".
In any case, I'm doing this because there's a probability that some redumps might never see the light of day because the corresponding real disks are lost.

§ane · 14 March 2003, 18:11

Quote:

Originally posted by andreas
So what Sane meant was that therefore the damaged copies should NOT be deleted to have a reference object for checking.

Very good. It's settled. Thanks Amigaboy.

Quote:

HOWEVER...

Does the working cd executable occupy the same sectors on disk as the corrupt copy, or has it been reallocated elsewhere? Are file attributes (pure bit?) and dates intact?

Quote:

In any case, I'm doing this because there's a probability that some redumps might never see the light of day because the corresponding real disks are lost.

Understood, that's acceptable.

andreas · 14 March 2003, 18:59

Quote:

Originally posted by §ane
Does the working cd executable occupy the same sectors on disk as the corrupt copy, or has it been reallocated elsewhere? Are file attributes (pure bit?) and dates intact?

Same sectors? I can't say. I don't know that if I replace a broken command executable by it's equivalent working one, it really occupies the same sectors.
If you really WANTED to be absolutely sure about this, you would have to hack the blocks until the previously-non-working 'cd' is (again!) physically the same as the working one. But that would really be a pain because you would have to "x-ray" each and every block affiliated until the checksum is, block-wise, EXACTLY the one as on the previous disk.
BTW:'copy ... clone' should fix the latter problem with flying colors.

Twistin'Ghost · 14 March 2003, 21:26

Is this level of exact replication really worth all of this for a freakin' compact?!? Why is the pure, original state of such a disk as this even neccesary. It's the equal to environmental extremists hellbent on saving every species of bug that exists simply because it's there. There are times when a facsimilie is enough. Next thing, someone will want to preserve the exact data structure of [m] disks...

andreas · 15 March 2003, 00:07

Quote:

Originally posted by Twistin'Ghost
Is this level of exact replication really worth all of this for a freakin' compact?!?

Not really, therefore I said I would stop at a certain extent for reasons of common sense.

jmmijo · 15 March 2003, 00:35

Quote:

Originally posted by Twistin'Ghost Is this level of exact replication really worth all of this for a freakin' compact?!? Why is the pure, original state of such a disk as this even neccesary. It's the equal to environmental extremists hellbent on saving every species of bug that exists simply because it's there. There are times when a facsimilie is enough. Next thing, someone will want to preserve the exact data structure of [m] disks...

So what are you really saying here TG, that we're not anal enough

andreas · 21 March 2003, 18:46

Nice you made some room. However, the content of my post will definitely not be "friendly" this time.
Who the fuck do you think you are?!

Quote:

Originally posted by §ane
It's never about recognition when someone defaces an image. It concerns information integrity.

Well, I'm not that perfect english speaker, so I needed some auxiliary tools to get the meaning.
AND WHAT DID I SEE?
...
http://www.merriam-webster.com/cgi-b...nary&va=deface

DEFACE. Ah yes. I deface images. Mind you, in Germany the word is "verunstalten". And it's sometimes used for some architects that restaurate an old building, making it look 100 TIMES WORSE than before the restauration process afterwards.

It's nice I get the REAL meaning what you think of my work. I once kept my mouth shut, and Amigaboy "clarified" (or should I say 'dilute' / 'embellish'?!) the situation by explaining what you actually meant.

But you've shown your true face this time.

And don't try to tell me you don't know anything about a NEGATIVE meaning of 'to deface'.
You're the native speaker, not me.

*not amused*

RCK · 21 March 2003, 19:44

you didn't have to react like this,
you always go to far when you're not happy, can't you take it easy ?

§ane · 22 March 2003, 04:07

Quote:

Originally posted by andreas
Nice you made some room. However, the content of my post will definitely not be "friendly" this time.

My Inbox full, your PM lost, you flame here, NICE.

Quote:

http://www.merriam-webster.com/cgi-b...nary&va=deface

DEFACE. Ah yes. I deface images. Mind you, in Germany the word is "verunstalten". And it's sometimes used for some architects that restaurate an old building, making it look 100 TIMES WORSE than before the restauration process afterwards.

I RESPECT and SUPPORT YOUR work, BUT I cannot stress more, NOT if it means losing the references images. Are we clear on this yet?

Quote:

Originally posted by andreas
There aren't any hidden messages included by me in startup-sequence either

So I should hope not! THIS really would be defacing the image and THIS is the misunderstanding. I was too blunt with my denotation before.

Perhaps the fix tag would better clarify these images, it still constitutes a hack or modification, when they shouldn't be passed off as anything else (i.e. Good dumps).

[f andreas]

We know the fixer, your name is attached to the tag to comply with the TNC and to be complete for future reference.

I'm truly sorry if I sapped your incentive and motivation with my former comments. I know too well what that is like. I do hope you continue with this project.

Amiga1992 · 22 March 2003, 04:25

You exact-bit fetishists

Come on, let's not get that serious, andreas. I don't think Sane tried to offend you.

Feltzkrone · 24 March 2003, 13:27

First of all it's a good thing which andreas does. As I'm rather passive concerning the further development of ADFRen this is a first step into a nice direction.

Nobody does need bad dumps if good dumps for the same disk exist. As andreas' task is to provide working versions of formerly bad dumps by manipulating it in a normal way (replacing corrupt files by working ones) the chances are very low that one "fixed" disk show errors where the formerly "bad" disk worked well.

But, (@andreas): You should be aware of one thing - some disks are "hybrid" (anyone got a better term for this?). For example Saint Dragon (if I remember correctly) has got normal ADOS-filesystem parts, therefore uses the normal filesystem routines but uses a pure trackloader for the actual game data. Now, if those data tracks aren't marked in the ADOS bitmap sector as being occupied, any replacement of broken files by good ones may result in overwritten game data as the replacement may have been placed where once the raw game data has been located.

Therefore: If you can't be sure that replaced files occupy the very same sectors as the old, broken files have done, you should be aware of if the game uses raw trackdata elsewhere which could be overwritten when replacing an ADOS-file.

Anyway, on pure ADOS-disks it doesn't matter at all. Feel free to run ReOrg to make a disk load even faster!

(I'm no bit fetishist!)

12 March 2003, 22:34	#2
andreas Zone Friend Join Date: Jun 2001 Location: Germany Age: 50 Posts: 5,857	Let's start the show! [1] 100% fixed version of ACU Graphics Utilities Disk 13. As another dump seems hard to get (if you can supply one anyway, let me know!), I fixed the bad version from TOSEC. (DAT = applications - compilations) - Recovered disk structure and rehashed directory structure using DiskSalv 4. Result: only disk structure was defective (key 968 used twice), no files were damaged! - Virus-checked disk and fixed bitmap so that it's now validated again. Found BGS9 virus sitting on block #1747 and removed it. First file in startup-sequence 'border' had been renamed by the virus program to a sequence of $A0 (dec = 160) and spaces $20 (dec = 32) and been moved to :devs. - Re-renamed file in :devs to :c/border, deleting old file in :c ( = virus!) [2a] Super Amiga Utilities 2 (c) 1992 Trinacia [ITALIAN]. This disk was not validated. I reversed this situation. Furthermore, command 'cd' was corrupt and spit out an Error 111 when launched. I replaced it by an identical command from my WB 1.3. [2b] Super Amiga Utilities 3 (c) 1992 Trinacia [ITALIAN]. The TOSEC image contained a SADDAM virus and had the wrong name (was actually S. A. U. volume 3, not volume 2). I removed this virus and a fully-working, virus-free version is now in the zone! Last edited by andreas; 21 March 2003 at 14:15.

13 March 2003, 05:00	#4
§ane Registered User Join Date: Jul 2001 Location: . Age: 44 Posts: 246	From: Super Amiga Utilities 2 (1992)(Trinacia)(It)[v Saddam] To: Super Amiga Utilities 2 (1992)(Trinacia)(It)[m andreas] Nice. Wait on a redump. Last edited by §ane; 13 March 2003 at 05:07.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Massive disk archiving project - Looking for advice	thgill	Amiga scene	75	04 September 2010 14:37
how to transfer non-dos TOSEC images to disk?	NfernalNfluence	New to Emulation or Amiga scene	3	24 June 2007 17:37
Amiga Docs Disk Preservation Project	mrodfr	News	10	17 February 2007 18:24
Save Disk Contribution for TOSEC	Marcuz	project.TOSEC (amiga only)	15	22 November 2006 20:09
Project - X data disk	Djay	support.Games	6	27 February 2003 15:49

12 March 2003, 22:29	#1
andreas Zone Friend Join Date: Jun 2001 Location: Germany Age: 50 Posts: 5,857	Andreas' TOSEC disk fixing project OK, here's a separate thread. I didn't feel well about cramming everything into That TOSEC Thread [tm]. I even didn't think this'll be such a big thing - but it will. My aim is it to not only fulfil my motto readable under my name , but also to get at least one working disk of a program (application or game) into TOSEC. Since a lot of disks aren't available in their "original" form anymore (even so-called "scene releases" are usually infected by AT LEAST one virus!), I decided to fix virus-infected and/or broken disks myself (if possible) if and only if there's no alternative working dump (yet) to be found in TOSEC. There might, however, exist not-yet-dumped, fully working images lying around in someone's disk boxes, and my work may, sooner or later, be in vain. But there are two reasons why I'm willing to put up with this anyway: - it would require me to request every disk separately, as soon as I know that there's no working dump available. This would be a pain for the whole EAB if some same single person keeps on requesting stuff. No thanks. - it may take VERY long until some new member comes to EAB who has this very disk eventually. And I'm a bit impatient concerning this topic ... so I'm not going to wait that long! So let's start with the first ones! Last edited by andreas; 12 March 2003 at 22:43.

13 March 2003, 01:18	#3
jmmijo Junior Member Join Date: Jan 2002 Location: PDX Age: 62 Posts: 2,395	Good job Andreas

13 March 2003, 10:17	#5
Big-Byte Long time member Join Date: Jul 2001 Location: UK Posts: 754	so the file Super Amiga Utilities 2 (1992)(Trinacia)(It)[v Saddam] can go into my Files to DELETE from tosec dat then? (see my thread)

14 March 2003, 15:35	#10
andreas Zone Friend Join Date: Jun 2001 Location: Germany Age: 50 Posts: 5,857	Ah NOW. Thank you. So what Sane meant was that therefore the damaged copies should NOT be deleted to have a reference object for checking. I see. /set obtuse_mode off HOWEVER... @Sane, there is no filesystem "arsed" by me, but everything was left in original state as closely as possible. That is I will NOT replace non-standard bootblocks if there's no actual urge to do so. And I also don't replace commands by some other commands if there's another way: I even try to find THAT cd command from THAT version of WB with THAT size that was used in the original disk, avoiding any randomly available stuff just for "filling a hole". In any case, I'm doing this because there's a probability that some redumps might never see the light of day because the corresponding real disks are lost.

14 March 2003, 21:26	#13
Twistin'Ghost Give up the ghost Join Date: Apr 2001 Location: U$A Age: 33 Posts: 4,662	Is this level of exact replication really worth all of this for a freakin' compact?!? Why is the pure, original state of such a disk as this even neccesary. It's the equal to environmental extremists hellbent on saving every species of bug that exists simply because it's there. There are times when a facsimilie is enough. Next thing, someone will want to preserve the exact data structure of [m] disks...

21 March 2003, 19:44	#17
RCK Administrator Join Date: Feb 2001 Location: Paris / France Age: 45 Posts: 3,086	{signature removed} you didn't have to react like this, you always go to far when you're not happy, can't you take it easy ?

22 March 2003, 04:25	#19
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	You exact-bit fetishists Come on, let's not get that serious, andreas. I don't think Sane tried to offend you.

24 March 2003, 13:27	#20
Feltzkrone Junior Member Join Date: Apr 2002 Location: Germany Posts: 103	First of all it's a good thing which andreas does. As I'm rather passive concerning the further development of ADFRen this is a first step into a nice direction. Nobody does need bad dumps if good dumps for the same disk exist. As andreas' task is to provide working versions of formerly bad dumps by manipulating it in a normal way (replacing corrupt files by working ones) the chances are very low that one "fixed" disk show errors where the formerly "bad" disk worked well. But, (@andreas): You should be aware of one thing - some disks are "hybrid" (anyone got a better term for this?). For example Saint Dragon (if I remember correctly) has got normal ADOS-filesystem parts, therefore uses the normal filesystem routines but uses a pure trackloader for the actual game data. Now, if those data tracks aren't marked in the ADOS bitmap sector as being occupied, any replacement of broken files by good ones may result in overwritten game data as the replacement may have been placed where once the raw game data has been located. Therefore: If you can't be sure that replaced files occupy the very same sectors as the old, broken files have done, you should be aware of if the game uses raw trackdata elsewhere which could be overwritten when replacing an ADOS-file. Anyway, on pure ADOS-disks it doesn't matter at all. Feel free to run ReOrg to make a disk load even faster! (I'm no bit fetishist!)

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)