Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Jan 1996 19:50:43 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        nate@sri.MT.net (Nate Williams)
Cc:        terry@lambert.org, hackers@FreeBSD.org
Subject:   Re: Multi-Port Async Cards
Message-ID:  <199601300250.TAA05385@phaeton.artisoft.com>
In-Reply-To: <199601292306.QAA09994@rocky.sri.MT.net> from "Nate Williams" at Jan 29, 96 04:06:41 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > Companies like Diamond, whose reluctance to provide programming info
> > stems from their hiring of EE's to write their ROM code ...
> ...
> 
> > Maybe they will hire a software engineer before it is too late; maybe
> > not.
> 
> Are you saying that EE's are not software engineers, because I take
> offense at that.  Some of the best software engineers I know have EE
> degrees (and don't have CS degrees BTW).

Some of the best ones I know are HE or Solid State Physicists.  8-).

The problem is not the ability to solve problems (which I think comes
from teaching critical thinking skills and so all hard science types
have an edge).

The problem *is* that for a hardware company, software is always second
fiddle to the hardware, and is used to "fix the hardware" instead of
being written to be software.

That leads to a tendency to take the first thing that seems to work as
final product.

Software, unlike Hardware, is not necessarily good just because it
survives burn-in.  8-).


A *good* video BIOS would work in protected mode or real mode and not
care.  If the programmer was truly a weenie, he'd give you an alternate
entry point for all INT 10 calls that would work in protected mode as
well as the ones that wouldn't so he could save his push/push/pop/pop
in the "real mode" case.

A *good* video BIOS would have a JMP followed by a structure that has
a version number (in case) and is otherwise expected to be the same on
all cards so the protected mode driver doesn't have to be rewritten
for each release.

A *good* video BIOS waits for veritcal blank instead of disabling
interrupts to get rid of "sparklies" on non-dual-ported RAM access
(cv: some ATI and Paradise VGA cards).  Disabling interrupts might be
OK if all you are doing is video I/O, but it sucks if you are using
the console on a 100Mb/S router, etc..


Anyway, you get the idea -- I don't need to redesign Diamond's BIOS for
them here (they need to hire someone who understands modular design
principles to do it, since the guy who did it last time screwed up).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601300250.TAA05385>