Mesajul original a fost trimis de "Clarence Verge" <[EMAIL PROTECTED]>
la data de Sat, 09 Jun 2001 04:12:14 EDT
>
> What can I say. The video drivers are crap and nothing will ever be done
> about them because some people believe that "C" is a useful programming
> language for such things.
>
> The reason I say the HTML may be marginal is because I also tried the
> page with A1.66 and it was incapable of rendering the tables correctly
> at all. I didn't bother with A1.70 because I feel it is too slow to be
> useful.
>
> Maybe some negativity will generate some activity ??
>
> > DOS users are not left out!
> > Try http://www.rahul.net/dkaufman/
>
>
> - Clarence Verge
> - Back to using Arachne V1.62 ....
Don't blame the C language for that!
The reason for the "lazyness" of the video drivers is that programming a
driver for a given OS can be tricky in its nature. Especially when the OS was
never designed to use that type of hardware. They often prefer to offer a
stable and versatile driver, capable of working with many applications,
instead of a fast but unstable and susceptible to crash at any moment one (and
AFAIK nobody has complained about Arachne locking any video card).
Also the limited amount of memory at Arachne disposal prevents her for playing
all sorts of tricks with the video card. In absence of the virtual screen,
scrolling may be is as simple as "clear screen, increment starting row and
redisplay the screen". To redisplay the screen may mean to reuse the "
generally display screen " routine for the tighteness of the code and to save
programming time.
"C" can't be blamed here. Blame the programmers using C the same way they're
using BASIC or Pascal or other programming languages totally unfitted for
doing things which are in close connection to the hardware. For the past five
years I have been programming nothing else applications for 8 bit
microcontrollers - tiny monsters with 1 to 8 kbytes of on-chip flash memory
and only 128 to 512 bytes of SRAM. The only languages to be used here -
assembler and C. Sometimes they're playing with BASIC - small 1-2 kbytes
interpreters - or flavours of Forth, but not for serious purposes. Any other
language would have big runtime routines with sophisticated ways of detecting
errors - simply they don't fit in.
Carefully using pointers and optimizing tricks 20 to 30 kbytes of C source
may result in 5-6 kbytes of binary code. And this by using no other compiler
but the well-known GCC, which has a port for the Atmel AVR RISC micros (it
suffices to download a recent snapshot of GCC and binutils from CVS or the one
of the GNU sites and do a "configure --target=avr" then "make" and "make
install". Under Linux, of course).
The big diference between PC programs and embedded microcontroller
applications - when encountering an error the PC programs either warn the
user and stop, either crash. The embedded applications have to find a way of
dealing with the error themselves, or, in the rare cases of a crash, a special
circuit named watchdog should reboot. In this particular case the program
should continue from where it was prior to the crash.
And C does it
--
Cristian Burneci
DHP Technology SRL
Bucharest, Romania
