:gdoc sec='IBM Internal Use Only' .rc 2 | :body :h1.RAMADE - Enable use of RAM in segments A, D and E :xmp .rc 1 on .rc 2 on .sx c |Version 1.21 || Cornell Wright| .sx c |1/12/87 || WRIGHT at PKEDVM8| .rc 2 off .rc 1 off :exmp :p.:hp3.WARNING - WARNING - WARNING - WARNING - WARNING:ehp3. .rc 1 on :ol :li.RAMADE is a program which has the potential for conflicting with the ROM and RAM addresses of existing and unannounced adapter cards. :li.RAMADE has had only limited use and testing. Please read :hdref refid=prob. before using it. :li.Use it with care and at your own risk. :eol .rc 1 off :h2.Function :p This program enables the utilization of 192 k of RAM in addition to the 640 k normal maximum for a PC. The additional RAM must be installed at segment addresses A000, D000 and E000. The 64k of RAM in segment A is contiguous with the normal 640k and is used simply by extending the memory size above 640. The 128k in segments D and E is not contiguous with the rest of RAM. It is used for loading various resident extensions, thus freeing up RAM in the main area (0-704k). :p See RAMCHIP QUERY on IBMPC for a discussion of methods for installing additional memory. .rc 1 on :h2.Changes :dl tsize=22 .rc 2 on :dt.Ver 1.21 - 1/12/87 :dd.Added save restore of segment register around DOS call to invoke secondary command processor. This is to fix a problem under DOS 2.1. :p.Added code to modify the DOS memory allocation blocks so that DOS will "forget" about the memory above the contiguous area. This fixes the problem where Filecmd will not cancel because it thinks something is installed above it. :p.Added test for 0 length clear in address table. .rc 2 off :dt.Ver 1.10 - 11/05/85 :dd.Placed constants for storage addresses in a table in the module as an interim approach to configurability. This will facilitate patching the addresses. See :hdref refid=zap. for more information. :dt.Ver 1.00 - 11/03/85 :dd.First release. :edl .rc 1 off :h2.Description :p The memory size is set to the end of segment E by resetting the bios memory size and rebooting. Storage in segments A, D and E is tested and cleared. Miscompares are detected, but no attempt is made to handle the more common case of parity checks during the test. :p Resident extensions are loaded in segments D and E by a secondary command processor which is invoked by RAMADE. After issuing a SETBLOCK function call to free the 128 K bytes in segments D and E, RAMADE invokes the secondary command processor with a command of 'AUTOLOAD'. This should be a bat file which contains the commands to load the resident extensions. :p After loading the resident extensions, RAMADE issues other memory management function calls which leave segments B and C allocated and free up unused memory below segment B. :p In addition, the warm boot flag in low storage is reset. The system bios sets this flag when doing a ctl-alt-del reset, but never clears it, apparently relying on power dropping to clear the area. (I've recently installed 256k chips on my system board, and after this installation, sometimes my system was warm booting when it should have been cold booting after turning the power off briefly.) :h2.Use :ol :li.Install 832 k of RAM in your PC as described above. :li.Create AUTOLOAD.BAT. This should contain the commands to invoke the resident extensions you wish to load in segments D and E. (See sample below.) :li.Invoke RAMADE early in your AUTOEXEC.BAT. (See sample below.) :eol :h4.Sample AUTOEXEC.BAT: :xmp echo off cls verify on cd \sys path c:\cmd;c:\dos31; ramade >nul keyin >nul pcutil sw cl pcutil sw cl copy graphic.fx prn >nul xtime echo ÿ echo ÿ iplmsg prompt $e[H$e[0;34;43m$p$e[K$e[;56H$t$h$h$h $d$e[0m$e[25;H$e[33mÍÍ$e[36m ver cd \misc keyin [4] :exmp :h4.Sample AUTOLOAD.BAT: :xmp echo off cls fastk /s /f /p >nul *keyin >nul retrieve retrieve.pro >nul puff >nul spi 32 >nul print /d&gml.lpt1 >nul fspause off /tm&gml.on /tv&gml.5 >nul set ff=c:\global filefac /i /o /nc /nm >nul cls scrfix.exe pctermon.com >nul fc3 /q :exmp :h4.MEMMAP output from the above: :xmp Seg 07E6 M Size 04E4 Owner 0008 Seg 0CCB M Size 00C0 Owner 0CCB Seg 0D8C M Size 000A Owner 0CCB Seg 0D97 M Size 0004 Owner 0000 Seg 0D9C M Size 0005 Owner 0DA9 Seg 0DA2 M Size 0006 Owner 0DA2 Seg 0DA9 M Size 0158 Owner 0DA9 Seg 0F02 M Size 000A Owner 0F0D Seg 0F0D M Size A0F2 Owner 0F0D Seg B000 M Size 2000 Owner 0DA2 Seg D001 M Size 00CB Owner 0000 Seg D0CD M Size 0005 Owner D0D3 Seg D0D3 M Size 002F Owner D0D3 Seg D103 M Size 0005 Owner D109 Seg D109 M Size 026D Owner D109 Seg D377 M Size 0005 Owner D37D Seg D37D M Size 0561 Owner D37D Seg D8DF M Size 0005 Owner D8E5 Seg D8E5 M Size 0840 Owner D8E5 Seg E126 M Size 0005 Owner E26C Seg E12C M Size 013F Owner E12C Seg E26C M Size 0055 Owner E26C Seg E2C2 M Size 0006 Owner E2C9 Seg E2C9 M Size 005E Owner E2C9 Seg E328 M Size 0006 Owner E32F Seg E32F M Size 0011 Owner E32F Seg E341 M Size 0006 Owner E348 Seg E348 M Size 0042 Owner E348 Seg E38B M Size 0006 Owner E392 Seg E392 M Size 0850 Owner E392 Seg EBE3 Z Size 041D Owner 0000 :exmp :h2 id=prob.Cautions, Problems and Notes :p.This program is still somewhat experimental. It has had limited use and testing. Use it with caution, and let me know if you have any problems. :h4.Testing Environment :ul :li.PC/XT with 832k RAM :li.MicroScience 20 meg file and Western Digital controller :li.DOS 3.1 :li.DOS extensions as listed in the sample installation :eul :h4.Known Problems :ol :li.When KEYIN is installed in the discontiguous area and is later invoked from the lower area, I get a 'GENERAL FAILURE' on the C drive. This could be related to my particular controller. I now have KEYIN installed in the lower area. :li.Norton Utilities 'Unerase' function fails with 'Error 7'. It appears to update the FAT, but not the directory. I used DR to get out of trouble on this one. :li.MASM was failing with 'OUT OF MEMORY'. I applied a patch from PROGRAM PATCHES on IBMPC and everything is fine. :eol .rc 1 on :h2 id=zap.Patching RAMADE to use Different Addresses :p The RAMADE.COM module contains a table of segment addresses and lengths. The existing values in the table support the addresses described in the rest of this document. If your PC has a different adapter configuration which requires a different arrangement of RAM above 640 K, it may be possible to patch this table to configure RAMADE to your PC. :p RAMADE views RAM as consisting of a contiguous area which starts at 0 and a discontiguous area which starts above the end of the contiguous area (with some intervening gap). There are values in the table to identify these areas. RAMADE also tests and clears 3 areas of RAM. The starting addresses and lengths of these areas are also in the table. .rc 2 on If the length is set to 0000, clearing that area will be skipped. .rc 2 off :p .rc 2 on The table is at offset 3C8h in the com module. It is immediately proceeded by the ASCII string 'ADDR TAB'. The table contains 9 words: .rc 2 off :dl :dt.+00 :dd.End of the contiguous area. Paragraph address of the first byte after the contiguous area. Default is b000h. :dt.+02 :dd.Start of the discontiguous area. Paragraph address of the first byte of the discontiguous area. Default is d000h. :dt.+04 :dd.End of the discontiguous area. Paragraph address of the first byte after the discontiguous area. Default is f000h. :dt.+06 :dd.Start of the first area to test and clear. Paragraph address of the first byte of the area. Default is a000h. :dt.+08 :dd.Length of the first area to test and clear. Length in words. Default is 8000h. :dt.+0A :dd.Start of the second area to test and clear. Paragraph address of the first byte of the area. Default is d000h. :dt.+0C :dd.Length of the second area to test and clear. Length in words. Default is 8000h. :dt.+0E :dd.Start of the third area to test and clear. Paragraph address of the first byte of the area. Default is e000h. :dt.+10 :dd.Length of the third area to test and clear. Length in words. Default is 8000h. :edl :p Remember that words are stored last-byte-first. Thus b000 is stored as 00b0. Got that ? .rc 1 off :egdoc