ADF to Disk doesn't work correctly
 

Hi.

I have the followimng problem: I have an amiga 1200 (commodore). I'm trying to write an adf file back to disk.. i tried adf2disk, adf blitzer, tsgui - always with the same result:
the write process seems to run till 100% without an error. but everytime the disk shows DF0:NDOS, even the source-adf is a dos-image.

but why this happen? i tried 3 different floppy drives (Chinon FB-354, FZ-354 and a modded Teac FD235HF-6291) and over 30 disks.

can anybody help me?

regards

i've used adf blitzer without troubles. are you sure the source images are indeed good? you are using good DS/DD floppy disks right? assuming all is well on the above questions,it would seem to be hardware level. AT motherboard maybe with floppy fixes? bad floppy drive cable?
try an external drive if you have one and see if it works.

mike

disk image .adf you are try to put to floppy is

Try tracktool from Codetapper. Best ADF writer out there :)

When and how did you check that the source ADF is a DOS disk?

If you checked it on a PC with WinUAE, it can still become corrupted during the transfer to the Amiga. Then changing the program or the disk does not help, you need to correct the transfer.

Yes, I tried in WinUAE... there all Operation works perfect. .,,.I copied the File on my CF-Card in WinUAE. Then I inserted the CF-Card back in my IDE-CF Adapter.
I tried this with different ADF-Files. It is always the same Result..

Which disk are you trying to transfer back?

that was my question, perhaps you use better words than me fol

Workbench 3.1 Install Disk and Ramses (Game)

What disks, you using?

Can you format them ok?

lol.

Workbench Install Disk ist named install_3.1.adf and has a crc32 37CD1DDE

Ramses i don'nt know.. i deleted the diskimage already..

but under winuae i can copy the adf to a "new disk" perfectly..

CodeTapper's TrackTool is not the best ADF writer to use in this case, as it does not check the destination disk for write errors. This can be a very useful feature in some circumstances, but not on this occasion. ;)

That CRC32 doesn't look right to me, but it shouldn't prevent the image being written back to floppy disk correctly, of course.

Sounds like the usual mistake everybody makes: MaxTransfer is set too high.

In TSGUI select "read block by block, not cylinders" from the "advanced options" menu. (If you don't have advanced options, get the latest version of TSGUI from here.)

If this works better, run HDToolbox, partition drive, enable Advanced Options, select the first partition, click on Change... and click into the MaxTranfer field, delete everything and enter 0x1fe00, then press enter (don't forget to press enter, otherwise the new value will not be used). Click ok and do the same with all the other partitions, too. Then return to the main menu and click on Save Changes To Disk. Finally reboot and try again. Maybe you need to copy the big files to the CF card again in WinUAE before it works.

hm, thats sound interesting, thomas... i can try this on monday and then i will report my results here...

writing to disk with the "read block by block, not cylinders" and setting the maxtransfer-rate to 0x1fe00 didn't help: it doesn't work.

BUT:

I copied the adfs to a fat-formatted cf-card and used it in the pcmcia slot...

when i write the adf from the pcmcia-cf to floppy, IT WORKS!

but why i doesn't work from ide-cf?

No idea. Copy the ADF from IDE-CF to RAM and from RAM to disk. Does it make a difference?

Copy the ADF from IDE-CF to PCMCIA-CF, then attach both, the original and the copied one here for comparison.

i think it is a problem with the data transfer between winaue and windows... when i copy the adf from pcmcia-cf to ide-cf i can write the adf successfully to floppy disk. when i copy the adf from windows to ide-cf (with winuae) it doesn't work..

Please attach the working and the non-working ADF for comparison. Or compare them yourself.

Which programs do you use for copying?