🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.micro.atari16
Article #1792

Re: Questions on BITBLIT, Malloc .......

#1792
From: XBR4D76H
Date: Fri, 12 Sep 1986 19:11
114 lines
4775 bytes
>I have some questions I hope someone can reply to:
> ......
>
>4.  Related to memory allocation.... Has anyone understood the Memory
>Parameter Block concept in the ST?  Is this related to GEMDOS's free memory
>list.  If so I'd try and write some working allocation routines (assuming
>Malloc is broken, see question 2) maintaining the system memory list
>myself, thereby not breaking the loader.  I looked a the MBP block in the
>system's variable area but nothing seemed to be linked to the three
>pointers in each.  Further, after an allocation, nothing changed.  Anyone
>understand how and where the SYSTEM's idea of free/allocated memory is
>kept?
>
> ......

I found some hints in the "Hitch' Guide" and played a bit with SID.

BIOS call "getmpb" is a special system call provided for GEMDOS use
only (parameter passing between BIOS and BDOS).
"getmpb" is called only once at boot time by GEMDOS to get its initial
memory management structure.

The first "getmpb" call initializes a BDOS structure at 0x56ec of type MPB
with  { 0x48e, 0, 0x48e } and a memory descriptor at 0x48e of type MD
with  {
         NULL         /* end of list */,
         0xa100       /* _membot */,
         0xedf00      /* _memtop - _membot (520ST+) */,
         NULL         /* owning process is system */
      }.
The memory descriptor at 0x48e is the initial single element free list for
the GEMDOS memory manager.
The first time, Malloc() is called, the MD at 0x48e is removed from the free
list and is inserted into the allocated list modified to the requested block
length. For the memory left a new MD is created and inserted into the allocated
list.
Insertion is done by putting the new in front of the existing elements.
This causes the MD at 0x48e to be the end of the allocated list and no Malloc()
call will change it.

Calling "getmpb" in a user program ( panic !!!!!!! ) modifies the last MD
in the allocated list.
Probably this has no effect to the memory manager because the modified MD
was originated for system memory which is never released, but who knows ?????

I wrote a little program to print the memory descriptor lists. It might be
useful, if you have memory fragmentation problems. Enjoy .....


------------ CUT HERE ------------

#include <osbind.h>

typedef struct PD {
                    long p_lowtpa,p_hitpa;
                    long p_tbase,p_tlen;
                    long p_dbase,p_dlen;
                    long p_bbase,p_blen;
                    char *p_xdta;
                    struct PD *p_parent;
                    char p_lddrv,p_curdrv;
                    char p_uft[2];
                    char *p_env;
                    char p_curdir[16];
                  } PD;

typedef struct MD {
                    struct MD *m_link;          /* next MD (or NULL) */
                    long m_start;               /* startaddr of block */
                    long m_length;              /* #bytes in block */
                    PD *m_own;          /* owner's process descriptor */
                  } MD;

typedef struct {
                 MD *mp_mfl;            /* memory free list */
                 MD *mp_mal;            /* memory allocated list */
                 MD *mp_rover;          /* roving ptr */
               } MPB;

MPB *gdosmpb = 0x56ec;  /* pointer to GEMDOS memory parameter block */

printmd(md)
  MD *md;
  {
     printf(" Address: %lx\tLength: %lx\tOwner: %lx\n",
             md->m_start, md->m_length, md->m_own);
  }

main(argc,argv)
  int argc;
  char *argv[];
  {
    MD *mdpnt;
    long stack;
    stack = Super(0L);
    mdpnt = gdosmpb->mp_mal;
    printf("\nAllocated Memory Blocks:\n\n");
    while (mdpnt) { printmd(mdpnt); mdpnt = mdpnt->m_link; }
    printf("\nFree Memory Blocks:\n\n");
    mdpnt = gdosmpb->mp_mfl;
    while (mdpnt) { printmd(mdpnt); mdpnt = mdpnt->m_link; }
    Super(stack);
    Cconin();
  }

------------ CUT HERE ------------

  Konrad Hahn
  Techn. University Darmstadt
  Dept. of Computer Science (Datentechnik)
  Merckstr. 25, D-6100 Darmstadt, W.-Germany
  BITNET: XBR4D76H@DDATHD21

....... a voice from good old Germany ........
Technical Details
Message-ID: <8609121814.AA25410@ucbvax.Berkeley.EDU>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!DDATHD21.BITNET!XBR4D76H

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!DDATHD21.BITNET!XBR4D76H
From: XBR4D76H@DDATHD21.BITNET
Newsgroups: net.micro.atari16
Subject: Re: Questions on BITBLIT, Malloc .......
Message-ID: <8609121814.AA25410@ucbvax.Berkeley.EDU>
Date: Fri, 12-Sep-86 15:11:42 EDT
Article-I.D.: ucbvax.8609121814.AA25410
Posted: Fri Sep 12 15:11:42 1986
Date-Received: Sat, 13-Sep-86 03:46:19 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 114