On Thu, 22 Oct 2020 10:32:17 +1100 David <bouncingc...@gmail.com> wrote:
> On Thu, 22 Oct 2020 at 08:45, David <bouncingc...@gmail.com> wrote: > > Hmmm again. Ignore my previous message. I didn't read the thread > carefully enough. I still haven't done that, because I should be > doing other things, but I have looked a little bit more carefully > so I have slightly better suggestions. ... > I downloaded the bootable image > https://www1.hgst.com/hdd/support/downloads/ftool_215_install.IMG > > and looked inside it using: > sudo mount -r -t msdos -o loop dft32_v416_b00_install.IMG /mnt/junk I tried that too. Just for the record, mount is pretty smart these days: a simple # mount image_file mount_point works fine ;) > The CONFIG.SYS file in the image shows what drivers are expected > to be loaded. A lot of what is in there is standard guff (ramdrive, upper > memory use, that may well be unnecessary) and causing the error > messages you reported earlier. It could be greatly simplified. > It looks like no additional drivers are loaded for ATA drives. > > The AUTOEXEC.BAT file in the image contains the essential > PATH=A:\DOS;A:\DFT;A:\; > cd DFT > LOADDFT.EXE DFT-V300.EXE DFT.EXE /PSR >NUL > > The final line is the most important. > That shows the correct use of the LOADDFT.EXE and > DFT-V300.EXE files, and invalidates my previous advice. > > The >NUL might be hiding diagnostic messages. > > And I wonder if /PSR is anything like "terminate and stay resident" > so I would be wary of expecting sensible results if running that > line more than one time. > > What I would do is rename AUTOEXEC.BAT in the image, to disable > it, and I would run the above commands manually at the DOS prompt. > And I would run them without the >NUL and perhaps also without the /PSR Thanks much. I think I'm done wasting time trying to get this thing to work, but if I'm motivated to try again, I'll keep this in mind. Celejar
