Datadrainer wrote on 2022-01-23, 09:45:
The UMA (0xA0000–0xFFFFF which is 640KB to 1 MB) is not mapped to RAM chips, so if any chip in the bus want to use this space it can. The software just need to read or write there to program the chips reading there (that maybe chip registers or on board expansion memory I think). That is why it is important to avoid addressing overlap.
You got it. To make it even more clear, write it as "is not mapped to mainboard RAM chips". The UMA may very well be mapped to RAM chips. For example RAM chips on the MDA card, the CGA card, selectable areas of EMS cards or network card packet buffer RAM.
Datadrainer wrote on 2022-01-23, 09:45:
So that means from the point of view of a memory expansion board of, say, 1 MB you literally loose 384 KB.
Usually, you don't. In the 80s, you couldn't afford losing 384KB, RAM was way too expensive for that. Instead, there was some hole in the address space. The original IBM AT, if equipped with 1MB RAM used a memory layout consisting of 512KB conventional memory (from 0KB to 512KB) and 512KB extended memory (from 1024KB to 1536KB), with no memory between 512KB and 1024KB. This has the advantage of being easy to implement: You can build a 512KB bank from 18 chips (including parity) of 256K x 1 each, and you wire up one bank as conventional memory and the second bank as extended memory.
The original AT memory layout wasn't DOS-friendly, as you don't even get 640KB for DOS programs. You could at a 128KB ISA memory card to expand the conventional memory to 640KB. Also some later memory expansion cards had the option to map 128KB of their memory space into that range, a feature usually called "backfill".
Later AT-compatible mainboards used chipsets wth more complex addressing schemes, which were generally able to to split 1MB of memory into 640KB of conventional memory and 384KB of extended memory, so you are not using actual memory, even though you have a hole in the address space.
And now I understand too how programs such as HIMEM and EMM386 works. They allow to remap UMA unused parts to the RAM so some programs can be loaded there (or in HMA the same way).
You need to get a bit more into detail to understand the different options of memory management. HIMEM actually doesn't do anything about the UMA. HIMEM does two things: It configures the computer for HMA access, and tracks whether the HMA is in use or free (typically, you allocate the HMA to the DOS kernel using DOS=HIGH, so the HMA is in use all the time). It also contains a driver that allows copying memory between the standard 1MB XT-like address space and XMS at higher addresses. The straightforward way to do that is temporarily switching to protected mode to be able to access all the 16MB of the 286 address space (or 4GB of the 386 address space), and indeed, that's what DR-DOS HIMEM.SYS DOS. On the other hand Microsoft's HIMEM used a special undocumented debugging feature of the 286 processor, called "LOADALL" to circumvent the need to switch to protected mode.
HIMEM does not remap any memory at all. The only thing you could somehow call "remapping" is that HIMEM disables a PC/XT compatibility mode that makes the address space wrap around at FFFF:000F back to 0, so you get nearly 64KB of extra memory at FFFF:0010..FFFF:FFFF, which would alias to 0000:0 to 0000:FFEF on a classic PC/XT system.
There were 286 boards which allowed to not remap the whole 384KB of RAM "behind the UMA" to XMS, but instead map some of that RAM into the UMA. The NEAT ("New Enhanced AT") chipset by Chips & Technologies is a well-known example for this. If your board supports making memory available at UMA addresses, or you have RAM cards that put RAM into that range, you can make DOS aware of that memory using a UMB driver. Typical examples of drivers that enable UMBs on certain chipsets and tell DOS about it are UMBDRVR.SYS and UMBPCI.SYS. If the RAM is already available, and you just need to tell DOS about it, USE!UMBS.SYS is a minimal driver that does just that. The important point is that up to now we are talking about memory that actually is at addresses in the UMA area on the system bus.
EMM386 works in a completely different way: The 386 processor has a feature that allows software-controlled remapping between memory addresses seen by DOS software (or any other 16-bit software) and physical addresses on the bus. This enables multitasking of individual DOS environments, by providing different memory mappings for different "DOS VMs". Providing multiple DOS VMs is not implemented in EMM386, but is used in the windows 386 enhanced mode, or by DESQView, and this is why this operation mode of the 386 processor is called "virtual 8086 mode". Nevertheless, the software-controlled remapping is used by EMM386 to emulate EMS and to map unused UMA space to RAM way past 1MB. EMM386 also provides the API to tell DOS where it remapped memory to to provide UMBs.
for me the PC BIOS had to be in charge to detect and copy the expansion board BIOS to the RAM.
This actually is a common thing to do when there is enough RAM available, but this is not done on old PC/AT systems. Copying of ROM to RAM is called "shadowing" and is used to provide faster BIOS execution. 386DX and 486 processors can access RAM 32-bits at a time, while only very few 386DX boards provide 32-bit access to the mainboard ROM BIOS, and you can't get 32-bit access to extension BIOSes located on ISA cards. Furthermore, typical ROM chips require extra wait states. So as performance optimization, the contents of the mainboard BIOS and expansion BIOS ROMs can be copied to RAM. There are two ways to handle it: Either the BIOS does it, with support from the mainboard chipset, which redirects certain areas of UMA to RAM instead of the ISA bus or the mainboard BIOS. Another way is letting EMM386 do it: EMM386 can also copy ROM to extended memory and use the memory remapping feature of the 386 processor to make it look as if the copy were at the UMA address which is actually occupied by the BIOS.
Datadrainer wrote on 2022-01-23, 09:45:
So, to go back to the Trident problem of @mogwaay, if the card require a specific address range in the UMA, that should be RAM independent, so why the screen freezes when trying to scroll when there is not enough RAM? Could the BIOS of the computer allocate arbitrary space in the UMA for some embedded chip of the motherboard depending of the amount of RAM installed creating an overlapping with the BIOS address space of this card?
The memory upgrade (from 256KB to 512KB) that made the system work applies to VGA memory, not mainboard memory. The Trident card always occupies selectable areas of the A000..BFFF space for video RAM access, and the C000..C7FF range for the video BIOS. The freezes were very likely completely unrelated to any UMA memory layout. Furthermore, the size of memory by itself doesn't matter, because everything the OP did doesn't require more than the 256KB of RAM which was already present on the original VGA.
The important point is that the original VGA card uses 32-bit memory access (by using 8 chips providing 4 bits at 64kilo-addresses, so all chips together provide 32 bits at 64 kilo-addresses, for a total of 256KB). The Trident chips mostly support up to 1MB of RAM (the 9000i-3 might be a cost-reduced version that is limited to 512KB), using different chips: They use chips that provide four bits each at 256 kilo-addresses. To equip a TVGA9000i-3 with 256KB of RAM, you just install two chips, which make 256 kiloaddresses, consisting of 8 bits each, so the TVGA chip can not access more than 8 bits at once. This acutally is a challenge for that chip, because the VGA programming model provides a multitude of memory access methods designed around the capability of accessing 32 bits of video RAM at once. When you upgrade a TVGA9000 card from 256KB to 512KB of RAM, you also upgrade the memory data path width from 8 bits to 16 bits, greatly reducing the stress on the TVGA chip. The freezes in the OP were most likely caused by the TVGA chip not being able to correctly handle the 8-bit RAM data path under certain access patterns (like scrolling), possibly the problems only occurs when video memory access and video BIOS access interleave (which is the case when the BIOS ROM scrolls text in the VGA RAM, unless the BIOS is shadowed (see above). The upgraded video RAM allowed the TVGA chip to handle the memory access in a way that works without problems.
