Mail Archives: opendos/1997/02/05/00:35:15
On Sun, 2 Feb 1997, Roger Ivie wrote:
> >root AT capslock DOT com wrote:
> >On Sat, 1 Feb 1997, Roger Ivie wrote:
> >
> >#1) Are you saying that you use COMMAND.COM on those little black
> > boxes on airplanes? I personnally think that this is NOT a good
> > enough reason for every PC user to NOT get direct video access. I
> > mean the number of black box users to PC users with a real
> > keyboard and a real video card and real monitor are about
> > 10000000/1. Sorry.
>
> Yes, the thing does run COMMAND.COM.
Cool. I want one.
> >#2) What we were suggesting was to ADD support for direct screen
> > writes to existing OpenDOS programs (primarily COMMAND.COM). How
> > does this effect you? It doesn't. There will no doubt be a
> > command line switch or a config file to enable direct screen
> > writes. Judgeing by the number of people interested in OpenDOS,
> > direct screen writes WILL become a reality.
>
> Just please don't make it difficult to _not_ do direct screen writes.
4DOS does it by setting an option in it's 4DOS.INI file. It
would be implemented in such a fashion in COMMAND.COM as well.
> All I really want you guys to think about is that there are other applications
> for OpenDOS besides a PC sitting on someone's desk.
Really? Oh yeah, a laptop. You're right!
> Just because something has an x86 does not mean it's a PC.
What? My microwave oven isn't a PC? Caldera had better make a
copy of COMMAND.COM that runs on my flourescent display!
> >> Fundamentally, memory-mapped video sucks. It is not as useful or as flexible
> >> as a good old serial port. About the only thing it's good for is drawing
> >> pretty pictures on the screen.
> >
> >That *ENTIRELY* depends on your applications. I think that serial
> >based video would really suck in any graphical applications, video
> >games, GUI's, and countless other graphical applications.
>
> Umm, aren't all of those "drawing pretty pictures on the screen"?
I'd hardly call them "pretty pictures", but...
Ok, how about Norton Commander, Norton Utilities, Telix,
Borland C IDE, RHIDE, LIST.COM, Boxer, countless other HUNDREDS
of THOUSANDS of text based software. Lots of software uses
direct writes, and a lot of them let you choose.
> There are plenty of applications for text mode left. It is already extremely
> difficult to do something unusual with the x86 processor; having unnecessary
> direct screen writes in the operating system is just more annoying.
First off, they aren't in the operating system. They *WOULD* be
in the command processor. The command processor is NOT the OS.
Besides as stated allready you could *choose*. Even if they hard
coded direct writes into COMMAND.COM, you're free to use the
COMMAND.COM from 7.01, no-one will stop you.
I don't see how doing direct screen writes is a "difficult" or
"unusual" thing to do with the x86 processors.
As for the plenty of apps that are left for text mode, I'll agree
with you. BUT, they should be direct screen write apps so that
*I* don't have to close my eyes to stop from getting a headache
waiting for screen retraces!!!
I think I'm going to code you a special version of command.com
that not only does DOS writes to the screen, but does them at
75bps!!! Then put BREAK OFF and DIR /S as the last line of your
autoexec.bat. :o)
> >> By the way, there are (or at least used to be) some really good fast console
> >> drivers. FANSI Console, for example, is blazing fast and still does ANSI
> >> terminal emulation.
> >
> >Who needs an ANSI driver in DOS nowadays? Keyboard redefinition can
> >be done via 4DOS etc. etc. etc.
>
> My point was that FANSI Console did blazing fast straight DOS writes to the
> screen; much faster than many programs I've seen which do direct video writes.
An ANSI driver doing blazing fast writes to the screen? That is
HARDLY direct writes!!!! MYPROGRAM->DOS->BIOS->ANSI.SYS->SCREEN
You email me a copy of FANSI.SYS, and I'll write a small test
program in C and make it do a screen test of what fast is. I'll
write some things to the screen via FANSI (in color of course),
and then via direct video memory access, then with DOS writes
without an ANSI driver loaded. I believe the order will go
something like this.
FASTEST->DIRECT->DOS->FANSI->SLOWEST
BTW, I'm very serious about sending me the driver. I *WILL*
write a program and profile it, giving out sources and
results when I'm done.
> > Sure, there are many uses for OpenDOS, and many uses for embedded
> > systems, however I don't see any problems with having the best of both
> > worlds. Why do you?
>
> Because I used to own a DEC Rainbow. I know where things go once everything
> starts doing direct screen writes.
Well, then you know that direct screen writes are as fast as you
can get. As a matter of fact, if I had it my way, I'd make
"Text Accelerator" cards, so that you could just send a few bytes
out port 0x4000 which would print RLE runs like:
outportb(0x4001, 0x1F); White on blue background
outportw(0x4000, 0xe5); Number of characters to repeat
This would be GREAT!!! It could also have functions for
implementing turbovision-like windows and stuff on the screen,
and have many English pulldown menu words downloadable, so that
you wouldn't have to send the text of pulldown menu's to the
screen, you could just download them into the accelerator, then
use a code to reference them. What a great idea!!
Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris
Computer Consultant | My webpage has moved and my address has changed.
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
mailto:mharris AT blackwidow DOT saultc DOT on DOT ca
OpenDOS: Download it now! http://www.caldera.com/dos/dos.htm
- Raw text -