21 March 2012, 00:59 | #21 | ||
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
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. Quote:
EDIT: The cable I used was a single-wire (not shielded), and its length was around 50 cm... |
||
21 March 2012, 01:17 | #22 | |||
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
Quote:
Quote:
Quote:
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. Last edited by prowler; 21 March 2012 at 01:24. |
|||
21 March 2012, 12:52 | #23 | |
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
Quote:
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. |
|
22 March 2012, 00:19 | #24 |
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
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: Code:
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> 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! O ye of little faith! Last edited by prowler; 22 March 2012 at 00:53. Reason: Added details of the parallel port cable construction. |
22 March 2012, 00:27 | #25 | ||
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
Quote:
Last edited by Supamax; 22 March 2012 at 01:02. |
||
22 March 2012, 00:36 | #26 | |
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
Yep, I've attached it below.
Quote:
I'll have a look tomorrow to see if they're mentioned. |
|
22 March 2012, 01:02 | #27 | |
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
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. |
|
22 March 2012, 01:23 | #28 | |
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
Quote:
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. |
|
22 March 2012, 06:25 | #29 |
Registered User
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 771
|
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 Last edited by clenched; 22 March 2012 at 10:56. Reason: add ballpark time estimate |
22 March 2012, 11:30 | #30 |
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
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. 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! |
22 March 2012, 15:38 | #31 | |
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
It's the only way to be practically 100% sure the dump is correct. |
|
22 March 2012, 17:14 | #32 |
Registered User
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 771
|
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.
|
22 March 2012, 18:51 | #33 | |
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
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. |
|
23 March 2012, 00:40 | #34 | ||||
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
Quote:
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. Quote:
Quote:
Quote:
Thanks. I appreciate that. Last edited by prowler; 23 March 2012 at 00:56. |
||||
23 March 2012, 03:07 | #35 | ||
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
Quote:
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. |
||
23 March 2012, 22:06 | #36 | |
Registered User
Join Date: Mar 2012
Location: Belfast,UK
Posts: 10
|
Hey Guys
Quote:
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 Last edited by Garyc2012; 23 March 2012 at 23:15. Reason: Fixed quote. |
|
23 March 2012, 22:21 | #37 | |
Registered User
Join Date: Mar 2012
Location: Belfast,UK
Posts: 10
|
Quote:
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 |
|
23 March 2012, 22:28 | #38 | |
Registered User
Join Date: Mar 2012
Location: Belfast,UK
Posts: 10
|
Quote:
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 |
|
23 March 2012, 22:37 | #39 |
Registered User
Join Date: Mar 2012
Location: Belfast,UK
Posts: 10
|
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 Last edited by Garyc2012; 23 March 2012 at 22:55. |
23 March 2012, 22:53 | #40 |
Global Moderator
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
|
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:That's probably the most interesting feature from the SPS perspective. Last edited by prowler; 23 March 2012 at 23:02. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Creating Macros | Lonewolf10 | Coders. Tutorials | 3 | 18 June 2013 22:12 |
Creating ADF images | Dreedo | support.Other | 16 | 06 December 2010 17:49 |
Creating ADF in WinUAE | JayParker | support.WinUAE | 1 | 07 October 2006 13:18 |
Creating Adf | Retro1234 | support.Other | 0 | 17 July 2006 16:25 |
|
|