From gdesroch@slate.Mines.Colorado.EDU Tue Feb 23 13:12:51 1993 Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629) on Tue, 23 Feb 93 13:12:47 -0600 id AA26862 with SMTP Received: from slate.Mines.Colorado.EDU by calvin.sfasu.EDU with SMTP (5.59/25-eef) id AA23590; Tue, 23 Feb 93 13:00:04 CST Return-Path: Received: by slate.Mines.Colorado.EDU (AIX 3.2/UCB 5.64/4.03) id AA65686; Tue, 23 Feb 1993 11:58:23 -0700 Date: Tue, 23 Feb 1993 11:58:23 -0700 From: gdesroch@slate.Mines.Colorado.EDU (DESROCHERS GARY FREDERIC) Message-Id: <9302231858.AA65686@slate.Mines.Colorado.EDU> To: hyperc-l@calvin.sfasu.edu Subject: Re: aux memory Status: R The following is a memory map for HyperC. I have had it for a while but noone ever asked for it. Following it is a couple of changes when using HC.System with some variables set. ROM Main Memory FFFF _____________ _____________ | monitor | | | F800 |-----------| | | _____________ DFFF | | | | | reserved | | | | ProDOS | |-----------| ???? | Applesoft | | | | ProDOS | | | | | |-----------| D100 | | | | | Free | D000 |-----------| |___________| |___________| D000 | other | C100 |___________| BFFF _____________ | ProDOS | BF00 |-----------| | | | | | File | ~ Buffers ~ | For | | HyperC | | | 9F00 |-----------| | C-Engine | | Stack | | | | ~ V ~ | They grow | | torward | | Each Other| 4000 |- ^ -| |-----------| | | | | Hi Res | | Your | | Page 1 | | Program | | | 2000 |-----------| |-----------| | | | | | opsys | | | | | 0800 |-----------| |-----------| | | | Text | | reserved | | Page 1 | 0400 |-----------| |-----------| 0300 |-----------| | free | 03?? |-----------| | reserved | 0200 |-----------| | stack | 0100 |-----------| | free | 004F |-----------| |shared/safe| 003A |-----------| | free | 0000 |___________| Check the ProDOS 8 reference manual for monitor and ProDOS zero page usage!(Trust me! Do this! They are not all free!) Aux. Memory FFFF _____________ | | | reserved | | | E000 |-----------| _____________ DFFF | | | reserved | | | |-----------| D100 | | | Free | D000 |___________| |___________| D000 BFFF _____________ | reserved | BF00 |-----------| | | | | ~ Free ~ | | | | 4000 |-----------| | Hi Res | | Page 1 | 2000 |-----------| | | | | | | ~ Free ~ | | | | | | 0800 |-----------| | Text | | | | Page 1 | 0400 |-----------| | | | ProDOS | | | 0200 |-----------| | aux/stack | (Free) 0100 |-----------| | ProDOS | 0080 |-----------| | aux/ZP | (Free) 0000 |___________| For HC.System on the IIgs. Main Memory: Quit code space at D100 now has HC.System's quit code. Aux Memory: 0800-0900 = IIgs break code.(I think I moved this to 6??? in the last version of HC.System.) 6000-6200 = Old Quit routine code. For anyone with any other // and disconnects /RAM using HC.System. Main Memory: Quit code space at D100 now has HC.System's quit code. Aux Memory: 6000-6200 = Old Quit routine code. If you are using graphics it is a suggestion that you should link at address $6000 or above. Gary gdesroch@slate.mines.colorado.edu From wulf@cip.physik.uni-stuttgart.de Thu Feb 25 11:49:08 1993 Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629) on Thu, 25 Feb 93 11:48:59 -0600 id AA11065 with SMTP Received: from OSCAR.PHYSIK.UNI-STUTTGART.DE by calvin.sfasu.EDU with SMTP (5.59/25-eef) id AA27951; Thu, 25 Feb 93 11:38:29 CST Return-Path: Received: by cip.physik.uni-stuttgart.de (MX V3.1C) id 24401; Thu, 25 Feb 1993 18:06:20 +0100 Date: Thu, 25 Feb 1993 18:08:32 +0100 From: Wulf Hofbauer To: hyperc-l@calvin.sfasu.edu Message-Id: <00968AC0.526800E0.24401@cip.physik.uni-stuttgart.de> Subject: Re: HyperC/Opsys memory map Status: R Sorry, Gary, there's a mistake in the memory map you gave for HyperC. The corrected map is (though I might overlook something, too :-) BFFF _____________ | ProDOS | BF00 |-----------| | Shell cmd | | line Bufs | BE00 |-----------| | | | | | File | ~ Buffers ~ | For | | HyperC | | | 9E00 |-----------| | C-Engine | | Stack | | | | ~ V ~ | They grow | | toward | | Each Other| 4000 |- ^ -| |-----------| | | | | Hi Res | | Your | | Page 1 | | Program | | | 2000 |-----------| |-----------| | | | | | opsys | | | | | 0800 |-----------| |-----------| | | | Text | | reserved | | Page 1 | 0400 |-----------| |-----------| |misc system| | vectors | 03F0 |-----------| | printer | | driver | | patch | | space | 03?? |-----------| | system | | variables | 0380 |-----------| | cargv[] | | array | 0340 |-----------| | argv[] | | array | 0300 |-----------| | unused | 02?? |-----------| |Shell/Opsys| | file path | 0280 |-----------| | unused | 02?? |-----------| | unused | | thrashed | | by clock | 0200 |-----------| | stack | 0100 |-----------| | free | 00F6 |-----------| |interpreter| | work space| 00C6 |-----------|-\ | free | | 004F |-----------| | |shared/safe| |- Can be changed, but will 003A |-----------| | partially be thrashed by | free | | opsys/interpreter/io-routines 0000 |___________|-/ fp routines I'd like to recommend to anyone not to use "free" memory for applications because other systems (like Opix ;-) may use some of it. It is much more easy anyway to leave address assignment to the linker. Zeropage adresses can't be assigned this way, and I won't recommend to use page zero for anything but temporary data storage (preferribly in the scratch space beginning at 0x00). Only system software may use this space, or address collisions are likely to occur. - Wulf