<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://www.vogonswiki.com/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Enigma</id>
		<title>Vogons Wiki - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://www.vogonswiki.com/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Enigma"/>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php/Special:Contributions/Enigma"/>
		<updated>2026-04-19T12:43:14Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.30.2</generator>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:List_of_games_that_support_AWE_synth&amp;diff=3562</id>
		<title>Talk:List of games that support AWE synth</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:List_of_games_that_support_AWE_synth&amp;diff=3562"/>
				<updated>2019-04-03T09:26:53Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: Created page with &amp;quot;The description states:  For these games, selecting AWE32 as the music device provides wavetable-quality MIDI output, utilizing the built-in ROM bank of the EMU8000 (or sound...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The description states:&lt;br /&gt;
&lt;br /&gt;
For these games, selecting AWE32 as the music device provides wavetable-quality MIDI output, utilizing the built-in ROM bank of the EMU8000 (or sound fonts loaded into the AWE RAM).&lt;br /&gt;
&lt;br /&gt;
Which DOS game actually supports sound fonts loaded to the AWE RAM and which tool is required to preload a SF from DOS to AWE RAM that the game utilizes it?&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Athlon_Motherboards&amp;diff=3020</id>
		<title>Talk:Athlon Motherboards</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Athlon_Motherboards&amp;diff=3020"/>
				<updated>2016-11-07T12:51:19Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Ali/SIS Socket A chipsets are missing.&lt;br /&gt;
&lt;br /&gt;
The MP chipsets are not mentioned.&lt;br /&gt;
&lt;br /&gt;
The PCI arbitration errata is described too generic, indicating more issues than actually occur.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Athlon_Motherboards&amp;diff=3019</id>
		<title>Talk:Athlon Motherboards</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Athlon_Motherboards&amp;diff=3019"/>
				<updated>2016-11-07T12:48:47Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Ali/SIS Socket A chipsets are missing.&lt;br /&gt;
&lt;br /&gt;
The PCI arbitration errata is described too generic, indicating more issues than actually occur.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Athlon_Motherboards&amp;diff=3018</id>
		<title>Talk:Athlon Motherboards</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Athlon_Motherboards&amp;diff=3018"/>
				<updated>2016-11-07T12:48:06Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: Created page with &amp;quot;The Ali Socket A chipsets are missing.  The PCI arbitration errata is described too generic, indicating more issues than actually occur.&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Ali Socket A chipsets are missing.&lt;br /&gt;
&lt;br /&gt;
The PCI arbitration errata is described too generic, indicating more issues than actually occur.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=User_talk:Enigma&amp;diff=3017</id>
		<title>User talk:Enigma</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=User_talk:Enigma&amp;diff=3017"/>
				<updated>2016-11-07T12:47:59Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: Blanked the page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=User_talk:Enigma&amp;diff=3016</id>
		<title>User talk:Enigma</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=User_talk:Enigma&amp;diff=3016"/>
				<updated>2016-11-07T12:46:51Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: Created page with &amp;quot;The Ali Socket A chipsets are missing.  The PCI arbitration errata is described too generic, indicating more issues than actually occur.&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Ali Socket A chipsets are missing.&lt;br /&gt;
&lt;br /&gt;
The PCI arbitration errata is described too generic, indicating more issues than actually occur.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=ATI&amp;diff=1839</id>
		<title>ATI</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=ATI&amp;diff=1839"/>
				<updated>2015-12-19T13:57:47Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* 3D Rage II */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;ATi Technologies produced graphics cards from the '80s through the mid '00s until merging with AMD in 2006. AMD still produces graphics cards today.&lt;br /&gt;
&lt;br /&gt;
== ATi Wonder Series ==&lt;br /&gt;
&lt;br /&gt;
The '''ATi Wonder series''' represents some of the first [[graphics]] add on products for [[IBM]] [[Personal computer|PCs]] and compatibles introduced by [[ATi Technologies]] in the mid to late 1980s. These cards were unique at the time as they offered the end user a considerable amount of value by combining support for multiple graphics standards (and monitors) into a single card. The VGA Wonder series added additional value with the inclusion of a [[Bus mouse|bus mouse port]], which normally required the installation of a dedicated [[Microsoft Bus Mouse]] adapter.&lt;br /&gt;
&lt;br /&gt;
The VGA Wonder series later merged with the [[ATI Mach]] series of cards in 1990. The [[ATi Graphics Ultra]] (VRAM) and [[ATi Graphics Vantage]] (DRAM) cards both featured independent VGA Wonder ASICs in addition to their Mach8 8514 compatible [[coprocessor chips]]. The Graphics Ultra was later renamed the VGA Wonder GT. In 1992, their following [[product line]], the Mach32, integrated the VGA wonder core and coprocessor into a single IC. At this point the VGA Wonder line was cancelled and replaced with a cost reduced DRAM based version of Mach32 known as the &amp;quot;ATi Graphics Wonder&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
===Graphics Solution (CGA)===&lt;br /&gt;
[[File:ATI Hercules Card 1986.xcf|thumb|One of the early graphics cards from ATI Technologies: a ''Graphics Solution Rev 3'' [[Hercules Graphics Card|Hercules]] graphics card from 1986. As can be seen from the PCB the layout was done in 1985, whereas the marking on the central chip CW16800-A says &amp;quot;8639&amp;quot; meaning that chip was manufactured week 39, 1986.]]&lt;br /&gt;
''Release Date: 1986''&lt;br /&gt;
&lt;br /&gt;
'''ATi Graphics Solution Rev 3'''&lt;br /&gt;
* [[Chipset]]: ATI CW16800-A&lt;br /&gt;
* Supports: [[Hercules Graphics Card]] mode&lt;br /&gt;
* Port: 8-bit PC/XT bus&lt;br /&gt;
&lt;br /&gt;
'''ATi Color Emulation Card '''&lt;br /&gt;
* Did at least support CGA graphics output to a [[TTL Monochrome]] monitor&lt;br /&gt;
&lt;br /&gt;
'''ATi Graphics Solution plus (1987)'''&lt;br /&gt;
* [[Chipset]]: ATI CW16800-B&lt;br /&gt;
* Supports CGA, [[Plantronics Colorplus]] CGA &amp;amp; [[Hercules Graphics Card]] graphics modes&lt;br /&gt;
* Compatible with MDA, CGA (and therefore also EGA displays), [[DIP switch]] selectable&lt;br /&gt;
* 64kb of DRAM&lt;br /&gt;
* Port: 8-bit PC/XT bus&lt;br /&gt;
'''Graphics Solution Plus SP'''&lt;br /&gt;
* Chipset: ATI CW16800-B&lt;br /&gt;
* Adds Serial/Parallel Ports&lt;br /&gt;
'''Graphics Solution SR'''&lt;br /&gt;
* Chipset: ATI CW16800-B&lt;br /&gt;
* Uses Static RAM&lt;br /&gt;
'''ATi Small Wonder Graphics Solution (1988)'''&lt;br /&gt;
* Chipset: ATI 18700&lt;br /&gt;
* Also known as Graphics Solution Single Chip or just GS-SC&lt;br /&gt;
* Single-chip version of the Graphics Solution plus&lt;br /&gt;
* 64kb of static RAM&lt;br /&gt;
* Composite Output&lt;br /&gt;
'''Graphics Solution Single Chip or GS-SC with Game (1988)'''&lt;br /&gt;
* Includes a [[game port]]&lt;br /&gt;
* Lacks external [[composite connector]]&lt;br /&gt;
&lt;br /&gt;
===EGA Wonder===&lt;br /&gt;
''Release Date: 1987''&lt;br /&gt;
&lt;br /&gt;
'''ATi EGA Wonder''' (March 1987)&lt;br /&gt;
* Chipset: ATI16899-0 + CHIPS P86C435&lt;br /&gt;
* Supports CGA, Hercules mono &amp;amp; EGA graphics modes&lt;br /&gt;
* Removes support for plantronics mode/Single-page Hercules mode/composite output&lt;br /&gt;
* Compatible with MDA, CGA and EGA displays (DIP switch selectable)&lt;br /&gt;
* [[Internal composite port]] for machines such as [[IBM 5155 Portable]]&lt;br /&gt;
* 256kb DRAM&lt;br /&gt;
* Port: 8-bit PC/XT bus&lt;br /&gt;
* Original MSRP: $399&lt;br /&gt;
'''ATi EGA Wonder 800'''&lt;br /&gt;
* Added support for extended EGA text and graphics modes (requires [[multisync monitor]])&lt;br /&gt;
* Added support for 16-colour VGA modes&lt;br /&gt;
'''ATi EGA Wonder 800+'''&lt;br /&gt;
* Rebadged VGA Edge lacking the analogue [[VGA port]]&lt;br /&gt;
* Chipset: ATI 18800&lt;br /&gt;
* Can auto-detect monitor type connected (DIP switches no longer present)&lt;br /&gt;
&lt;br /&gt;
===VGA Wonder===&lt;br /&gt;
''Release Date: 1987''&lt;br /&gt;
&lt;br /&gt;
'''ATi VIP or VGA Improved Performance (1987)'''&lt;br /&gt;
&lt;br /&gt;
* Chipset: ATi 16899-0 &amp;amp; Chips P82C441&lt;br /&gt;
* Supports CGA, Hercules mono, EGA &amp;amp; VGA graphics with Softsense automatic mode switching&lt;br /&gt;
* Compatible with MDA, CGA, EGA and VGA displays (DIP switch selectable)&lt;br /&gt;
* 9-pin TTL and 15-pin analogue connectors&lt;br /&gt;
* 256kb DRAM&lt;br /&gt;
* Port: 8-bit PC/XT bus&lt;br /&gt;
* Original MSRP: $449 ($99 for Compaq expansion module)&lt;br /&gt;
'''ATi VGA Wonder (1988)'''&lt;br /&gt;
* Chipset: ATI 18800&lt;br /&gt;
* Adds support for SVGA graphics modes&lt;br /&gt;
* Adds support for monitor auto-sensing (switchless configuration)&lt;br /&gt;
* Uses on-board EEPROM to store configuration information&lt;br /&gt;
* 256kb or 512kb DRAM&lt;br /&gt;
* Port: 8-bit PC/XT bus&lt;br /&gt;
'''ATi VGA Edge 8'''&lt;br /&gt;
* Cost Reduced VGA Wonder&lt;br /&gt;
* 256KB DRAM&lt;br /&gt;
'''ATi VGA Wonder 16 (1988)'''&lt;br /&gt;
* Speed enhancements due to a wider bus&lt;br /&gt;
* VGA pass through connector&lt;br /&gt;
* Bus mouse connector&lt;br /&gt;
* 256KB or 512KB DRAM&lt;br /&gt;
* Port: [[16-bit]] PC/AT bus (ISA), [[8-bit]] compatible&lt;br /&gt;
* Original MSRP: $499 or $699 respectively&lt;br /&gt;
'''ATi VGA Edge-16'''&lt;br /&gt;
* Cost reduced VGA Wonder 16&lt;br /&gt;
* Lacks the bus mouse connector and the digital TTL output&lt;br /&gt;
* 256kb DRAM (not expandable to 512kb)&lt;br /&gt;
'''ATi VGA Wonder+ (1990)'''&lt;br /&gt;
[[File:ATI Wonder.jpg|right|thumb|ATI VGA Wonder+]]&lt;br /&gt;
* Chipset: ATI 28800-2, -4, or -5&lt;br /&gt;
* Based on a new chipset which claimed to offer speeds rivalling VRAM based cards&lt;br /&gt;
* Dual page mode memory access&lt;br /&gt;
* Dynamic CPU/CRT interleaving&lt;br /&gt;
* 256KB or 512KB DRAM&lt;br /&gt;
'''ATi VGA Integra (1990)'''&lt;br /&gt;
* Cost reduced version based on new ATi 28800 ASIC&lt;br /&gt;
* Lacks bus mouse connector&lt;br /&gt;
* Uses a much smaller PCB with a surface mount BIOS &amp;amp; RAMDAC&lt;br /&gt;
* Supports SVGA Graphics with 72&amp;amp;nbsp;Hz refresh rates&lt;br /&gt;
* 512KB DRAM&lt;br /&gt;
'''ATi VGA Basic-16 (1990)'''&lt;br /&gt;
* PCB layout similar to VGA Integra but using cheaper RAMDAC&lt;br /&gt;
* Only supports the basic 60&amp;amp;nbsp;Hz VGA modes of the IBM VGA standard from 1987&lt;br /&gt;
* 256KB DRAM (not upgradable)&lt;br /&gt;
'''ATi VGA Charger (1991)'''&lt;br /&gt;
* Similar to VGA Basic-16, but can be upgraded to 512KB&lt;br /&gt;
'''ATi VGA Wonder XL (May 1991)'''&lt;br /&gt;
* Sierra RAMDAC adds support for 15-bit colour in 640x480@72&amp;amp;nbsp;Hz, 800x600@60&amp;amp;nbsp;Hz&lt;br /&gt;
* Supports a flicker-free vertical refresh rate of 72&amp;amp;nbsp;Hz&lt;br /&gt;
* 256KB, 512KB or 1MB DRAM&lt;br /&gt;
* Original MSRP: $229, $349, $399 respectively&lt;br /&gt;
'''ATi VGA Stereo·F/X'''&lt;br /&gt;
[[File:Vgafx.JPG|400px|right|thumb|ATi VGA Stereo·F/X]]&lt;br /&gt;
* Chipset: ATI 28800&lt;br /&gt;
* Combines a VGA Wonder XL with a Sound Blaster 1.5&lt;br /&gt;
* Features &amp;quot;fake&amp;quot; stereo sound&lt;br /&gt;
* 512KB or 1MB DRAM&lt;br /&gt;
'''ATi VGA Wonder XL24 (1992)'''&lt;br /&gt;
* Contains a Brooktree Bt481KPJ85 RAMDAC that adds support for hi and true colour graphics modes&lt;br /&gt;
* 512KB or 1MB DRAM&lt;br /&gt;
'''ATi VGA Wonder 1024'''&lt;br /&gt;
* A series of OEM cost reduced versions of several VGA Wonder models&lt;br /&gt;
* Typically lacks the bus mouse connector and/or the digital TTL output&lt;br /&gt;
&lt;br /&gt;
== ATi Mach series ==&lt;br /&gt;
&lt;br /&gt;
The ATi '''Mach''' line was a series of [[2D computer graphics|2D graphics accelerators]] for [[personal computer]]s developed by [[ATI Technologies]]. It became an extension (and eventual successor) to the ATI Wonder series of cards. The first chip in the series was the ATi Mach8. It was essentially a clone of the IBM 8514/A with a few notable extensions such as Crystal fonts. Being one of the first graphics accelerator chips on the market, the Mach8 did not have an integrated VGA core. In order to use the first Mach8 coprocessor cards, a separate VGA card was required. This made ownership considerably expensive. A temporary solution was presented with the ATi Graphics Ultra/Vantage cards, which combined an ATi 8514 Ultra and VGA Wonder+ into a single card (though using discrete ICs). The Mach32 chip was the follow-up to the Mach8, which finally featured an integrated VGA core, true colour support and a 64-bit datapath to internal memory.&lt;br /&gt;
&lt;br /&gt;
===Mach 8===&lt;br /&gt;
&lt;br /&gt;
''Released: 1990''&lt;br /&gt;
*[[IBM 8514|IBM 8514/A]] clone&lt;br /&gt;
*Support for up to 8-bit color modes&lt;br /&gt;
*Optional VGAWonder 2 (28800) graphics core (with dedicated 256–512&amp;amp;nbsp;KB DRAM)&lt;br /&gt;
*512&amp;amp;nbsp;KB or 1&amp;amp;nbsp;MB available with either DRAM or VRAM&lt;br /&gt;
*Port: ISA, MCA&lt;br /&gt;
The Mach 8 chip was used on the following ATI products:&lt;br /&gt;
&lt;br /&gt;
*8514 Ultra (VRAM, coprocessor only)&lt;br /&gt;
*8514 Vantage (DRAM, coprocessor only)&lt;br /&gt;
*Graphics Vantage (DRAM)&lt;br /&gt;
*Graphics Ultra (VRAM)&lt;br /&gt;
*VGAWonder GT (Repackaged Graphics Ultra, 1&amp;amp;nbsp;MB RAM standard)&lt;br /&gt;
&lt;br /&gt;
===Mach 32===&lt;br /&gt;
&lt;br /&gt;
''Released: 1992''&lt;br /&gt;
*[[32-bit]] [[graphical user interface|GUI]] accelerator with basic [[DOS]] support&lt;br /&gt;
*Limited [[VESA BIOS Extensions|VESA VBE]] support&lt;br /&gt;
*Support for 15&amp;amp;nbsp;bbp, 16&amp;amp;nbsp;bbp and 24&amp;amp;nbsp;bbp colour modes added&lt;br /&gt;
*Video memory: 1 or 2&amp;amp;nbsp;MB [[Dynamic random access memory|DRAM]] or [[Dynamic random access memory#Video DRAM .28VRAM.29|VRAM]]&lt;br /&gt;
*Memory interface: [[64-bit]]&lt;br /&gt;
*Port: [[Industry Standard Architecture|ISA]], [[Extended Industry Standard Architecture|EISA]], [[VESA local bus|VLB]], [[Peripheral Component Interconnect|PCI]], [[Micro Channel Architecture|MCA]]&lt;br /&gt;
*Integrated VGA core&lt;br /&gt;
*100% compatible with IBM 8514/A&lt;br /&gt;
&lt;br /&gt;
The Mach 32 chip was used on the following ATI products:&lt;br /&gt;
*Graphics Wonder (DRAM)&lt;br /&gt;
*Graphics Ultra + (DRAM, fast RAMDAC)&lt;br /&gt;
*Graphics Ultra CLX (DRAM, cost-reduced OEM version)&lt;br /&gt;
*Graphics Ultra Pro (VRAM)&lt;br /&gt;
*Graphics Ultra XLR (VRAM, cost-reduced OEM version)&lt;br /&gt;
&lt;br /&gt;
===Mach 64===&lt;br /&gt;
''Released: 1994''&lt;br /&gt;
*64-bit GUI accelerator with basic DOS support&lt;br /&gt;
*Limited VESA VBE support&lt;br /&gt;
*Video memory: 1, 2, 4 or 8&amp;amp;nbsp;MB DRAM, VRAM, or [[Dynamic random access memory#Synchronous graphics RAM .28SGRAM.29|SGRAM]]&lt;br /&gt;
*Memory interface: 64-bit&lt;br /&gt;
*Port: ISA, VLB, PCI&lt;br /&gt;
*Variants:&lt;br /&gt;
&lt;br /&gt;
**&amp;quot;Mach64 CX/210888&amp;quot; - Original chipset, uncommon (up to 2&amp;amp;nbsp;MB DRAM, or 4&amp;amp;nbsp;MB VRAM)&lt;br /&gt;
**&amp;quot;Mach64 GX/210888GX&amp;quot; - Enhanced video playback capabilities&lt;br /&gt;
**&amp;quot;Mach64 ET/210888ET&amp;quot; - Embedded???&lt;br /&gt;
**&amp;quot;Mach64 CT/264CT - Cost-reduced Mach64 with integrated RAMDAC and clock chip (up to 2&amp;amp;nbsp;MB DRAM)&lt;br /&gt;
**&amp;quot;Mach64 VT/264VT  - AMC connector (Support for TV-tuner)&lt;br /&gt;
**&amp;quot;Mach64 GT/264GT 3D Rage&amp;quot; - 3D capabilities&lt;br /&gt;
**&amp;quot;Mach64 GT-B/264GT-B [[ATI Rage II|3D Rage II]] - SDRAM &amp;amp; SGRAM support(up to 8&amp;amp;nbsp;MB)&lt;br /&gt;
**&amp;quot;Mach64 LT/264LT&amp;quot; - Low-power mobile version of Mach64 GT&lt;br /&gt;
&lt;br /&gt;
The Mach 64 chip was used on the following ATI products:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Mach64 GX Family:'''&lt;br /&gt;
*Graphics Xpression (1 or 2&amp;amp;nbsp;MB DRAM)&lt;br /&gt;
*Graphics Pro Turbo (2 or 4&amp;amp;nbsp;MB VRAM)&lt;br /&gt;
*WinTurbo (1 or 2&amp;amp;nbsp;MB VRAM, non-upgradable)&lt;br /&gt;
*Graphics Pro Turbo 1600 (fast RAMDAC,PCI-only)&lt;br /&gt;
*XCLAIM GA (Macintosh)&lt;br /&gt;
&lt;br /&gt;
'''Mach64 CT Family:'''&lt;br /&gt;
*WinBoost (1&amp;amp;nbsp;MB DRAM, upgradable to 2mb)&lt;br /&gt;
*WinCharger (2&amp;amp;nbsp;MB DRAM)&lt;br /&gt;
&lt;br /&gt;
'''Mach64 VT Family:'''&lt;br /&gt;
*Video Charger&lt;br /&gt;
*Video Xpression (Mach64 VT2)&lt;br /&gt;
*Video Xpression+ (Mach64 VT4)&lt;br /&gt;
&lt;br /&gt;
'''Mach64 GT Family:'''&lt;br /&gt;
*3D Xpression (2&amp;amp;nbsp;MB EDO DRAM))&lt;br /&gt;
&lt;br /&gt;
'''Mach64 GT-B Family:'''&lt;br /&gt;
*3D Charger (2&amp;amp;nbsp;MB EDO DRAM)&lt;br /&gt;
*3D XPRESSION+ (2 or 4&amp;amp;nbsp;MB SDRAM)&lt;br /&gt;
*3D XPRESSION+ PC2TV (TV-out)&lt;br /&gt;
*3D Pro Turbo (2, 4, 6 or 8&amp;amp;nbsp;MB SGRAM)&lt;br /&gt;
*3D Pro Turbo+ PC2TV (TV-out)&lt;br /&gt;
*Xclaim VR - early versions (Macintosh, 2, 4 or 8&amp;amp;nbsp;MB SGRAM, Video-In Video-Out)&lt;br /&gt;
*Xclaim 3D - early versions (Macintosh, 4 or 8&amp;amp;nbsp;MB SGRAM)&lt;br /&gt;
*All-In-Wonder (SDRAM, TV Tuner)&lt;br /&gt;
&lt;br /&gt;
'''Important Note:''' The 3D Rage and 3D Rage II chips were also known as Mach64 GT and Mach64 GT-B respectively. The Mach64 moniker was eliminated with introduction of the 3D Rage Pro.&lt;br /&gt;
&lt;br /&gt;
== ATi Rage series ==&lt;br /&gt;
[[File:ATIRage128Pro.JPG|thumb|Rage 128 Pro OEM]]&lt;br /&gt;
&lt;br /&gt;
===== 3D Rage =====&lt;br /&gt;
===== 3D Rage II =====&lt;br /&gt;
===== 3D Rage Pro =====&lt;br /&gt;
Released in the latter half of 1997, the Rage Pro was a major improvement on ATI's previous Rage II chip. Improvements include an increased texture cache size (now at 4 KB) allowing for improved texture filtering, as well as an integrated triangle setup engine. It is the first ATI chip (and among the earliest graphics chips) to fully support AGP bus features, including execute mode (AGP texturing). It is also the first ATI chip to support OpenGL in hardware. However, like the previous Rage chips, the Rage Pro cannot bilinear filter alpha textures, resulting in transparent textures still having a rough appearance. Performance-wise, it is very similar to 3Dfx's original Voodoo Graphics chipset. The Rage Pro was very popular with OEMs and up until the late 2000s, it was integrated into many server motherboards.&lt;br /&gt;
&lt;br /&gt;
The Rage Pro is also the last chip to support ATI's CIF application programming interface. It is also ATI's last chip with Windows 3.1x support.&lt;br /&gt;
&lt;br /&gt;
===== Rage 128 =====&lt;br /&gt;
&lt;br /&gt;
== ATi Radeon series ==&lt;br /&gt;
&lt;br /&gt;
===== R100 =====&lt;br /&gt;
[[File:Radeon7500agp.jpg|thumb|Radeon 7500 64MB]]&lt;br /&gt;
The original Radeon was a Direct3D 7 visual processing unit (VPU), as ATi named it. It is a 2 pixel per clock design with 3 texture units on each of the pixel pipelines. The 166 MHz Radeon DDR (aka 7200) is competitive with GeForce 256 DDR. Clock speeds varied from 143 - 200 MHz, synchronous memory and core. &lt;br /&gt;
&lt;br /&gt;
It supports environmental bump mapping (EMBM), unlike GeForce cards at the time. It has a basic form of anisotropic filtering that is high performance and offers a nice quality improvement but is highly angle-dependent and can not operate at the same time as trilinear filtering. It also offers ordered-grid supersampling anti-aliasing.&lt;br /&gt;
&lt;br /&gt;
Backwards compatibility with old D3D 5 games is limited because of the lack of support for fog table and palettized textures. It is possible to enable fog table via registry tweaks but it was not officially supported.&lt;br /&gt;
&lt;br /&gt;
RV100 (Radeon VE / 7000) is a chip with dual display capabilities but with reduced 3D hardware. It lacks T&amp;amp;L and has a single pixel pipeline. It is somewhat faster than TNT2 Ultra and G400 Max.&lt;br /&gt;
&lt;br /&gt;
RV200 (Radeon 7500) is a die shrink of R100 with some improvements. It has more anisotropic filtering options and is capable of asynchronous clocking of memory and the core. The top of the line model is clocked at 290 MHz core and 230 MHz RAM, and competes with GeForce 2 Ti/Pro. There are many variations of this card.&lt;br /&gt;
&lt;br /&gt;
'''Notes:'''&lt;br /&gt;
*DVI on these cards is flaky and is essentially unusable with DOS.  High resolutions may also be problematic.&lt;br /&gt;
&lt;br /&gt;
===== R200 =====&lt;br /&gt;
[[File:Radeon8500 128mb.JPG|thumb|Radeon 8500 128MB]]&lt;br /&gt;
This generation is the first with Direct3D 8 compliance, actually Direct3D 8.1. The Radeon 8500 is a 4 pipeline design with 2 texture units per pipeline and operates at up to 275 MHz, typically with synchronous core and RAM. It is competitive with GeForce 3 Ti 500. &lt;br /&gt;
&lt;br /&gt;
A wide variety of supersampling anti-aliasing modes are available (2-6x, quality/performance). ATi calls it &amp;quot;Smoothvision&amp;quot;. It uses various techniques, including a jittered-grid pattern for some modes/cases and ordered-grid for others. In Direct3D, fog may force it to use ordered-grid. Drivers vary in their behavior as well.[http://forum.beyond3d.com/showpost.php?p=4859&amp;amp;postcount=64]&lt;br /&gt;
&lt;br /&gt;
Anisotropic filtering is somewhat improved, with more levels supported, but is again very angle dependent and can not work with trilinear filtering. GeForce 3+ have higher quality anisotropic filtering but with a much higher performance impact.&lt;br /&gt;
&lt;br /&gt;
ATi introduced a tessellation function called [[TruForm]].&lt;br /&gt;
&lt;br /&gt;
Backwards compatibility with old D3D 5 games is limited because of the lack of support for fog table and palettized textures.&lt;br /&gt;
&lt;br /&gt;
RV250 and RV280, known as Radeon 9000, 9200 and 9250, are slight evolutions of the design. They have somewhat reduced specifications but are more efficient and run cooler. They were popular notebook GPUs. Performance of Radeon 9000 Pro is not far off of Radeon 8500. Radeon 9100 is a rename of Radeon 8500 LE.&lt;br /&gt;
&lt;br /&gt;
'''Notes:'''&lt;br /&gt;
*DVI on these cards is flaky and is essentially unusable with DOS. High resolutions may also be problematic.&lt;br /&gt;
*With Star Wars KOTOR and KOTOR2, use Catalyst 4.2.&lt;br /&gt;
&lt;br /&gt;
===== R300 =====&lt;br /&gt;
[[File:Radeon9800pro256.JPG|thumb|Radeon 9800 Pro 256MB]]&lt;br /&gt;
Introduced in August 2002, the R300 GPUs are Direct3D 9.0-compliant graphics chips. R300 introduced Shader Model 2.0 support and is also OpenGL 2.0-compliant. The R300 was designed by the ArtX engineering team that ATI had acquired in Feburary 2000. The same ArtX engineers (who were also former SGI employees) designed the Nintendo Gamecube GPU (Flipper) as well as the SGI RealityEngine-based graphics processor in the Nintendo 64. The first R300-based cards released were the Radeon 9500 and 9700 line of cards. In 2003, the Radeon 9600 and 9800 series were added to the lineup. R300 has many improvements and noticeably better visual quality than ATI's prior chips. Radeon 9800 Pro is competitive with GeForce FX 5900 Ultra, but with Direct3D 9 games the GeForce FX falls far behind.&lt;br /&gt;
&lt;br /&gt;
Anisotropic filtering quality is vastly improved in the R300, with much lower angle-dependency and the ability to work simultaneously with trilinear filtering. Furthermore, compared to its initial competitor, NVIDIA's GeForce 4 Ti series, R300's anisotropic filtering incurred much less performance decrease. Anti-aliasing is now performed with 2-6x gamma-corrected rotated-grid multi-sampling anti-aliasing. MSAA operates only on polygon edges, which of course means no anti-aliasing within textures or of transparent textures, but expends far less fillrate and is thus useable at higher resolutions. NVIDIA does not match the quality of this MSAA until GeForce 8. However, ATi did not support any form of super-sampling with R300-R700, while NVIDIA did.&lt;br /&gt;
&lt;br /&gt;
The R300 enjoyed visual quality and performance supremacy over its competitors in games and applications that extensively used Shader Model 2.0. NVIDIA would not be able to match or exceed ATI's Direct3D 9.0 performance until the release of the GeForce 6 series in 2004.&lt;br /&gt;
&lt;br /&gt;
Backwards compatibility with old D3D 5 games is limited because of the lack of support for fog table and palettized textures.&lt;br /&gt;
Also, despite being Direct3D 9.0-compliant, the R300 is not officially supported under Windows 7. However, for full Direct3D and OpenGL support, it is still possible to use the Windows Vista driver instead under Windows 7, although WDDM 1.1 features will not be present.&lt;br /&gt;
&lt;br /&gt;
'''Notes:'''&lt;br /&gt;
*With Star Wars KOTOR and KOTOR2, use Catalyst 4.2.&lt;br /&gt;
&lt;br /&gt;
===== R400 ===== &lt;br /&gt;
[[File:RadeonX800XTPE.jpg|thumb|Radeon X800 XT PE]]&lt;br /&gt;
&lt;br /&gt;
Introduced in 2004, this is ATi's Direct3D 9.0b generation. It is very similar to R300 in general, but with 16 pipelines in the top chip instead of 8, and higher clock speeds. They are still shader model 2.0 GPUs but have some extensions beyond 2.0, which gives them a 2.0b designation, but are not 3.0 compliant. This was not an issue until about 2 years after launch when games started to outright require shader model 3.0 or run without some visual features. There are some games that utilize 2.0b features - for example Oblivion has more visual effects available on X800 than 9800.&lt;br /&gt;
&lt;br /&gt;
A new anti-aliasing mode was introduced, called temporal AA. This feature shifts the sampling pattern on a per-frame basis, if the card can maintain &amp;gt;= 60 fps. This works well with human vision and gives a tangible improvement to anti-aliasing quality. Also, while not initially available, adaptive anti-aliasing was added to the R400 series after the release of R500 series. Adaptive AA anti-aliases within transparent textures, giving MSAA more SSAA-like capabilities.&lt;br /&gt;
&lt;br /&gt;
The ATI R400 series are ATI's last GPUs with official Windows 98/98 SE/ME support. Likewise with the R300 series, the R400 series is not officially supported under Windows 7. However, for full Direct3D and OpenGL support, it is still possible to use the Windows Vista driver instead under Windows 7, although WDDM 1.1 features will not be present.&lt;br /&gt;
&lt;br /&gt;
===== R500 =====&lt;br /&gt;
Introduced in 2005, the Radeon X1000 / R500 series are ATI's first Direct3D 9.0c-compliant GPUs with full Shader Model 3.0 features. The R500 series is not officially supported under Windows 7. However, for full Direct3D and OpenGL support, it is still possible to use the Windows Vista driver instead under Windows 7, although WDDM 1.1 features will not be present.&lt;br /&gt;
&lt;br /&gt;
==Video captures==&lt;br /&gt;
&lt;br /&gt;
===3D Rage II ===&lt;br /&gt;
{{#ev:youtube|wdJXf6MpN7A}}&lt;br /&gt;
Note: The Dawning Demo was actually targeted for the ATI Rage128 series that is a considerably newer, thus faster core than the 3D Rage II.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{{#ev:youtube|iFHwNf7-oZk}}&lt;br /&gt;
&lt;br /&gt;
{{#ev:youtube|wWzWdwj9NvU}}&lt;br /&gt;
&lt;br /&gt;
===3D Rage Pro ===&lt;br /&gt;
{{#ev:youtube|DU5Zi69QPQs}}&lt;br /&gt;
{{#ev:youtube|uZna8WXC4ds}}&lt;br /&gt;
{{#ev:youtube|IG3hd1humM0}}&lt;br /&gt;
{{#ev:youtube|i4pB5Fw8Slk}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Hardware]]&lt;br /&gt;
[[Category:Graphics Cards]]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=3.5_inch_floppy_disk&amp;diff=1681</id>
		<title>3.5 inch floppy disk</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=3.5_inch_floppy_disk&amp;diff=1681"/>
				<updated>2014-07-20T08:28:39Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This format was designed to be smaller then the [[5.25 inch floppy|5.25in floppydrive and it's media]] and fixed some of the 5.25in floppies design problems.&lt;br /&gt;
The disks are housed in a stiff housing, opposed to the &amp;quot;floppy&amp;quot; housing the 5.25in floppy was made in. Despite the more rugged design, 3.5 inch floppy drives tend to to be less reliable due to their compact nature.&lt;br /&gt;
&lt;br /&gt;
3.5 inch floppies came in three different densities (easily distinguished by a second hole on the side) and while only the earliest 3.5in disks were single sided, almost all 3.5 inch floppies can be written to on both sides.&lt;br /&gt;
The 3 densities are:&lt;br /&gt;
*Double density (a.k.a. DD, 720kb)&lt;br /&gt;
*High density (a.k.a. HD, 1.44mb)&lt;br /&gt;
*Extra high density (a.k.a. ED, 2.88mb)&lt;br /&gt;
&lt;br /&gt;
Like earlier floppies, there were many different ways to format a disk, often depending on what type of computer the disk was formatted with. On PC's, DD disks were usually (DOS-)formatted to 720KB (though in practice it had about 714KB of usable space), HD disks formatted to 1.44MB (in practice it was around 1.38MB) and the uncommon 2.88MB disks (primarily used in IBM PS/2s) formatted to around 2.76MB. On older Macs the DD disks formatted to around 820KB, and on Amiga 880kb.&lt;br /&gt;
&lt;br /&gt;
In the 1990ies the demand for higher capacities increased. Software utilities appeared that allowed to format disks to higher capacities like 1.72 Mb. By loading a small TSR-driver such formatted disks could be used like the normal 1.44 Mb formatted disks in DOS. Well known tools are fdformat (fdread), vgacopy (vgaread). Even Microsofts made use of this by introducing the DMF format (1.68 Mb) for distributing software on disks. Current archiving tools like Winimage also support disks with increased capacity.&lt;br /&gt;
Most over-formatting utilities don't handle ED disks, as the format never gained much popularity.&lt;br /&gt;
[[File:DD HD ED.JPG|200px|thumb||Unformatted capacity of DD, HD and ED disks]]&lt;br /&gt;
&lt;br /&gt;
The overall transfer speed when reading from a 1.44 Mb disk is about 30 kB/s. This could be tuned by formatting disks with an optimal track interleave that reduces access times after a track change on sequential reads significantly. Tools like vgacopy offered this feature.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Gravis_Ultrasound&amp;diff=1416</id>
		<title>Talk:Gravis Ultrasound</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Gravis_Ultrasound&amp;diff=1416"/>
				<updated>2013-07-19T12:00:57Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: Created page with &amp;quot;You wrote &amp;quot;MegaEM, in addition, is very picky about the EMM386 version.&amp;quot;. Where is this from? Actually MegaEM works with every EMM386 version.&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;You wrote &amp;quot;MegaEM, in addition, is very picky about the EMM386 version.&amp;quot;. Where is this from?&lt;br /&gt;
Actually MegaEM works with every EMM386 version.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Socket_5_/_7_/_Super-7_Motherboards&amp;diff=1208</id>
		<title>Socket 5 / 7 / Super-7 Motherboards</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Socket_5_/_7_/_Super-7_Motherboards&amp;diff=1208"/>
				<updated>2013-04-11T15:05:53Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Intel */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Socket 5 ==&lt;br /&gt;
[[File:Socket5.jpg|200px|thumb||Socket 5]]&lt;br /&gt;
Socket 5 was developed for the Pentium &amp;quot;P54C&amp;quot; CPU that operated at 3.3v instead of the original P5's 5.0v. This was a die shrink revision of the Pentium and operated at 75-120MHz with a bus speed of either 60MHz or 66MHz.&lt;br /&gt;
&lt;br /&gt;
There are several CPUs from companies other than Intel available for Socket 5. The Centaur/IDT Winchip and the AMD K5 are perhaps most well known. There are also several Intel Pentium Overdrive CPUs that were produced to match Socket 5 options to later Socket 7 CPU clock speeds.&lt;br /&gt;
&lt;br /&gt;
Socket 5 motherboards are built to the AT specification, and typically use PCI and ISA slots. There were some with VLB slots as well, and some have onboard audio or video.&lt;br /&gt;
&lt;br /&gt;
=== Chipsets ===&lt;br /&gt;
*'''430NX &amp;quot;Neptune&amp;quot;''' - SMP, PCI 2.0, FPM DRAM, Asynchronous cache. 512 MB cacheable RAM limit. 512 MB max RAM.  Some boards use IDE controller chips with known bugs, like CMD640.&lt;br /&gt;
*'''430FX &amp;quot;Triton&amp;quot;''' - 16 MB/s DMA IDE, PCI 2.0, FPM/EDO DRAM, and pipeline burst synchronous cache options. 64 MB cacheable RAM limit. 128 MB max RAM.&lt;br /&gt;
&lt;br /&gt;
== Socket 7 ==&lt;br /&gt;
[[File:ATC-5030_430TX.jpg|200px|thumb||Socket 7 Motherboard]]&lt;br /&gt;
&lt;br /&gt;
Socket 7 brings &amp;quot;split-rail&amp;quot; voltage support, which is required for CPUs that use a core voltage different than 3.3v IO. Initially the socket was used with &amp;quot;P54C&amp;quot; Pentium CPUs that went to 200 MHz, and later the Pentium MMX &amp;quot;P55C&amp;quot; that went to 233 MHz.  Socket 7 boards typically support 60 and 66 MHz bus speeds, but many motherboards allow a wider range to support some non-Intel CPUs. Alternative CPUs include products from Cyrix, AMD, Rise and Centaur.&lt;br /&gt;
&lt;br /&gt;
Socket 7 motherboards are available in AT and ATX form factor. They have PCI and ISA slots. Some have extra onboard components like audio and video.&lt;br /&gt;
&lt;br /&gt;
=== Chipsets ===&lt;br /&gt;
==== Intel ====&lt;br /&gt;
*'''430HX &amp;quot;Triton II&amp;quot;''' - 16 MB/s BM-DMA IDE, SMP, PCI 2.1, USB 1.0, FPM/EDO DRAM and pipeline burst synchronous cache options. Supports either 64 MB or 512 MB cacheable RAM. 512 MB RAM max.&lt;br /&gt;
*'''430VX &amp;quot;Triton II&amp;quot;''' - 16 MB/s BM-DMA IDE, PCI 2.1, USB 1.0, FPM/EDO DRAM, 2clk SDRAM and pipeline burst synchronous cache options. 64 MB cacheable limit. 128 MB max RAM. Slightly slower than 430HX. &lt;br /&gt;
*'''430TX''' - 33 MB/s UDMA IDE, PCI 2.1, USB 1.0, ACPI, FPM/EDO DRAM, 2clk SDRAM, and pipeline burst synchronous cache options. 64 MB cacheable limit. 256 MB max RAM.&lt;br /&gt;
&lt;br /&gt;
==== VIA ====&lt;br /&gt;
&lt;br /&gt;
* '''Apollo Master''' - FPM/EDO DRAM&lt;br /&gt;
* '''Apollo VP''' - FPM/BEDO/EDO DRAM, SDRAM, max. 512 MB, 50/60/66 MHz FSB, USB 1.0, 16 MB/s DMA IDE&lt;br /&gt;
* '''Apollo VPX''' - FPM/EDO DRAM, SDRAM, max. 512 Mb&lt;br /&gt;
* '''Apollo VP2''' - FPM/EDO DRAM, SDRAM, max. 512 Mb&lt;br /&gt;
* '''Apollo VP3''' - FPM/EDO DRAM, SDRAM, max. 1 Gb, AGP 1.0&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== SIS ====&lt;br /&gt;
&lt;br /&gt;
* '''SiS 530 + SiS 5595''' - &lt;br /&gt;
&lt;br /&gt;
==== ALI ====&lt;br /&gt;
&lt;br /&gt;
* '''M1451/M1449'''&lt;br /&gt;
* '''M1521/M1523 / ALADDiN III''' -&lt;br /&gt;
* '''M1531/M1543 / ALADDiN IV''' -&lt;br /&gt;
* '''M1531B/M1543 / ALADDiN IV+''' - FSB max. 83 MHz&lt;br /&gt;
* '''M1541/M1542 / ALADDiN V''' -&lt;br /&gt;
* '''M1561/M1535D / ALADDiN 7''' - 66,100 MHz FSB, USB 1.0, UDMA2, SDRAM max. 1GB&lt;br /&gt;
&lt;br /&gt;
== Super Socket 7 ==&lt;br /&gt;
Super Socket 7 is an AMD creation. They modernized the Socket 7 platform with AGP and 100 MHz bus support for their K6-2 processor. Intel was not involved with this nor did they produce CPUs specifically for it.  &lt;br /&gt;
&lt;br /&gt;
Chipsets were produced by ALI, VIA and SiS. The boards come in AT and ATX form factors and usually have AGP, PCI and ISA. Some boards use integrated graphics and forgo the AGP slot.&lt;br /&gt;
&lt;br /&gt;
These solutions competed against Intel Celeron and Pentium II.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Socket_5_/_7_/_Super-7_Motherboards&amp;diff=1207</id>
		<title>Socket 5 / 7 / Super-7 Motherboards</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Socket_5_/_7_/_Super-7_Motherboards&amp;diff=1207"/>
				<updated>2013-04-11T14:35:18Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Intel */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Socket 5 ==&lt;br /&gt;
[[File:Socket5.jpg|200px|thumb||Socket 5]]&lt;br /&gt;
Socket 5 was developed for the Pentium &amp;quot;P54C&amp;quot; CPU that operated at 3.3v instead of the original P5's 5.0v. This was a die shrink revision of the Pentium and operated at 75-120MHz with a bus speed of either 60MHz or 66MHz.&lt;br /&gt;
&lt;br /&gt;
There are several CPUs from companies other than Intel available for Socket 5. The Centaur/IDT Winchip and the AMD K5 are perhaps most well known. There are also several Intel Pentium Overdrive CPUs that were produced to match Socket 5 options to later Socket 7 CPU clock speeds.&lt;br /&gt;
&lt;br /&gt;
Socket 5 motherboards are built to the AT specification, and typically use PCI and ISA slots. There were some with VLB slots as well, and some have onboard audio or video.&lt;br /&gt;
&lt;br /&gt;
=== Chipsets ===&lt;br /&gt;
*'''430NX &amp;quot;Neptune&amp;quot;''' - SMP, PCI 2.0, FPM DRAM, Asynchronous cache. 512 MB cacheable RAM limit. 512 MB max RAM.  Some boards use IDE controller chips with known bugs, like CMD640.&lt;br /&gt;
*'''430FX &amp;quot;Triton&amp;quot;''' - 16 MB/s DMA IDE, PCI 2.0, FPM/EDO DRAM, and pipeline burst synchronous cache options. 64 MB cacheable RAM limit. 128 MB max RAM.&lt;br /&gt;
&lt;br /&gt;
== Socket 7 ==&lt;br /&gt;
[[File:ATC-5030_430TX.jpg|200px|thumb||Socket 7 Motherboard]]&lt;br /&gt;
&lt;br /&gt;
Socket 7 brings &amp;quot;split-rail&amp;quot; voltage support, which is required for CPUs that use a core voltage different than 3.3v IO. Initially the socket was used with &amp;quot;P54C&amp;quot; Pentium CPUs that went to 200 MHz, and later the Pentium MMX &amp;quot;P55C&amp;quot; that went to 233 MHz.  Socket 7 boards typically support 60 and 66 MHz bus speeds, but many motherboards allow a wider range to support some non-Intel CPUs. Alternative CPUs include products from Cyrix, AMD, Rise and Centaur.&lt;br /&gt;
&lt;br /&gt;
Socket 7 motherboards are available in AT and ATX form factor. They have PCI and ISA slots. Some have extra onboard components like audio and video.&lt;br /&gt;
&lt;br /&gt;
=== Chipsets ===&lt;br /&gt;
==== Intel ====&lt;br /&gt;
*'''430HX &amp;quot;Triton II&amp;quot;''' - 16 MB/s BM-DMA IDE, SMP, PCI 2.1, USB 1.0, FPM/EDO DRAM and pipeline burst synchronous cache options. Supports either 64 MB or 512 MB cacheable RAM. 512 MB RAM max.&lt;br /&gt;
*'''430VX &amp;quot;Triton II&amp;quot;''' - 16 MB/s BM-DMA IDE, PCI 2.1, USB 1.0, FPM/EDO DRAM, 2clk SDRAM and pipeline burst synchronous cache options. 64 MB cacheable limit. 128 MB max RAM. Slightly slower than 430HX. &lt;br /&gt;
*'''430TX''' - 33 MB/s UDMA IDE, PCI 2.1, USB 1.0, ACPI, FPM/EDO DRAM, 2clk SDRAM, and pipeline burst synchronous cache options. 64 MB cacheable limit. 256 MB max RAM.&lt;br /&gt;
&lt;br /&gt;
== Super Socket 7 ==&lt;br /&gt;
Super Socket 7 is an AMD creation. They modernized the Socket 7 platform with AGP and 100 MHz bus support for their K6-2 processor. Intel was not involved with this nor did they produce CPUs specifically for it.  &lt;br /&gt;
&lt;br /&gt;
Chipsets were produced by ALI, VIA and SiS. The boards come in AT and ATX form factors and usually have AGP, PCI and ISA. Some boards use integrated graphics and forgo the AGP slot.&lt;br /&gt;
&lt;br /&gt;
These solutions competed against Intel Celeron and Pentium II.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Socket_5_/_7_/_Super-7_Motherboards&amp;diff=1206</id>
		<title>Socket 5 / 7 / Super-7 Motherboards</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Socket_5_/_7_/_Super-7_Motherboards&amp;diff=1206"/>
				<updated>2013-04-11T14:34:54Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Chipsets */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Socket 5 ==&lt;br /&gt;
[[File:Socket5.jpg|200px|thumb||Socket 5]]&lt;br /&gt;
Socket 5 was developed for the Pentium &amp;quot;P54C&amp;quot; CPU that operated at 3.3v instead of the original P5's 5.0v. This was a die shrink revision of the Pentium and operated at 75-120MHz with a bus speed of either 60MHz or 66MHz.&lt;br /&gt;
&lt;br /&gt;
There are several CPUs from companies other than Intel available for Socket 5. The Centaur/IDT Winchip and the AMD K5 are perhaps most well known. There are also several Intel Pentium Overdrive CPUs that were produced to match Socket 5 options to later Socket 7 CPU clock speeds.&lt;br /&gt;
&lt;br /&gt;
Socket 5 motherboards are built to the AT specification, and typically use PCI and ISA slots. There were some with VLB slots as well, and some have onboard audio or video.&lt;br /&gt;
&lt;br /&gt;
=== Chipsets ===&lt;br /&gt;
*'''430NX &amp;quot;Neptune&amp;quot;''' - SMP, PCI 2.0, FPM DRAM, Asynchronous cache. 512 MB cacheable RAM limit. 512 MB max RAM.  Some boards use IDE controller chips with known bugs, like CMD640.&lt;br /&gt;
*'''430FX &amp;quot;Triton&amp;quot;''' - 16 MB/s DMA IDE, PCI 2.0, FPM/EDO DRAM, and pipeline burst synchronous cache options. 64 MB cacheable RAM limit. 128 MB max RAM.&lt;br /&gt;
&lt;br /&gt;
== Socket 7 ==&lt;br /&gt;
[[File:ATC-5030_430TX.jpg|200px|thumb||Socket 7 Motherboard]]&lt;br /&gt;
&lt;br /&gt;
Socket 7 brings &amp;quot;split-rail&amp;quot; voltage support, which is required for CPUs that use a core voltage different than 3.3v IO. Initially the socket was used with &amp;quot;P54C&amp;quot; Pentium CPUs that went to 200 MHz, and later the Pentium MMX &amp;quot;P55C&amp;quot; that went to 233 MHz.  Socket 7 boards typically support 60 and 66 MHz bus speeds, but many motherboards allow a wider range to support some non-Intel CPUs. Alternative CPUs include products from Cyrix, AMD, Rise and Centaur.&lt;br /&gt;
&lt;br /&gt;
Socket 7 motherboards are available in AT and ATX form factor. They have PCI and ISA slots. Some have extra onboard components like audio and video.&lt;br /&gt;
&lt;br /&gt;
=== Chipsets ===&lt;br /&gt;
==== Intel ====&lt;br /&gt;
*'''430HX &amp;quot;Triton II&amp;quot;''' - 16 MB/s BM-DMA IDE, PCI 2.1, USB 1.0, FPM/EDO DRAM and pipeline burst synchronous cache options. Supports either 64 MB or 512 MB cacheable RAM. 512 MB RAM max.&lt;br /&gt;
*'''430VX &amp;quot;Triton II&amp;quot;''' - 16 MB/s BM-DMA IDE, PCI 2.1, USB 1.0, FPM/EDO DRAM, 2clk SDRAM and pipeline burst synchronous cache options. 64 MB cacheable limit. 128 MB max RAM. Slightly slower than 430HX. &lt;br /&gt;
*'''430TX''' - 33 MB/s UDMA IDE, PCI 2.1, USB 1.0, ACPI, FPM/EDO DRAM, 2clk SDRAM, and pipeline burst synchronous cache options. 64 MB cacheable limit. 256 MB max RAM.&lt;br /&gt;
&lt;br /&gt;
== Super Socket 7 ==&lt;br /&gt;
Super Socket 7 is an AMD creation. They modernized the Socket 7 platform with AGP and 100 MHz bus support for their K6-2 processor. Intel was not involved with this nor did they produce CPUs specifically for it.  &lt;br /&gt;
&lt;br /&gt;
Chipsets were produced by ALI, VIA and SiS. The boards come in AT and ATX form factors and usually have AGP, PCI and ISA. Some boards use integrated graphics and forgo the AGP slot.&lt;br /&gt;
&lt;br /&gt;
These solutions competed against Intel Celeron and Pentium II.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Socket_5_/_7_/_Super-7_Motherboards&amp;diff=1205</id>
		<title>Socket 5 / 7 / Super-7 Motherboards</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Socket_5_/_7_/_Super-7_Motherboards&amp;diff=1205"/>
				<updated>2013-04-11T14:30:32Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Intel */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Socket 5 ==&lt;br /&gt;
[[File:Socket5.jpg|200px|thumb||Socket 5]]&lt;br /&gt;
Socket 5 was developed for the Pentium &amp;quot;P54C&amp;quot; CPU that operated at 3.3v instead of the original P5's 5.0v. This was a die shrink revision of the Pentium and operated at 75-120MHz with a bus speed of either 60MHz or 66MHz.&lt;br /&gt;
&lt;br /&gt;
There are several CPUs from companies other than Intel available for Socket 5. The Centaur/IDT Winchip and the AMD K5 are perhaps most well known. There are also several Intel Pentium Overdrive CPUs that were produced to match Socket 5 options to later Socket 7 CPU clock speeds.&lt;br /&gt;
&lt;br /&gt;
Socket 5 motherboards are built to the AT specification, and typically use PCI and ISA slots. There were some with VLB slots as well, and some have onboard audio or video.&lt;br /&gt;
&lt;br /&gt;
=== Chipsets ===&lt;br /&gt;
*'''430NX &amp;quot;Neptune&amp;quot;''' - FPM DRAM. Asynchronous cache. 512 MB cacheable RAM limit. 512 MB max RAM.  Some boards use IDE controllers with known bugs.&lt;br /&gt;
*'''430FX &amp;quot;Triton&amp;quot;''' - 16 MB/s DMA IDE, EDO DRAM, and pipeline burst synchronous cache options. 64 MB cacheable RAM limit. 128 MB max RAM.&lt;br /&gt;
&lt;br /&gt;
== Socket 7 ==&lt;br /&gt;
[[File:ATC-5030_430TX.jpg|200px|thumb||Socket 7 Motherboard]]&lt;br /&gt;
&lt;br /&gt;
Socket 7 brings &amp;quot;split-rail&amp;quot; voltage support, which is required for CPUs that use a core voltage different than 3.3v IO. Initially the socket was used with &amp;quot;P54C&amp;quot; Pentium CPUs that went to 200 MHz, and later the Pentium MMX &amp;quot;P55C&amp;quot; that went to 233 MHz.  Socket 7 boards typically support 60 and 66 MHz bus speeds, but many motherboards allow a wider range to support some non-Intel CPUs. Alternative CPUs include products from Cyrix, AMD, Rise and Centaur.&lt;br /&gt;
&lt;br /&gt;
Socket 7 motherboards are available in AT and ATX form factor. They have PCI and ISA slots. Some have extra onboard components like audio and video.&lt;br /&gt;
&lt;br /&gt;
=== Chipsets ===&lt;br /&gt;
==== Intel ====&lt;br /&gt;
*'''430HX &amp;quot;Triton II&amp;quot;''' - 16 MB/s BM-DMA IDE, PCI 2.1, USB 1.0, FPM/EDO DRAM and pipeline burst synchronous cache options. Supports either 64 MB or 512 MB cacheable RAM. 512 MB RAM max.&lt;br /&gt;
*'''430VX &amp;quot;Triton II&amp;quot;''' - 16 MB/s BM-DMA IDE, PCI 2.1, USB 1.0, FPM/EDO DRAM, 2clk SDRAM and pipeline burst synchronous cache options. 64 MB cacheable limit. 128 MB max RAM. Slightly slower than 430HX. &lt;br /&gt;
*'''430TX''' - 33 MB/s UDMA IDE, PCI 2.1, USB 1.0, ACPI, FPM/EDO DRAM, 2clk SDRAM, and pipeline burst synchronous cache options. 64 MB cacheable limit. 256 MB max RAM.&lt;br /&gt;
&lt;br /&gt;
== Super Socket 7 ==&lt;br /&gt;
Super Socket 7 is an AMD creation. They modernized the Socket 7 platform with AGP and 100 MHz bus support for their K6-2 processor. Intel was not involved with this nor did they produce CPUs specifically for it.  &lt;br /&gt;
&lt;br /&gt;
Chipsets were produced by ALI, VIA and SiS. The boards come in AT and ATX form factors and usually have AGP, PCI and ISA. Some boards use integrated graphics and forgo the AGP slot.&lt;br /&gt;
&lt;br /&gt;
These solutions competed against Intel Celeron and Pentium II.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1204</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1204"/>
				<updated>2013-04-11T14:17:36Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Additional Remarks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The '''upper memory area''' ('''UMA''') is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use parts of the UMA for own BIOS ROMs or buffer RAM. The Extended Memory Specification (XMS) allows to map blocks of mainboard RAM in the remaining UMA memory range. These blocks are called '''Upper Memory Blocks''' (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area ('''HMA''') are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The '''Expanded Memory Specification''' ('''EMS''') is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The '''Extended Memory Specification''' ('''XMS''') describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Additional Remarks ==&lt;br /&gt;
&lt;br /&gt;
While UMBs are a optional feature of XMS HIMEM.SYS does not support UMB. On bare MS-DOS this requires to load EMM386.EXE.&lt;br /&gt;
&lt;br /&gt;
The DOS=HIGH and DOS=UMB statements in config.sys can be combined by writing DOS=HIGH,UMB. Specifying DOS=LOW can be used to prevent DOS from using the HMA.&lt;br /&gt;
&lt;br /&gt;
Shadow-RAM is the RAM below the reserved UMA. Depending on chipset this RAM can be mapped in again in specific UMA memory ranges. A common use of Shadow-RAM is copying the BIOS ROMs to the Shadow-RAM below and mapping out the ROM afterwards. As the BIOS code is executed now from RAM instead of slow ROM the BIOS calls get accelerated. This functionality can usually enabled by BIOS (''Shadow System BIOS'' and ''Shadow Video BIOS'') or as parameter of a memory manager. Also the UMBPCI driver uses this feature to create UMBs through Shadow-RAM.&lt;br /&gt;
&lt;br /&gt;
Architectural reasons force the memory for DMA transfers of ISA cards to be reserved below 1 Mb. This is usually of 16 kB size and reserved in UMA.&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver. Some chipsets have jumpers to set XMS and EMS assignment of the main memory.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
Another way is to use a utility that changes the start up files such that the amount of free conventional memory is maximal (e.g. MS-DOS Memmaker, QEMM Optimize). Typically these programs run several analysis reboots to gather information about the drivers and memory layout. In the end a optimized configuration is presented. The analysis depth and the final quality of the presented new boot configuration of the programs varies. &lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
'''MEMMAKER.EXE''': introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''UMBPCI''' Upper memory driver, partial replacement for EMM386.EXE. Uses Shadow-RAM instead of extended memory to create UMBs. Functionality is chipset dependent, see [http://www.uwe-sieber.de/umbpci_e.html UMBPCI homepage] for a list of supported chipsets. Also be aware of issues with ISA-DMA using the Shadow-RAM method that could lead to data corruption if not setup properly. This driver leaves the CPU in Real mode.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1203</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1203"/>
				<updated>2013-04-11T13:54:49Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Software */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The '''upper memory area''' ('''UMA''') is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use parts of the UMA for own BIOS ROMs or buffer RAM. The Extended Memory Specification (XMS) allows to map blocks of mainboard RAM in the remaining UMA memory range. These blocks are called '''Upper Memory Blocks''' (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area ('''HMA''') are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The '''Expanded Memory Specification''' ('''EMS''') is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The '''Extended Memory Specification''' ('''XMS''') describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Additional Remarks ==&lt;br /&gt;
&lt;br /&gt;
While UMBs are a optional feature of XMS HIMEM.SYS does not support UMB. On bare MS-DOS this requires to load EMM386.EXE.&lt;br /&gt;
&lt;br /&gt;
The DOS=HIGH and DOS=UMB statements in config.sys can be combined by writing DOS=HIGH,UMB. Specifying DOS=LOW can be used to prevent DOS from using the HMA.&lt;br /&gt;
&lt;br /&gt;
Shadow RAM is RAM in the same range as BIOS ROMs. It can usually enabled by BIOS or as parameter of a memory manager. Since ROM access is rather slow it is usually used to copy the BIOS ROM to the underlying RAM at the same location and then switching off the ROM. This accelerates all BIOS calls.&lt;br /&gt;
&lt;br /&gt;
Architectural reasons force the memory for DMA transfers of ISA cards to be reserved below 1 Mb. This is usually of 16 kB size and reserved in UMA.&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver. Some chipsets have jumpers to set XMS and EMS assignment of the main memory.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
Another way is to use a utility that changes the start up files such that the amount of free conventional memory is maximal (e.g. MS-DOS Memmaker, QEMM Optimize). Typically these programs run several analysis reboots to gather information about the drivers and memory layout. In the end a optimized configuration is presented. The analysis depth and the final quality of the presented new boot configuration of the programs varies. &lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
'''MEMMAKER.EXE''': introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''UMBPCI''' Upper memory driver, partial replacement for EMM386.EXE. Uses Shadow-RAM instead of extended memory to create UMBs. Functionality is chipset dependent, see [http://www.uwe-sieber.de/umbpci_e.html UMBPCI homepage] for a list of supported chipsets. Also be aware of issues with ISA-DMA using the Shadow-RAM method that could lead to data corruption if not setup properly. This driver leaves the CPU in Real mode.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1202</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1202"/>
				<updated>2013-04-11T13:54:10Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Software */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The '''upper memory area''' ('''UMA''') is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use parts of the UMA for own BIOS ROMs or buffer RAM. The Extended Memory Specification (XMS) allows to map blocks of mainboard RAM in the remaining UMA memory range. These blocks are called '''Upper Memory Blocks''' (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area ('''HMA''') are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The '''Expanded Memory Specification''' ('''EMS''') is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The '''Extended Memory Specification''' ('''XMS''') describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Additional Remarks ==&lt;br /&gt;
&lt;br /&gt;
While UMBs are a optional feature of XMS HIMEM.SYS does not support UMB. On bare MS-DOS this requires to load EMM386.EXE.&lt;br /&gt;
&lt;br /&gt;
The DOS=HIGH and DOS=UMB statements in config.sys can be combined by writing DOS=HIGH,UMB. Specifying DOS=LOW can be used to prevent DOS from using the HMA.&lt;br /&gt;
&lt;br /&gt;
Shadow RAM is RAM in the same range as BIOS ROMs. It can usually enabled by BIOS or as parameter of a memory manager. Since ROM access is rather slow it is usually used to copy the BIOS ROM to the underlying RAM at the same location and then switching off the ROM. This accelerates all BIOS calls.&lt;br /&gt;
&lt;br /&gt;
Architectural reasons force the memory for DMA transfers of ISA cards to be reserved below 1 Mb. This is usually of 16 kB size and reserved in UMA.&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver. Some chipsets have jumpers to set XMS and EMS assignment of the main memory.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
Another way is to use a utility that changes the start up files such that the amount of free conventional memory is maximal (e.g. MS-DOS Memmaker, QEMM Optimize). Typically these programs run several analysis reboots to gather information about the drivers and memory layout. In the end a optimized configuration is presented. The analysis depth and the final quality of the presented new boot configuration of the programs varies. &lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
'''MEMMAKER.EXE''': introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''UMBPCI''' Upper memory driver, partial replacement for EMM386.EXE. Uses Shadow-RAM instead of extended memory to create UMBs. Functionality is chipset dependent, see [http://www.uwe-sieber.de/umbpci_e.html UMBPCI homepage] for a list of supported chipsets. Also be aware of issues with ISA-DMA using the Shadow-RAM method that could lead to data corruption if not setup properly.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1201</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1201"/>
				<updated>2013-04-11T00:03:30Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Getting more conventional memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The '''upper memory area''' ('''UMA''') is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use parts of the UMA for own BIOS ROMs or buffer RAM. The Extended Memory Specification (XMS) allows to map blocks of mainboard RAM in the remaining UMA memory range. These blocks are called '''Upper Memory Blocks''' (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area ('''HMA''') are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The '''Expanded Memory Specification''' ('''EMS''') is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The '''Extended Memory Specification''' ('''XMS''') describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Additional Remarks ==&lt;br /&gt;
&lt;br /&gt;
While UMBs are a optional feature of XMS HIMEM.SYS does not support UMB. On bare MS-DOS this requires to load EMM386.EXE.&lt;br /&gt;
&lt;br /&gt;
The DOS=HIGH and DOS=UMB statements in config.sys can be combined by writing DOS=HIGH,UMB. Specifying DOS=LOW can be used to prevent DOS from using the HMA.&lt;br /&gt;
&lt;br /&gt;
Shadow RAM is RAM in the same range as BIOS ROMs. It can usually enabled by BIOS or as parameter of a memory manager. Since ROM access is rather slow it is usually used to copy the BIOS ROM to the underlying RAM at the same location and then switching off the ROM. This accelerates all BIOS calls.&lt;br /&gt;
&lt;br /&gt;
Architectural reasons force the memory for DMA transfers of ISA cards to be reserved below 1 Mb. This is usually of 16 kB size and reserved in UMA.&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver. Some chipsets have jumpers to set XMS and EMS assignment of the main memory.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
Another way is to use a utility that changes the start up files such that the amount of free conventional memory is maximal (e.g. MS-DOS Memmaker, QEMM Optimize). Typically these programs run several analysis reboots to gather information about the drivers and memory layout. In the end a optimized configuration is presented. The analysis depth and the final quality of the presented new boot configuration of the programs varies. &lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
'''MEMMAKER.EXE''': introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1200</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1200"/>
				<updated>2013-04-10T23:50:47Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The '''upper memory area''' ('''UMA''') is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use parts of the UMA for own BIOS ROMs or buffer RAM. The Extended Memory Specification (XMS) allows to map blocks of mainboard RAM in the remaining UMA memory range. These blocks are called '''Upper Memory Blocks''' (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area ('''HMA''') are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The '''Expanded Memory Specification''' ('''EMS''') is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The '''Extended Memory Specification''' ('''XMS''') describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Additional Remarks ==&lt;br /&gt;
&lt;br /&gt;
While UMBs are a optional feature of XMS HIMEM.SYS does not support UMB. On bare MS-DOS this requires to load EMM386.EXE.&lt;br /&gt;
&lt;br /&gt;
The DOS=HIGH and DOS=UMB statements in config.sys can be combined by writing DOS=HIGH,UMB. Specifying DOS=LOW can be used to prevent DOS from using the HMA.&lt;br /&gt;
&lt;br /&gt;
Shadow RAM is RAM in the same range as BIOS ROMs. It can usually enabled by BIOS or as parameter of a memory manager. Since ROM access is rather slow it is usually used to copy the BIOS ROM to the underlying RAM at the same location and then switching off the ROM. This accelerates all BIOS calls.&lt;br /&gt;
&lt;br /&gt;
Architectural reasons force the memory for DMA transfers of ISA cards to be reserved below 1 Mb. This is usually of 16 kB size and reserved in UMA.&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
'''MEMMAKER.EXE''': introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1199</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1199"/>
				<updated>2013-04-10T23:46:55Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Additional Remarks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use parts of the UMA for own BIOS ROMs or buffer RAM. The Extended Memory Specification (XMS) allows to map blocks of mainboard RAM in the remaining UMA memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Additional Remarks ==&lt;br /&gt;
&lt;br /&gt;
While UMBs are a optional feature of XMS HIMEM.SYS does not support UMB. On bare MS-DOS this requires to load EMM386.EXE.&lt;br /&gt;
&lt;br /&gt;
The DOS=HIGH and DOS=UMB statements in config.sys can be combined by writing DOS=HIGH,UMB. Specifying DOS=LOW can be used to prevent DOS from using the HMA.&lt;br /&gt;
&lt;br /&gt;
Shadow RAM is RAM in the same range as BIOS ROMs. It can usually enabled by BIOS or as parameter of a memory manager. Since ROM access is rather slow it is usually used to copy the BIOS ROM to the underlying RAM at the same location and then switching off the ROM. This accelerates all BIOS calls.&lt;br /&gt;
&lt;br /&gt;
Architectural reasons force the memory for DMA transfers of ISA cards to be reserved below 1 Mb. This is usually of 16 kB size and reserved in UMA.&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
'''MEMMAKER.EXE''': introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1198</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1198"/>
				<updated>2013-04-10T23:35:53Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Upper memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use parts of the UMA for own BIOS ROMs or buffer RAM. The Extended Memory Specification (XMS) allows to map blocks of mainboard RAM in the remaining UMA memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Additional Remarks ==&lt;br /&gt;
&lt;br /&gt;
While UMBs are a optional feature of XMS HIMEM.SYS does not support UMB. On bare MS-DOS this requires to load EMM386.EXE.&lt;br /&gt;
&lt;br /&gt;
The DOS=HIGH and DOS=UMB statements in config.sys can be combined by writing DOS=HIGH,UMB. Specifying DOS=LOW can be used to prevent DOS from using the HMA.&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
'''MEMMAKER.EXE''': introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1197</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1197"/>
				<updated>2013-04-10T23:34:55Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. The Extended Memory Specification (XMS) allows to map blocks of mainboard RAM in the remaining UMA memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Additional Remarks ==&lt;br /&gt;
&lt;br /&gt;
While UMBs are a optional feature of XMS HIMEM.SYS does not support UMB. On bare MS-DOS this requires to load EMM386.EXE.&lt;br /&gt;
&lt;br /&gt;
The DOS=HIGH and DOS=UMB statements in config.sys can be combined by writing DOS=HIGH,UMB. Specifying DOS=LOW can be used to prevent DOS from using the HMA.&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
'''MEMMAKER.EXE''': introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1196</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1196"/>
				<updated>2013-04-10T23:26:16Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
'''HIMEM.SYS''': introduced with MS-DOS 5.0, enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
'''EMM386.EXE''': introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;br /&gt;
&lt;br /&gt;
MEMMAKER.EXE: introduced with MS-DOS 6.0, utility to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''QEMM386''': a complete package of memory management driver and utilities, last version 9.0 / QEMM97&lt;br /&gt;
&lt;br /&gt;
'''QEMM386.SYS''' memory management driver implementing XMS, EMS, UMA, VCPI and DPMI, enhanced features include support for up to 256 MB RAM, QuickBoot, Stealth, dynamically load drivers from command line and specific support for popular drivers as DoubleSpace, Stacker. Additional utilities include &lt;br /&gt;
&lt;br /&gt;
'''Optimize''' a powerful tool to optimize free conventional memory&lt;br /&gt;
&lt;br /&gt;
'''DOS-UP''' for relocating DOS to high memory&lt;br /&gt;
&lt;br /&gt;
'''Manifest''' a system information tool with focus on memory layout&lt;br /&gt;
&lt;br /&gt;
'''QDPMI''' a DPMI 0.9 server&lt;br /&gt;
&lt;br /&gt;
'''MagnaRAM''' a memory compression utility replacing a portion of Windows 3.1 virtual memory subsystem.&lt;br /&gt;
&lt;br /&gt;
[http://support.microsoft.com/kb/95555 Overview of Memory-Management Functionality in MS-DOS]&lt;br /&gt;
[http://en.wikipedia.org/wiki/QEMM#DOS_equivalents Overview about features of different memory managers]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1195</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1195"/>
				<updated>2013-04-10T23:06:52Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* High memory area */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb and are part of XMS. To use HMA it is required to load HIMEM.SYS in config.sys. By specifying the line '''DOS=HIGH''' in config.sys DOS is asked to load parts to HMA. Directly after an XMS driver is loaded in config.sys with DEVICE= and the HMA is still unoccupied DOS will move parts of code there. If DOS=HIGH was specified but loading to HMA fails ''HMA not available/loading DOS low'' is reported.&lt;br /&gt;
The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
HIMEM.SYS: introduced with MS-DOS 5.0, enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
EMM386.SYS: introduced with MS-DOS 4.01, enables UMBs in UMA, enables EMS&lt;br /&gt;
&lt;br /&gt;
EMM386.EXE: introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1194</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1194"/>
				<updated>2013-04-10T23:00:33Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Upper memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping through XMS memory is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps XMS memory there creating Upper Memory Blocks.&lt;br /&gt;
By specifying DOS=UMB in config.sys MS-DOS allocates all UMBs through XMS and takes over memory management of them. this allows TSR-programs to be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no contiguous free Upper Memory Block is available the driver will be loaded to Conventional Memory. Since UMA memory is managed in blocks the amount of free Upper Memory is usually larger than the largest contiguous free block. The external program MEM with parameter /C reports additionally the UMA RAM status.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
HIMEM.SYS: introduced with MS-DOS 5.0, enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
EMM386.SYS: introduced with MS-DOS 4.01, enables UMBs in UMA, enables EMS&lt;br /&gt;
&lt;br /&gt;
EMM386.EXE: introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1193</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1193"/>
				<updated>2013-04-10T22:50:51Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Software */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory. The external program MEM reports the amount of High RAM. Parts of DOS can be loaded into Upper Memory Blocks by specifying DOS=UMB in config.sys but usually it is better to load DOS to the High Memory Area leaving Upper Memory Blocks free for TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
HIMEM.SYS: introduced with MS-DOS 5.0, enables XMS (except UMBs) with 286 up to 15 Mb, with 386/486 up to 1023 Mb&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
MS-DOS 5.0 : 2.77, max. 15 Mb XMS&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.0 : 3.07, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
MS-DOS 6.2 6.21 6.22 : 3.10, recognizes max. 4 Gb, 1023 MB XMS useable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
EMM386.SYS: introduced with MS-DOS 4.01, enables UMBs in UMA, enables EMS&lt;br /&gt;
&lt;br /&gt;
EMM386.EXE: introduced with MS-DOS 5.0, uses XMS to create UMBs in UMA, uses XMS to create EMS&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1192</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1192"/>
				<updated>2013-04-10T22:28:08Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Expanded memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory. The external program MEM reports the amount of High RAM. Parts of DOS can be loaded into Upper Memory Blocks by specifying DOS=UMB in config.sys but usually it is better to load DOS to the High Memory Area leaving Upper Memory Blocks free for TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode. The amount of free main memory beyond 1 MB can be shared between EMS and XMS by adding the parameter AUTO to EMM386.EXE.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
(todo: list of memory managing software?)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1191</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1191"/>
				<updated>2013-04-10T22:26:29Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Expanded memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory. The external program MEM reports the amount of High RAM. Parts of DOS can be loaded into Upper Memory Blocks by specifying DOS=UMB in config.sys but usually it is better to load DOS to the High Memory Area leaving Upper Memory Blocks free for TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
EMS 3.0: max. 4 Mb&lt;br /&gt;
EMS 3.2: max. 8 Mb&lt;br /&gt;
EMS 4.0: max. 32 Mb&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
(todo: list of memory managing software?)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1190</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1190"/>
				<updated>2013-04-10T22:24:18Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Extended memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory. The external program MEM reports the amount of High RAM. Parts of DOS can be loaded into Upper Memory Blocks by specifying DOS=UMB in config.sys but usually it is better to load DOS to the High Memory Area leaving Upper Memory Blocks free for TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
The Extended Memory Specification (XMS) describes an application interface that allows to copy memory between conventional and extended memory. Extended Memory is all main memory beyond 1 Mb. The most common memory management driver for this functionality is HIMEM.SYS that has to be loaded as first driver in config.sys. Accessing memory above the High Memory Area requires switching the CPU to Protected Mode, thus HIMEM.SYS requires at least a 286 CPU.&lt;br /&gt;
&lt;br /&gt;
Versions:&lt;br /&gt;
&lt;br /&gt;
XMS 2.0: max. 64 Mb&lt;br /&gt;
&lt;br /&gt;
XMS 3.0: max. 4 Gb&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
(todo: list of memory managing software?)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1189</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1189"/>
				<updated>2013-04-10T22:12:22Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Expanded memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory. The external program MEM reports the amount of High RAM. Parts of DOS can be loaded into Upper Memory Blocks by specifying DOS=UMB in config.sys but usually it is better to load DOS to the High Memory Area leaving Upper Memory Blocks free for TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. To achieve this it has to switch the CPU to Protected Mode.&lt;br /&gt;
In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
XMS&lt;br /&gt;
(todo)&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
(todo: list of memory managing software?)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1188</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1188"/>
				<updated>2013-04-10T22:11:37Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Expanded memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory. The external program MEM reports the amount of High RAM. Parts of DOS can be loaded into Upper Memory Blocks by specifying DOS=UMB in config.sys but usually it is better to load DOS to the High Memory Area leaving Upper Memory Blocks free for TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
The Expanded Memory Specification (EMS) is a standard developed by Lotus, Intel and Microsoft. Expanded Memory can be either memory on an memory expansion card or a part of the main memory. The specification describes that this memory can be used by mapping a 64 kB large part to the Upper Memory Area between 640 kB and 1 Mb. The 64 kB region within the Upper Memory Area is referred to as EMS Page Frame. The latest EMS 4.0 allowed to use up to 32 Mb as expanded memory. The most commonly used memory management driver implementing EMS is EMM386.EXE that has to be loaded in config.sys as second driver after HIMEM.SYS. EMM386 emulates expanded memory by using main memory beyond the High Memory Area. In the case no EMS is required this feature can be deactivated by using the parameter NOEMS. This frees 64 kB in the Upper Memory Area for loading TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
XMS&lt;br /&gt;
(todo)&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
(todo: list of memory managing software?)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1187</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1187"/>
				<updated>2013-04-10T21:44:26Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Upper memory */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory area is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory. The external program MEM reports the amount of High RAM. Parts of DOS can be loaded into Upper Memory Blocks by specifying DOS=UMB in config.sys but usually it is better to load DOS to the High Memory Area leaving Upper Memory Blocks free for TSR-programs.&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
EMS&lt;br /&gt;
(todo)&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
XMS&lt;br /&gt;
(todo)&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
(todo: list of memory managing software?)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1186</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1186"/>
				<updated>2013-04-10T21:41:11Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* High memory area */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory.&lt;br /&gt;
The external program MEM reports the amount of High RAM.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
The High Memory Area (HMA) are the 64 kb directly above 1 Mb. To use HMA it is required to load HIMEM.SYS in config.sys that enables the A20-gate to gain access to memory beyond 1 Mb. The HMA is typically used to move parts of DOS there that normally occupy conventional memory. For this in config.sys the line '''DOS=HIGH''' has to be specified. The external program MEM reports if DOS is using the HMA.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
EMS&lt;br /&gt;
(todo)&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
XMS&lt;br /&gt;
(todo)&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
(todo: list of memory managing software?)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1185</id>
		<title>DOS memory management</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=DOS_memory_management&amp;diff=1185"/>
				<updated>2013-04-10T19:54:31Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all.&lt;br /&gt;
In DOS hardware and memory access is closely related to the standards defined by the x86 architecture. In DOS memory is split into different regions and there are several standards as EMS and XMS for accessing memory. To use the available RAM effectively in DOS you have to know how the x86 architecture splits up RAM, what these different regions are for. It is also helpful to know the most common memory management drivers. Optimizing your system to attain enough free memory for your programs is called '''memory management'''.&lt;br /&gt;
&lt;br /&gt;
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favorite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice.&lt;br /&gt;
&lt;br /&gt;
== Types of memory ==&lt;br /&gt;
=== Conventional memory ===&lt;br /&gt;
Conventional memory or base memory is the memory range between 0 kb and 640 kb. Programs are loaded to this memory range. The available free memory can be lower as some drivers have to leave a part of their code in memory to handle e.g. hardware. This is called Terminate and Stay Resident (TSR). By default such drivers are placed in conventional memory.&lt;br /&gt;
The amount of free conventional memory is reported by CHKDSK or MEM.&lt;br /&gt;
&lt;br /&gt;
=== Upper memory ===&lt;br /&gt;
The upper memory is memory in the range between 640 kb and 1 Mb. By default there is no RAM in this range as it is reserved for use with hardware that is able to map own memory to this range. Usually present in this region is a part of the graphics cards RAM and the BIOS ROMs of the graphics card and mainboard. Additional hardware like mass storage controllers, network adapters... can use additional parts for own BIOS ROMs or buffer RAM. Mainboard chipsets allow to map blocks of mainboard RAM in the remaining unused memory range. These blocks are called Upper Memory Blocks (UMB) and are treated from DOS as High Memory. The default memory management driver that enables this mapping is EMM386.EXE. It has to be loaded in config.sys as second driver after HIMEM.SYS. The driver tries to detect common unused blocks and maps UMBs there.&lt;br /&gt;
TSR-programs can be loaded to UMBs (in High Memory) in config.sys by using ''DEVICEHIGH=driver.sys'' or in autoexec.bat with the loadhigh statement, like ''LH driver.com''. If no High RAM is avilable the drivers will be loaded to Conventional Memory.&lt;br /&gt;
The external program MEM reports the amount of High RAM.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== High memory area ===&lt;br /&gt;
HMA is the first 64KB above the 1MB limit. This can be a bit confusing if you're just getting started in memory management, since the name is similar to upper memory area and is usually referred to in the same context as upper memory. They are in fact separate regions, where the upper memory is '''below''' the high memory area. If you really want to know how this became a separate region, use your favourite search engine. All you really need to know is that you can load parts of DOS into it by specifying '''DOS=HIGH(,UMB)''' in your config.sys file. Using HMA requires a driver that enable the A20-gate to gain access to memory beyond the 1 MB barrier like HIMEM.SYS.&lt;br /&gt;
&lt;br /&gt;
=== Expanded memory ===&lt;br /&gt;
EMS&lt;br /&gt;
(todo)&lt;br /&gt;
&lt;br /&gt;
=== Extended memory ===&lt;br /&gt;
XMS&lt;br /&gt;
(todo)&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
=== Getting more conventional memory ===&lt;br /&gt;
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access.&lt;br /&gt;
The availability of memory types depends on CPU and chipset.&lt;br /&gt;
&lt;br /&gt;
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API.&lt;br /&gt;
It is also possible to emulate a EMS page frame with the EMM286 driver.&lt;br /&gt;
&lt;br /&gt;
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.&lt;br /&gt;
&lt;br /&gt;
(todo UMBPCI)&lt;br /&gt;
&lt;br /&gt;
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware.&lt;br /&gt;
Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (&amp;gt; 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.&lt;br /&gt;
&lt;br /&gt;
(todo: expand)&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
(todo: list of memory managing software?)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Windows_versions&amp;diff=1179</id>
		<title>Windows versions</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Windows_versions&amp;diff=1179"/>
				<updated>2013-04-09T14:24:30Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a list describing different Windows versions in terms of game compatibility.&lt;br /&gt;
&lt;br /&gt;
=== Windows 3.x ===&lt;br /&gt;
&lt;br /&gt;
Windows 3.0 is a graphical environment that can be run from DOS. The requirements are a 8088/8086 CPU, 386K of RAM, 6-7 MB HDD free space, a CGA/EGA/VGA/Hercules/8514/A graphics adapter and MS-DOS 3.1.. Windows 3.0 supports also 286/386 CPUs and can be run in Real Mode, 286 Protected Mode or 386 Protected Mode. However due to the similar implementation of the 386 Protected Mode the maximum useable memory is 16 MB, same as the limit for 286 Protected Mode. A few programs are included in Windows 3.0 like Program Manager, File Manager, Notepad, Paintbrush, Reversi and Solitaire. Later the Multimedia Extension 1.0 upgrade was released including a Soundblaster Pro and CD-ROM drive (Panasonic?). For True Type Font support Adobe Type Manager has to be installed.&lt;br /&gt;
&lt;br /&gt;
Windows 3.1&lt;br /&gt;
&lt;br /&gt;
Windows 3.11&lt;br /&gt;
&lt;br /&gt;
Windows for Workgroups 3.11&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Windows 95 ===&lt;br /&gt;
&lt;br /&gt;
=== Windows NT4 === &lt;br /&gt;
Windows NT4 uses a preemptive multitasking kernel and supports two CPUs and up to 4 GB RAM in the Workstation Professional version. The system is rather lightweight and requires only a 486DX2-66 and about 32 MB RAM, a Pentium system is recommended. After boot the whole Windows system uses just about 16 MB RAM. Windows NT4 has a higher stability as Windows 95.&lt;br /&gt;
It was released with DirectX2 and got support for DirectX3 with the latest servicepack 6a. The user interface is the same as in Windows 95 with some additional features from Microsoft Plus! for Windows 95. However it is possible to upgrade to the user interface known from Windows 98 by installing Internet Explorer 4 with Active Desktop. &lt;br /&gt;
Windows NT4 does not support Plug and Play and USB. This is usually no problem since drivers for PnP hardware bring their own configuration sheet and for mass storage USB devices third party software is available.&lt;br /&gt;
&lt;br /&gt;
For gaming Direct3D from DirectX3 is supported. However most DirectX games with accelerated 3D graphics require at least DirectX5. Still, DirectX3 allows most 2D games that use DirectDraw to run (e.g. Starcraft, Diablo e.g.). Benchmarks show that due to the different driver architecture accelerated 2D graphics is a lot faster compared to Windows 95.&lt;br /&gt;
The OpenGL support from graphics card drivers for Windows NT4 is solid. Also the most important gaming 3D accelerator cards from 3dfx at this time have Glide support in Windows NT4. Thus most Glide compatible games work (e.g. Unreal engines, Quake engines).&lt;br /&gt;
&lt;br /&gt;
Any 16 bit related code like DOS programs are run in a Virtual DOS machine (NTVDM). It supports 486 code. Direct hardware calls are not possible.&lt;br /&gt;
&lt;br /&gt;
=== Windows 98 ===&lt;br /&gt;
Best all-in-one operating system for DOS and Win9x gaming. Basically a much more refined continuation of Windows 95. Good DOS compatibility either by DOS window or rebooting into DOS. Emulates USB mouses and gamepads in DOS window as well. Has numerous features that Win95 got only with the OSR releases and which weren't present in its original release, such as support for P6 (Pentium Pro and up), FAT32, selection of IRQs, AGP, UDMA, USB and MMX.&lt;br /&gt;
&lt;br /&gt;
Furthermore, SSE and multiple monitor support is exclusive for Windows 98 and up. Windows 98 supports up to 512 MB RAM without tweaking, with tweaking up to 1 GB. 3rd party USB mass storage drivers, namely nusb33e, are only available for Windows 98 SE due to its newer USB stack, so this revision is by far preferable. 3rd party drivers are also available for ADSL connectivity (raspppoe).&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Windows 2000 ===&lt;br /&gt;
A continuation of NT4 and the final OS from the NT line without a version targeted at home users/consumers. In similar fashion to the relation between 95 and NT4, 2000 is more stable than 98, although several graphics cards manufacturers initially had problems providing drivers with the same performance as under 98. Win2000 Professional supports up to two processors, Windows2000 Server up to four, with no differentiation between physical processors and individual cores on a multi-core CPU.&lt;br /&gt;
&lt;br /&gt;
=== Windows XP ===&lt;br /&gt;
Last OS from Microsoft so far to support game ports, MPU-401 ports, the IPX protocol, out of the box MIDI device selection and EAX 3D sound hardware acceleration through the DirectSound HAL. Generally good Win9x game compatibility.&lt;br /&gt;
&lt;br /&gt;
DOS programs are run in the NT Virtual DOS Machine (NTVDM). Basic Sound Blaster 2.0 and MPU-401 support can be enabled by adding SET BLASTER=A220 I5 D1 P330 T3 to the autoexec.nt file. The virtual resources do not have to represent real hardware resources. The NTVDM emulation uses the default windows multimedia devices. Direct hardware access from within NTVDM is not possible.&lt;br /&gt;
&lt;br /&gt;
Windows XP introduced the recognition of Intel's Hyper-threading simultaneous multithreading technique. Furthermore, it differentiates between actual physical processors with their own socket and multiple cores on one CPU. WinXP Home Edition supports one physical processor, WinXP Professional two; both support up to 32 cores without Hyper-threading, 16 with it. The somewhat exotic Windows XP x64, which is essentially a relabeled Server 2003 x64, supports up to 64 and 32 cores, respectively.&lt;br /&gt;
&lt;br /&gt;
== External Links ==&lt;br /&gt;
*[http://exuberant.ms11.net/98sesp.html Unofficial Win98 SE service pack with several tweaks and fixes]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Windows_versions&amp;diff=1175</id>
		<title>Windows versions</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Windows_versions&amp;diff=1175"/>
				<updated>2013-04-09T00:08:09Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a list describing different Windows versions in terms of game compatibility.&lt;br /&gt;
&lt;br /&gt;
'''Windows 3.x:'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''Windows 95:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Windows NT4:''' Windows NT4 uses a preemptive multitasking kernel and supports two CPUs and up to 4 GB RAM in the Workstation Professional version. The system is rather lightweight and requires only a 486DX2-66 and about 32 MB RAM, a Pentium system is recommended. After boot the whole Windows system uses just about 16 MB RAM. Windows NT4 has a higher stability as Windows 95.&lt;br /&gt;
It was released with DirectX2 and got support for DirectX3 with the latest servicepack 6a. The user interface is the same as in Windows 95 with some additional features from Microsoft Plus! for Windows 95. However it is possible to upgrade to the user interface known from Windows 98 by installing Internet Explorer 4 with Active Desktop. &lt;br /&gt;
Windows NT4 does not support Plug and Play and USB. This is usually no problem since drivers for PnP hardware bring their own configuration sheet and for mass storage USB devices third party software is available.&lt;br /&gt;
&lt;br /&gt;
For gaming Direct3D from DirectX3 is supported. However most DirectX games with accelerated 3D graphics require at least DirectX5. Still, DirectX3 allows most 2D games that use DirectDraw to run (e.g. Starcraft, Diablo e.g.). Benchmarks show that due to the different driver architecture accelerated 2D graphics is a lot faster compared to Windows 95.&lt;br /&gt;
The OpenGL support from graphics card drivers for Windows NT4 is solid. Also the most important gaming 3D accelerator cards from 3dfx at this time have Glide support in Windows NT4. Thus most Glide compatible games work (e.g. Unreal engines, Quake engines).&lt;br /&gt;
&lt;br /&gt;
Any 16 bit related code like DOS programs are run in a Virtual DOS machine (NTVDM). It supports 486 code. Direct hardware calls are not possible.&lt;br /&gt;
&lt;br /&gt;
'''Windows 98:''' Best all-in-one operating system for DOS and Win9x gaming. Basically a much more refined continuation of Windows 95. Good DOS compatibility either by DOS window or rebooting into DOS. Emulates USB mouses and gamepads in DOS window as well. Has numerous features that Win95 got only with the OSR releases and which weren't present in its original release, such as support for P6 (Pentium Pro and up), FAT32, selection of IRQs, AGP, UDMA, USB and MMX.&amp;lt;br&amp;gt;&lt;br /&gt;
Furthermore, SSE and multiple monitor support is exclusive for Windows 98 and up. Windows 98 supports up to 512 MB RAM without tweaking, with tweaking up to 1 GB. 3rd party USB mass storage drivers, namely nusb33e, are only available for Windows 98 SE due to its newer USB stack, so this revision is by far preferable. 3rd party drivers are also available for ADSL connectivity (raspppoe).&amp;lt;br&amp;gt;&lt;br /&gt;
'''Windows 2000:'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''Windows XP:''' Last OS from Microsoft so far to support game ports, MPU-401 ports, the IPX protocol, out of the box MIDI device selection and EAX 3D sound hardware acceleration through the DirectSound HAL. Generally good Win9x game compatibility. &lt;br /&gt;
DOS programs are run in the NT Virtual DOS Machine (NTVDM). Basic Sound Blaster 2.0 and MPU-401 support can be enabled by adding SET BLASTER=A220 I5 D1 P330 T3 to the autoexec.nt file. The virtual resources do not have to represent real hardware resources. The NTVDM emulation uses the default windows multimedia devices. Direct hardware access from within NTVDM is not possible.&lt;br /&gt;
&lt;br /&gt;
== External Links ==&lt;br /&gt;
*[http://exuberant.ms11.net/98sesp.html Unofficial Win98 SE service pack with several tweaks and fixes]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Windows_versions&amp;diff=1174</id>
		<title>Windows versions</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Windows_versions&amp;diff=1174"/>
				<updated>2013-04-09T00:03:20Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a list describing different Windows versions in terms of game compatibility.&lt;br /&gt;
&lt;br /&gt;
'''Windows 3.x:'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''Windows 95:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Windows NT4:''' Windows NT4 uses a preemptive multitasking kernel and supports two CPUs and up to 4 GB RAM in the Workstation Professional version. The system is rather lightweight and requires only a 486DX2-66 and about 32 MB RAM, a Pentium system is recommended. After boot the whole Windows system uses just about 16 MB RAM. Windows NT4 has a higher stability as Windows 95.&lt;br /&gt;
It was released with DirectX2 and got support for DirectX3 with the latest servicepack 6a. The user interface is the same as in Windows 95 with some additional features from Microsoft Plus! for Windows 95. However it is possible to upgrade to the user interface known from Windows 98 by installing Internet Explorer 4 with Active Desktop. &lt;br /&gt;
Windows NT4 does not support Plug and Play and USB. This is usually no problem since drivers for PnP hardware bring their own configuration sheet and for mass storage USB devices third party software is available.&lt;br /&gt;
&lt;br /&gt;
For gaming Direct3D from DirectX3 is supported. However most DirectX games with accelerated 3D graphics require at least DirectX5. Still, DirectX3 allows most 2D games that use DirectDraw to run (e.g. Starcraft, Diablo e.g.). Benchmarks show that due to the different driver architecture accelerated 2D graphics is a lot faster compared to Windows 95.&lt;br /&gt;
The OpenGL support from graphics card drivers for Windows NT4 is solid. Also the most important gaming 3D accelerator cards from 3dfx at this time have Glide support in Windows NT4. Thus most Glide compatible games work (e.g. Unreal engines, Quake engines).&lt;br /&gt;
&lt;br /&gt;
Any 16 bit related code like DOS programs are run in a Virtual DOS machine (NTVDM). It supports 486 code. Direct hardware calls are not possible.&lt;br /&gt;
&lt;br /&gt;
'''Windows 98:''' Best all-in-one operating system for DOS and Win9x gaming. Basically a much more refined continuation of Windows 95. Good DOS compatibility either by DOS window or rebooting into DOS. Emulates USB mouses and gamepads in DOS window as well. Has numerous features that Win95 got only with the OSR releases and which weren't present in its original release, such as support for P6 (Pentium Pro and up), FAT32, selection of IRQs, AGP, UDMA, USB and MMX.&amp;lt;br&amp;gt;&lt;br /&gt;
Furthermore, SSE and multiple monitor support is exclusive for Windows 98 and up. Windows 98 supports up to 512 MB RAM without tweaking, with tweaking up to 1 GB. 3rd party USB mass storage drivers, namely nusb33e, are only available for Windows 98 SE due to its newer USB stack, so this revision is by far preferable. 3rd party drivers are also available for ADSL connectivity (raspppoe).&amp;lt;br&amp;gt;&lt;br /&gt;
'''Windows 2000:'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''Windows XP:''' Last OS from Microsoft so far to support game ports, MPU-401 ports, the IPX protocol, out of the box MIDI device selection and EAX 3D sound hardware acceleration through the DirectSound HAL. Generally good Win9x game compatibility. &lt;br /&gt;
DOS programs are run in the NT Virtual DOS Machine (NTVDM). Basic Sound Blaster 2.0 and MPU-401 support can be enabled by adding SET BLASTER=A220 I5 D1 P330 T3 to the autoexec.nt file. The virtual resources do not have to represent real hardware resources. The NTVDM emulation uses the default windows multimedia devices. Direct hardware access is not possible.&lt;br /&gt;
&lt;br /&gt;
== External Links ==&lt;br /&gt;
*[http://exuberant.ms11.net/98sesp.html Unofficial Win98 SE service pack with several tweaks and fixes]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Windows_versions&amp;diff=1166</id>
		<title>Talk:Windows versions</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Windows_versions&amp;diff=1166"/>
				<updated>2013-04-08T10:32:26Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: Created page with &amp;quot;Please never write that something is best, like with Win98. Always write for which application. If you have a 386 system for vintage gaming, Windows 98 is definitely not the b...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Please never write that something is best, like with Win98. Always write for which application. If you have a 386 system for vintage gaming, Windows 98 is definitely not the best because it wont even install.&lt;br /&gt;
You should also try to mention the drawbacks and disadvantages and f.e. Win98 has some.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 20:32, 8 April 2013 (EST)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1123</id>
		<title>Talk:Socket 7 Builds</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1123"/>
				<updated>2013-04-05T11:39:29Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The presented VX Pro and TX Pro facts should be removed since they do not contain valuable information.&lt;br /&gt;
Even the linked Redhill Guide article mentiones that the VX Pro is slower and that the TX Pro ran quite well even at 75 MHz. Quite a contradiction to whats written here.&lt;br /&gt;
&lt;br /&gt;
TX Pro is btw the SIS5591 chipset and VX Pro+ the Apollo VPX chipset.&lt;br /&gt;
&lt;br /&gt;
I have boards with both chipsets and I don't have anything to complain about these boards. Lower performance compared to i430VX might be the case for the VX Pro+, i did no direct comparison.&lt;br /&gt;
The comparison should be done against another Apollo VPX board.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 10:53, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Is that better? :)&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 16:54, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Yes. Still the fact with the high defect rates has no source. Redhill writes that PCChips builds mainboards with lowest quality, but defect rates for VX Pro+ and TX Pro are not given. So it is open, if these boards had high defect rates. At least the boards I have still work, but that doesn't tell statistics. Also defect rate tend to follow the bath tub curve. So if anyone gets such a mainboard and it is still working it is more unlikely to fail soon.&lt;br /&gt;
&lt;br /&gt;
So I would change the argumentation this way, that the boards were manufactured by PC Chips, a company that is known to use lowest quality components. I would not mention defect rates for these boards, as I do not know them and there is no source for defect rates.&lt;br /&gt;
[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 02:12, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
As a matter of fact, there is. http://redhill.net.au/b/b-bad.html&lt;br /&gt;
&lt;br /&gt;
''Second, they are made by PC Chips, renowned as the industry's cheapest, lowest-quality manufacturer. Their defective rates are legendary, between 10-15% in an industry where 5% or less is considered good. PC Chips was also the originator of putting &amp;quot;fake&amp;quot; plastic cache chips on motherboards. With these VX Pro boards you really do get what you pay for. ... The price is unbeatable, but price has always been PC Chip's sole selling point. ... Why would you buy a motherboard made by the industry's absolute lowest bidder?''&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 04:06, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
I read this. My interpretation of this text is that they extend the prior defective rates to the at this time new VX Pro boards. For me this is rather speculative. It could has been as well that while the boards were cheap the defective rates were ok, especially since the TX Pro worked well. But maybe some native english speaker reads there something between the lines.&lt;br /&gt;
&lt;br /&gt;
However, today the focus whats important is different. If you get such a board and it still works then it is still a Socket 7 system. If performance matters just get another board. No manufacturer knows how the defective rates change after 20 years.&lt;br /&gt;
[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 04:43, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Ok, I think, I got your point:) I really appreciate your attitude, it's pretty much scientifical and seems to oppose any kind of &amp;quot;holy war&amp;quot;. I changed a few lines in hope this would be the most adequate angle, at which the user would know what he's dealing with, but would not worry much in case it works OK. Still, I think that the owner of the actual hardware should have the final word here. By the way, can you provide some benchmark results for the special section? It really lacks data collected from non-intel chipsets.&lt;br /&gt;
&lt;br /&gt;
And what do you think of RAM paragraph?&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 05:38, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Well, most importantly that PS/2 SIMMs have to be plugged as pairs in S7 systems is missing. The 3.3V vs. 5V issue is not too critical as most memory chips support the whole voltage range. The heat dissipation as written should be considered. The golden rule for SDRAM is to choose DIMMs with a lot of ICs for high capacities. On the other hand it may not be a problem if only a partial capacity is detected. I would always recommend to run memtest86 at least 1-pass for a large memory setup to find out if chipset and DIMMs work in combination. PS/2 SIMMs are usually not problematic regarding memory layouts exceeding the memory controllers specs.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 06:08, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Forgot to mention that SIMMS work in pairs. However, that's only partially true for EDO, on 2 of 3 boards I posess EDO RAM works well without the same stick in the adjacent slot.--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 17:06, 5 April 2013 (EST)&lt;br /&gt;
A pair means same memory organization. It doesn't mean that it has to be the same manufacturer. Of course the risk is higher with different manufacturers to choose mismatched sticks. But this can be seen by the amount of detected memory.&lt;br /&gt;
Maybe it is also worth to mention that 430VX started to support EDO, while 430FX f.e. did not. And what about S7 boards supporting BEDO?[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 22:39, 5 April 2013 (EST)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1117</id>
		<title>Talk:Socket 7 Builds</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1117"/>
				<updated>2013-04-04T19:08:43Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The presented VX Pro and TX Pro facts should be removed since they do not contain valuable information.&lt;br /&gt;
Even the linked Redhill Guide article mentiones that the VX Pro is slower and that the TX Pro ran quite well even at 75 MHz. Quite a contradiction to whats written here.&lt;br /&gt;
&lt;br /&gt;
TX Pro is btw the SIS5591 chipset and VX Pro+ the Apollo VPX chipset.&lt;br /&gt;
&lt;br /&gt;
I have boards with both chipsets and I don't have anything to complain about these boards. Lower performance compared to i430VX might be the case for the VX Pro+, i did no direct comparison.&lt;br /&gt;
The comparison should be done against another Apollo VPX board.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 10:53, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Is that better? :)&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 16:54, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Yes. Still the fact with the high defect rates has no source. Redhill writes that PCChips builds mainboards with lowest quality, but defect rates for VX Pro+ and TX Pro are not given. So it is open, if these boards had high defect rates. At least the boards I have still work, but that doesn't tell statistics. Also defect rate tend to follow the bath tub curve. So if anyone gets such a mainboard and it is still working it is more unlikely to fail soon.&lt;br /&gt;
&lt;br /&gt;
So I would change the argumentation this way, that the boards were manufactured by PC Chips, a company that is known to use lowest quality components. I would not mention defect rates for these boards, as I do not know them and there is no source for defect rates.&lt;br /&gt;
[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 02:12, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
As a matter of fact, there is. http://redhill.net.au/b/b-bad.html&lt;br /&gt;
&lt;br /&gt;
''Second, they are made by PC Chips, renowned as the industry's cheapest, lowest-quality manufacturer. Their defective rates are legendary, between 10-15% in an industry where 5% or less is considered good. PC Chips was also the originator of putting &amp;quot;fake&amp;quot; plastic cache chips on motherboards. With these VX Pro boards you really do get what you pay for. ... The price is unbeatable, but price has always been PC Chip's sole selling point. ... Why would you buy a motherboard made by the industry's absolute lowest bidder?''&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 04:06, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
I read this. My interpretation of this text is that they extend the prior defective rates to the at this time new VX Pro boards. For me this is rather speculative. It could has been as well that while the boards were cheap the defective rates were ok, especially since the TX Pro worked well. But maybe some native english speaker reads there something between the lines.&lt;br /&gt;
&lt;br /&gt;
However, today the focus whats important is different. If you get such a board and it still works then it is still a Socket 7 system. If performance matters just get another board. No manufacturer knows how the defective rates change after 20 years.&lt;br /&gt;
[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 04:43, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Ok, I think, I got your point:) I really appreciate your attitude, it's pretty much scientifical and seems to oppose any kind of &amp;quot;holy war&amp;quot;. I changed a few lines in hope this would be the most adequate angle, at which the user would know what he's dealing with, but would not worry much in case it works OK. Still, I think that the owner of the actual hardware should have the final word here. By the way, can you provide some benchmark results for the special section? It really lacks data collected from non-intel chipsets.&lt;br /&gt;
&lt;br /&gt;
And what do you think of RAM paragraph?&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 05:38, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Well, most importantly that PS/2 SIMMs have to be plugged as pairs in S7 systems is missing. The 3.3V vs. 5V issue is not too critical as most memory chips support the whole voltage range. The heat dissipation as written should be considered. The golden rule for SDRAM is to choose DIMMs with a lot of ICs for high capacities. On the other hand it may not be a problem if only a partial capacity is detected. I would always recommend to run memtest86 at least 1-pass for a large memory setup to find out if chipset and DIMMs work in combination. PS/2 SIMMs are usually not problematic regarding memory layouts exceeding the memory controllers specs.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 06:08, 5 April 2013 (EST)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1091</id>
		<title>Talk:Socket 7 Builds</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1091"/>
				<updated>2013-04-04T17:43:07Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The presented VX Pro and TX Pro facts should be removed since they do not contain valuable information.&lt;br /&gt;
Even the linked Redhill Guide article mentiones that the VX Pro is slower and that the TX Pro ran quite well even at 75 MHz. Quite a contradiction to whats written here.&lt;br /&gt;
&lt;br /&gt;
TX Pro is btw the SIS5591 chipset and VX Pro+ the Apollo VPX chipset.&lt;br /&gt;
&lt;br /&gt;
I have boards with both chipsets and I don't have anything to complain about these boards. Lower performance compared to i430VX might be the case for the VX Pro+, i did no direct comparison.&lt;br /&gt;
The comparison should be done against another Apollo VPX board.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 10:53, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Is that better? :)&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 16:54, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Yes. Still the fact with the high defect rates has no source. Redhill writes that PCChips builds mainboards with lowest quality, but defect rates for VX Pro+ and TX Pro are not given. So it is open, if these boards had high defect rates. At least the boards I have still work, but that doesn't tell statistics. Also defect rate tend to follow the bath tub curve. So if anyone gets such a mainboard and it is still working it is more unlikely to fail soon.&lt;br /&gt;
&lt;br /&gt;
So I would change the argumentation this way, that the boards were manufactured by PC Chips, a company that is known to use lowest quality components. I would not mention defect rates for these boards, as I do not know them and there is no source for defect rates.&lt;br /&gt;
[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 02:12, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
As a matter of fact, there is. http://redhill.net.au/b/b-bad.html&lt;br /&gt;
&lt;br /&gt;
''Second, they are made by PC Chips, renowned as the industry's cheapest, lowest-quality manufacturer. Their defective rates are legendary, between 10-15% in an industry where 5% or less is considered good. PC Chips was also the originator of putting &amp;quot;fake&amp;quot; plastic cache chips on motherboards. With these VX Pro boards you really do get what you pay for. ... The price is unbeatable, but price has always been PC Chip's sole selling point. ... Why would you buy a motherboard made by the industry's absolute lowest bidder?''&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 04:06, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
I read this. My interpretation of this text is that they extend the prior defective rates to the at this time new VX Pro boards. For me this is rather speculative. It could has been as well that while the boards were cheap the defective rates were ok, especially since the TX Pro worked well. But maybe some native english speaker reads there something between the lines.&lt;br /&gt;
&lt;br /&gt;
However, today the focus whats important is different. If you get such a board and it still works then it is still a Socket 7 system. If performance matters just get another board. No manufacturer knows how the defective rates change after 20 years.&lt;br /&gt;
[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 04:43, 5 April 2013 (EST)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1090</id>
		<title>Talk:Socket 7 Builds</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1090"/>
				<updated>2013-04-04T17:42:54Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The presented VX Pro and TX Pro facts should be removed since they do not contain valuable information.&lt;br /&gt;
Even the linked Redhill Guide article mentiones that the VX Pro is slower and that the TX Pro ran quite well even at 75 MHz. Quite a contradiction to whats written here.&lt;br /&gt;
&lt;br /&gt;
TX Pro is btw the SIS5591 chipset and VX Pro+ the Apollo VPX chipset.&lt;br /&gt;
&lt;br /&gt;
I have boards with both chipsets and I don't have anything to complain about these boards. Lower performance compared to i430VX might be the case for the VX Pro+, i did no direct comparison.&lt;br /&gt;
The comparison should be done against another Apollo VPX board.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 10:53, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Is that better? :)&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 16:54, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Yes. Still the fact with the high defect rates has no source. Redhill writes that PCChips builds mainboards with lowest quality, but defect rates for VX Pro+ and TX Pro are not given. So it is open, if these boards had high defect rates. At least the boards I have still work, but that doesn't tell statistics. Also defect rate tend to follow the bath tub curve. So if anyone gets such a mainboard and it is still working it is more unlikely to fail soon.&lt;br /&gt;
&lt;br /&gt;
So I would change the argumentation this way, that the boards were manufactured by PC Chips, a company that is known to use lowest quality components. I would not mention defect rates for these boards, as I do not know them and there is no source for defect rates.&lt;br /&gt;
[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 02:12, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
As a matter of fact, there is. http://redhill.net.au/b/b-bad.html&lt;br /&gt;
&lt;br /&gt;
''Second, they are made by PC Chips, renowned as the industry's cheapest, lowest-quality manufacturer. Their defective rates are legendary, between 10-15% in an industry where 5% or less is considered good. PC Chips was also the originator of putting &amp;quot;fake&amp;quot; plastic cache chips on motherboards. With these VX Pro boards you really do get what you pay for. ... The price is unbeatable, but price has always been PC Chip's sole selling point. ... Why would you buy a motherboard made by the industry's absolute lowest bidder?''&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 04:06, 5 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
I read this. My interpretation of this text is that they extend the prior defective rates to the at this time new VX Pro boards. For me this is rather speculative. It could has been as well that while the boards were cheap the defective rates were ok, especially since the TX Pro worked well. But maybe some native english speaker reads there something between the lines.&lt;br /&gt;
&lt;br /&gt;
However, today the focus whats important is different. If you get such a board and it still works then it is still a Socket 7 system. If performance matters just get another board. No manufacturer knows how the defective rates change after 20 years.&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1080</id>
		<title>Talk:Socket 7 Builds</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1080"/>
				<updated>2013-04-04T15:12:23Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The presented VX Pro and TX Pro facts should be removed since they do not contain valuable information.&lt;br /&gt;
Even the linked Redhill Guide article mentiones that the VX Pro is slower and that the TX Pro ran quite well even at 75 MHz. Quite a contradiction to whats written here.&lt;br /&gt;
&lt;br /&gt;
TX Pro is btw the SIS5591 chipset and VX Pro+ the Apollo VPX chipset.&lt;br /&gt;
&lt;br /&gt;
I have boards with both chipsets and I don't have anything to complain about these boards. Lower performance compared to i430VX might be the case for the VX Pro+, i did no direct comparison.&lt;br /&gt;
The comparison should be done against another Apollo VPX board.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 10:53, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Is that better? :)&lt;br /&gt;
--[[User:RacoonRider|RacoonRider]] ([[User talk:RacoonRider|talk]]) 16:54, 4 April 2013 (EST)&lt;br /&gt;
&lt;br /&gt;
Yes. Still the fact with the high defect rates has no source. Redhill writes that PCChips builds mainboards with lowest quality, but defect rates for VX Pro+ and TX Pro are not given. So it is open, if these boards had high defect rates. At least the boards I have still work, but that doesn't tell statistics. Also defect rate tend to follow the bath tub curve. So if anyone gets such a mainboard and it is still working it is more unlikely to fail soon.&lt;br /&gt;
&lt;br /&gt;
So I would change the argumentation this way, that the boards were manufactured by PC Chips, a company that is known to use lowest quality components. I would not mention defect rates for these boards, as I do not know them and there is no source for defect rates.&lt;br /&gt;
[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 02:12, 5 April 2013 (EST)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1074</id>
		<title>Talk:Socket 7 Builds</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Socket_7_Builds&amp;diff=1074"/>
				<updated>2013-04-03T23:53:51Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: Created page with &amp;quot;The presented VX Pro and TX Pro facts should be removed since they do not contain valuable information. Even the linked Redhill Guide article mentiones that the VX Pro is slow...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The presented VX Pro and TX Pro facts should be removed since they do not contain valuable information.&lt;br /&gt;
Even the linked Redhill Guide article mentiones that the VX Pro is slower and that the TX Pro ran quite well even at 75 MHz. Quite a contradiction to whats written here.&lt;br /&gt;
&lt;br /&gt;
TX Pro is btw the SIS5591 chipset and VX Pro+ the Apollo VPX chipset.&lt;br /&gt;
&lt;br /&gt;
I have boards with both chipsets and I don't have anything to complain about these boards. Lower performance compared to i430VX might be the case for the VX Pro+, i did no direct comparison.&lt;br /&gt;
The comparison should be done against another Apollo VPX board.[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 10:53, 4 April 2013 (EST)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Talk:Maestro_32/96&amp;diff=945</id>
		<title>Talk:Maestro 32/96</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Talk:Maestro_32/96&amp;diff=945"/>
				<updated>2013-03-19T10:38:58Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The thing with MIDI-1 SysEx messages is true for the EWS64 as well from my testing. Also, I thought fast systems with this card were simply unbootable instead of speed issues in games. [[User:D1stortion|D1stortion]] ([[User talk:D1stortion|talk]]) 00:42, 19 March 2013 (EST)&lt;br /&gt;
:I got that Sysex information from the M3296 FAQ on the Terratec FTP server. I also recall that some faster systems (Athlon and above) will not (warm-)boot with this card. I think Terratec published a hardware fix for that (exchanging a capacitor on the card or something like that...). [[User:Pyrogx|Pyrogx]] ([[User talk:Pyrogx|talk]]) 04:03, 19 March 2013 (EST)&lt;br /&gt;
::Yup, I read it too. It just came to my attention that the same applies to the EWS64, even if it's not listed in the respective FAQ. In any case, it makes sense since those cards are almost identical in many ways.&amp;lt;br&amp;gt;As for the speed issue, I think I read that it starts with about P200 or so... [[User:D1stortion|D1stortion]] ([[User talk:D1stortion|talk]]) 05:52, 19 March 2013 (EST)&lt;br /&gt;
::: I can't give facts about the M3296 as I do not own such a card. I have several EWS64s/XLs, also in fast systems and didn't experienced boot problems with these. Is there any source which cards revisions are affected? How does the boot up bug manifests?--[[User:Enigma|Enigma]] ([[User talk:Enigma|talk]]) 21:38, 19 March 2013 (EST)&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Sound_Cards_%26_Modules&amp;diff=929</id>
		<title>Sound Cards &amp; Modules</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Sound_Cards_%26_Modules&amp;diff=929"/>
				<updated>2013-03-16T23:54:32Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;*[[Creative Labs]]&lt;br /&gt;
*[[Ad Lib, Inc.]]&lt;br /&gt;
*[[Advanced Gravis]]&lt;br /&gt;
*[[Roland]]&lt;br /&gt;
*[[Yamaha]]&lt;br /&gt;
*[[Terratec]]&lt;br /&gt;
*[[Guillemot]]&lt;br /&gt;
*[[Ensoniq]]&lt;br /&gt;
*[[ESS Technologies]]&lt;br /&gt;
*[[Aureal Semiconductor]]&lt;br /&gt;
*[[C-Media]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Hardware]]&lt;br /&gt;
[[Category:Sound Cards]]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Terratec&amp;diff=928</id>
		<title>Terratec</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Terratec&amp;diff=928"/>
				<updated>2013-03-16T23:53:00Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Terratec is a German manufacturer of multimedia equipment founded in 1994. Their products mainly include sound cards and TV adapters.&lt;br /&gt;
&lt;br /&gt;
== Soundcards (ISA) ==&lt;br /&gt;
&lt;br /&gt;
* Base 1 (Analog Devices AD1816JS SoundPort)&lt;br /&gt;
* [[EWS64]] family&lt;br /&gt;
* Maestro 32/96&lt;br /&gt;
&lt;br /&gt;
== Soundcards (PCI) ==&lt;br /&gt;
&lt;br /&gt;
* Solo 1 (ESS Solo-1 ES1938S)&lt;br /&gt;
* XLerate Pro (Aureal Vortex2)&lt;br /&gt;
* DMX XFire (Crystal SoundFusion CS4624)&lt;br /&gt;
* SiXPack (Crystal SoundFusion CS4630)&lt;br /&gt;
* 512i digital (ForteMedia FM801)&lt;br /&gt;
* Soundsystem DMX (ESS Canyon3D)&lt;br /&gt;
&lt;br /&gt;
[[Category:Hardware]]&lt;br /&gt;
[[Category:Sound Cards]]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=Example_.TTM_file_for_EWS64S&amp;diff=918</id>
		<title>Example .TTM file for EWS64S</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=Example_.TTM_file_for_EWS64S&amp;diff=918"/>
				<updated>2013-03-16T21:34:11Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: Created page with &amp;quot;The following text should be saved to a EWS64S mixer file like MIXER.TTM for use with 64SINIT   &amp;lt;nowiki&amp;gt; [EWS64S MIXER SETTING] VERSION=EWS64S CONTROL CENTER VERSION_NR=1.06 D...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following text should be saved to a EWS64S mixer file like MIXER.TTM for use with 64SINIT&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;nowiki&amp;gt;&lt;br /&gt;
[EWS64S MIXER SETTING]&lt;br /&gt;
VERSION=EWS64S CONTROL CENTER&lt;br /&gt;
VERSION_NR=1.06&lt;br /&gt;
DESCRIPTION=Amplify DOS Games (please DO NOT USE for Windows - really too loud!!!)&lt;br /&gt;
SAVE_FLAGS=1111111111111111111111111111111111111111111111111111111&lt;br /&gt;
&lt;br /&gt;
[MIXER_SETTINGS]&lt;br /&gt;
Clipping=1&lt;br /&gt;
MasterVol=128&lt;br /&gt;
MasterMute=0&lt;br /&gt;
MIDIRoute=MIDI1&lt;br /&gt;
SynINPUT=CoDec&lt;br /&gt;
ECHO_ON=0&lt;br /&gt;
EQ_CHANNELS=4&lt;br /&gt;
REV_ON=1&lt;br /&gt;
CHR_ON=1&lt;br /&gt;
SURR_ON=0&lt;br /&gt;
Wave_4CH=0&lt;br /&gt;
MOD_4CH=0&lt;br /&gt;
REC_ON=1&lt;br /&gt;
RECORD_ALL=0&lt;br /&gt;
SURR_4CH=0&lt;br /&gt;
SURR_MONO=1&lt;br /&gt;
REVERB_TYPE=4&lt;br /&gt;
CHORUS_TYPE=1&lt;br /&gt;
GM_POST_FX=0&lt;br /&gt;
WAVE_POST_FX=0&lt;br /&gt;
MOD_POST_FX=0&lt;br /&gt;
REC_POST_FX=1&lt;br /&gt;
FX_POST_FX=0&lt;br /&gt;
AUDIO_VOL=128&lt;br /&gt;
AUDIO_PAN_LR=64&lt;br /&gt;
AUDIO_PAN_FB=64&lt;br /&gt;
AUDIO_MUTE=0&lt;br /&gt;
AUDIO_REVERB_SEND=0&lt;br /&gt;
AUDIO_CHORUS_SEND=0&lt;br /&gt;
AUDIO_ECHO_Level=0&lt;br /&gt;
AUDIO_ECHO_TIME=0&lt;br /&gt;
AUDIO_ECHO_FeedBack=0&lt;br /&gt;
REC_LVOL=128&lt;br /&gt;
REC_RVOL=128&lt;br /&gt;
SURR_DELAY=50&lt;br /&gt;
SURR_VOL=127&lt;br /&gt;
MIDI_VOL=100&lt;br /&gt;
MIDI_PAN_LR=64&lt;br /&gt;
MIDI_PAN_FB=0&lt;br /&gt;
MIDI_REVERB_SEND=63&lt;br /&gt;
MIDI_CHORUS_SEND=63&lt;br /&gt;
REVERB_VOL=127&lt;br /&gt;
REV_TIME=64&lt;br /&gt;
REV_FBACK=44&lt;br /&gt;
CHORUS_VOL=127&lt;br /&gt;
CHR_DELAY=63&lt;br /&gt;
CHR_FBACK=9&lt;br /&gt;
CHR_RATE=3&lt;br /&gt;
CHR_DEPTH=19&lt;br /&gt;
WAVE_VOL=128&lt;br /&gt;
WAVE_PAN_LR=64&lt;br /&gt;
WAVE_PAN_FB=64&lt;br /&gt;
WAVE_MUTE=0&lt;br /&gt;
WAVE_PITCH=65536&lt;br /&gt;
WAVE_REVERB=0&lt;br /&gt;
WAVE_CHORUS=0&lt;br /&gt;
MOD_REVERB=0&lt;br /&gt;
MOD_CHORUS=0&lt;br /&gt;
EqVol1L=127&lt;br /&gt;
EqVol1R=127&lt;br /&gt;
EqVol2L=127&lt;br /&gt;
EqVol2R=127&lt;br /&gt;
EqVol3L=127&lt;br /&gt;
EqVol3R=127&lt;br /&gt;
EqVol4L=127&lt;br /&gt;
EqVol4R=127&lt;br /&gt;
EqFreq1=1&lt;br /&gt;
EqFreq2=20&lt;br /&gt;
EqFreq3=88&lt;br /&gt;
EqFreq4=127&lt;br /&gt;
vWave_0_Vol=128&lt;br /&gt;
vWave_0_PanLR=64&lt;br /&gt;
vWave_0_PanFB=64&lt;br /&gt;
vWave_0_Mute=0&lt;br /&gt;
vWave_0_Reverb=0&lt;br /&gt;
vWave_0_Chorus=0&lt;br /&gt;
vWave_0_Pitch=65536&lt;br /&gt;
vWave_1_Vol=128&lt;br /&gt;
vWave_1_PanLR=64&lt;br /&gt;
vWave_1_PanFB=64&lt;br /&gt;
vWave_1_Mute=0&lt;br /&gt;
vWave_1_Reverb=0&lt;br /&gt;
vWave_1_Chorus=0&lt;br /&gt;
vWave_1_Pitch=65536&lt;br /&gt;
cWAV_LVol=64512&lt;br /&gt;
cWAV_RVol=64512&lt;br /&gt;
cWAV_Mute=0&lt;br /&gt;
cIn1_LVol=0&lt;br /&gt;
cIn1_RVol=0&lt;br /&gt;
cIn1_MUTE=1&lt;br /&gt;
cDIG_LVol=0&lt;br /&gt;
cDIG_RVol=0&lt;br /&gt;
cDIG_MUTE=0&lt;br /&gt;
cMIC_Vol=0&lt;br /&gt;
cMIC_MUTE=1&lt;br /&gt;
cCD_LVol=49151&lt;br /&gt;
cCD_RVol=49151&lt;br /&gt;
cCD_MUTE=0&lt;br /&gt;
FM_LVol=65535&lt;br /&gt;
FM_RVol=65535&lt;br /&gt;
FM_MUTE=0&lt;br /&gt;
cREC_lGain=0&lt;br /&gt;
cREC_rGain=0&lt;br /&gt;
cREC_Input=5&lt;br /&gt;
cMIC_Boost=0&lt;br /&gt;
cMIC_AGC=0&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=EWS64&amp;diff=917</id>
		<title>EWS64</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=EWS64&amp;diff=917"/>
				<updated>2013-03-16T21:25:50Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The EWS64 is a line of semi-professional ISA soundcards released by [[Terratec]] in 1997. They consist of a codec and the Dream SAM9407 synthesizer chip and are thus basically two soundcards on one PCB.&lt;br /&gt;
&lt;br /&gt;
There are two different versions of the actual card: the EWS64L/XL/XXL and the EWS64S. The former are basically variants built around the same card and only differ in the type of the front panel delivered with the card (L: no front panel, XL: basic front panel, XXL: front panel with integrated MicrowaveXT synthesizer).&lt;br /&gt;
&lt;br /&gt;
The latter EWS64S has a different, more simple card design and comes with a different codec chip. Both cards are PnP-compatible and can be configured by software.&lt;br /&gt;
&lt;br /&gt;
== EWS64L/XL/XXL ==&lt;br /&gt;
&lt;br /&gt;
[[File:EWS64XL.JPG|thumb|400px| ''EWS64 XL'']]&lt;br /&gt;
=== Hardware description ===&lt;br /&gt;
The codec is a CS4236B made by Crystal Semiconductors, featuring SBPro, OPL3 and Windows Sound System compatibility. The card's IN-1 and the CD/MIDI-DB analog-in is wired to the codec. The synthesizer is a Dream SAM9407 which has access to the on-board memory (2MB) and PS/2 SIMM module (max. 64MB). Version 1.0 of the EWS64 also had an on-board ROM, which was removed for the 1.2 revision of the card. The IN-2 connector can also be wired to the SAM9407.&lt;br /&gt;
&lt;br /&gt;
The card has two analog outputs: OUT-2 is permanently connected to the SAM9407. OUT-1, however, can either output the analog signal from the codec or the output from the SAM9407. In the former case, the synthesizers' signal is routed into the codec. In the latter case, the signal of the codec can be sent to the SAM9407 instead of the IN-2 signal.&lt;br /&gt;
&lt;br /&gt;
The Dream chip also features an effects processor which can apply different (predefined) reverb, chorus and echo effects to the SAM9407 input signals. If the codec sound is routed through the synthesizer, these effects also can be applied to this signal. The SAM9407 also provides a four-band equalizer and pseudo-3D (Vspace) effects. The SAM9407 has a 34 voice polyphony with all features enabled that increases if unused features get disabled (up to 64).&lt;br /&gt;
&lt;br /&gt;
Using OUT-1 and OUT-2, the EWS64 also provides basic DirectSound3D compatibility, however, in 4-channel mode, the effects are unavailable. The EWS64 also has two independent MIDI ports (UART only). MIDI-1 is always connected to the SAM9407 chip, while MIDI-2 is connected to the daughterboard header in the front panel, or, if no daughterboard is connected, to the Gameport on the back of the card. Both MIDI ports can also be used simultaneously by the 5-pin DIN connectors in the front panel.&lt;br /&gt;
&lt;br /&gt;
=== Operating system support ===&lt;br /&gt;
The EWS64 is supported by the following operating systems: DOS, Windows 9x, Windows NT4, Windows 2000, Linux (via 3rd-party driver). OSs which have support for the CS4236 can drive the codec part only. The DOS and Windows drivers and tools can be downloaded from the Terratec FTP server.&lt;br /&gt;
&lt;br /&gt;
Only the 1.2 revision can be used with Windows 2000 or XP.&lt;br /&gt;
&lt;br /&gt;
==== DOS support ====&lt;br /&gt;
The EWS64 comes with a few DOS utilities: &lt;br /&gt;
&lt;br /&gt;
* EWS64CFG.EXE: Is used to configure the IO/IRQ/DMA resources used by the card. The codec can also be disabled with this tool. EWS64CFG '''must''' be run under plain DOS (i.e. Not in a Win9x DOS box). This tool writes a default configuration to the internal EEPROM that is used for ISA-PnP initialization of the card. After changing resource settings the computer has to be cold booted (i.e. by pressing Reset).&lt;br /&gt;
&lt;br /&gt;
* EWSINIT.EXE: This must be called on each boot as it initializes the codec and the SAM9407 according to the EEPROM settings. It loads the SAM9407s firmware and can load a single .94B sound set into the on-board RAM. It also sets up the mixer, card routing and effects using a .TTM file.&lt;br /&gt;
&lt;br /&gt;
* FMON.EXE: Enables output from the codecs FM-Synth. The codecs FM-Synth uses the same mixer volume setting as the Dream SAM9407 wavetable in a typical routing configuration of the card for DOS games.&lt;br /&gt;
&lt;br /&gt;
As the EWS64 has no dedicated DOS mixer application, all mixer settings are read from a configuration file (extension .TTM). The easiest way to create these mixer files is to use the Windows EWS64-Mixer to adjust the volumes as desired and then save the settings to a .TTM file. This file, in turn, can be passed to the DOS initialization tool.&lt;br /&gt;
&lt;br /&gt;
Due to a (hardware?) bug, the codec tends to mute several of its input channels (such as the wavetable daughterboard / CD-in) when the SBPro part is used. In 2009 user Locutus from Vogons forum [http://vogons.zetafleet.com/viewtopic.php?p=156857&amp;amp;highlight=#156857 reported a solution]. The bug can be overcome by doing a „post-initialization“ of the codec with the DOS mixer application from the original Crystal CX423X drivers. This program is usually called CS32MIX or CWDMIX, depending on the driver version and can also be used as DOS mixer application.&lt;br /&gt;
&lt;br /&gt;
A typical default initialisation looks like this:&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\EWSINIT -F -V -B SOUNDSET.94B -M MIXER.TTM&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\FMON&lt;br /&gt;
&lt;br /&gt;
SET BLASTER=A220 I5 D1 T4&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\CS32MIX /M=15,15 /W=13,13 /L=0,0 /X=1 /F=7,7 /C=11,11 /I=L&lt;br /&gt;
&lt;br /&gt;
where W denotes the digital part of the codec as SBPro and WSS, L is Line-In, F is FM-Synth and SAM9407 wavetable, C is the volume of the front module wavetable and I chooses the input. The BLASTER= settings should of course correspond to the resources set by EWSINIT that are shown with the -V switch.&lt;br /&gt;
&lt;br /&gt;
[[example .TTM file for EWS64L/XL/XXL]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Windows 9x support ====&lt;br /&gt;
The EWS64 Windows driver comes with several tools in order to control the EWS64:&lt;br /&gt;
&lt;br /&gt;
* The EWS Control Panel controls the volume settings of the codec and the SAM9407 as well as the audio signal routing on the card.&lt;br /&gt;
&lt;br /&gt;
* The FX panel is used for adjusting the effects processor. Echo, Equalizer, Reverb and Chorus settings can be changed here.&lt;br /&gt;
&lt;br /&gt;
* The „Virtual Channels“ tool is used to control the individual hardware mixing channels. See&lt;br /&gt;
&lt;br /&gt;
„Hardware Mixing“ section below.&lt;br /&gt;
&lt;br /&gt;
* The Set Manager loads and removes sound sets to and from the cards' RAM.&lt;br /&gt;
&lt;br /&gt;
There is also the 3rd-party application „EWS ProMix“ which combines the first three programs to one convenient application.&lt;br /&gt;
&lt;br /&gt;
==== Control panel settings ====&lt;br /&gt;
&lt;br /&gt;
[[File:EWScontrol.png|frameless|600px|EWS64XL Control Panel layout]]&lt;br /&gt;
&lt;br /&gt;
The Control panel has several sections which control either volume levels or specific routing settings. Section A has all the volume sliders for the CS4236 codec. If the codec is disabled, these sliders do nothing. The slider SYN adjusts the volume of the SAM9407 if its output is routed into the codec. This is done when the switch D is set to „A“. When set to „B“, the synthesizer is directly connected to OUT-1 (section B left). The remaining input channel IN-2 of the SAM9407 can be switched with switch „C“ between the IN-2 connector on the cards' bracket (setting A), the digital input of the front panel (setting D) or the output signal from the codec mixer (setting M). The OUT-2 is always connected to the SAM9407.&lt;br /&gt;
&lt;br /&gt;
The MIDI routing switch E controls which of the two MIDI ports of the card is connected to the game port on the back plate. The corresponding MIDI connectors in the front panel are disabled if the routing is active.&lt;br /&gt;
&lt;br /&gt;
==== Hardware Mixing ====&lt;br /&gt;
As the SAM9407 also supports hardware mixing, the Windows driver allows for the use of 16 independent wave output devices which represent 2x16 channels of the synthesizer chip. The number of these virtual channels can be adjusted under Control Panel/System/Device Manager/Terratec Devices/EWS Synthesizer. Each of those channels has its own volume and effects control slider, accessible via the „Virtual Channels“ application. If the Reverb/Chorus sliders are set to zero, no effects are applied to the selected virtual channel, regardless of the settings in the FX panel.&lt;br /&gt;
&lt;br /&gt;
==== Windows NT4 and 2000 support ====&lt;br /&gt;
TBD&lt;br /&gt;
&lt;br /&gt;
==== Linux support ====&lt;br /&gt;
&amp;lt;nowiki&amp;gt;Although Terratec does not offer a driver for it, the EWS64 can be used under Linux as well. The codec is supported by the appropriate ALSA or OSS driver for Crystal CX423X chips. The Dream chip, however, needs a third-party driver from Gerd Rausch (see links below). Unfortunately, this driver has now been unmaintained for years and has several problems:&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Only kernels up to and including 2.4.x are supported.&lt;br /&gt;
&lt;br /&gt;
* The control panel looks sort of „clumsy“ and requires profound knowledge of the inner working of the EWS64.&lt;br /&gt;
&lt;br /&gt;
* Only EWS64L/XL hardware version 1.2 is supported.&lt;br /&gt;
&lt;br /&gt;
The driver requires the firmware EWS64OS.BIN and a .94B sound bank in order to work. As it is a generic driver for all SAM9407-based cards, some of the elements in the control panel are non-functional or disabled.&lt;br /&gt;
&lt;br /&gt;
When installed and configured successfully, the SAM9407 can be used as an audio output device via /dev/sam0_dsp and as a MIDI playback device via /dev/sam0_sequencer or (via MikMod) as a MOD player.&lt;br /&gt;
&lt;br /&gt;
== EWS64S ==&lt;br /&gt;
=== Hardware description ===&lt;br /&gt;
[[File:EWS64S.JPG|thumb|400px| ''EWS64 S'']]&lt;br /&gt;
&lt;br /&gt;
Despite the name and the use of the same synthesizer chip, the EWS64S is a completely different piece of hardware when compared with the L/XL/XXL counterpart. The main differences are the codec chip and the internal routing possibilities. The codec is an Analog Devices AD1816 which provides SBPro and OPL3 compatibility. It is, however, not WSS-compatible. The AD codec is wired permanently to the SAM9407 and can not be routed directly to the OUT-1. In addition, the codec cannot be disabled as on the L/XL/XXL variants.&lt;br /&gt;
The XL/XXL front panel is incompatible with the 64S. In order to get digital outputs, a small slot-mountable PCB called &amp;quot;DigitalXtension R&amp;quot; is needed. The EWS64S has no waveblaster header but a connector for Terratecs ActiveRadio extension.&lt;br /&gt;
&lt;br /&gt;
=== OS support ===&lt;br /&gt;
The 64S needs a different set of drivers and applications from Terratec, the L/XL/XXL drivers do not work. Moreover, there are no NT4 or Windows 2000 drivers available for this card. The card is supported under Linux with Gerd Rauschs generic SAM9407 driver.&lt;br /&gt;
&lt;br /&gt;
=== DOS ===&lt;br /&gt;
* 64SCFG.EXE: This tool allows to change the resource configuration of the card. Changes are saved to the EEPROM on exit. This tool should be used once upon first installation in a new system and must be run in plain DOS. If resources were changed a cold boot is required. Recommended settings for DOS are&lt;br /&gt;
WSS I/O 530, WSS IRQ 5, WSS Play DMA 1, WSS Record DMA ---, FM I/O 388, SB Pro I/O 220, GAME I/O 200, MIDI-1 I/O 330, MIDI-1 IRQ ---, MIDI-2 I/O PnP, MIDI-2 IRQ ---, Dig. Control I/O PnP&lt;br /&gt;
&lt;br /&gt;
The WSS IRQ and DMA setting is also used for SB Pro.&lt;br /&gt;
&lt;br /&gt;
For DOS initialisation 64SINIT is called. So a typical startup look like this:&lt;br /&gt;
&lt;br /&gt;
C:\EWS64S\64SINIT -V -F -B SOUNDSET.94B -M MIXER.TTM&lt;br /&gt;
&lt;br /&gt;
SET BLASTER=A220 I5 D1 P330 T4&lt;br /&gt;
&lt;br /&gt;
The BLASTER= settings should of course correspond to the resources set by 64SINIT that are shown with the -V switch.&lt;br /&gt;
A .TTM file is used for mixer settings and SAM9407 configuration.&lt;br /&gt;
&lt;br /&gt;
[[example .TTM file for EWS64S]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
* [ftp://ftp.terratec.de/Audio/EWS/64XL Terratec FTP archive]&lt;br /&gt;
* [http://www.studio4all.de/htmle/welcomeewst.html Site dedicated to the EWS64]&lt;br /&gt;
* [http://sam9407.sourceforge.net Linux SAM9407 driver]&lt;br /&gt;
&lt;br /&gt;
[[Category:Hardware]]&lt;br /&gt;
[[Category:Sound Cards]]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=EWS64&amp;diff=916</id>
		<title>EWS64</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=EWS64&amp;diff=916"/>
				<updated>2013-03-16T20:44:23Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Hardware description */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The EWS64 is a line of semi-professional ISA soundcards released by [[Terratec]] in 1997. They consist of a codec and the Dream SAM9407 synthesizer chip and are thus basically two soundcards on one PCB.&lt;br /&gt;
&lt;br /&gt;
There are two different versions of the actual card: the EWS64L/XL/XXL and the EWS64S. The former are basically variants built around the same card and only differ in the type of the front panel delivered with the card (L: no front panel, XL: basic front panel, XXL: front panel with integrated MicrowaveXT synthesizer).&lt;br /&gt;
&lt;br /&gt;
The latter EWS64S has a different, more simple card design and comes with a different codec chip. Both cards are PnP-compatible and can be configured by software.&lt;br /&gt;
&lt;br /&gt;
== EWS64L/XL/XXL ==&lt;br /&gt;
&lt;br /&gt;
[[File:EWS64XL.JPG|thumb|400px| ''EWS64 XL'']]&lt;br /&gt;
=== Hardware description ===&lt;br /&gt;
The codec is a CS4236B made by Crystal Semiconductors, featuring SBPro, OPL3 and Windows Sound System compatibility. The card's IN-1 and the CD/MIDI-DB analog-in is wired to the codec. The synthesizer is a Dream SAM9407 which has access to the on-board memory (2MB) and PS/2 SIMM module (max. 64MB). Version 1.0 of the EWS64 also had an on-board ROM, which was removed for the 1.2 revision of the card. The IN-2 connector can also be wired to the SAM9407.&lt;br /&gt;
&lt;br /&gt;
The card has two analog outputs: OUT-2 is permanently connected to the SAM9407. OUT-1, however, can either output the analog signal from the codec or the output from the SAM9407. In the former case, the synthesizers' signal is routed into the codec. In the latter case, the signal of the codec can be sent to the SAM9407 instead of the IN-2 signal.&lt;br /&gt;
&lt;br /&gt;
The Dream chip also features an effects processor which can apply different (predefined) reverb, chorus and echo effects to the SAM9407 input signals. If the codec sound is routed through the synthesizer, these effects also can be applied to this signal. The SAM9407 also provides a four-band equalizer and pseudo-3D (Vspace) effects. The SAM9407 has a 34 voice polyphony with all features enabled that increases if unused features get disabled (up to 64).&lt;br /&gt;
&lt;br /&gt;
Using OUT-1 and OUT-2, the EWS64 also provides basic DirectSound3D compatibility, however, in 4-channel mode, the effects are unavailable. The EWS64 also has two independent MIDI ports (UART only). MIDI-1 is always connected to the SAM9407 chip, while MIDI-2 is connected to the daughterboard header in the front panel, or, if no daughterboard is connected, to the Gameport on the back of the card. Both MIDI ports can also be used simultaneously by the 5-pin DIN connectors in the front panel.&lt;br /&gt;
&lt;br /&gt;
=== Operating system support ===&lt;br /&gt;
The EWS64 is supported by the following operating systems: DOS, Windows 9x, Windows NT4, Windows 2000, Linux (via 3rd-party driver). OSs which have support for the CS4236 can drive the codec part only. The DOS and Windows drivers and tools can be downloaded from the Terratec FTP server.&lt;br /&gt;
&lt;br /&gt;
Only the 1.2 revision can be used with Windows 2000 or XP.&lt;br /&gt;
&lt;br /&gt;
==== DOS support ====&lt;br /&gt;
The EWS64 comes with a few DOS utilities: &lt;br /&gt;
&lt;br /&gt;
* EWS64CFG.EXE: Is used to configure the IO/IRQ/DMA resources used by the card. The codec can also be disabled with this tool. EWS64CFG '''must''' be run under plain DOS (i.e. Not in a Win9x DOS box). This tool writes a default configuration to the internal EEPROM that is used for ISA-PnP initialization of the card. After changing resource settings the computer has to be cold booted (i.e. by pressing Reset).&lt;br /&gt;
&lt;br /&gt;
* EWSINIT.EXE: This must be called on each boot as it initializes the codec and the SAM9407 according to the EEPROM settings. It loads the SAM9407s firmware and can load a single .94B sound set into the on-board RAM. It also sets up the mixer, card routing and effects using a .TTM file.&lt;br /&gt;
&lt;br /&gt;
* FMON.EXE: Enables output from the codecs FM-Synth. The codecs FM-Synth uses the same mixer volume setting as the Dream SAM9407 wavetable in a typical routing configuration of the card for DOS games.&lt;br /&gt;
&lt;br /&gt;
As the EWS64 has no dedicated DOS mixer application, all mixer settings are read from a configuration file (extension .TTM). The easiest way to create these mixer files is to use the Windows EWS64-Mixer to adjust the volumes as desired and then save the settings to a .TTM file. This file, in turn, can be passed to the DOS initialization tool.&lt;br /&gt;
&lt;br /&gt;
Due to a (hardware?) bug, the codec tends to mute several of its input channels (such as the wavetable daughterboard / CD-in) when the SBPro part is used. In 2009 user Locutus from Vogons forum [http://vogons.zetafleet.com/viewtopic.php?p=156857&amp;amp;highlight=#156857 reported a solution]. The bug can be overcome by doing a „post-initialization“ of the codec with the DOS mixer application from the original Crystal CX423X drivers. This program is usually called CS32MIX or CWDMIX, depending on the driver version and can also be used as DOS mixer application.&lt;br /&gt;
&lt;br /&gt;
A typical default initialisation looks like this:&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\EWSINIT -F -V -B SOUNDSET.94B -M MIXER.TTM&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\FMON&lt;br /&gt;
&lt;br /&gt;
SET BLASTER=A220 I5 D1 T4&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\CS32MIX /M=15,15 /W=13,13 /L=0,0 /X=1 /F=7,7 /C=11,11 /I=L&lt;br /&gt;
&lt;br /&gt;
where W denotes the digital part of the codec as SBPro and WSS, L is Line-In, F is FM-Synth and SAM9407 wavetable, C is the volume of the front module wavetable and I chooses the input. The BLASTER= settings should of course correspond to the resources set by EWSINIT that are shown with the -V switch.&lt;br /&gt;
&lt;br /&gt;
[[example .TTM file for EWS64L/XL/XXL]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Windows 9x support ====&lt;br /&gt;
The EWS64 Windows driver comes with several tools in order to control the EWS64:&lt;br /&gt;
&lt;br /&gt;
* The EWS Control Panel controls the volume settings of the codec and the SAM9407 as well as the audio signal routing on the card.&lt;br /&gt;
&lt;br /&gt;
* The FX panel is used for adjusting the effects processor. Echo, Equalizer, Reverb and Chorus settings can be changed here.&lt;br /&gt;
&lt;br /&gt;
* The „Virtual Channels“ tool is used to control the individual hardware mixing channels. See&lt;br /&gt;
&lt;br /&gt;
„Hardware Mixing“ section below.&lt;br /&gt;
&lt;br /&gt;
* The Set Manager loads and removes sound sets to and from the cards' RAM.&lt;br /&gt;
&lt;br /&gt;
There is also the 3rd-party application „EWS ProMix“ which combines the first three programs to one convenient application.&lt;br /&gt;
&lt;br /&gt;
==== Control panel settings ====&lt;br /&gt;
&lt;br /&gt;
[[File:EWScontrol.png|frameless|600px|EWS64XL Control Panel layout]]&lt;br /&gt;
&lt;br /&gt;
The Control panel has several sections which control either volume levels or specific routing settings. Section A has all the volume sliders for the CS4236 codec. If the codec is disabled, these sliders do nothing. The slider SYN adjusts the volume of the SAM9407 if its output is routed into the codec. This is done when the switch D is set to „A“. When set to „B“, the synthesizer is directly connected to OUT-1 (section B left). The remaining input channel IN-2 of the SAM9407 can be switched with switch „C“ between the IN-2 connector on the cards' bracket (setting A), the digital input of the front panel (setting D) or the output signal from the codec mixer (setting M). The OUT-2 is always connected to the SAM9407.&lt;br /&gt;
&lt;br /&gt;
The MIDI routing switch E controls which of the two MIDI ports of the card is connected to the game port on the back plate. The corresponding MIDI connectors in the front panel are disabled if the routing is active.&lt;br /&gt;
&lt;br /&gt;
==== Hardware Mixing ====&lt;br /&gt;
As the SAM9407 also supports hardware mixing, the Windows driver allows for the use of 16 independent wave output devices which represent 2x16 channels of the synthesizer chip. The number of these virtual channels can be adjusted under Control Panel/System/Device Manager/Terratec Devices/EWS Synthesizer. Each of those channels has its own volume and effects control slider, accessible via the „Virtual Channels“ application. If the Reverb/Chorus sliders are set to zero, no effects are applied to the selected virtual channel, regardless of the settings in the FX panel.&lt;br /&gt;
&lt;br /&gt;
==== Windows NT4 and 2000 support ====&lt;br /&gt;
TBD&lt;br /&gt;
&lt;br /&gt;
==== Linux support ====&lt;br /&gt;
&amp;lt;nowiki&amp;gt;Although Terratec does not offer a driver for it, the EWS64 can be used under Linux as well. The codec is supported by the appropriate ALSA or OSS driver for Crystal CX423X chips. The Dream chip, however, needs a third-party driver from Gerd Rausch (see links below). Unfortunately, this driver has now been unmaintained for years and has several problems:&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Only kernels up to and including 2.4.x are supported.&lt;br /&gt;
&lt;br /&gt;
* The control panel looks sort of „clumsy“ and requires profound knowledge of the inner working of the EWS64.&lt;br /&gt;
&lt;br /&gt;
* Only EWS64L/XL hardware version 1.2 is supported.&lt;br /&gt;
&lt;br /&gt;
The driver requires the firmware EWS64OS.BIN and a .94B sound bank in order to work. As it is a generic driver for all SAM9407-based cards, some of the elements in the control panel are non-functional or disabled.&lt;br /&gt;
&lt;br /&gt;
When installed and configured successfully, the SAM9407 can be used as an audio output device via /dev/sam0_dsp and as a MIDI playback device via /dev/sam0_sequencer or (via MikMod) as a MOD player.&lt;br /&gt;
&lt;br /&gt;
== EWS64S ==&lt;br /&gt;
=== Hardware description ===&lt;br /&gt;
[[File:EWS64S.JPG|thumb|400px| ''EWS64 S'']]&lt;br /&gt;
&lt;br /&gt;
Despite the name and the use of the same synthesizer chip, the EWS64S is a completely different piece of hardware when compared with the L/XL/XXL counterpart. The main differences are the codec chip and the internal routing possibilities. The codec is an Analog Devices AD1816 which provides SBPro and OPL3 compatibility. It is, however, not WSS-compatible. The AD codec is wired permanently to the SAM9407 and can not be routed directly to the OUT-1. In addition, the codec cannot be disabled as on the L/XL/XXL variants.&lt;br /&gt;
The XL/XXL front panel is incompatible with the 64S. In order to get digital outputs, a small slot-mountable PCB called &amp;quot;DigitalXtension R&amp;quot; is needed. The EWS64S has no waveblaster header but a connector for Terratecs ActiveRadio extension.&lt;br /&gt;
&lt;br /&gt;
=== OS support ===&lt;br /&gt;
The 64S needs a different set of drivers and applications from Terratec, the L/XL/XXL drivers do not work. Moreover, there are no NT4 or Windows 2000 drivers available for this card. The card is supported under Linux with Gerd Rauschs generic SAM9407 driver.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
* [ftp://ftp.terratec.de/Audio/EWS/64XL Terratec FTP archive]&lt;br /&gt;
* [http://www.studio4all.de/htmle/welcomeewst.html Site dedicated to the EWS64]&lt;br /&gt;
* [http://sam9407.sourceforge.net Linux SAM9407 driver]&lt;br /&gt;
&lt;br /&gt;
[[Category:Hardware]]&lt;br /&gt;
[[Category:Sound Cards]]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	<entry>
		<id>https://www.vogonswiki.com/index.php?title=EWS64&amp;diff=915</id>
		<title>EWS64</title>
		<link rel="alternate" type="text/html" href="https://www.vogonswiki.com/index.php?title=EWS64&amp;diff=915"/>
				<updated>2013-03-16T20:35:39Z</updated>
		
		<summary type="html">&lt;p&gt;Enigma: /* Hardware description */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The EWS64 is a line of semi-professional ISA soundcards released by [[Terratec]] in 1997. They consist of a codec and the Dream SAM9407 synthesizer chip and are thus basically two soundcards on one PCB.&lt;br /&gt;
&lt;br /&gt;
There are two different versions of the actual card: the EWS64L/XL/XXL and the EWS64S. The former are basically variants built around the same card and only differ in the type of the front panel delivered with the card (L: no front panel, XL: basic front panel, XXL: front panel with integrated MicrowaveXT synthesizer).&lt;br /&gt;
&lt;br /&gt;
The latter EWS64S has a different, more simple card design and comes with a different codec chip. Both cards are PnP-compatible and can be configured by software.&lt;br /&gt;
&lt;br /&gt;
== EWS64L/XL/XXL ==&lt;br /&gt;
&lt;br /&gt;
[[File:EWS64XL.JPG|thumb|400px| ''EWS64 XL'']]&lt;br /&gt;
=== Hardware description ===&lt;br /&gt;
The codec is a CS4236B made by Crystal Semiconductors, featuring SBPro, OPL3 and Windows Sound System compatibility. The card's IN-1 and the CD/MIDI-DB analog-in is wired to the codec. The synthesizer is a Dream SAM9407 which has access to the onboard memory (2MB) and PS/2 SIMM module. Version 1.0 of the EWS64 also had an onboard ROM, which was removed for the 1.2 revision of the card. The IN-2 connector can also be wired to the SAM9407.&lt;br /&gt;
&lt;br /&gt;
The card has two analog outputs: OUT-2 is permamently connected to the SAM9407. OUT-1, however, can either output the analog signal from the codec or the output from the SAM9407. In the former case, the synthesizers' signal is routed into the codec. In the latter case, the signal of the codec can be sent to the SAM9407 instead of the IN-2 signal.&lt;br /&gt;
&lt;br /&gt;
The Dream chip also features an effects processor which can apply different (predefined) reverb and chorus effects to the SAM9407 input signals. If the codec sound is routed through the synthesizer, these effects also can be applied to this signal. The SAM9407 also provides a four-band equalizer, echo and pseudo-3D (Vspace) effects.&lt;br /&gt;
&lt;br /&gt;
Using OUT-1 and OUT-2, the EWS64 also provides basic DirectSound3D compatibility, however, in 4-channel mode, the effects are unavailable. The EWS64 also has two independent MIDI ports (UART only). MIDI-1 is always connected to the SAM9407 chip, while MIDI-2 is connected to the daughterboard header in the front panel, or, if no daughterboard is connected, to the Gameport on the back of the card. Both MIDI ports can also be used by the 5-pin DIN connectors in the front panel.&lt;br /&gt;
&lt;br /&gt;
=== Operating system support ===&lt;br /&gt;
The EWS64 is supported by the following operating systems: DOS, Windows 9x, Windows NT4, Windows 2000, Linux (via 3rd-party driver). OSs which have support for the CS4236 can drive the codec part only. The DOS and Windows drivers and tools can be downloaded from the Terratec FTP server.&lt;br /&gt;
&lt;br /&gt;
Only the 1.2 revision can be used with Windows 2000 or XP.&lt;br /&gt;
&lt;br /&gt;
==== DOS support ====&lt;br /&gt;
The EWS64 comes with a few DOS utilities: &lt;br /&gt;
&lt;br /&gt;
* EWS64CFG.EXE: Is used to configure the IO/IRQ/DMA resources used by the card. The codec can also be disabled with this tool. EWS64CFG '''must''' be run under plain DOS (i.e. Not in a Win9x DOS box). This tool writes a default configuration to the internal EEPROM that is used for ISA-PnP initialization of the card. After changing resource settings the computer has to be cold booted (i.e. by pressing Reset).&lt;br /&gt;
&lt;br /&gt;
* EWSINIT.EXE: This must be called on each boot as it initializes the codec and the SAM9407 according to the EEPROM settings. It loads the SAM9407s firmware and can load a single .94B sound set into the on-board RAM. It also sets up the mixer, card routing and effects using a .TTM file.&lt;br /&gt;
&lt;br /&gt;
* FMON.EXE: Enables output from the codecs FM-Synth. The codecs FM-Synth uses the same mixer volume setting as the Dream SAM9407 wavetable in a typical routing configuration of the card for DOS games.&lt;br /&gt;
&lt;br /&gt;
As the EWS64 has no dedicated DOS mixer application, all mixer settings are read from a configuration file (extension .TTM). The easiest way to create these mixer files is to use the Windows EWS64-Mixer to adjust the volumes as desired and then save the settings to a .TTM file. This file, in turn, can be passed to the DOS initialization tool.&lt;br /&gt;
&lt;br /&gt;
Due to a (hardware?) bug, the codec tends to mute several of its input channels (such as the wavetable daughterboard / CD-in) when the SBPro part is used. In 2009 user Locutus from Vogons forum [http://vogons.zetafleet.com/viewtopic.php?p=156857&amp;amp;highlight=#156857 reported a solution]. The bug can be overcome by doing a „post-initialization“ of the codec with the DOS mixer application from the original Crystal CX423X drivers. This program is usually called CS32MIX or CWDMIX, depending on the driver version and can also be used as DOS mixer application.&lt;br /&gt;
&lt;br /&gt;
A typical default initialisation looks like this:&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\EWSINIT -F -V -B SOUNDSET.94B -M MIXER.TTM&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\FMON&lt;br /&gt;
&lt;br /&gt;
SET BLASTER=A220 I5 D1 T4&lt;br /&gt;
&lt;br /&gt;
C:\EWS64\CS32MIX /M=15,15 /W=13,13 /L=0,0 /X=1 /F=7,7 /C=11,11 /I=L&lt;br /&gt;
&lt;br /&gt;
where W denotes the digital part of the codec as SBPro and WSS, L is Line-In, F is FM-Synth and SAM9407 wavetable, C is the volume of the front module wavetable and I chooses the input. The BLASTER= settings should of course correspond to the resources set by EWSINIT that are shown with the -V switch.&lt;br /&gt;
&lt;br /&gt;
[[example .TTM file for EWS64L/XL/XXL]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Windows 9x support ====&lt;br /&gt;
The EWS64 Windows driver comes with several tools in order to control the EWS64:&lt;br /&gt;
&lt;br /&gt;
* The EWS Control Panel controls the volume settings of the codec and the SAM9407 as well as the audio signal routing on the card.&lt;br /&gt;
&lt;br /&gt;
* The FX panel is used for adjusting the effects processor. Echo, Equalizer, Reverb and Chorus settings can be changed here.&lt;br /&gt;
&lt;br /&gt;
* The „Virtual Channels“ tool is used to control the individual hardware mixing channels. See&lt;br /&gt;
&lt;br /&gt;
„Hardware Mixing“ section below.&lt;br /&gt;
&lt;br /&gt;
* The Set Manager loads and removes sound sets to and from the cards' RAM.&lt;br /&gt;
&lt;br /&gt;
There is also the 3rd-party application „EWS ProMix“ which combines the first three programs to one convenient application.&lt;br /&gt;
&lt;br /&gt;
==== Control panel settings ====&lt;br /&gt;
&lt;br /&gt;
[[File:EWScontrol.png|frameless|600px|EWS64XL Control Panel layout]]&lt;br /&gt;
&lt;br /&gt;
The Control panel has several sections which control either volume levels or specific routing settings. Section A has all the volume sliders for the CS4236 codec. If the codec is disabled, these sliders do nothing. The slider SYN adjusts the volume of the SAM9407 if its output is routed into the codec. This is done when the switch D is set to „A“. When set to „B“, the synthesizer is directly connected to OUT-1 (section B left). The remaining input channel IN-2 of the SAM9407 can be switched with switch „C“ between the IN-2 connector on the cards' bracket (setting A), the digital input of the front panel (setting D) or the output signal from the codec mixer (setting M). The OUT-2 is always connected to the SAM9407.&lt;br /&gt;
&lt;br /&gt;
The MIDI routing switch E controls which of the two MIDI ports of the card is connected to the game port on the back plate. The corresponding MIDI connectors in the front panel are disabled if the routing is active.&lt;br /&gt;
&lt;br /&gt;
==== Hardware Mixing ====&lt;br /&gt;
As the SAM9407 also supports hardware mixing, the Windows driver allows for the use of 16 independent wave output devices which represent 2x16 channels of the synthesizer chip. The number of these virtual channels can be adjusted under Control Panel/System/Device Manager/Terratec Devices/EWS Synthesizer. Each of those channels has its own volume and effects control slider, accessible via the „Virtual Channels“ application. If the Reverb/Chorus sliders are set to zero, no effects are applied to the selected virtual channel, regardless of the settings in the FX panel.&lt;br /&gt;
&lt;br /&gt;
==== Windows NT4 and 2000 support ====&lt;br /&gt;
TBD&lt;br /&gt;
&lt;br /&gt;
==== Linux support ====&lt;br /&gt;
&amp;lt;nowiki&amp;gt;Although Terratec does not offer a driver for it, the EWS64 can be used under Linux as well. The codec is supported by the appropriate ALSA or OSS driver for Crystal CX423X chips. The Dream chip, however, needs a third-party driver from Gerd Rausch (see links below). Unfortunately, this driver has now been unmaintained for years and has several problems:&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Only kernels up to and including 2.4.x are supported.&lt;br /&gt;
&lt;br /&gt;
* The control panel looks sort of „clumsy“ and requires profound knowledge of the inner working of the EWS64.&lt;br /&gt;
&lt;br /&gt;
* Only EWS64L/XL hardware version 1.2 is supported.&lt;br /&gt;
&lt;br /&gt;
The driver requires the firmware EWS64OS.BIN and a .94B sound bank in order to work. As it is a generic driver for all SAM9407-based cards, some of the elements in the control panel are non-functional or disabled.&lt;br /&gt;
&lt;br /&gt;
When installed and configured successfully, the SAM9407 can be used as an audio output device via /dev/sam0_dsp and as a MIDI playback device via /dev/sam0_sequencer or (via MikMod) as a MOD player.&lt;br /&gt;
&lt;br /&gt;
== EWS64S ==&lt;br /&gt;
=== Hardware description ===&lt;br /&gt;
[[File:EWS64S.JPG|thumb|400px| ''EWS64 S'']]&lt;br /&gt;
&lt;br /&gt;
Despite the name and the use of the same synthesizer chip, the EWS64S is a completely different piece of hardware when compared with the L/XL/XXL counterpart. The main differences are the codec chip and the internal routing possibilities. The codec is an Analog Devices AD1816 which provides SBPro and OPL3 compatibility. It is, however, not WSS-compatible. The AD codec is wired permanently to the SAM9407 and can not be routed directly to the OUT-1. In addition, the codec cannot be disabled as on the L/XL/XXL variants.&lt;br /&gt;
The XL/XXL front panel is incompatible with the 64S. In order to get digital outputs, a small slot-mountable PCB called &amp;quot;DigitalXtension R&amp;quot; is needed. The EWS64S has no waveblaster header but a connector for Terratecs ActiveRadio extension.&lt;br /&gt;
&lt;br /&gt;
=== OS support ===&lt;br /&gt;
The 64S needs a different set of drivers and applications from Terratec, the L/XL/XXL drivers do not work. Moreover, there are no NT4 or Windows 2000 drivers available for this card. The card is supported under Linux with Gerd Rauschs generic SAM9407 driver.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
* [ftp://ftp.terratec.de/Audio/EWS/64XL Terratec FTP archive]&lt;br /&gt;
* [http://www.studio4all.de/htmle/welcomeewst.html Site dedicated to the EWS64]&lt;br /&gt;
* [http://sam9407.sourceforge.net Linux SAM9407 driver]&lt;br /&gt;
&lt;br /&gt;
[[Category:Hardware]]&lt;br /&gt;
[[Category:Sound Cards]]&lt;/div&gt;</summary>
		<author><name>Enigma</name></author>	</entry>

	</feed>