> On Apr 7, 2023, at 12:23 PM, tom ehlert <t...@drivesnapshot.de> wrote: > > Hi, > >> Don’t know if the issue is in the Kernel (0.85a), HimemX (3.38), JEMM386 >> (5.83) or My Head. > > it's in the Kernel - or in your head.
Yep, could be my interpretation of the documentation. > > to decide between these two alternatives it's always helpful to send your > actual sources - not > an english description of what you had intended to do. > and of course autoexec.bat/config.sys I understand that. :-) I was considering whipping up a demo program after finishing working on my current project. Possibly on a bootable floppy image. That would make understanding and finding the issue easier. In part, the previous post was to remind me to do that. And, remind me what was going on. But, it will only take a few minutes to create one. I’ll do it now. . . . Ok, that took longer than I wanted. But, it yielded some interesting results. You can download the sources and precompile test programs from my server at: https://fd.lod.bz/redist/memory/umbtest.zip There are 4 binaries built from the same source (conditional defines): UMBNTEST.COM - Binary without read back verification. UMBNTEST.SYS - Device driver without read back verification. UMBVTEST.COM - Binary with read back verification. UMBVTEST.SYS - Device driver with read back verification. (plus a sample FDCONFIG.SYS) Executing the COM files (with or without verification) performs as expected. But with the device driver version, things get interesting. When using the UMBVTEST.SYS (with read back verification), DOS says it successfully changes the UMB linked state. However, when reading back the new setting it returns 0x00. The driver then terminates and all is well. Using the UMBNTEST.SYS (no read back), once again DOS says it changed the UMB linked state. When read back, a error message is displayed. But, we continue anyway. No error changing the strategy. Allocation succeeds regardless of size tested or strategy. Sometimes returning a segment in the high memory area, sometimes low. The system will continue to boot. After both FDCONFIG.SYS and FDAUTO.BAT have been fully processed. The system crashes with a JEMM exception while trying to load FreeCOM. Loading the either test driver low exhibits the same behavior with one exception. When it allocates low memory, the segment address it returns is the code segment of the driver. Ouch. Testing the test driver under MS-DOS 6.22: When UMBNTEST.SYS is loaded high, DOS reports failure when attempting to set the linked state. Changing the allocation strategy is successful. All attempts to allocate memory fail with error 0x0008 and 0 free paragraphs. The system continues to boot and operates normally. When UMBNTEST.SYS is loaded low, DOS reports failure when attempting to set the linked state. All test allocations succeed. However, regardless of the strategy are allocated in upper memory using 0x40, 0x41, 0x42. Some are allocated at the beginning or end of high memory based on only 3 bits of the strategy. The system continues to boot and operates normally. The config under MS-DOS was very simple, basically just: DOS=HIGH DOS=UMB DEVICE=C:\MSDOS\SETVER.EXE DEVICE=C:\MSDOS\HIMEM.SYS /TESTMEM:OFF DEVICE=C:\MSDOS\EMM386.EXE NOEMS RAM DEVICE=C:\UMBNTEST.SYS > and - well I understand that kernel version control is a complete > mess - but Kernel 0.85a seems a bit unlikely given that > https://github.com/FDOS/kernel/blob/master/docs/history.txt refers to > 0.42. Sorry, was a long day and the cat kept jumping on me (great excuse for dumb mistakes). Don’t know how or why I wrote Kernel (0.85a). Should have been Kernel (2043), FreeCOM (0.85a)…. But obviously, FreeCOM would not have anything to do with the issue. > > Tom Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
