BootMajik

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

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

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