#Controllers
10 messages in this thread
Hi Ron,well what if someone asked me if I knew about that problem on their HD
Controller…..like what is the fix for whatever that controller is?
C u laitr
Brendan Pratt – Queensland,Australia.
Beautiful one day,
Perfect the next!
I understand what you're trying to say, its just that this is not something I
consider a problem. I know that a few people might hit a problem that is
corrected by changing a small setting. If someone actually bumped into it and
called the manufacturer they would get this same info. And since I watch out
for many scsi related issues on the 3 forums, if someone raised it here odds
are pretty good I'd notice, or for that matter, the manufacturer might notice.
Ron
Ron,
Personally, I think that's a pretty bad attitude. Someone has specifically
asked you a question, and you are too much of an apologist for C Ltd. to answer
it. If it is such a small problem, and easily correctable, then there is no
reason why you should hesitate. If it isn't a small problem, then everyone
should be aware of it. The whole thing leaves me wondering what _your_ problem
is. Have you been instructed by C Ltd. to not mention it?
-larry
I haven't been instructed by anyone at any company. I simply was advised that
there is a small possibility that someone doing a download might have a problem
using a certain piece of hardware with one of its software parameters set a
certain way. This is by no means a certainty, and I suspect that it would only
happen at extremely high thruput rates, such as one might get attaching
serialport to serial port. When the original question came up here I merely
asked what scsi board was in use to see if there was any chance it could be the
board in question. It was not.
As for being an appologist, you are the person who still seems convinced that
if CBM built it then it must be perfect. As to my opinions on products, when I
find bugs or problems I promptly point them out to the vendor or builder or
publisher if reasonably possible so that they can be fixed.
Ron
Ron,
Yes, you did ask the person in question, but someone also asked you a direct
question about that answer. Apparently you are choosing to keep folks in the
dark about it, for reasons of your own, said reasons being suspect at best,
considering your history of disinformation about any non-C Ltd. products, and
your gushing over anything bearing their name.
That _you_ suspect it would happen at high rates of speed on the serial port
is no consolation to the poor fellow who is wondering why he is having problems
at all, and does not think to call C Ltd. because it isn't the Kronos that
looks like the culprit to him. Doesn't leave much doubt in my mind that you
care more about some concept of the perfection of C Ltd than you do about the
people who ask you direct questions, or at least not in my mind.
No… I am not convinced that CBM products are perfect, and if you had been
paying attention, you would have seen me slam many CBM products, bugs, and so
on over the years. You say that when you find bugs or problems, you promptly
point them out to the vendor. Seems to me that when they are problems with your
beloved C Ltd products, that's true, yet you do not hesitate to point out
problems with other vendors products to the world at large.
-larry
When the person in question told me what he was using, it was not the item I
was thinking of and I told him so. Period. And as to CLtd products, I've
spent enough time telling Ed very directly when I find problems in his
products, and he generally fixes those problems and listens to my comments. And
you are the one who always leaps to the defense of CBM products, especially the
holy 2090(a), quick to overlook its features/problems when overlooking them
suits you. With about as big a holier then thou attitude and an ability for
putting people down as I've ever seen.
Unlike you, I am generally willing to admit that I don't know something, or
that I've made a mistake. There are some areas I don't claim any real
knowledge, such as programming the Amiga (though I do consider myself a good
programmer). I admit that I sometimes offer my opinion a bit quickly, yet I
think I have some degree of ability to cut thru the bull and do a fairly good
and impartial evaluation of something regardless of personal prejudices or
loyalties. And if I sometimes make some decisions that people don't like, such
as not announcing what device and maker in this case, so be it. My best
judgement is the way I go.
Ron
Ron,
Again, if you had been paying attention, or if your memory weren't quite so
selective in what gets retained, you woulkd have noticed that I do not leap to
the defense of anything when it gets put down for reasons that have basis in
fact.
Your affirmation that you will not enlighten folks about a possible problem
only serves to reinforce my evaluation of your motives as I noted earlier in
this thread. If that's 'your best judgement', I'd hate to see your worst.
-larry
Larry,
If what you are talking about is the Kronos board's dropping of serial
data, then I ran into it at first with my new Kronos board. But the REASON and
SOLUTION for this "problem" *IS* documented in the manual.
In the file "DevSetup" (where the device setup info is stored) there are
two basic areas – the "Initialize Handler" and "Initialize Unit" (there can be
more than one of each of these, depending on the connected hardware). In *both*
there is something called "Flags NoDisable_IRQ" , (or "Flags Disable_IRQ").
Both sections say the same thing – "Hold Of (should be off) Interrupts.
This attribute allows the user to select between 'Disable' and 'NoDisable'.
When Disable is selected, all system interrupts will be held off during SCSI
bus data transfer and processed when SCSI transfer is complete. This provides
Maximum SPEED at the cost of jerky mouse movements during hard disk activity
and the inability to reliably operate most telecommunications programs while
hard disk activity is in progress. When 'NoDisable' is selected, all operations
will act normally, but some minor speed degradation (single digit percentage –
depends totally on applications in progress at the time) will may (their
wording) occur with some hard drives. Selecting the 'Disable' here will
over-ride the GLOBAL selection of 'NoDisable' made in the 'HANDLER'
Initialization. If the GLOBAL selection is set to 'Disable' it can't be
overridden by any setting here."
<continued>
<continuation>
On their setup floppys, they have two unit entries, one with Disable_IRQ
and one with NoDiable_IRQ, but unfortunately the Disable_IRQ example is the
FIRST on, and the one *I* used without much modification. That is what caused
my problem. But once discovered, it *WAS* easially corrected.
Why have the option? Well, with Disable_IRQ set, the hard drive works
faster. A Seagate SCSI drive on my computer with the Kronos was about the same
speed as a similar Seagate SCSI drive on a friend's HardFrame. With
NoDisable_IRQ, it was just a little slower. With the option to set it, you can
have different hard drives, or different PARTITIONS of a single hard drive, set
up for "safe" use of telecommunications, or for speed.
I don't know what the "problem" between you and Ron is, but since it *IS*
discussed in the manual, I can hardly believe that he has "…been instructed
by C Ltd. to not mention it."
Lloyd
Lloyd,
Thank you kindly for that clear explanation.
I don't know if it is the same problem that Ron was tiptoeing around, but if
so, I hope he sees that he is doing more harm than good by his actions.
-larry -larry