Creating ADF's using sewing needles !!!

[prowler]

Originally Posted by clenched

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.

Hmm... Perhaps we're reading too much into these erroneous numbers. I must admit I was surprised whenever I saw the track numbers changing, because I never heard the drive heads stepping.

Originally Posted by clenched

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

[clenched]

Prowler - You are right after all. I changed the program to stop after one of those sector variables went out of bounds and it did. If I'm reading these sources right, it looks like the header data are only tested for accuracy after the numbers have already been printed. Here is one I had turn up: 255 69 82 93. The simplest way to fix it would be to put the check ahead of the line print. From my observations the program won't continue until the numbers return to normal and the sector is either read correctly or aborted.

[prowler]

Originally Posted by clenched

Prowler - You are right after all. I changed the program to stop after one of those sector variables went out of bounds and it did. If I'm reading these sources right, it looks like the header data are only tested for accuracy after the numbers have already been printed. Here is one I had turn up: 255 69 82 93.

Great work, clenched! (How do those sector variables ever get out of bounds in the first place, I wonder? )

Well, now you're (once again! ) in debugging mood (and everything's up for tweaking now you've got the sources to compile), it has occurred to me that something similar is going on here:

Originally Posted by prowler

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.

It looks like the sector status flags are checked only after they have already been displayed (and the track progress also, because the indicator had actually reached full scale when the options showed up again in each case, IIRC ).

Originally Posted by clenched

The simplest way to fix it would be to put the check ahead of the line print. From my observations the program won't continue until the numbers return to normal and the sector is either read correctly or aborted.

Please do give it a try. I'll check the result of running any test version you can compile on my machine and, in the meantime I'll be looking at the source code in new light.

PS. I've just found I have a Reference Manual for the Microsoft Pascal Compiler (MS-DOS; not sure what version). I wonder if I have the disk(s) for it somewhere?

Edit: Yes, I've found the User's Manual and 5¼-inch two-disk set to go with it!

Hmm... I've also found a 3½-inch disk for Microsoft Pascal Version 3.31 (Disks 1 & 2). This disk is HP150 D/S MS-DOS formatted, but I'm not sure it's part of the same set. I guess I'll find out soon enough.

[clenched]

I really hate to let loose of anything changed without the results being compared to those of an Amiga. I fished around on Aminet a bit to see if there are any existing programs that might display this header info but came up empty. There are any number of trackloaders that might be adapted but the ones I looked at only decode the data portion and not the header which is what is needed here.

[prowler]

Originally Posted by prowler

PS. I've just found I have a Reference Manual for the Microsoft Pascal Compiler (MS-DOS; not sure what version). I wonder if I have the disk(s) for it somewhere?

Edit: Yes, I've found the User's Manual and 5¼-inch two-disk set to go with it!

Hmm... I've also found a 3½-inch disk for Microsoft Pascal Version 3.31 (Disks 1 & 2). This disk is HP150 D/S MS-DOS formatted, but I'm not sure it's part of the same set. I guess I'll find out soon enough.

All three of my Microsoft Pascal Compiler v3.31 disks are still okay after many years in storage with the manuals in a cupboard in the spare bedroom!

The 3½-inch disk contains all the files on the 5¼-inch disk set, though this must have been a third party conversion because the label states "This software supplied by GREY MATTER Ltd., 2 Prigg Meadow, Ashburton, Devon TQ13 7DF". Despite the HP150 format, I can read this disk without the HP150.SYS driver loaded. None of the files is compressed, so it's just a matter of copying the files to my hard drive and I'm good to go!

So, I'll see if I can get the Print1 and ReadADF programs to compile with Microsoft Pascal tomorrow.

Hey clenched,
I'm assuming that the FDC_UTIL.TPU file included in the source archive is just an intermediate (object code) file generated by Borland Turbo Pascal and so I won't need to use it. Is that correct?

[clenched]

Originally Posted by prowler

I'm assuming that the FDC_UTIL.TPU file included in the source archive is just an intermediate (object code) file generated by Borland Turbo Pascal and so I won't need to use it. Is that correct?

Yes, that is a so-called unit as opposed to a program. I just used the one already there on the first compile (the one Zoned). If FDC_UTIL.pas is compiled independently it produces a new (slightly smaller in my case) FDC_UTIL.TPU. I had no touble locating several of the Borland compilers with Google ranging from ~500K - 1.9M dl size. That's in case MS konks out on you.

EDIT: After a closer read, YES to the object file part and NO to the part about not needing it.

[prowler]

Originally Posted by prowler

I'll see if I can get the Print1 and ReadADF programs to compile with Microsoft Pascal tomorrow.

The Print1 and ReadADF source code is so incompatible with Microsoft's Pascal Compiler that this was more or less a non-starter.

This is the summary of the compiler source listing output (no object code generated) after Pass One:

                Errors  Warns  In Pass One 
PRINT1.PAS          42     41
FDC_UTIL.PAS         2     62
DECODSTD.PAS         2      2
DECODEXT.PAS         2      4
READADF.PAS        243    187

so I'd say it's beyond tinkering.

I'm not really surprised. Version 3.31 of the Compiler is dated October 1985. I'll start tomorrow trying to get the sources compiling with Borland Turbo Pascal, as they seem to have been written with that in mind.

Originally Posted by clenched

I had no trouble locating several of the Borland compilers with Google ranging from ~500K - 1.9M dl size. That's in case MS konks out on you.

I would have gone for those straightaway if I'd known they were available, but I really thought you were using original disks and manuals and thought I'd do the same.

I managed to grab versions 5.5, 6.0 and 7.0 last night while I was online. I've virus-scanned them, extracted the DOS files from the archives and everything looks good, so I'm all set.

[prowler]

Well, it certainly helps if you use the right compiler!

Earlier this evening, I got both Read1 and Readadf compiling successfully from the unchanged Pascal sources using Borland Turbo Pascal 7.0's TPX environment with the default settings.

Then I produced an English version of Readadf by replacing the German text in the Decodstd.pas module.

For the Readadf executables, I used the slightly smaller Fdc_util.tpu unit (4160 bytes) which resulted from having compiled the Fdc_util.pas module previously.

I have attached the files here, though I haven't yet had time to test them on my Disk2FDI machine.

Readadfd.exe is the German version. If these programs function correctly, then I shall compile a German version of the Print1 program next to go with it.

[Retro1234]

What kind of PC spec are you recommending? and what about modern PCs?

[prowler]

Documentation, such as it is, suggests Pentium 90 or better machine running real mode DOS.

My test machine is a P166MMX.

Clenched has exploded the myth that the program doesn't work with processors faster than 266MHz by running it without patches on a 450MHz machine, IIRC.

For machines without a parallel port, a PCI parallel port card can be used, and there are a few generic drivers available for such cards.

The more users who try this utility, the better idea we'll have of the min/max machine specs required.

[clenched]

Prowler - All three programs work OK here.
Tip for tough disks - Try feathering the eject button with varying amounts of force but not enough to eject it. This process is akin to the way the clutch would be worked to get a car unstuck from a ditch. This worked on Fusionpaint and WB1.3 disk. Experiment with releasing button at once, gradually easing off, or just maintaining pressure after the bad spot has passed.

[prowler]

Originally Posted by clenched

Prowler - All three programs work OK here.

Thanks for confirming that, clenched! I'm hoping to try them myself tomorrow.

Originally Posted by clenched

Tip for tough disks - Try feathering the eject button with varying amounts of force but not enough to eject it. This process is akin to the way the clutch would be worked to get a car unstuck from a ditch. This worked on Fusionpaint and WB1.3 disk. Experiment with releasing button at once, gradually easing off, or just maintaining pressure after the bad spot has passed.

I have seen a trick similar to this mentioned in the KryoFlux forums. In that case, it was achieved by carefully pressing the disk deeper into the drive to achieve a slight adjustment to the alignment of bad tracks with the read heads. That method has one limitation, however: it cannot be used when the disk fits very tightly in the drive. See tect's posts in this thread:
http://forum.kryoflux.com/viewtopic.php?f=4&t=176

Your trick, on the other hand, works by gently pulling the disk from the drive.

[clenched]

That post describes pretty much what I am seeing. The disk's jacket jiggles when viewed through the slot. I realize there is some play between the disk surface and the jacket but it must grab it enough to make the difference. Also the screeching noise WB1.3 makes disappears when the "sweet spot" is found.

[s2325]

I'm curious if Disk2FDI can work with old Toshiba laptop external floppy drive + internal floppy drive. This external drive is not connected with USB but with some special connector, I can not recognize it.

[prowler]

Originally Posted by s2325

I'm curious if Disk2FDI can work with old Toshiba laptop external floppy drive + internal floppy drive. This external drive is not connected with USB but with some special connector, I can not recognize it.

Disk2FDI non-Registered version can only employ the two drives trick if both drives are connected to the same floppy drive controller.

If the special connector you are referring to manages to configure the drives in this way, so that the drives are addressed as Drive A: and Drive B:, for example, without any drivers or remapping of the drive letters, then it should work.

If the external drive is accessed via the parallel port, say, or requires a driver to activate it, then Disk2FDI will not work, I'm afraid.

[seuden]

prowler, I find myself always reading your posts about this stuff, I have no clue about it but always find it intriguing. I think it's because you know an awful lot about it and I'm fascinated by your knowledge. Same as the sps guys.

[prowler]

Originally Posted by s2325

This external drive is not connected with USB but with some special connector, I can not recognize it.

Does the external drive connector look like a Centronix printer or SCSI port?

It's quite possible that this port is actually connected to the same floppy controller as the internal drive. It would be useful to know the external drive port pin assignments if you don't have an external drive with a suitable cable.

I have an old Amstrad laptop with an external drive port of this type, but I do not have a suitable external drive for it and the handbook contains no details of the pin assignments, unfortunately.

And, BTW, is your old Toshiba laptop not fast enough (Pentium 90) to run ReadADF?

Originally Posted by seuden

prowler, I find myself always reading your posts about this stuff, I have no clue about it but always find it intriguing. I think it's because you know an awful lot about it and I'm fascinated by your knowledge. Same as the sps guys.

Hey, I'm not in the same league as the SPS guys, you know. I have more luck with this stuff than real knowledge.

[s2325]

I must dig out that laptop, not easy task.

[felixkat]

The US has produced quite a few decent TV programs that are suddenly abandoned just as I was getting into them.

I just experienced the same thing with this thread.

I was really getting into it and then it was just abandoned. lol.

I'm quite interested in the many methods of data recovery as I have a few disks to do myself. I will certainly try this software, I'm pretty sure I have a motherboard kicking around with an old processor although i will try a modern'ish one first.

[lesta_smsc]

Lol revival of a dead thread but I agree it just 'stopped'... just out of curiosity what types of disks formats were successful in backup via these methods say compared to KryoFlux as this is certainly cheaper lol.