[Coco] new problem with unpack

[Greg Law]

There are a few other things you might try to split the modules into 
physically separate processes without resorting to using temporary files for 
intermediate output.

1. Have the first part of the application (decode?) write all output to 
standard input and the secondary/tertiary applications read from standard 
input and write standard output. This way you can deocde ! unpack ! split ! 
prettyprint >module.bas via fast pipes without touching disk for the 
intermediate results.

2. If you need to feed a secondary app data and get decoded data back out in 
a loop (e.g. for DRPN), set up a named pipe. I think (someone correct me if 
I'm wrong here) named pipes were carried over into NitrOS-9, so you could 
open something like /pipe/dprn in read+write mode in both processes and 
communicate via a predefined protocol over the pipe. This way the two 
functions are separate processes with their own 64K process space. 
Communicating over a pipe this way is slower than calling a function, but it 
is significantly faster than disk.

-----Original Message----- 
From: Wayne Campbell
Sent: Wednesday, October 30, 2013 5:42 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] new problem with unpack

I have been able to get unpack to work more reliably, but there is still a
major malfunction. I split readCode into two procedures, readCode and
lineNums. I also removed the code for all the counters I was tracking in
decode. This got around the problem as far as beginning the unpack is
concerned. Now I can run it with a #16k modifier and it will go all the way
to instruction before bombing.

The problem with instruction is that it and DRPN (currently) are both in
memory at the same time, and DRPN is being called for each instruction line
being built by instruction. Because the data memory requirements for each
call for a 8K block each, there isn't sufficient memory left to allocate
enough for both procedures. I am still thinking about what to do. I did
remove the code for creating the .B09 source code file. When unpack works
completely, you will be required to redirect stdout to a file.

DCom 1.0 provides a possible solution. I don't have that code anymore, but
what it did was simple. DInstr (the equivalent of instruction) wrote all of
it's output to a file. DRPN read that file and parsed it so the resulting
output would be source code. It worked as a standalone procedure. I
modified it in DCom2.0 to work within DCom as a part of DInstr. Those two
files and hex$ were all packed and loaded together, and it worked. I think
it is the bug-fixes I have made to DRPN as a result of decode that may be
part of the reason it won't work now.

I may try separating DRPN out to work apart from instruction. It will mean
adding the output file back in, but with changes, and then changes to DRPN
to handle opening the file and reading it's input from there. I do not know
how much this will increase the time it takes unpack to do its thing.

Wayne