- [0040h:0013h] - Base Memory Size In KBytes(Word) → System BIOS remaining memory.
- [0040h:000Eh] - Segment Of Extended BIOS Data Segment(Word) → [System BIOS current memory segment]:[0000h] → offset 00h - Length Of EBDA In kilobytes(Byte) → Has been used memory.
EBDA usage:
回覆刪除During pre-boot phase, multiple software entities may need to use EBDA for storing data. If EBDA is incorrectly allocated, there is a chance that other users of EBDA will not find their data.
Some basic information:
Memory location 40:0e (2 bytes) contains EBDA segment.
Memory location 40:13 (2 bytes) contains size of conventional memory in units of 1K
First byte of EBDA contains size of EBDA in units of 1K.
It is reasonable to assume that the value in 40:0e is 0x40 times the value in 40:0e.
For example, in a system with 4k EBDA -
40:13=0x27c
40:0e=0x9f00
9f00:0=4
If a software program wants to allocate EBDA, it should go through the following steps -
1. Check if EBDA is currently allocated. This can be done by checking the BDA location (40:0e). If this location is 0, no one has allocated EBDA. Another way to find out existing EBDA segment is to call int 15, functions C0, and int 15 function C1.
2. If an EBDA exists, the software must shift the existing EBDA
down (to lower memory address). The new EBDA segment is equal to the old EBDA segment minus (extra EBDA space needed/16). Extra EBDA space needed must be a multiple of 1k. E.g. if the existing EBDA is at 9f00:0, and an Option ROM needs 2 k more, it should copy 9f00:0-9fff:f to 9e80:0-9f7f:f. It can now use the 2k memory starting 9f80:0. It must also update the EBDA size, EBDA segment, and conventional memory size accordingly.
40:13=0x27a
40:0e=0x9e80
9e80:0=6
How to get EBDA data segment in int13 handle?
回覆刪除answer: 2 solutions
(1). Add a signature(such as “ABCD”) when get the EBDA memory in POST stage. In run time Int13 handle, check the signature first, if it doesn’t match signature, search it in memory(1M).
(2). When you allocate the memory, please keep the current used EBDA size(such as: BYTE length of EBDA in kilobytes = 0x01, 0x03, or 0x06 that unit is K(1024 bytes)) that is the offset.
After enter to int13h handle, get current EBDA segment DS = 40h:0Eh, BYTE length of EBDA in kilobytes = DS:000h.
Offset is 0x01. Device A’s data segment = [current EBDA segment] + ([current length of EBDA] – 0x01) << 6
Offset is 0x03. Device B’s data segment = [current EBDA segment] + ([current length of EBDA] – 0x03) << 6
Offset is 0x06. data segment = [current EBDA segment] + ([current length of EBDA] – 0x06) << 6
作者已經移除這則留言。
回覆刪除Format of Extended BIOS Data Area (IBM):
回覆刪除Offset Size Description (Table M001)
00h BYTE length of EBDA in kilobytes
01h 15 BYTEs reserved
17h BYTE number of entries in POST error log (0-5)
18h 5 WORDs POST error log (each word is a POST error number)
22h DWORD Pointing Device Driver entry point
26h BYTE Pointing Device Flags 1 (see #M002)
27h BYTE Pointing Device Flags 2 (see #M003)
28h 8 BYTEs Pointing Device Auxiliary Device Data
30h DWORD Vector for INT 07h stored here during 80387 interrupt
34h DWORD Vector for INT 01h stored here during INT 07h emulation
38h BYTE Scratchpad for 80287/80387 interrupt code
39h WORD Timer3: Watchdog timer initial count
3Bh BYTE ??? seen non-zero on Model 30
3Ch BYTE ???
3Dh 16 BYTEs Fixed Disk parameter table for drive 0 (for older machines which don't directly support the installed drive)
4Dh 16 BYTEs Fixed Disk parameter table for drive 1 (for older machines which don't directly support the installed drive)
5Dh-67h ???
68h BYTE cache control
bits 7-2 unused (0)
bit 1: CPU cache failed test
bit 0: CPU cache disabled
69h-6Bh ???
6Ch BYTE Fixed disk: (=FFh on ESDI systems)
bits 7-4: Channel number 00-0Fh
bits 3-0: DMA arbitration level 00-0Eh
6Dh BYTE ???
6Eh WORD current typematic setting (see INT 16/AH=03h)
70h BYTE number of attached hard drives
71h BYTE hard disk 16-bit DMA channel
72h BYTE interrupt status for hard disk controller (1Fh on timeout)
73h BYTE hard disk operation flags
bit 7: controller issued operation-complete INT 76h
bit 6: controller has been reset
bits 5-0: unused (0)
74h DWORD old INT 76h vector
78h BYTE hard disk DMA type typically 44h for reads and 4Ch for writes
79h BYTE status of last hard disk operation
7Ah BYTE hard disk timeout counter
7Bh-7Dh
7Eh 8 WORDs storage for hard disk controller status
8Eh-E6h
E7h BYTE floppy drive type
bit 7: drive(s) present
bits 6-2: unused (0)
bit 1: drive 1 is 5.25" instead of 3.5"
bit 0: drive 0 is 5.25"
E8h 4 BYTEs ???
ECh BYTE hard disk parameters flag
bit 7: parameters loaded into EBDA
bits 6-0: unused (0)
EDh BYTE ???
EEh BYTE CPU family ID (03h = 386, 04h = 486, etc.) (see INT 15/AH=C9h)
EFh BYTE CPU stepping (see INT 15/AH=C9h)
F0h 39 BYTEs ???
117h WORD keyboard ID (see INT 16/AH=0Ah)
(most commonly 41ABh)
119h BYTE ???
11Ah BYTE non-BIOS INT 18h flag
bits 7-1: unused (0)
bit 0: set by BIOS before calling user INT 18h at offset 11Dh
11Bh 2 BYTE ???
11Dh DWORD user INT 18h vector if BIOS has re-hooked INT 18h
121h and up: ??? seen non-zero on Model 60
3F0h BYTE Fixed disk buffer (???)
The low memory size is stored in the BIOS Data Area (BDA) by POST during system initialization in a 16-bit field called LowMemorySize. ROM Extensions or other software that uses memory from the end of available low memory must reduce this field by the amount of memory reserved so that the operating system and applications will not overwrite the reserved memory. This technique is used by the BIOS itself during POST to establish the Extended BIOS Data Area (EBDA), a 1KB region located at the top of physical low memory.
回覆刪除