The MASM Forum Archive 2004 to 2012

Miscellaneous Forums => 16 bit DOS Programming => Topic started by: ninjarider on July 22, 2007, 09:34:49 PM

Title: drivers versus int
Post by: ninjarider on July 22, 2007, 09:34:49 PM
if i programmed all my own drivers using in and out, would i still need anything from the bios. would i also still need the a block or could i move the a block.
Title: Re: drivers versus int
Post by: Tedd on July 23, 2007, 01:06:25 PM
Once you're in protected mode and handling the interrupts/devices yourself, you can ignore bios.
However, there are some areas of memory you should leave alone - these are indicated in the memory map you receive from the bios SMAP function (int 15, e820). You should leave the nvram sections (until you know how/why you can change them), but all memory sections labelled as free are free as you like, including the real mode interrupt table and bios extended area, etc..
"the a block"? The memory at A0000h is mapped to vga memory, so depending on your screen mode you may or may not want to mess it up, equally B8000h is for CGA memory, so if you're in a text mode you want to keep that fresh. But again, once you get a video driver working you'll know about these areas and can move them if you like (you can tell the graphics device where they should go.)
Title: Re: drivers versus int
Post by: ninjarider on July 23, 2007, 07:03:43 PM
thnx for answering my question.
Title: Re: drivers versus int
Post by: MichaelW on July 23, 2007, 09:20:40 PM
The attachment is DOS app that calls the SMAP function and displays what it returns.

[attachment deleted by admin]
Title: Re: drivers versus int
Post by: ninjarider on July 23, 2007, 09:38:45 PM
thnx.
Title: Re: drivers versus int
Post by: sinsi on July 24, 2007, 12:32:41 AM
Quote from: MichaelW on July 23, 2007, 09:20:40 PM
The attachment is DOS app that calls the SMAP function and displays what it returns.
Just a small error in the code

    int   15h
    .IF eax != 'SMAP'
      print NL,"Interrupt 15h Function E820h not supported or not available.",NL,NL
      jmp   callFunction88h
    .ENDIF
  @@:
    jc    finish

since if EAX='SMAP' then carry is always clear and "jc finish" will never happen.
Title: Re: drivers versus int
Post by: ninjarider on July 24, 2007, 01:58:45 AM
im not home to say it will. but whats the chances that i can't call that on my box.

and does that need to be ran in real or protected.
Title: Re: drivers versus int
Post by: MichaelW on July 24, 2007, 02:43:24 AM
Quote from: sinsi on July 24, 2007, 12:32:41 AM
Just a small error in the code
Thanks. That error was present in the original code posted on the old forum, and you are the first to catch it. Fixed version in the attachment.
Title: Re: drivers versus int
Post by: MichaelW on July 24, 2007, 03:21:32 AM
Quote from: ninjarider on July 24, 2007, 01:58:45 AM
im not home to say it will. but whats the chances that i can't call that on my box.

and does that need to be ran in real or protected.
You should be able to call it OK, but if you call it under Windows 2000 or XP, or on a system that is too old, the function will return an error. Per RBIL, the function was "originally introduced with the Phoenix BIOS v4.0". I have a system with a Phoenix BIOS dated 04/10/98 that supports the function, and a system with an Award BIOS dated 06/12/00 that supports the function.

The code calls DOS and BIOS functions, so it must run in real (or V86) mode.
Title: Re: drivers versus int
Post by: ninjarider on July 24, 2007, 03:36:22 AM
ok, you answered something i was concerned about. wether i needed to be running it in real or protected mode. so i should be fine running it off a boot sector and displaying the info.
Title: Re: drivers versus int
Post by: MichaelW on July 24, 2007, 04:54:30 AM
Support.asm calls DOS functions, so it must be a DOS or Windows9x boot disk.