!config.sys - is it the expanded memory manager? --- agk's diary 16 August 2026 --- written on HP Mini netbook (2011) and IBM Model F keyboard from a 5155 PC Portable (1984), with calvin 2.3 vi editor (1993) on SvarDOS from USB, as daughter falls asleep to a Cocteau Twins CD --- I'm writing this on my daughter's computer system. Some tinkerers from Ukraine, and Solderpunk, emailed to encourage me to continue documenting the sorrows and joys of my DOS-from-USB-flash exploration. In non-computer life, my daughter babysat a 3-year- old family friend for four days of daycare closures. On the fourth day, amid torrential rain, we all went to a flood-prone part of the wilderness, talked about floodwater dangers as we looked at the raging brown torrent. Then I tied a guideline, ford- ed the kids across, and we walked a couple miles in the deep, deep woods. On the drive home, daughter announced they started a union. After deliberation, their demands to management: No cutting trees and Elsa may not freeze hearts. Now, back to my occasional quest to make a live-USB distro for kids that's as good as Paul Blair's FUZOMA from Liam Proven's SvarDOS-based usb-dos. Done: 1. I resized this system's partition to 2GB, and made the other 1.7GB of this USB2.0 flash drive an empty FAT32 partition for backups. BIOS mounts both partitions at boot, with different drive letters. Backups work with COPY or Bud L. Rasmussen's BD (Backup Directory), from his BLRUT UTility suite. Current tasks: 1. Prevent the memory manager JEMM86 from occasion- ally reporting a general protection fault interrupt (vector number 0Dh [13]) and exiting, and irreparable corruption destroying the folder of the open program (and any open file). 2. Attempt to load the system to RAMDisk and discard all changes at shutdown, to protect the file- system on USB flash disk from damage by children and bugs. Both current tasks probably involve messing with config.sys. 1. What occassionally corrupts my disk? ------------------------------------ Ideas: a) Maybe JEMM86 isn't playing nice with my BIOS, trying to write to protected [RAM] memory it misidentified or something? Test ideas: - Try another memory manager, - Try running everything in the 640KB that can be addressed in real mode (no memory manager) - Play with JEMM86's flags, - Try the flash drive in another host computer for a while, - Understand what's happening. b) Maybe the flash drive is bad, even though a scan reports no bad blocks? Test idea: - Try a different flash drive for a while. Error message, from the last time it happened: --- C:\>vi DOCS\0812.TXT Jemm386: exception 0D occured at CS:EIP=0385:00000039, ERRC=00000000 SS:ESP=0F8D:00000080 EBP=00009FBF EFL=00033246 CR0=80000013 CR4=00000608 EAX=000FFFFF EBX=0000FFFF ECX=3F5F7FFF EDX=00000158 ESI=00000000 EDI=0000FFFF DS=0DA9 ES=0364 FS=0000 GS=0000 [CS:IP]=26 81 3D 38 37 75 19 26 Press ESC to abort program C:\>vi DOCS\0812.TXT ; pressed ESC, this file loaded normally --- Exception 0D (13 in hexadecimal) is a general pro- tection fault. The rest of the error message lists locations of segment registers in memory when the fault happened. These locations mean nothing to me, but I identified the segment registers (quoted text is from Wikipedia): * current program Code Segment (CS:EIP=0385:00000039, ERRC=00000000) ([CS:IP]=26 81 3D 38 37 75 19 26) "The code segment, also known as text segment, contains executable code and is generally read- only and fixed size." * current Stack Segment (SS:ESP=0F8D:00000080 EBP=00009FBF EFL=00033246 CR0=80000013 CR4=00000608 EAX=000FFFFF EBX=0000FFFF ECX=3F5F7FFF EDX=00000158 ESI=00000000 EDI=0000FFFF) "The stack segment contains the call stack, a LIFO structure, typically located in the higher parts of memory. A "stack pointer" register tracks the top of the stack; it is adjusted each time a value is pushed onto the stack. The set of values pushed for one function call is termed a "stack frame". A stack frame consists at min- imum of a return address. Automatic variables are also allocated on the stack. On standard PC x86 architecture the stack grows toward address zero, meaning that more recent items, deeper in the call chain, are at numerically lower address- es and closer to the heap." * current Data Segment (DS=0DA9) "The data segment contains initialized static variables, i.e. global variables and local static variables which have a defined value and can be modified." * an Extra Segment determined by the system program- mer (ES=0364) * "The Intel 80386, introduced in 1985, adds two additional segment registers, FS and GS, with no specific uses defined by the hardware." (FS=0000 GS=0000) I shut down the computer, mounted the USB drive as mass storage on another computer, backed up my documents, copied a new textfile into the docs folder, put it back in the HP Mini, and booted it up. When I tried to run DOSSHELL, JEMM86 reported the same error, but new segment register addresses. I shut it down again, mounted the USB as mass stor- age again, and checked DOSSHELL's directory. Corrup- ted into undeleteable garbage. I had to reformat and reimage the USB drive. After documenting the new error message and my an- notated config.sys and autoexec.bat on this system, I'll end this textfile. Sorry, no solutions on this day. Pinkie promise I'll write about RAMDisk adven- tures in the next textfile. --- C:\>dosshell Jemm386: exception 0D occured at CS:EIP=20CD:00010000, ERRC=00000000 SS:ESP=0375:000057F8 EBP=00000000 EFL=00033286 CR0=80000013 CR4=00000608 EAX=000F0000 EBX=00000000 ECX=3F5F0375 EDX=00000300 ESI=00000100 EDI=0000FFEE DS=0375 ES=0375 FS=0000 GS=0000 [CS:IP]=00 00 00 00 00 00 00 00 Press ESC to abort program --- Jemm386 is an expanded memory manager. In order to be backward-compatible with DOS programs written for the 16-bit 8086 chip (1977), DOS only addresses 1MB of (RAM) memory in "real" mode. 640KB is avail- able to programs. To free memory, DOS utilities like HIMEMX can load programs (like COMMAND.COM and drivers) into the upper memory area between 640KB and 1MB, being careful not to interfere with the other stuff up there, like video memory. Then DOS expanded memory managers like JEMM86[^1] can page segments in and out of extended memory above 1MB. To my n00b understanding, you have to load HIMEMX first. [^1]:https://github.com/Baron-von-Riedesel/Jemm Here's the config.sys on this system: --- ; SvarDOS kernel configuration ; highest allowed drive letter LASTDRIVE=Z ; max. number of files that programs are allowed to open simultaneously FILES=25 ; XMS memory driver DEVICE=C:\SVARDOS\HIMEMX.EXE ; EMS driver device=c:\drivers\jemm\jemm386.exe frame=none ram ; try moving DOS to upper memory, then to high memory DOS=UMB,HIGH ; command interpreter (shell) location and environment size SHELL=C:\COMMAND.COM /E:512 /P ; NLS configuration COUNTRY=044,437,C:\SVARDOS\COUNTRY.SYS --- So I load HIMEMX, then JEMM386 with options I don't fully understand, then get DOS out of the 640KB of real-mode memory so other programs can use it. The readme says: "FRAME= instructs Jemm to use a certain page frame. Accepted are frame values from 8000 to E000 or NONE. The page frame should start at the beginning of a physical EMS page, that is, the frame address should be divisible by 0x400 without remainder. FRAME= NONE disables the page frame, but there are quite some programs which won't run with this setting. A page frame below A000 should be set only on computers with 512 kB of conventional memory. Usually it's better to let Jemm find a page frame on its own, because choosing an address which is not free might cause troubles. "RAM/NORAM instruct Jemm to supply UMBs or not. RAM is the default. NORAM is intended to be used when loading Jemm from the cmdline, in which case adding UMBs might be less useful." More notes from the readme: "To provide Expanded Memory an EMM Emulator like Jemm runs the cpu in so-called V86-mode. This mode does not allow to run privileged opcodes. Some of these opcodes which might be useful for application programs are emulated by Jemm, how- ever. These are: - mov , ;special_reg = CRn, DRn, TRn - mov , ;reg = eax, ebx, ecx, edx, esi, edi, ebp - WBINVD - INVD - WRMSR - RDMSR - RDTSC" "If Jemm halts or reboots the machine, the follow- ing combinations of parameters may help to find the reason. Generally, Jemm386 should be loaded immediately after the XMM (HIMEM[S]X.EXE, HIMEM.SYS), and the XMM itself should be the first device driver to be loaded. For testing, it might also help to prevent DOS from loading in the HMA and/or not to use UMBs at all. - X=A000-FFFF NOHI NOINVLPG This is the safest combination. If this doesn't work, Jemm most likely isn't compat- ible with the current DOS/BIOS; for example, the BIOS might try to unconditionally use "un- real" mode to access USB mass storage devices - with Jemm, this will cause an exception. - X=TEST NOHI NOINVLPG This is slightly less safe, since Jemm will scan the upper memory region to find "unused" address ranges usable for UMBs. If this doesn't work, one has to manually set X=xxxx- yyyy to finally find the region which causes the troubles. Tool MEMSTAT may be used to find the address region which is reserved for the ROM-BIOS." "Some DOS programs will not work if EMS is enabled without a page frame. MS CodeView v4.1, for example, may refuse to start then. Some DOS programs will crash if too much VCPI memory is offered. Jemm's default is 128MB, it can be changed with option MAX=xxx. Popular pro- grams that may cause troubles are programs that use Borland's DPMI hosts DPMI16BI.OVL/DPMI32VM.OVL (coupled with RTM.EXE/32RTM.EXE). Setting Jemm option MAX=32752K (that's 32MB minus 16kB) should help; alternately, try setting environment vari- able "DPMIMEM=MAXMEM 16383"." In line with the readme, the first time I corrupted this filesystem, the proximate cause was a DPMI host (whatever that is) I loaded to try to modify the AMB ("Ancient Machine Book") files SvarDOS stores its help system in. I guess I have some troubleshooting ideas. But no explanatiion for corruption of the filesystem on my USB flash drive. Even if I fix it, I may never understand. Any hints help. Remember, I know almost nothing, and don't enjoy the chase, just the result: a simple, saved from the trash and the shelf, un- surveilled, working system, with no dark patterns. The relevant parts of my autoexec.bat, with comments: --- lh FDAPM ADV:REG ;lh loads this into high memory, ;it supposedly enables CPU power ;saving SET LANG=EN lh \drivers\doskey\doskey ;loads into high memory, ;enables command history lh \drivers\ctmouse\ctmouse ;mouse driver to HMA SET NLSPATH=%DOSDIR%\NLS SET DIRCMD=/O/P SET WATTCP.CFG=%DOSDIR% ;guessing these set environ- set temp=%dosdir%\temp ;ment variables I don't un- set tmp=%dosdir%\temp ;derstand. set dircmd=/oen --- There you have the shape of my current dilemma. I will try stuff. Next: How FUZOMA loads DOS into a RAMDisk! Later this month, Results of tests to try to stop probably: ghosts from eating my flash drive. If you understand any part of why JEMM86 exits and my filesystem gets corrupted, my email's agk@sdf.org. Every little tidbit helps.