[Coco] new problem with unpack

[Gene Heskett]

On Monday 28 October 2013 13:04:29 Wayne Campbell did opine:

> I know, from having this problem in DCom, that it happens because the
> parent procedure (unpack in this case)  has so much smaller a data
> memory allocation that RunB does not or cannot make a correct
> determination of memory requirement when a child procedure is much
> larger. To demonstrate, the data requirement for unpack (with
> getHeader) is 449 bytes. The rest are as follows:
> 
> readCode,lSort: 8475
> defVars,vSort,fSort: 7138
> buildSrc,dsSort: 8082
> instruction,hex$,DRPN: 11643
> 
> readCode is slightly over 8K, and instruction is well over 8K. unpack is
> not even 1/2 of 1K. I do not know if this is a RunB problem, or a shell
> problem, or a system problem. I do know it goes all the way back to OS-9
> Level 2 for the Color Computer 3. I never tried to run DCom on a CoCo2,
> because I had to sell my CoCo2 to get the CoCo3.
> 
> Anyway, the problem is about memory allocation. I have always thought if
> I could use one of the memory allocation system calls to increase the
> memory allocation of the parent procedure, it would eliminate the
> problem for the child procedures. However, I do not know enough about
> the system level to know if I am correct, or what the proper code to
> accomplish it would look like.
> 
> Can anyone shed some light on this?
> 
> Wayne
> 
> On Fri, Oct 25, 2013 at 1:11 PM, Wayne Campbell <asa.rand at gmail.com> 
wrote:
> > I got the changes made to decode and inserted the RUN and associated
> > statements in unpack. When I run it from the command line, I get the
> > following:
> > 
> > command: unpack elapsed
> > result ERROR #32: Memory Full
> > 
> > command: unpack elapsed #20K (or higher)
> > result: ERROR 43: Procedure not found
> > 
> > command: unpack elapsed #12K (through 15K)
> > result: PROCEDURE and DIM statements are printed, and
> > ERROR #201
> > 
> > I am using ErrorCodes to give me the error messages. In the third one,
> > the only one that actually gets as far as it does, there is no error
> > message displayed, only the error number. That tells me that the
> > system is returning the error, not the program.
> > 
> > Does anyone know what might be the cause of this, and/or what to do to
> > fix it? I know it isn't the program code. I have seen this problem
> > before, and never knew the cause. Re-writing the code sometimes
> > helped, but there's no problems in the code. I am bewildered.
> > 
> > Wayne
> > --
> > The Structure of I-Code
> > http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code
> > 
> > decode
> > http://cococoding.com/wayne/

AFAIK Wayne, the shell launching runb should accept the usual #8k or 
whatever memory allocation syntax to launch runb with.  I have used as much 
as $40k on my 2meg equipt coco3.  Or am I not grokking the problem?

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

I put aside my copy of "BOWLING WORLD" and think about GUN CONTROL
legislation...
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.