[Coco] decode 1.2.10

Sun Jun 11 09:57:53 EDT 2017

As I was testing decode I found two more items that are broken that were
not broken before. They are not major, but are important. The first is line
number references. decode is supposed to account for a procedure with no
line references, but it does not. It claims 1 reference for all procedures
that have none, and obviously, that reference is incorrect. The second is
more fatal. It is causing decode to end with a 67 (illegal argument) error.
It concerns procedures that have no Description area (DSAT). Again, I
thought I had that accounted for, but apparently it has become broken. I
will be correcting both of those issues as part of the 1.2.10 release since
they were not supposed to be broken to begin with. My goal is to have
1.2.10 devoid of any problems other than the TYPE statement issue, which I
am still working on.

My next post, when I have the data ready, will document the TYPE statement
issue. I will be asking for help to try and determine a way to deal with
it, though my current thinking is there's nothing that can be done about it
due to the lack of information contained in I-Code.

In a previous thread, a few years back, I had brought up an issue where
passing a BYTE variable was not being received by the called procedure as a
BYTE. At that time I was told that it is normal for all bytes to be
expanded to integers when being passed as parameters. I accepted this as
true concerning a BYTE variable being passed by value (byteVar+0), but I
had never had problems passing the variable alone before. Well, I wrote a
test program
, and lo and behold, the problem is not existing anymore. I was using VCC
back then, so I can only suspect that it has something to do with the
DIVQ_X problem, because I can now pass a byte variable (or a byte field in
a record) and the called procedure will receive it as a byte, not an
integer.

My test program is as follows:

PROCEDURE main
TYPE TST=path:BYTE; popen:BOOLEAN
TYPE TST2=path1:TST
TYPE TST3=path2:TST2
DIM phat:TST3

phat.path2.path1.popen:=FALSE
OPEN #phat.path2.path1.path,"main.b09"
phat.path2.path1.popen:=TRUE

RUN second(phat.path2.path1.path,phat.path2.path1.popen)
END
PROCEDURE second
PARAM path:BYTE; popen:BOOLEAN
DIM path2:BYTE

path2:=path
IF popen THEN
PRINT path
ENDIF
PRINT path2
CLOSE #path
popen:=FALSE
END

The program executes as expected and displays the path2 and path variables
as having the same value, and there is no error when closing the file in
the "second" procedure. This test began as two variables named path and
popen. When that worked, I decided to see what happens with compounded
records. Previously, the program would not get past the first level (ie, it
would pass the address of path2, not the value of path). This time I kept
increasing the difficulty by adding in more depth to the record. It still
correctly passes the value of the path field.

I add this to this thread only because I am so happy to see that the
problem no longer exists. Again, I think it may have been related to the
DIVQ_X issue in the emulator, but I don't know for certain.

On Mon, Jun 5, 2017 at 4:17 PM, Wayne Campbell <asa.rand at gmail.com> wrote:

> I added in the code to validate the data memory allocation, and am
> including that as part of the 1.2.10 release. It's time to see if I can get
> into cococoding so I can update the site. Aaron, if you are watching this
> thread, I may need your help to remember how to get in.
>
> On Mon, Jun 5, 2017 at 1:11 PM, Wayne Campbell <asa.rand at gmail.com> wrote:
>
>> That would be awesome. I will have to see if I can make time to be
>> available in the time slot for whatever show Steve wants to talk about
>> this. Saturday mornings (west coast, US) I am in Spanish class at my
>> church.
>> I may be able to be there, but it depends on what happens after class.
>> Sometimes I have to do church related things (I am on the church council).
>> If I can make the time I will be there when/if Steve wants to talk about
>> this subject.
>>
>> On Mon, Jun 5, 2017 at 12:37 PM, Salvador Garcia via Coco <
>> coco at maltedmedia.com> wrote:
>>
>>> Yes, agreed! It looks like we have yet another fantastic topic to broach
>>> on Steve's CoCoTalk! Salvador
>>>
>>>
>>>       From: D. Bruce Moore <bruce at gracenote.ca>
>>>  To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>>>  Sent: Sunday, June 4, 2017 10:33 PM
>>>  Subject: Re: [Coco] decode 1.2.10
>>>
>>> Wonderful summary! Cool project, Wayne!
>>>
>>>
>>> D. Bruce Moore, BA, BGS, Dipl
>>> www.AlternativeVocalTraining.com
>>> Distinguished Voice Professional – New York  Singing Teachers Association
>>>
>>> > On Jun 4, 2017, at 4:26 PM, Wayne Campbell <asa.rand at gmail.com> wrote:
>>> >
>>> > Hi Bruce,
>>> >
>>> > As I read your response it dawned on me that there is an entire group
>>> on
>>> > this list who wasn't here before, and that know nothing of DCom or
>>> decode.
>>> > I will create a background/history page to explain it in detail, and
>>> for
>>> > now I will do a brief history here.
>>> >
>>> > As most all programmers can attest to, when you first begin writing
>>> code,
>>> > you tend to not make backups of your source, and you also tend to lose
>>> the
>>> > only copy you have for a variety of reasons, the predominant reason
>>> being
>>> > that you simply deleted the file by accident.
>>> >
>>> > My language of choice, since I began programming, has been BASIC. When
>>> I
>>> > discovered OS-9 and Basic09, I knew that I had found the language I
>>> wanted
>>> > to program in. Like other programmers, I was not very good at
>>> remembering
>>> > to make backups of my source until I lost them enough times to learn a
>>> > lesson.
>>> >
>>> > For me it took a few years to learn it. If you are programming in
>>> assembly,
>>> > and you lose your source but still have a compiled executable, a
>>> > disassembly will give you a good approximation of your source and you
>>> can
>>> > use that as the starting point to rebuild your source. All you have to
>>> do
>>> > is remember your variable and label names, and where your code may have
>>> > differed from the disassembly output. In Basic09 (or any BASIC that
>>> doesn't
>>> > compile to object code for that matter), you were not given that
>>> option.
>>> > Even if you had the I-Code module, you could not easily recover your
>>> source
>>> > code from it. For the most part you were relegated to starting all over
>>> > from scratch and rewriting your code from the beginning. I noticed
>>> that I
>>> > never was able to duplicate my code exactly, as the new modules
>>> differed
>>> > from the original.
>>> >
>>> > In early 1991 I decided that someone needed to write a program to
>>> recover
>>> > source code from a Basic09 I-Code module, and since no one else was
>>> doing
>>> > it, I would. I named the program DCom - Basic09 I-Code De-Compiler. I
>>> > worked on that program from November, 1991 until approximately April,
>>> 1993.
>>> > At that time I had to sell my CoCo3 and everything that went with it,
>>> and
>>> > all I had left was a 3-inch binder of the source code and other related
>>> > Basic09 information. I managed to keep that binder until approximately
>>> > summer, 2009, when I was now in a position to get back to it.
>>> >
>>> > I discovered quickly that DCom was a kludge. It was a miracle that the
>>> > program worked at all, and in most cases it didn't, or didn't work
>>> well. I
>>> > had learned alot more about programming and program structure over the
>>> > years, and decided that I needed to rethink the program and start
>>> over. The
>>> > program became decode, and has progressed to where it is now. I have
>>> had
>>> > some help along the way, notably from Aaron Wolfe who supplied me with
>>> a
>>> > routine to speed up the searches for counter identification and helped
>>> me
>>> > with file search routines.
>>> >
>>> > I had to stop working on it again in 2014. For the past three years I
>>> have
>>> > left it alone pretty much, though I have kept up with the list and the
>>> > efforts to make our beloved CoCo more usable in the 21st century.
>>> Since I
>>> > have been able to return to work on decode, I have decided to try and
>>> take
>>> > the program the next step by correcting the display issues, adding a
>>> new
>>> > feature for preserving user options, and start thinking about the next
>>> step
>>> > in the evolution of the program.
>>> >
>>> > One of the things that occurred to me before is that I really needed to
>>> > come up with a name that better identifies the program with its
>>> purpose.
>>> > Since I-Code is "packed" in Basic09, I reasoned that the opposite is
>>> > "unpacking". unpack is the name the program will have when it reaches
>>> the
>>> > point in development where it really becomes useful. That point is
>>> where it
>>> > is able to deal with merged module files and can identify modules that
>>> are
>>> > object code, and files that are not executable.
>>> >
>>> > I have already written that code, several times, but decode (in its
>>> present
>>> > form) cannot be used with the unpack front-end. I am thinking it will
>>> > require a rewrite of both decode and unpack to make it work. Those
>>> details
>>> > are for another day, and for the history of the program document that
>>> will
>>> > be a page on the unpack-decode site.
>>> >
>>> > I hope this answers your (and anyone else's) questions regarding what
>>> > decode is and what purpose it serves. Oh, and it is written in
>>> Basic09. I
>>> > am certain that if I could write it in assembly I could make it run
>>> faster
>>> > and be smaller than it is now, but I do not know assembly (or C) well
>>> > enough to do that, and I prefer writing it in Basic09.
>>> >
>>> > Thank you for your interest, and if you or anyone else has questions
>>> about
>>> > the remaining issues the decode engine still has regarding I-Code, ask
>>> and
>>> > I will write another post detailing those issues.
>>> >
>>> >
>>> >> On Sun, Jun 4, 2017 at 5:42 AM, D. Bruce Moore <bruce at gracenote.ca>
>>> wrote:
>>> >>
>>> >> Wayne,
>>> >>
>>> >> I took a look at your Decode page and I am not quite sure what’s
>>> going on.
>>> >>
>>> >> An intro, explaining what it is and does, in layman’s terms, might be
>>> a
>>> >> nice addition.
>>> >>
>>> >> Cheers!
>>> >>
>>> >>
>>> >>
>>> >>> On Jun 3, 2017, at 11:08 PM, Wayne Campbell <asa.rand at gmail.com>
>>> wrote:
>>> >>>
>>> >>> I have been working on decode for the past few days. I have gotten
>>> much
>>> >>> done to correct display issues and add support for preserving user
>>> >> options.
>>> >>> The new version is 1.2.10. When I can remember how to connect to
>>> >> cococoding
>>> >>> via telnet (unless that has changed) I will upload the updated pages
>>> and
>>> >>> new version disk images there.
>>> >>>
>>> >>> I had prepared a video to showcase decode, but when I went to upload
>>> it
>>> >> to
>>> >>> youtube, iSpring Free Cam8 crashed for no apparent reason. Because I
>>> had
>>> >>> not saved the project, I lost the video. I am back to square one and
>>> have
>>> >>> to make a new video. I will post here when I have the video made and
>>> >>> uploaded to youtube.
>>> >>>
>>> >>> --
>>> >>> Wayne
>>> >>>
>>> >>> 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
>>> >>> https://pairlist5.pair.net/mailman/listinfo/coco
>>> >>
>>> >>
>>> >> --
>>> >> Coco mailing list
>>> >> Coco at maltedmedia.com
>>> >> https://pairlist5.pair.net/mailman/listinfo/coco
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Wayne
>>> >
>>> > 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
>>> > https://pairlist5.pair.net/mailman/listinfo/coco
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>
>>>
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>
>>
>>
>>
>> --
>> Wayne
>>
>> The Structure of I-Code
>> http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code
>>
>> decode
>> http://cococoding.com/wayne/
>>
>
>
>
> --
> Wayne
>
> The Structure of I-Code
> http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code
>
> decode
> http://cococoding.com/wayne/
>

-- 
Wayne

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

decode
http://cococoding.com/wayne/