jimc@iscuva.UUCP (Jim Cathey) (08/27/86)
Help! I am trying to write an application program for my 512E Mac to permanently move the application heap from where it is normally to an extra 1MB of non-contiguous ram that I usually use as a non-volatile RAMdisk. I would prefer to leave the system heap where it is (perhaps bumping the size to encompass the range normally used by the application heap). Right now, all I get is a system bomb (no specified number as it doesn't get that far) when I try. Is there any way to do this? Must I settle for a "Mega-launch" application that chains another desired program with a temporary application heap up there? Mind you, I don't know if this is possible either, but the Switcher does something like this. Anyway, using MacsBug is no help since Tracing through this code gives different results than running it. When MemTop is moved the next PC shown is the SysErr routine. Manually putting it back into my program causes it to run normally with an exit to Finder, but with all interrupts trashed (no mouse, disk runs forever). Should I be looking at an INIT resource to do this instead? I would prefer an application. The current (off the cuff but you get the idea) sequence I am using is: NewZone of the 1MB area (which affects TheZone too) MemTop ApplLimit ApplZone HeapEnd Stack Pointer, CurStack StkLowPt (0 to turn off sniffer) ExitToShell What's going on here? Any information would be gratefully appreciated. -- +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! Spokane, WA ! IISSSS CC ! UUCP: ihnp4!tektronix!reed!iscuva!jimc ! II CCCCCC ! (509)927-5757 +----------------+ "With excitement like this, who is needing enemas?"
tim@hoptoad.uucp (Tim Maroney) (09/03/86)
In article <250@iscuva.UUCP> jimc@iscuva.UUCP (Jim Cathey) writes: >Help! I am trying to write an application program for my 512E Mac to >permanently move the application heap from where it is normally to an >extra 1MB of non-contiguous ram that I usually use as a non-volatile >RAMdisk. I would prefer to leave the system heap where it is (perhaps >bumping the size to encompass the range normally used by the >application heap). Right now, all I get is a system bomb (no specified >number as it doesn't get that far) when I try. Is there any way to do >this? You can do it, but you will have to patch in your own versions of Launch and ExitToShell. This is a good deal of work, but it can be done. Do not muck about with the layout of a process in memory! I assume you were going to do this from your note that you are disabling the stack sniffer. Many applications, notably a little thing known as the Finder, depend on the stack being right above ApplLimit. You are almost guaranteed to run into a lot of uanticpated problems and tricky debugging when monkeying with these parts of the operating system, so don't even try this if you are thinking about a weekend project. It will be hard, and you will have to know a lot about the Mac OS. There is also some very delicate assembly-language coding involved.... I don't know about your hardware configuration, but if it was purchased from somewhere else or built as a kit, and it is billed as only a RAM disk, I'd be willing to wager that you can't grow MemTop the way you are trying to do, or otherwise use it as other than a RAMdisk. -- Tim Maroney, Electronic Village Idiot {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa) These are the official opinions of the Vatican Council of Bishops.
jimc@iscuva.UUCP (Jim Cathey) (09/12/86)
In article <1053@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>Help! I am trying to write an application program for my 512E Mac to >>permanently move the application heap from where it is normally to an >>extra 1MB of non-contiguous ram that I usually use as a non-volatile >>RAMdisk. >You can do it, but you will have to patch in your own versions of Launch and >ExitToShell. This is a good deal of work, but it can be done. Do not muck >about with the layout of a process in memory! I assume you were going to do >this from your note that you are disabling the stack sniffer. Many >applications, notably a little thing known as the Finder, depend on the >stack being right above ApplLimit. > >You are almost guaranteed to run into a lot of uanticpated problems and >tricky debugging when monkeying with these parts of the operating system, so >don't even try this if you are thinking about a weekend project. It will be >hard, and you will have to know a lot about the Mac OS. There is also some >very delicate assembly-language coding involved.... The program (named BigHeap) now works just fine. As is usually the case, there are calls to the Mac OS to do just what you want, provided you know how to set up for them. The steps were (from memory, not paper): 0) ZeroScrap. I figured that this was ok for such a quick hack. Scrap is the only interesting thing in the Application Heap at this time but you must take care of it since Launch (called later, indirectly) looks at it. A proper fix would be to BlockMove it to new memory and relocate its pointers like Launch does. Thank you MacNosy. 1) Set MemTop to be 1MB, not a pointer to the top of memory. This is what Switcher does when tricking programs into using less memory. MemTop is what the Finder displays in About... Thank you MacNosy. 2) Move BufPtr to the top of the new memory. 3) Move A7, CurStackBase, and StkLowPt to the top of the new memory. I was hoping to continue to use the old 512K for stack so as to maximize the heap, but no such luck. See step #6. 4) BlockMove the ending (marker) block of the System Heap to the beginning of the new memory. 5) Patch the ending block of the System Heap to look like a NewPtr block of a size to cover all the space between where it is and the beginning of the new memory. 6) Call InitApplZone. This was the joker that didn't work at first. It starts the ApplZone just after the System Heap, and the top is put to some strange conjunction of BufPtr and A7. I think it uses BufPtr unless the stack is too low... hence step #3. Again, thank you MacNosy. 7) ExitToShell. Only because the stack has already been blown. Voila. A permanently moved Application Heap, with about 978K available for Switcher to use. I have only found three programs that don't work: TK!Solver (which probably doesn't work on 1MB anyway), PageMaker 1.1, and Excel 1.00. TK and PM just hang in startup, and Excel barfs out with a message about _Insufficient Memory_! According to MacNosy, Excel checks to make sure it is loaded into the BOTTOM 1MB and quits otherwise! I think Excel patches itself (maybe in the P-Code) and can't handle addresses larger than 20 bits. Shades of IBM PC here! Talk about schlock code. Take that, MicroSoft! No, I don't own it, and no, I don't use it. I was just looking around for programs that might take advantage of larger memory, and for popular ones to test. By the way, it was a three-weekend project, and yes there were many bugs. They were before I removed 50% of the code and did the job right. The RAM is homebrew and much extra work was needed to hide it from the auto-sizing code in the new ROMs. It is non-volatile over crashes and reboots -- just the ticket for development. I've only lost it once to a crash in 1 year. -- +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! Spokane, WA ! IISSSS CC ! UUCP: ihnp4!tektronix!reed!iscuva!jimc ! II CCCCCC ! (509)927-5757 +----------------+ "With excitement like this, who is needing enemas?"