[Coco] new problem with unpack

[Wayne Campbell]

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