Most people would just use those routines to access the hardware, ie hard
drive, floppy disk drive, keyboard, ect. But how do these service routines
There are not that many useful information floating around. All of these
routines are kind of like black boxes that hide the detail from user. I truely
believe that having the source code of these routine handy will greatly promote
programmers to understand more about the PC. However due to various reasons,
most of the companies instead hide the information or document the products in
a very vague manner. The last piece of BIOS source code was from IBM's AT
technical reference dated back in 1985. Since then, to get the BIOS source
code require disassembly.
Of course, you don't have to bother about how things behave the ways they
are. I, however, want to find out how things work. I have tried to
disassemble the BIOS, using int 21 function 35 to locate the interrupt handler,
then disassemble the instructions return from ex:bx. however, I had no
success. I urge people who read this message and share the interests of
cracking the black box. We should work together as a team, share what we know,
using what we have, and maybe develope some utilities along the way to take the
BIOS out. I truely believe that we can learn from each other and learn more
about how the machine works. We can gain experience of disassembly when there
are no source available. And I hope you will join me. We should share what we
know in the newsgroup so people who can join in and share their insights. If
you think this is a joke, please disregard what you read.
truely and sincerely
When I disassemble code, BIOS or any other code, I first locate the
correct address with a debugger (Turbo Debugger). Most interrupts are already
hooked by other programs, including DOS, so I follow the ISRs all the way
until it chains to the previous handler. Eventually, I land in BIOS land and
know the correct address.
If you want a book that covers the low-level hardware programming, this book might
interest you: "The Indispensable PC Hardware Book third edition" by Hans-Peter Messmer
(Addison Wesley ISBN 0-201-40399-4) US$42.95, CAN$58.95. It's 1380 pages and covers
all the hardware (almost) in a PC, including chipsets, buses, CPUs, etc.
>When I disassemble code, BIOS or any >other code, I first locate the
>correct address with a debugger (Turbo >Debugger). Most interrupts are already
>hooked by other programs, including DOS, >so I follow the ISRs all the way
>until it chains to the previous handler. >Eventually, I land in BIOS land and
>know the correct address.
tracing BIOS code, aha. This is NOT GOING TO WORK since most of the debuggers
rely on BIOS or DOS services. As most of you have known, BIOS and DOS are not
re-entrant. Once you locate the address of the ISR, if you try to step thru,
you are certainly running yourself to trouble unless you have some debuggers
that dont rely on DOS or BIOS such as soft-ice. If you really want to take the
BIOS apart, here is a few suggestions, go into debug, and copy a image file
starting from A0000 to FFFFF, the image file should contain the code of the
BIOS routines controling the hardware. Then static unassemble the image file.
It will take a lot of works to decode the list. A easier approach will be
getting sourcer and BIOS pre processer from V-communication, then disassemble
the BIOS. But it still take a lot of work to understand how BIOS interact with
the hardware. The last approach I will use will be writing a program that does
the trace for you, this is not like single stepping thru ISR which can cause
you trouble. Then save copy the image file from the address that you obtain
from the tracing program. Disassemble the ISR. You still have to understand
the port address, and some control registers of the hardware and what those
AND, OR, bitwise level meaning to the hardware.
Finally I have to say, why bother doing this if there are sources available.
Spend about 500 bucks and get the MSDN Pro, which you will get the DDK, I am
talking about the DDK, inside are some mini vxd driver, to give you an idea,
disk controller vxd, keyboard vxd, video vxd, and so on, besides, the Libarary
contains tons of useful information for programming and specification such as
some of windows file format, ie. COFF, PE, and so on.
But if you really want to take a look at the original code of the BIOS, go to
www.annabook.com, I believe they still have the IBM AT's technical reference
available for 100 something bucks. It includes the complete source code of the
BIOS, from POST to transfering control to DOS. It is a bit old, but it should
be useful to you if you want to learn how things work. If you dont have the
money to do this, I will suggest you to write a small utilities that do the job
best wish for you all.
>If you want a book that covers the low-level >hardware programming, this book
>interest you: "The Indispensable PC >Hardware Book third edition" by
>(Addison Wesley ISBN 0-201-40399-4) US$42.95, CAN$58.95. It's 1380 pages and
>all the hardware (almost) in a PC, including >chipsets, buses, CPUs, etc.
I will definately recommend that book plus the "undocumented PC 2nd edition".
some other books you might find useful
"undocumented dos 1st edition"
this book has extensive coverage of how debug work
"undocumented dos 2nd edition"
this book teaches you techniques to explore a system, plus you will learn how
to disassemble and what codes to look for. How to write some useful utilities
along the way.
if you want to disassemble windows, this is a book to read
"inside windows 95 file system"
good topics on some undocumented aspects of windows 95 and how the installable
file system manager works.
"inside windows 95 registry"
another good book to explore the inner aspect of windows 95
"unauthorized windows 95"
good discussion about how windows 95 is not really what MS claimed to be.
"windows 95 system programming secret"
another execellent book on windows 95
DDJ CD-ROM, WDJ CD-ROM, CUJ CD-ROM, provides a lot of excellent articles on
you need softice if you want to do serious programming
Of course. I forgot to mention I don't run the code when I search the original
BIOS address. I just read the assembly code and searches for the jmp to the
previous handler and jumps to it (ALT-F10 F in TD)
|you need softice if you want to do serious programming
Highly recommended. The best software debugger.
> Just like Unix, the system is well studied, well
> documented. Why can't we, who love
> assembly language and the low level stuff, combine our effort and
> make the BIOS
> archetechure. Like, we can try disassemble
> the disk ISR, then publish what we find.
> Share techniques about how we achieve the
> result and so on. When people work as a
> team instead of going self-style, it can make
> things possible.
Well, _this_ sounds interesting. Reading the original post, I thought
"Nah. Just another guy writing a Thom Hogan's PC Programmer's
Sourcebook". Anyway, having the actual code to command an I/O board
(such as a disk controller) would be invaluable, especially if this
information would be stored in one place, all together. Where would
that place be? Spilling it out in a newsgroup doesn't seem very
practical a solution, since the articles tend to expire after some
Glossary: AVI = Almost Video Interleaved
>Well, _this_ sounds interesting. Reading the
>original post, I thought "Nah. Just another
>guy writing a Thom Hogan's PC
>programmer's Sourcebook". Anyway,
>....... Where would that place be? Spilling it
>out in a newsgroup doesn't seem very
>practical a solution, since the articles tend to
>expire after some time...
We can try to compile the listing and post the
list on a web page or upload to simtel.net
where all information can be readily
accessable. Any way, there has been enough
talk, but no action has been carrying out yet.
So, I am going to take the first step since I
posted the original article. I am going to
disassemble the keyboard int 9 for now. I will
let you guys know the techniques, and maybe
pitfalls I fall under. And I will post questions
about how to do certain things. It's like a
growing experience for me. I will soon
publish my web page on disassembling and
the BIOS code that I can dig out. Hope you
guys will join me and make disassembling
from scratch interesting. I think it can also
help you out in a long run since sometimes
the only solution to a problem is thru
disassembling the code.
I believe Sourcer may do this for you. Look for SOURCER.ARJ - it has
RUNBIOSP that will give you the full commented listing for your BIOS.
It doesn't explain what the code does. Just adds simple comments.
I have recently been involved with what I believe to be an interesting
task. I have to reload an operating system by manually loading the boot
sector from a disk other than the one that I booted from and then jumping
to it like the INT 19 would have done. I have sort of been involved with
disassembling the INT 19 instruction, so perhaps if there is a place that I
can report my findings, I would be happy to do so.
But what I am writing here is that if you want to find out, on your system,
where all the original interrupts are (unless of course BIOS extensions
have chained certain vectors) is to do a little modification of the boot
sector on a bootable floppy that saves an image of the interrupt vector
table to a high memory location that is not overwritten when the OS starts.
I have been using 7000:0000 with success. It has been interesting, and
frustrating, to see how the different computers 'look' at startup.
Now if I can just figure out how the environment is supposed to be when the
boot sector starts executing.....
> I have recently been involved with what I believe to be an
> task. I have to reload an operating system by manually loading the
> sector from a disk other than the one that I booted from and then
> to it like the INT 19 would have done. I have sort of been involved
> disassembling the INT 19 instruction, so perhaps if there is a place
> that I
> can report my findings, I would be happy to do so.
> Now if I can just figure out how the environment is supposed to be
> when the
> boot sector starts executing.....
If memory serves, DL holds the boot drive code (00h for A, 01 for B,
80h for C, 81h for D...),CS:IP is set to 7c0h:0 and stack down from
07c00h abs (how SS:SP is actually set seems to vary between different
BIOSes). Executing a Far jump as the first thing at 7c00h abs makes it
able for a boot sector to get its own CS:IP right. In some systems,
the POST has set ES set to 40h (BIOS data area) and DS = CS, but this
seems to vary. Oh, and if you use BIOS 19h, then there's a magic word
somewhere in the BIOS data area (sorry, memory fails) that can be set
to 1234h or 4321h. It had something to do with the way the BIOS boots
(whether it executes a warm boot, whether it resets the I/O boards,
etc). Don't know if any OS boot code makes use of this information or
Glossary, from comp.os.ms-windows.win95.misc:
MSOffice Toolbar = where Microsoft Office Tools hang out when not
I still may have to end up taking apart the Bios though, or looking for
source code, because if in CMOS I turn off the hard disk and indicate that
it is not present, I do not see how it is turned on for access. Whether it
is on or not, interrupt 41 still points to the same parameter table (in ROM
interestingly enough). If I restore a low memory configuration when the
hard disk was configured to work, to a system that was not started with the
disk present, I get an error from INT 13 when I try to load the boot
sector. This tells me that a) somewhere in bios, CMOS is used when
accessing the disk, as opposed to just using the BIOS data area and the
interrupt table or b) the controller has to be 'activated' somehow, and
Bios takes care of this when it powers up on its equipment check. Figuring
this out seems to be my task for today.
> interrupt 41 still points to the same parameter table (in ROM
> interestingly enough). If I restore a low memory configuration when the
> hard disk was configured to work, to a system that was not started with the
> disk present, I get an error from INT 13
Just a guess, but I think the key point is that the "ROM" isn't
really ROM, it is shadow RAM.
Most BIOS's actually change the contents of the parameter table
in shadow RAM based on the CMOS settings. (The BIOS knows how to
write enable the shadow RAM, make a change and then write protect