The MShell Blog P7

*************************************************************************************

From PC to Coco... (09/10/2014)

I finally got my main PC back up and running. You never know how much you rely on something until you have to go without it! My main PC is a Gateway w/AMD Phenom II X4 and having to fall back to a machine with a Pentium 3 was drastic to say the least. I finally moved to my "Entertainment System" which resides in my living room and runs my TV and surround sound system. It's an AMD Phenom II X2, but it was still no match for my X4. It's good to be home again :-)

Now that I'm back out in the studio, I can continue with some serious Coco stuff as well as get some recording done while I'm at it :-)

The MShell project is slowly stablizing into a nice File Manager system and a lot of the quirks are slowly disappearing. As I go through the code, adding one thing or another, I try to optimize all the code around the part I'm working on. This is freeing up some memory. I was having problems moving some code out to "fragged" subroutines, but I think I've figured out where my problem lies. The main program has to remain under $9E00 bytes in size. The fragged subs have to be no more that $2000 bytes in size. The problem seems to be that when the sub is called from 3 or more levels deep into the main, the stack has grown beyond the $9E00 limit and the fragged sub fails because there's no room. I have 2 choices, to either cut the size of the main down so the stack never grows over the $9E00 limit, or, find a way to call the sub from top level of the main instead of from within another sub several levels deep. Now that I know why some fragged subs were failing, I should be able to free up more memory by moving my disk routines out to fragged subs. This basically frees up most of the main and makes room for a few more features that I want to add before moving to the next module.

I have determined that in creating any new modules such as the "Source Control" system or the "BootMajik" OS9 boot maker, I will have to create the new modules as seperate programs from MShell. The 64k workspace just will not hold all the variables needed for what is going to be a massive system. What I plan to do is to "chain" any new modules from the main. This way (hopefully), any module chained from the main will inherit the pipes to the graphics handler (Ms1Grf) and run under the same window. When that module is finished, it just "chains" back to the main or the next module. This is all just theory, but I used chains in my DW4Man project and it worked well. I may be testing this theory later on this evening or tomorrow. Right now I'm trying to stablize my dw4 command parser so I can get the PC file manager in place.

B.P.

*************************************************************************************

Fragging Ain't Easy... (09/13/2014)

Well... things still are not panning out on the fragged subroutines. I can use one of the working subs as a templet, insert the new code, and it refuses to load. I'm missing something somewhere. I have enough system memory to "pre-load" the sub, mdir shows it's there. But the sub never seems to copy into the workspace and MShell hangs up. I've tried several different routines, all from code that works properly in the main. But when I move it out to a new fregged sub, it will not work. One really good example is that I can move my "pcroots" routine that enumerates the dw4 PC server's drives, into an existing sub that has room and it works. I can then delete all the "other" code and rename the sub so it is its own fragged sub, and it crashes. I know it has something to do with the memory allocation but I can't quite get a handle on what's causing it.

All the components of MShell seem to be very finicky about crossing certain 256 byte page boundries. Mike even had "filler" code in the original sources to "Ultimuse3" so he could adjust the page boundries as the code grew and shrank. But this feature was only used in the main program to make sure it ended on the proper boundry so the 8k get/put buffer, the 8k sub space and the 8k global variables all fell on the proper boundries. His subs all had different sizes and never used the "filler" technique so I don't think that's what's happening here. It's not the size of the main as existing subs load and execute properly. Only the new subs fail. This is driving me up the wall and holding me back from moving a lot of functions out to fragged subs to give more space in the main. All the disk routines should be in fragged subs, but every attempt to move them has failed. I've gotten to the point, that when I start a new "concept module" such as "Source Control", "FTP Browser", "OS9 Boot Editor" ect.... I will have to completely write a new set of programs and "chain" them together.

On another note, I have gotten a few things done in the past couple of days. I've moved a lot of the "error messages" and some of the "standard text" statements out of the main and into the independent graphics handler. I had to add a new command to the "piped" commands that by send just 2 bytes (cmd byte + message number byte) down the pipe, the new routine will open the overlay window and print the message. This is freeing up some memory in the main which is allowing me to start working on the PC file reader system.

I think I have my dw4 command parser stable now (somewhat), so I started on the PC file reader. MShell can now query the DW4 server and report all the PC server's root drives. As soon as I clear just a little more memory, I should be able to browse the PC hard drive as if it were an OS-9 drive. If I could figure out the fragged sub problem, then the memory would no longer be a problem. All the variable were set up for this in the beginning so all that is needed is enough memory to add the functions. The PC drive read functions were actually written (and worked) in my DW4Man project and very little has top be changed to make it work in MShell. I just need the memory for the functions.

Other than a few small things, the PC File Browser will be the final routine in the MShell OS-9 File Manager module. Here is a list of what actuall works as MShell stands right now:

• Dual Panel (2 columns each) 640x200 GUI with point/click interface. Display 2 directories on the screen at once.
• All functions accessable by mouse or keyboard.
• Suuport for the Tandy Hi-Res interface
• Internet Updater - Updates MShell (via DW4) from the MShell Update FTP on the internet.
• Automatic Drive Enumeration - MShell recognizes all drives on the system. No "user input" required to select drives.
• User Configurable Screen Colors
• User configurations saved automatically. Once set, the defaults persist in subsequent runs of MShell.
• Browse OS-9 Drives - Browse any OS-9 drive system using the mouse or keyboard.
• Copy OS-9 to OS-9 - Copy files from any OS-9 drive to any OS-9 drive.
• Copy OS-9 to RSDOS - Copy any OS-9 file from any OS-9 drive to any RSDOS drive, including RSDOS partitioned HDs/VHDs.
• Browse RSDOS Drives - Browse any RSDOS file system on any RSDOS drive/disk using the mouse or keyboard.
• Copy RSDOS to RSDOS - Copy files from any RSDOS drive/disk to any RSDOS drive/disk.
• Copy RSDOS to OS-9 - Copy any RSDOS file from any RSDOS drive/disk to any OS-9 drive.
• Delete OS-9 Files - Delete any Os-9 file on any OS-9 drive
• Delete RSDOS Files - Delete any RSDOS file on any RSDOS drive/disk
• Move OS-9 or RSDOS File - Works the same as copy above, but also deletes the original file
• Create OS-9 Directory - Creates a new directory on any OS-9 drive.

Here is a list of the functions left to be added to the File Manager:

• DW4 PC Server File Browser - Browse you DW4 PC server's file system as if it was an OS-9 drive.
• Copy PC to OS-9 - Copy any file from you DW4 host PC to any OS-9 drive (OS9 to PC copies not allowed by DW4)
• Copy PC to RSDOS - Copy any file from your DW4 host PC to any RSDOS drive/disk (RSDOS to PC copies not allowed by DW4)
• OS-9 File Attributes - Set the file attributes on any OS-9 file
• Batch File Manipulation - Select multiple OS-9, RSDOS, or PC files to copy move or delete
• File Type Filters - Set the browser to view only file of a certain type by their extension type.
• File Type Context Menus - Based on file types above, use to play music files, list text files, and view graphics via "forked" players and viewers.
• Menus to run the upcoming MShell modules from the main menu. I have many different modules planned.

As you can see, I have accomplished quite a bit since this project started, but I still have quite a bit to go... and this is just the File Manager! Wait until you see what I have planned for the next few modules. Some of which I've already started working on.

Just remember.. to get the latest version of MShell... just use the MShell Updater and download it straight to your Coco! Or if you are not running DriveWire4, just download the latest distributions disk from the MShell website :-)

B.P.

*************************************************************************************