Hardware Interrupts

Hardware Interrupts

[Carroll-Tech]

Has anyone here read "Ada Concurrent Programming" by Narain Gehani?
In the book, Narain talks about address clauses.  For example:

task Interrupt_handler is
    entry DONE;
    for DONE use at 16#40#;
end Interrupt_handler;

Can an address clause be done with a procedure or function instead of a
task entry?
What about arguments?
How can I capture a return value, if there is one?

I want to call the BIOS interrupt (INT11h) to get the equipment list
word.  In my Assembly book it says that INT11h "returns" a word
containing the equipment list.  I'm assuming that a '1' at a given bit
within the word means the equipment is in the computer and '0' is not.

Here is my code so far
-------------------------------------------------------
with ada.text_io; use ada.text_io;
with system.interrupts; use system.interrupts;

procedure getequipment is
 type equiplist is array(0..15) of boolean;
 package boolean_io is new enumeration_io(boolean);
 procedure getlist(list: out equiplist);
 for getlist use at reference(16#11#);
 mylist: equiplist;

begin
 getlist(mylist);

-- for I in 0..15 loop
--  boolean_io.put(mylist(i));
-- end loop;
end getequipment;
------------------------------------------------------

When I compile this code the compiler says several things
that I do not know how to fix.

getequipment.adb:2:12: warning: "system.interrupts" is an internal GNAT unit
getequipment.adb:2:12: warning: use of this unit is non-portable and
version-dependent
getequipment.adb:7:09: missing body for "getlist"
getequipment.adb:8:13: address clause can only be given for imported
subprogram

Any ideas?

Maybe there is an easier way to call INT11h from Ada?
I looked into System.Machine_Code and the ASM procedure but that seems
pretty
complex (per GNAT reference manual explanation).

system calls, was Re: Hardware Interrupts

[tmoran]

> task Interrupt_handler is
> ...
> I want to call the BIOS interrupt (INT11h) to get the equipment list
  The task stuff is about *handling* interrupts, but you want to *call*
something via a software interrupt.  Compiler vendors normally supply
packages to do such system dependent things - presumably your copy of
Gnat does too.
  If not, you will need to find such a package (or find one in C and
interface to it) or else you'll have to use "machine code insertions"
and code in assembly to set up the calling sequence, issue the interrupt,
and retrieve the results.
  BTW, what machine has a BIOS INT11h call?

Re: Hardware Interrupts

[sk]

andrew@carroll-tech.net:

 > procedure getequipment is
 >  type equiplist is array(0..15) of boolean;
 >  package boolean_io is new enumeration_io(boolean);
 >  procedure getlist(list: out equiplist);
 >  for getlist use at reference(16#11#);
 >  mylist: equiplist;
 > begin

I don't know any answers to your questions. What I do
remember about any assembly calls to BIOS interrupts
is that you have to set up the registers with parameters
etc.

You are using GNAT from your examples. Which version
and platform ?

If it is an Intel compiler running in "protected" mode,
that is 32-bit address space etc, the physical address
"16#11# does not corespond to the interrupt 11. Once
32-bit protected mode is entered, the Interrupts are
gated and are typically not at the booting 0 .. 255
address space of an Intel 386 processor boot prior to
entering protected mode.

Another thing to note is that, I believe, the BIOS
is not accessible as regular memory once Intel 32-bit
protected mode is established (I could be wrong on this :-)

If you are still determined to go into never-never land,
you need to look at Ada's machine code insertions. The
code you posted looks potentially fatal to your machine.

So, beyond Gnat telling you the code is non-portable, I
would say it is also, at the least, not what you are
looking for, at worst calling "format disk" which is
a BIOS routine of almost 20 years ago before the
current IDE standards were established.

Sorry, not much help, but I am hoping that you don't
trash your system by being determined to call a
possible inaccessible BIOS.

Simon :-)

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Hardware Interrupts

[Carroll-Tech]

> From: tmoran@acm.org
> Subject: system calls, was Re: Hardware Interrupts
>
> > task Interrupt_handler is
> > ...
> > I want to call the BIOS interrupt (INT11h) to get the equipment list
[snip]
>   BTW, what machine has a BIOS INT11h call?
Good question!  I'm just going by the information in Kip R. Irvine's book
"Assembly Language For Intel-Based Computers", third edition.
I also found the same information in a book called "DOS 5: A Developer's
Guide" by Al Williams (page 163).  This book does say 80286 - 80486.
So...it must be pretty old.

> ------------------------------
> From: sk <noname@myob.com>
> Subject: Re: Hardware Interrupts
>
> andrew@carroll-tech.net:
>
>  > procedure getequipment is
[snip]
> I don't know any answers to your questions. What I do
> remember about any assembly calls to BIOS interrupts
> is that you have to set up the registers with parameters
> etc.
Okay, I understand that regarding "assembly" but not going
through Ada.

> You are using GNAT from your examples. Which version
> and platform ?
Gnat 3.15p on a FreeBSD Unix 5.1

> If it is an Intel compiler running in "protected" mode,
> that is 32-bit address space etc, the physical address
> "16#11# does not corespond to the interrupt 11. Once
[snip]
> entering protected mode.
Basically I've made my own bootloader and it will boot programs
that I create.  So there is no kernel loaded or anything like that.  The
bootloader loads the program I want right after the BIOS is done.  In
fact, I am trying this "stuff" out because I want to learn more about
kernels (other than reading in a book) and how to do PIC programming
and stuff like that.

> If you are still determined to go into never-never land,
> you need to look at Ada's machine code insertions.
Links?  References?

>The code you posted looks potentially fatal to your machine.
Hey, how else am I going to learn?  If I make a mistake at least it's not
while I'm working for some client or something.  I'm just doing some
of my own research.

> Sorry, not much help, but I am hoping that you don't
> trash your system by being determined to call a
> possible inaccessible BIOS.
I'll look into this before I continue.  I don't really wan't to format the
disk
either, even though it's not imperitive at this point if it happens.

Thanks!

Re: Hardware Interrupts

[tmoran]

> >   BTW, what machine has a BIOS INT11h call?
> Good question!  I'm just going by the information in Kip R. Irvine's book
> "Assembly Language For Intel-Based Computers", third edition.
> I also found the same information in a book called "DOS 5: A Developer's
> Guide" by Al Williams (page 163).  This book does say 80286 - 80486.
  According to Ralf Brown's Interrupt List Int11h means different things to
different BIOSes - are you sure yours is one that returns an equipment list?

> Gnat 3.15p on a FreeBSD Unix 5.1
> > entering protected mode.
> Basically I've made my own bootloader and it will boot programs
  Does your bootloader load into 32 or into 16 bit mode?  Does that Gnat
generate the same?  The BIOS usually runs as 16, so if you are in 32
you may need to switch.
  (I recently had to use BIOS level disk IO calls and dug up an ancient
16 bit Ada 83 compiler to do it.  That compiler came with a vendor
supplied library for doing INT calls.)

Re: Hardware Interrupts

[sk]

andrew@carroll-tech.net:

 >> If you are still determined to go into never-never land,
 >> you need to look at Ada's machine code insertions.
 >
 > Links?  References?

Sorry, no. The Gnat manual has a section in it concerning
inline assembly.

As "tmoran" states, "Ralf Brown" is a good resource.

<shameless plug>
Another resource of course would be my translation of
Frank Cornelis's Edu-OS into Ada. However, a misplaced
"mke2fs" two falls ago (2002) totally destroyed that
effort ... but I do have an Ada bootable from GRUB which
you might find useful.

"www.ktc.com/~sknipe/" follow the links to get the
BOOT packages.
</shameless plug>

PS. As mentioned above,  I trashed a lot of (admittedly
terrible) coding of the EduOs-Ada-CINA. Would someone
who downloaded it the time be willing to get copies back
to me ? I believe the BOOT code is a far better example,
but I would like to have some of the original CINA effort.

Thanks,

Simon

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Hardware Interrupts

[Carroll-Tech]

> ------------------------------
> From: tmoran@acm.org
> Subject: Re: Hardware Interrupts
>
>   According to Ralf Brown's Interrupt List Int11h means different things
to
> different BIOSes - are you sure yours is one that returns an equipment
list?
No.  Who is Ralf Brown?

> > Gnat 3.15p on a FreeBSD Unix 5.1
> > > entering protected mode.
> > Basically I've made my own bootloader and it will boot programs
I have no special code in the bootloader to switch to 32.  The bootloader
started out as an experiment.  The only thing it does really is a JMP.

> ------------------------------
> From: sk <noname@myob.com>
> Subject: Re: Hardware Interrupts
> [snip]
> <shameless plug>
> Another resource of course would be my translation of
> Frank Cornelis's Edu-OS into Ada. However, a misplaced
> "mke2fs" two falls ago (2002) totally destroyed that
> effort ... but I do have an Ada bootable from GRUB which
> you might find useful.
>
> "www.ktc.com/~sknipe/" follow the links to get the
> BOOT packages.
> </shameless plug>
>
> Simon
I think this can be helpful information in the future.  Thank you!!


Are the things I am asking about the same things that motivate
AdaOS to build a compiler?

It seems like what I need is to define a procedure, say
"getequiplist" and then define what machine code is
supposed to be generated by the compiler for "getequiplist".
Then when I used "getequiplist" the compiler would output
the machine code I want to be executed at the proper location
within the program.  Did that make any sense?  Speaking
abstractly and in general.

I guess another way to describe it is that if I wrote the procedure
in assembly and in Ada, after "making" the executables of each
one the machine code of both of them would look the same.

Can anyone tell what I'm trying to say or am I just loosing it?

Andrew

Re: Hardware Interrupts

[tmoran]

>It seems like what I need is to define a procedure, say
>"getequiplist" and then define what machine code is
>supposed to be generated by the compiler for "getequiplist".
  And the way you "define what machine code is supposed to be generated"
is by describing it using Machine-Code Insertions.

A generally better way is to define a general BIOS call procedure, eg
    Procedure Int_Call(Int_Num : Integer; Regs : In Out Most_Regs);
        -- Call the interrupt (for BIOS use, others?) with the registers set
        -- from Regs.  The result registers and flags are placed back into Regs.
(Taken from Janus Ada 83 "package DosCall") and then define
  function Get_BIOS_Equipment_List return ... is
    Regs : Most_Regs := (AX=>..., BX=>..., ...
  begin
    Int_Call(16#11#, Regs);
    return ...
  end Get_BIOS_Equipment_List;

But note that you need an Ada compiler that generates code for your
machine/OS combination - in this case 16 bit "real mode" x86 with your
boot loader (no DOS) as the OS.   If you don't mind a little dust on
the antique manuals ;), I'm sure you could purchase such a thing.  I
don't know if, say, MaRTE OS, supports 16 bit BIOS calls.

Re: Hardware Interrupts

[Brian Catlin]

<tmoran@acm.org> wrote in message news:X4s_b.108457$jk2.483600@attbi_s53...
> >It seems like what I need is to define a procedure, say
> >"getequiplist" and then define what machine code is
> >supposed to be generated by the compiler for "getequiplist".
>   And the way you "define what machine code is supposed to be generated"
> is by describing it using Machine-Code Insertions.
>
> A generally better way is to define a general BIOS call procedure, eg
>     Procedure Int_Call(Int_Num : Integer; Regs : In Out Most_Regs);
>         -- Call the interrupt (for BIOS use, others?) with the registers set
>         -- from Regs.  The result registers and flags are placed back into
Regs.
> (Taken from Janus Ada 83 "package DosCall") and then define
>   function Get_BIOS_Equipment_List return ... is
>     Regs : Most_Regs := (AX=>..., BX=>..., ...
>   begin
>     Int_Call(16#11#, Regs);
>     return ...
>   end Get_BIOS_Equipment_List;
>
> But note that you need an Ada compiler that generates code for your
> machine/OS combination - in this case 16 bit "real mode" x86 with your
> boot loader (no DOS) as the OS.   If you don't mind a little dust on
> the antique manuals ;), I'm sure you could purchase such a thing.  I
> don't know if, say, MaRTE OS, supports 16 bit BIOS calls.

I really think that you would be better off forgetting the BIOS and do
everything yourself.  This may sound like a bold statement (and a lot of work),
but one of the primary reasons that the Win9x family of operating systems was so
unreliable, is that they used the BIOS for I/O.  Contrast this with the
reliability of NT, 2K, XP, etc., which don't use the BIOS for anything (other
than loading their own boot loader from disk).  Get the ACPI specs
(www.acpi.org) and write your own code to parse the ACPI tables (which contains
the hardware configuration of the machine), and write your own "drivers" for the
various common PC motherboard hardware (VGA, keyboard, mouse, USB, serial, PCI,
etc.).

 -Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS

Re: Hardware Interrupts

[David C. Hoos]

----- Original Message ----- 
From: "Brian Catlin" <BrianC@sannas.org.bad>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada-france.org>
Sent: Monday, February 23, 2004 2:39 PM
Subject: Re: Hardware Interrupts


<snip>
> I really think that you would be better off forgetting the BIOS and do
> everything yourself.  This may sound like a bold statement (and a lot of
work),
> but one of the primary reasons that the Win9x family of operating systems
was so
> unreliable, is that they used the BIOS for I/O.  Contrast this with the
> reliability of NT, 2K, XP, etc., which don't use the BIOS for anything
(other
> than loading their own boot loader from disk).  Get the ACPI specs
> (www.acpi.org) and write your own code to parse the ACPI tables (which
contains
> the hardware configuration of the machine), and write your own "drivers"
for the
> various common PC motherboard hardware (VGA, keyboard, mouse, USB, serial,
PCI,
> etc.).

Did you mean www.acpi.info? www.acpi.org is the
Avaiation Crime Prevention Institute.

Re: Hardware Interrupts

[Brian Catlin]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.16.1077570392.327.comp.lang.ada@ada-france.org...
> ----- Original Message ----- 
> From: "Brian Catlin" <BrianC@sannas.org.bad>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada-france.org>
> Sent: Monday, February 23, 2004 2:39 PM
> Subject: Re: Hardware Interrupts
>
>
> <snip>
> > I really think that you would be better off forgetting the BIOS and do
> > everything yourself.  This may sound like a bold statement (and a lot of
> work),
> > but one of the primary reasons that the Win9x family of operating systems
> was so
> > unreliable, is that they used the BIOS for I/O.  Contrast this with the
> > reliability of NT, 2K, XP, etc., which don't use the BIOS for anything
> (other
> > than loading their own boot loader from disk).  Get the ACPI specs
> > (www.acpi.org) and write your own code to parse the ACPI tables (which
> contains
> > the hardware configuration of the machine), and write your own "drivers"
> for the
> > various common PC motherboard hardware (VGA, keyboard, mouse, USB, serial,
> PCI,
> > etc.).
>
> Did you mean www.acpi.info? www.acpi.org is the
> Avaiation Crime Prevention Institute.


Oops.  Thanks for the correction

 -Brian

Re: Hardware Interrupts

[sk]

andrew@carroll-tech.net :
 > Are the things I am asking about the same things that motivate
 > AdaOS to build a compiler?

I do not know about the AdaOS group, but you can get quite
far without having to hack the GNAT run-time or the compiler.

The area where GNAT (on Linux or Windows, I do not know
about *BSD's) will be unreliable, as "Jerry van Dijk"
points out, is in 16-bit mode. GCC does document a switch
that causes it to produce 16-bit code, but it also
documents that they, the gcc people, would not rely on
it (by the way "Jerry van Dijk" authored an inline
assembler tutorial for GNAT which is now part of
the manual. I found the turorial to be one of the
most useful practical discussions of "gas" assembly
even though it is limited to an Ada inline scope).

Some thoughts for you:

procedure X is

     procedure A is
     begin
         null;
     end A;

     procedure B (N : natural) is
     begin
         null;
     end B;

     procedure C (N : in out natural) is
     begin
         null;
     end C;

     Num : Natural;

begin
     A;
     B (Num);
     C (Num);
end X;

Use the "-s" gnatmake switch to compile and peruse the
produced assembly code and notice the pushes and pops
prior to and after the calls to the procedures. This
would give you a good idea of how gcc/GNAT passes
parameters to procedures etc at the assembly level.

The study should give you some ideas on how to create
assembly routines which you can "pragma Import (ASM, ...)"

(PS Still hoping someone has a EduOs-Ada-CINA that
they can get back to me, thanks :-).

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Hardware Interrupts

[Carroll-Tech]

> ----------------------------------------------------------------------
> From: Jerry van Dijk <somename@nospam.demon.nl>
> Subject: Re: Hardware Interrupts
>
> Note this thread escaped me so I might be wrong, but I am guessing you
want
> bootcode for a PC ?

I appologize, I haven't been to clear on what I'm trying to accomplish.  I
am
building my own "super computer".  Ok, well, it's really an experiment to
satisfy my own interests.  Super computer might be a large leap!
However realistic it is I don't really care.  I'm learning things and at
this time
I feel I'm enjoying what I'm doing.  I'm going bankrupt anyway so I might
as well go bankrupt doing something I feel satisfied with.

I've connected two computers together via the IDE ports (altered the ribbon
cable for such purposes).  Now I know that Windows, nor *nix will provide
me with "drivers" for how I connected them nor a kernel to do what I want to
do with the connection.  I don't want to sort through "public" code, like
FreeBSD
C code,  just to print "hello world" or something.

Initially my goal is simple.  Execute code on computer A that displays on
computer B's monitor through the IDE connection.  Let's say "hello world".
That's where hardware interrupts and "chaining" my own interrupt routines
comes into play.  I think, to start, I just want to know what hardware
interrupts are showing up and then I can "chain" my own routines on them
(through the Interrupt vector table) and can eventually achive some kind
of communication between the two computers via the IDE connection.

Call it a driver, call it a kernel, call it balogne, whatever...I just know
that
I've seen examples of using Ada for "chaining" interrupts and I know I
can get the interrupts from the vector table   So to get a feel for what I
am doing I wanted to "practice" working with interrupts from the interrupt
vector table by getting a list of attached hardware from the BIOS.  That was
the arbitrary INT call that I picked out from the references I have.  I know
it has a list because it prints it out when it boots up and several authors
have placed information in their written work describing an INT instruction
that yields that information.

I don't "have" to get the hardware list.  I could go with something else
like
detecting if their is a printer installed or something.  I just want to get
familiar
with the interrupt "stuff" and the hardware list was my initial choice.


>------------------------------
> From: tmoran@acm.org
> Subject: Re: Hardware Interrupts
>
>   And the way you "define what machine code is supposed to be generated"
> is by describing it using Machine-Code Insertions.
>
> A generally better way is to define a general BIOS call procedure, eg
>     Procedure Int_Call(Int_Num : Integer; Regs : In Out Most_Regs);
>         -- Call the interrupt (for BIOS use, others?) with the registers
set
>         -- from Regs.  The result registers and flags are placed back into
Regs.
> (Taken from Janus Ada 83 "package DosCall") and then define
>   function Get_BIOS_Equipment_List return ... is
>     Regs : Most_Regs := (AX=>..., BX=>..., ...
>   begin
>     Int_Call(16#11#, Regs);
>     return ...
>   end Get_BIOS_Equipment_List;
> But note that you need an Ada compiler that generates code for your
> machine/OS combination - in this case 16 bit "real mode" x86 with your
> boot loader (no DOS) as the OS.

Ahhhhhh, GREAT information!!!



> ------------------------------
> From: sk <noname@myob.com>
> Subject: Re: Hardware Interrupts
>
> it (by the way "Jerry van Dijk" authored an inline
> assembler tutorial for GNAT which is now part of
> the manual.

Is it in the gnat_ug.html?  Where?

> Some thoughts for you:
[snip]
> parameters to procedures etc at the assembly level.
> The study should give you some ideas on how to create
> assembly routines which you can "pragma Import (ASM, ...)"

I'll have to play around with that.  Thank you!



> ------------------------------
> From: "Brian Catlin" <BrianC@sannas.org.bad>
> Subject: Re: Hardware Interrupts
>
> I really think that you would be better off forgetting the BIOS and do
> everything yourself.  This may sound like a bold statement (and a lot of
work),
[snip]
> Get the ACPI specs
> (www.acpi.info) and write your own code to parse the ACPI tables (which
contains
> the hardware configuration of the machine), and write your own "drivers"
for the
> various common PC motherboard hardware (VGA, keyboard, mouse, USB, serial,
PCI,
> etc.).

Cool!!  I'm going to look into this also.  Thank you!!

Thanks for the help all!!

Re: Hardware Interrupts

[Preben Randhol]

On 2004-02-24, Carroll-Tech <andrew@carroll-tech.net> wrote:
>> From: sk <noname@myob.com>
>> Subject: Re: Hardware Interrupts
>>
>> it (by the way "Jerry van Dijk" authored an inline
>> assembler tutorial for GNAT which is now part of
>> the manual.
>
> Is it in the gnat_ug.html?  Where?

http://www.adapower.com/articles/gnatasm/inline_asm_toc.html

Perhaps this is also of interest: ?

http://www.beesknees.freeserve.co.uk/articles/gnat.html
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Hardware Interrupts

[tmoran]

> Initially my goal is simple.  Execute code on computer A that displays on
> computer B's monitor through the IDE connection.  Let's say "hello world".
> That's where hardware interrupts and "chaining" my own interrupt routines
  It sounds to me like the OP is making a project to learn with.  If he
wants to learn about hardware interrupts, 16 bit DOS is a good place to
start, though he will need a suitable compiler.  If he wants to learn
about device drivers in big, modern, OSes then Linux or Windows should
be good platforms, but are a lot more complicated than simple real-mode
interrupts.  If he wants to experiment with networked computers, OTOH,
then appendix E Distributed Systems is much easier.
  What platforms do they use in CS classes to teach interrupts and such?

Re: Hardware Interrupts

[Chad R. Meiners]

<tmoran@acm.org> wrote in message news:LMQ_b.399511$na.765442@attbi_s04...
>   What platforms do they use in CS classes to teach interrupts and such?

In a lot of universities, they don't teach interrupts anymore.  Both
architecture and organization classes as well as assembly programming
classes have been depreciated.

-CRM