#: 9686 S10/OS9/6809 (CoCo)
    05-Mar-91  00:53:44
Sb: #9679-#Memory at 3am
Fm: Kevin Darling 76703,4227
To: DAVID DE FEO 71630,721 (X)

Dave - you're right on target, with the sole exception that: the System process
doesn't go ahead and allocate 64K of RAM, but will get more if it needs to.  If
your PMAP shows the system map to be all full up, then that happened.

PMap only shows what "64K images" have been assigned to process descriptors
(it's a Process Map).  It's to help you visualize how block numbers are shared
if they hold a module, and to show that code is mapped in high and data mapped
in at lower addresses, and to help debug memory requirements, etc.

MMap kinda shows the window RAM usage... the window memory comes from the
highest block numbers (with the kernel taking up block 3F at the very top).
WDir (in the libs) will actually tell you the block number(s) being used for
each window, if that'll help.  Each little tool tells a piece .

The SLED answer: I dunno, but any program can ask for more RAM after it starts
up, which could be what's happening there.

Yes, two 4K windows will try to use the same 8K block if possible. Use DDir to
make sure that the deiniz actually gave up the window.  There is a bug with the
text windows tho... what happens is this: if the window was visible when it's
given up, it is CLS'd.  Unfortunately that happens AFTER a "this block is free"
flag ($FF) was stored in the first byte of that 4K section when the RAM was
given back :-(  So the memory effectively disappears from use. Ouch.  I'll see
if I have a patch.  Fast grfdrv?  - kev

There is 1 Reply.