MShell - The Ultimate OS-9 GUI

MShell

The "Ultimate" NitrOS9 GUI

To keep up with the progress of MShell

Visit the

The MShell Blog

Or download the "just released"

"MShell 01.00.3w"

(Latest Version uploaded 12/22/2019)

And now the MShell Demonstration Video

I have just released a video on the power of MShell on youtube.

You can view the video here"

(Be sure to set your viewer for "HD" quality as this video is in Hi Def)

(The video is an older version of MShell, things have expanded since then. I hope to have new videos soon!)

!!! PLEASE READ THE MANUAL INCLUDED IN THE ZIP !!!

Thanks to Stephen Pereira, who has tested MShell on the Coco3FPGA running at 25mhz and all is running well (so far). IMHO, the Coco3FPGA is the future of the Color Computer, so I definitely want MShell running on that platform! If I ever get my hands on one, I'll start making a version for the higher resolution screens... of course I'll have to write an OS9 driver for it :-)

[EDIT] I now have the Coco3FPGA and the "Analog Board" daughterboard. MShell works perfectly with the Coco3FPGA and I hope to soon offer a special version of MShell that supports the Coco3FPGA's 640x450, 256 color mode. NitrOS9 drivers for the new mode are a WIP, so I have to wait until these drivers are completed, but The Coco3FPGA version of MShell should expand well beyond the capabilities of the original.

MShell v01.00.3q and greater now requires a later version of NitrOS-9 (v3.3.0 or later preferred). This is due to the use of a couple of "new" system calls that are only available in later versions of NitrOS-9. My original intentions were to have MShell run on any version of OS-9, but alas... that was not to be. The addition of the newer system calls were needed to implement the new "batch copy" functions and there was no way I could find to get around using the calls. Personally, I wouldn't use any other version of OS-9 for the simple reason that NitrOS-9 v3.3.0 is the fastest, most stable version of OS-9 ever released. Not only that, it is available for almost any version of 64k Coco ever released (1, 2, & 3) as well as Dragon 64, Tano Dragon64 and even the Coco3FPGA!! So if you are not using NitrOS-9 3.3.0 or better, I suggest you make the switch, you'll never regret it!!

IMPORTANT: As of 08/28/2016, I am revamping these MShell pages. The original page was for all intents and purposes, a page describing what I wanted to do with MShell. The development of MShell has reached a level in which MShell is now a usable system and I now have definite directions in where MShell is headed and I want these pages to reflect these directions. All info, pictures and videos will be updated within the near future to reflect MShell's current status. I will hopefully be creating an individual page for each of MShell's modules and utilities with pages for modules under development. Stay tuned for more MShell info :-)

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

Introduction

The idea for this project originally started back in the late eighties when the Color Computer 3 and OS-9 Level II were in their heyday. I was constantly reading letters to Rainbow and other magazines about OS-9’s high learning curve and how there should be some sort of “User Interface” to make it easy for non-programmers who were just starting out with OS-9. Unfortunately, in the eighties, I didn’t have the knowledge or resources to write such a project even though I had all the right ideas. With much of the Coco software and documentation now available on the internet in “Coco archives”, the project doesn’t seem as daunting as it did back then. My programming experience has grown vastly since then as well. I think I’m finally ready to embark on what will probably be the largest suite of NitrOS9/Os-9 programs ever assembled in one package. I will most likely be releasing bits and pieces of this package over the course of the next year or more. Along the way, I’m sure I’ll be looking for BETA testers to make sure I’m heading in the right direction with my methods. The goal here is “OS-9 Ease of Use”

I really had no idea I was heading in the direction of this project until someone told me that my DW4Man project would make a good templet for running software from a NitrOS-9/DriveWire empowered system. This got me thinking of the possibilities. I began to write a few utilities for DW4Man and soon realized that this had grown well beyond what DW4Man had started out to be. It was time to aim the project directly at the target. NitroS-9 itself.

What if I could create a suite of programs to do all the things that OS-9 can do but from one central user interface? I know, Tandy tried that with Multi-Vue with minimal success. Others tried it as well, but their efforts just didn’t seem to cover enough ground. But I already had a usable, working interface, several base modules to build from, and several projects that would tie in nicely with this one. The more I thought about it, the more ideas I had. A more modern form of DeskMate, with the functionality of Multi-Vue, the ease of Ultimuse 3 and the power of NitrOS-9 and DriveWire4 !!

Thus “Multi-Shell” or ”MShell” was born.

The Concept Behind MShell:

The concept for MShell is a simple mouse/keyboard driven menu system that will allow a user to do most of the common OS-9 tasks from within the interface without typing long command lines or pathlists. I have incorporated the modularity of OS-9 to make use of the “fork” and “chain” commands to run various modules from within the menu system as well as using fragged subroutines, originally developed for Ultimuse3 by Mike Knudsen, and now incorporated into the MShell architecture. Fragged subroutines are small modules (8k & under) written in a special manner that they can be loaded into the main module's workspace, with both the main and sub sharing global & direct page variables. The functions in the sub are callable by the main and certain predefined functions in the main are usable by the sub. The fragged subroutines can be hot swapped at any time making functionality of the module almost unlimited! MShell also makes use of virtual memory, memory outside the module's 64k workspace. The virtual memory is any memory present in the Coco not allocated by NitrOS9, which will utilize from 512k, up to 2 megs of memory (via Disto's 1 & 2 meg upgrades, Coco3FPGA's extra 2 meg available with the analog board, the Boomerang memory board and Cloud9's latest Triad upgrade). This extra memory is used for various large data arrays and for passing program variables to and from external modules.

MShell consists of many modules for it’s various functions and features. Some modules have already been completed in other projects and will be adapted for MShell. I have others that I’ve already started from scratch, as well as a few still in the concept/layout stage. Hopefully, sometime within the future, a lot of these modules will reach maturity and become part of the MShell system.

On the next pages I will try to describe some of the MShell features… those finished as well as those in planning. The format for these modules/listings/panels will be in graphics mode. One, two, three, and four column “panes” in an 80 column graphics window. Even though I'm using a graphics screen for the interface, I have chosen not to use an “Icon” system due to the fact I have found I can list more files on the Coco screen with text than I can icons. In a 2 column screen, I have found that I can effectively list about 84 files (21 files per column, scrollable) on the screen at one time, most with full filenames, where as Multi-Vue style “Icons”, in it’s current form, can only list 32 Icons with partial names of 11 characters max. Then you have to assign unique icons… that you have to create… along with an aif file… that you create.. You get the picture. I feel the text method to be much more informative with a lot less hassle. Not to mention, OS-9 can write a screen of text filenames at 10 times the speed it can draw a screen of icons. This method also leaves me room for a “status bar” at the bottom of the screen to display detailed info on the selected file/directory/dsk/vhd and a "Drive Panel" on the left side of the screen allowing you to switch drives almost instantly. These features alone makes this format worth using.

This software suite is already growing to be quite a large installation. So far, in the upcoming release, there are 30+ working modules/sub-modules. And there are over 20 planned modules and possibly 25 or 30 planned sub-modules. There will also be a complete NitrOS9 module repository for creating OS9Boot files with the upcoming "BootMajik". Many versions of NitrOS9 will be provided as well as a massive driver/descriptor/module archive for making almost any kind of OS9Boot from the current NitrOS-9 repository in all it’s incarnations (sIDE, DW4, Becker, CocoSDC, Coco3FPGA etc). The programming library for the upcoming "CocoIDE" programming environment will contain almost every known ASM and C incarnation for OS-9 with standard and custom libraries, headers, and defs. A database will also be included from which to build your own custom libraries and defs.

MShell is currently available on a single floppy disk image, but it is quickly outgrowing the floppy format size limit. The type of media in which the future MShell revisions will be released is undetermined as of yet, but I suspect I will be offering “custom” virtual hard drives (VHD) and offer to set up custom boot systems for these drives as well. For those still using "real" hardware storage, there will be a series of installation disk images available as well. For the most part, MShell will be hard drive oriented. I doubt all the features I have in mind would fit on a floppy disk system and with today's Coco storage options such as "DriveWire4", "SuperIDE", CocoSDC, Coco3FPGA SD, and others, I assume that most "serious" Coco/NitrOS9 hobbyists have incorporated some form of "mass storage".

Since I started this project, I have made huge advancements in enhancing the GUI for MShell, I decided to revamp this website to explain the many features and uses for MShell. I will try to post progress updates as each new module comes available. The MShell GUI is reminiscent of the Mike Knudsen's "UltiMusE III" GUI as I've used Mike's Ultimuse III sources as a templet for my GUI. Ultimuse III is one of the finest examples of what can be done with OS-9 Level 2 and I hope to follow in Mike's footsteps in creating a "user friendly" interface with tons of features, modularity, virtual memory and a "point-n-click" interface.

With that said, here is a list of the system requirements for the MShell software suite:

The System Requirements:

• A Tandy Color Computer 3 with at least 512k of memory with either the 6809 or 6309 CPU. If you have the Disto 1 meg or 2 meg memory upgrade (or any other such memory upgrade), the extra memory will be utilized for extra windows, data buffers and more simultaneous processes. The latest VCC and Mess Coco3 emulators with Becker port support will also work, but must be set up for Drivewire4 use to be able to use the DriveWire features. Older versions of VCC and Mess will work as well, but you lose DriveWire capability. These emulators can be run with up to 2 meg of memory effectively. The support for the Coco3FPGA (@512k) and Analog Board (@2 meg) is completed, so MShell runs properly on the Coco3FPGA :-)
• NitrOS-9 Level 2 Ver 3.3.0 operating system or better with DriveWire4 or Becker Port (for VCC) support. Older versions of NitrOS-9 may work but must be Drivewire4 or Becker port compatible for the DriveWire management tools.
  • Your NitrOS-9 bootfile must include the “CoWin” Or "CoGrf" terminal driver. CoWin/CoGrf is required to use the Multi-Vue like menuing system. Gshell or Multi-Vue are NOT required. You must also have at least 7 window device descriptors installed (/w1 - /w7).
  • You MUST also have “Pipe”, “Piper” and “Pipeman” in you boot as well. MShell will be using pipes to communicate with forked modules and the main graphics handler.
  • The "stdfonts", "stdptrs", and "stdpats_xx" are NOT required as MShell creates it's own fonts, pointers, patterns, and icons. In fact, MShell uses very few of OS-9's graphics routines. Most of MShell's graphics routines were were written from scratch by Mike Knudsen for Ultimuse3. The fonts, pointers, and patterns are included and installed within the MShell install package.
  • To use the DriveWire management tools, you will need a Windows/Mac/Linux PC running DriveWire4 server and a DriveWire cable (Coco Serial to DB-9), and your Bootfile must also include “scdwv” driver and at least two of the “/Nx” descriptors. These are the virtual channel drivers used by MShell to communicate with the DW4 server. Also used are the "scdwp" and "/p" driver/descriptor for DW4. MShell will automatically check for DW4 drivers on startup, so if you are not running DW4, the menu choices for those tools will be disabled automatically.
  • To use the DriveWire management tools, For using MShell’s "Updater" and (future) FTP and Repository features, the server must have internet access. This is not a requirement to run MShell though, it’s just for those features.
  • To use the DriveWire4 MIDI Synth" for the upcoming "SoundChaser Multi-Format Music Player", your NitrOS-9 bootfile must include the "scdwv" driver and the "/MIDI" device descriptor from the NitrOS9 package. These are included in most of the "standard" NitrOS-9 package releases (see below).
• A joystick or mouse connected to your Coco. The Tandy "Hi Res Interface" is also supported. I do not own a Coco Max joystick interface so I will not be supporting that unit (yet). I have included enough "keyboard shortcuts" to make MShell run completely from the keyboard as well, so running MShell without a mouse or joystick is as easy as 1 or 2 keystrokes.
• To use the DriveWire4 features of MShell, your Coco system must be connected to a DriveWire4 server running on a PC (Window, Mac, or Linux). The enhanced DriveWire portion of MShell will not be compatible with DriveWire3. Most of the DriveWire commands and features of MShell are exclusive to DriveWire4 and are not supported by DriveWire3, though standard disk operations should work on a DriveWire3 system automatically.
• To use the MIDI features of MShell, you must have your DW4 and Java set up for MIDI sound or either have a hardware MIDI setup using a Speech Systems or Glenside MIDI Pak. If you are not using DriveWire, then Coco serial MIDI communication through the bit-banger port can also be used. This not required to run MShell, but to hear MIDI music such as Ultimuse3, Standard MIDI, converted MFPlay files ("xxx.cmf0), or Lyra songs through the DW4 MIDI synth, MIDI drivers for DW4 (/MIDI) must be installed in the NitrOS9 bootfile. The serial and hardware MIDI cart drivers are already built into the various Midi players. The current builds of NitrOS9 for DW4 all have the DW4 MIDI drivers installed as default.
• When playing any wavetable type music or sound files that normally play through the Coco’s 6-bit DAC (TV sound), an option to reroute this sound to an Orchestra 90 cart is available. This gives the Coco the ability to play stereo 8 bit sound. The wavetable players are coded to operate with the Orch90 cart and Musica files in particular sound very well in stereo. This configuration also works with the virtual Orch90 pak DLL in the VCC Coco 3 emulator as well. This option in VCC gives you full stereo sound through your host PC’s soundcard. An MPI (or the MPI.dll in VCC) is required for these options. If you are running NitrOS9 or HDBDOS with no MPI and no disk controller and the Coco’s cartridge slot is empty, then the Orch90 cart can be used if the CS (cart select) pins of the cart are “taped” over to keep the Orch90 ROM from being activated. With this method, you can use the Orch90 without an MPI. This would mostly apply to a Drivewire setup in which HDBDOS is started from the cassette or disk and NitrOS9 is booted from a disk image in Drivewire. I may provide options for the RS Sound/Speech cart as well as Speech System’s Stereo Pak if there is enough requests for it.
• DW4 is not required for MShell. MShell will run without DW4 but will lose about 25% of the functionality of MShell, but makes it usable on a non DW4 NitrOS-9 system. Some modules will be completely eliminated and others just limited in their use. Other modules will not be affected at all. I’ve designed this system in conjunction with DW4 and it’s capabilities so a non DW4 system will be limited but very usable. All normal OS-9 disk functions and features will work properly. You will just be limited to the actual drives on your system. Since MShell uses DW4 for it’s “Updater”, “Virtual Disk Manager”, “Repository Manager” and all “internet connections”, the absence of DW4 will disable these functions. All graphics, music and sound functions should work as well. Only the DW4 MIDI capabilities are disabled in this respect.

The "MShell File Manager User's Guide" PDF file included in the zip will explain the installation and running of MShell. It will answer a lot of questions before you ask them. I finally complete the full manual as promised and I've tried to cover every aspect of running the MShell File Manager.

Any "release" of MShell is by NO means an "end product". MShell is always under a constant state of development. Each change or expansion reveals changes to old items as the MShell modules menus are constantly changing. Yes, there are still quirks and bugs and the error trapping is still being worked on, so having MShell to do something it's not designed to do may cause it to crash... with no error report. So if you do crash it, or notice odd behavior, please notify me and I will see if I can find and correct the problem.

At this time, most functions in the current modules are fully operational, but the dual directory listing feature of the File Manager alone is worth the price of admission (FREE!), which will allow you to browse "any" OS9, RSDOS or DW4 server's PC file system on (as far as I know) any form of file storage. Not only can you browse, but copy, move, delete and best of all, the selection feature allows batch processing of multiple files! This includes floppies, HDs, CFs, SDs, VHDs, DSKs, and should work on the CocoSDC and Coco3FPGA SD cards as well. If there's a NitrOS9 driver for the drive, MShell should be able to access it. If you have any problems with any media type, please let me know.

MShell is "DriveWire4" (DW4) compatible, but does not require DW4 to run. In saying "DriveWire4 compatible" I do not mean just DriveWire drive access, that is automatic as long as the drivers are present. I am referring to DW4's virtual ports, virtual printer, virtual modem, and virtual terminal window features. These various ports are MShell's link to the outside world of your PC's files, printer, and even the internet. See the "DriveWire4" usage page for more info on how MShell uses DW4. The absence of DW4 will cause certain features to not be available. MShell needs NitrOS9 3.3.0 (or greater) as it will no longer run under "vanilla OS-9" due to the use of a couple of "new" system calls available only in later versions of NitrOS-9. If DW4 use is desired, then I suggest using the latest release of NitrOS9, as some older releases have problems in the DW4 drivers.

MShell allows both Mouse and Keyboard control, so a Mouse is not required. Here is a quick "wrap up" of the MShell requirements:

REQUIRED

• Coco 3 (or VCC and Mess Coco 3 emulators or the Coco3FPGA (with or without the analog board)
• 6809 or 6309 CPU
• 512k - 2-meg of memory (512k min)
• NitrOS9 (v3.3.0 or better preferred)
• NitrOS9 Must have "CoWin" or "CoGrf" installed in the bootfile
• NitrOS9 Must have "pipe", "piper", & "pipeman" installed

OPTIONAL

• Joystick or Mouse
• Tandy Hi-Res Interface (supported, but not needed)
• DriveWire4
  • To use the DW4 features, you must have NitrOS-9 and these DriveWire drivers and descriptors:
    • The "scdwv.dr" driver
    • The "/N.dd" and at least 2 "/Nx.dd" descriptors
    • The "scdwp.dr" driver
    • The matching "p_scdwp.dd" descriptor
    • (all of these are standard in NitrOS9 "latest build" images with DW and Becker support).
• Internet Connection (with drivewire4 server)
• RGB Monitor (should display fine on Composite output)

Please report any bugs, strange occurrences, or alien invasions to the email address provided in the text document. When reporting a bug, please include all info. Your system version, memory, type of drives, and nature of the error and what happened when it errored. I will get back to you as soon as possible :-)

Next I will list some of the "proposed" features for MShell. Since this project is still in it's infancy, most of these features are not yet a reality. But, most of these features have been explored or used in other projects and will be adapted for use in MShell. I will try to keep the list updated with completed modules marked as such. Here's the List:

Planned Features for MShell:

File Manager (Working, 99% Complete)

The "File Manager" will be the "heart" of MShell. It will incorporate most features of the standard OS-9 file management utilities such as "copy", "delete", "move", "rename", "free", "dmode" and many more. The proposed GUI for this interface will be a two panel screen display; two columns of files in each panel. The two panels will each display a complete directory listing for that particular directory. Directories larger than the panel area can be scrolled with the "scroll arrows" or using the arrow keys. Each file listing can the be selected and a "context menu" can be access showing the command possibilities for that particular file. Each file's context menu will be offer commands based on the known file extension format. In this respect, text files can be "read", music files can be "played", graphics files can be "viewed" and archive files can be "decompressed" and much more.

Each "panel" can display any accessible drive on your system. One panel may be OS9 files from your disk drive while the other panel may be RSDOS files on an RSDOS partition on your DW4 VHD. Any given file may be manipulated in any "normal" fashion just you would from the cmd line or copied to any other drive on your system. The possibilities are endless. I have been experimenting with this part of the system in my other projects and have found that with proper programming, you can do anything with a drive.. no matter what the format. All you need is the proper tools. And that what MShell is all about. The File Manger will support several file systems. So far, the working file system support is:

• OS-9 File Format (98% complete) - Any OS-9 format file stored on any drive accessible to your OS-9 system. Completed so far:
• List and scroll OS-9 Directories (real or emulated)
• View individual OS-9 file stats of selected file
• Copy selected OS-9 file to any supported file system
• Delete selected OS-9 file
• Make new OS-9 directory within currently viewed director
• Batch operations of all the above
• RSDOS File Format (95% complete) - Any RSDOS file stored on your system. This includes RSDOS formatted floppy disks and RSDOS partitions on your HD or VHD (real or emulated). Completed so far:
• List and scroll any RSDOS disk or HD partition (real or emulated)
• View individual RSDOS file stats of selected file
• Copy selected RSDOS file to any supported file system
• Delete RSDOS file from RSDOS disk
• Batch operations of most of the above
• PC File Format (DW4 only) - Any File form your PC (Windows, Mac, Linux) from any drive on your DW4 host PC.
• List and scroll complete PC directories
• view 'some' of the file stats of the PC file
• Copy selected files to any supported file system
• Batch copies of file from the DW4 PC server
• Mount DSK and VHD images directly from MShell's PC dir listing, to your DW4 server.

SoundChaser - The Music/MIDI File Manager/Player (Work In Progress, 75% completed)

This feature will be offered via the new MShell version of SoundChaser and is based on my original Sound Chaser project. Based on the file's extension, you will be able to play music or MIDI files right from the SoundChaser module. The music/MIDI type will be determined by the file extension and the proper player is "forked" to play the file. Those formats marked as "working" mean I already have a working player for that format. Support for the player from within MShell has not yet been implemented but I should be releasing it soon. So far, the proposed supported file types are (by extension):

• UME - Files created by Ultimuse III (working)
• LYR - Files created by Lyra (75% working, still working on a slight tempo problem)
• MUS - Files created by Musica I & II (working)
• ORC - Files created by Orchestra 90cc (WIP)
• MID - Standard PC MIDI files (working, but with size limitations)
• CMF0 - Standard MIDI files converted to MFPlay format for OS-9 (working)
• BW2 - Files created by Bells & Whistles II (WIP)
• MOD - Files created by PC Mod Trackers, and based on Sock Master's "CocoTracker" MOD player (WIP)
• SND, AMI, MAC, & WAV - Digital sound files created by various "Sound Samplers" (WIP)

These formats will be played by external "forked" players in an invisible window with a "Now Playing" box displaying info on the currently playing file. This will be similar to the way music files are handled by my original Sound Chaser software.

Graphics Viewer/Editor (Work In Progress, 10% complete)

Also callable from the “Context Menu” as well as from the main menu, will be a graphics viewer and editor. Just click on a graphics file and choose to edit or view. I started the editor module a while back and really need to get back to work on it as there are many Coco graphics files out there. I hope to make this editor in the style of MV Canvas for OS-9 but with more functionality. I want to add the ability to view and edit old Coco 1 & 2 PMODE graphics as well as Coco 3 Hi-Res graphics. I will be looking at all the features of MV Canvas, CocoMax 1, 2 & 3 as well as ColorMax Deluxe. This editor will play an integral part in the “Desktop Publishing” module that is currently in planning. The editor will provide a way to create “clip” libraries for use with the publisher as well as an icon , pattern , cursor, and font editor for the OS-9 system itself. Since I just recently acquired an X-Pad, I will try to incorporate it’s use into the editor. The ultimate all-in-one graphics editor.

Some of the supported graphics formats are:

• VEF - Standard OS-9 Graphics format. Both compressed and non-compressed will be supported
• MGE - RSDOS Deluxe ColorMax 3 format
• CM3 - RSDOS CocoMax III format
• BIN, PM1-4, MAX, and others - Color Computer 2 picture formats including CocoMax 2 double page pictures
• GIF - Standard gif images from downloads.
• BMP -Windows bmp format
• CLP - Various clip formats
• FNT - Various font formats
• PTR - OS-9's mouse pointer
• PAT - Standard OS-9 "patterns"

I will be exploring the various graphics formats and incorporating any new formats I find.

OS-9 Archiver (Work In Progress, 10% complete)

Available in the context menus will be an archiver system. This will allow one to select single or multiple files and archive them to “lzh”, “zip”, “pak”, “tc3”, and other formats. The archiver system will also have the ability to “decompress” any of these formats as well. I don’t know if this will also be in the main menu choices as well since it is file oriented and easier to invoke by selecting files. This system is mainly intended for decompressing files downloaded from the internet.

Some of the supported compression formats will be:

• ARC
• LZH
• ZIP
• PAK
• TC3
• CUTS
• ARJ
• TAR
• RAR

Automated OS-9 Bootfile Creation (Work In Progress, 60% complete)

This module will probably be the most useful tool in the MShell suite. “BootMajik” (working module title) will prompt you for a few system requirement parameters such as desired system type (L1, L2 etc), desired CPU type (6809/6309) and then will display a 3 column screen with a list of available system, driver and support modules that fit the requirements in pane 1. When a modules is selected in pane 1, a list will be generated in pane 2 showing the required modules (auto selected) as well as allowing you to select from the optional descriptors/sub modules for that file. The 3^rd pane will show an ordered list of all the modules selected for the bootlist. The bootlist can be edited to remove modules no longer needed. There will be menu choices to save/ load and edit the bootlist. The a final “Create OS9Boot” menu selection will create the bootfile on the drive you specify. I plan to have support for all NitrOS9 systems as well as Level 1 & 2. The actual boot module files will be kept in a special database directory. I may even add a feature for the user to add new modules to the database and place them in the proper category. I hope to be able to provide short descriptions for what each module is and what it’s used for. With this system, you will be able to create an OS9Boot file for almost any Coco system on one machine…. Effortlessly!

Developer's Environment (Work In Progress, 20% complete)

With this module I wish to create a development environment for C, RMA, Asm, and Basic09. Possibly even an RSDOS assembly package. There will be a text editor for editing sources, a user definable compiler system, a source code browser that allows selecting files for editing or linking in the compiler, a C library builder for making your own C libraries, a Defs file builder for creating special purpose defs files, and a programmer’s reference library which can be called to review code syntax for the above formats. This set of utilities will make programming in OS-9 a breeze.

Here are a few of the programming environments I plan to support:

• OS-9 ASM - Standard OS-9 Level 1 & 2 asm command
• OS-9 "C" - Standard Microware OS-9 "C" as well as my custom "MJK C Compiler System"
• OS-9 RMA - Standard OS-9 RMA (Relocating Macro Assembler) as well as the "patched" 6309 version of RMA
• OS-9 Disassemblers - I'll be using "Sleuth3" by Bud Pass as it's the best OS-9 disassembler I've ever used.
• RSDOS EDTASM - It's my hope to add support for RSDOS assembly.

I've already started the Source Control module. At this point, it's being developed in a "standalone" mode as I need a source control system just to keep up with all the sources in the MShell project. I should soon have the "Coco Source Control System" (CcScS) up and running. I will integrate it into the MShell when I start work on the "Developer's Environment" module.

FTP Browser (Work In Progress, 50% complete)

Using a DriveWire4 server (Windows/Mac/Linux), you will be able to browse Coco Archive FTP sites such as the RTSI archive and view lists of available files in pane 1. Clicking on the selected file will give you the option to download to the OS9 directory listed in pane 2. The Coco will then download the file from the FTP and store it in the local directory then update the directory list. A batch selection feature will be implemented for downloading multiple files in one action. Your DW4 server must be connected to the internet for this function to work.

Color Computer Source Repository Manager (Work In Progress, 30% complete)

Using the FTP system above for internet access, you will be able to download sources from a special repository and build programs and possibly NitrOS9 itself from within NitrOS9 on the Coco 3 using the “Developer System” above. This will be much like using the NitrOS9 repository on Source Forge, but for the Coco compilers on the Coco, not cross-compilers on a PC. Also, for any Coco programs I can find sources for, not just NitrOS9. Your DW4 server must have internet access to be able to use this module. The detecting for internet access is handled by the program automatically. It will inform you if you have no connection. The manager will use the developers tools above for compiling/assembling the sources. For now, I haven’t quite figured out how to make the Coco upload to the repository as DW4 will only do downloads. So files will have to be uploaded via PC for now. I hope to come up with a solution to this problem soon. I will most likely provide a “Local User Library” feature as well. This will be a folder on your OS-9 file system in which to store your own sources privately and not in the online public repository.

Word Processor/Text Editor ( 5% complete)

I want to include a full blown word processor with “Desktop Publishing” features such as inserting graphics, multi-column text and others. I also want to include a 2^nd mode for a simple full screen text editor for writing simple notes and source code. The “Virtual Memory” system will be incorporated for a very large text buffer only limited by the memory of your Coco. On a Coco 3 with 512k of memory, this would equal about a 256k buffer as the MShell system itself will be using at least 256k. On Disto 1 & 2 meg systems, this will mean about a 1.5 meg buffer. I don’t think this has ever been done on a coco before so this will be a ground breaking project as will many of the other MShell modules.

DataBase (0% complete)

What better way to keep track of all the lists you can view with MShell than to have a built in database program that can catalog all your OS-9 program files, music files, graphics files, archived files, and from the PC with DW4, your DSK and VHD collection. This will be a massive effort to create one of the most useful integrated databases ever programmed for the Coco.

Disk/File Zapper (0% complete)

This will be a Ded style disk/file editor and possibly a memory module editor as well. Most of the features in Ded will be incorporated and possibly a few that come from elsewhere. With a built-in linker and a verify function, it will be a useful tool for patching modules, fixing disks, and recovering damaged files.

Telecomm System (Work In Progress, 10% complete)

This is just an idea at the moment. If I see that there is enough interest in this, I will continue as it fits well with the above “online” modules. That is to create a telecomm system to connect to online BBSs and TelNet servers. This is often discussed on the Coco mail list and I would like to see it come about. I will most li8kely use the sources to "Supercomm" by Dave Philipson as the templet for this module as it has most of the features that I want to support and most of all, the sources are readilly available in the NitrOS9 repository. It would also provide a way to upload files for the above repositories and FTPs. If this comes to fruition, it will most likely be one of the last modules I work on.

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

In Summary

These of course, are just proposed modules. Given the extent of the programming time involved, some may be a while in coming. But with most of these modules, I've either already started on the programming or have done extensive layout and planning. When you take into mind all the various utilities involved to create such a module library, there's quite a bit to be done. There have been many advancements and utilities already developed for MShell that I originally had planned to use in my other projects like DW4Man, Sound Chaser and HRSView, but ran out of memory. MShell will utilize the "virtual memory" system for storing array structures, buffers and databases. It will also incorporate Mike Knudsen's "Fragged" subroutine programming format used in Ultimuse III. This allows the main modules (the GUI) to link in "sub-modules" that share the same direct page and global variables as the main program therefore allowing easy manipulation of data from one module to another. To explain how this system works would make for an article in itself so I will not get into that here. Let's just say it allows a program to expand beyond the 64k workspace limit with unlimited modules that can be linked and run in the same workspace.

As a side note. all programs, subroutines, and modules are being written in Microware C, RMA, and OS-9 ASM programming languages as well as my "MJK C Compiler System using either a real Coco 3 running NitrOS9 or VCC 2.0.1c (used for compiling speed when overclocked). There will be no "Basic09" modules with all their "baggage". All files are compiled to 100% machine code for speed and efficiency.

All together, the "MShell NitrOS-9 System Manager Software Suite" is undoubtedly going to be one of the largest program projects ever attempted on a Tandy/Radio Shack Color Computer. This is a massive project with seemingly "unrealistic" goals, but I assure you, they are not as unrealistic as they seem. The "modularity" of OS-9 was never exploited to it's full potential and I plan to push the limits of OS-9 to it's max. 64/512k is not a limit, it's a challenge and I shall succeed :-)

I hope to be making a progress report soon and reporting on the development of the various modules and the programming techniques used to create them.

See ya Soon... Keep On Cocoing :-)

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

Well, I guess I better get back to coding or it won't get done. For now, here's a few screenshots of the progress on the GUI. Just remember, none of this is set in stone and will most likely change by the time I release a test version. The screenshots are from VCC v2.0.1b with Becker support running NitrOS-9 v3.3.0 on a 640 X 192, 2 color graphics screen. This has been tested a real Coco 3 running NitrOS-9 and the results are identical. VCC was used for ease of getting the screenshots as my Tandy CM-8 monitor doesn't photograph very well.

Click the images for full size viewing

MShell's Title screen The one of a kind drive selection feature

An MShell 4 column directory listing The "Award Winning" internet update routine

The DW4 MIDI device selector The DW4 MIDI profile selector

(These screenshots are actually very old. I hope to post some recent ones soon!)

More coming soon !!!

B.P.

web counter