noshutdown wrote:

and i wanna know how mem.exe and chkdsk.exe reports free conventional ram?

well this is just realmode memory. Calculating that is easy.

you can

1 - walk, the MCB chain, remove your current app and count up all free memory. east to do!
2 - do a alloc all in dos which will return largest free memory block. keep allocating blocks until you run out, add them all up.

then test for ems, if present, get the count of free pages, multiply by 16kb since a page is 16kb.
then test for xms, if present, get how much is free.

I wrote a utility to walk the MCB and manipulate memory on my tandy 1000 sx to add blocks in umb to the chain (in dos3.3 there is no umb).

This is part of it I cut down for you as an example, builds with watcom as real mode exe

BloodyCactus wrote:

well this is just realmode memory. Calculating that is easy. you can […]
Show full quote

well this is just realmode memory. Calculating that is easy.
you can

1 - walk, the MCB chain, remove your current app and count up all free memory. east to do!

I wrote a utility to walk the MCB and manipulate memory on my tandy 1000 sx to add blocks in umb to the chain (in dos3.3 there is no umb).

This is part of it I cut down for you as an example, builds with watcom as real mode exe

MCBLIST.ZIP

thanks a lot for the info. unfortunately i am not very experienced in programming so i can barely understand how it works, and there are some features in the code that i don't need, so i wonder if i got it right:
1.define a struct of MCB, and a pointer of it.
2.use int21h-52h to get the address of first MCB, and set the pointer to it.
3.sum up its size if its owner is 0.
4.move the pointer onto the next MCB(i havn't figured out how to yet) and repeat until its Signature is 'Z'.

i wrote a little quick and dirty program(with borland c) to see if i got it right, but it only displayed 5 blocks and ended with a block type 0. can you tell me where i have done wrong?

1#include <dos.h>
2#include <iostream.h>
3
4long freeram(int mode)
5{
6	if ((mode<1)||(mode>2))
7		return -1;
8	struct mcb
9	{
10		unsigned char type;
11		unsigned short owner;
12		unsigned short size;
13		unsigned char unused[3];
14		unsigned char name[8];
15	};
16	mcb far *mcbpointer;
17	unsigned short far *temp1;
18	long freeram=0, maxfreeblock=0;
19	_AX=0x5200;
20	geninterrupt(0x21);
21	temp1=(unsigned short far*)MK_FP(_ES,_BX-2);
22	mcbpointer=(mcb far*)MK_FP(*temp1,0);
23	unsigned int blockcounter=0;
24	do
25	{
26		cout<<"block "<<(++blockcounter)<<" is "<<(mcbpointer->size)<<"*16 bytes, block type is "<<(int)(mcbpointer->type)<<".\n";
27		if (!(mcbpointer->owner))
28		{
29			cout<<"this block is free.\n";
30			freeram+=(mcbpointer->size);
31			if (maxfreeblock<(mcbpointer->size))
32				maxfreeblock=(mcbpointer->size);
33		}
34		mcbpointer+=((mcbpointer->size)+1);
35	}
36	while ((mcbpointer->type)=='M');
37	cout<<"last block type is "<<(int)(mcbpointer->type)<<endl;
38	if (mode==1)
39		return (freeram<<4);
40	else
41		return (maxfreeblock<<4);
42}
43
44int main(int argc, char **argv)
45{
46	cout<<freeram(1)<<" bytes conventional ram free.\n";
47	cout<<"largest free block is "<<freeram(2)<<" bytes.\n";
48	return 0;
49}

and the result is:
block 1 is 1*16 bytes, block type is 77.
block 2 is 4*16 bytes, block type is 77.
this block is free.
block 3 is 16*16 bytes, block type is 77.
block 4 is 9*16 bytes, block type is 77.
block 5 is 5236*16 bytes, block type is 77.
last block type is 0
64 bytes conventional ram free.

i found it! its that far mcbpointer that overflowed, so i changed the way of moving onto the next block and its working now.

block 1 is 1*16 bytes long, block type is 77.
block 2 is 4*16 bytes long, block type is 77.
this block is free.
block 3 is 16*16 bytes long, block type is 77.
block 4 is 9*16 bytes long, block type is 77.
block 5 is 4112*16 bytes long, block type is 77.
block 6 is 36444*16 bytes long, block type is 90.
this block is free.
583168 bytes conventional ram free.
largest free block is 583104 bytes.

this is still quite surprising because dosbox start out at 632kb free, so the program itself took 62.5kb even though i compiled in tiny mode and only a few variables were defined.
i also want to know if these keywords work with other dos compilers?

you must pack your structures.

also last block is 'Z' and still valid, your skipping the last block.

BloodyCactus wrote:

also last block is 'Z' and still valid, your skipping the last block.

true but i have already observed and fixed that. as you can see from my last reply, the last block type reported is 90.
what shall i do to "pack my structures"?

i also noticed that the program reports ~570kb free when compiled in tiny mode, ~550kb in small mode, and ~600kb in large mode. in all modes the reported amount is close to farcoreleft(), so i wonder if its because large mode has no near heap, which is not reflected in the mcb chain? how do i add up the unused amount in near heap in tiby/small/medium mode?

Scali wrote:

There are basically 3 kinds of pointers in 16-bit segmented mode. As you probably know, a pointer is a combination of two 16-bit […]
Show full quote

There are basically 3 kinds of pointers in 16-bit segmented mode.
As you probably know, a pointer is a combination of two 16-bit integers, segment and offset.
The linear address is formed by (segment*16)+offset.

A near pointer stores only the offset, the segment is the 'default' segment for data or code. The advantage is that pointers are smaller, and pointer arithmetic is faster, because the segment is fixed.
A far pointer stores offset and segment, but the segment is 'static'. That is, pointer arithmetic only updates the offset part. This is still relatively fast, but obviously limits you to a 64k block of data starting at the given segment.
A huge pointer updates both segment and offset, which allows you to address all memory as if it is linear. So you can use it for arrays of more than 64k, but it is also the slowest.

In a huge model, all pointers are huge by default.

thanks for the explaination, but do they still make much speed difference when running on 386 or newer cpus?

noshutdown wrote:

thanks for the explaination, but do they still make much speed difference when running on 386 or newer cpus?

Yup. In 16-bit mode, you only have instructions and address modes to handle offsets, so only 'near' addresses.
Any far/huge pointer handling requires changing the segment, which just takes several instructions.

That's why 32-bit mode quickly became mainstream for games and other performance-critical software, once the 386sx and better CPUs were commonplace.
In 32-bit mode, your offsets are now 32-bit, and you can address 4 GB at a time, so you never need to deal with segments anymore. All address modes and special instructions such as lods, stos, movs will now update 32-bit offsets, which effectively give you a flat addressing model.
It makes handling datasets of more than 64k a lot faster and easier.

noshutdown wrote:

i also noticed that the program reports ~570kb free when compiled in tiny mode, ~550kb in small mode, and ~600kb in large mode. in all modes the reported amount is close to farcoreleft(), so i wonder if its because large mode has no near heap, which is not reflected in the mcb chain? how do i add up the unused amount in near heap in tiby/small/medium mode?

odd. mine does not change results based on changing small/large/huge/compact.

BloodyCactus wrote:

odd. mine does not change results based on changing small/large/huge/compact.

i read your program over and noticed that after you make a copy of the mcb chain, you treat the memory used by your own program as free, and merge it into the previous or next block if either is free. did i get it right?
this does correspond to the available ram of dos, but what i really want is "how much ram can i still abuse without getting into trouble" during my program. yes there is a lot to be concerned like the difference between near heap and far heap, and i have yet to find out how to new an object larger than 64kb rather than farmalloc...

Under watcom, if you want to alloc the largest free block of ram in real mode,

1#include <dos.h>
2uint16_t segment;
3uint16_t size_paras;
4// ask for all, dos returns max size we can have
5_dos_allocmem(0xFFFF, (unsigned short*)&size_paras);
6// allocate max size then
7_dos_allocmem(size_paras, (unsigned short*)&segment);

thats off top of my head, but should work.

in protected mode that wont work tho.

I'm still not clear what your real goal is.

BloodyCactus wrote:

thats off top of my head, but should work.

in protected mode that wont work tho.

I'm still not clear what your real goal is.

what i want is:

1#in real mode
2cout<<"total unused ram in far heap.";
3cout<<"largest free block in far heap.";
4switch (memorymode)
5{
6    case tiny:
7    case small:
8    case medium:
9        cout<<"total unused ram in near heap.";
10        cout<<"largest free block in near heap.";
11}

i also found that counting the mcb chain doesn't reflect freed blocks, thats the same issue as coreleft() and farcoreleft(). heres some results:

initial status:
coreleft() reports 635088 bytes free, farcoreleft() reports 635088 bytes free.
block 5 is 896*16 bytes long, block type is 77, owner is 402.
block 6 is 39660*16 bytes long, block type is 90, owner is free.
634624 bytes free, largest free block is 634560 bytes long.

after mallocing 8*32kb blocks in far heap:
coreleft() reports 372816 bytes free, farcoreleft() reports 372816 bytes free.
block 5 is 17280*16 bytes long, block type is 77, owner is 402.
block 6 is 23276*16 bytes long, block type is 90, owner is free.
372480 bytes free, largest free block is 372416 bytes long.

freeing block 0.
freeing block 1.
freeing block 2.
freeing block 3.
freeing block 4.
freeing block 5.
freeing block 6.
//block 7 is not freed.
after freeing block 0~6:
coreleft() reports 372816 bytes free, farcoreleft() reports 372816 bytes free.
block 5 is 17280*16 bytes long, block type is 77, owner is 402.
block 6 is 23276*16 bytes long, block type is 90, owner is free.
372480 bytes free, largest free block is 372416 bytes long.

noshutdown wrote:

i also found that counting the mcb chain doesn't reflect freed blocks, thats the same issue as coreleft() and farcoreleft(). heres some results:

you have a fundamental misunderstanding how dos memory and compilers work. Pretty much any dos compiler manages memory itself, not via dos (func 48/49/4A) with the MCB. Compilers will often allocate large blocks and internally manage them through its internal heap mechanism and using sbrk. malloc + free are not dosfunc 0x48 + 0x49.