unpack-decode

04 April 2014

I have the setOpts dialog completed, but there is an issue with the colors that I am having difficulty in rectifying. I have uploaded the source code for anyone who wishes to take a look and see if you can tell what I am doing wrong, or not grokking correctly.

setOpts Source

setOpts Pretty-Print

27 March 2014

I have been busy creating the options dialog that will be used in decode. I am almost finished with the development phase, and will be inserting it into decode in the next few days. This is going to make things much more simple and intuitive than it was previously. I am going to try to make a video and put it on youTube. I'll post to the list if I am successful. I am still working on the color picker (it's not graphic) so that part won't show much.

I have been giving it alot of thought, and have decided that since I am having difficulty making decode work in unpack, that maybe I should try to make unpack fit decode. For now, I will continue to call it decode, but when the ability to handle merged module files is added I will rename the program unpack. Until I know how to make the program smaller and work under Level 1, this will be a CoCo3/NitrOS-9 Level 2/3 program.

22 March 2014

It has been a few months since my last update. I have been hard at work during this time, however, and the effort has benefitted me greatly in my understanding of I-Code and how it is arranged. The SWTPC Files are completed now, as much as I can do with it at this time. I hope those that who peruse it will find it useful.

I was able to successfully reconstruct the source code for the game New Trivia. By that I mean that all five I-Code modules have been decoded and the resulting source code, when packed with Basic09, will produce a module 100% identical to the original module. decode did not do all the work, obviously, but I have made significant changes to the output files generated by decode, enabling me to focus on getting the syntax and precedence right. The output of the first pass is as close to human-readable I-Code as you will ever see. This pass now produces a file named <modulename>Raw.txt. The other files generated by decode include:

     
  • <modulename>Lines.txt
  • : Line References
         
  • <modulename>Vars.txt
  • : Variable References
         
  • <modulename>VDT.txt
  • : VDT Validation
         
  • <modulename>DSAT.txt
  • : DSAT Validation
         
  • <modulename>.B09
  • : Basic09 Source Code

    I am also adding code to allow decode to deal with non-executable and non-I-Code files. Instead of choking, decode now pops up a dialog notifying you of the problem and asks for a choice of new filename or [ENTER] to quit. In addition I am changing the way the displays work. Instead of the as-you-go approach I used initially, I am adding user-definable settings. By default, the dialog will open when you first run decode. From that dialog, you will be able to have decode use the settings as they are (default or create a user-default) and not show the dialog at startup. The settings are not all defined yet, but they include:

         
  • View Processes (toggle)
  • : The following are ignored by decode if this option is toggled OFF.
            
  • Instruction Decode (toggle)
  • : View Windows is toggled ON by default,
            
  • Line Reference List (unnumbered) (toggle)
  • : with Instruction Decode ON and the rest OFF.
            
  • Line Reference List (numbered) (toggle)
  • : All settings are saveable as user-defaults.
            
  • Variable Reference List (unsorted) (toggle)
  • :
            
  • Variable Reference List (naming) (toggle)
  • : You can choose which processes
            
  • Variable Reference List (sorted) (toggle)
  • : you want to see.
            
  • VDT Validation (toggle)
  • :
            
  • DSAT Count (toggle)
  • : If you toggle all windows OFF
            
  • DSAT Validation (toggle)
  • : decode toggles View Processes OFF.
         
  • Source Output (toggle)
  • There will be other options as well. All of this will be explained in detail in the new document I am writing to be the user manual for decode.

    04 December 2013

    I am sorting through the disk listings for the SWTPC OS9 archive. I thought I would let everyone who visits this site, and who has an interest, see the progress I am making by putting it on this page.

    30 October 2013

    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 DCom 2.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.

    I have not uploaded any changes to this site. I will post to the list when I have something new for you to download.

    28 October 2013

    As I have been trying to understand the memory problem, I have also noted a couple of spots that needed to be changed. First, not everyone wants to use ErrorCodes to see the error messages. If you dond't have it in your CMDS directory, unpack will likely spit out ERROR #216 no matter what the original error was. To correct this, I have added a boolean called useErrs. It is set TRUE by default. You can change that to FALSE and it will just print out an error number, like the system does.

    Second, I'm sure some of you are wondering what the last line of the error report is all about. That is my own internal error system that allows me to know what procedure the error occured in, as well as about where the error occured. I decided that this info is not always needed, so I added another BOOLEAN called debug. It is set FALSE by default so users will only see an error message. If you want to use the internal error tracking, simply change the debug variable from FALSE to TRUE.

    I have also been playing around with the "shell" version of unpack (the one that doesn't really do anything, but says it does). I have seen that this is the perfect framework for a few other utilities. I have made one version called showMods. What this does is simply tell you what modules are merged in a merged-module file. It also tells you if the module is Object-Code or I-Code. Along with that, and remembering a program called modBuster that I no longer have and have not found a copy of, I made a version called unmerge. When completed, it will not only tell you if the module is Object-Code or I-Code, but it will also make a copy of the module and place it in the current directory, and will repeat this process for each module found in the file, like modBuster. Unlike modBuster (at least the one I used to have), it will correctly set the file attributes for each file created so that they are executable from the start. No more having to run attr after separating all the modules.

    I will be uploading the new unpack disk image, including all these routines for you to play with, today.

    25 October 2013

    Everything was going so well. The process of modifying the code to work in unpack went without a hitch. When I loaded each file into Basic09, I waited for errors. I did get two, one in readCode (decode's new name for unpack) which was just a DIM statement needing to be commented, and one in buildSrc, where I had overlooked one instruction statement that needed to be commented. Everything packed without error. I was ready. I typed 'unpack elapsed', and waited to see the first DIM statements. Instead, I got Error#: 32 Memory Full. I groaned. I remember this problem. It took me awhile to get DCom to run properly because of this problem. It seems the parent procedure is not being given enough RAM because it's data size requirements are less than the modules being called have. Of course, with DCom, there were all kinds of issues, so this was just another one. Eventually I did get DCom to run without erroring out this way. I haven't had this problem in decode, because decode was the main module, and each module chained cleared all the memory for its own use.

    I have made a new unpack.os9 image. It contains all the source, all the packed modules, and the ErrorCodes module if you don't have it already. If anyone knows how to deal with this error, I would love to learn!

    24 October 2013

    I dug unpack back out, cleaned it up abit, and made sure it is ready for decode to be inserted into the program. Now that I have it ready, I decided to let those of you who wish to play around with it. It doesn't do any decoding at this point. All it does is handle the file handling and prep work. This includes dealing with non-executable files and non-I-Code modules. It also handles dealing with merged module files. Play with it and see what you think. The image only contains the one source-code file and the one executable file for unpack. Things have been slowing me down, but I am still ready to insert decode. By next week unpack will be ready for initial release.

    23 October 2013

    I have been spending time working on documentation for dealing with the output of decode while I work on the program. Understanding decode is well underway now, with a second page to be added soon. I have also added a new page that chronicles the load errors found in every RiBBS module that has them.

    14 October 2013

    Now that decode is working as expected without displays, it is time to make the next change that will finally make decode ready for insertion into unpack. This involves removing the initialization code and module header code (this is handled in unpack and decode need not concern itself with it), changing the chain code so that unpack will call each part internally, and changing the initial parameters to decode so that it accepts the parameters unpack will be passing to it. In addition, there is now need for a REAL pointer so that the file pointer for merged module files is correct. These include the input file pointer and the VDT and DSAT offset addresses for the module being decoded. When this is completed and inserted into unpack, the first release of unpack will be ready.

    12 October 2013

    Help with decode is here. Click the 'understanding decode' link in the box to the right. Yesterday I began work on a new page on this site that deals with how to understand what decode's output is, how to use the files it generates to help deal with reconstruction of TYPE statements and how to connect parameters between procedures. I will be updating it over a period of days until it is completed. If anyone has questions or comments, you can post a message to the cocolist, or you can email me directly if you have my email address. (Use the cocolist to find my email address if you don't have it. It is part of the message header for every post I send to the list.)

    11 October 2013

    I have completed the removal of display code from decode and tested it, and it works. I have not uploaded a copy of it because this version is for use in unpack. It does bring me another step closer to having unpack ready for it's initial beta release. I will be working on this over the next few days, so by next week I should have the first beta release version of unpack online.

    05 October 2013

    I successfully commented out the display code in decode today. Test runs indicated that it was not much faster, if at all, than with the display code. Of course, I have not begun to comment out the unused variables yet. I wanted to be sure it would still decode a module before taking that step. This way I isolate each step so that if something goes wrong, I know what is not the problem.

    I have interesting news today. I downloaded VCC and installed it. I inserted my boot floppy image that I boot in MESS with in FD-502 drive 0 and the hard disk image I use to work with in MESS in HD drive 0 and ran the emulation. I did set the configuration to use the OS9 keyboard. It ran flawlessly, and I didn't have a single issue. Oh, and I did not download the 3.2.8 vhd image that was on the site.

    I decoded elapsed and connect, and both tasks were done much faster than in MESS. Two things about that. I am using the Disto RTC (because the Cloud9 version didn't work on my laptop, and I have not built a new boot disk to use the Cloud9 RTC), and this computer has 640 megs of RAM. The thing is, the 128 meg chip is 133ns and the 512 meg chip is 143 ns. I don't know if either of these things may have contributed to the slowdown I have experienced with MESS since moving it to this computer. VCC clears up the fact that it is not the clock or the memory, unless MESS has an issue with them. That said, this computer loads applications as slow as molasses for a 1.6 GHz P4. My laptop was a 1.5 GHz Celeron M and it was faster than this P4.

    I will be creating a batch file to give me times so I can determine the actual decode times. I will be running both versions of decode so I can get real numbers about the times.

    04 October 2013

    Version 1.1.6 is now ready. All changes I spoke about in yesterday's post are done. Now that I have reached this plateau, I can begin to work on removing display code for unpack's version of decode.

    03 October 2013

    I added a hit counter today, thanks to Bill Pierce. I have also followed the blog style by making my entries newest first. This way it may be easier for people to follow what's happening here.

    I corrected Using_decode.txt. I wrote to copy all files in the CMDS and DATA directories to your primary CMDS directory, not CMDS and DATA directories, so I made that correction.

    I now have the TYPE, DIM and PARAM statements in decode organized better. I found that the problem I had when I first tried to comment out the display code was due to the fact that I changed the initDB and procData files to not include the display related variables I was storing in them, and removed the color record also. I changed the code back to using the original initDB and procData files, and the problem cleared up.

    I now have the code ready to try again. Since I rearranged the declaration statements, I am calling this version 1.1.5a. Before I do any display code removal, I am going to rename the output files (VDT and DSAT) to .txt instead of .b09. I am also going to include the necessary code to print out the vars file (like readVars does now), also with a .txt extension. I am also going to make the DSAT file include the relative offsets to the DSAT for each entry, and include the variable names for the validated entries. Once those changes are made, I will increase the version number to 1.1.6 At that stage I will begin to work on commenting out the display code, and preparing decode to be used in unpack.

    02 October 2013

    I have added decode_corrections.zip in order to help those who are trying to understand decode's output, and to help them find and correct the TYPE, DIM and PARAM statement errors that may be produced by decode. The archive is all text files, so you don't need any special software, other than a text editor, to read them. Start with explanation.txt. It will guide you through the other files.

    Now that I have gotten a better handle on CSS, I can start to make this page look better. Look for changes to come.

    Wayne