Embedded Files
*************************************************************************************
The Utlities Cometh... (06/04/2015)
I have been busy with the new MShell templets and I decided to create a "starting templet", which is going to be the first module loaded when you start MShell. This module I think I will call "The MShell 2 System" module or "Ms2Sys". Ms2Sys will not only have the "Module Menu" for selecting the MShell module in which you wish to run, but will also be a sort of "System Manager" module as well. Ms2Sys will contain many utilities to manage the OS9/NitrOS9 system such as editing screen colors, setting your mouse/joystick settings, keyboard repeat settings, free memory, disk check, free disk space, and a lot more. I have already started on several of these utilities and I'm very happy with how well they mesh into the MShell system and GUI. Some of the utilities I already have working are:
- Virtual Memory Modules - The virtual memory (memory beyond the 64k workspace) is utilized to store directory and file arrays. Vmem is also used to store global variable that would otherwise occupy the workspace and allow newly loaded modules to access the global variable, making them truely "global" (based on Mike Knudsen's vmem routines from "Ultimuse3")
- Fragged Subroutines - Fragging allows MShell to dynamically load an 8k subroutine into it's workspace. The subroutine has access to the module's global and direct page variables. The calling module's functions can also be accessed as if the subroutine was a part of the main module. This allows endless modules to be developed. (based on Mike Knudsen's fragged subroutine routines from "Ultimuse3")
- CPU Type Identifier - Identifies between the 6809 and 6309 CPU and if the 6309 is found, the utility checks the mode it is running in (based on "cputype" from the NitrOS9 repo).
- RBF Drive Enumerator - Identifies and enumerates all RBF drives on the OS9/NitrOS9 system and stores the data into an array (based on Greg Law's "mdir in C" from a Rainbow article)
- DW4 PC Server Drive Enumerator - Identifies and enumerates the DW4 server's drives and stores the data in an array (DW4 only)
- Memory Test - Tests the Coco 3's memory up to 2 meg. (based on John Collyer's "MemTest")
- Free - Checks drives for free space. Reports in bytes, megs, sectors, and clusters. (based on an enhanced version of "free", author unknown)
- Dynamic Menus - The menus can now change with each module by dynamically loading a new menu array when a new module is started.
- Internet Updater - This utility allows MShell to update it's own system and module files from an FTP site on the internet using DriveWire4 (DW4 only)
- RSDOS File Read/Write - MShell can read/write & delete files on an RSDOS formatted disk or HDBDOS/RGBDOS partition (based on Robert Gault's "HRSDOS" utility)
- DW4 PC Server File Read/Write - MShell can read/write files to and from the DW4 PC server allowing you to move files back and forth between the Coco and your PC (DW4 only)
- Disk Drive Timer - Graphical disk drive timer to check floppy drive speeds (based on Robert Gault's "RPMB09")
- Drive Check - Checks the integretiy of the disk/HD/VHD
- System Control - Allows the user to set screen colors, mouse/joystick type & side, key repeats & delays, and turn the system warning/attention bell on/off
- OS9 Shell - Allows the using to run non-MShell utilities from within a "shell" in the MShell GUI
- DriveWire 4 VHD Mounting - allows the user to view their "VHD" directory on the DW4 server PC and mount VHDs into the sever directly from the COCO. No more going back and forth between the PC and the Coco to change VHDs in DriveWire4 (DW4 only)
- Search - Allows users to seafch any screen listing (database) for any occurance of any string up to 29 characters.
- PrefIO - An automatic preferences routine to save and load system preferences after changing the system with "System Control"
- Config - A config editor for the initial setting of the system parameters. Set the same things as System Control as well as sets the default directories that a module may use. This utility is run once the first time you run MShell to set up the system. It can also be run later to change system settings when needed. Some modules may have their own config file that will also be set on the first run of that module.
- System Status - Displays all of the OS9 system settings that pertain to MShell
- DriveWire4 Status - Displays settings and status of the DW4 server (DW4 only)
I know I'm probably forgetting some things, but I think you will get the idea. I am rewriting a lot of utilities so that they function properly in the MShell GUI environment. I try to find sources for utilities that have a little more functionality than the original Microware utilities that came with OS9 L2. Some utilities are completely original and have never before been implemented on an OS9 system. And of course, no intergrated, multi module project of this size and scope has ever been attempted before under OS9 and the Coco 3. I have already surpassed "Desk Mate 3" and "Multi-Vue" in size, scope, and functionality.
I have the GUI templets far enough along now that I will probably start dropping the code to MShell's original "File Manager" into the 2 panel templet so I can get it going and have some functionality instead of just an empy GUI. I have already started working my "BootMajik" and "Sound Chaser" projects into the new modules as well. I hope to soon do a demo release with at least 4 working modules so I can show off the versitality and modularity of a good GUI based OS9 system. Until then... Keep on Coding :-)
B.P.
*************************************************************************************
Time to STOP!... (11/10/2015)
I have been in and out of the MShell code for the past few months as my studio has picked up some business, but when I get a chance to work on MShell, boy do I work on it!. The past few months have been crazy as I found new ways to do many things in MShell and have expanded it's capabilities tremendously! I finally reduced my 3-part virtual memory routines (for the 3 different file systems) down to a 'generic' routine which works with all 3 files systems. This alone took a large chunk of code from the file manager module and any routine using this code. I think I can even optimize it further but I'm going to save that for the "upcoming rewrite" of MShell's core code. In experimenting wth MShell's C code, I have found there's lots of things that I can write in aseembly using the RMA assembler which would be much faster than the same C routine. So ultimately, I'm going to attempt a partial conversion to RMA code from C. I may do a 100% conversion if I see that this works well. Converting from C to RMA is no trivial matter, especially when dealing with large structured string arrays. C was written for that kind of thing and already has libraries supporting it. In asm (or RMA), you have to write your own string handlers and that's not easy, but it can be done (and I'm doing it!).
In the meantime, I have still been updating the current release of MShell but have come to a point where I feel I must STOP. The more I add now, the more I have to convert later. The main things I've been adding are functions that have been requested from my MShell users, so it was not in vain. I have about 4 more small things I'm going to complete in this revision and then I'm going to dedicate all my time to the assembly rewrite of MShell. In the past week alone, I have added about 9 or 10 major functions to MShell. Most of which involve "batch processing" This has been about the most requested feature for MShell... The ability to select and mark a group of files, click copy, delelte or move and MShell completes the action on all selected files in succession. Another thing I added was a couple of 'forked' modules that report and test the Coco's memory and a free disk space analyzer. This was actually easier than I thought it would be, but I just hadn't had enough free memory in the project until I optimized the virtual memory routines. Doing that released a lot of memory and I had some room to play. But as I said, it's time to stop. Starting next week, all my free time goes to the new MShell conversion project. Once this is done, MShell should be smaller, faster, and have many more features. The conversion also makes it easier to expand with the new modules I'm working on ... the "BootMajik" NitrOs9 boot creator, the "CocoIDE' Coco programming environment, the Dw4 system manager (for managing all aspects of the DW4 sevrer), and the "CocoHub" source control manager for "CocoIDE". These will be my projects for the new year as I have done about all I can do with a file manager (for now). So there's lots of good things yet to come!
B.P.
*************************************************************************************
Running STOP signs!... (12/02/2015)
I have tried to stop working on the current revision of MShell several times now so that I could focus on the C to ASM rewrite of the code, but it just hasn't worked. I sent my last revision to a group of test users to see if there were any 'bugs' to be squashed, and of course they found a few. Then in fixing the bugs, I made a few optimizations and freed up some memory so I started adding more utilities. The next thing I know, I'm four or five test versions down the road with several more utilities added! The one utility I added was a much needed feature, the "Directory Favorites". The Directory Favorites allows the user to browse to any directory on any file system (OS9, RSDOS, or PC) and then 'save' that filepath into a 20 slot directory favorites listing which can be instantly recalled at any time to go straight to that directory. This makes it easier to get to those "most used" directories buried deep on your OS9 hard drive or your PC server. I've also implemented a "Dir Sort" routine to sort your directories to keep them looking neat. There's a couple of more things that I can't think of at the moment, but for the past 2 weeks, I have been in a programming frenzy as the utilities just keep coming. I have two more that will be added in the next couple of days, which will be the "Delete Dir", "Copy Dir" and "Move Dir" which are much needed to complete the goals I had set for this module set in the beginning. With those utilities, I can finally complete the "Disk Copy" function will will be a combination of several utilities being run in conjunction with each other to get the job done.
Most of the programming time is spent chasing down the "add one thing, break two others" syndrom. This is due to the fact that the MShell modules and subroutines all sit on the edge of the Coco's and OS9's capabilities.There are many things in MShell, like the fragged subroutines, the virtual memory, the graphics work area and the menu overlay save buffers that all rely on falling on a 256 byte page or 8k page boundry. When something new is added, it moves other things over their boundries and something breaks. Then there's the evergrowing program stack space. Sometimes it's hard to tell were the boundries are being crossed as a function can span between two or three modules or subroutines, all using virtuall memory. For example, just this morning, I was adding a new menu to the graphics handler. I then proceeded to add code to the modules that would use the menu. Once I had things like I wanted, I run MShell and everything started breaking. I was getting error messages for functions I wasn't even using... after about 3 hours of chasing down and debugging code in the modules, I decided to take a look at the original addition of the menu to the graphics handler. I had added padding to the code in the graphics handler to make it's code fill the space needed so the mapped in graphics screen (for direct drawing) would fall on an 8k boundry. In adding the menu, the code stepped over this boundry and the direct draw graphics were overwriting the menu system. I removed the extra code padding and everything went back to working like normal and the new menu worked perfectly. And that was one of the easier ones to find... Some take days to figure out what is going on.
So I hope to finish up these last few routines within the next couple of days so I can then get back to work on the upcoming "New MShell v02.00.00" rewrite and maybe get back to work on some of the upcoming MShell modules that I keep mentioning... like the BootMajik automated OS9 boot maker, the FTP browser, The CocoIDE programming environment... BUT WAIT..... There's 213 bytes of memory I'm not using... I have a routine that will fit right in there!
B.P.
*************************************************************************************
Prev / Next
Page updated
Google Sites
Report abuse