Creating ADF's using sewing needles !!!

[Supamax]

Originally Posted by prowler

I did try the TP7P5Fix program anyway. It installed okay, but had no discernable effect.

Wait! What's 'TP7P5Fix' for?
I never used it.
Thinking about the past, perhaps I used a 400 MHz AMD K6... I'm not sure.

Is the original picture/scheme still viewable on the site/WayBack Machine?
It was a .gif, I think, showing where to make the connections etc.

I may be able to improve things by shortening the parallel port cable and trying the command line switches. We'll see...

I wonder... why bother? You have both the Catweasel and KryoFlux, so you're light years ahead of ReadADF...

EDIT: The cable I used was a single-wire (not shielded), and its length was around 50 cm...

[prowler]

Originally Posted by Supamax

Wait! What's 'TP7P5Fix' for?
I never used it.
Thinking about the past, perhaps I used a 400 MHz AMD K6... I'm not sure.

TP7P5Fix.com is a TSR (Terminate and Stay Resident) patch for running ReadADF on PCs with processors faster than 266MHz. I've attached it below.

Originally Posted by Supamax

Is the original picture/scheme still viewable on the site/WayBack Machine?
It was a .gif, I think, showing where to make the connections etc.

Cable schematic is attached below.

Originally Posted by Supamax

I wonder... why bother? You have both the Catweasel and KryoFlux, so you're light years ahead of ReadADF...

This program has enough interesting features (retries, etc.) to justify trying to make it run smoothly, plus it's not closed source like the others you mention.

Originally Posted by Supamax

EDIT: The cable I used was a single-wire (not shielded), and its length was around 50 cm...

Yep, that's what's recommended. My cable is shorter than that but, because it was designed for the Disk2FDI program, it has two wires and it's a twisted pair (but I can't remember whether twisting them was recommended or not). Now I'm wondering whether screening it might help prevent interference and thus improve the speed and performance of the ReadADF program.

[mr.vince]

Originally Posted by prowler

Like yourself, I imagine, I'm interested in evaluating any program and/or hardware which might help recover data from troublesome media.

Yes, but I really can't see why this would perform better than any of the alternatives mentioned. You have a lot of loose ends there, especially all the stuff (interrupts) going on in the background that will mangle your timings.

This will give you some ADFs for disks that are fine, but the jitter and other stuff induced will for sure not help when trying to recover things.

[prowler]

Well, I have finally got ReadADF working properly on my Disk2FDI machine by running the parallel port cable internally from the motherboard header, having first removed the ribbon cable to the external parallel D-type socket (which I never use on this machine anyway).

It is still an unshielded twisted pair of wires which will serve as both a Disk2FDI and ReadADF parallel port cable. It connects Pins 10 (ACKNOWLEDGE) and 13 (SELECT) of the parallel port motherboard header with Pins 30 (READ DATA) and 8 (INDEX) of the spare 3½-inch floppy drive cable connector, respectively. I made a neat job of it by using an old PC-speaker lead to span Pins 10-13 of the parallel port header and soldered a square header pin to the other end of each of the two wires to insert into the floppy drive connector.

Now, when I run the ReadADF program using the default settings and a good disk, the speed is MUCH improved (approximately half the speed of Disk2FDI) and the resulting disk image exactly matches the one produced by Disk2FDI!

Unfortunately, there are inconsistencies between the command line switches that the program will accept and the help screen:

D:\D2F>readadf
readadf <filename> -p n -i n -s n -d n
<filename> Name of the file to write
-p n       n=LPT Port to use (default LPT1)
-i n       n=IRQ to use (default 7)
-e         Reads copyprotected Disks (slow)
-m s:m1:m2 Manualmode:
         s: the shift depending on the cpu speed (0=90/100,1=133/166,2=200/233 Mhz)
         m1,m2: readmark 1,2 depending on the disk/cpu/board ....
-t         Testmode:generates some stupid pics
         and saves them to disk. Send this files (PIC*.DAT)
         as e-mail to ChristianK.@t-online.de if
         readadf does not work.
for example readadf disk.adf -p 2 -i 5
 
D:\D2F>

The sample command line: "readadf <filename> -p n -i n -s n -d n" contains no copyprotected mode (-e), manual mode (-m) or test mode (-t) switches, but the -s and -d switches it does contain are undocumented.

Before I replaced the cable, I did try to use the manual mode switch consistent with a 166MHz processor, (-m 1:1:1 by my reckoning), to see if this would improve the dismal speed I was witnessing yesterday. However, the only display the program would generate in this case was an occasional "Read error (A)bort (I)gnore (R)etry R(E)calibrate" at the bottom of the screen, following an unsuccessful default number of retries, until I aborted the process. (I now know that this behaviour is consistent with failure to read entire tracks!)

I don't think I have any copy-protected disks, so I haven't tried that mode, I can't imagine what the -s and -d switches are for and test mode is academic unless the program is still supported.

However, I have got the program running as it was surely meant to, so I now have an additional application in my floppy recovery toolbox!

I ran both the Disk2FDI and ReadADF programs on Ze Emulatron's original Compute Games disk, which has 21 bad sectors - 13 of them with a missing header. Disk2FDI will always fill "missing sector header" blocks in the image with zeroes and sometimes "bad sector checksum" blocks too, but ReadADF always captures something. Most times this is nothing useful, but occasionally there will be something more meaningful, and whole sectors can sometimes be rebuilt from information like this gathered over a sufficient number of runs and a bit of guesswork based on inspection of the rest of the disk image.

Using good disks, I can't distinguish between the Retry and Recalibrate choices following notification of a read error; there may be differences in the processes involved, but the result is the same: both will persist until the whole track is captured.

With bad disks, however, both these options can result in an endless loop if a truly unreadable sector is encountered, so it's best to stick with the Ignore option. A read error notification will follow 20 unsuccessful retries, which is a fair number (Disk2FDI uses only 10 retries, IIRC).

ReadADF is not such a bad utility after all!

Originally Posted by mr.vince

This will give you some ADFs for disks that are fine, but the jitter and other stuff induced will for sure not help when trying to recover things.

O ye of little faith!

[Supamax]

Originally Posted by clenched

On the EAB fileserver /Commodore_Amiga/App/Archive/readadf_cc/ folder this software and some source code can be found

Is there really some source code of readADF?

The sample command line: "readadf <filename> -p n -i n -s n -d n" contains no copyprotected mode (-e), manual mode (-m) or test mode (-t) switches, but the -s and -d switches it does contain are undocumented.

If some source code is available, you could perhaps analyse it hoping to find something about those undocumented parameters... ?

[prowler]

Originally Posted by Supamax

Is there really some source code of readADF?

Yep, I've attached it below.

Originally Posted by Supamax

If some source code is available, you could perhaps analyse it hoping to find something about those undocumented parameters... ?

Good idea! (Why didn't I think of that? )

I'll have a look tomorrow to see if they're mentioned.

[Supamax]

I don't think I have any copy-protected disks, so I haven't tried that mode, I can't imagine what the -s and -d switches are for and test mode is academic unless the program is still supported.

I tested it, many years ago, with my original disks of Dragon's Lair and Dungeon Master. I couldn't get a "working" (in WinUAE) .adf, though.
If I remember correctly, the resulting .adf file had the ordinary size, not more (the "extended adf format" didn't exist yet), so I suspect that the copy of protected disks was equal to "skipping bad sectors" without the need to ask the user what to do.

[prowler]

Originally Posted by Supamax

I suspect that the copy of protected disks was equal to "skipping bad sectors" without the need to ask the user what to do.

Hmm... There might be some clue about that in the source code as well, if we're lucky.

If the program were to encounter a long track (as opposed to a sector with weak bits, for example), then recognized and subsequently decoded it correctly, then it should be indicated by an increase in the number of sectors displayed for that track, presumably.

I think you would have noticed that, so you're probably correct and it doesn't work properly.

[clenched]

Prowler's success has motivated me to try the AMD anyway. First the CPU is AMD-K6-2 450 MHz rather than 400. The floppy brand is unknown. I was astounded that the very first disk imaged perfectly. That is without, repeat without running the patch. I imaged 3 of 5 Distant Suns disks, WB1.3 Extras disk, KindWords super font disks [all originals]. 2 of 5 Distant Suns disks and WB1.3 failed to image. The WB disk seemed to have drag on it like it was running on sandpaper and also the read error requester had to be clicked several times when I booted it on the A500. Without exception all the disks I imaged that didn't report read errors, the CRCs matched exactly with ADF backups I made back in 1998.

EDIT: Rough timing test. C.A.P.E. assembler disk as test subject.
transdisk to RAM: on A500 - 43sec
readadf to PC harddrive on AMD - 1min 45sec

[mr.vince]

Originally Posted by prowler

ReadADF is not such a bad utility after all!

Absolutely. I am shocked it spits out more than Disk2FDI which means Disk2FDI is worse. That's really a shame, because it's sold as a serious ingestion app with preservation background.

I'd really like to find out more because I know some people working with it and it would only be fair to let them know. Maybe we can PM about the images you created.

Originally Posted by prowler

O ye of little faith!

Well, the ADF itself is limiting you here when it comes to raw data that does not resolve. Anyway, I never said it would not work; would be nice to compare it to something modern, e.g. KryoFlux.

Well done!

[Supamax]

Originally Posted by clenched

PWithout exception all the disks I imaged that didn't report read errors, the CRCs matched exactly with ADF backups I made back in 1998.

Even if I'm risking to appear very boring, I always recommend to make at least two dumps of each floppy and then compare them with a binary converter such as UltraCompare . I always do so.
It's the only way to be practically 100% sure the dump is correct.

[clenched]

I would have preferred a byte compare but the Win95 installation has no USB support for memory stick to move the file to my main PC. However WindowsME does so I am going to adjust the partitions so ME and W95 will both be available. If I had a clue this thing would actually work, I would have done it beforehand.

[Supamax]

Originally Posted by clenched

I would have preferred a byte compare but the Win95 installation has no USB support for memory stick to move the file to my main PC. However WindowsME does so I am going to adjust the partitions so ME and W95 will both be available. If I had a clue this thing would actually work, I would have done it beforehand.

No problem, my advise was general .
A temporary solution could be this one: you could (always) make 2 or 3 dumps and store them all. Then, when you'll be able to compare them, you'll do.
But in the meantime you have dumped (and safely stored) multiple copies of a floppy which you don't know if will be readable in the future.
It's always better than making a single dump (which you are not sure it's 100% ok until you can compare to something), in my opinion.

[prowler]

Originally Posted by mr.vince

I am shocked it spits out more than Disk2FDI which means Disk2FDI is worse. That's really a shame, because it's sold as a serious ingestion app with preservation background.

I am not inclined to agree with you that my findings necessarily indicate that Disk2FDI is the worse of these two utilities. A lot depends on the experience of the user.

I have found that if Disk2FDI fills a whole block of a dumped image with zeroes (most likely when a "missing sector header" is encountered), then that's a sure sign you'll not recover any meaningful data from that sector using that particular combination of disk drive and controller, whereas ReadADF would, I guess, have filled that block with randomly-generated data based solely on the noise picked up by the parallel port cable to which the program is so susceptible in the absence of anything else. In this case, the data "captured" by ReadADF can be dismissed.

However, let's now consider a less clear-cut case which occurred yesterday evening where Disk2FDI had captured some corrupted data from a sector with a checksum error and ReadADF captured more meaningful data using the same hardware (though I haven't yet fully analysed the implications of this particular example).

I have previously seen wholesale corruption of the data partway through a block in a dumped image triggered by a bad bit which was the singular cause of a persistent checksum error in that block on the disk! In this case, I was eventually able to capture more meaningful data from that disk block using KryoFlyux and another disk drive which hasn't since then repeated the same trick on another disk.

If yesterday's case turns out to be similar, then I guess that the susceptibility of the ReadADF program to the noise picked up by the parallel port cable somehow produced a cancelling, or at least dampening, effect on whatever perpetuated the corruption in the original image (though I have no knowledge of what feature KryoFlux might have which gives it this knack).

I should mention that even when this trick succeeds, it can take very many captures, a large number of which may fail, before the whole sector can be reconstructed.

Originally Posted by mr.vince

Well, the ADF itself is limiting you here when it comes to raw data that does not resolve.

I do not consider that to be an insurmountable handicap.

Originally Posted by mr.vince

Anyway, I never said it would not work; would be nice to compare it to something modern, e.g. KryoFlux.

In the short time that I have been using ReadADF, I have already found reasons which I have mentioned in this thread for comparing it to both Catweasel and KryoFlux.

Originally Posted by mr.vince

I'd really like to find out more because I know some people working with it and it would only be fair to let them know. Maybe we can PM about the images you created.

First, I need to find out more myself. Data recovery can be something of a black art. Breakthroughs don't happen very often, and when they do it can sometimes take weeks before the implications can be understood and the technique fully exploited.

Originally Posted by mr.vince

Well done!

Thanks. I appreciate that.

[prowler]

Originally Posted by Supamax

If some source code is available, you could perhaps analyse it hoping to find something about those undocumented parameters... ?

I've now studied the (uncommented! ) source code; Readadf.pas in particular.

This version of the program is dated 25-08-1998. The -p, -i, -e, -m and -t command line switches appear to function as documented in the help screen, but the mysterious -s and -d switches are not parsed by the program.

I would guess that the -s and -d command line switches were a feature of the earlier version of the program. Does anyone have the earlier version?

The copyprotected mode (-e) switch activates an "extended decoding and writing" mode instead of the standard one (featured in Decodext.pas and Decodstd.pas, respectvely), but I am still none the wiser about the manual mode (-m) switch.

[Garyc2012]

Originally Posted by prowler

TP7P5Fix.com is a TSR (Terminate and Stay Resident) patch for running ReadADF on PCs with processors faster than 266MHz. I've attached it below.

Hi Prowler

I tried that TSR fix as well (and others), no joy, tbh the problem is I think the way it slows the CPU down, It prob grabs the cpu for a whole bunch of continuous cycles.

Also tried a borland patch that "fixed" the runtime error 200 on >266Mhz machines (Modern CPUS were so fast they caused a divide by zero error), it didn't work. All the old software (Amiga Included) made alot of use of CPU cycles for timing purposes.....not good :/

I then managed to find the source code (Pascal). The *core* of the program is 20 or so lines of assembler code. Thats why it has to run in Real DOS mode, and why TSR's would play havoc with it.

The other thing was the code wrote DIRECTLY to memory addresses as well as the video address if I remember rightly and thats another reason this will never work in a dos shell etc, it needed Real mode or linux with all other interrupts halted.

What I think would be great would be if a *Live* Linux CD could be created. Would be interesting to see what is the latest kernel it would support (Give SATA/USB support etc).

Cheap £5 parallel ports can be bought on ebay with proper UART chips.

I also tried the guys suggestion above, I used a bit of copper cat5 cable and it worked *better* than the needles removed the FDD cable and slipped one end (stripped 1cm) into the plastic connector, and I "wrapped" the other end around a needle to create a "pigs tail" curly bit of wire, straightened it a BIT and it fitted real snug into the parallel port.

Will get another look this weekend. But *really* need to get the Linux source code!

Gary

[Garyc2012]

Originally Posted by clenched

Total failure on my 75MHz Pentium PC. Drive is a Sony MPF 520-1. I didn't need the needles. A piece of solid bell wire held snug in the connectors. Tried original KindWords disk, Workbench disks etc. all resulted in the drive lighting up stepping a bit then nothing. Created files of 0 byte size. If I used the -e option then it prints a row of changing numbers at the top for a while longer but eventually quits too. Ran prog in real mode DOS and Win95 in a box. Tried all permutations of EPP,ECP,bi-directional etc in BIOS. I'll leave it hooked up a while in case anybody has a breakthrough.

EDIT:The print1 utility on that page reports:

insert dd disk and press enter

(connected)
Bits transfered! wiring ok!
interrupt generated! lpt-port ok!

(disconnected)
No bits transfered! check wiring
No interrupt generated! check lpt-port

The minimum manual setting on the readadf prog shows a 90/100 so maybe this PC is too slow.

Hi !!!

I think my PC about 11/12 years ago was that spec

Did you observe the "stripe" on the FDD connector - indicating pin 1 ?

Gary

[Garyc2012]

Originally Posted by Boo Boo

Interesting and detailed review Thanks
Its a dirty hack and I like it

In theory controlling the drive like this and the other methods avalible could it possible to also write

Abso----freaking---lutely what I was thinking

I have a couple of other thoughts, FDD with flashable BIOS, Use alternative port for reading eg COM (my quad core AMD has still serial port but not sure what max baud rate is)...and er....im sure I will come up with more ...mabe not ;p

Gary

[Garyc2012]

Gary HUGS prowler !!!!!!

Well done my son

"Most times this is nothing useful, but occasionally there will be something more meaningful, and whole sectors can sometimes be rebuilt from information like this gathered over a sufficient number of runs and a bit of guesswork based on inspection of the rest of the disk image. "

How true !!!!!!!!! I don't actually remember it being that slow, but remember I had just came off An Amiga A500 without a HDD

just read the authors theory again.....Bain Marie !!! as Del Boy would say

"My idea for reading Amiga disks (theoretically, this method could also apply to C64 disks) is based on the data that was read being passed to the printer port, past the floppy controller (i. e. not touching it), giving way for the CPU to fetch it and decode it "by hand".

He is capturing the Raw Data coming from the FDD....valid or not, and then using a mask to rebuild it ????


Gary

[prowler]

Hi Gary,

I wondered where you had gone for the last week, but now it seems like you're making up for lost time!

Thanks for alerting us to this interesting alternative Amiga disk imaging solution for the PC!

(It seems that the SPS guys have been aware of this one for quite some time, but were keeping quiet about it. )

Edit:

Originally Posted by Garyc2012

He is capturing the Raw Data coming from the FDD....valid or not, and then using a mask to rebuild it ????

That's probably the most interesting feature from the SPS perspective.