Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!brandeis.BITNET!LINDAHL From: LINDAHL@brandeis.BITNET Newsgroups: comp.sys.atari.st Subject: GEMDOS memory allocation Message-ID: <8701190836.AA05609@ucbvax.Berkeley.EDU> Date: Mon, 19-Jan-87 03:36:40 EST Article-I.D.: ucbvax.8701190836.AA05609 Posted: Mon Jan 19 03:36:40 1987 Date-Received: Mon, 19-Jan-87 19:11:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: LINDAHL%BRANDEIS.BITNET@forsythe.stanford.edu Organization: The ARPA Internet Lines: 35 Date: Sun, 18 Jan 87 23:38 EST From: Subject: GEMDOS memory allocation To: info-atari16@score.stanford.edu X-Original-To: info-atari16@score.stanford.edu, LINDAHL has anyone looked into the way that GEMDOS manages memory? i seem to lose RAM over time, especially after running programs like micro emacs which do lots of Malloc calls (you are only allowed to allocate 20 blocks per process according to the GEMDOS manual). i think that GEMDOS "loses" memory when you do too many Mallocs, so i would like to look at the memory free and memory allocated lists and see what blocks aren't on either list. i looked into the Getmpb() bios function, but it seems that as far as the bios is concerned, GEMDOS allocates all memory. obviously GEMDOS is managing this memory internally. i next tried to trace a Malloc() call using MonST in trace-walk mode, but my machine freezes up when the rom routine tries to change register a7. (i guess that MonST isn't preserving it's stack or something.) no doubt the answer lies in the rom somewhere, but i'd rather spend lots of time looking. does anyone have any idea where GEMDOS keeps its list? Greg Lindahl us snail: box 2522 brandeis university bitnet: lindahl@brandeis.bitnet waltham mass 02254 cps: [76515,1122] [NSA CIA Cray hackey-sack tie-dye divestment radical civil disobedience Thoreau Locke Hobbes flower-power frisbee physics star wars Teller long hair vegetarians 'and to think that MY tax dollars pay for this!']