[colorforth] Seeing the Vesa mode on start-up/changeing same.

["Ray St. Marie" <ray.stmarie@xxxxxxxxx>]

Hi colorForth fans
Ray here...


I've been offline a couple of weeks... recent blog entry about that at
http://colorforth.net
I've been busy in my offline time working with a couple of colorForths
and a few of  the problems that I've seen pop up recently in this
mailinglist. One of the things that I've included lately is a way to
use LOGO as a debugging tool. Also, I've created a couple words to aid
in the display debugging process. Nick, I was thinking of you. :-)


What you do is....

Add the words

vesa @ h.

just after the word text and before the word cf in the word LOGO.

vesa :== yellow, the rest are green.


: logo show black screen ( or "blank" if defined like in 2.0a) 800 710
blue box 600 50 at 1024 620 red box 200 100 at 700 500 green box text
"vesa" @ h. cf keyboard.

To add it to the disk will be discussed here in a bit.  There is
another, similar way to go about this in other colorForths, as the
variable vesa may not be exposed or defined in other colorForths. In
that case, a listing of the program gives you the address of where the
vesa variable information is stored. In some cases the listing is the
only place that the variable can be found as the image writes itself
to 0 (7c00) after boot and writes over this value, not needing it any
more because the display is already engaged during the boot process. (
I could be wrong about that, btw. )

Nick found a variable in colorForth that he could manipulate by hand,
and I think he did this with a Hex Editor on the source. Nick? do you
recall that?

So, now when you boot, you should see the value in hex at the top of
the screen, just as in at least two cases that I was able to test
here.
I have a monitor, it is an ega/vga model from 1998 and I can boot
several colorforths on it.
In a "0 dump u" or in other words an address zero dump followed by
dump's up command, reveals the value at address 0x15h is 0x10cd4117h,
which is the vesa value for this particular copy of '05 that I happen
to have loaded in one of the twin Pentium 1's.

What I recall about what Nick had done was that if you do a "15 @"
(set phasers to stun and the keyboard to hex because 15 is a hex
value)  you may be able to read that value. I think that I might have
found "17 @" for another version of colorForth and I'm looking for
that now as I proceed in testing this idea.

Instead of adding "vesa @ h." to logo, you may have to enter (hex) 15
@ h. , or similar for 17 @ h. .

Just now looking at Howerd Oakford's cfDos4 and it's at 0x1bh so (hex)
1b @ h. in that case.

Looking at an Appelman Small Fonts and the value is split between the
2 least significan bits of address 0x17h and the 2 most significant of
the address 0x16h.  some sort of character fetch is in order here an
may need to be defined in the macros. Look thru your bootable version
of colorForth or at htmlized sources and you will find definitions 1@
and 1! or similar that do this operation.

Okay... the value of being able to SEE this vesa value when logo
displays is that in some cases the display is properly booted but some
of the words that define icons sizes and screen sizes are out of wack
and make the display look as if everything is twice as big. Nick has
mentioned this in a previous post.

I was able to display the vesa value on the top of the screen in a
2.0a version that had otherwise been distorted. In one case I had set
the vesa value to 10cd4118, in which I got a screen that was otherwise
unreadable, grey in color, looked vertically striped and DID display
the Hex value of vesa properly in the top right corner. Infact it
displayed it 3 times across the screen. It could be that the display
is shifted over to the right way too far, as I've expereanced this
problem in the past when I was displaying 'line' and 'box' created
objects on the screen. Moveing the object too far left or down crashes
colorForth. Moving the object too far right just displays the object (
i'm making an educated guess here) a pixel downward as if it had
wrapped from the left being way too far on the right.

I then reset this value to 10cd4117 and got another display all
together. In this case I think I recreated what Nick had done. I could
read the Hex value, but now I could see colorForth double size taking
up much of the top of the screen area and in the wrong colors. The
boxes had also displayed, but it was obvious that the display could
not create them properly, most likely due to sizeing issues and maybe
even colors encoding. This I must still explore.

I do recall that when I changed Terry Loveall's version of colorForth
back from 800x600 to 1024x768, there were many adjustments that
involved sizes of margins, right and left, and of character sizes in
the emit and 2emit words of the kernal, amonst other adjustments that
don't currently come to mind. This is discussed in the report I did a
few years back in the mailinglist under the topic "how I got
colorforth to boot".
 Trying the value 4123 in place ( the ati definition on block 52
Floppy Driver stuff ) and I got entirely no display at all. Reminding
you, this is all in the 2.0a version, trying to boot it in one of my
pentium ones. It works fine in windows on the pentium 4 I normally
run, native too.

There is a word I defined, 'p', because it is the top left of the
keyboard, representing the top-left of the display.

: p "10cd0000" + "vesa" !  ;

In Windows, this definition goes just under the "mark empty" and I did
switch off the qwerty keyboard by using the change 'c' key in the
editor keyboard which changed the word qwerty from green to a white
comment. This way, I could navigate the keyboard blindly, should I not
get a good "vesa" number entered on reboot using the original
colorForth keyboards, which I happen to be very familure with.

Don't forget to save if you change the vesa value.  In other
colorForths you just use the address like the hex address 0x15h, used
above.

TIP: n n n spacebar n n n spacebar n n n spacebar will guaranty that
you are at the outer interpreter accept keyboard from any keyboard you
may have navigated to previously. /TIP

Knowing that spacebar alt will enter the hex keyboard, you can type in
the new hex value's last four digits, such as 4117, and then hit the
spacebar, followed by 'p', the top left key, followed by spacebar
followed by 'save' spacebar, and when the light goes out, 'boot'
spacebar... and you have your testing method in blind-no-display mode.
One may have to rehearse this in a working colorforth or just write
down the keys for save ( ;a/e) and boot ( mssk) . A list of modes to
test would be nice to have and I will search for such soon to be
placed at the doc's-wiki at http://ForthWorks/c4th .


From what I can find out, I believe that in the case of some monitors
the value 4117 is the working value.
This is a problem for colorForth 2.0a at this time, as the rest of the
definitions for changing screen sizes and colors are not available,
not easily accessable to my knowladge, not well discribed anywhere at
this time. A conversion of the sourcecode from hex to a listing may be
necessary to find these values. The system does seem to be optimized
to operate under two modes, Nvidia 4118, and ati 4123, as you can see
if you look at block 52. You'll need to load block 52 to access these
values to change display settings. This is the reason for my 'p'
definition, as no loading is necessary between boots. you COULD add 52
load in yellow to the top of the block 18 just for these tests, and
also create a 4117 version of the code to block 52. This way you can
just type the words that change the code automatically. Save, re-boot.

It may be interesting to note that in the case of the 4117 test, I
also tested '0 dump'.
This worked, but of course, I was not able to see the bottom of the
screen. No keyboard, only the topmost dump doublewords. This is
actually a workable condition, as dump can be used to display any
address you want to the top of the screen. It's just a matter of
adding an offset of 8 or -8 in many cases. Instead of 0 dump, try -8
dump.
Be careful trying this in Windows as it has areas of memory you CAN
NOT access, due to windows restrictions. Jump around and see what you
can dump. You can dump anything from block 18 on, and in some cases
you can dump stuff before block 18 in colorForth for windows, by Roman
Pavlyuk.

This can help to see the vesa value. It can also be used for exploring
the dump output on an otherwise unreadable display. I suppose it could
be used to help identify the other display settings as well, in a
pinch, if you can't do anything else.

Stay tuned... I'm hoping others will jump in and tell us where and
what to do about these problems. I'm still searching.


In other news, Chuckbot now has a zoom feature under development. It's
starting to look good. I can go easily from a total world display to a
zoom-in of the top-left quadrent currently. This is accomplished by
having two copies of the necessary data that can empty and start each
other when the zoom key is hit on the Chuckbot keyboard, compiling so
fast that one never notices. Care is taken so that in-world data is
not affected by the re-compile.

I imagine the other three quadrents will be addressed similarly, but
the boon to this idea is that just about any world configuration, even
levels of Chuckbot World, can be easily created. This works much like
configuration files. Copy this block that has the proper info and just
change what needs to be changed, walla!

I'm going to try to get Chuckbot to execute a zoom when he gets to the
edge of one quadrent and right before he enters the next.

Okay, that's it for now. More to follow.
Ray

-- 
Raymond St. Marie ii,
http://colorforthray.info
http://colorForth.net
http://ForthWorks.com/c4th

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com