[Coco] DCom 3.5 source

Wayne Campbell asa.rand at yahoo.com
Tue Sep 29 13:38:22 EDT 2009

Each "part" file is merged procedures. The list is:

DCom - DCom (main procedure) and DCIA
DCP1 - DData1, DData2, DComplex and DVars
DCP2 - DMatch, DSort, ZSort, CSort, VSort and DTypes
DCP3 - DLNums, RSort, LSort and DPrint
DCP4 - DInstr, DRPN and DHex

You should not remove the REM statements as a whole. If you want to de-compile DCom, simply leave the REM statement as it is. If you remove the REM keyword and pack the procedures, DCom will not decompile itself.

REM line:="@8y at aa"

is changed to"

line:="@8y at aa"
to prevent DCom from self-decompile.

The syntax for running DCom is:

dcom pathname opts

pathname is any valid path or filename, such as:


opts are:

-o is suppress output file and print to stdout only.
-v is dupe output to output file and stdout
-, ?, -?, or no params displays the built-in help

The sort routines were my first attempt at trying to create a fast sorting algorythm. With so many different things to sort, I ended up needing different sorts. I want to try to make a better sort for unpack. I never did like the way I did it in DCom.

You cannot run any part of DCom by itself. The main procedure loads each part file in its turn, and executes each procedure in its turn:

DCP1: DCom executes DData1, DData2, DComplex and DVars
DCP2: DCom executes DMatch, DSort (which calls the other sorts) and DTypes
DCP3: DCom executes DLNums, and DPrint. (the sorts are run from DLNums)
DCP4: DCom executes DInstr. DRPN and DHex are called by Dinstr

As each procedure is completed, DCom KILLs the procedure, and when the part is done, DCom unlinks the first procedure in the part so it is removed from memory.

Because DCom takes so much time to perform its task, I included print statements (to stderr) so you can have a clue where in its execution DCom is. In the default mode (the way the source is), It prints a character (or 2) showing which procedure is being executed (like D1 for DData1), and a period for each file created (In DData1 and DData2, the output is D1.. and D2..) That is how I know where it is getting hung. If it made it to DComplex, it would print C on the screen. It never gets that far.

If there's any other info you need, ask me. I am trying to finish up the documentation to the program, and when I'm finished with that I am going to try to debug DCom again.


From: Robert Gault <robert.gault at worldnet.att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Tuesday, September 29, 2009 5:57:34 AM
Subject: Re: [Coco] DCom 3.5 source

Wayne Campbell wrote:
> I have finished typing in the source code to DCom 3.5. I have uploaded it to source forge. I'm not certain what is going on with it, though. When I wrote it, it ran, and worked, at least as far as decompiling itself on my CoCo3 was concerned.
> It loads and packs without error, but for some reason it reports a 201 error (illegal path number) while running DData2. If I specify no output file (-o option), it doesn't error, but it hangs, as though it's stuck in a loop. I am going to try to figure out what is wrong with it, but I've been working on the new version (called unpack), so I'm not sure how much effort I want to put into fixing DCom.
> If anyone wants to look at the code, you can find it on sourceforge.
> http://sourceforge.net/projects/dcomb09/files/
> I'm going to be putting the source for version 3.1 there also. There are major differences between the two versions, and I want to preserve both versions. The source to 3.1 is DCom generated. I used 3.1 to decompile itself a short time ago. The 3.1 source will be on sourceforge in the next week or so.
> Wayne

I downloaded your code and found that DCP4.B09 is three Basic09 source code files. I think that DINSTR is the main module and removed the REM but get a parameter error at $B09  IF verbose THEN   when trying to run the program.

What is the correct syntax for using the program?

Coco mailing list
Coco at maltedmedia.com


More information about the Coco mailing list