News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

drivers versus int

Started by ninjarider, July 22, 2007, 09:34:49 PM

Previous topic - Next topic

ninjarider

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.

Tedd

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.)
No snowflake in an avalanche feels responsible.

ninjarider

thnx for answering my question.

MichaelW

#3
The attachment is DOS app that calls the SMAP function and displays what it returns.

[attachment deleted by admin]
eschew obfuscation


sinsi

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.
Light travels faster than sound, that's why some people seem bright until you hear them.

ninjarider

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.

MichaelW

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.
eschew obfuscation

MichaelW

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.
eschew obfuscation

ninjarider

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.

MichaelW

Support.asm calls DOS functions, so it must be a DOS or Windows9x boot disk.
eschew obfuscation