From: M DOT H DOT M DOT Michels AT kub DOT nl (Tijs Michels)
Subject: Accessing hardware -- nasm and gcc
11 Mar 1998 21:19:07 -0800
Message-ID: <199803111122.MAA21506.cygnus.gnu-win32@mailnews.kub.nl>
Reply-To: M DOT H DOT M DOT Michels AT kub DOT nl
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
To: "Paul Garceau" <pgarceau AT submergedsoftware DOT com>
Cc: gnu-win32 AT cygnus DOT com

Dear Paul,

20-11-1997 you wrote:

> Under Win95, the programmer can directly access any and
> all hardware without any sort of special case scenarios
> outside of those required to understand (programmatically
> speaking) the hardware in question (things such as h/w
> specs available with a Video Card). Under NT this is not
> the case.

Could you please point me to some docs on how to access hardware 
under Win95 using Cygwin32, or better still, to some examples?

Back in the DOS years I used to code all my programs in pure 
assembly. That was great for accessing hardware. Now that I've 
upgraded to the Win95\Cygwin32 platform writing to a port or issuing 
a simple interrupt seems impossible. I tried the following approach.

I have a simple .c file mijn.c consisting of four lines:

   extern void tijs(void);
   int main(void) {
   tijs();
   }

I have a simple .asm file mijn.asm like this:

      BITS 32
      GLOBAL _tijs

      SECTION .text

; prototype: void tijs(void);
_tijs mov dx,0x3C8 ; Port 3C8h to switch to PEL address write mode.
      mov al,1     ; 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,0x3F  ; 3Fh.
      out dx,al    ;
      ret

      SECTION .data
      SECTION .bss

Next I issue the following two commands:

  nasm -f coff mijn.asm
  gcc -o mijn mijn.c mijn.o

The result is mijn.exe, for sure. Neither nasm nor gcc complains.
The executable runs, both from the command.com prompt and from the
bash prompt, and the system doesn't crash. But nothing happens!! It
doesn't seem to get through to the ports. When I compile mijn.asm as
a .com program and run it from command.com, however, dark blue
becomes bright blue, just as it should! I've used this simple routine
for years. It never failed.

Am I missing something obvious, or trying to do something
impossible? I know that _The Undocumented PC_, Frank van Gilluwe says
(page 43):

 "Real mode is similar in concept to an 8088
  processor. All resources, such as I/O ports,
  are always accessible to all software users.
  No provisions are available to limit access
  to I/O addresses.
  Two other processor modes, Protected and
  Virtual 86, can limit access to I/O. This
  means that an advanced operating system such
  as Windows or OS/2 can control who is allowed
  to read or write I/O ports. [...]"

However, ports 3C8h and 3C9h are not listed as such.

Any suggestion, doc, or example is much appreciated.

Best wishes,

Tijs
m DOT h DOT m DOT michels AT kub DOT nl
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".