The MShell Blog

First and foremost....

I would like to state that I am not a "programmer" by trade or education. I am a 10th grade "dropout", blue collar worker who very fortunately bought a little white box in 1984 (85?) with 16k Color BASIC and an Orchestra 90cc program pack. My interest in music and graphic art and the fact that the Color Computer would do both, grew into a passion that never went away. A passion that made me continue my education (privately) and expand my knowledge in computers, music, art, and in life in general.

My programming experience grew from Color BASIC, to Extended Color BASIC, to Disk Extended Color BASIC, to EDTASM and assembly, and eventually into OS-9 with OS-9 assembly, Basic09 and now, for the past 3 years, OS-9 C, which has been quite an adventure in itself.

So as you can see, I'm not some engineer or programmer who does this every day. Just a hobbiest with a passion. A passion for the Tandy Color Computer and OS-9.

MShell is not my idea, and certainly not my code. MShell stems from every program I've ever run and every source code I've ever viewed. There's pieces of code from all over the Coco community in MShell along with ideas and advice by everyone I talk to. I constantly search my huge Coco archive for sources for reference to some function I want to implement or create. For example... The MShell GUI , "fragged" subs, and virtual memory were all based on the sources from Ultimuse 3 by Mike Knudsen. The RSDOS disk read routines are based on the sources from HRSDos by Robert Gault. My OS-9 directory routines are based on utilities by Bob Devries and others. There are many pieces of many people in MShell, some of whom I do not know their names as there was no name on the source I used.

Yes, putting all this together was MY idea... but it's an idea that has been discussed and even tried by many people over the past 30 years.

I just decided to be the person that made it "Just Work"

Reinventing The Wheel (12/17/2013)

I have been having a lot of success with the MShell GUI (graphic user interface). In using the sources of "Ultimuse 3" as my templet for the code, I now have a nice GUI with mouse/keyboard control, menuing system, "fragged" modular design, and virtual memory for the databases. The more I delve into the Ultimuse3 code, the more I find that I can do with it. Mike Knudsen (Ultimuse 3 author) created a system that was completely self-sufficiant in that it needs no graphics libraries, no "outside" commands, and a compact coding style that I've yet to see in any OS-9 "C" sources that I've found.

The GUI is almost ready to start adding my custom modules. The hardest part was to "strip" all the "score editing" code from the project as that was 70% of the code. Once this was done, I found I had created quite a bit of room in the main code for most of what I want to do. If I keep the main code this small, I may even be able to use up to 16k for my "fragged" subroutines. This would mean a lot more features could be added to the various "modules" and keep their code out of the main module. The hardest part of working with this GUI is keeping the global variables down in size. These are the variables that need to be shared with all modules and will be part of the main. I've yet to test my version of the v-memory buffers, but I'm pretty sure I can get it to work like I want. The difficult part of implementing the v-memory is that the original Ultimuse GUI only used 1 buffer system. I will be using three or more! This eliminates the use of the 64k workspace for the buffers saving tons of memory for the actual program.

Using the mods I've already programmed for the actual Ultimuse 3 software, I've already implemented my "DriveWire4 MIDI" module as well as my "Internet Update" module. These modules are up and running in MShell using the "fragged" subroutine system. This alone lets me know I have my "DW4" parser working. I've also tested this on a real Coco 3 and everything works as expected.

The next step is to get the split screen, dual directory interface working. To do this, I have to create the split screen routines. Eventually, I will be utilizing 2, 3 and possibly 4 "panes" on the screen at once. But for now, I'll settle for just 2 as that's all I need for the OS-9 file manager module which is the first major module I plan to have working. This module will display 2 panels (panes) that will display 2 seperate directories in which you'll be able to manipulate files (point and click) from any 2 drive systems on your OS-9 machine. You will be able to do most anything to the displayed files that you would normally do from the OS-9 command line. I hope to have a demo of this module ready by the first part of next year (2014) and with the progress I've made with the GUI, I feel I'm right on schedule so far.

The big test will be getting the directory listings into the virtual memory arrays. Setting this module up has been my priority for the past couple of weeks. I've been busy with work lately so I haven't had the time I normally have, but I think I've got everything layed out pretty good and should have this going by Christmas (less than 2 weeks away). This reminds me of the big rush I was in last year about this time as I was trying to get the DW4Man software working properly by the first of the year so I could start bug testing and finalizing features to have DW4Man ready for the CocoFest. I barely made the deadline. I hope to have MShell ready for "showing" at the 2014 "Last Anual CocoFest" but I don't know how many modules I can have ready. I know that once the virtual memory buffers are working properly, I have at least 5 modules that are nearly done. These modules were part of other projects and can be easily converted to MShell's "fragged" module system. Then there's about 6 modules I've started that I stopped working on because they needed the virtual memory system and at that time, I had no clue how to implement it. Once the virtual memory system is in place, these modules should move along quickly. But for now, I'll settle on having the OS-9 file manager system working as this is going to be the heart and soul of MShell.

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

Next Page