AExplorer/Transdisk ALWAYS fail at track 40

Hey hackers, please help me. Using Amiga Explorer to transfer ADFs to my PC always results in a Guru Meditation with the progress bar at 50%. Transferring single small files works fine. The last parts of the Amiga Explorer log is to be found below.

The error occurs when using Transdisk as well. Transdisk tracks 0-39 works fine, as well as tracks 41-79, but NOT TRACK 40. I've tried different disks and different diskdrives, the error always occurs when trying track 40. I get a 'Software error - task held Finish ALL disk activity Select CANCEL to reset/debug' (followed by a Guru Meditation)

I've spent some weeks trying. Now I hope for some useful help.



Read Packet 5
< [512 bytes]
< 00 06 C0 64 46 82 76 00 4A B0 18 08 67 02 46 83 84 83 23 42
< ...
< 20 3C 00 00 00 F0 28 6A 01 24 4E 95 20 3C 00 00 00 E8 28 6A
< [4 bytes]
< 51 E5 D8 A1
> [4 bytes]
> 50 6B 4F 6B
Write Packet 0
> [12 bytes]
> 00 00 00 00 00 00 03 6F 93 02 F0 63
< [4 bytes]
< 50 6B 4F 6B
< [12 bytes]
< 00 05 02 00 00 00 03 74 06 97 B7 23
Read Packet 5
< [512 bytes]
< 00 06 C2 60 01 10 4E 95 72 01 D2 A9 00 C8 60 00 FE B0 4E D6
< ...
< 49 EC FF 78 4E 95 22 81 24 01 E5 8A 21 AA 02 6C 28 00 25 51
< [4 bytes]
< DD C0 C4 42
> [4 bytes]
> 50 6B 4F 6B
Write Packet 0
> [12 bytes]
> 00 00 00 00 00 00 03 70 1E 0A FD 96
< [4 bytes]
< 50 6B 4F 6B
< [12 bytes]
< 00 05 02 00 00 00 03 75 71 90 87 B5
Read Packet 5
< [512 bytes]
< 00 06 C4 5C 02 6C 4E D6 24 2A 02 70 B4 AA 02 A0 67 00 00 06
< ...
< 22 11 70 20 49 EC 01 5C 4E 95 22 2A 02 A0 70 20 28 6A 02 74
< [4 bytes]
< 2E E9 98 AC
> [4 bytes]
> 50 6B 4F 6B
Write Packet 0
> [12 bytes]
> 00 00 00 00 00 00 03 71 69 0D CD 00
< [4 bytes]
< 50 6B 4F 6B
< [12 bytes]
< 00 05 02 00 00 00 03 76 E8 99 D6 0F
Read Packet 5
< [512 bytes]
< 00 06 C6 58 4E 95 53 AA 02 70 22 2A 02 70 B2 AA 02 C8 6C 00
< ...
< 0C 81 00 00 06 40 6C 00 00 1C 47 EC 01 38 22 0B E4 89 70 30
< [4 bytes]
< BE 22 C0 7F
> [4 bytes]
> 50 6B 4F 6B
Write Packet 0
> [12 bytes]
> 00 00 00 00 00 00 03 72 F0 04 9C BA
< [4 bytes]
< 50 6B 4F 6B
< [0 bytes]
COM READ ERROR: 12 bytes expected (code 0, timeout 5000)
< [0 bytes]
COM READ ERROR: 12 bytes expected (code 0, timeout 5000)
Write Packet 109
> [0 bytes]
COM WRITE ERROR: 12 bytes should have been written (code 0, timeout 5000)

[Marcuz]

hello and welcome,
the first thing that comes to mind is that track 40 is the one that stores the [edited] ROOT block [/edited] of the disk, so it may be a problem of non standard bootblock or non-dos disk: it may be that you will not be able to transfer the disk with those programs, if this is the case.
you should resort either to disk2adf or the SPS tools (you have to ask them on their site.

some more experienced amiga delver may help you more

also: read here:
http://wiki.abime.net/amiga:file_transfer
for more tools

Thanks. I've tried some ten to twenty disks, most of them Workbench disks. They should be OK, shouldn't they? Could you please describe your suggestion more in detail? Are they better programs than the ones I've already tried (Amiga Explorer and Transdisk)?

[Galahad/FLT]

Track 40 does not store the bootblock data.

Track 40 stores the ROOT block data (i.e. the disk name, filenames, size of files on disk, where on the disk they are, date files were created, etc).

You sure its not simply a memory problem? Instead of trying to read a disk in two passes, try three.

[Marcuz]

thanks for correcting me, it's years since i last used copy stuff and i written a load of crap.

if the disks are standard dos as they appear, it's probably a memory fault or disk drive maybe?
a quick way to check is to trandsisk shorter pieces of the disk: 0-30 31-50 51-79 for instance, move them on pc and join them

Thankyou for your ideas. However, It's not a memory issue. I even tried to make a file with only ONE track (track 40). It doesn't work either. I've borrowed an additional diskdrive and get the same result every time. No matter what disk or what diskdrive (df0 or df1) I use.

I'm about to lose hope...

[Marcuz]

what i find strange is that if there were some hardware problem, probably you would also be unable to use the disks normally, due to some fault in reading the root block. i'm at loss here

[thomas]

Originally Posted by erik_l

No matter what disk or what diskdrive (df0 or df1) I use.

This suggests that it is a software problem. Perhaps your computer is infected by a virus which prevents programs other than dos.library from reading the root track.

Carefully ensure that you don't insert any disk without the write protection active. Each write-enabled disk will become infected, too.

Then do the following: boot from your Workbench disk (write protected !!), insert an empty disk (write enabled) and format it. If it doesn't fail to format track 40, try to read it with transdisk. Do not send the transdisk data over the serial bus, but keep it locally (e.g. in RAM: or throw it away to NIL: ).

When the program fails, how does the failure show up ? Is there any error message ? For example error code 21 is quite common for magnetical damages on floppy disks.

thomas: thanks, I'll try that when I bring my Amiga out of the closet the next time. I'll post the result here.

Ok, track 40 still fails. I get the standard error message
"Software error - task held Finish all disk activity Select CANCEL to reset/debug" followed by a Guru meditation.

Any new or old ideas? Every other track works fine.

[thomas]

Any new or old ideas?

You should tell something about the other suggestions. Did you make a virus test ? Did you try to format a disk ?

I get the standard error message
"Software error - task held Finish all disk activity Select CANCEL to reset/debug" followed by a Guru meditation.

What are the numbers in the guru meditation ?

Actually this is not a "standard error message". This is a crash. An error message (caused by a bad disk for example) would be "error 21" or something like that.

The crash is most probably caused by either another program which randomly pokes around in memory (i.e. a virus) or by a bad RAM chip.

You cannot deny bad RAM just because the computer otherwise works correctly. A bad bit somewhere in memory can cause the strangest behaviour.