Are paragraphs and pages the same in terms of memory?

[Robert Pengelly]

Some MZ executables have maxalloc set to 0xFFFF and documentation says it's "The number of paragraphs requested by the program" so does that mean that 1048560 (0xFFFF * 16) bytes are allocated or does it mean that 65536 (0xFFFF / 16 + 1) bytes are allocated?

[s***@yahoo.com]

Post by Robert Pengelly
Some MZ executables have maxalloc set to 0xFFFF and documentation says it's "The number of paragraphs requested by the program" so does that mean that 1048560 (0xFFFF * 16) bytes are allocated or does it mean that 65536 (0xFFFF / 16 + 1) bytes are allocated?

~~~~~~~
No, a 'page' is 0100h bytes since the Intel 8-bit days, (16 bit addresses.) where the low order byte of the 16 bit address is 00h.
So valid pages are {0000h, 0100h, 0200h, ...}.
Incrementing the high order byte of an address is 'stepping' through memory a 'page' at a time.

Considering Intel x86, 'paragraph' is a sub unit, 16 bytes, where the low order nibble is zero.
Incrementing a Segment Register value is akin to 'stepping' through memory a 'paragraph' at a time.

So, 'paragraphs' and 'pages' are not the same in terms of memory.

~~~~~~~
As to MZ & Dos malloc treatment across various x86's, I don't know.
I seem to recall that value of FFFFh is treated as a flag to allocate as much memory as freely available.
You will need to get into the dos documentation on its compiler to figure your question out.

hth
Steve
~~~~~~~

[Paul Edwards]

Post by s***@yahoo.com
No, a 'page' is 0100h bytes since the Intel 8-bit days, (16 bit addresses.) where the low order byte of the 16 bit address is 00h.
So valid pages are {0000h, 0100h, 0200h, ...}.
Incrementing the high order byte of an address is 'stepping' through memory a 'page' at a time.

How do you reconcile that with:

https://www.ctyme.com/intr/rb-2939.htm

02h WORD number of bytes in last 512-byte page of executable
04h WORD total number of 512-byte pages in executable (includes any
partial last page)


BFN. Paul.

[George Neuner]

On Mon, 30 Oct 2023 14:46:52 -0700 (PDT), Paul Edwards

Post by Paul Edwards

Post by s***@yahoo.com
No, a 'page' is 0100h bytes since the Intel 8-bit days, (16 bit
addresses.) where the low order byte of the 16 bit address is 00h.
So valid pages are {0000h, 0100h, 0200h, ...}.
Incrementing the high order byte of an address is 'stepping' through
memory a 'page' at a time.

https://www.ctyme.com/intr/rb-2939.htm
02h WORD number of bytes in last 512-byte page of executable
04h WORD total number of 512-byte pages in executable (includes any
partial last page)
BFN. Paul.

They have nothing to do with one another.

What you have quoted here is from the *disk* based header of an EXE
file. To save space, the header encodes the file's length in *blocks*
rather than in bytes - 512 bytes being the block size of the storage
medium (floppy diskette) that was in use at the time DOS was designed.

The ctyme description errs in referring to blocks as "pages".

[s***@yahoo.com]

Post by Paul Edwards

Post by s***@yahoo.com
No, a 'page' is 0100h bytes since the Intel 8-bit days, (16 bit addresses.) where the low order byte of the 16 bit address is 00h.
So valid pages are {0000h, 0100h, 0200h, ...}.
Incrementing the high order byte of an address is 'stepping' through memory a 'page' at a time.

https://www.ctyme.com/intr/rb-2939.htm
02h WORD number of bytes in last 512-byte page of executable
04h WORD total number of 512-byte pages in executable (includes any
partial last page)
BFN. Paul

~~~~~~~
(How do you reconcile that with)

That implies that they are in conflict.
I was inclined to say they are 'apples' and 'oranges'. We could also add 'bananas' by talk of cpu pagination of 4k pages.
The qualifier '512-byte' self-defines 'page' there, and George beats me to the term 'blocks' - which is more fitting because
we are refering to the storage and retrieval to 'block devices'.

Kildall use the term 'pages' - meaning 0100h bytes on Intel's 8080 cpu, in an article for DDJ where he describes a method
to build page relocated software with the tools of that era, of late 1970's that did not directly support this..

The method was to assemble a source file twice, First at "ORG 0000h', secondly at "ORG 0100h". The two binaries would
differ only in the high byte of addresses. A list of these addresses in a separate file, and provided to a Loader could allow
the Loader to place the binary in any 'page' of memory, and 'fixup' addresses to that 'page' to allow the binary to run there.
That is the earliest mention of 'page', and practical use method, that I know of.

The addressing method of the 8080 was changed in the x86. In the x86, the resolution of memory is now down to 16 bytes,
10h, because of Segmentation, and this the size of a paragraph. So a binary, ORG 0000h, is self-relocatable to any Segment
number, a 'paragraph'.

Steve
~~~~~~~