inability to use UMBs

[stsp]

DOS=UMB is not understood by MOS.
The documented solution is to use FREEMEM=
statements to specify the UMB blocks manually.
My config.sys looks like the below:

FREEMEM=B0000,B8000^M
FREEMEM=D0000,E0000^M
smpsize=16^M
cache=16^M
LASTDRIVE=Z^M

The FREEMEM= statements worked:

[C:\]mos info
 
PC-MOS System Information         Start     End
 
Freemem =                         B0000    B8000
Freemem =                         D0000    E0000
 
MOS Kernel Segment #1               700     D200
MOS Kernel Segment #2              D200    1B7F0
System Memory Pool (SMP) #1       1B7F0    1F7F0
Disk Cache Descriptors            1FA00    1FA80
Disk Cache                        1FA80    23A80
Command Processor                 23A80    2BE90

And yet there was no any low memory freed
as the result:

[C:\]   bin\mem
 
Memory Type        Total       Used       Free
----------------  --------   --------   --------
Conventional          640K       202K       438K
Upper                   0K         0K         0K
Reserved              384K       384K         0K
Extended (XMS)      8,256K        64K     8,192K
----------------  --------   --------   --------
Total memory        9,280K       650K     8,630K
 
Total under 1 MB      640K       202K       438K
 
Total Expanded (EMS)                8,576K (8,781,824 bytes)
Free Expanded (EMS)                 8,128K (8,323,072 bytes)
 
Largest executable program size       438K (448,336 bytes)

Same 438K are available when no FREEMEM=
directive specified. So it seems like, contrary to
what is advertised in the doc, MOS does not
relocate itself to the space specified by FREEMEM=.
Please let me know if there is a way to "ask" him
politely to do so.

[roelandjansen]

I have under vmware the following:

$386.sys /p
$ems.sys
freemem c8000,ec000

kernel segment 1 d8000-e4b00
kernel segment 2 101000-10f5f0
smp c8000-d8000

I can add tasks up to 568k. (10 and have SMP at 73% use)

[stsp]

Yes, it was already pointed by @the-grue that
with MEMDEV= it starts to work. But it is not
documented to require MEMDEV=, and also
it looks like it should work otherwise, because
in mos info I can see the added memory regions.
They are just not used.

[stsp]

As it stays, it seems to be impossible to use
UMBs w/o prot mode drivers, which is both
contrary to the documentation, and is a severe
limitation (if not bug).

[roelandjansen]

that confirms what @the-grue saw too. Removing the protected mode driver leaves the
size to just under 400k here.

without looking in the code -- I think the announced FREEMEM is only what's from the config.sys file and not if it's really remapped without memory management.

(I currently am trying to mount the vmdk; that works; And now I want to add tooling et al so that I can build easily in MOS itself).

So if it's a bug or a lack in the docs, I am not sure at this point.

[stsp]

Well, apart from the docs, we can also consider
the fact that other DOSes do not have such limitation.
So while you can "fix" the docs, the most natural
and user-friendly move is to fix it in a code.

[the-grue]

fact that other DOSes do not have such limitation

MOS != DOS

Two completely different animals. Though MOS strives for DOS compatibility, it is not 100% compatible and doesn't aim or claim to be. Especially if you are looking at features > DOS 5.0 because it looks like MOS development didn't add features above DOS 5.0.

Now, with that said, we can always ADD features to make it closer to DOS compatibility but someone is going to have to do the coding. And that someone can't be just me unless someone wants to pay me to make this my full time job. :)

[roelandjansen]

I am with you on this James. The first thing to shed is to get rid of multitasking, multiport i/o and the like to make it a DOS clone. But that's kind of throwing the baby out with the bathwater. IOW, it's not a good idea.

Adding fetaures is fine of course and sending @the-grue money via paypal as well ;-)

[stsp]

Unfortunately for @the-grue, most of everyone here
in this forum have already written his own DOS with all
the bells and whistles, and will unlikely pay for the friendly
projects. :)
As for me, I do already pay (sometimes) for developing
my DOS, so I can't also pay for MOS obviously. :)
But if someone wants to get paid - be my guest.
I always look for good DOS coders.

[the-grue]

That was actually a joke. The best I have done in the past is an autographed copy of Andrew Tanenbaum's "Operating Systems Design and Implementation 3e" as a bounty for porting software to Minix. Everything else I have done is for fun and/or a challenge. Coding isn't my day job, it is a hobby and a passion. Besides that, I kind of like my day job. 🙂 You are correct, nobody is going to pay someone to work fulltime on stuff like this.

[stsp]

You are correct, nobody is going to pay someone to work fulltime on stuff like this.

Indeed, but bounties for the specific tasks
are much more viable in such cases than
the full-time work (which I think is very unlikely
in a DOS area these days).
Bounties never hurt those who likes his daily job. :)

[the-grue]

Hi @stsp! I had asked on another thread where you are getting the UMB.SYS driver? Is it available in source code form or is it part of a compiled/commercial distribution?

[stsp]

Hi, it is available in sources as part of
the dosemu package. The sys file is
just a stub: all functionality is implemented
in the emulator itself so there are no
hopes you can test it with vbox.
Look around for umbpci.sys driver -
I think that one was supposed to work
on vbox.

[the-grue]

Hi @stsp! I downloaded umbpci.sys and have reached out to the author of umbpci to see if he would be willing to share the source code with me. Not sure what will come of it, but we'll see.

[stsp]

Wow, I didn't know its closed source!
@mcericdos Is there any open-source UMB pci
driver around? :)

[the-grue]

It sounds like it is open source. The author just doesn't have the source code available for download. You have to e-mail and ask for it.

My "Not sure what will come of it, but we'll see" was more towards the ability of us to get support for MOS=UMB into MOS. :)

[stsp]

OK, I think its author also references other
similar drivers that DO have the source code
available for download:
https://www.uwe-sieber.de/umbpci_e.html
Scroll to the bottom: at least uram and hiram
come with sources, but both sources have
comments and var names in German.

[stsp]

In fact, DOS=UMB only enables the use
of UMB for device driver and apps with LOADHIGH
and DEVICEHIGH. Is usually not difficult and
should be doable for MOS too.
What is more difficult is DOSDATA=UMB -
that one asks the DOS to relocate its data
to UMB.
By the way, I wonder if FREEMEM in MOS does
the first thing at least. I was checking only if
the DOS have relocated and freed some mem.
No, but maybe at least it allowed to load something
else to UMB?

[dgorski]

Hi

I have enjoyed a few days of PCMOS. I'm running the 5.01 with the patches, (no 60m timebomb.) I cannot remember how I went about this, I think I used one of the archives that was already installed/patched. Will look at the 5.02 build, but wanted to prove it all out first since I managed to get 5.01 working...

I too am considering it for a multinode DOS BBS. I've managed to run the software, but have a couple of issues I need to work around. Will open them seperately. Meanwhile I wanted to chime in on ths memory management discussion for MOS, which is really cool!

I've been struggling to determine free high memory areas, but using the boot/crash/fix approach I've been able to move almost everything high. I should mention I'm running in QEMU with SeaBIOS. Here's my latest success, which is stable with basically nothing running in it...

[C:\]type config.sys
FREEMEM=C80000,EA0000
MEMDEV=C:\PCMOS\$386.SYS
SMPSIZE=68K
DEVICE=C:\PCMOS\UPDAT501.SYS
DEVICE=C:\PCMOS\$SERIAL.SYS

[C:\]mos info

PC-MOS System Information         Start     End

Freemem =                         C8000    EA000

MOS Kernel Segment #1             D9000    E5B00
MOS Kernel Segment #2            101000   10F530
System Memory Pool (SMP) #1       C8000    D9000
Disk Cache Descriptors            E5D10    E5D90
Disk Cache                         7000     8000
Command Processor                 E5B00    E5B10
Master Video Context Area         E6000    EA000

[C:\]mos map

                         PC-MOS USER TASK STATISTICS

Task Start Size Video  User    Program     Port   Baud   Pri Slice Files  Status

 0*  08000 608K  CGA         MOS     .COM   N/A    N/A   2    1     3   ACT  ND
 2   08000 608K  CGA         COMKYERR.EXE   N/A    N/A   2    1     5   ACT  ND
 1   08000 608K  CGA         COMKYERR.EXE   N/A    N/A   2    1     5   ACT  ND
 3   08000 608K  CGA         COMMAND .COM   N/A    N/A   2    1     3   WAIT ND
 4   08000 608K  CGA         COMMAND .COM   N/A    N/A   2    1     3   WAIT ND

61568K of 65152K Memory Available
   32K of    68K SMP Allocated

My goal is to run 4 nodes, the above shows two of them running (COMKYERR.EXE is a Pascal program I wrote to act as a fake modem/mailer combo front-end for my BBS software).

If SeaBIOS had better doco on their memory map it might be possible to load everything high, but I haven't found anything concrete on which chunks are free verus used so it was trial and error. Actually thought about re-building the SeaBIOS to see if I could tighten it up but that's may be just a bit over my head. We'll see.

Enjoy!

• Darrin

[stsp]

MEMDEV=C:\PCMOS$386.SYS

Yes, it was already pointed in that thread
that with MEMDEV it is much easier to do
than without. :) The problem was only that
it is not documented that way, and also the
emulator I used to run MOS, does not
support MEMDEV (it provides its own guest
drivers), so I had a problem.

[dgorski]

Hmm. I read through the 5.01 manual and it seemed pretty clear that there is a significant difference between "memory managed" and not.

Anyway, I was just excited to have shoved it all into himem - (I moved C80000 down to C7 and now the cache is located in himem too, leaving 612K of convential for tasks!) I thought it might save someone else the many hours I spent getting to this point. ;)

[C:\]type config.sys
FREEMEM=C70000,EA0000
MEMDEV=C:\PCMOS\$386.SYS
SMPSIZE=68K
DEVICE=C:\PCMOS\UPDAT501.SYS
DEVICE=C:\PCMOS\$SERIAL.SYS

[C:\]mos info

PC-MOS System Information         Start     End

Freemem =                         C7000    EA000

MOS Kernel Segment #1             D8000    E4B00
MOS Kernel Segment #2            101000   10F530
System Memory Pool (SMP) #1       C7000    D8000
Disk Cache Descriptors            E4D10    E4D90
Disk Cache                        E9000    EA000
Command Processor                 E4B00    E4B10
Master Video Context Area         E5000    E9000

[C:\]mos map

                         PC-MOS USER TASK STATISTICS

Task Start Size Video  User    Program     Port   Baud   Pri Slice Files  Status

 0*  07000 612K  CGA         MOS     .COM   N/A    N/A   2    1     3   ACT  ND
 1   07000 612K  CGA         COMMAND .COM   N/A    N/A   2    1     3   WAIT ND

Now I just wish I knew assembler so I could fix command.com to behave normally (exit with proper returncode/errorlevel) and get the kernel to stop brutalizing the processor.

• Darrin

[stsp]

Well, while its amazing for mos, 612K
of conv mem is definitely not the
world record. I think even with freedos
you can get more, and freedos is
quite bad on that too.

[roelandjansen]

I've written BIOSes within 2kB.... juggling a bit most of the time works fine and note that you can start several tasks with this memory layout. freedos is quite bad on that too... E.g. I feel that 612k is pretty neat and for the DOS tools most people run more than adequate.

…

On Thu, Apr 30, 2020 at 10:58 AM Stas Sergeev ***@***.***> wrote: Well, while its amazing for mos, 612K of conv mem is definitely not the world record. I think even with freedos you can get more, and freedos is quite bad on that too. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#89 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNIXVSFM7REUHRDNMHNMCLRPE4TTANCNFSM4IK2T7IQ> .

[stsp]

several tasks with this memory layout.
freedos is quite bad on that too...

Yep, you are right.
Maybe a comparison with desqview will
make some sense.