Memory from 640K to 1MB
Cameron McCormack
I was just thinking about all the stuff that's within the 640K to 1MB
region of memory, and how that corresponds to actual memory, if it all.
At the start of this region, you've got the mode 13h memory, then a bit
after that the CGA text mode memory, then the VGA text mode memory. Is
all of this memory the same memory that's in the SIMMs you put on the
motherboard, or is this some video memory on the video card itself?
Then you've got some ROM stuff, like the VGA ROM and the BIOS. I
assume that addresses here are just decoded in hardware to the relevant
ROM chips -- is this right? Also, the E000 segment - is that used for
anything, or can you just use it as some more memory (assuming you
haven't got DOS or Windows or anything using it)?
What I was wondering, was if you've got these areas of the address
space which map to ROMs, how do you access the memory which'd normally
be at that address? If you have, say, a single 32MB SIMM on your
motherboard, this memory doesn't just have gaps in places like F0000 -
FFFFF. There's a full 1MB of memory from byte 0 to byte FFFFF. But in
the PC the ROM hogs some of that address space... surely there must be
a way to address the memory, and not the ROM.
Thanks...
Cameron
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Henry Branchdale
This is going back a bit to the days of the 386/486 but...
Compaq DeskPro 386/486 's used to remap the region from: A 0000 -> F FFFF
(640K to 1M - 1) to FA 0000 -> FF FFFF ( ( 16M -384K ) to 16M - 1 )
This 384K region of memory was split into two areas: A 256K block and a 128K
block.
After the BIOS Power On Self Test the code in the BIOS would copy the BIOS
ROM area from ( E 0000 -> F FFFF ) to ( FE 0000 -> FF FFFF )
It would then disable the BIOS ROM and remap the 128K at just below 16M so
that it would appear at ( E 0000 -> F FFFF ) as well.
It would then Write Protect this region
Result: BIOS running in RAM i.e. shadow BIOS
The other 256K block from FA 0000 -> FD FFFF was available to COMPAQ
versions of utilities like EMM386.EXE (CEMM.EXE) and RAMDRIVE as available
memory.
Hope this is useful (if a bit dated)
Henry
Cameron McCormack <camer...@my-deja.com> wrote in message
news:7l7r87$mae$2...@autumn.news.rcn.net...
wbinvd
|hey...
|
|I was just thinking about all the stuff that's within the 640K to 1MB
|region of memory, and how that corresponds to actual memory, if it all.
|
|At the start of this region, you've got the mode 13h memory, then a bit
|after that the CGA text mode memory, then the VGA text mode memory. Is
|all of this memory the same memory that's in the SIMMs you put on the
|motherboard, or is this some video memory on the video card itself?
Normally, it's just video memory, but could be normal RAM if the DRAM
controller maps RAM there instead of passing read/write accesses to PCI.
The RAM that's hidden under A0000-BFFFF is usually used as SMRAM when
the CPU is in SMM (System Management Mode).
|
|Then you've got some ROM stuff, like the VGA ROM and the BIOS. I
|assume that addresses here are just decoded in hardware to the relevant
|ROM chips -- is this right? Also, the E000 segment - is that used for
|anything, or can you just use it as some more memory (assuming you
|haven't got DOS or Windows or anything using it)?
You know if it's used by scanning C0000-EFFFF for ROM headers:
WORD AA55 ;Signature
BYTE xxh ;# of 512 byte blocks
3 BYTEs ;FAR PTR init code (called by BIOS)
...
(last byte in image)
BYTE ;Checksum - all bytes in ROM image must add up to 0
; else it's not a valid ROM
Pseudo code:
Segment = C000h
Loop:
if Segment:[0]=AA55h AND all_bytes_in_image_add_up_to_0
CALL FAR PTR SEGMENT:3
segment = segment + (size_of_image_in_bytes/16)
else
segment = segment + (2k / 16)
If segment >= F000h, exit
jmp Loop
Don't expect to find your PCI card's ROM there since PCI ROMs are always
shadowed in RAM. All you'll find is the shadowed ROM image.
|
|What I was wondering, was if you've got these areas of the address
|space which map to ROMs, how do you access the memory which'd normally
|be at that address? If you have, say, a single 32MB SIMM on your
|motherboard, this memory doesn't just have gaps in places like F0000 -
|FFFFF. There's a full 1MB of memory from byte 0 to byte FFFFF. But in
|the PC the ROM hogs some of that address space... surely there must be
|a way to address the memory, and not the ROM.
It's possible to access that RAM; taht's what the BIOS does when it shadows
your PCI expansion card's BIOS. See your chipset manual (Host/PCI bridge)
on how to enable read and write accesses to RAM at A0000-FFFFFh
http://developer.intel.com/ if you have an intel chipset
http://www.opti.com/ if you have an OPTi chipset
http://www.sis.com.tw/ if you have a SiS chipset
http://www.via.com.tw/ if you have a VIA chipset
http://www.smsc.com/ if you have an SMSC chipset
http://www.tough.luck.dude.tw/ if you have an ALi chipset...
kgl...@seganet.com
On 1999-06-28 camer...@my-deja.com said:
>hey...
>I was just thinking about all the stuff that's within the 640K to
>1MB region of memory, and how that corresponds to actual memory, if
>it all.
>At the start of this region, you've got the mode 13h memory, then a
>bit after that the CGA text mode memory, then the VGA text mode
>memory.
You forgot MDA and Herc monochrome memory, which starts at B000h! :)
>Is all of this memory the same memory that's in the SIMMs
>you put on the motherboard...
No.
>...or is this some video memory on the video card itself?
Yes.
>Then you've got some ROM stuff, like the VGA ROM and the BIOS. I
>assume that addresses here are just decoded in hardware to the
>relevant ROM chips -- is this right?
No.
>Also, the E000 segment - is
>that used for anything, or can you just use it as some more memory
>(assuming you haven't got DOS or Windows or anything using it)?
Some of this space is -- or was -- used for EGA ROM.
>What I was wondering, was if you've got these areas of the address
>space which map to ROMs, how do you access the memory which'd
>normally be at that address?
Natively, you can't. But read on.
>If you have, say, a single 32MB SIMM
>on your motherboard, this memory doesn't just have gaps in places
>like F0000 - FFFFF. There's a full 1MB of memory from byte 0 to
>byte FFFFF. But in the PC the ROM hogs some of that address space...
>surely there must be a way to address the memory, and not the ROM.
You're re-inventing the wheel. All of this territory has already been
well-explored and well-documented way back in the early 1980s.
Here's the thing: using an upper memory manager (such as EMM386), you
=can= re-map memory from above the one megabyte boundary into some of
these lower "reserved" memory areas. See your DOS manual for details.
But that remapped memory can't be used as =DOS= memory. DOS memory
must be contiguous.
There's nothing magic about the memory addresses from A000h to FFFFh.
It's just that IBM, in designing the architecture for the original
PC, decided to reserve this area for use by various peripherals.
We often hear talk about the "DOS 640k limit." In reality, it isn't
=DOS= that limits us to 640k of lower memory; it's the IBM =architecture=
which imposes that limit.
DOS, itself, can use up to 1 full megabyte of contiguous memory if it's
available. And the 8086, 8088 and V20 processor chips -- used in the
original IBM PC and clones -- can also directly address up to 1 full
megabyte of memory.
But, as Bill Gates stated in 1981, "640k ought to be enough for anybody."
And it was. Even WIN-DOZE 1.xx ran in 640k of memory on an 8088-based
turbo XT-class machine.
Then Micro$loth concluded that a glitzy, superficial, dumbed-down, pointee-
clickee, bloated, resource-hogging MacIntosh-interface clone was to be
"the vision of the future" (read that as: "How can we continue to extract
more money from a dumbed-down, superficial, short-attention-spanned,
technically stupid public?")
"Y'know, we've said there's no future. Well, this is it."
- Blank Reg (from "Max Headroom")
.....................................................................
Return address is mangled to foil spambots. Remove all "g"s to e-mail.
Net-Tamer V 1.08X - Test Drive