The MShell Blog P3
No Graphics for a Graphic User Interface (12/31/2013)
You never know how "in depth" something is until you dive into it's "depths". In stripping the Ultimuse3 sources and taking it down to the bare bones of a GUI, I see more and more just how complex this software is. Part of this complexity is the graphics handling routines. Mike Knudsen did not use any C graphics libraries and avoided most graphics oriented system calls. Instead he wrote all his own graphics routines from scratch. This includes copying the screen page into his workspace, drawing directly on the screen page and copying it back. Suprizingly, the routines are small and fast. Ultimuse3 uses hundreds (literally) of "icon" type graphics to display the multiple staves and hundreds of notes and score symbols on the user's screen. The score editor is very complex in it's ability to edit a music score not to mention playing the music itself. In stripping Ulimuse3, I've decided I need to strip all the elements of the score drawing functions. This is no easy task as there are parts of this in almost evey one of the functions. Eliminating one item can sometimes lead to 30 or 40 edits in various sources in reference to that item which can lead to disabling another related item which leads to more edits. Ultimately, everything is connected and changing one, changes all. What makes it all so hard, is that even thought the Umuse3 sources are pretty much organized into catagories, as the program grew over the 7 or 8 years that Mike worked on it, as a module out grew it's size limit, Mike would move sections of code to another module that had more room or he would just create a new fragged sub-module for the code. These actions spread code parts all throughout the sources (125+) and makes them tough to trace down. Removing all references of a variable without breaking the functionality of the GUI becomes a difficult task... But it must be done.
The graphic icons are loaded uniquely as some are loaded from a file ("/dd/sys/AllUm3.img") and some are loaded from data in the sources. Included in the graphics data is the data containing the mouse pointer graphics, menu boxes, check boxes, etc. So I find myself deleting an item... compiling the code... correcting any other references to the item found in compilation... re-compiling... (rinse and repeat) then finally running the program. One by one I'm eliminating all the unwanted elements to leave only what's needed for my GUI. It's a slow, long process. This delete/test/delete/test routine is now the major holdback in getting the v-mem functions in operation. The one good thing all this is acomplishing is that the source files are getting smaller and smaller and making room for more of my own code. One thing for is for sure... I need all the room I can get. I need to get the direct page and global variables down as small as I can to make room for the tons of stuff I will eventually be adding.
My ultimate goal is to reduce the main program down to a size that allows me to use 16k fragged sub-modules as opposed to the current 8k modules. This would make the modules easier to write as well as give more room for more features. Even at 16k, some modules will still be divided up into 2 or 3 modules and some will still be forked to their own 64k workspace as there's no way to implement these in a small workspace. Since forked modules inherit the parent's I/O paths, the forked modules will automatically be already piped to the (forked) graphics handler and will use the mouse, cursor and hi-res text functions. It's even possible to have the forked modules to have their own "fragged" sub-module system which expands the capabilites even further. The overall limit here is the 512k total memory. If the host Coco system is running the Disto 1 or 2 meg upgrade, MShell will utilize the extra memory. I have a 1 meg upgrade in my own Coco 3 and Vcc Coco 3 emulator will run in 2 meg mode so this is tested for thoroughly. I also set Vcc for 512k ocassionally just to make sure I haven't overstepped the 512k boundries. With both the Coco 3 and Vcc running from the same DriveWire4 host, testing on both platforms is a breeze. I do most work in Vcc but check the progress on the Coco 3 constantly. I will not make the mistake I made with DW4Man and end up with something that does not run on the real machine but runs on the emulator. This software suite is meant for a real Coco 3
Memory to Spare... (01/07/2014)
After hours (read days) of playing with several methods of setting up pointers into the virtual memory system, I finally got it set up to use 2 dynamic (and structurally different) buffer systems in one program. The structure of the bufferr arrays can be changed on the fly. I needed this as the main use for my buffer arrays is to store the filename listings for 2 seperate drive systems that could at any time, either one could be one of 3 different formats; OS-9, RSDOS and PC formats, each having it's own structer for variances in filename length, dating format, access and others. I've only been testing with the OS-9 structure but will be testing the RSDOS and PC structures later tonight. This all leads to the next step of which I've already started, but needed the structures in place to complete. And that is setting up the display systems to display directories of 2 differnt drives (2 columns each) in dual panels on a Coco 3 Hi-Res screen. I'll most likely use a fragged sub in which to call only when the display needs refreshing for a panel. I may even have to create a sub for each of the structures. The fragged subs have a limit of 8k with only local variable (no globals) and that makes it hard to keep it all in one sub. The OS9 and RSDOS structures will be display in 2 columns each in scrollable panels.
Because of the possible length of PC filenames, those directory listings will be display in single column (still 2 panel for the 1st & 2nd drives). The screenshots below show a 4 column OS9 directory listing but without the panels. The end display will feature dividing lines between the panels (not the columns). I'm working on a way to "highlight" the active column. Since (for now), I'm only using 2 color graphics, this is not so easy to do. I may try to go with the 80 col 4 color mode but that would mean changing the very stable graphics routines and I don't know if I want to mess with that yet. Four colors would simplify many things like highlighting selected files, Directory names in a different color, wanings etc. But I'll worry about all that later. My core graphics work, they're dast and stable and "if it ain't broke, don't fix it" (yet :-).
With the V-Mem routines working, the fun stuff starts. Setting up drive selection, file selection, panel selection, status bar, menu systems, screen layouts, etc. This is actually the part I enjoy. Designing the front-end and seeing the immediate results has a lot of gratification. There's something about seeing it all roll onto the screen in it's proper place that makes me smile. And this is only the file manager !!
I still have many other modules to go.
And Awaaay Weee Gooo.... (01/08/2014)
After a couple of hours last night, I had the virtual memory system stable. The next several hours were spent playing around with making the front-end display behave like I wanted.... then came the ideas. Once I get on a roll, I can go for days with little sleep, lots of coffee and a BIG dose of imagination. This is the mode I'm in now. With every little routine I work on, ideas for 5 more jump in my head. The menu layouts are starting to fall in place, the mouse routines are gettin' some cheeze, and the subs are piecing themselves together. This is when I love programming, when you take all the scraps and pieces that've been bouncing around in your head (and on your hard drive) for months and weld them all together into something pleasing to the eye and easy on the mind, which is the ultimate goal for MShell. Today and tomorrow will be good days as MShell takes leaps and bounds over it's current state and becomes something useful instead of just a thrown together GUI with some inactive menus. Even the directory page scrolling routines are coming together. If all goes well, by the end of the weekend, I should have the OS9, RSDOS, and PC file managers in place and running. Once the file managers are working, I can start putting together some subroutines. Players, viewers, readers utilities, etc will all come together quickly. Most of that work is done, I just need file lists to base them on. Then comes the major work. The internet FTP browser, the sources repository, the bootfile creator, and many others. That's when the programming gets serious and the loops get tight!
I've had several people to ask me why I go to all this trouble for a 30 year old outdated 8 bit computer. I have only one answer and it's the same one I had 30 years ago when the Coco was fresh and new....
Because It's FUN!!!
They Say the First to Go is the Memory... (01/16/2014)
Well, it's virtual memory problems again. Nothing major, just a pointer bug somewhere in the code. In trying to read and list the second directory, the wrong block is being mapped into memory and the directory is lost. Somewhere, I have a pointer out of place or mistyped. It's just a matter of tracing it down and smashing it. Until then I'm still working on the menu system and directory displays. So far, the toughest thing is how to switch emphesis from one panel to the other and still monitor if the user is clicking the main menu bar. I have some nice menu selection routines, but for the most part, they lock the cursor response to the listing area. I have to find a way check for mouse clicks outside the work area and respond if a valid area such as the menu bar. This will also allow that if the cursor is on the non-active panel, then that panel will be activated and the active panel is put to sleep. I'm not sure how I want to implement this yet, but things like this is what I'm working out now.
Within the Umuse3 GUI templet, there are 3 different types of menu selection. The first is a push-button menu. This type surrounds the menu selection with a box whose shape signifies the type of menu selection the item portrays. The second is the mouse scrollable selection in which the item is highlighted by reverse colors as the mouse passes over the item. The last is the check-box selection which allows the user to click a check-box to turn a feature on or off. All of these selection types also allow some sort of keyboard selection as well. In fact, almost all functions can be accessed by mouse or keyboard (so far). I am going to try to keep it that way. Since my Coco 3 has an Eagle AT keyboard interface and a full PC style keyboard, I have to remember not to program for keys not found on a normal Coco 3 keyboard.
*****************************************************************************************************************
