#amiga hard drives
12 messages in this thread
Steve,
I had a problem with prep accessing the wrong drive. Notified Andy of this
about 2 months ago. The new hddisk fixed the problem. Also if you look at the
new driver with NewZap you will notice a reference to a RomBoot.device.
The upcoming hd boot capability is probably going to require this release
of hddisk.
BTW a little off subject but! Is there a way to disable ctl-p on the CIS
end. Almost every day, when dumping the msg's here I'm getting sent back to
the menus. The strange thing is the control P will appear in the middle of a
word without any other line noise around it. Wouldn't mind so much if the
high-msg pointer was updated.
Dale
I too have the latest version (HD34_4) of the HDdisk.device driver and am
trying to keep from tearing the hair I still have off when, at random times,
(usually while copying or using a diskutil) the hash tables will be trashed
or a WHOLE sub-directory dis-appears (AND I MEAD/N DIS!). What could be
causing this? Andy, have you any sugesstions(sic)? Using a 5 meg 2000 w/A2090
and 2 ST506/412 drives (one k/ now serves ONLY as a backup for the other
since I can't r/ trust these things….Using a Miniscribe 3650 as DH0: and a
Seagate 125-3 1/2" as DH1: HELP!!! PLEASE!!! NO MORE @@@@!!##$$$$ 2-5 hour
backups because of a silly device driver or some such
fault….PLLLLEEEAAASSEE?
Griffith
Griffith,
I haven't had any problems with the new driver. I'm using SCSI drives thou.
There is a possibility that you have found a bug that affects your particular
setup. (ie. ST-506 or some drive incompatibility)
I had a problem with the old hddisk. The problem only occurred when using
multiple Miniscribe 8425s drives. (Prep would always access the first unit in
the string.) I had to rip the 2000 apart and re-address the drives just to
prep the second drive.
I would suggest going back to the old driver & leaving Andy some EMail
detailing your problems. The new driver doesn't seem to be important at this
time anyway. It's not faster and does not offer any enhancements that I can
find. I think it's main purpose is ADos 1.3 romboot.
Andy seems to be good about these things. He'll listen, check it out, and
get back too you. At least he did with my problem.
Dale
Thanks, Dale, for the info….it may be that the ST506 side is the only thing
this bug BITES, but it is definitely there and I'll follow your suggestions
about telling Andy. I did switch back to the older driver and all buggy
operation has ceased (I think!) so it's definitely going to have to be
resolved if not only for me., but for all the others that will sooner or
later run into the problem…thanks again..
Griffith
Griffith,
I am running a 2000 with 5.5 megs on memory, a 2090, and two ST506 drives,
with none of the problems you mention. i think the driver is fine, and would
look elsewhere for a problem. What sort of software are you running?
-larry
Weellll???…..I don't know what is happening right now in terms of the
driver that was released here (HD34_4), but when I changed back to the older
driver, the crashes and wierd behaviour stopped! (to the best of my knowledge
right now)
I don't use very esoteric software, am an EE and MSCS, so I think I have a
basici c grip on what to do at startup (setting stack, properly setting up
background tasks, etc.) The specific piece of software I was running into the
most trouble with is DISK MECHANIC by Lake Forest Logic. Eric(k) from Lake
Forest has been as helpful as could be expected considering I am in Seattle
and LFL is in Illin ois. His sugesstion was to change back to the older
driver and indeed that did help, but it's too early to tell whether it cured
the situation. He's also checking with C= to see what they did to the new
driver's structure vis-a-vis his software.
Other than that, I have run into wierd copying problems like LOSING entire
directories doing a COPY A// (COPY DH0: DH1: ALL {Quiet}) which should show
NO problems at ANY time….I dont(sic) get into multu/i-tasking so I would
guess
no problem there….any other Ideas would be appreciated….Thanks,
Griffith
Griffith,
I'm not familiar with DISK MECHANIC, though it does sound interesting. I
can certainly understand a program of that name having problems if the author
made any unwarranted assumptions about the driver, but the other problems are
harder to figure out.
Interstingly enough, I just had a strange thing happen today, when a file
sort of 'disappeared'. I could still access it, but it showed up in neither
LIST not DIR. I used Sectorama to track it down, and it was second place in a
hash chain, with the first entry being a corrupt one. I think I'll play it
safe and go back to the older driver too. It's also faster.
-larry
YES! Larry, youve(sic) just experienced the same kind of problem I had. I got
into one drive with Sectorama and found the same thing when a program would
not DIR or LIST for me. Something strange going on inside that driver! I wish
C= would be more forth-coming and open in release of the source code ala IBM
for HDdisk.device., then we could REALLY see what was going on. Why have they
not done this? It only works with the A2090 so I can't see where they would
lose money or anything….IBM is the giant in PC's BECAUSE they released
source with the computers and made it an open system. Interestingly, now that
they are NOT releasing source on the PS/2 line, their market share has
dropped
Lets all encourage the release of source for these things that depend upon
specific hardware (where the manf. would not lose anything at any rate)…
Are you listening C=????????????
good luck Larry, Griffith
The idea of releasing source is an interesting one, but one that gets
pretty scary in terms of providing support for the software. How can I
provide support for software that you, the user, has modified? I can hear
it now, "the change I made can't possibly have any relationship to the
problem I'm experiencing". Now don't take this as a personal attack, cause
it isn't meant that way. Now, if one were to purchase software on an "as
is" basis, then releasing the source would be less of a problem, since the
buyer is on his/her own for support anyway. That's just not the way things
work.
You have a point about supporting software that has been modified, but
there is always the position that a modified version is not supported,
period. It is easy enough to check that the person is talking about the
original, and to just plain refuse to listen if it isn't the released
version. One side benefit of this would be that CBM could use ideas or bug
fixes incorporated by others, and save money/time doing it.
Larry,
Offering support _only_ for unmodified software is the only way feasible,
but even with that position, I'd still be expecting calls for support for
"unmodified" versions that in fact were modified. And to track that down
would be a royal pain in the a**. If this policy were the norm, then it
would be hard for users to keep track of which software packages that they
use were modified, and which were virginal – especially 6 months or more
after they started using the software, and had almost forgotten about it's
existence. It would be difficult at best to implement, and closer to
impossible.
Bob,
Your points are well taken. I do think though that this should not be a
'blanket' policy for all things, but there are certain pieces of software
that cry out for availability of source so that they can be modified to suit
the users needs. The hddisk.device is a case in point. CBM chooses not to
support anything but the most generic of SCSI controllers, and those are for
disk. What about all the tape drives and other SCSI devices that we might
want to talk to? In this case, I feel that either the source or full
documented functionality should be provided. As it stands right now, I am
seriously considering going to another controller, and it's a shame because
the 2090 is fast, low cost, and supports ST506 as well as SCSI.
-larry