Fast Clear VGA mode 13 screen with 16000 byte loop

can be found here:

http://www.geocities.com/yssmlp

CII wrote:

> can be found here:
>
> http://www.geocities.com/yssmlp

here's what's in the page:


CII wrote:

> can be found here:
>
> http://www.geocities.com/yssmlp

FASTCLR.BA?,.ASM ((C) 2005 by YSS)
----------------

Test program to fast CLR hires $13 (16000 byte cycle loop) through the
use of the 32bit internal VGA video bus. Read the notes for technical
details. The notes may be somewhat scattered, but all the info needed
is there. Those notes were put together from observations through
direct programming of the VGA registers and from reading tech info on
VGA, so that's just what they are, notes.

This file lists one example in both BASIC and 80x86 ASSEMBLY versions.
Listings are somewhere inside file.


Premise: It's possible to clear the VGA mode 13 bitmap at 4X speed,
i.e, by a byte loop that repeats 16000 times instead of 64000
times.



INTRO
-----

A long time ago, 2600 taught me -and some friends as well- that during
game programming every cycle counts (if you want to make sharp smooth
games anyway). Clearing the bitmap screen is no exception, and you'll
want to do it as fast as possible. Instead of using the 64000 byte
clear loop (or its 32000 16bit clr version), why not use VGA's internal
32bit bus to do the same thing at 4x normal speed? That's what
FASTCLR.BA?,.ASM do: They program VGA's sequencer for this purpose.
The details are down below in the notes.

FASTCLR.BA?,.ASM work in 7 easy steps:

1- Set hires mode 13
2- Fill the screen with a test pattern (anything)
3- Wait for a key before clearing. If key=esc -> end
4- Tell VGA's sequencer NOT TO CHAIN its 4 bit planes during CPU access.

5- Wipe the ENTIRE video screen (320x200, 64000 bytes) thru just 16000
bytes. 6- Wait for a key again. If key=esc -> end.
7- If not, CHAIN back the way it was and repeat from step 2.

** end means set screen back to normal and exit.

Good luck.
pixelrat@hotmail.com
///////////////////////////////////



Notes:
(Mar 30,
2005) 03C4 #4 BT3 controls the "chaining" of bit planes in VGA.

('03C4 #4' is to be read 'Port 03C4 index 4' meaning write 04 to port
03C4 and read or write
from/to port 03C5 to
read/alter index 4 of 03C4)

[Incidentally, port 03C4 on ibm/at style machines with VGA is mapped to
VGA's "Sequencer Registers", which has 5 registers. Register 4 (index
4) is called the "Memory Mode Register" and that's the one in question
at this time.]


[Remember how VGA cards use memory banks called "display memory bit
planes". There are 4 planes which are numbered 0 to 3. Those bit planes
are where video image data comes from in VGA.]


When planes are "chained", CPU accesses to them are individual, that is,
sequential.

Example: For addresses incrementing one byte at a time, the CPU
accesses one plane first, then the next one in chain, then a third and
then a fourth. Afterwards it accesses the first one it first accessed
again but one
sequential byte after (sequential in the plane), and so on..

[sequential in the plane means that each plane has 64K bytes, numbered
from 0 to 65535. That sequence is not necessarily followed by the CPU
address decoding, which is what this is all about.]

[** CHAINING seems to affect CPU accesses only. Display output doesn't
seem to be affected.]

[ When the bit planes are chained, when CPU writes to VGA, it writes to
one single plane at a time. When planes are "not chained", "loose",
"unchained" or however you'd call it, when CPU writes to VGA it can
write to ALL planes AT ONCE.]



The chaining is actually controlled by A1,A0, the two least significant
CPU address bits into VGA memory. That means that accesses A1-A0=10 are
done upon VGA memory bit plane 2 ('10' binary). That also means the
following:

Every contiguous byte in each plane is accessed every 4th
CPU access, since the last three were done upon the other
planes. I know it may be kind of hard to picture, but it
works.

Ex.: In chained mode,

OFFSET ADRR = 0000 (A1-A0=00) accesses byte 0 of plane 0
0001 01 '' '' 0 '' '' 1
0002 02 '' '' 0 ' ' 2
0003 03 '' '' 0 ' ' 3
0004 00 '' '' 1 ' ' 0

Someone wrote this in 2005. In MASM. For DOS.
In 16-bit mode for the 8086.

Why?

John Nagle

I'm not trying the tools, just the principle, but just so you know I'm
glad you've asked such a question. It's a very good question in fact
and I have my reasons for it. .

However, what does it matter what platform or language or approach I've
used, as long as the method works?

If you've got a better method that you could share, I'll appreciate it
greatly and look into it right away.

I invite you if you like to write the same thing I did in assembly in
the language of your choice and to post it here for others to see and
study just as I've done. I'm sure someone will benefit from it. If you
make it work in less than 84 bytes I'll be happy to hear about it and
we'll then take it from there.

I'm extending that invitation both professionally and corteously.


Regards.

John Nagle wrote:

> Someone wrote this in 2005. In MASM. For DOS.
> In 16-bit mode for the 8086.
>
> Why?
>
> John Nagle

In article <42541387.22E515A9@laposte.net>, x.yss@laposte.net says...
> I'm not trying the tools, just the principle, but just so you know I'm
> glad you've asked such a question. It's a very good question in fact
> and I have my reasons for it. .
>
> However, what does it matter what platform or language or approach I've
> used, as long as the method works?
>
> If you've got a better method that you could share, I'll appreciate it
> greatly and look into it right away.
>
> I invite you if you like to write the same thing I did in assembly in
> the language of your choice and to post it here for others to see and
> study just as I've done. I'm sure someone will benefit from it. If you
> make it work in less than 84 bytes I'll be happy to hear about it and
> we'll then take it from there.

CRect clientRect;
GetClientRect( & clientRect );
GetDC()->FillSolidRect( & clientRect, RGB( 0, 0, 0 ) );

That will blank the MFC window I'm using, fast enough for most
purposes, and it took seconds to write.

However, I think Blitz Basic has a 'Cls' keyword which is even more
economical.

In both cases, one need not waste time on issues that are irrelevant to
programming games nowadays.

- Gerry Quinn

Gerry Quinn wrote:

> In article <42541387.22E515A9@laposte.net>, x.yss@laposte.net says...
> > I'm not trying the tools, just the principle, but just so you know I'm
> > glad you've asked such a question. It's a very good question in fact
> > and I have my reasons for it. .
> >
> > However, what does it matter what platform or language or approach I've
> > used, as long as the method works?
> >
> > If you've got a better method that you could share, I'll appreciate it
> > greatly and look into it right away.
> >
> > I invite you if you like to write the same thing I did in assembly in
> > the language of your choice and to post it here for others to see and
> > study just as I've done. I'm sure someone will benefit from it. If you
> > make it work in less than 84 bytes I'll be happy to hear about it and
> > we'll then take it from there.
>
> CRect clientRect;
> GetClientRect( & clientRect );
> GetDC()->FillSolidRect( & clientRect, RGB( 0, 0, 0 ) );
>
> That will blank the MFC window I'm using, fast enough for most
> purposes, and it took seconds to write.
>
> However, I think Blitz Basic has a 'Cls' keyword which is even more
> economical.
>
> In both cases, one need not waste time on issues that are irrelevant to
> programming games nowadays.
>
> - Gerry Quinn
>

You're missing the point, but in any case I understand your position.
However, the irrelevancy of such issues depends on the point of view.

Tom Plunket wrote:

> CII wrote:
>
> > > Someone wrote this in 2005. In MASM. For DOS.
> > > In 16-bit mode for the 8086.
> > >
> > > Why?
> >
> > However, what does it matter what platform or language or approach I've
> > used, as long as the method works?
>
> Well the platform and language matter considerably, considering
> that this only works on one particular bit of hardware, and in
> assembly for a platform that uses that hardware.
>

I beg to differ. If you read the explanations carefully, there aren't just
programming examples in assembly or basic given inside the notes. Those
examples happen to be incidental. The method doesn't rely on them for
nothing more than to show factually that it itself works as shown. There is
all the technical information necessary (independent from the examples) to
build the same algorithm on any platform , on any language and for any VGA
hardware, which is the real contribution of the notes.

I appreciate your comments, but the fact that this works on one particular
bit of hardware, VGA nonetheless -which most PCs have- and which is a
hardware standard on dare I say every pc video card out there, makes this
method worth the while, for those interested of course. I'm sure none of you
guys are using 320x200 at all, that's "too primitive" for state of the art
demand, so why bother? But there are some of us who use it for many
applications including academic purposes. Using VGA mode 13 would seem as
pointless as it seems pointless for some people to calculate the square root
of two time and again, but that won't stop them from doing it. That's part
of what science is.

Many haven't realized that no matter what type of video hardware is used, as
long as it provides SVGA of some sort, VGA is underneath at the bit level.
This I have observed. What this means is that VGA may be more important to
games today than one could think. As long as they (video manufacturing
companies) remain using the concept of "bit planes" to deliver video images,
VGA will be there within. This sole fact can exploited for efficiency, and
when I program games I want absolutely all the efficiency I can get, which is
in part my reason for reading newsgroups, looking for interesting information
I could learn from.

Posting a different method for so arcane a piece of hardware does nothing but
to enrich the amount of information available through here for anyone around
the world who may actually need it at some point..


>
> > If you've got a better method that you could share, I'll appreciate it
> > greatly and look into it right away.
>
> Different hardware, different techniques. On the PS2 you could
> do the same thing in less than 64 bytes more than likely, and
> it'd be considerably faster as well since on the CPU you just DMA
> those bytes to the graphics hardware.
>

I think you've missed the point.






>
> -tom!
>
> --
> There's really no reason to send a copy of your
> followup to my email address, so please don't.

CII wrote:

> > Someone wrote this in 2005. In MASM. For DOS.
> > In 16-bit mode for the 8086.
> >
> > Why?
>
> However, what does it matter what platform or language or approach I've
> used, as long as the method works?

Well the platform and language matter considerably, considering
that this only works on one particular bit of hardware, and in
assembly for a platform that uses that hardware.

> If you've got a better method that you could share, I'll appreciate it
> greatly and look into it right away.

Different hardware, different techniques. On the PS2 you could
do the same thing in less than 64 bytes more than likely, and
it'd be considerably faster as well since on the CPU you just DMA
those bytes to the graphics hardware.


-tom!

--
There's really no reason to send a copy of your
followup to my email address, so please don't.

In article <42558A57.F163C7A6@laposte.net>, x.yss@laposte.net says...
> Gerry Quinn wrote:

> > CRect clientRect;
> > GetClientRect( & clientRect );
> > GetDC()->FillSolidRect( & clientRect, RGB( 0, 0, 0 ) );
> >
> > That will blank the MFC window I'm using, fast enough for most
> > purposes, and it took seconds to write.
> >
> > However, I think Blitz Basic has a 'Cls' keyword which is even more
> > economical.
> >
> > In both cases, one need not waste time on issues that are irrelevant to
> > programming games nowadays.

> You're missing the point, but in any case I understand your position.
> However, the irrelevancy of such issues depends on the point of view.

I want to write games that people will play. In 2005, and beyond. How
is a fast assmbly VGA clear relevant?

- Gerry Quinn

In article <425591EE.B0825DAA@laposte.net>, x.yss@laposte.net says...

> Many haven't realized that no matter what type of video hardware is used, as
> long as it provides SVGA of some sort, VGA is underneath at the bit level.
> This I have observed. What this means is that VGA may be more important to
> games today than one could think. As long as they (video manufacturing
> companies) remain using the concept of "bit planes" to deliver video images,
> VGA will be there within. This sole fact can exploited for efficiency, and
> when I program games I want absolutely all the efficiency I can get, which is
> in part my reason for reading newsgroups, looking for interesting information
> I could learn from.

Are you quite sure of that? My guess would be that modern graphics
board use 32-bit pixel-based colour, and VGA is emulated.

Heck, I'm sure of it - one of the Amiga's big problems c. 1995 was that
the bit-plane graphics technology was horribly unsuited to the 3D games
genre starting with DOOM. And PC graphics cards are now built to
target exactly that genre. As a side effect, there is more than enough
power for 3D applications.

- Gerry Quinn