[Coco] new problem with unpack
Wayne Campbell
asa.rand at gmail.com
Tue Oct 29 20:35:19 EDT 2013
Unpack passes three records plus a few other variables to each of the other
parts. I suppose I could try using the SHELL command in Basic09 to run
those, but I don't think I can pass parameters that way.
Wayne
On Oct 29, 2013 8:22 PM, "Bill Pierce" <ooogalapasooo at aol.com> wrote:
>
> Wayne,
> Do your module pass data beteween them? If not, why not fork something to
> another process space?
>
> Bill Pierce
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Webmaster of The TRS-80 Color Computer Archive
> http://www.colorcomputerarchive.com/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com
>
>
>
>
> -----Original Message-----
> From: Wayne Campbell <asa.rand at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Tue, Oct 29, 2013 8:16 pm
> Subject: Re: [Coco] new problem with unpack
>
>
> 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/
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
More information about the Coco
mailing list