Creating ADF's using sewing needles !!!

[Garyc2012]

Hey Prowler !!

"SPS guys " Who are the SPS guys ???

PS are you going to the Amimeet

http://eab.abime.net/showthread.php?p=809114#post809114

Would love to meet up for a bit of Amiga crack !!!!!!! (I left a message, I am more than happy to make a good contribution to the running costs...Im not mega rich nor am I looking attention, but I would be glad to make a generous contribution to the running costs and more importantly to the bar bill )_

I see the BBC event has just sold out (((

BBC was just as revolutionary as the Amiga, but with the benefit it was a British Design.

Never owned a beeb but respect to the guys who created it, and just look at ARM today !!!!! and then again part of that was down to Sir Clive Sinclair !!! (indirectly)

I still have a brand new Sinclair C5 with 0 miles on the clock, and get this the original "Telex" is in the "boot"

Gary

[clenched]

Originally Posted by Garyc2012

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

The middle connector on the ribbon cable has the corner pins numbered so it was a simple matter to count two pins over from 34 and insert the wire. I'm guessing that needles are for piercing insulation on cables without that connector. I can't think of anything else to try on the P75 and it still works like new.

[prowler]

Originally Posted by Garyc2012

Hey Prowler !!

"SPS guys " Who are the SPS guys ???

The SPS guys are the Software Preservation Society, and originators of the Kryoflux USB Floppy Controller.

You can recognize them on EAB by the SPS featured in their avatars.

Originally Posted by Garyc2012

PS are you going to the Amimeet

http://eab.abime.net/showthread.php?p=809114#post809114

I would like to, but I can't commit to it yet, as I may be otherwise occupied at that time.

If I find I am free to go, then, yes, I shall be there.


Edit:

Originally Posted by clenched

The middle connector on the ribbon cable has the corner pins numbered so it was a simple matter to count two pins over from 34 and insert the wire.

Quite so, and the output from the Print1 program demonstrated the accuracy of your wiring.

[mr.vince]

Originally Posted by prowler

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

Well you have been, too... it's the same tech as Disk2FDI. It's nothing new, and prone to errors, especially when reading raw data. When you know what to expect, e.g. ADF, you can read as long as the format validates and you have your data. When you don't know what to expect (raw, e.g. copy protection) you better get a good read.

Also parallel port adapters for USB are a hassle as they usually don't work reliably bi-directional. Every tried a X1541 cable with such an adapter?

That's why we never followed that path. It's one thing if you make this for your own and tweak an old school PC for this or change the software as needed. When you want give something usable of industrial quality you better iron out all setup issues, otherwise you drown in supporting this.

So this is not information withheld, it was around all the time, _we_ can't make use of it for preservation.

Happy hacking!

[prowler]

Well, this evening I have made an astonishing discovery while checking the three Compute Games disk images I made using ReadADF against one I made at the same time using Disk2FDI on the same equipment.

The second ReadADF image contains snippets of ASCII data (plain text, path and filenames, etc.) which should not have been found on the disk!

I can only imagine that this was from residual data which had been overwritten by what the disk contains now.

I this turns out to be the case (and I can ask Ze Emulatron if it's possible that the disk once contained such data), then I have achieved what I had thought was impossible without very expensive specialist equipment!

Originally Posted by mr.vince

Well you have been, too... it's the same tech as Disk2FDI.

You are quite wrong. I have never made a secret of the fact that I am a Registered user of Disk2FDI. It is only the program itself that is confidential.

[mr.vince]

I am very sure we've said on many occasions that we can't use/accept dumps made with Disk2FDI; until recently I've not been aware of the other program that actually seems to do the same.

As for your find... If your theory turns out to be true, the magic must have been with the drive. I would assume that the data you read now was written with a drive of the same alignment whereas the data you read the other day, was extracted with a drive of different alignment. I think you would get the same results with Disk2FDI, Discweasel, KryoFlux or whatever.

[prowler]

Originally Posted by mr.vince

I am very sure we've said on many occasions that we can't use/accept dumps made with Disk2FDI; until recently I've not been aware of the other program that actually seems to do the same.

We are obviously talking at cross-purposes here; I have never made any comment about the SPS position regarding Disk2FDI dumps, and my awareness of the ReadADF program began only with this thread.

Originally Posted by mr.vince

As for your find... If your theory turns out to be true, the magic must have been with the drive. I would assume that the data you read now was written with a drive of the same alignment whereas the data you read the other day, was extracted with a drive of different alignment. I think you would get the same results with Disk2FDI, Discweasel, KryoFlux or whatever.

I discovered the "hidden" data while comparing the performance of the Disk2FDI and ReadADF programs running on the same equipment using a disk known to have bad sectors of both the "missing sector header" and "bad sector checksum" type. Your theory that these data were originally written with a drive of the same (or very closely matching) alignment must surely be true, but the test showed that Disk2FDI did not pick them up and ReadADF detected them in only one of three runs.

I am still analysing these captures. When I know more I shall elaborate here.

[clenched]

This is what you're after.

   _?   _track #
  |    |
  |    |   ?   ?
 255  11   1  10                                                                
 TRUE                                                                          
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE  Good sector
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                  Track progress indicator
                                 |                          
################################################################################

##### - one # for each completed cylinder.

Here sectors 0 and 10 are bad but enough retries will correct it.

 255  13   1  10                                                                
FALSE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
FALSE                                                                           
 
##################################################################              
 
###### 

The PC is really struggling on this track. Only two sectors can be salvaged intact. The Amiga can read it no problem.

 255   5   1  10                                                                
 TRUE                                                                           
 TRUE                                                                           
FALSE                                                                           
FALSE                                                                           
FALSE                                                                           
FALSE                                                                           
FALSE                                                                           
FALSE                                                                           
FALSE                                                                           
FALSE                                                                           
FALSE                                                                           
 
###############                                                                 
 
##

[mr.vince]

Originally Posted by prowler

We are obviously talking at cross-purposes here; I have never made any comment about the SPS position regarding Disk2FDI dumps, and my awareness of the ReadADF program began only with this thread.

Ok, somewhere above it sounded like we'd known for years, but hidden its existence. I wanted to address that impression... Maybe I got it wrong.

Originally Posted by prowler

I discovered the "hidden" data while comparing the performance of the Disk2FDI and ReadADF programs running on the same equipment using a disk known to have bad sectors of both the "missing sector header" and "bad sector checksum" type. Your theory that these data were originally written with a drive of the same (or very closely matching) alignment must surely be true, but the test showed that Disk2FDI did not pick them up and ReadADF detected them in only one of three runs.

I am still analysing these captures. When I know more I shall elaborate here.

Please do. Would love to know how KryoFlux would read it...

[prowler]

Originally Posted by mr.vince

Ok, somewhere above it sounded like we'd known for years, but hidden its existence. I wanted to address that impression... Maybe I got it wrong.

I'm sorry. I must have given you that impression by posting this:

Originally Posted by prowler

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

...because that's how I interpreted what you had posted before:

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.

So, it was all just a misunderstanding, after all. Maybe we should switch to German for PMs.


Okay, back to the matter in hand:

Originally Posted by mr.vince

Please do.

I'm working on it...

Originally Posted by mr.vince

Would love to know how KryoFlux would read it...

Actually, I had thought perhaps KryoFlux was already programmed to do just that in the full (commercial) version of the software.

And it was only something I had read in an EAB or KryoFlux forum thread about it being possible to recover what had been written to a disk before it was overwritten which alerted me to the possibility that I had captured previously-written data from this disk. Without that, I would have been wondering whether the program had a bug and was mixing in data it had got from somewhere else. So, thanks for that!

[mr.vince]

Well, the board can't align the drive, so finding the right track in the first place is actually important...

[prowler]

Originally Posted by mr.vince

Well, the board can't align the drive, so finding the right track in the first place is actually important...

I'm surprised to hear you say that. I have found I can sometimes recover difficult sectors by introducing varying degrees of misalignment to a disk drive by rotating the drive motor. This trick works using Catweasel but not when I have tried it using KryoFlux. The initial calibration seems to cancel out the adjustment, and normal captures result.

[mr.vince]

Whatever it is, no device can change the drive's calibration unless such drive would have a mechanism for this (e.g. Piezo crystals like in video heads).

[clenched]

In the Zone readadf and print1 are recompiled from the EAB fileserver sources with Borland Turbo Pascal 7. They are complete and require no modification at all to compile.

[prowler]

Originally Posted by mr.vince

Whatever it is, no device can change the drive's calibration unless such drive would have a mechanism for this (e.g. Piezo crystals like in video heads).

You've lost me there, i'm afraid. Are you saying that it's impossible for KryoFlux to have corrected the drive's deliberate, physical misalignment simply by recalibrating or otherwise?

Originally Posted by clenched

In the Zone readadf and print1 are recompiled from the EAB fileserver sources with Borland Turbo Pascal 7. They are complete and require no modification at all to compile.

Thanks for the recompilation of these utilities, clenched! I'll try them out when I get time.

I've noticed that the included 'Decodstd.pas' routine writes German text to the screen (whereas the others write English text), and no option to R(E)calibrate is provided - only (A)bbrechen (Abort), (I)gnorieren (Ignore) and (W)iederholen (Retry), so presumably your version does the same. I am unable to differentiate between the (R)etry and R(E)calibrate options provided by the English version anyway.

I have added extra notation to your first screen output illustration where I have discovered the meanings of the numbers. If you would care to add them to your post above, then I can delete this here version.

 
  _Format identifier
  |    _Track #
  |    |   _Sector #
  |    |   |   _ Sectors to fill in the gap
  |    |   |   |
 255  11   1  10                                                                
 TRUE                                                                          
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE  Good sector
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                                                                           
 TRUE                  Track progress indicator
                                 |                          
################################################################################
##### - one # for each completed cylinder.

Note that 'Sector #' + 'Sectors to fill in the gap' = 11 for a standard track length.

[clenched]

Prowler - Thanks for filling in my chart. I was mystified by those three numbers but I did notice the sum of the last two = 11. Yes, the recalibrate is gone so what we're using is probably someone else's work. The only difference I have seen is the one in the Zone doesn't crash with runtime error in a Window's DOS box anymore. Moot since the program doesn't work there anyway. That may be how the myth got started about it not working on >266MHz PCs.

[prowler]

Earlier this evening, I tried out the recompiled versions in The Zone...

The Print1 utility works just the same as the first one, but the ReadADF program performs a little differently to the original on my machine, and has some good and bad features in comparison with it.

With the good disk I used before, the recompiled version is much slower than the original, and the image is prone to errors where there are none reported. It's not as bad as the original version was before I shortened and re-routed the parallel port cable, but bad enough for me to prefer using the original version with good disks.

With the bad disk, however, the new version showed no slow-down, and still the same errors were encountered, but now when you select the Retry (Wiederholen) option, the program will retry another 20 times before presenting you with all the options again, so it doesn't get stuck in an endless loop in the event of an unresolveable bad sector!

Also, I've noticed that sometimes, when the program encounters a very bad sector, the sum of "Sector #" and "Sectors to fill the gap" is no longer 11 (I witnessed examples of 13 and 20 with this disk). I didn't notice this when using the original program, but I wasn't sure what those numbers represented at that time.

I haven't checked the image I captured from the bad disk this time against those I captured previously with the original program but, if it is no worse, then I have to say I prefer using the recompiled version of the program when working with bad disks.

This judgement is, of course, based on having tried only one of each good and bad disks, and the outcome may have been entirely different had I chosen another pair of disks.

In conclusion, I would say that it's most probably an advantage to have both versions of the program available. Thankyou. Well done, clenched!

Incidentally, despite both Print1 programs asking for a DD disk to be inserted in the drive, it actually doesn't seem to matter whether a DD or HD disk is used for this test. Also, if the disk is PC-formatted, then the drive activity light can be extinguished when the program has finished by entering dir a: at the DOS-prompt, thus obviating the need to reboot the machine.

[clenched]

I think what you're seeing is actually two single-digit numbers overlapping because of some misalignment. I could catch brief glances on both program along the lines of 82 39 where the the two lefts and two rights would total eleven. The numbers change so fast on my PC don't hold me to it though.

[prowler]

Yes, that's certainly possible when the top line of the display is continually being updated, though I've not seen it happen often enough to have spotted the significance of adding the left and right columns.

However, I've also seen some large numbers like that accompanied by the track number temporarily changing to a much higher or lower number following a number of unsuccessful retries, as if the program has decided it's time to attempt realignment of the drive heads with the track by reapproaching it from a sufficient distance, and most times this appears to be successful.

The figures I quoted above were the result of much smaller numbers (8 5 and 13 8, IIRC) with no change in the track number.

I'll be watching those figures more closely next time.

Also, when using the recompiled version, I noticed once or twice that I was presented with the Abort, Ignore, Retry options when all sectors were showing TRUE! And, of course, upon selecting Retry, the program immediately stepped to the next track.

[clenched]

Originally Posted by Garyc2012

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.

It could also be that the line is partially written when screen is scanning near the bottom but not quite complete before the top line is drawn. The video memory would only have been partially refreshed then. The video buffer would have bits of the new and previous screen.

EDIT: It's too bad that Gary, the guy who needs this thing, is having the most trouble with it.