Re: Video Mode 13h in windows XP ... impossible?

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 02/20/04 

Date: Fri, 20 Feb 2004 12:13:38 -0000

wolfgang kern wrote:
> Beth answered da_buddha:
> [about Vmode13 PM]
>
> Beth described the 'standard way' of graphic-access
> while in protected mode, which make use of the DOS-box.
> For a beginner this is a good way to achieve first
> satisfying results.

Well, indeed; This is meant for a tutorial for schoolkids from the
sounds of what da_buddha was saying so, yeah, I was 100% thinking "cut
out the fluff so they can concentrate on just plotting pixels without
any complications"...

> For me (the speed freak) this is a detouring slow way.

Actually, running full-screen and not in a window, Windows simply gets
out of the way...you can even access the VGA registers directly for
"special effects", which work just fine...so, apparently, when
full-screen, Windows simply makes sure that the "OUT" commands pass
through to the VGA card and that the video buffer is directly
accessible and then says "do whatever you like!"...because, when
full-screen, there is no particular reason not to simply hand over the
keys to the video display...

At least, you will not suffer any more or any less "interception" and
"redirection" than you would with the VESA methods...in fact, VESA
support on Windows could very likely come from some Microsoft provided
VESA routines which may, indeed, simply redirect to the device drivers
(some cards do not come with VESA routines so Microsoft, I think,
provide this automatically with their own emulation code...much like
you don't need to run mouse driver software for a "DOS box" under
Windows because it simply "re-uses" the Windows mouse stuff and
interprets it to "INT 33h" for DOS to access it :)...

> Here is a faster method:
>
> Perform this four steps in the DOS-box only once.
>
> 1. check if your graphic card support VBE+2.0 (int10 4f..)

And what if it doesn't? Mode 13h is available on all VGA compatible
cards...VESA support isn't necessarily...and VESA themselves
recommend - due to limited space in the RAM area devoted to BIOS
code - that if the VESA BIOS is too big then only a "stub" should be
included in the BIOS and a separate _software_ program should be
provided that "hooks" the VESA BIOS routines to provide the full
support...

> 2. search for the mode13h VESA-alias 640*480,256
> in the mode-list (by features rather than VESA-number)

Well, 640 x 480 x 256 is an _SVGA_ mode, actually...

It's NOT "mode 13h", which is 320 x 200 x 256...

> 3. check if this mode can be "layed flat" (linear VRAM-space)

And what if it can't? Two sets of routines for "banked" and "linear"?

> 4. check if the V-BIOS support PM32 mode-set and start-address,
> then get the PM-entry point.

Sorry, we're NOT in protected mode under a "DOS box", so this won't
actually work directly...the Windows "DOS box" runs in _V86 mode_, NOT
PM, wolfgang...

Hence, to do what you're suggesting, you'll also need to write code to
change to protected mode...except, of course, Windows itself is
already in protected mode (code that directly changes CR0 will,
indeed, work in _real DOS_ - depending on things like HIMEM.SYS, of
course - but these programs will _fail_ under Windows because it has
set PM first and protects the OS - understandably - from the prospect
of some code trying to switch Windows back into real mode, which would
bring the entire system down)...so, this suggests using something DPMI
to get into "faux" protected mode in _co-operation_ with
Windows...which, in fact, is basically an _emulation_ via Windows, so
your "direct access" thing isn't quite what you expect...

This stuff is certainly beyond schoolkids writing some of their first
ASM code, wolfgang...heck, I'm perfectly aware of what needs to be
done and it scares the hell out of me!

_IF_ you want to take this approach (it's a valid idea...perhaps not
for schoolkids learning ASM but for other "intermediate ASMites" to
give a try ;) then I'd _STRONGLY_ suggest that you get yourself a copy
of _real DOS_...DON'T go this way for something that you always intend
to run from a "DOS box"...as it must be remembered that the Windows
"DOS box" is a _virtual machine_, NOT the real deal (even more so
under an NT-based kernel like XP, as mentioned by the OP, than Win9x
:)...it runs in _V86 mode_, NOT PM...anything that could "conflict"
with Windows normal operation is "intercepted" and basically re-routed
to the Windows device drivers behind the scenes (_including_ VESA
support, most probably...Windows need to be _100% sure_ that when it
returns to the desktop, everything is returned to normal so I'd hazard
a pretty good guess that VESA would be _intercepted_ and _re-routed_
under a "DOS box" to the Windows device drivers to make sure of that
:)...blah-blah-blah...

wolfgang's right about VESA...BUT NOT as a solution under a Windows
"DOS box"...throw Windows out of the window (boom-boom!) and go with
_real DOS_...then, yeah, exactly...use DPMI or your own PM mode
changer code to get into PM...call VESA via the PM interface it has
provided...initialise to a _SVGA_ mode like 640 x 480 x 256...and,
yup, _use every square inch of video RAM you have available_ (it's
dedicated video RAM on the video card itself, you're running under a
single-tasking OS where nothing else needs access, etc...basically, if
you ain't using that RAM to good purpose under _real DOS_ then it
ain't be used by anything else and is going to waste...hence, yeah, if
you're going with DOS + VESA then, indeed, create some massive
3200*2000 "playing area" and then just use the "display start" stuff
to do "scrolling" and all that kind of stuff...don't just
double-buffer, triple-buffer, if you have the VRAM! ;)...

Under Windows, the fastest method is direct communication with the
device drivers for such SVGA video modes and you've written the device
driver yourself too...although, note, Microsoft don't particularly
expect anyone to do this - because DirectX is the component they
provide to do that job for you - so you may encounter difficulties
with a "direct to device driver" method...VESA access from a "DOS box"
is perilous (there's actually a bug in XP's VESA support,
apparently...as well as all the other issues I've mentioned above) and
you will be unlikely to beat DirectX, anyway...this is because DirectX
does allow for "surfaces" to be "locked" and you receive a pointer
directly to that memory, which you can "MOV" pixels into to your
heart's content...the actual "flip" method - when full-screen - is a
literal change of "display start", which is no different from VESA's
method (in a window, this _is_ different...it copies the RAM
instead...but the reason for that should be obvious: When in a window,
the application is _sharing_ the display and can't do whatever it
likes without corrupting all the other applications on the screen
;)...and then there's the useful abilities under DirectX that it
automatically always works in "linear mode" (if it's actually banked
then the OS's internal "paging" mechanisms are used to transparently
change "banks" to give the appearance of "linear", even when "banked"
:)...and, of course, if you want to move beyond simple 2D "plot
pixels" stuff into exploiting the 3D accelerations on your video card,
DirectX has that stuff incorporated too...

wolfgang's right except that he shouldn't be recommending it under
Windows and "DOS boxes"...Windows is a minefield and it'll go and
"intercept" the things you're doing behind your back slowing them
down, even when you think it isn't...so, yes, if you want to use VESA
like wolfgang suggests _do so_ but NOT under Windows...use it under
_real DOS_ (or, of course, in wolfgang's case, under his own OS ;)...

> If all above questions result positive,
> you now may change Vmode without leaving PM,

A "DOS box" isn't in PM!!! It's in "V86 mode", giving the impression
that it's in "real mode" inside a Windows "virtual machine" which has
a terrible habit of "intercepting" and "re-routing" what you're doing
to its own device drivers (to be fair, it kind of _has to_ do that
because DOS boxes run in a multi-tasking environment and, for example,
you could have _two or more_ DOS boxes open at one time! ;)...

You've got yourself a little confused, I think, wolfgang..._Windows_
is in PM, of course...but "DOS boxes" are running inside a "V86
virtual machine" in order to give the DOS programs the "illusion" that
they are still running under real DOS in real-mode, when, in fact,
they aren't because Windows needs to remain in PM itself for what it
does...

The VESA suggestion _is_ good...just NOT under an XP "DOS box"...do
this stuff under _real DOS_...and, also, of course, this is also much
too complicated an idea for schoolkids to do as their first ASM
graphics programming example...everyone else can take your advice but
I don't think it's appropriate for the OP's original request as just a
"simple introduction to graphics programming in ASM" :)

> and you can direct write direct to the whole Video-memory.
> This allow much faster mode-changes and access
> to all of the V-RAM (not limited to 64/128KB aperture at 0A0000..).

Yup; On these points of the actual benefits, wolfgang is on the
money...

> For example my 8MB VRAM give me (direct and consecutive accessible)
> 27 pages of 640*480,256 that way.
> Many 'faster' games use a larger play-field (ie:3200*2400,256)
> as a permanent resident map to let you extremely fast scroll
through,
> by just altering the 'screen-start' address.

Also, most games employ "double-buffering" for animation (two screens
in RAM: one visible and one off-screen...write your graphics to the
"off-screen" and then swap the two screens around - the fastest way
being to have both screens in VRAM and then you can "flip" screens by
simply changing the "screen-start" address - so what was "off-screen"
becomes visible and what was visible becomes your new
"off-screen"...just keep writing to the "off-screen" VRAM and
"flipping" it into view and then you get smooth-looking
animation...this is the easiest way to avoid flicker if you have
"overdraw"...overdraw is where you write to a pixel more than once -
overdrawing what's already there - that if you do this 60 times a
second or more, that pixel starts flicking and flashing...with
double-buffering, you only see things once they are fully drawn so
this problem vanishes...of course, another way to solve "overdraw" is
to write your routines never to draw to the same pixel twice...but for
something like texture-mapped polygons and stuff, then you'd employ a
"z-buffer" (or "w-buffer") and draw from front-to-back (rather than
the "painter's algorithm" of back-to-front overwriting your previous
work :) so that you don't write to any pixel twice...in practice, this
is an awful lot of work - unless you're borrowing the "z-buffer"
capabilities already present in your video hardware - and it's often
_faster_ to simply blast complete polygons and "suffer" that you'll be
overwriting pixels here and there rather than constantly gain a
penalty, under software, of checking each and every single pixel
before you plot it...rather use a more general clipping method (don't
draw any backfaces, use some very basic "rectangular" clipping which
only drops a polygon when it's _fully obscured_, etc. :)...you can
actually see this in something like Quake or Half-life by finding out
the console command to ask the renderer to draw things front-to-back
not back-to-front...these games provide these rendering modes to help
map makers create maps with the least polygons but they also give an
insight into what the 3D engines are actually _really_ drawing...yup,
they draw _more_ than you see on the screen but the closer polygons
overwrite the ones further back...

> confusing? perhaps.., but isn't fast graphic the target?

No, not in this case...it's just about introducing some schoolkids to
using ASM to do some basic graphics programming...

And, no, anyway...a graphics program is about delivering the best
visuals...but, NOTE: The faster you update the screen - the higher the
"frames per second" rating - then the _smoother_ the graphics will
be...hence, _INDIRECTLY_, yes, we _want_ speed, speed, speed...there's
never any such thing as "good enough" in this respect until, one day,
computer graphics become literally totally and utterly
indistinguishable from reality (which though you might think DOOM III
looks impressive, there's _still_ an awfully long way left to go to
master that...consider accurately rendering a forest as you walk
through it with the shadows of individual leaves falling on the
reflective and also transparent surfaces of a river, while the
branches sway gently in the breeze and then walking into a city scape
with literally _thousands_ of buildings and highly reflective
skyscrapers all perfectly visible to the viewer and getting all the
millions of reflections and shadows between these things 100%
accurate...we're nowhere near this, in truth...it requires, basically,
a fully-functional real-time raytracer that handles totally irregular
objects and doesn't skimp on a single reflection or refraction or
shadow or light attenuation at all...sorry, absolutely nowhere near
this and, even with today's processors, it's still an awfully long,
long, long way to go before, finally, a computer can generate images
with such accuracy that even under a microscope with an expert, they
couldn't discern the difference between reality and the
computer-generated image :)...

> My (fastest) way is using direct hw-access,
> but this goes a bit deeper and needs hardware specific routines,
> so I can only support a few known cards that way,
> for all 'unknown' stuff I have to use VBE/VESA method.

Yeah, this method is the fastest but is effectively like re-writing
all the Windows device drivers available one by one manually...heck,
even Microsoft don't attempt that because it's much too impractical
(they get hardware manufacturers - the "local branch offices" of
Microsoft - to do all the hard work for them in maintaining their
monopoly on their behalf ;)...

And, of course, VESA is the committee of various video technology
manufacturers that got together to work out a solution to this
"standards makes code easy, small and portable - so we want that -
but, also, we don't want to be held down by standards to innovate new
ideas like 3D accelerations and stuff - so we want that too"...there
is essentially a "conflict of interest"...VGA cards are, indeed,
"portable" so that you can write VGA code - like I was showing - which
works across all video cards, no problem...this is the power of
"standards" for these things...but, at the same time, who wants to
give up having a 3D accelerated bump-mapping video card for running
DOOM III using all the dedicated hardware that makes it possible?
Exactly!

A "conflict of interest" in giving manufacturers freedom to innovate
new things as they feel like but, also, wouldn't it be nice if all the
cards were all the same - following a "standard" - so that you could
just write _one set_ of code that, yup, _directly accesses_ the
hardware in the fastest possible way?

Well, unfortunately, one gets in the way of the other..."innovation"
is about "standing out from the crowd and striking for pastures new",
while "standards" are about: "blending into the crowd, being uniform,
following the rules"...

The way that's been developed to solve this is to allow the _hardware_
to "innovate" and all be different...but that "device drivers" remain
"standard"...and this, to be fair, is actually a _reasonable_
solution...

The big problem - as I was stressing to Annie before - is not the
_idea_ of "device drivers" (for example, how else are you going to
allow completely separate programs to multi-task alongside each other
sharing the video screen otherwise? :)...

The big problem here is the crap, crap, crap, CRAP, CRAP, CRAP
_implementation_ Microsoft use: based on "friendly to beginner
graphics programmers" rather than _USEFUL_ to people who know what
they are doing...founding it in HLL practices rather than just a "as
simple as possible, as fast as possible" base...and, of course, the
biggest issues of them all: device drivers are all
_proprietary_...this is the biggest problem because it means there's
no "standard" between a Linux and a Win32 device driver...it's also a
massive problem in that Microsoft's monopoly is, basically, _entirely
based_ around the unfair advantage they have here...after all, an OS
is just software...wolfgang has written his own...there's plenty of
developers out there who could kick MS's arse in software quality -
"Sir" Bill hires _cheap_ students just out of college, focussing on
saving himself money rather than getting the best quality - and, with
"open source" a la Linux, that development "muscle" could produce
something to blow MS out of the water, in truth...the missing
ingredient is these bloody device drivers...after all, Windows
basically supports every single video card ever made with a dedicated
device driver written by the manufacturers of the card
themselves...wolfgang has to plod along one by one adding what he can
(you'd _need_ to be as rich as Big Bill simply to buy one of every
card available in order to develop and test your device driver
code...let alone going into the cost in terms of _time_ to do
this...which is basically beyond any one man or woman's lifetime)...

Hardware support is the problem here...Microsoft literally go from
strength to strength with their hardware support because it's a
slippery slope: a hardware manufacturer looks at which is the most
popular OS - oh, it's Windows - and works for that primarily because,
well, they want to sell the most units possible to, like, make money
and everything...so, they make stuff for Windows...and this emboldens
Windows even more as _the_ platform...so, the next set of hardware
manufacturers look and Windows is about the only choice they have, if
they want any chance of selling hardware to make money...so, they
develop for Windows...which makes Windows _even stronger still_...and
so on and so forth...

This kind of "unfair advantage" gains you a knighthood from the Queen,
apparently...which only goes to remind me why I've always considered
that royalty stuff to be utter nonsense...they only serve one useful
purpose: Attracting tourists to get some extra money into our
economy...but, then again, can't we just build something like the
Eiffel Tower or the Statue of Liberty instead? Or promote Stonehenge
and things like that instead (rather than - and I'm stunned by this
insane idea - building a tunnel underneath it!! Yes, those stones have
stood for thousands of years - _OLDER THAN THE PYRAMIDS OF GIZA_ - and
they want to build a road tunnel directly under them...this "won't
disturb" them, apparently...yeah, right...and, tell me, when in a few
hundred years' time, that road tunnel is old and is falling down,
Stonehenge is just supposed to fall into the hole? Like me remind
people: Unlike Stonehenge, these modern things aren't built to
last...if the tunnel underneath crumbles then it'll bring Stonehenge
down with it...they won't listen, of course...but, simply, DON'T TOUCH
IT...not even with a very long bargepole or some tunnel underneath
it...can you imagine the reaction if people proposed: "Hey, let's
build a highway that goes under the pyramids of Giza and around the
Valley of the Kings!!"...they'd rightly tell someone with that idea to
"fudge off"...well, I think, basically, there's far too many Britains
who don't actually realise what Stonehenge really is...we're not
talking medieval or King Arthur and the knights and that sort of
thing...we're talking about one of the oldest monuments in the entire
world...it's _older_ than the Pyramids at Giza! Heck, what next? A
highway that goes into one of the President's mouthes at Mount
Rushmore? Attaching a cable car to Madame Liberty's torch of Freedom
and a helter-skelter slide going around the outside of her body for
"fast access" to get back to the ground of Liberty Island? Re-using
the girders in the Eiffel tower as supports for a new raised highway?
Building "luxury apartments" on top of Ayer's rock? Actually, there's
a point...though the religion isn't around anymore - well, except for
hippies dressing up as druids (getting their historical dates
completely wrong, I might add...Stonehenge is _ANCIENT_, has no-one
any idea by just how much anymore? Even the "druids" are centuries and
centuries _too late_, you stupid hippies!!! ;) - the whole of the
Avebury area is a religious site...there's not just
Stonehenge...there's all these other standing stones and specially
carved out mounds and that kind of thing...the whole area is,
basically, just as _sacred_ as Ayer's Rock...which, rightly, the
Austrailian authorities would never dream of
touching..._literally_...it's not just an amazing tourist
money-spinner, it's a deeply religious Aboriginal site...touching it
is kind of equivalent to blowing up the Holy Lands or firing bullets
into the Church of the Nativity...oh, yeah...that reminds me: When is
Israel going to show other religions the respect that they _demand_
gets shown to them? It ain't just the Muslims...Jesus was born and
made his entire ministry in that area...and, yet, that wall they're
building stops Christians visiting their holy sites too, like the
Church of the Nativity which both Isrealis and Palestinians used as
"target practice" before, riddling the outside of it with bullet
holes...I Hope they realise that if it weren't for tolerance being one
of the highest Christian values, then this action is far, far, far
beyond having someone merely step onto sacred land...imagine the
outcry if American soldiers, under fundamentalist Christian Bush's
orders, ordered troops to blast chunks out of an equivalent temple or
mosque (to put into context, to Christians, you're talking about a
place that is the birthplace of the Son of God..._DO_ these other
religions have an equivalent? Not just a Holy place where Moses or
Mohammed once stood but where _Jehovah or Allah_ once stood...it's, in
fact, _only_ on this technicality that they are left off the hook of
immense wrath from the fundamentalist Christians: God is far bigger
than any one place that Christians look to these places as "focuses"
but don't put as much weight into them because God is everywhere and,
so, individual places aren't considered too important in the same
light...but if Christians did see things in that same light, then a
fundamentalist like Bush under Billy Graham's orders? It doesn't bear
thinking about...one Holocaust was far, far too much, indeed)...

> And Beth is right, end all your DOS-session with int10 ax=0003,
> otherwise the DOS-window may show wrong font garbage.

Actually, another great thing to do as an alternative is to use the
"save / restore video state" stuff to put the video state back to
exactly what it was before the program ran (so, if the video had been
switched to, say, 50 rows mode then it would return to that :)...this
option, though, _isn't_ available in a Windows "DOS box" because it's
buggy and doesn't work at all, thanks to Microsoft programming, of
course...you can use it as a "VGA check" (because the interrupt
service was only added with VGA cards) but, beyond that, it can't be
used in a Windows "DOS box", simply because the Microsoft support is
broken for it...

This, by the way, though, also demonstrates what I mean about how you
might _think_ you're calling a standard BIOS real-mode routine but, in
fact, Windows grabs it and "intercepts" it, re-routing to its own
device drivers...if it was the real "INT 10h" BIOS stuff then it
wouldn't fail because it'd be calling BIOS code...but, actually, it
isn't the real BIOS code at all...it's some Microsoft "emulation"
stuff as part of the "virtual machine" things it does for "DOS
boxes"...and, as the VESA support in XP is also known to have a "bug"
in it, then, actually, wolfgang, you're probably NOT getting what you
think you're getting accessing this stuff through a Windows "DOS
box"...this makes sense because the Windows desktop itself is running
in just such a SVGA mode so the BIOS VESA stuff has to be made
"compatible" with Windows' own device drivers and
desktop...basically,even without the "bug" in the support, you're not
actually using the real VESA BIOS but some Microsoft "emulation" of it
which gets redirected to its own internal stuff...

Nah, it's a simple rule of thumb: If you want "absolute most optimal
fastest possible" then _Windows shouldn't be running on the machine at
all_...basically, Windows' architecture means it stuffs itself in the
way of practically everything and MS are such "control freaks" that
nothing happens without some badly coded C routine somewhere poking
its nose in and slowing everything down...the word "optimal" - if you
mean it in its absolute sense of the very best that the hardware
you've got is ultimately capable of...total and utter zero redundency
in the system completely - then is essentially incompatible with the
word "Windows"...note, as everyone and their pet monkey insults
Microsoft, I should stress that this isn't just a "cheap insult" to
throw at Microsoft, it's a statement of _fact_...I've been programming
Windows since its 16-bit Win3.x days and, as an ASM coder, have looked
for the "loopholes"...and, generally speaking, it's the underyling
_architecture_ of Windows itself...it refuses to get out of the way
that, even when you think it's not - because of "transparency"
concepts - it actually still is getting in the way...

And, actually, one of the rare exceptions is what I was showing...when
full-screen, Windows lets you access the VGA registers and the A000
segment about as "direct" as you're ever going to get with Windows...

One alternative here, of course, is that 320 x 200 = 64KB but a VGA
card comes with 256KB RAM! You're actually loosing _three
quarters_(!!) of your video memory to support "one byte per pixel"
simplicity...it's the "chain 4" bit in the VGA registers, you
see...basically, to give the story in short, the EGA card had 4
bitplanes and it was _hard-wired_ that way...for a 256 colour mode,
you need _8_ bitplanes, not 4...they wanted the VGA, though, to be
"EGA compatible" right down to the registers...so, in fact, internally
speaking, mode 13h uses _4 bitplanes_ to render an _8 bitplane_
mode...programming this is highly confusing (using bitplanes is enough
of a pain but using the wrong amount of bitplanes? A nightmare!!
;)...so, they invented this "chain 4" thingy...when you write to the
video memory, the lower two bits of the address automatically select
the "bitplanes" to be written to...this happens in hardware and
"hides" the complexity of the "wrong amount of bitplanes" architecture
of mode 13h...the problem here, though, is those 2 lower bits are now
selecting the bitplanes and are NOT part of the actual address...you
don't need much of a mathematical mind to relate this to the fact that
you lose _three quarters_ of your available video VGA RAM(!) while
this "chain 4" thing is operating...as the lower two bits are not part
of the address then you can only address a quarter of the available
RAM (two bits: 0-3 :)...

Hence, it is possible to _quadruple_ your available RAM (so, you can
have four 320 x 200 x 256 "pages" available to this modified "mode
13h"...enough to "double buffer" and use the "screen-start" address
thingy to do the actual "flipping" between "pages"...plus, another two
"spare" screens' worth of RAM for other things :)...you can do this by
switching off the "chain 4" bit in one of the VGA registers...mind
you, the instant you do this, you are _exposed_ to the madness of
having to use not only "bitplanes" but to the bizarre, bizarre scheme
of there only being 4 bitplanes available to control what's actually
an 8 bitplane mode...the "simplicity" of "one byte per pixel" in mode
13h is _shattered_ by switching off this bit...it now goes from being
one of the simplest video modes ever devised to becoming the _most
complicated_ video mode ever devised...

On the other hand, once you get used to the madness in how to address
pixels, you are gaining yourself an extra 192KB of video RAM
available...exactly enough for something like double-buffering _and_
using two screens full of RAM to do some "infinitely scrolling
vertical playing field" trick too :)...

Or, of course, you could also twiddle the vertical resolution to 240
pixels (320 x 240 x 256) and, hey presto, you're in the famous "mode
X"...there's plenty of stuff about this on the Internet...I think it
was Abrash, in fact, who made this famous by publishing stuff about
how to do it in Dr.Dobb's...something like that, anyway...why 240
pixels? Well, a standard non-widescreen monitor is 4:3 (as are
non-widescreen TV sets, by the way :)...this is the "aspect
ratio"...if a video mode is also 4:3 (which 640 x 480, 800 x 640, 1024
x 768 and all those other video modes you may find familiar are ;),
then the "aspect ratio" of the video mode and the monitor are the
same...which basically means: _square pixels_...in 320 x 200, the
pixels aren't actually square...they are slightly taller than they
should be...if you're wondering why any of this matters then launch
non-square-pixels mode 13h and then, using an ordinary "circle"
formula, try drawing a circle...oops, it looks a bit like an ellipse!
This is, of couse, because the pixels are _taller_ than they should
be...the screen is kind of "stretched" vertically and that also
"stretches" your circle too...you can, of course, _account for this_
and delibrately draw ellipses that are slightly wider than tall (by
the exact amount of the difference in 320 x 200 to 320 x 240 "aspect
ratios" :)...on the other hand, once you've switched off the "chain 4"
bit then the reason for mode 13h only having 200 pixels vertically (if
you haven't worked it out, let me explain: 320 x 200 = 64KB...one
segment = 64KB ;) has gone, anyway, and you've got more RAM so twiddle
the vertical resolution to 240 and get yourself square pixels...then
any circular or rotational routines don't need to "account for" the
aspect ratio problem...of course, you now have _less_ than 4 pages
(3.4 pages, to be exact ;) but, hey, you only need two for "double
buffering" so this is usually okay :)...

So, there is a kind of "half-way" between mode 13h and using VESA in
manipulating the VGA registers to "tweak" a VGA video mode into
something more useful...most VGAs can handle, for example, pushing
things up to 360 or even 400 pixels horizontally while still being a
256 colour mode...so, "mode X" programming can release a little more
RAM and capabilities to your disposal...because one thing people might
not realise is that there's _nothing_ sacred in the standard BIOS
video modes like 640 x 480 x 16 or 320 x 200 x 256 at all...video
cards actually have very versatile hardware based on _timings_, in
fact, to synchronise the output they provide with the raster beam on
the monitor...the BIOS stuff is merely "standard" video modes, not the
"only" video modes your cards can handle...and this also applies to
SVGA cards as well as VGA (the problem with similarily "tweaking" SVGA
cards has to do with the fact that all SVGA cards _work
differently_...so tweaking a register on one to change the horizontal
resolution might require a completely different procedure on another
video card and so on and so forth...but, strictly, if you work
"non-portably" to just your own video card, you might be able to get
the "specifications" and work out a way to come up with your own
personal "non-standard" video mode with a funny number of pixels (1024
x 200, anyone? Really tall, skinny pixels! That would certainly look
weird ;)...you can "get away" with tweaking VGAs (up to a degree, at
least...pushing some of the higher resolutions may not synchronise
properly with certain monitors and cards ;) because VGA is all
"standardised"...

But, of course, all this stuff wolfgang and me are talking about is
not really at all appropriate to some "introduction to graphics
programming in ASM" for schoolkids...heck, I bet just plotting a
single pixel will cause unbelievable chaos and half the kids going:
"Sir! I don't understand! Why must we spell 'move' wrongly as 'mov'?"
/ "Sir! It's not working...what do you mean 'the operands go the other
way around'? What's an operand? Oh, the funny 'eax' things...why is it
backwards, sir? Can computers only read backwards or something?" /
"Sir! What's a pixel? Why are we 'plotting' them, anyway? Can't we
just move the mouse over the JPEG file and load that instead? This is
dumb!!"...and so on and so forth...if you've never tried to lead a
class full of kids before - for even the most brain-dead simplest of
tasks even - then you'll find it an eye-opener...of course, if you can
make it work and at least some of the kids get something out of it
then that's the whole point so it's worth doing this stuff...but, no,
you DON'T go anywhere near "complicated"...it honestly, in this
context, is better to approach this thinking "right, start with
something totally brain-dead and easy...then just introduce things one
by one" because, even then, you _WILL_ lose someone along the way who
wasn't listening...I mean, didn't you also kind of "ignore" teacher
while you chatted about some TV programme or something? One kid in
your class who's always "the Joker"? Some things _don't ever change_,
trust me on that...hehehe ;)...

Beth :)