Ben Franchuk wrote:
Jerome H. Fine
wrote:
But I am totally unable to solve hardware problems, so it would
be interesting to know how long the average hardware fix takes?
It really depends
on A) How fast can you be without a computer or
radio or whatever. B) Finding the bug and getting parts to repair.
I would suspect software and hardware bugs take the same magnitude
of time to find.It is when you have software interacating with
hardware the fun begins are you are now not sure what works.
Jerome Fine replies:
Fortunately I can't remember having that problem very often.
When I first started to program computers, I found it difficult
to find software bugs. While it is still difficult, I now realize that
hardware rarely fails. Although I have found a one or two bugs
that were caused by a hardware failure during more than 40 years
of working with and designing software, I initially made the mistake
of blaming hardware some of the time. I could not accept that
my programs could actually have a bug. Finally - through much
experience - I realized that 99.9999999% of the time, it was a
bug in my program code that was causing the problem.
Two examples of hardware might help:
(a) I once found a sticky bit - defined as a bit which was always
ONE when it was supposed to be ONE, but sometimes a ONE
when it was supposed to be zero. The quick solution was to be
sure to place an instruction at that location which required that
the sticky bit be a ONE - that way, the program always worked.
(b) Although I never did see the exact problem, back in 1990
(or around that year) I bought one of the first CQD 220/TM
host adapters. When I attempted to read a block into a user
address in high memory (RT11XM for you fellows who can
understand) that overlapped a 1/4 MByte (or 256 KByte)
boundary, the system crashed. I finally isolated the problem
by forcing the device driver to step through the code - after
which using hardware ODT I found that the firmware in the
host adapter had done a wraparound when the DMA address
had reached the 1/4 MByte boundary and started to place
the rest of the read into addresses at zero - thereby destroying
the interrupt vectors in low physical memory. What astounded
me was that CMD admitted the error two days later when they
were able to duplicate it in their labs (it helped to know exactly
what to look for). Within two weeks, they had sent a new version
of the 2 EPROMs used in the firmware for the host adapter.
What was interesting was that Dialog had the same problem
with the early versions of the SQ706A which I was testing as
well and Dialog in Canada refused to admit there was a problem.
I suspect that I should have asked CMD for a free host adapter
for identifying the problem - after all, it must have been the same
with a microVAX II as well.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
