Raytracer 1.0

[mark_k]

Yeah, it's strange. At the AmigaDOS/file level, the original and repaired images are identical, apart from the file datestamps which are broken on the "repaired" ADF (06-Feb-78).

dottyflowers: what exactly was wrong with the original ADF, and how did you create the repaired one?

[emufan]

Originally Posted by dottyflowers

... If I don't hear anything in a day or two I'll try the comcast one.

ok

[dottyflowers]

Hi Crashdisk, on the original Movie2 wouldn't load because of some checksum errors on track 2. It works for you?

@emufan: Mr. Graham responded and was happy to have it back :-)

[emufan]

Originally Posted by dottyflowers

@emufan: Mr. Graham responded and was happy to have it back :-)

cool

[prowler]

I intend to give these disk images some detailed scrutiny when I have rebuilt my workstation.

[Crashdisk]

Originally Posted by dottyflowers

Hi Crashdisk, on the original Movie2 wouldn't load because of some checksum errors on track 2. It works for you?

There is no error on the original disk and the movie2 works without displaying a visual error. You were probably errors before transfer with Kryoflux...

Originally Posted by prowler

I intend to give these disk images some detailed scrutiny when I have rebuilt my workstation.

Still not finished?

[emufan]

does anyone have a valid command line for the ssg tool?
"ssg robot.dat" - for example - gives errors and does nothing.

edit:
anyone compiled the source files already? any hint on compiler/makefile is welcome
is ssg the binary of the 3 *.c files?

[prowler]

Originally Posted by Crashdisk

Still not finished?

I have just bought a new, more powerful PSU for it. The one I had originally bought didn't have enough overhead to ensure no repeat of the problem which destroyed first one and then the other hard drive. That PSU was only 20W more powerful than the original. The new one I've bought is 170W more powerful, so things should start moving now.

Originally Posted by Crashdisk

There is no error on the original disk and the movie2 works without displaying a visual error. You were probably errors before transfer with Kryoflux...

The original and fixed disk images are identical for only about the first 25%, and then there are major binary differences.

If the original disk image is fine, then there is nothing more to do. However, if the original disk image is problematic in any way, then I would like to try and producre a fixed disk image with as few binary changes as possible for inclusion in TOSEC.

[dottyflowers]

Hi guys, sorry for the late reply, I've been busy last the weekend :-)

@mark_k : The original had checksum errors. It could very well be the KryoFlux dump was able to ignore/fix that. That is the normal ADF dump. To be sure I also did a dump (the repaired one) after I used DiskSalv to copy all files to my workstation and made another ADF of that disk (also using KryoFlux).

My original still gives errors on 3 machines, AmigaDOS nor X-Copy can't copy it. If you like I have a full streamcopy aswell.

[dottyflowers]

@Prowler: if you take the original ADF and copy the Movie2 file from the repaired disk you will have a disk that comes closest to the original. However, I did check the repaired ADF and all stuff works on that one..

[mark_k]

If you compare the files on the original and repaired ADFs using DirDiff, you should see that they are all byte-for-byte identical.

The repaired ADF will have many files in different locations on the disk (since you used DiskSalv to copy the files from the original to a blank disk). And as mentioned that broke all the file datestamps.

For whatever reason the original ADF seems to be fine. Maybe that's because Kryoflux reads several revolutions' worth of data from each track, and at least one revolution read correctly from the problem track(s). Or maybe the drive you use with Kryoflux has slightly better alignment or can handle weak signals better. So I'd suggest the repaired ADF be ignored for preservation/TOSEC purposes. It would be interesting to examing the stream copy though.

[prowler]

Originally Posted by dottyflowers

@Prowler: if you take the original ADF and copy the Movie2 file from the repaired disk you will have a disk that comes closest to the original. However, I did check the repaired ADF and all stuff works on that one..

When copying an AmigaDOS file from one disk (or disk image if you're using emulation) to another in these circumstances, there is no guarantee that the replacement file will overwrite the original file sector for sector. It is far more likely that the write process will fill unassigned blocks before overwriting the sectors used by the original file, and it looks like this is what happened when you 'repaired' the original disk image.

This is why there are so many binary differences betwen your original disk image and the repaired one. The only way to repair the original disk image properly is to paste replacement data sectors from the repaired disk image into the original image and then fix the headers.

It is annoying to have to do this to preserve the disk in a form which will be acceptable for inclusion in TOSEC. However, the default AmigaDOS sector assignment behaviour when copying files can be of tremendous help when recovering damaged sectors, because very often good replacement data can be found elsewhere on the disk in unassigned sectors.
Note: This is why I deplore "bamcopied" disks as mentioned in the TOSEC Amiga Correction Thread.

That's what I meant above when I said I would try to produce a properly fixed disk, but if your original KryoFlux disk image is actually a good one, then there will be no need for me to do so.

[dottyflowers]

Gents, mark_k is right. For some reason KryoFlux was able to copy the original in such a way all is well. What didn't work on the original physical disk, works on the ADF. No reason to use the repaired ADF.

I guess we're done :-)

[prowler]

Thanks for confirming that.

[Crashdisk]

The original disk will be preserved in TOSEC. Thank you!

[thellier]

Hello all

Just to say that I have recompiled the given rt1.c rt2.c rt3.c
It works :-) but only give a raytraced sphere...
So certainly building the whole "juggler demo" need some other stuff ( other sources ?)

Alain Thellier - Wazp3D

[emufan]

Originally Posted by dottyflowers

I guess we're done :-)

good news, thanks again

Originally Posted by thellier

Just to say that I have recompiled the given rt1.c rt2.c rt3.c
It works :-) but only give a raytraced sphere...

ah nice. can you explain what compiler you were using, any command-line?
and/(or) attach the executable please

So certainly building the whole "juggler demo" need some other stuff ( other sources ?)

Ernie Wright on his juggler-page, said the following about the missing scene-file:

I used to have the static geometry of the Juggler, probably from the Raytracing 1.0 disk mentioned here, but that was lost several computers ago. I don't think I ever had, or saw, what could be called the scene file describing the motion. I suspect it was never circulated publicly.

perhaps someone, another 20 years later, will come up with this file

edit: any success with the ssg command?

[thellier]

I will put the fixed sources + makefile + binary on Aminet
I used an old gcc but fixed (ad minima) the sources syntax to make it compile without any warnings

new: i have patched the source to use robot.dat scene so
now i can also render a (static) juggler :-)

Alain Thellier

[emufan]

cool, thanks

do you think ssg is made from those three rc source files?

[thellier]

No. I dont know what is/doing (really) ssg...
The build I maded just create&display a raytraced scene and dont print a text like ssg

Alain