The MShell Blog P8
*************************************************************************************
The Long And Winding Road... (11/17/2014)
I have been really busy with the MShell code in the past month or so. In fact, too busy to even add to the MShell Blog :-)
A lot of things have been accomplished in the past 2 months. Mshell can now copy from the DW4 server PC drives to the Coco's OS9 drives. It can also copy from the OS9 drives back to the DW4 PC server's drives! This gives MShell another first in the OS9/Coco3 world. Mshell has become the proving ground to what OS9 can do. All these things were possible in the 80s, but no one ever tried. There were only a small handfull of programmers that were pushing OS9 to it's limits. Had more programmers done this... and published their works, Tandy may have taken more notice of the Coco as a valid developement environment, and let Microware carry on to upgrade OS9 to Level 3. This (IMHO) would have extended the life of the Coco. Had Tandy seen the possibility of more $$$, they would've continued with the Coco 4 project which we now know was actually in the developement stage when Tandy dropped the Coco line.
Anyway, enough about the woes of Tandy.
Mshell now has enough features that I would consider it a working file manager, not just a beta experiment. All the theories of "virtual memory", "fragged subruotines", and "chained and forked modules" have been proven. All packaged in a nice GUI for a pleasant working environment. I have about 6 or 7 more small routines I want to work into MShell's packed memory constraints, but the file system is becoming more stable every day. The little "quirks" are slowly going away, one by one.
I think I finally got a handle on how the stack keeps getting overwritten every time I try to add something new. MShell's memory limits are tricky to work with. If you add one item in one place, it will overflow the stack in another. Each module and subroutine has to keep a balance with it's own stack and the concurrently running module's stack. Even though the fragged subroutines share the direct page and global variables with the main module, each unit keeps it's own stack for local variables and importing from the direct page and global variable. This stack can grow quickly when working with long strings such as filenames and pathlists which is the meat of MShell. When the main and sub are both passing long strings, the two stacks can over run each other therefore wiping out the stack. Then it's "CRASH, BOOM, BAM.... <RESET>". So I've now started trying to eliminate long strings when possible. It seems to be helping.
I would post more in this blog enrty as a lot has been done, but I have another project which needs my attention at the moment, so I have to cut this short. I will be back in a few days to finish this progress report as I have a lot to report. I have posted the new MShell version for you to download and try. Please keep me posted on anything you find not working properly.
Enjoy!
B.P.
*************************************************************************************
When does an MShell become a "shell"?... (02/12/2015)
Well, I finally got around to starting the 'rewrite' of MShell. Over the past couple of months, I've stabalized the 'release' version of MShell to the point that I don't think there are many problems, but you never know. But now I have a 'templet' started for making MShell operate in a completely different way.
The first thing I wanted to do was to make the graphics handler (MS1Grf) to be the main module (parent process) and not the product of the file manager. The idea is to make MS1Grf into a real shell. Since this module handles all text printing, menu generation, and screen drawing, and is used by every module in the MShell suite, it needs to be loaded first. All other modules will be forked from MShell (formally MS1Grf) or chained from the current running module. In trying an experiment to see if the file manager could chain another process, I found that the graphics handler died and had to be restarted by the process. This would not do. So by making the graphics handler the main, I can chain any of the other processes and never lose the graphics handler. Since all other modules will be a product of the first module run after MShell, all modules will inherit the first modules pipes to MShell for text and graphics.
I now have a prototype of this running and see no problems. There were actually only a few changes that needed to be made to the file manager and the graphics handler to make this work. Originally, the filemanager was started and created the 640x192 hi-res screen, then forked the graphics handler with the needed pipes to make it all work. Now, the graphics handler is started first, creating it's own hi-res window, inits the graphics, then forks the file manager. Now when I chain another process from the file manager, the file manager dies gracefully and the new process runs and there's no screen interruptions. If the new process needs a different sceen, it will erase the old screen and draw the new one. I have this going on the current release version and all is working well.
I have a bad habit of taking everything I like in creating the new MShell templet and adding it to the release version if possible. Since the templet has no real functionality at the moment but to draw the MShell screen, the only way to test new functionality is to add it to the working version.
In making the new templet, I've come up with better ideas on how to make each module independant of the others. Formally, MShell held all the text for the menu system in arrays. Since there are many modules planned, there will not be enough room to do this as I add modules with different menu needs. I've come up with a plan to use dynamic menus in which when a module loads, a control code is sent to MShell which then dynamically loads the menu system for that module. It will add a little more disk activity to switching modules, but in the new system a lot of the old disk activity is being minimized so maybe this will not slow down the operations as much. Another thing I'm attempting to do is to move a large chunk of the global variables out to virtual memory. This will allow any chained module to have access to common variables used in all modules and also allow the new module to know the status of the screen from last module. The idea is using one 8k buffer with a globally known group and buffer number that all modules can map in dynamically. Since OS9 only kills a get/put buffer by software command, I can leave the buffer active while MShell is running and map it into any process as needed. When the process ends, the buffer is mapped back out and the actual high memory location is updated with any changes so that when a new module maps it in, the buffer contains the current state of the system. It all sounds kind of complicated, but in reality, it's really simple. Even the large dynamic data buffers can be implemented this way making any listings I want to pass to a new module available without reloading the data. The more I work with these get/put buffers, the more I see that Microware was actually looking into the future of virtual memory and what it could be used for.
The whole concept boils down to:
First, MShell is loaded, the graphics, fonts, and pointers are initialized along with the Hi-Res graphics screen.
Second, the MShell logo screen is displayed while the 1st module is loaded and intitialized.
Third, the first module will be a "System Control" module in which to set various system parameters (colors, mouse etc), enumerate the drive system, initiate DriveWire4 if available, initiate the virtual memory buffers, set the default screen mode, and most of all, a module menu in which to select the module you want to run. This system module will hopefully be available from within any other module. In fact, I hope to be able to jump to any module at any given time.
Fourth, once a module is selected, the system module unmaps all buffers and chains the selected module.
Each module will have the virtual memory buffers available as well as the ability to use fragged subroutines. Some modules will not use the fragged subroutines due to the data space needed for the module, but most of these can be forked from the running module as a sub, then returning to the running module. This way, buffers are not lost and the screen remains untouched.
B.P.
*************************************************************************************
The 'new' MShell templet... (05/10/2015)
I took a short break from the MShell code (if you can call it that), and worked on the "BootMajik" project for a bit (or two). Since BootMajik will eventually be an MShell module and uses much the same interface, I started seeing where a lot of the MShell core module had to be made more "universal" so that any feature that any future module might add, MShell would be ready for it. Such as setting MShell up with dynamic menus that change as each new modules is run, dynamic database structures in the virtual memory routines so that a new module can change the format of how the database is laid out, and many other things that a new module might bring into the picture.
I stripped the MShell code down to it's "core" functions (once again!), and started working on making it completely independant of any module code. Any changes in how the screen is to be displayed i.e. number of panels, menu contents, error messages, etc, are now being either piped to MShell from the module, or loaded as the module starts up by piping a command to load a new configuration file which resets the menus, screen panels, and message system to fit the new module. At the moment, this whole theory of operation is just in test mode, but I have the dynamic menu systems (for the most part) working. I'm having one small problem with some menu items displaying "spaces" after the item name, but I know it's got something to do with how I'm clearing the static array system and reloading it with the new menu items, but I will see the error eventually. It's really just a small thing, but I've found that it's those small things that develope into major crashes later if not taken care of early.
When a new module is selected, the current module will "chain" the new module, therefore "killing" the old module. The new module automatically inherits the old module's "pipes" to Mshell. The first thing the new module does is send a "module change" command, which consists of 2 variables... first, the number of "panels" the new module requires and second, the name of the new module's config file. MShell then loads the config files which consists of a structured list of "number of menus", "menubar names", followed by a structured list of the new menu items with their screen locations and "menu window" sizes. MShell then initializes the menu arrays with the new data and does a screen refresh, displaying the new screen. From that point, the new module resumes it's operation. At first I thought this would be time consuming, but found the disk access and setup time involved only takes a second or two. Not bad for a 2mhz 8-bit machine :-)
I'm now working on setting up a second test module to make sure the "chaining" proccess is seamless. The whole process of changing modules has to be invisible to the user. Just a quick screen refresh and they're on their way. The next step will be getting the virtual memory routines in a more "generic" mode. If my idea for the vmem routines work, this whole section of code may end up in a C library and be much more compact than it currently is. For example; The current vmem routines for the File Manager" module uses 3 different database structures for PC file directories, RSDOS file directories, and OS9 file directories. This take 3 separate sets of vmem routines that are identical with the exception of the array structure and the "record" size that increments as you move from viwing one record to another. The new vmem routines will hopefullybe rewritten to dynamically change the array structure and array size using just one generic routine. I've yet to test the theory, but according to everything I'm reading in the "MW OS9 C Programming Guide" and the "K&R C" book, my theory should work.
Once I have the vmem routines worked out (it's always the vmem routines), I will finish the templets for 1, 2, 3, & 4 panel modules. I hope the module templets will (for the most part), be "fill in the blank" in that all I have to do is add the new program code in the proper places, make a new menu configuration file and the new module will be done. Of course, the "fill in the blank" part can get a little complex as there's a lot of blanks to fill in and they all have to tie together in the end. But all-in-all, the proccess of module developemant should be much easier using these templets.
I hope to have some screenshots, or maybe even a short demonstration video of the new concept before long. This will be a big step in making MShell what I had originally conceived... a "multi-module" graphic user interface for OS-9/NitrOS-9 that replaces many (if not most) of the common tasks in OS-9. My original plan on the MShell - The Ultimate OS-9 GUI page still stands as the model in which I'm shooting for. Hey.... I never said it would be easy... and I never said it would happen quick... all I said is that IT CAN BE DONE, and I still stand behind what I said. I hope MShell will truely be "The Ultimate OS-9 System Manager".
B.P.
*************************************************************************************
