Embedded Files
BootMajik
The Ultimate OS-9 Boot Creation Utility
By Bill Pierce
Note:
All blog entries are in reverse order (newest first). This makes it easier to view the latest entry. To read the blog in chronological order, just start from the bottom entry and read up :-)
*************************************************************************************************************
Getting to First Base... Database that is...
(03/20/2015)
I now have the BootMajik GUI fully functional in a 4 column mode with mouse selection and pull down menus. In working on the database for the OS9Boot files list in which the user will choose their modules from, I have run into a slight problem. In the years of NitrOS9 developement, a new module type was introduced. The "Subroutine" module. Originally, subroutines were defined as "user" modules called by OS9 executable modules. The new "subroutine" type is being used as a "part 2" of manager and driver modules... a driver extension module of sorts. In most cases, these modules are required by the driver and would be loaded by default, but there are cases in which certain drivers support multiple subroutine modules or a choice of several types. Most of these types often have their own descriptors... but not always. This is where the problem crops up. I need a way to flag the descriptor modules to point to either the subroutine or the driver. I may have to use multiple flags on each descriptor as some descriptors are used by several drivers as "general" descriptors. The floppy disk descriptors are a prime example of this. There are currently 3 floppy disk drivers that all use the same floppy disk descriptors, so I need a way to flag the descriptors so that when each of the drivers are selected, the next panel lists the proper descriptors.
It's not really a "serious" problem, but one must remember... I only have so much memory in which to implement all the flags and arrays needed to properly list the modules in a parent/child format.
The idea is a list such as:
Of course, this is just a small sample of available drivers, but the idea is to click each column to reveal the available "child" modules in the next and so on...
The table above shows the "subroutines" (column 3) as having descriptors as their children. Here, the problem is that "WD1773.dr" has no subroutine and it's children are the descriptors. Had that been the selection, then column 4 would not have any entries.
Here's another example showing subroutines with just the opposite order:
In the 3rd column, the first 7 modules are subroutines and have no descriptors. Also, of the first 5 of these subroutines, only 1 is selectable. The other 2 are required.
Now, of the "cowin.io" and "cogrf.io", only one is selectable. The same goes for "covdg.io" and "covdg_small.io". Also, each of these sets share the same set of descriptors.
The problem is not so much in deciding the parent/child dependencies of each module as it is finding a way to flag these dependencies in such a way that the database is easily searched and displayed. Also in making it easy to add new modules as new drivers are developed (or old drivers found) and still keep everything in line.
One idea I've been playing with is adding a "module list editor" in which you create new module lists or edit old ones. In developing such an editor, I hope to find the "key" to making the database work. Then the display method would just be a reverse of the editor. So far, I'm using "ID" numbers for each module. Then the array for each module contains a multi-element array that list the "parent(s)" ID of the module. Also there is a flag if the module is required, one for the number of the modules in the group, and one for the number you are allowed to select from the group. The method is usable, but has a few pitfalls in adding new modules as the user has no idea of the ID number of any parent or child module. A method must be found for the user to select which "group" the new module belongs to. At this point, I am thinking of using the columns as shown above, but when an existing module is selected, the user has the option of deleting, editing, or add a new module to the group. This would allow the user to "page" through the columns and add new drivers and their dependancies. I'm not sure I have the memory to implement this as I using one of the 8k "fragged" subroutines for this utility and only so much can be crammed into 8k. The editor itself will require a lot of data manipulation and that takes memory. There is the option to make this a "forked" module, therefore residing in it's own 64k and allowing more memory use. I have a feeling this will end up being the route I will have to go.
Once I have resolved the whole "dependancy" problem, the rest of the program should start taking shape. As I stated in the beginning, the GUI is (for the most part) finished and ready for the main code. Even some of this code is done, such as the display routines for the columns and the selection routines.
Here's a couple of screenshots of BootMajik running on VCC. The first is the Machine/CPU/Level selection menu (working). The 2nd is a mockup of what I'm proposing for the module selection screen (WIP).
Click the pictures for a larger view
Machine & level selection menu Mockup of the module selection screen
B.P
*************************************************************************************************************
BootMajik... Coming of Age
(03/06/2015)
While working on a complete re-write of the "MShell" GUI core, I came across my code for the 4 column screen I had planned to use in BootMajik. Since I've run into a few problems with the MShell re-write and need to re-think my ideas, I decided to take a little break and do some work on "BootMajik", the OS9 bootfile manager.
The idea is to not stray too far from my goals for the MShell project and keep BootMajik within the bounds of the project while making it a stand alone program (for now). Once the MShell project problems are worked out and I have the new system where I want it, I will merge BootMajik into that project making it a integrated module to the MShell software suite. The MShell GUI makes it easier to write this software as the screen, mouse, and menus as well as "virtual memory" and "fragged subroutines" are already written into the GUI. BootMajik will make extensive use of these features.
I have the data structures and screen layout set up for BootMajik and I'm now working on the menu system which will allow creating an OS9Boot file for any model Color Computer as well as the Dragon 64 and Tano Dragon 64. The complete process will be "point-n-click" and no user input will be required. The user will select the machine model, NitrOS9 level, and CPU type (6809/6309) and then select their modules from a structured list tree. BootMajik will automatically select any "required" modules and let the user know when items are optional and/or how many are needed. All selected (clicked) modules will show a small description so that the user understands what they are installing in their boot file.
I hope to have a few screen shots up soon as this is moving along pretty quickly, so check back soon for a view of BootMajik, the OS9Boot file manager :-)
B.P.
*************************************************************************************************************
New Beginnings (and hopefully, a new ending)
(11/09/2014)
I finally got the MShell GUI working and my MShell file manager is about to be released (soon), so due to popular demand, I've decided it's time to start tinkering with the "BootMajik" project once again. I will still be working to expand the MShell file manager, as it is integrated into almost everything I do now. The GUI is just "too nice". I can take the MShell GUI and adapt it to just about any program type I need... databases, word processors, file browsers, anything! The MShell GUI will allow BootMajik to have full mouse control over a 4 column screen with pull-down menus and almost zero user intput.
I should be posting something here on the first draft of this new interration of BoottMajik within the next couple of weeks. The more I look at what I've done with the MShell code and it's capabilities, the more things I think I can do with BootMajik. I now know I could actuall pull files from FTP sites directly from the Coco as well as directly from the DriveWire4 host PC. I can even keep an "online" database of the latest NitrOS9 drivers, and have BootMajik update it's local copy of the database from the internet... pretty amazing for an 8 bitter invented 20 years befor the internet existed :-)
As I posted on the Coco mail list recently, I have put together a "NitrOS9 Bootfile Dependacy Tree" which shows how all the modules in a Level 2 bootfile relate to one another. I'v e only finished the tree for NitrOS9 Level 2, but will do the NitrOS9 Level 1 trees soon. Level 1 is a little trickier as it is very memory dependant, and the slightest thing out of place can cause huge memory problems within OS9. Also, there are different setups in Level 1 for the Coco 1, Coco 2, Coco 2b, and Coco Deluxe. I have uploaded the Level 2 dependacy tree to my dropbox and there's a link to the text file in the right sidebar above.
So keep an eye on this site for any new developements in the "BootMajik" automated NitrOS-9 Bootfile Creator.
*************************************************************************************************************
Why Drive A Volkswagon When You Can Drive A Caddy?
(09/20/2013)
Ok, it's done. I finally made the decision. All work on HRSView, DW4Man, Sound Chaser, BootMajik, and a few others I haven't even mentioned yet, has come to a sqeaking HALT. There will be no more work on these programs until I finalize a new graphics user interface (GUI). I am tired of CGFX breaking everything I try to do. I have decided to do exactly what I've wanted to do since the very beginning of all these projects. That is to use the sources of Ultimuse 3 as a templet to create a general purpose GUI that incorporates the mouse, "fragged" subroutines, forked & piped graphics and file managers, and virtual memory data storage. In Mike Knudsen's 9 or 10 year stretch of developement for Ultimuse 3, he had worked out almost every known bug. To avoid the various bugs and quirks of the OS-9 sysem, he wrote most of his own text and graphics handlers. The CGFX library is never used in his sources. The only C library used was Carl Krieder's "klib.l". In using Ultimuse 3 for almost 10 years myself, I watched it grow from a small 2 or 3 files package to the final 13 or 14 file package that it became. I've used many graphics oriented, mouse controled programs for OS-9 and RSDOS and I can truthfully say that Ultimuse 3 has the smoothest graphics scrolls, the fastest, most accurate mouse control, and the most intuitive menu system of any Color Computer program I've ever run, bar none. This is why I've decided to use these sources as a templet for my new GUI. Why reinvent the wheel when the wheel already has radial tires, hydraulic suspension, power steering, power brakes and air-conditioning?
The difficult part of this project is going to be to remove all the Midi playing and score editing code to get the sources down to a compilable version of just a bare menu system with all it's functions still intact. There is a lote of C code contained in the 125+ files that make up the Ultimuse 3 sources. It will not be an easy task. I will be leaving all the mouse, text, menu, dialog and disk i/o functions as with a little modification, they will fit my needs nicely. I will also leave the virtual memory routines intact as with a few changes to the data structure and indexing functions, I can use these roitines to maintain the tons of data arrys that are used in my various projects. Ultimuse 3 also has a unique feature that I've never seen in any other Color Computer OS-9 product before... The main program code stays below a certain size as to leave at least 8k of memory free above the program. This main program handles all mouse and keyboard reads and activates any calls to any menus or functions. When these menus or functions are needed, the main then loads a sub-module into the 8k area and links it with a unique pointer sytem that allows these sub-modules to not only call functions from the main program, but to also call functions and subrouitnes from other (not yet linked or loaded) sub-modules. The main program will then unlink the sub-module, load in the new sub-module, execute the needed function, then unlink the sub-module, load the old sub-module back into the 8k memory and resume where it left off. The amazing thing is that not once does Mike use illegal code to acomplish this. It's all done using standard MW OS-9 C code and standard OS-9 system calls. The sub-modules are all restricted to be under 8k in size (of course) and a special version of "cstart.r" was created that uses the same "global" variables already initialized in the main program. In this way they share the same variable space. When each sub-module is called the first time, the main checkes to see if it is in memory already, if not it does an "NMLoad" that loads the module into the system memory therefore leaving the main's 64k workspace intact. Then the main "links" the module into the empty 8k space and executes the needed function. The main keeps tabs on which sub-modules have been loaded into memory and in what order they were loaded and used. When the next sub-module is called, the old sub-module is unlinked, but not unloaded. This double linking system allows the module to hang around in system memory so it's doesn't have to be re-loaded from disk when called again. As each module is used, they are loaded and linked in this fashion which speeds up the whole process once the modules are in memory. The nice thing about this system of using sub-modules is it's not an experiment. It's a proven programming technique that been in use with Ultimuse 3 since 1989 when Mike added the feature. It was then tweaked and perfected for the next 9 or so years until it was flawless. The other thing that Ultimuse 3 does is it runs in 2 independent 64k workspaces. The main program accepts all mouse and keyboard input and decides what functions are needed. But when something is output to the screen, Mike used a piping system to pipe the text and graphics commands to a second process called "Fran". When the main is first started, Fran is forked into a 2nd 64k workspace and proceeds to create the screen. Once the screen is initialized, it returns to the main and basically sleeps till it's needed again. When the main or any sub-module needs something displayed, whether it's graphics or text, the commands are "piped" to Fran and Fran does the display work in the background. While Fran is working, the main continues so that program flow does not stop. To see this in action all you have to do is to run Ultimuse 3 and do a scroll through a music score. While the screen is redrawing, hit a few known menu commands in succession. When the screen finishes with the redraw, the menus will open and perform what ever function you typed in. Keep in mind that these menu drawing functions pipe right back to Fran again to display the menus. It's an amazing system to watch in operation if you've never run Ultimuse 3 before. The whole time all this is going on, the mouse cursor is sitting there waiting for you to make some editing move or menu choice. The only time you really need the keyboard is when entering a filename or description of some sort. Even with that, all menus and functions are still callable with a simple keystroke.
All in all, the ease of programming with using the Ultimuse 3 sources as a templet for my GUI is going to make for an intersting OS-9 project. I have been studying these sources for almost 3 years now and have become very comfortable with the program flow and Mike's C coding style. The first time I ever saw this code, it was like trying to read Japanese. But over time I began to see why Mike did certain things the way he did as most things were avoiding OS-9's "quirks". Mike was a professional C programmer with 2 college degrees, a PHD and a Master's in programming from 2 different Universities. He then worked and retired from Bell Labs as a C programmer. So his knowledge in C coding was not average but extreme. After programming in C on a Unix mainframe all day then coming home to work on Ultimuse 3 in OS-9, it was like working on a high tech drag racing engine all day to come home and procede to "soup up" the family car. OS-9 was just a "mini" version of Unix to him.
So... until I get the Ultimuse 3 code converted to my GUI and can start working in all my previous code from the other projects, there will be no updates to the program packkages or the blogs for "DW4Man", "Sound Chaser", "HRSView", "BootMajik" or "Reclaiming OS-9 For The Coco". Yes, "Reclaiming OS-9 For The Coco" this has become part of this now greatly expanded project. Just wait till you see what I have in store for that project. It's going to be a Coco "one of a kind" feature. Already I have close to 20 different sub-modules started or in planning for this new "Complete OS-9/NitrOS-9 GUI, System Management, and Utility Program Suite". So far, the only working title for the system is "MShell" or "Multi-Management-Shell". This may change as things progress, but for now, "MShell" seems to stick.
Besides... It's easy to type in to a command line :-)
*************************************************************************************************************
Introduction
(05/28/2013)
Not too Long ago, I was helping Nick Marantes set up an NitrOS-9 boot disk. In response to one of my emails explaining the OS-9 boot process, Nick commented that there needs to be a simple, easy to use bootfile creation utility. This immediately put my gears in motion as I had spent many hours explaining the process to many people throughout the years. Yes, a good bootfile creation system is needed, and I’m going to write it!
Thus “BootMajik” was born. This utility will keep a database of current NitrOS-9 modules used in making a bootfile and will give the user educated choices in making a proper bootfile on the first try. With a few menu driven selections and lists, the user will define their Color Computer system and hardware. After all selections ar made, the program will then create a bootlist to be used with OS9Gen to create an OS9Boot file on the assigned drive.
It is my hopes that this software will not be limited to creating a bootfile for just one NitrOS-9 system but for all Coco NitrOS-9 systems. This will include:
1. Coco 1 NitrOS-9 Level 1
2. Coco 2 NitrOS-9 Level 1
3. Coco 2b NitrOS-9 Level 1
3. Coco 3 NitrOS-9 Level 2 6809
4. Coco 3 NitrOS-9 Level 2 6309
If there is people needing it, I will include support for Coco 1 and 2 with a 6309 CPU under NirOS-9 Level 1.
I may even include support for “Standard” Tandy/Microware OS-9 Level 1 and 2, possibly even the “patched” versions from the early 1990s. I’ve found that some users still prefer the old standard versions.
The only cavet in this is that the build process will have to be done from within NitrOS-9 Level 2. Level 1 does not provide enough memory for these types of operations and cannot fork a new process in another window. Also, the 32 column screen is too cramped for displaying lots of data. This does not limit the type of bootfiles that can be created, only the machine they are created on. So I’ll only be releasing this for Level 2.... for now...
I will also try to address as many hardware drivers as possible. I plan to gather some of the more obscure drivers from other users so the library of drivers is as complete as possible. So if you have an obscure driver that is not included in this system please contact me and I will see that it gets into the driver database.
Another thing I would like to do after I get this system stable, is to create an FTP site on the internet and attempt to have the user’s BootMajik program update it’s database from the FTP site. This will be done using the Coco 3 running NitrOS-9 L2 with the DriveWire 4 drivers and will only be available to those who use DriveWire and are connected to the internet. This will also allow updates for the BootMajik program itself, just as DW4Man and Sound Chaser that already have self-updating features. For those not using DriveWire 4, a direct download site will be provided to update the driver database disks and software.
With the FTP for the database, I can make any new modules that I add available to all as soon as I add them.
So I start this project with my “Sound Chaser” style GUI as a templet and a lot of ideas.
I’ll be doing my coding in my MJK C Compiler system on the VCC emulator with the Becker port for DriveWire 4 support as usual.
Let’s see where it goes....
*************************************************************************************************************
And they’re off....
(05/29/2013)
I’ve started converting the GUI for BootMajik over from the DW4Man interface as it’s set up the best. I’ll be using a lot of basic functions of DW4Man as a base to do what is needed. That’s what I like about this GUI. It’s easy to change things to do something completely different with it and make new software. I hope to have a templet for this GUI uploaded for public developement soon. The big thing here is to put priorities on what needs to be done first and what follows next. Also, getting the menu system so that it’s functional and easy enough for a beginning OS-9 user to grasp the concept.
Another thing I’ve been doing this evening, is gathering all the drivers and modules I have in my archives. I’m sorting through them and trying to place them in appropriet directories. I need all levels of drivers from all incarnations of NitrOS-9/OS-9. I really didn’t realize how many I had till I started gathering them all in one place. Just the different “levels” of drivers from the NitrOS-9 repository are a large list in themselves. This is going to grow as I start gathering drivers from others. This database could get to be very large.
(more coming soon...)
Page updated
Google Sites
Report abuse