1. Graphics mode 257 memory address(es)
Does anyone know what memory address(es) the video data for graphics
mode 257 (640 x 480, at 256 colors) is stored at?
I would *really* love to use a virtual screen for plotting points, but I'm not
sure where to poke the data when I'm done drawing. I assume mode
257 only has one "page", even if broken up over several locations.
Help! 
2. Re: Graphics mode 257 memory address(es)
There is a small virtual screen library for handling higher resolutions with the
program "faster fill" in the (recent?) contributions at RDS's Eu page. It has
some functions that you might find useful in the include file vesa.e
Most super vga cards present their memory to the computer through a window
located
at #A0000 that is only 64k in size. When using mode #13 the amount of memory
needed for a picture is only 320 * 200 = 64000, which fits nicely in one window.
This makes it possible to peek or poke colour values as offsets with ease.
Graphics modes that use more memory than this can be accessed piecemeal by
moving
the 64k window over parts of the video ram. This can be achieved by calling the
right vesa video interrupt function with the position of the window. The
overall
operation is not trivial however, as the position value is given in granularity
units, the minimum step possible, and this value varies between cards.
So one must first call the vesa video interrupt mode information function to
retrieve pertinent information about the mode, preferably when or during setting
it. refresh(mode) from vesa.e is an example of this.
To then plot a pixel, one calculates the page/offset for the pixel
using:
mem_pos = y_pos * x_max + x_pos
page=remainder(mem_pos, 65536)
offset = floor(mem_pos, 65536)
One then sets the page with a function like set_page() and pokes the pixel at
#A0000 + offset.
Changing the page before poking the pixel is expensive and should be avoided by
keeping a variable that tracks the active page and skips the set_page step if
the
new page is already active. It is also important to reset the page to 0 before
using any Eu screen routines.
As a different approach, one could use a flat frame buffer or virtual screen in
memory, poking colour values directly into offsets and when finished copying the
entire virtual screen to the display using procedures like splat_screen(). This
may seem easier, and a snappy display is preferable sometimes. Overall though,
the process is slower than the previous one due to the relatively expensive
process of copying the entire picture in such an inefficient manner.
Other methods exist which overcome many of these limitations but I believe they
would be somewhat trickier in the world of Eu. I believe there exist much more
comprehensive graphics librarys that can manage true colour, sprites and more,
for
instance Pete Eberlein's neil.e as a good complete example, but in general such
librarys are large and complicated beasts, unweildy in small applications.
I hope I havn't forgotten too much, and I wont be held responsible for major
causeway crashes if I did B^) Give it a try anyway, don't hesitate to ask more
questions....
Cheers,
Nick
Roderick Jackson wrote:
> Does anyone know what memory address(es) the video data for graphics
> mode 257 (640 x 480, at 256 colors) is stored at?
>
> I would *really* love to use a virtual screen for plotting points, but I'm not
> sure where to poke the data when I'm done drawing. I assume mode
> 257 only has one "page", even if broken up over several locations.
>
> Help!
3. Re: Graphics mode 257 memory address(es)
>From: Nick[SMTP:metcalfn at ALPHALINK.COM.AU]
>Sent: Monday, April 05, 1999 2:43 PM
>
>There is a small virtual screen library for handling higher resolutions with
>the
>program "faster fill" in the (recent?) contributions at RDS's Eu page. It has
>some functions that you might find useful in the include file vesa.e
>
>Most super vga cards present their memory to the computer through a window
>located
>at #A0000 that is only 64k in size. When using mode #13 the amount of memory
>needed for a picture is only 320 * 200 = 64000, which fits nicely in one
>window.
>This makes it possible to peek or poke colour values as offsets with ease.
>Graphics modes that use more memory than this can be accessed piecemeal by
>moving
>the 64k window over parts of the video ram. This can be achieved by calling
>the
>right vesa video interrupt function with the position of the window. The
>overall
>operation is not trivial however, as the position value is given in granularity
>units, the minimum step possible, and this value varies between cards.
<snip>
Thanks, Nick. That was just what I was looking for. I had
thought there might be an easy, universal, fast method to it.
But it looks like I'll be better off just sticking with mode 19
for what I'm doing. Ah, well... I'll still try out your code
though, since eventually I'll come back to it--and I'll look
into the other packages too, maybe make a higher-resolution
variant for 500MHz+ CPUs. 
Rod Jackson
4. Re: Graphics mode 257 memory address(es)
Or he could just use Neil, and have the benefit of command lists using 100%
machine code, without him having to worry about
anything.
I am confused, how little graphics demo's and game's use Neil. I assume most
download all graphics libraries for Euphoria, so
either half of the list are [.....], or they didn't understand it at all. Few
demo's would be better of with the simplicity of
specific hack to the VESA interface...
And no, I didn't write Neil. But that's really not the point. It seems are
re-inventing all wheels already available for
Euphoria.
Consider my EDOM, with Gabriel Boehme's binary print & get, there is no reason
to even keep a copy of my EDOM routines, since
his, almost do the same, but are a lot cleaner, faster, etc. That's logical and
makes sense. I wouldn't suggest any one now to
use those old bloated routines.
Maybe we ought to make a package full of Euphoria libraries, the best of each
section. (graphics-interface, win32 support,
graphics-drawing/imaging, spell-checkers, database, etc. I mean its not about
opinions, or anything, in each section one library
really is better.
Ralf
5. Re: Graphics mode 257 memory address(es)
Ralf wrote:
> Or he could just use Neil, and have the benefit of command lists using
> 100% machine code, without him having to worry about
> anything.
> I am confused, how little graphics demo's and game's use Neil. I assume
> most download all graphics libraries for Euphoria, so
> either half of the list are [.....], or they didn't understand it at
> all. Few demo's would be better of with the simplicity of
> specific hack to the VESA interface...
Neil does infact provide an easy interface to the flat address space of
most video cards. It's just not documented very well. I've created a
simple demo to show how to access the linear frame buffer in VESA modes...
gfx_mode simply sets the global variable "video_mem" with the address and
you can peek or poke to it to your hearts content. It also sets the
global variable "bytes_per_line" so you know the virtual width of the
display memory. Do not assume bytes_per_line will be the same as
SCREEN_W.
The demo and updated Neil.e are available at my web page.
_______ ______ _______ ______
[ _ \[ _ ][ _ _ ][ _ ]
[/| [_] |[/| [_\][/ | | \][/| [_\]
| ___/ | _] | | | _]
[\| [/] [\| [_/] [\| |/] [\| [_/]
[_____] [______] [_____] [______]
xseal at harborside.com ICQ:13466657
http://www.harborside.com/home/x/xseal/euphoria/
6. Re: Graphics mode 257 memory address(es)
I have no argument that Neil is the best graphics engine implementation I have
seen for Eu, capable of most things. It may not suit
everybody, though, for several reasons.
First is the bulk of such a library. If I have a small demo that requires a
virtual screen and I want to send it to the list for
evaluation by all you out there, I'm sure most would prefer it to be as small as
possible. This can also be significant during
downloads when one has a service provider as crappy as mine :)
Second is the inflexibility of the library, given by the very machine code
routines that make it so fast. Any modifications to fit
a specific purpose usually mean begging off to the author. Pete is a clever
programmer, and his code embodies concepts and
techniques whith which a user may not have enough familiarity to change. This
goes for any such library that attempts to reach
beyond Eu for the hardware.
Third is the educational value of plugging in a ready made library. Of course,
everybody's got a different agenda, and a ready
rolled high performance option should be made available, but nothing makes a
concept clear like doing it yourself.
Anyway, simply pointing out a graphics library to use isn't really answering the
question, is it?
I do agree that the available Eu libraries should be classified into groups, but
the defenition of 'best' from the user's point of
view might vary considerably. Perhaps a classification more like 'beginner'
'intermediate' and 'advanced' would be more
appropriate, with beginner being 'example code', pure easy Eu where possible,
intermediate having hairy programming concepts or
calls to hardware, and advanced having assembler or mission-critical code.
One could then look to 'beginner' to learn how it's done, 'intermediate' to see
how others did it, or to 'advanced' for high
performance plug ins.
Just a thought....
Nick.
Ralf Nieuwenhuijsen wrote:
> Or he could just use Neil, and have the benefit of command lists using 100%
> machine code, without him having to worry about
> anything.
> I am confused, how little graphics demo's and game's use Neil. I assume most
> download all graphics libraries for Euphoria, so
> either half of the list are [.....], or they didn't understand it at all. Few
> demo's would be better of with the simplicity of
> specific hack to the VESA interface...
>
> And no, I didn't write Neil. But that's really not the point. It seems are
> re-inventing all wheels already available for
> Euphoria.
> Consider my EDOM, with Gabriel Boehme's binary print & get, there is no reason
> to even keep a copy of my EDOM routines, since
> his, almost do the same, but are a lot cleaner, faster, etc. That's logical
> and makes sense. I wouldn't suggest any one now to
> use those old bloated routines.
>
> Maybe we ought to make a package full of Euphoria libraries, the best of each
> section. (graphics-interface, win32 support,
> graphics-drawing/imaging, spell-checkers, database, etc. I mean its not about
> opinions, or anything, in each section one library
> really is better.
>
> Ralf
7. Re: Graphics mode 257 memory address(es)
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Apr 06, 1999
-
Last edited Apr 07, 1999
> First is the bulk of such a library. If I have a small demo that requires a
> virtual screen and I want to send it to the list
for
> evaluation by all you out there, I'm sure most would prefer it to be as small
> as possible. This can also be significant
during
> downloads when one has a service provider as crappy as mine :)
I agree, its quite a large library, that is, for an Euphoria library. But are
Euphoria libraries, by definition, not very small
?
But ok, its a huge library.
> Second is the inflexibility of the library, given by the very machine code
> routines that make it so fast. Any modifications
to fit
> a specific purpose usually mean begging off to the author. Pete is a clever
> programmer, and his code embodies concepts and
> techniques whith which a user may not have enough familiarity to change. This
> goes for any such library that attempts to
reach
> beyond Eu for the hardware.
Not true. First of all, most 'pointers' it gives you, are also machine addreses,
you can acces, peek & poke as much as you like.
Secondly, it is based upon the command list principle. First introduced by
Micheal Bolin, although Pete uses a much more
effective approach (if you want to alter it often).
Just wondering, what kind of flexibility are you talking about ? Being able to
write a demo that would work with any video mode,
using any color depth ? Since, that is pretty much what it offers. What else
would you want to be able to do ? (that can not be
achieved at the most efficient way, using the commands it provides)
> Third is the educational value of plugging in a ready made library. Of
> course, everybody's got a different agenda, and a
ready
> rolled high performance option should be made available, but nothing makes a
> concept clear like doing it yourself.
>
> Anyway, simply pointing out a graphics library to use isn't really answering
> the question, is it?
'cuse me. Knowing the video memory addres, is as much educational, as knowing
the multiply tables upto 100 by heart.
Hacking the vesa interface has got nothing to do with concepts, its just a silly
technical trick. Virtual screen's, sprites,
etc. are real concepts.
And those are the concepts one needs. And playing with those is by all means a
good thing. But do you seriously smash down a
nail into wood with your hand, for educational purposes, rather than using a
hammer.
> I do agree that the available Eu libraries should be classified into groups,
> but the defenition of 'best' from the user's
point of
> view might vary considerably. Perhaps a classification more like 'beginner'
> 'intermediate' and 'advanced' would be more
> appropriate, with beginner being 'example code', pure easy Eu where possible,
> intermediate having hairy programming concepts
or
> calls to hardware, and advanced having assembler or mission-critical code.
For of all, I agree, it hard to tell which one is 'best' .. but one if always
'better' than others.
Requirements for being the 'best' (in right order)..
-- a library offers something other libraries don't (crucial, the scope of
the tool)
If it doesn't ...
-- is it faster/smaller/cleaner .. ('performace' comparisment)
Say, take my old EDOM and Gabriel's binary print & get.
Both libraries kind of do the same, only his is faster, and smaller. Mine is
thus redunant and not needed.
> One could then look to 'beginner' to learn how it's done, 'intermediate' to
> see how others did it, or to 'advanced' for high
> performance plug ins.
Isn't this what example programs are for ?
Ralf N. -- Oh well, enough about Neil for one day. What do you all think
about Jaques Deschenes (I always have trouble
spelling his name) GUI-designer based on David's early attempt. Quite a neat
tool, especially considering it is written for and
using win32lib. (so the look should be consistent)
8. Re: Graphics mode 257 memory address(es)
Ralf Nieuwenhuijsen wrote:
> > Second is the inflexibility of the library, given by the very machine code
> > routines that make it so fast. Any modifications
> to fit
> > a specific purpose usually mean begging off to the author. Pete is a clever
> > programmer, and his code embodies concepts and
> > techniques whith which a user may not have enough familiarity to change.
> > This goes for any such library that attempts to
> reach
> > beyond Eu for the hardware.
>
> Not true. First of all, most 'pointers' it gives you, are also machine
> addreses, you can acces, peek & poke as much as you like.
> Secondly, it is based upon the command list principle. First introduced by
> Micheal Bolin, although Pete uses a much more effective
> approach (if you want to alter it often).
> Just wondering, what kind of flexibility are you talking about ? Being able to
> write a demo that would work with any video mode,
> using any color depth ? Since, that is pretty much what it offers. What else
> would you want to be able to do ? (that can not be
> achieved at the most efficient way, using the commands it provides)
>
Well, by flexibility I mean accessibility. When I was starting in Euphoria the
way I learnt how things worked was to look at the
code. To achieve my goals, often code would need to be tweaked or rewritten
entirely. The Neil library is very capable, and from
the outside provides much of the functionality an experienced user could ask
for, but I can't imagine what I would have made of it
back then... :) Sure, it probably would not need to see the programmer's hand,
but what if....
Of course it all depends on one's perspective. I like to keep things simple and
concise, and as compact and fast as feasable. To
this end, I sometimes make includes specific to programs with any modifications
thus isolated. It also helps me to understand
what's really going on.
> > Third is the educational value of plugging in a ready made library. Of
> > course, everybody's got a different agenda, and a
> ready
> > rolled high performance option should be made available, but nothing makes a
> > concept clear like doing it yourself.
> >
> > Anyway, simply pointing out a graphics library to use isn't really answering
> > the question, is it?
>
> 'cuse me. Knowing the video memory addres, is as much educational, as knowing
> the multiply tables upto 100 by heart.
Wether you know it off the top of your head or spend hours finding it in a book,
it is still important to know why it's there and
what it's good for surely? I have a friend who says he did not do well at maths
in school because he used to think he was meant to
understand the formulas or tecniques he was told to use. He would not accept
that one simply plugs in numbers and follows specific
steps for a solution. He sought the deeper meaning, and in doing so, failed
quite miserably. This led him to assume he was
mathematically inept, a shame for a clever mind. My point is that one may
understand a concept better by being aware of it's
fundamentals, for some people it's the only way. I'm much the same myself.
> Hacking the vesa interface has got nothing to do with concepts, its just a
> silly technical trick. Virtual screen's, sprites,
> etc. are real concepts.
> And those are the concepts one needs. And playing with those is by all means a
> good thing. But do you seriously smash down a
> nail into wood with your hand, for educational purposes, rather than using a
> hammer.
I don't believe I suggested that one hacks it themself, it was difficult enough
for me. I remember asking myself the very same
question at one time, when I wanted to write to the screen directly. I think I
ended up driving in that nail with my forehead. Well,
at one time Neil.e did not exist and I needed a solution of my own. The
routines I indicated are an easily digestible example of
addressing the screen directly, not necessarily a solution (although they
comprise a limited one). I simply condensed my own
experience, based on the question asked. I believe I mentioned there were
better methods than mine in the original post. It's
really up to the individual to decide what suits, direct screen writes or
virtual screens, and what library to use.
I do not use Neil in my own applications, even granted it's power, because I
have some special functions that might become tricky to
implement. I do not know enough about Neil to incorporate them smoothly,
although that might change soon.
Anyway, to wind up I'm not knocking Neil in any way, in fact I think it is very
impressive and most capable. I'm not disagreeing
with you either, Ralf, virtual screens and sprites are the meat in the sandwich,
but I didn't think that was what the original
question was about.
> > I do agree that the available Eu libraries should be classified into groups,
> > but the defenition of 'best' from the user's
> point of
> > view might vary considerably. Perhaps a classification more like 'beginner'
> > 'intermediate' and 'advanced' would be more
> > appropriate, with beginner being 'example code', pure easy Eu where
> > possible, intermediate having hairy programming concepts
> or
> > calls to hardware, and advanced having assembler or mission-critical code.
>
> For of all, I agree, it hard to tell which one is 'best' .. but one if always
> 'better' than others.
>
> Requirements for being the 'best' (in right order)..
> -- a library offers something other libraries don't (crucial, the scope of
> the tool)
>
> If it doesn't ...
> -- is it faster/smaller/cleaner .. ('performace' comparisment)
>
> Say, take my old EDOM and Gabriel's binary print & get.
> Both libraries kind of do the same, only his is faster, and smaller. Mine is
> thus redunant and not needed.
If both the librarys perform identical functions, then indeed it becomes
confusing to keep the inferior library hanging around.
More often this is not the case, simalar librarys each have their own merit.
Once again, the choice is with the user as to what
suits best, or to make their own if none suit.
> > One could then look to 'beginner' to learn how it's done, 'intermediate' to
> > see how others did it, or to 'advanced' for high
> > performance plug ins.
>
> Isn't this what example programs are for ?
Example programs show what a library does, more often than not it is assumed you
already know why and don't really want to know
how. For a beginner this can make for slow progress figuring out how to do
something that isn't exactly what the library was
written for. If the simpler but more instructive librarys were tagged as
beginners librarys this process could be made easier. The
more good relevant reference material one can find the easier it is to
understand and conquer a specific problem, no matter what the
functional quality of the example may be.
> Ralf N. -- Oh well, enough about Neil for one day. What do you all
> think about Jaques Deschenes (I always have trouble
> spelling his name) GUI-designer based on David's early attempt. Quite a neat
> tool, especially considering it is written for and
> using win32lib. (so the look should be consistent)
Hehe I do not have Eu for W as of yet. This also will change soon.
Cheers all,
Nick
