Conversation
Contributor
|
Great job @ghaerr Now we have the maximum we can squeeze in terms of memory on ELKS with XMS, HMA and UMB! And it makes it easier to port heavier programs. |
Contributor
|
On 486 with 10MB ram drive, with /bin copied to the the /mnt ramdrive, export PATH=/mnt everything flies! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes the default configurations to compile in support for XMS and HMA, so that users don't have to reconfigure and recompile to get the most out of whatever machine they may be booting from.
By default, hma=kernel is set in /bootopts, so if the machine has XMS memory available and a working A20 gate, the kernel will be loaded into HMA automatically, saving ~64K RAM.
By default, xmsbuf=0 in /bootopts, so the machine won't automatically use XMS buffers unless this line is removed, or set to the number of xms buffers desired. The default is now 500 (=500K of system buffers) in the case xmsbuf= is missing. This is turned off since there is some chance of data loss on a system crash with a large amount of XMS buffers, or if the system is rebooted without syncing. When XMS buffers are disabled, the default setting of 64 EXT buffers (=64k) is used out of main memory.
Even though XMS buffers are disabled by default, the XMS ramdisk is also compiled in and can be activated by executing
ramdisk /dev/ssd make 1024, for instance, to create a 1M XMS ramdisk. The /dev/rd0 ramdisk using main memory is also compiled in, and also activated usingramdisk.The maximum XMS buffers possible is 2975, which is 2.975MB of buffers. The maximum XMS ramdisk is 16MB. Both are subject to the max XMS memory reported by the BIOS.
In previous versions, XMS was also compiled in but always activated. This caused a crash on 8086 systems without extended memory. This should not happen with this version, since the kernel is now using a BIOS call to determine whether and how much XMS memory is present. This should still work on ancient 8086 systems, which will effectively report zero XMS, thus disabling XMS. In other words, XMS support is pretty much fully automatic, with the user just specifying XMS buffers if wanted in /bootopts.
The images created by the GitHub CI runner for this PR can be used to test HMA and XMS.
NOTE: At this time, the PC-98 version has not had the XMS memory size query implemented, and has a fake "stubbed-in" 4M XMS reported. If the A20 gate is still operational on PC-98 machines with no XMS, this may cause boot failure unless hma=kernel is commented out. All this will be fixed once we figure out how to find out the amount of extended memory present on PC-98 machines.