The MShell Blog P5

It's been a long time... (05/27/2014)

It's been a long time since my last post, and I must say, MShell has come a looong way baby.

Since the last post, I've gotten OS-9 and RSDOS file browsing fully functional. The GUI has matured greatly and the menus expanded. Not only can you read OS-9 format drives in one panel and RSDOS format drives in the other, you can now copy RSDOS files to an OS-9 drive, and copy OS-9 files to an RSDOS drive (or HD/VHD partition).

Here's the capabilities as they stand for now:

• Read OS-9 file system directories on any OS-9 formatted drive (real or emulated) and display the directory contents in a panel which is scrollable and selectable.
• Read RSDOS file system directories on any RSDOS formatted drive (real emulared or partition), and diplay the directoy listing in a scrollable, selectable panel.
• Copy OS-9 files to the RSDOS file system, complete with proper RSDOS attributes
• Copy RSDOS files to the OS-9 file system.
• Delete RSDOS files from the RSDOS drive.
• Delete OS-9 files from the OS-9 drive.
• Create directories on the OS-9 file system
• Open directories on the OS-9 file system with a click of the mouse.
• Select drives from an automated drive listing, no entering drive names.
• Manage DriveWire4 Midi devices
• Manage DriveWire4 Midi Profiles for the dw4 MidiSynth
• Update MShell from the internet update site (from the Coco) via DriveWire4
• Select left or right mouse (or no mouse)
• Set Tandy Hi-Res joystick interface on or off.
• Complete keyboard control if no mouse or joystick available
• Turn the system 'bell' on or off
• System defaults save to a preference file
• Auto sensing of the current 'default' drive and CMDS drive,
• Intelligent config utility to set default system directories
• Select your own screen colors (saved to preferences)
• Screen refresh
• Dual dynamic virtual memory buffers for low OS-9 memory use
• "Fragged" sub-routines for loading custom modules

These are just the completed features I can think of at the moment. I know there's more... and many more coming.

For the past two weeks I've been running a public test release to see how well MShell functioned on it's own with others. With the help of Robert Gault, Kip Koon, Bob Devries, and Bill Noble, a lot of little bugs were completely eliminated and new features added. There have been cosmetic changes at the suggestion of the testers, mis-spellings corrected, and many other things that could have plagued MShell later in developement had they not been found now.

After 2 months of running MShell, I can say the virtual memory system is rock solid. Changes from one v-mem buffer to the other goes smoothly and transparently. I may even create a third buffer to for "general" use to store temp variables and such. This is almost inevitable to get OS-9 to OS-9 file copies working as I need buffer space for the transfers. This is all that's holding that particular feature back. The other "standard" OS-9 utilties are much easier and will fall into place quickly. Utils such as "rename", "deldir", "attr", "dmode", "wmode" etc. These are fairly simple to implement but.....

With all the virtual memory and fragged subroutines, I'm still running out of memory in the 64k program workspace. The cause of this is that to get all the current features functioning quickly, I coded most of them in MShell's main program. This was not my original intention but came about due to getting in a hurry, and for ease in bug fixes later. But with the subs running well and showing no signs of bugs, I should be able to start moving things around soon to get everything into the fragged subs where they belong. This will clear a lot of the 64k workspace to make room for more features.

This has become the next step... optimizing MShell to reduce memory and fraggin out all the disk routines. I now have to get MShell down to just the "shell function" of handling the input and output to the fragged, forked, and piped subs. The code got out of hand in trying to get everything woking, so I'll most likely stop at this point and do a complete re-write of the main program. I have to try to "localise" all the sub's variables to the subs without using precious space in the global variables file as this file will eventually hold all the flags for every module planned. The bad part, is that within the memory constraints of the MShell system, I only have 8k for the global variable space. So I have to be careful what I put there. I have to consider if it's going to be used by all modules or just one. This makes my next task tough as I have to design a variable system that keeps the globals available system wide while at the same time, loading each sub's local variable in with the subroutine and into this global file. This is not an easy task as each fragged sub can only be 8k in size as well... and that's inluding it's variables. I have a couple of ideas, but haven't quite worked them out yet, but I'm sure I can find a way to make it work.

The whole idea is that each sub has to stand alone as to be able to load it into any "main" module I may be running at the time. This means each main module must share the same global file and function pointers, but at the same time dynamically load and unload variables that reside in only the sub-modules. I've got a feeling this will require using several "global" variable modules that only get compiled into the sub in which they are used. That part is not so hard, but getting the already established main module to load new variables into it's system without increasing memory is going to be a "trick with a hole in it". But I really feel it can be done. As I said, I have ideas, I just need to reorganize things so I can work this type of coding into the modules. The real problem is MShell's strict memory mapping. To keep the virtual memory and fragged subs from failing, MShell has to work within certain limits or it will fail.

The main module can only occupy $9E00 bytes of the 64k workspace.

Then the global variables occupy $2000 bytes (8k) (shared by all modules and subs)

The Gep/Put buffer for the virual memory block has to be reserved at $2000 bytes (8k)

Then the fragged subroutine takes up the last $2000 bytes (8k)

That leaves about $200 bytes for the reserved system copy to reside in.

If any of these boundries are broken, MShell fails with a big train wreck!

As you can see, there's not much room to work, but the modularity of OS-9 makes it possible to do things a little different and a lot of things can be "split up" and made into their own fragged subs. The good thing is that a fragged sub can call a fragged sub, and once it's done, reload and return to the correct position in the original sub. But only if everything stays within the above framework.

The rewrite of MShell will be a slow process as I will be trying more new ideas to make all this happen without breaking the rules. MShell stays within the OS-9 program guidlines and never breaks the rules to access memory directly. All subs use standard OS-9 system calls to acomplish their magic and I want to keep it that way.

So I guess I'm to do some rewriting... wish me luck :-)

Bill Pierce

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

Prev / Next