I believe MSDOS programmers would directly access
0xb8000 because using ANSI control characters with
ansi.sys (which uses the BIOS) was too slow. The only
figure I have is that it takes about 1 second on an XT
to draw a screen using the BIOS.
If ansi.sys had instead directly written to 0xb8000 itself,
would that have alleviated the problem and made using
ANSI control characters viable? So long as the application
had done a setvbuf to fully-buffered, just a single write()
interrupt could have been done to do the work. So it's a
question of how much overhead is involved in constructing
ANSI controls which are then interpreted by the same
machine.
You know, what's really needed is for something like
curses to be in the OS itself and directly callable as a
library. Which is what the BIOS already is, except it isn't
callable. Why is the BIOS slow in the first place?
Thanks. Paul.
On Tue, 16 Nov 2021 13:08:17 -0800 (PST), muta...@gmail.com wrote:
I believe MSDOS programmers would directly access
0xb8000 because using ANSI control characters with
ansi.sys (which uses the BIOS) was too slow. The only
figure I have is that it takes about 1 second on an XT
to draw a screen using the BIOS.
If ansi.sys had instead directly written to 0xb8000 itself,
would that have alleviated the problem and made using
ANSI control characters viable? So long as the application
had done a setvbuf to fully-buffered, just a single write()
interrupt could have been done to do the work. So it's a
question of how much overhead is involved in constructing
ANSI controls which are then interpreted by the same
machine.
I think only old programs (relative to DOS era) still use BIOS for screen output. Newer programs writes directly into the video buffer. So, it's a question of whether you're using an old program or not.
I'm looking into sensible rules that should have existed
around 1983 with MSDOS 2.0. Can we direct programmers
to use ANSI control characters (which incidentally were only
supported once again in Windows a few years ago), or are
programs going to be crap if ANSI is used?
If ANSI is crap, can it be made non-crap by Microsoft or some
rival?
Thanks. Paul.
I'm looking into sensible rules that should have existed
around 1983 with MSDOS 2.0. Can we direct programmers
to use ANSI control characters (which incidentally were only
supported once again in Windows a few years ago), or are
programs going to be crap if ANSI is used?
The problem is that MS-DOS and all of its variants (so far) don't have built in ANSI escape sequence support. It only exists as an optional feature. Because of that, there's no guarantee that every DOS systems have ANSI support enabled. That's why programmers don't take advantage of ANSI.
So if basic ANSI support had been embedded in MSDOS 2.0,
at the cost of presumably a few kb of RAM, and preferably
had directly manipulated video memory instead of using the
BIOS, the world would have been a different place?
BFN. Paul.
So if basic ANSI support had been embedded in MSDOS 2.0,
at the cost of presumably a few kb of RAM, and preferably
had directly manipulated video memory instead of using the
BIOS, the world would have been a different place?
In DOS world, yes, I would think so.
Linux is a good example, where there are relatively more softwares which
take advantage ANSI escape sequence than DOS at the time DOS hasn't been taken over by Windows. And probably up to this day if compared with DOS and Windows 10 softwares combined.
That's for the ANSI part...
Direct video memory access is an entirely different matter. MS-DOS 2.0 may
be implemented to use direct memory access, but it will only recognize standard video modes. It won't recognize custom video modes unless VESA already exist at that time, and is already supported.
Without VESA, there won't be a standard method to describe the configuration of a video mode. i.e. DOS and its softwares can't know if there are 15, 16, 24, and 32 bits pixel video mode. Or whether the video buffer is planar or linear, etc.
Sorry, why is any of this needed? What's wrong with 0xb0000
and 0xb8000?
The competition is only with the BIOS, not graphics.
BFN. Paul.
If ansi.sys had instead directly written to 0xb8000 itself,
would that have alleviated the problem and made using
ANSI control characters viable?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 417 |
Nodes: | 16 (2 / 14) |
Uptime: | 11:47:45 |
Calls: | 8,759 |
Calls today: | 2 |
Files: | 13,287 |
Messages: | 5,963,484 |