> 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:

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:

> 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 

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


Freedos-devel mailing list

Reply via email to