Colorforth2a & QEMU RBG issues

[David Goehrig]

So I saw that Colorforth2a requires a 32bit color mode, and as such
tweaked the location where it sets the video mode in BIOS by editing
address 0x18C in a hex editor and changed it from 18 to 44 which is the
Bochs/Plex86 VGA bios specific mode for 1024x768x8888  as per:

#define VBE_OWN_MODE_1024X768X8888                       0x144

And low and behold, Colorforth is running under QEMU on a MacBook Pro
under MacOSX.... with one slight problem, R & B are swapped resulting in
Blue definitions, light blue execution, teal literals, yellow macros,
and white comments.

While I actually really like this color scheme, if any one has a good
idea on how to swap R & B I'd love to hear it  :)

--

David J. Goehrig


Email: dave@...


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

[Ray St. Marie]

Hi Dave,  Congrats! and well done!

Ray here...

On Sat, May 24, 2008 at 8:27 PM, David J. Goehrig <dave@...> wrote:

> So I saw that Colorforth2a requires a 32bit color mode, and as such tweaked
> the location where it sets the video mode in BIOS by editing address 0x18C
> in a hex editor and changed it from 18 to 44 which is the Bochs/Plex86 VGA
> bios specific mode for 1024x768x8888  as per:
>
> #define VBE_OWN_MODE_1024X768X8888                       0x144
>
> And low and behold, Colorforth is running under QEMU on a MacBook Pro under
> MacOSX.... with one slight problem, R & B are swapped resulting in Blue
> definitions, light blue execution, teal literals, yellow macros, and white
> comments.
>
> While I actually really like this color scheme, if any one has a good idea
> on how to swap R & B I'd love to hear it  :)
> --
>
> David J. Goehrig
>
>
> Email: dave@...

Dave I'm wondering what colors that "LOGO" loads. Are these colors
correct or are they also "off"?

Reason I ask is that if they too are off then they can be corrected on
block 26 ( was block 30 in previous colorForths). This might can be
used to determine just how off the colors are.

What I fear for this problem is the same fear for Nick's display
problems. These colors for the editor are hard coded in the kernel,
where the editor is defined.

We still don't know what the kernel looks like, tho we can speculate
from what we know about older colorforths and what we find in the
execution of the system.
But, speculation doesn't fix the problem.

What's needed is at least a listing of the kernel as it was run
through the assembler, or the construction files. I wonder that if we
don't have all of the files used to create and recreate this system
from scratch, maybe do to some protection ( as we appear to no longer
be working with an environment under Public Domain ) then maybe we
shall never have official copies due to that protection.

No, one has said anything either way.

I suppose dissassembly is needed. This, like most computing is still a
tad over my pay grade, but I'll get there if I have to.

Best of luck, Dave
I'll help where I can
Ray

--
Raymond St. Marie ii,
colorforthray.info

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