pcmos386v501
pcmos386v501 copied to clipboard
roelandjansen
inability to use UMBs
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.
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)
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.
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).
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.
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.
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. :)
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 ;-)
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.
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.
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. :)
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?
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.
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.
Wow, I didn't know its closed source! @mcericdos Is there any open-source UMB pci driver around? :)
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. :)
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.
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?
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
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.
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
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.
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 [email protected] 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 https://github.com/roelandjansen/pcmos386v501/issues/89#issuecomment-621706735, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNIXVSFM7REUHRDNMHNMCLRPE4TTANCNFSM4IK2T7IQ .
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.