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.

> 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.

Because BIOS is not stored in RAM. It's stored in a ROM/EEPROM which is
slower than RAM. It's mapped onto RAM so that it's directly accessible.
Access speed can be increased by enabling Shadow RAM for that BIOS memory
range in RAM. But even that, it's still a bit slower than RAM.

On Wednesday, November 17, 2021 at 12:38:07 PM UTC+11, JJ wrote:
> 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.

On Tue, 16 Nov 2021 19:07:38 -0800 (PST), muta...@gmail.com wrote:
>
> 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.

> If ANSI is crap, can it be made non-crap by Microsoft or some
> rival?
>
> Thanks. Paul.

I don't think ANSI is crap. Of course, there's a possibility that binary
data outputted to the screen by a program, may end up triggering ANSI
function and visually screw up something. But that's a problem on the user
side. Not ANSI.

On Saturday, November 20, 2021 at 1:35:26 PM UTC+11, JJ wrote:

> > 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.

On Mon, 22 Nov 2021 09:58:45 -0800 (PST), muta...@gmail.com wrote:
>
> 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.

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.

On Tuesday, November 23, 2021 at 8:05:35 PM UTC+11, JJ wrote:

> > 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.

The software would probably be portable at the source
code level to other environments like the Amiga if ANSI
escape sequences had been used. It wouldn't just be
DOS/8086.

BTW, another possibility would be for ANSI.SYS to be
auto-loaded when it is determined that the executable
needs it, like a DLL.

> 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.

On Tue, 23 Nov 2021 11:27:40 -0800 (PST), muta...@gmail.com wrote:
>
> 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.

Uh...

> If ansi.sys had instead directly written to 0xb8000 itself,
> would that have alleviated the problem and made using
> ANSI control characters viable?