Author Message

Hi  ,  how are you??

Would you like to tell me what will the computer do when it finished all the
instruction from boot sector ?Keep going to fetch the instructions that next
to the 0000:7c00 or jmp to somewhere???
If it keep going to fetch the instructions , how about it reach the highest
address limit ? That mean what will it do when it fetched the last
instruction from the top of 1MB??

thank you for all you answers ....

Wed, 03 Jul 2002 03:00:00 GMT  

   >Hi, how are you??

Well, I'm fine as frog hair; thanks very much for inquiring of this
humble personage.  May the gods smile on you and your posterity, and
give you many children to help work the rice paddies.

   >Would you like to tell me what will the computer do when it
   >finished all the instruction from boot sector?

Since you, I would =not= particularly like to tell you that.

   >Keep going to fetch
   >the instructions that next to the 0000:7c00 or jmp to somewhere???
   >If it keep going to fetch the instructions , how about it reach the
   >highest address limit ? That mean what will it do when it fetched
   >the last instruction from the top of 1MB??

Oh, all right; I'll tell you, if you promise not to use the information
to advance some silly-assed Communist agenda.  We have too much of that
{*filter*}in the U.S.A. already.

Here's how DOS does it.



>"Programmer's Technical Reference for MSDOS and the IBM PC"
>Copyright (c) 1987, 1990 Dave Williams
>USA copyright TXG 392-616
>ISBN 1-878830-02-3 (disk-based text)


>DOS consists of four components:

> * The boot record
> * The ROM BIOS interface  (IBMBIO.COM, DRBIOS.SYS, or IO.SYS)
> * The DOS program file    (IBMDOS.COM, DRBDOS.SYS, or MSDOS.SYS)
> * The command processor   (COMMAND.COM or aftermarket replacement)

>* The Boot Record

> The boot record begins on track 0, sector 1, side 0 of every diskette format-
>ted by the DOS FORMAT command. The boot record is placed on diskettes to
>produce an error message if you try to start up the system with a nonsystem
>diskette in drive A. For hard disks, the boot record resides on the first
>sector of the DOS partition. All media supported by DOS use one sector for
>the boot record.

>* Read Only Memory (ROM) BIOS Interface and Extensions

> The file IBMBIO.COM or IO.SYS is the interface module to the ROM BIOS.
>This file provides a low-level interface to the ROM BIOS device routines and
>may contain extensions or changes to the system board ROMs. Some compatibles do
>not have a ROM BIOS to extend, and load the entire BIOS from disk. (Sanyo 55x,
>Viasyn machines). Some versions of MSDOS, such as those supplied to Tandy, are
>named IBMBIO.COM but are not IBM files.

> These low-level interface routines include the instructions for performing
>operations such as displaying information on the screen, reading the keyboard,
>sending data out to the printer, operating the disk drives, and so on. It is
>the operating system's means of controlling the hardware. IBMBIO.COM contains
>any modifications or updates to the ROM BIOS that are needed to correct any
>bugs or add support for other types of hardware such as new disk drives. By
>using IBMBIO.COM to update the ROM BIOS on the fly when the user turns on their
>computer, IBM does not need to replace the ROM BIOS chip itself, but makes any
>corrections through the cheaper and easier method of modifying the IBMBIO.COM
>file instead.

> IBMBIO.COM also keeps track of hardware operations on an internal stack or
>"scratch pad" area for the operating system to save information such as
>addresses it will need, etc. An example of the use for this stack can be seen
>when running a program such as a word processor. If you have told the word
>processor to save your letter, it will write the data to your disk. During this
>time, if you start typing some more information, the keyboard generates a
>hardware interrupt. Since you don't want the process of writing the information
>to the disk to be interrupted, DOS allocates a slot in the stack for the
>keyboard's hardware interrupt and when it gets a chance, (probably after the
>data has been written to the disk), it can process that interrupt and pick up
>the characters you may have been typing. The STACKS= command in DOS 3.2+'s
>CONFIG.SYS file controls the number of stack frames availible for this

> IBMBIO.COM also reads your CONFIG.SYS file and installs any device drivers
>(i.e. DEVICE=ANSI.SYS) or configuration commands it may find there.

>* The DOS Program

> The actual DOS program is the file IBMDOS.COM or MSDOS.SYS. It provides a
>high-level interface for user (application) programs. This program consists of
>file management routines, data blocking/deblocking for the disk routines, and
>a variety of built-in functions easily accessible by user programs.

> When a user program calls these function routines, they accept high-level
>information by way of register and control block contents. When a user program
>calls DOS to perform an operation, these functions translate the requirement
>into one or more calls to IBMBIO.COM, MSDOS.SYS or system hardware to complete
>the request.

> This section is often referred to as the "kernel" by systems programmers.

>* The Command Interpreter

> The command interpreter, COMMAND.COM, is the part you interact with on the
>command line. COMMAND.COM has three parts. IBM calls them the "resident
>portion", the "initialization portion" and the "transient portion".

> IBM's original documentation spoke of installing alternate command
>interpreters (programs other than COMMAND.COM) with the SHELL= statement in
>CONFIG.SYS. Unfortunately, IBM chose not to document much of the interaction
>between IBMDOS.COM and IBMBIO.COM. By the time much of the interaction was
>widely understood, many commercial software programs had been written to use
>peculiarities of COMMAND.COM itself.

> Two programs exist that perform as actual "shells" by completely replacing
>COMMAND.COM and substituting their own command interpreter to use with the
>hidden DOS files. These are Command Plus, a commercial package, and the very
>interesting shareware 4DOS package. Both supply greatly enhanced batch
>language and editing capabilities.

>NOTE: DOS 3.3+ checks for the presence of a hard disk, and will default to
>      COMSPEC=C:\. Previous versions default to COMSPEC=A:\. Under some DOS
>      versions, if COMMAND.COM is not immediately availible for reloading
>      (i.e., swapping to a floppy with COMMAND.COM on it) DOS may crash.

>Resident Portion:

> The resident portion resides in memory immediately following IBMDOS.COM and
>its data area. This portion contains routines to process interrupts 22h
>(Terminate Address), 23h (Ctrl-Break Handler), and 24h (Critical Error Hand-
>ler), as well as a routine to reload the transient portion if needed. For DOS
>3.x, this portion also contains a routine to load and execute external com-
>mands, such as files with exensions of COM or EXE.

> When a program terminates, a checksum is used to determine if the application
>program overlaid the transient portion of COMMAND.COM. If so, the resident
>portion will reload the transient portion from the area designated by COMSPEC=
>in the DOS environment. If COMMAND.COM cannot be found, the system will halt.

> All standard DOS error handling is done within the resident portion of
>COMMAND.COM.  This includes displaying error messages and interpreting the
>replies to the "Abort, Retry, Ignore, Fail?" message.

> Since the transient portion of COMMAND.COM is so large (containing the
>internal commands and all those error messages), and it is not needed when the
>user is running an application it can be overlaid that program if that
>application needs the room.  When the application is through, the resident
>portion of COMMAND.COM brings the transient portion back into memory to show
>the prompt.  This is why you will sometimes see the message "Insert disk with
>COMMAND.COM". It needs to get the transient portion off the disk since it was
>overlaid with the application program.

> The initialization portion of COMMAND.COM follows the resident portion and is
>given control during the bootup procedure. This section actually processes the
>AUTOEXEC.BAT file. It also decides where to load the user's programs when they
>are executed. Since this code is only needed during startup, it is overlaid by
>the first program which COMMAND.COM loads.

> The transient portion is loaded at the high end of memory and it is the
>command processor itself. It interprets whatever the user types in at the
>keyboard, hence messages such as "Bad command or file name" for when the user
>misspells a command. This portion contains all the internal commands (i.e.
>COPY, DIR, RENAME, ERASE), the batch file processor (to run .BAT files) and
>a routine to load and execute external commands which are either .COM or
>.EXE files.

> The transient portion of COMMAND.COM produces the system prompt, (C>), and
>reads what the user types in from the keyboard and tries to do something with
>it. For any .COM or .EXE files, it builds a command line and issues an EXEC
>function call to load the program and transfer control to it.


> The system is initialized by a software reset (Ctrl-Alt-Del), a hardware reset
>(reset button), or by turning the computer on. The Intel x86 series processors
>always look for their first instruction at the end of their address space
>(0FFFF0h) when powered up or reset. This address contains a jump to the first
>instruction for the ROM BIOS.

> Built-in ROM programs (Power-On Self-Test, or POST, in the IBM) check machine
>status and run inspection programs of various sorts. Some machines set up a
>reserved RAM area with bytes indicating installed equipment (AT and PCjr).

> When the ROM BIOS finds a ROM on an adapter card, it lets that ROM take
>control of the system so that it may perform any set up necessary to use the
>hardware or software controlled by that ROM. The ROM BIOS searches absolute
>addresses C8000h through E0000h in 2K increments in search of a valid ROM.
>A valid ROM is determined by the first few bytes in the ROM. The ROM will have
>the bytes 55h, AAh, a length indicator and then the assembly language


read more »

Wed, 10 Jul 2002 03:00:00 GMT  
 [ 2 post ] 

 Relevant Pages 

1. Detecting When Startup Has Finished

2. Detecting when a Mac has finished booting up

3. Finishing the awk Job

4. OOA of a large already finished project

5. How to determine window has finished opening

6. Wait until program finish on CW5ee

7. A button disables after another button is finished..

8. Is C5EE ver.a the finished product

9. Distributing finished VW ST Smalltalk app

10. Finish my C5/MS-SQL Project - Houston, TX

11. Only print report after first one finished

12. Need quick Answer - must finish project today.


Powered by phpBB® Forum Software