[Coco] new problem with unpack

Wayne Campbell asa.rand at gmail.com
Tue Oct 29 20:15:03 EDT 2013


This explanation helps me make better sense of things. So, I need to have
more memory than I have. I will have to think about this. I don't know that
I can reduce either, but I may have to take four procedure files and turn
them into eight. I am not sure at all how easy that will be to do, even if
I try to go only to six.

Wayne



On Tue, Oct 29, 2013 at 3:30 PM, Greg Law <glaw at live.com> wrote:

> These numbers don't quite look right to me because you're not taking into
> account the 8K MMU block size and you're not accounting for
> RunB+Inkey+SysCall+gfx2 being linked into the process space. Assuming
> runb+inkey+syscall+gfx2 are merged into a single fileyou'll end up with
> something more like this:
>
> RunB = 12,185
> gfx2 = 2250
> inkey = 95
> syscall = 99
> Total = 14,629
> Allocation = 16K
>
> Assuming unpack has a 2,733 byte module size, this is one 8K block. So
> when you run unpack, it loads unpack into one 8K block and loads and links
> runb+inkey+syscall+gfx2 into two 8K blocks for a total allocation of 24K.
> If it needs to load and link readCode with a 9,054 byte module size, this
> tacks on another 16K block for a total of 40K.
>
> Now you need 8,475+451 bytes for data and runb needs 4K for data so this
> is another 16K block for a total of 56K.
>
>
> -----Original Message----- From: Wayne Campbell
> Sent: Tuesday, October 29, 2013 1:07 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] new problem with unpack
>
>
> I used vfy and ded both to change the data space requirement for unpack. I
> used vfy first, then when it showed the 215 error, I started again and used
> ded. It resulted in a different error (215 bad pathname). Using decode, I
> can tell that I did increase the storage size field to 8192.
>
> I have put together a list of the modules in memory at once, including
> their module sizes and their data sizes. I am not using formatting in this
> post, so you will likely need to copy the table below to a text editor that
> allows you to see mono-spaced text. I believe that the last row (C) proves
> that I am not using up the entire 64K space, but I am still not sure.
> Perhaps someone else can tell me if I am going over the limit (remembering
> that the 64K space includes whatever is copied from the system, as well as
> the merged RunB modules).
>
> RunB is merged with Inkey, SysCall and gfx2.
>
> Wayne
>
> 1 unpack/readCode
> 2 unpack/defVars
> 3 unpack/buildSrc
> 4 unpack/instruction
> A module size
> B data size
> C total size
>
>      1       2       3       4
>   =====   =====   =====   =====
> A   2733    2733    2733    2733
>    9054   10460    5526    9848
>   =====   =====   =====   =====
>   11787   13193    8259   12581
>
> B    451     451     451     451
>    8475    7138    8082   11643
>   =====   =====   =====   =====
>    8926    7589    8533   12094
>
> C  11787   13193    8259   12581
>    8926    7589    8533   12094
>   =====   =====   =====   =====
>   20713   20782   16792   24575
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>



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

decode
http://cococoding.com/wayne/



More information about the Coco mailing list