Aztec C 3.6a Disk 3 with Read Errors

[Lonewolf10]

Originally Posted by prowler

Edit1: Beaten to the post by Lonewolf10!

Hehe, sorry about that


Regards,
Lonewolf10

[aragon]

Hey djukon,

here we go. I have upped my Aztec-C archives to the Zone.

Please check if 3.6a Disk 3 is ok for you now. I could not find any errors.

If you really want to go with 3.6a be sure to spin up the SDB (Source Level Debugger). This was really useful back in the day.

I have upped the 5.0a and 5.2a archives as well, as these supported Kick/WB 2.x.

Have fun and let us know of your progress

[prowler]

Great work, aragon!

Now all the Aztec C TOSEC disks can be checked.

Edit1: @aragon: There are discrepancies between each of your v3.6a and v5.0a disk images and those in TOSEC. Please don't interpret this as a criticism of your disk imaging technique. As I have said, the Aztec C v3.6a TOSEC disk 3 image was evidently produced without any regard to error checking and the same may well be true of the others.

I will investigate the discrepancies more thoroughly tomorrow.

Edit2: The Aztec v5.0a TOSEC disks are identical to those available here.

Aztec C for the Amiga
Version 5.0a
1/9/89

aztecc50a.zip
ReadMe

Of course, that may well be where the disks in TOSEC originated.

Edit3: @Nathan: Don't be discouraged. We may still require your sets to nail this one.

[Supamax]

Originally Posted by prowler

@aragon: There are discrepancies between each of your v3.6a and v5.0a disk images and those in TOSEC. Please don't interpret this as a criticism of your disk imaging technique.

@aragon (and @ anybody who can find this useful):

I imaged all my floppies (they are thousands) two times (I always do so). Then I compared their respective .adf files with a Windows byte-per-byte compare utility.
- If they are equal, OK, I can reasonably presume that they are correct
- if not, I do a third image of the disk and then compare it with the previous two
- if 2 out of 3 are equal, I reasonably presume that those 2 are correct images of the floppy disk. The different one is bad.

[aragon]

I'm not surprised that there might be differences to the TOSEC versions. OTOH, lots of TOSEC dumps were not made from clean, unchanged disks. That's not to say that the dumps I provided are 100% perfect - but at least they were dumped from my original disks and not downloaded from anywhere else.

In the case of applications disks, what would be of more interest are the individual checksums and contents of the files. Nowadays we are used to daily snapshots on SVN repositories, but back then I think that some companies delivered minor bugfixes without notification and bumping the release number. So maybe it would be interesting to see if there are any differences in the content of the TOSEC 3.6a and my version -- I think I will investigate this, too.

After unpacking all the disks and comparing the contents, I have found this:

- the TOSEC version contains the Library Source as Disk 2, but misses the SDB. This is no surprise, as the SDB was sold separately back then. But as far as I remember, the Library Sources were sold separately as well. Anyway, I always wanted them, but did not bother to look at the TOSEC version. So, hooray! What a fine day!

- apart from that, the only file differences are on the SYS3 disk, which was broken in the TOSEC archive. prowler's repair attempts have fixed some of them, but only 3 remain broken in the sense that the original content could not be restored.
These are:
examples/shell/comm1.c
examples/shell/main.c
examples/shell/run.c

To wrap things up I would replace the SYS3 version of the TOSEC archives with SYS3 from my version and add the SDB, giving a new complete Aztec 3.6a distribution with 5 disks!

Final remark: If you want to install these to a harddisk, make sure the SYS3/examples do not override the SYS2/examples, or the makefile and makeit will be mangled over!

[aragon]

Just found an interesting book on Amiga development in the early days.
Check this link to "Amiga for Advanced Programmers". It starts with an introduction to the first C compilers on the Amiga, Aztec-C and Lattice-C, which became SAS-C later.

Chapter 1.1.1 will tell you some details about the different packages of Aztec-C 3.6a you could purchase.

On that site you can find some more manuals and books if you're interested.
Unfortunately, the original 3.6a Reference Manual seems to be lost in time...

Enjoy!

[prowler]

Aragon has uploaded a set of Aztec v3.6a disk images, the checksums all of which are different to the TOSEC set. Binary comparison of WIP3.adf with Disk 3 of this set showed that the structure of the two disks was broadly similar. Crucially, I discovered that copying Disk Blocks 1232-1342 and 1283 into the WIP3 disk image would repair the damaged files!

Disk Block 1283 fixed the main.c file, Disk Blocks 1241-1242 fixed the run.c file and Disk Blocks 1232-1240 fixed the comm1.c file. I have uploaded the WIP4 disk image to The Zone.

Aragon's disk image has provided the original data required to fix the Aztec v3.6a TOSEC Disk 3 image and it contains all the same files. However, there is a new Bitmap as well as a copy of the old one and there is an extra file in the root directory:

.info         16 ----rwed 26-Mar-90 09:44:28

I am certain that neither aragon's Aztec v3.6a Disk 3 image, nor the TOSEC one, even when fixed, is a true copy of an original, unmodified disk. The root blocks of both images show that the original disk was created on 20-Dec-1987 at 22:25:33 and remains unmodified, and yet aragon's dump contains a postdated file and the unused blocks of the TOSEC disk image have been cleared, which is unlikely. An original disk dump will probably turn out to feature elements of both disk images.

Nathan has the original Aztec v3.6a disks which should settle the matter. In the meantime, both aragon's dump and the fixed (WIP4) TOSEC disk image will provide a full working copy of the software.

I have not yet been able to spend sufficient time on this to check the other disks, but what I have discovered so far shows just why the TOSEC DATs are so difficult to maintain.

Originally Posted by aragon

After unpacking all the disks and comparing the contents, I have found this:

- the TOSEC version contains the Library Source as Disk 2, but misses the SDB. This is no surprise, as the SDB was sold separately back then. But as far as I remember, the Library Sources were sold separately as well. Anyway, I always wanted them, but did not bother to look at the TOSEC version. So, hooray! What a fine day!

- apart from that, the only file differences are on the SYS3 disk, which was broken in the TOSEC archive. prowler's repair attempts have fixed some of them, but only 3 remain broken in the sense that the original content could not be restored.
These are:
examples/shell/comm1.c
examples/shell/main.c
examples/shell/run.c

My WIP4 disk image fixes those files too, thanks to your dump!

Originally Posted by aragon

To wrap things up I would replace the SYS3 version of the TOSEC archives with SYS3 from my version and add the SDB, giving a new complete Aztec 3.6a distribution with 5 disks!

Final remark: If you want to install these to a harddisk, make sure the SYS3/examples do not override the SYS2/examples, or the makefile and makeit will be mangled over!

A 5 disk distribution is a great suggestion, but let's have a look at Nathan's disk images first, eh?

Originally Posted by aragon

Unfortunately, the original 3.6a Reference Manual seems to be lost in time...

Nathan has that too!

[aragon]

Hey prowler,

thanks again for your work!

I'm glad to see that someone tries to restore the original distributions in all their glory. I'm excited to see what Nathan has to offer!

TOSEC as well as other dumping/preservation efforts tends to be quite messy. If you take a look at the dumps available for other retro computers and consoles, you will see that it is nearly impossible to find a source with only clean, unaltered disk or rom dumps.

Taking the Amiga, I think there should be an initiative and place to collect all the application software. Games are covered much better that apps, but where is a repository of all the great apps that defined the Amiga in a state that is not as incomplete or messy as TOSEC?

What do you guys think about this? Hanging around at EAB for some years, I don't see that this has changed for the better. There were some people trying to set up ftp space for an apps repository, but after loading up a bunch of apps, that disappeared without any backup :-(

Looking forward for the 3.6a Reference Manual! I found the 5.0a manual at the site I posted yesterday.

[djukon]

aragon and prowler, great job! And thank you .

Now I only have time for a quick reply. I'll check back as soon I can try out 3.6a with the new disks.

[prowler]

Originally Posted by aragon

Hey prowler,

thanks again for your work!

I'm glad to see that someone tries to restore the original distributions in all their glory. I'm excited to see what Nathan has to offer!

When salvaging/repairing floppy disks/images, I always try to retain or reconstruct all the original data, including that in loose blocks. The Amiga's file system, in particular the OFS, helps tremendously in this respect with its bitmap, lists, pointers and checksums. Thankyou for your comment; it's encouraging to know that this effort is appreciated.

It may well be that Nathan's uploads will provide the definitive set of original dumps but, if not, then, when I have time, I will try to create such a set, on a maximum likelihood basis, from the three sets of disk images we will have.

Originally Posted by aragon

TOSEC as well as other dumping/preservation efforts tends to be quite messy. If you take a look at the dumps available for other retro computers and consoles, you will see that it is nearly impossible to find a source with only clean, unaltered disk or rom dumps.

Taking the Amiga, I think there should be an initiative and place to collect all the application software. Games are covered much better that apps, but where is a repository of all the great apps that defined the Amiga in a state that is not as incomplete or messy as TOSEC?

What do you guys think about this? Hanging around at EAB for some years, I don't see that this has changed for the better. There were some people trying to set up ftp space for an apps repository, but after loading up a bunch of apps, that disappeared without any backup :-(

The most disappointing feature of TOSEC relative to the Amiga (and probably other platforms too) is the sheer abundance of alternate [a] dumps. With a bit of work, I should think many of these could be discounted on the basis of their obviously having been modified.

And, hey, don't you know about the EAB File Server as a source for Amiga apps, demos, games and just about everything else?

[TCD]

Originally Posted by prowler

The most disappointing feature of TOSEC relative to the Amiga (and probably other platforms too) is the sheer abundance of alternate [a] dumps. With a bit of work, I should think many of these could be discounted on the basis of their obviously having been modified.

TOSEC indexes every disk image (modified or not) that is found, so people can check if they have disks not contained in the TOSEC DATs. More important would be that people would check in which way a disk image is modified and let someone that can change the TOSEC DATs know.

[prowler]

Originally Posted by TheCyberDruid

TOSEC indexes every disk image (modified or not) that is found, so people can check if they have disks not contained in the TOSEC DATs. More important would be that people would check in which way a disk image is modified and let someone that can change the TOSEC DATs know.

I'm sorry, I had not intended to be critical of TOSEC. What I wished to suggest (but actually neglected to say ) was that the TOSEC DATs could be used as a starting point for creating the kind of file repository which aragon and many others would like to see. Checking the disks for obvious signs of modification would be necessary to identify those not suitable for inclusion, and if this were also to be helpful towards improving the TOSEC DATs, then so much the better. Phew!

[TCD]

No worries Just wanted to point a quite common misunderstanding about TOSEC out (not saying that you gave the false impression, but like you said it wasn't that clear either ). Would be great to have a 'goodset' DAT based on TOSEC and other sources, that includes original and/or fully working 'backup copies' of apps/demos/games etc. Not holding my breath though, since that would require some serious amount of work...

[Supamax]

Originally Posted by prowler

When salvaging/repairing floppy disks/images, I always try to retain or reconstruct all the original data, including that in loose blocks. The Amiga's file system, in particular the OFS, helps tremendously in this respect with its bitmap, lists, pointers and checksums. Thankyou for your comment; it's encouraging to know that this effort is appreciated.

I'm one of those who appreciate your competence and your salvaging work . I think it's precious.
I still don't know (one day I'll ask you thorougly about it ) how you generally manage to fix damaged disks without altering the disk fat / file map... you're able to fix/overwrite the damaged files with good ones "right in the disk image/adf"... this is very good, since it retains the original structure.
By the way, sooner or later (time is a jailer, as Anouk sings) we'll cooperate again on the unfinished work about A-Max.. I'm counting on it

[prowler]

Originally Posted by Supamax

I'm one of those who appreciate your competence and your salvaging work . I think it's precious.
I still don't know (one day I'll ask you thorougly about it ) how you generally manage to fix damaged disks without altering the disk fat / file map... you're able to fix/overwrite the damaged files with good ones "right in the disk image/adf"... this is very good, since it retains the original structure.

Thanks for your kind words, mate.

I often think I really ought to start a Disk Recovery Tips and Tricks Masterclass thread, but it would not be easy to write as there are so many things to be aware of simultaneously.

I think that djukon had the right idea when he asked me to provide some links to good websites and utilities, so that he could read up on the subject. With that in mind, I shall be posting some links here shortly.

Originally Posted by Supamax

By the way, sooner or later (time is a jailer, as Anouk sings) we'll cooperate again on the unfinished work about A-Max.. I'm counting on it

Yes indeed. I look forward to that.

[Supamax]

Originally Posted by prowler

I often think I really ought to start a Disk Recovery Tips and Tricks Masterclass thread, but it would not be easy to write as there are so many things to be aware of simultaneously.

It would be great if you could find the time to do it!
Even a simple, little hints&tricks guide. You could update it later...

I think that djukon had the right idea when he asked me to provide some links to good websites and utilities, so that he could read up on the subject. With that in mind, I shall be posting some links here shortly.

thanks

Perhaps the best idea is to start a new thread, as you wrote... then it would grow with EAB user's contributions/questions, your answers etc.

[aragon]

Originally Posted by prowler

And, hey, don't you know about the EAB File Server as a source for Amiga apps, demos, games and just about everything else?

I just learned a few days ago of its existence. Nice work, if this is here to stay I would be more than happy to contribute what I can!

Most of the dumps I did have been created many years ago, but have been backed up regularly. Maybe I should start adding a folder with the list of apps I can provide.

[Lonewolf10]

Originally Posted by prowler

Due to one or more bad blocks on the original Aztec C v3.6 disk 3 used to make the image, Track 56, Side 0 contains a duplicate of the data from Track 55, Side 0, i.e. Disk Blocks 1232-1242 contain the same data as Disk Blocks 1210-1220.

The consequence of this is that in the examples/shell subfolder, the last nine data blocks of comm1.c and the second and third data blocks of run.c have been replaced with copies of the last nine data blocks of readme.205m and the second and third data blocks of rawconsole.c, respectively.

Just curious, how did you work all this out? Did you use Dave Haynies DiskSalv software, or did you examine the adf's manually?


Regards,
Lonewolf10

[prowler]

Originally Posted by Lonewolf10

Just curious, how did you work all this out? Did you use Dave Haynies DiskSalv software, or did you examine the adf's manually?

Regards,
Lonewolf10

Hi Lonewolf10, and thanks for your question.

I had started to reply just as soon as you posted, but then noticed that you had amended the quoted text.

So that I could determine the reason that the comm1.c file included text from the end of the readme.205m file, I mapped all blocks and file chains on the disk using DiskMonTools.

Mounting the WIP3 disk image as DF0: in WinUAE and using the 'DiskMon' feature of DiskMonTools on the emulated floppy drive, I viewed all 1760 blocks on the disk to map out the file chains.

With this process completed, I could determine the following:

1) Disk Blocks 1232-1242 contained a copy of the data in Disk Blocks 1210-1220,

2) Disk Blocks 1210-1220 contained the last nine data blocks of readme.205m followed by the second and third data blocks of rawconsole.c,

3) Disk Blocks 1232-1242 should have contained the last nine data blocks of comm1.c and the second and third data blocks of run.c, and

4) Copies of the missing data blocks did not appear elsewhere on the disk.

Each file's Header Block lists the data block sequence.

The 'DiskMon' feature of DiskMonTools facilitates the disk mapping process by presenting all the necessary information relating to each block.

In my experience, imaging floppy disks with bad blocks can often produce duplicate adjacent tracks in the destination image. Hence my opinion that one or more bad blocks on Track 56, Side 0 was the cause.

I hope this answers your question.

[Lonewolf10]

Originally Posted by prowler

I had started to reply just as soon as you posted, but then noticed that you had amended the quoted text.

Sorry about that. Some people have a tendancy to respond too quickly!

Thanks for the info. I'll keep that in mind next time I have problems with disks.


Regards,
Lonewolf10