Weird fact: A number of AT clones with 1 MB on the motherboard could either run it as 640K losing the other 384K or split into 512K of conventional and 512K of extended which required a 128K memory board to reach 640K of conventional. BIOS updates to fix that happened fast
EMS 4.0 functions 1-15 are the same as EMS 3.2 for backwards compatibility. EMS 3.2 only had a single 64K page frame. Physical pages 0-3 (16K each) are always this page frame, even with EMS 4.0 drivers.Can a program just use function 2 to get the page frame base address and only use physical page 0 for mapping?
There is another function called 25 (GET MAPPABLE PHYSICAL ADDRESS ARRAY) that returns a full list of physical pages. Is the address returned from function 2 always physical page 0?
Yes, the page frame returned by function 2 will always be 64K. EMS 4.0 has the possibility of being configured with no page frame, in which case function 2 will return ah=80h ("software error"). An example of this would be EMM386 with FRAME=NONE.So function 2 will always get the address of the beginning of 4 16K pages (0, 1, 2, and 3)? Can it ever be shorter than 64K
So function 2 will always get the address of the beginning of 4 16K pages (0, 1, 2, and 3)? Can it ever be shorter than 64K
;* Check_EMS - Make sure that EMS servicer is in.
; ----------------------------------------------
;
; Returns carry set if not.
;
limint equ 67h ; EMS interrupt
LIM_Header label byte ; the LIM header
db 'EMMXXXX0'
LIM_Len equ $-LIM_Header
LIM_Detected db 0 ; nonzero if LIM handler detected
Check_EMS proc near private
test cs:LIM_Detected,-1
jnz Check_EMS2 ; it's okay
push ax
push si
push di
push es
xor ax,ax
mov es,ax
mov es,word ptr es:[4*limint+2] ; get EMM segment
mov di,10
lea si,LIM_Header
mov cx,LIM_Len
cld
repe cmps byte ptr cs:[si],es:[di] ; check for header
pop es
pop di
pop si
pop ax
stc
jne Check_EMS2 ; if nowhere
mov cs:LIM_Detected,1 ; we have it
clc
Check_EMS2:
ret
Check_EMS endp
Some systems had shadow memory which placed RAM in the 640-1MB region with copies of the ROMs to make the system faster. That did prevent the memory being used as extended.
This issue predates me, but I was looking through the XMS specification and it talks about backward compatibility with programs that would take an allocation of extended memory before HIMEM.SYS existed. One was to allocate memory upward by placing a VDISK-compatible header. Another was to allocate from the top of memory down, by hooking the interrupt to determine the amount of extended memory in the system and subtracting the allocation. A hack but I guess it worked.* Just to prove how annoying the term extended memory could be, UCSD Pascal when allocated 128K referred to the second block of 64K as extended memory. Troubleshooting problems on a 5170 where UCSD Pascal was installed on a VDISK in IBM extended memory could result in questions to figure out which form of extended memory was creating the issue. Poor management for UCSD Pascal solved the problem by having it largely disappear from the market before large numbers could afford to install more than a MB on a 286.