• Please review our updated Terms and Rules here

EMS Standards (8-bit ISA)

pearce_jj

Veteran Member
Joined
May 14, 2010
Messages
2,808
Location
UK
On account of the other thread, I want to finish my EMS board but there is some question over how exactly EMS is supposed to work. Please help!

My understanding of LIM 4 is that:

  • EMS memory is addressed by 16KB page number, from 0..2047, giving a maximum of 32MB (2K x 16KB)
  • A least one 64KB page frame should be provided
  • The page frame accommodates four pages, hence at least four registers should be provided

So, say the frame is 64KB at E000h. Then, accessing between E000h and E3FF(F)h refers to the page whose number is stored in the first register, and E400..E7FF(F)h the second and so on. An application could also use the window as 2x 32KB or 1x 64KB by aligning the four registers accordingly.

But, since the hardware obviously has to have implemented 16-bit registers to support this, why didn't the spec allow for the full 1GB address space (64K pages)?
 
Consider the "when" of the EMS 4.0 specification. 3.0 was 1985; 4.0 was 1987. Who on Thor's green earth had 1GB of memory then? Who would have imagined $100 4TB hard drives?

Get real, man!
 
On account of the other thread, I want to finish my EMS board but there is some question over how exactly EMS is supposed to work. Please help!

My understanding of LIM 4 is that:

  • EMS memory is addressed by 16KB page number, from 0..2047, giving a maximum of 32MB (2K x 16KB)
  • A least one 64KB page frame should be provided
  • The page frame accommodates four pages, hence at least four registers should be provided

So, say the frame is 64KB at E000h. Then, accessing between E000h and E3FF(F)h refers to the page whose number is stored in the first register, and E400..E7FF(F)h the second and so on. An application could also use the window as 2x 32KB or 1x 64KB by aligning the four registers accordingly.

But, since the hardware obviously has to have implemented 16-bit registers to support this, why didn't the spec allow for the full 1GB address space (64K pages)?

What you have described is LIM 3.2 (functions 1-7). LIM 4.0 has more features including backfilling conventional memory and allocating raw pages (usually 4K). See http://www.phatcode.net/res/218/files/limems40.txt.

The 2048 page limit is only mentioned in one place (function 13). I'm not sure the original reasoning behind the limitation, but there are some programs that make the 32MB max assumption. I remember setting EMM386 up on a Windows 9x box such that there was around 64MB EMS...the install program for some games refused to install because they detected -32MB EMS free. I guess they were using a 16-bit signed int to calculate the EMS free in KB.

If you want to "safely" support more memory, you could internally have more pages but limit the pages per handle to 2048 and cap the unallocated page count at 2048.
 
My understanding of LIM 4 is that:

  • EMS memory is addressed by 64KB page number, from 0...65536 , giving a maximum of 4GB (16bit x 64KB)
  • Registers are 2 x 8bit = 16bit
  • The page frame accommodates 1 page.

So, say the frame is 64KB at E000h. Then, accessing between E000h and EFFFh refers to the page whose number is stored in the registers. An application would use the window as 1x 64KB by setting registers accordingly.

Max memory = 4GB...
 
Memory in the lower 640kB is used by the EMS driver to track the handles that could be in use. EMS 3.2 allows a maximum of 128 handles each defining a 64KB region that could be paged into the 64KB EMS window. EMS 4 shrinks the size of the pages to 16KB but increases the number of handles to 2048 for a total of 32MB. I think each handle uses 32 bytes so EMS 3.2 driver could use up 4KB for handle tracking while the EMS 4 driver might need 64KB to track handles. A 4GB EMS specification would require a real mode EMS driver using 8MB out of 640KB which would probably be a bit difficult.
 
Wow...I only read 255 handles with 0 being the system handle and 255 being an unassigned handle, with each 64K Page is mapped to a handle by a single Byte, you are right though it would take 64MB+ to map each of the pages in 4GB...Damn...
 
On the other hand, there's nothing in the spec that says you can't keep your table of descriptors/handles in a reserved area of EMS, is there? Of course, the address calculation gets a little messy...but it's doable.

But again, why would anyone want to do this? What existing programs could even take advantage of it?

Back in the day, I wrote like a lot of other authors--first try LIM, then XMS, then finally disk for more storage (also allow a combination of all three).
 
My understanding of LIM 4 is that:

  • EMS memory is addressed by 64KB page number, from 0...65536 , giving a maximum of 4GB (16bit x 64KB)
  • Registers are 2 x 8bit = 16bit
  • The page frame accommodates 1 page.

So, say the frame is 64KB at E000h. Then, accessing between E000h and EFFFh refers to the page whose number is stored in the registers. An application would use the window as 1x 64KB by setting registers accordingly.

Max memory = 4GB...

Your understanding is incorrect...read the standard I linked above.

krebizfan said:
Memory in the lower 640kB is used by the EMS driver to track the handles that could be in use. EMS 3.2 allows a maximum of 128 handles each defining a 64KB region that could be paged into the 64KB EMS window. EMS 4 shrinks the size of the pages to 16KB but increases the number of handles to 2048 for a total of 32MB. I think each handle uses 32 bytes so EMS 3.2 driver could use up 4KB for handle tracking while the EMS 4 driver might need 64KB to track handles. A 4GB EMS specification would require a real mode EMS driver using 8MB out of 640KB which would probably be a bit difficult.

Also incorrect.
 
OK so that all being the case, it seems reasonable to leave the board with 8-bit registers, since I can't see any obvious way to implement more than 4MB memory on the thing anyway. That seems to still meet LIM4 - it could never report more than 256 free pages anyway.
 
Back
Top