[Coco] new problem with unpack

[Wayne Campbell]

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/
>



-- 
The Structure of I-Code
http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code

decode
http://cococoding.com/wayne/