News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Allocation of memory in DOS??

Started by Shintaro, January 23, 2022, 04:42:14 PM

Previous topic - Next topic

Shintaro

Hi,
So there is a discussion about allocation of memory in the 16Bit programming forum. And rather than hijack the conversation I thought I would ask here.

1/ Is the correct way of allocating memory in DOS, to use the LIM standard, via Int 67, and query the status before requesting the allocation, in this case 64Kb or more? Or can you simply allocate it and let EMM386 handle it?

2/ 64Kb is a segment in DOS (EMM386 EMS) and I thought, maybe incorrectly, that it would be FAR jumps, as the code would be in a different segment to the data?

3/ Using .386, tells the compiler to use 32bit registers, but why use "segment word public use16 'CODE'" which to me says use 16bit registers?? Or have I completely misunderstood?

Regards,
Craig
"Wyrd bið ful āræd. Fate is inexorable."

hutch--

Craig,

Sorry to have to move your topic but we can't mix up 16, 32 and 64 bit assembler code as they are different planets.

FORTRANS

Hi,

Quote from: Shintaro on January 23, 2022, 04:42:14 PM
3/ Using .386, tells the compiler to use 32bit registers, but why use "segment word public use16 'CODE'" which to me says use 16bit registers?? Or have I completely misunderstood?

   The X86 processors can operate in different modes.  16-bit, 32-bit, and 64-bit code is
processed differently, an identical opcode can have different actions in different modes.
"USE16" says the processor is running in 16-bit mode.  This is the mode used for DOS
programs.  ".386" tells the assembler that 32-bit opcodes are legal to use.  Using 32-bit
instructions is perfectly legal in 16-bit mode (with limits).  But the assembler needs to
add prefixes to tell the CPU that the instruction is to be executed as a 32-bit instruction
and not as a 16-bit instruction.

HTH,

Steve N.

Shintaro

Quote from: hutch-- on January 23, 2022, 09:57:46 PM
Sorry to have to move your topic but we can't mix up 16, 32 and 64 bit assembler code as they are different planets.
Thanks mate, I just didn't want to cause any drama's with my basic questions.

Quote from: FORTRANS on January 24, 2022, 12:35:24 AM
Using 32-bit instructions is perfectly legal in 16-bit mode (with limits). 
Thanks Steve, I thought it was one or the other. I didn't think a mix was allowed. A bit more of RTFM.


"Wyrd bið ful āræd. Fate is inexorable."

_japheth

Quote from: Shintaro on January 23, 2022, 04:42:14 PM
1/ Is the correct way of allocating memory in DOS, to use the LIM standard, via Int 67, and query the status before requesting the allocation, in this case 64Kb or more? Or can you simply allocate it and let EMM386 handle it?

Your're lucky to ask such a question here, because I'm one of the few persons on this planet that are able to write an EMM, actually perhaps the only one that still maintains one of those beasts (https://github.com/Baron-von-Riedesel/Jemm. ( I usually don't do such frank bragging, but learnt recently that this is the prefered practice in this forum  :biggrin:).

To your question: no, it's NOT the correct way to allocate memory in DOS because the EMM (expanded memory manager) is an optional program to load, and running pretty much independant from DOS ( DOS doesn't care about memory blocks allocated thru LIM and you are responsible to free such blocks once you are done with them ).
DOS has its own memory allocation functions, but they are restricted to conventional memory ( 640 kB) and, since v5.0, socalled "upper memory" ( at best ca 300 kB, usually far less ).
Using EMS (=LIM), you may allocate up to 32 MB, but access to this memory requires some extra steps ( and running code in such memory is actually pretty "advanced" stuff, but it can be and has been done ).
Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.

nidud

#5
deleted

Shintaro

Quote from: _japheth on January 24, 2022, 11:21:25 PM

Your're lucky to ask such a question here, because I'm one of the few persons on this planet that are able to write an EMM, actually perhaps the only one that still maintains one of those beasts (https://github.com/Baron-von-Riedesel/Jemm. ( I usually don't do such frank bragging, but learnt recently that this is the prefered practice in this forum  :biggrin: ).

Lucky indeed!
It seems that a lot of people want to play with Win 3.1 and DOS but not do anything with it. It's a bit like owning a 4WD and never going off-road. It's just a pretty shinny thing.

QuoteTo your question: no, it's NOT the correct way to allocate memory in DOS because the EMM (expanded memory manager) is an optional program to load, and running pretty much independant from DOS ( DOS doesn't care about memory blocks allocated thru LIM and you are responsible to free such blocks once you are done with them ).
Now that's interesting, I had forgotten about freeing memory when done. Modern programming has made me lazy.


QuoteDOS has its own memory allocation functions, but they are restricted to conventional memory ( 640 kB) and, since v5.0, socalled "upper memory" ( at best ca 300 kB, usually far less ).
Ah, yep a quick search, int 21 function 48H. It helps when people point it out. Thank you. But I didn't know that restriction was for conventional memory and UMB drivers. I suppose that makes sense, since in the early days, that's all there was.
Ugh, my programming classes in 1990 were basically useless. Certainly gave me a false sense of knowledge.



QuoteUsing EMS (=LIM), you may allocate up to 32 MB, but access to this memory requires some extra steps ( and running code in such memory is actually pretty "advanced" stuff, but it can be and has been done ).

I have a lot more reading and experimenting to do. I always thought that the limit was 16Mb (16bit addresses 24 address pins). I would image that the reason I would not have thought about that limit back was the cost of memory. I think...1Mb = $120 here in Australia (Ballarat, Victoria)  about 1990'ish.

"Wyrd bið ful āræd. Fate is inexorable."

_japheth

Quote
It seems that a lot of people want to play with Win 3.1 and DOS but not do anything with it. It's a bit like owning a 4WD and never going off-road. It's just a pretty shinny thing.
This is an assembly forum - most things done in this language is just for fun and leisure, these days.

Quote
I always thought that the limit was 16Mb (16bit addresses 24 address pins). I would image that the reason I would not have thought about that limit back was the cost of memory. I think...1Mb = $120 here in Australia (Ballarat, Victoria)  about 1990'ish.

Address space.for real-mode is actually 1 MB only. And that isn't changed when using LIM memory. To access LIM memory directly is has to be mapped into this 1 MB address space ( usually a 64 KB area, the so-called "page frame").
Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.

jejump

Quote


It seems that a lot of people want to play with Win 3.1 and DOS but not do anything with it. It's a bit like owning a 4WD and never going off-road. It's just a pretty shinny thing.

Quote

This is an assembly forum - most things done in this language is just for fun and leisure, these days.

So... You guys might find this fascinating.  I work as a contract engineer for a variety of companies that make a variety of products.  One of those companies is Kennametal.  They manufacture carbide cutting tools, and one of their processes is grinding the carbide sharp and to finish size.  They just retired last year, about 10 of one such CNC grinder that boots up in MS-DOS 6.22, auto-starts Windows 3.11, then auto-starts the human-machine-interface (or HMI) and CNC management system.  In some instances, the operator would have to minimize the HMI and do stuff in Windows File Manager, so they had to know the Win3.11 environment, at least a little bit.

I've been called in to help with these machines in the event of hard drive failures (a whopping 100MB drive) or deeper DOS/Windows related issues with these machines.  I will say... These machines weren't decommissioned because of DOS/Windows 3.11. They were only taken out due to lack of available replacement parts on both, the control side and mechanical side of things.  Plus they were mechanically worn and that makes holding tolerances (in microns) a greater challenge.  Point being, DOS/Win 3.11 can actually still do useful things in the modern day.

-John

Shintaro

Quote
This is an assembly forum - most things done in this language is just for fun and leisure, these days.

Amazingly enough this forum is the opposite to others that I am a member of.


Quote
Address space.for real-mode is actually 1 MB only. And that isn't changed when using LIM memory. To access LIM memory directly is has to be mapped into this 1 MB address space ( usually a 64 KB area, the so-called "page frame").

I have a small understanding of the workings of LIM, but I am, at the moment going through subjects like Directives i.e Full vs Simplified segments etc, to ensure I understand them. As just pushing ahead, as I have found, wastes 10x more time, due to fixing/solving silly errors.
The biggest problem is documentation, ie. _BSS (Block Starting Symbol), took time to find out that it is the Full segment directive (Simplified = .DATA?) for uninitialized data, part of the DGROUP for tiny, small and compact models.

I need to do a bit more reading and experimenting before I ask more questions. So please don't take my silence as ignoring anybody.


"Wyrd bið ful āræd. Fate is inexorable."