Subject: Re: Accessing hardware -- nasm and gcc
From: [email-masked] (Tijs Michels)

14 Mar 1998 07:42:44 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
To: Benjamin Riefenstahl <[email-masked]>
Cc: [email-masked]

Hi Ben,

Thank you very much for your reply: most informative!

I'm going to look at your suggestions. That might take a while.
However, your mail made me realize that my original posting was, at
times, not precise enough. I should have included in my original
posting what the sample program was supposed to do. Here it is: I
run Bash either in Rxvt or in a *full screen mode* from the
command.com prompt. By default command.com returns dark white
characters on a black background (07). I don't like that, so I have
hacked command.com to return bright white characters on a *dark*
blue background (1F). However, I would like to have bright white
characters on a *bright* blue background. This is no longer possible
by hacking command.com. For when I replace 1F by 9F, the background
is not bright blue, but blinking dark blue. So I stick to dark blue
(1F) and simply change VGA color 1 from dark blue (00_00_1F) to
bright blue (00_00_3F). Et voila.

Now from the command.com prompt these registers can be changed very 
easy with the program presented earlier (assemble as a classic .com 
program):

MOV DX,3C8h ; Port 3C8h to switch to PEL Address Write Mode.
MOV AL,01h  ; By default palette register 01h is mapped to
OUT DX,AL   ; PEL data register 01h. So to change the color
INC DX      ; of attribute 1.h address PEL data register 01h.
XOR AL,AL   ; To compose a color set the intensity of red,
OUT DX,AL   ; green, and blue on a scale from 0h to 3Fh (63).
OUT DX,AL   ; Bright blue (00_00_FFh) corresponds to 00_00_
MOV AL,3Fh  ; 3Fh.
OUT DX,AL   ;

MOV AH,4Ch
INT 21h

However, once in Bash, I obviously can no longer use this .com 
program. So I decided to try to write an .exe program which could do 
the same in the 32 bits Bash environment. So far to no avail.

Given that all of this pertains to **full screen text modes** (mode
3 or VESA mode 108h), I doubt the video driver is making life hard on
me. Why would a Win95 driver trap ports designed for accessing
registers which Win95 programs using a GUI would never want to access
directly?

I will give it another shot, using your suggestions and those on:

http://www.geocities.com/SiliconValley/Heights/7394/

You wondered whether I was doing this as a hobby. I sure am. The 
PhD thesis I'm currently writing has absolutely nothing to do with 
accessing hardware.

Thanks again for you informative reply.
Best wishes,

Tijs
[email-masked]
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".