VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

What happens to the memory that's mapped in the memory gaps? So the 386K memory in the UMA and 1MB in the extended memory at the 15-16MB gap, also the 3-4GB gap?

I currently have it mapped upwards in RAM(so essentially, the 386KB between 640K-1MB is mapped at 1MB+, while the old 1MB-15MB RAM is mapped between 1MB+386K and 16MB+. The same kind of principle applies to the 3-4GB gap, which is mapped to the end, while the final remaining RAM is mapped above 4GB(including any remainder from the lower megabytes.

So, with 1MB RAM:
0-640K=Direct mapped
1MB-(1MB+386K)=First memory hole mapped high

With 16MB RAM:
0-640K=Direct mapped
1MB-(1MB+386K)=First memory hole mapped high
(1MB+386K)-15M=lower part of the 15 MB RAM
16MB+=remainder upper part of the 15 MB RAM.

With 3GB+ RAM the same applies, but with the remainder mapped above 4GB(unusable with 32-bit CPU emulation).

Last edited by superfury on 2018-06-11, 12:27. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 8, by root42

User metadata
Rank l33t
Rank
l33t

Not sure what exactly your question is, but for example the UMA is re-mapped to 1024k+ because the area is reserved for BIOS and other ROMs from ISA cards etc.

Those ROMs will shadow the original RAM and make it unusable. Most BIOSs will have an option to cache the ROM contents in the original RAM, to make execution of BIOS and ROM code much faster, since old (E)EPROMs are quite slow, compared to DRAM or FP DRAM.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 2 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

My question is this: is the memory that's usually within the memory hole mapped higher in RAM(thus the memory holes actually resolve no RAM when the ROMs are disabled). From a program's point of view, having 1MB+386K(with 16MB physical RAM installed) of RAM within the memory holes makes 1MB and 386K of RAM appear at the end of the rest of the RAM. Basically simply adding that RAM to the end of the usable non-memory hole address space?

Is that correct behaviour?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 8, by root42

User metadata
Rank l33t
Rank
l33t

Well, it depends a bit on the CPU mode. In real mode you can only use EMS or XMS memory.
For EMS parts of the extended memory that was mapped above 1MB gets mapped into the UMA. This needs hardware support on 8086 and 80286 machines and a software driver on 386 machines.
For XMS the memory is copied in some buffer below 1MB and hence it is rather slow, usually.

For 386 and above the whole thing changes when working in protected mode. Here you get a flat memory model where you have 4GB of available address space and the OS dynamically maps this to physical memory locations or even pages on the hard disk (swap).

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 4 of 8, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:

My question is this: is the memory that's usually within the memory hole mapped higher in RAM(thus the memory holes actually resolve no RAM when the ROMs are disabled). From a program's point of view, having 1MB+386K(with 16MB physical RAM installed) of RAM within the memory holes makes 1MB and 386K of RAM appear at the end of the rest of the RAM. Basically simply adding that RAM to the end of the usable non-memory hole address space?

Is that correct behaviour?

it depends on bios.

when you enter protected mode, there may or may not be a hole visible at 15-16mb. Often machines with 32mb of ram and the hole only show 32mb ram, they dont have a hole and '33mb' etc.

sometimes enabling this in bios will stop all ram access over 15mb!

so it depends on bios. I dont think in all my pmode programming and writing a dos extender I ever saw something have a hole at 15mb and go up to 33mb etc. it didnt remap ram, the 1mb at 15mb just didnt show up.

also note with pci + isa difference. isa bus only can map to 16mb, but once you get more advanced chipsets get in the way of the isa bus.. so its also down to chipset as well.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 5 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

So if I understand it correctly, the physical RAM at the RAM chips on the location of the memory holes simply cannot be used and isn't remapped to the start/end of the remaining RAM? So with 4MB RAM installed, only 4MB-386K can be seen by the CPU(in 32-bit protected mode), same for 16MB only being able to access 16MB-386K-1MB in 32-bit protected mode? And with 4GB RAM, only 4GB-1GB-1MB-386K is available for CPU access in 64-bit mode?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Strangely enough, the AT has a different memory map for 4MB RAM than the Compaq Deskpro 386 does? The Compaq Deskpro 386 currently ends at 4MB mark(detecting 4MB RAM during POST), while the Compaq Deskpro 386 ends at 4MB+386KB RAM(while also detecting 4MB RAM during POST). Is that correct behaviour?

Edit: Looking at the results of the mem command, it matches the behaviour of PCJS, matching memory sizes for extended memory(conventional memory is 1KB less because it's taken up by the harddisk BIOS in UniPCemu)?
Edit: This is the case for both the Compaq Deskpro 386 and IBM AT configurations of both emulators.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 7 of 8, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie

The answer is that it varies.

Older (286/386/486) systems tend to remap part or all of the adaptor area. If you had a system with 1MB of RAM you wouldn't want to waste 384KB of it, so it would be split up into 640KB base and then 384KB extended, leaving the adaptor area empty save for BIOS/video/expansion cards. I have also seen where only 256KB was remapped, and 128KB remained accessible from $D0000-$EFFFF, or it was used to shadow VGA/BIOS ROMs.

On newer systems with more available RAM, presumably people stopped caring that much about a piddly 384KB, and it is not remapped. So some parts of the adaptor space will have usable RAM (Upper Memory Blocks). And the RAM that is "covered up" by the BIOS/video simply becomes inaccessible. On newer CPUs with built-in memory controller, the RAM that is normally inaccessible may actually be used behind-the-scenes when the CPU is in system management mode.

The memory hole at 15MB is usually an option in the BIOS, just to accomodate legacy stuff. When the memory hole is enabled, do they remap that 1MB instead of letting it go to waste? I don't know since I never used it, but either way would work.

Remapping or not remapping is only going to result in a slight change in the total amount of usable RAM. The important thing is that the same RAM should not be visible at two different addresses at the same time.

Reply 8 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

There's one exception there, though(mapping to two locatiins) Compaq Deskpro reserved RAM. It's located at FA0000-FFFFFF and remappable(double mapped for ROM shadowing purposes to the mid and low memory gaps) to the E0000-FFFFF range. Said RAM(the whole 386K area) can be write-protected(it's filled with shadow BIOS ROM copy, mapped mid and low then marked read-only through the register at memory location 80C00000 during BIOS initialization(during hard reset)).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io