Fast Clear VGA mode 13 screen with 16000 byte loop

In article <1116355500.801321.254090@g14g2000cwa.googlegroups .com>,
MobyGamer@gmail.com says...
> Tom Plunket wrote:
> > > Even the most basic 3D cards have additive plotting (for
> > > transparency), and any card made after 1999 has anti-aliasing.
> > > Stop speculating and start reading.
> >
> > That's very useful information for applications looking to run on
> > computers that were made before 1999.
>
> Nobody says you have to use the HAL. D3D has had software rendering
> since it was introduced. You write for D3D, then cards with hardware
> acceleration will use it, and cards without, won't.

Except that I'm already doing software rendering, the way I want it.

To be fair, it might be that something with additive blending would
work on modern cards, though I have a suspicion that not all
cards/drivers would listen to one's demand for accurate sub-pixel
polygons.

- Gerry Quinn

CII wrote:

> Where mode x requires object memory set in a particular fashion, I can
> have the advantages of "linearity" with "mode 13" and still use the
> "fast draw" (or fast blit) of the technique in question.

Hmm, I'm not convinced. If you're loading graphics into any area
outside of the first 64K of VRAM you cannot use a linear method. You
would need to load each plane of data in one at a time, ala Mode-X.

Because the
> "fast clear" technique implicitely allows me to access a full 256K
> memory without bank switching -and even all video memory if the bus is
> handled correctly, I have the same benefits of "mode x" as well
> (scrolling - buffering..) while staying right in mode 13, which is the
> beauty of it.

Again, this sounds like nonsense. You can't ever have access to the
full 256K of VRAM directly on a VGA. And there is no banking mechanism.
All you ever have is one 64K window in PC memory space starting at
A000:0000, which depending on which planes are enabled maps through to
between none and four 64K planes. Because of this it simply isn't
possible to (AFAIK) write to/read from any more than 64K of VRAM with a
linear mode set up. This then precludes the use of hardware double
buffering and hardware scrolling without using Mode-X techniques.

So could you explain please? I haven't had time to look in detail at
your code yet, but I suspect it isn't doing what you say it is. For
one, I'd just love you to try and explain to me how to hardware double
buffering combined with hardware scrolling *without* using Mode-X as you
claim.

> When I spoke about my observations regarding modern cards note that I
> didn't mention "4 bit planes". Any number of planes could be employed
> and still "simulate" 4. They do however use bit planes still, each one
> of them being a ram bank as far as I know.

Well..whatever. My own feeling is that a modern card will be designed
to make maxium use of the memory bandwidth availble and that method may
not always have a 1:1 correlation to the simple VGA 4 ram bank hardware
setup. Either way, as stated previously the GPU will always completely
blow away whatever you can do across the bus filling or blitting wise.

> When one considers
> the way the SVGA and 3D GPU registers are used during their programming,
> their access and so forth, one is left with the impression that the VGA
> concept lies within because of the implicit theory of operation that is
> applied.

If you're suggesting that because one still programs a graphics card
through the use of registers (actually memory mapped thesedays) then
that is also nonsense. All devices are programmed through registers of
some sort. If that's not what you're suggesting then spit it out,
because your answer was somewhat vague.

> It is possible that only if two parallel video subsystems
> existed, one independent of each other, one for VGA and another one for
> "acceleration", only then would the VGA be absolutely separated from any
> "emulated" subsystem. That is a theory nothing more, but it does seem
> to make sense at least from a designer's point of view.

As the complexity of a VGA core is so low compared to the monster GPU
hardware it probably only takes up a tiny fraction of the available die
space. It wouldnt surprise me if you could just buy a clone VGA design
as intellecual property as a CAD part and just drop it into your circuit
design. (I'm not a hardware engineer so I don't know the correct
terminolgy) The key point here is how you decide to implement it. The
designer is going to implement it with the least hassle and cost seeing
as it's only provided for compatibility nowadays. Performance is not
even going to figure on the designer's list of things he want's to
achieve from it. Hell I wouldnt even say they'd be all that fussed
about it having a great degree of register compatibility except for the
CRTC registers which are pretty critical.

> The response times when reading or writing to VGA registers and new SVGA
> 3D registers are minor clues, but they are clues still. They can hint
> to which of the registers is electronically tied "deeper" in a sense.

You're making a bit of a leap there me thinks. Do you have any data
you'd like to share with us on this?

Regards,
Graham

Graham Donaldson wrote:
> Again, this sounds like nonsense. You can't ever have access to the
> full 256K of VRAM directly on a VGA. And there is no banking
mechanism.

Well... it depends on the card. Any card that supports VESA 2.0 or
higher in the onboard BIOS can indeed give you a linear view of the
entire framebuffer. This requires protected mode, of course.

> I'd just love you to try and explain to me how to hardware double
> buffering combined with hardware scrolling *without* using Mode-X as
you
> claim.

Please stop trying to get him to explain his code/motivations/etc.
It's starting to hurt my brain ;-) He is defending his code as useful
in modern environments, which is simply false. What he should have
done from the beginning is to simply say "Hey, here's some code that
may be valuable to anyone developing for older machines and/or embedded
systems!" and none of this crappy thread would ever have happened.

> > When I spoke about my observations regarding modern cards note that
I
> > didn't mention "4 bit planes". Any number of planes could be
employed
> > and still "simulate" 4. They do however use bit planes still, each
one
> > of them being a ram bank as far as I know.

He is speculating, and also wrong.

> My own feeling is that a modern card will be designed
> to make maxium use of the memory bandwidth availble and that method
may
> not always have a 1:1 correlation to the simple VGA 4 ram bank
hardware
> setup. Either way, as stated previously the GPU will always
completely
> blow away whatever you can do across the bus filling or blitting
wise.

You are absolutely correct. GPUs can do 128-bit fills, for example,
without any intervention from the CPU. This is faster than anything
else you can attempt, because 1. it avoid tying up the CPU, leaving it
free for other stuff, and 2. no data is transferred across the bus.

> > The response times when reading or writing to VGA registers and new
SVGA
> > 3D registers are minor clues, but they are clues still. They can
hint
> > to which of the registers is electronically tied "deeper" in a
sense.
>
> You're making a bit of a leap there me thinks. Do you have any data
> you'd like to share with us on this?

Of course not! Please ignore him :-)

Trixter wrote:
> Well... it depends on the card. Any card that supports VESA 2.0 or
> higher in the onboard BIOS can indeed give you a linear view of the
> entire framebuffer. This requires protected mode, of course.

To explain - for the purposes of this discussion with CII I was limiting
the context to a true-blue 256K VGA. No bank switching, no linear frame
buffer etc, these are all features of SuperVGAs. Otherwise you could
indeed do many things that CII is claiming, but then his code would be
relevant to SuperVGA's not VGA. And as you point out, LFB would require
protected mode.

That might seem slightly anal, but it's an important distinction in a
discussion where we were talking about what was possible with VGA's back
in the day.

> Please stop trying to get him to explain his code/motivations/etc.
> It's starting to hurt my brain ;-)

Aww - it's fun.

Graham.