DW4Man

The Award Winning DW4Man

!! Beta Release !!

"You won't like me when I'm plugged in !"

Title screen Listing of PC directory

Mounting a disk from PC Using the Directory Database

Credits First !!

First and foremost I would like to thank Aaron Wolfe for all he has done to make this possible. Not only has he modified DriveWire 4 to meet the needs of DW4Man, he has put up with numerous emails from me filled with question after question or arguing some method of data transfer. He has had a lot of patience with me and I really appreciate all he has done.

I would also like to thank Robert Gault, Bob Devries, Gene Heskett, Michael Knudsen, Lester Hands and all the people on the Coco mailing list. Without their help in answering all my stupid programming questions, this program would have never happened.

Thank you... Everyone !!

Note: The order of the blogs have been reversed from last to first to make reading the most recent post much easier.

To read them "in order", just start from the last message and read them backwards.... standing on your head. :-)

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 Ultimuse3 software suite. It will not be an easy task. I will be leaving all the mouse, text, menu, dialog and disk i/o functions "as is" 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 checks 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 major 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 :-)

Making it all come together... (05/03/2013)

Wow, the last couple of weeks have been really strange. I have spent this time trying to get DW4Man ready for The Coco Coding Contest. After a week of tweeking, I thought I had it ready then found some really strange things going on in VCC. First, I had been running VCC heavily overclocked to speed C compiling and just by chance the other day, I slowed the clock down only to find the DriveWire communication is very bad once it's at normal speed. After a lot of tests by Aaron Wolfe and myself, we've determined that the problem is my DW4 driver is being over run with the data returning to the server. When overclocked, it can keep up. Aaron assures me it works fine on the real Coco and the problem seems to be isolated to VCC and the Becker port.

So needless to say, I finished up my edits and submitted the program "as is" to the contest. A few days before Cocofest, I had a brainstorm and told Aaron to hold his review as I was about to make a big change. DW4Man now has the ability to update itself from the internet and restart with the updates. After a few tests and a lot of coding, I finally got it to work. Now you can select the "Update" selection from the menu bar and DW4Man will log on to the internet through DriveWire and check for new updates. If there are updates available, it will download the files, set the attributes and restart itself in the new version. If I'm not mistaken, this is a first for a Color Computer program of any kind! With this final addition to DW4Man's arsenal of capabilities, I let it go to the Fest. Guess what?

I WON!!!

!! DW4Man was selected best new program of all catagories at the "2013 Last Annual CocoFest" !!

Sound Chaser was selected best Sound Program and was enjoyed at the fest as well.

Now that the contest is over I'll most likely take a break from both DW4Man and Sound Chaser and work on some other projects. These two programs have occupied my computer screen for about 9 months straight now. It's a wonder if they didn't burn an image of DW4Man into my monitor. It's time for a break. I may be visiting back every once in a while with a bug fix or two, but for now they go on hold.

I will definately be coming back to try and fix the Vcc/Dw4 problem with my driver and will eventually do a complete rewrite to use a more multivue type screen with mouse/joystick control and most of all finish the OS9 file manager module. I actually have a lot of this done but to be honest with you, I'm really burned out on this program for now.

So until I get back at this, I guess this is the end for now.

I would like to thank everyone for all their help and support. Without all of you, I would've never gotten this far with DW4Man or Sound Chaser.

Thank you... and good night

Would you like some sound with that Midi?... (03/11/2013)

It's been cleanup time in the DW4man realm. I've been running the program over and over, looking for anything that may not be displayed or running the way I want. I finally remembered that I needed a way to show what directoy the PC disk manger was currently viewing. I added a "Dir:xxxxxxx" to the menu bar that shows what directory that Drivewire is currently connected to.During the past few days, I've been trying to finalize a lot of the routines that have already been coded for DW4Man. A lot of the routines have little bugs, like dialog boxes with text not starting in the proper location, menus not refreshing, those kind of things. The things that "bug" ya, but don't interfere with program operation so you just ignore them because you're working on that "next big" routine. Another thing I've done is to add a "Sound Chaser" menu option to the main menu. This option allows you to run my Sound Chaser Multi Format Music Player right from DW4Man. I figured that since I was doing Midi setups, I might as well tie into Sound Chaser. I may put this option in the Midi menu as well as that's where it really belongs. I've even though of adding DW4Man functionality to Sound Chaser allowing you to run DW4Man functions from within the program. I'll have to think about that one a bit. I still haven't started on the OS-9 file manager section of DW4Man, but I have a feeling I may try to get it in before the CocoFest debut. It's a matter of finishing up what I have and working out all the little things. If I get to a point where I feel there's nothing else I can do to the current routines, I will start on the file manager.

I also finally got around to setting up a VBox for Linux so I could test DW4man's displays against the Linux file system. I was pleased that most things worked as planned. There was one problem with displaying the root directory as on the Linux version of the Drivewire server it comes to the Coco as "/". I had a filter that was jumping past a single character entry as a delimiter and it was blocking the root dir from displaying. After an hour or two of going through all the code, I fanally located the problem and now all the Linux directories display properly. I have to give Aaron Wolfe credit here for his completeness in covering all the bases in his Drivewire server. One program, all machines. By keeping most of his server reponses "generic", he made it easy for me to use DW4Man to display different formats with out writing a different routine for each machine respnse. Thank for all the extra work Aaron. Now I need someone with a Mac to test DW4Man. Aaron tells me the Mac resonses will be similar to the Linux respnses, but I know "similar" can mean disaster in blind programming for a machine I don't own and have never run. So if anyone with a Mac Drivewire server and a Coco 3 running NitrOS-9 with Drivewire who would like to test DW4man, please contact me by e-mail or on the maltedmedia Coco list.

On with the show... (03/02/2013)

I now have the DW4Man routines split into sub-programs that are loaded as needed. I was having some problems with my display, but I think I have that worked out now. It was a matter of one variable using base 1 and another using base 0 therefore making the display routine either count one too many or in other cases one less than needed. Anyway, it looks good now. The PC directory routines are just about done except for adding the filter so only virtual disk files are shown. I've started the Midi sub so I guess the next thing will be the file copy and list routines. These routines will allow the user to move files to and from the PC and the Coco. If all this comes together in time, I may try to add an OS-9 file manager sub to manage the native OS-9 drives whether they are real drives, DW drives, or virtual drives on the SuperIDE CF card. OS-9 has needed a good file manager UI since OS-9 Level 1 and I think this program interface just may do it !

The OS-9 file manager sub would allow you to copy, move, delete, view, list, or run just about any file on your drive system. I want to make this part look similar to the old version of Windows Explorer with two panes, the left pane being the directory tree and the right being the contents of the selection on the left. With my current method of directory handling of the PC directories, I think I can make this work well. The big decision will be whether to use outside cmds for "copy", "del", etc or to write built in cmds. The more cmds I write in, the less room I have for record keeping of the directories so I may use the external file cmds. Some cmds are built into C already and that will help some. The OS-9 directories and filenames will be much easier to manage than the PC names because of the smaller size limitations. That will make my database arrays much smaller and easier to work with. Whether or not I get this routine in before CocoFest time will rely on how quick I can get the other routines in working order. I do know that after the Coco Coding Contest is over, this program will go through some MAJOR changes and a lot more stuff will be added. Well, it's time for more coffee and more coding.

Round and round we go... (02/06/2013)

After trying the new "ui" API set for Drivewire, I found that the response formats used in that set are still too verbose. Without going into details, Aaron finally made a new command in the "ui" API that would give me most of the info I needed for files and directories. He also changed all the delimiters to the same character and that will help a lot. The rest I will just "deal with it". So now I embark once again on that wonderful journey of re-writing the all the DW routines in the manager to fit the new commands...... again. After much experimentation and elimination of a lot of code due to low memory, I finally have the manager going from directory to directory so I can browse my PC from the Coco and mount virtual disks into DW. The problem is that the data structure is so large to make room for long PC filenames and directory paths, there's no room for anything else. Now I know I will be breaking down different sections of the manager and using the same forking technique for the various subs that Sound Chaser uses for it's various players. That's the only way I see that I might get all the features into the manager that I originally planned. I don't know how they'll be layed out yet, but it looks like the virtual disk database will be it's own sub as it has the largest data structure and uses the most memory. Again, a good bank switching system would allow for a lot more memory storage but I'm getting too close to the Coco Coding Contest deadline for entry to try to set that system up now. It may still be a future option but for now I'll stay in the 64k workspace.

I'll be spending the rest of this week deciding what routines will go in what external subs. There will most likey be 4-5 subs. I was hoping to get it all in on file but there's no way to do it with the number of long strings I have to work with. The one really good thing that is coming out of all this is I have a very good idea for a file manager for OS-9 itself. I may start that project after the contest is over. I want this program to be in some usable form for the Fest. I know Aaron will be showing it then as well as for the contest. I'm still waiting on Aaron for one or two more things that needs to be done to DW for this to work properly. But at least now I have plenty to work on.

Here we go again... (01/14/2013)

Aaron finally decided that creating a new command API would involve too much rewriting of the Drivewire interface, so he fixed the original "UI" command set so that it would work from the Coco. The "ui" set gives responses more suitable for machine parsing than the "dw" set as the "dw" was meant more for readable text responses for viewing. The "dw" contains a lot of text not needed by a command parser. Now with the "ui" command set back in place, we might just make some major porgress. There are still a few things that Aaron and I are ironing out in the API but overall, it will be easier to parse and not use nearly as much memory. Now I have to go through all the current code and rewrite the routines to fit the new API. It may even be easier just to start from scratch with the menu skeleton and write the commands over again. The returning responses have major differences from the "dw" command set that I was using. I will still have to use a lot of the "dw" set to write the data back to the PC as the "ui" set doesn't seem to do much "writing". At least the "dw" set doesn't require the "verbose" format in writing back to the PC. Most of the commands are straight forward on the write routines. So basically, I will be using both command sets to get all the things done that will be the core of the DW4Man protocol. While I working on some disk routines the other day, I came to the realization that I had been writing all this code for Windows formatted directory responses. I hadn't even considered the fact that this program will be accessing all kinds of operating systems as Drivewire 4 will run on many systems including Linux and Mac. Now I have to find Linux and Mac users and get them to send me copies of various responses from Drivewire so I can make sure DW4Man is printing the proper data to the screen. I think Aaron is making a couple of changes to the API to make parsing a little easier so there are a couple of commands that I can't write routines for until he makes the changes. So I'm back to the waiting game again. I know Aaron has been really busy over the holidays with a major client and hasn't had much time to work on Drivewire so I have to be patient and wait till he gets the time. Until then, I'll be making my conversions for the new API and trying to sort out just what DW4Man will be capable of doing. My next post should be full of major advancements.

I would like a menu please... (01/05/2012)

I've been doing as I said and working on the menu systems. I had functions listed that I see now as not ever being finished and some that were just in the wrong place all together. I've cleaned them up pretty good and I think I have a good, working menu system now. I then started working on the "selection" routines for the database selection and it's come along nicely. The thing now is deciding how I want to catalog the database. The problem is I give the user a choice of up to 10 PC directories to view from then they can view the contents of that directory on the screen and select files for the database. In doing this, memory has become too short to store the actual database while the directory is being displayed. I know, again with the memory right? Well, when you only have 64k for a workspace, it doesn't take long to fill it. I've been looking at various ways to reference the files using an index system, but I still come down to the point I need to store all the filenames in arrays. With the massive arrays already in use for just viewing the directories, the database arrays will run me out of memory. I'm still working on a fix for this as it's a major priority to be able to load and save databases of user defined disk sets. This was what inspired the program to start with. This not to mention that I've yet to set up arrays for the Midi and config parameters. That's a whole 'nother ballgame.

I've been trying to decide if I want to release a Beta version of DW4Man. I originally wanted to wait and let it debut for the Coco Coding Contest at the "23rd Last Anual CocoFest", but it's becoming such an interesting project that I want people to see it. In it's present form, DW4Man is already a usefull program. But when it's done, you'll wonder how you ran Drivewire without it.

I been searchin' everywhere.... (01/03/2013)

Today I got a lot of un-needed menus, variables and unused subroutines out of DW4Man. This cleared up a lot of memory that was being taken up by these. It should open the program up for more stuff that is needed. I also managed to add a search routine in. Now you can search the displayed PC directory for any given string up to 33 characters. This will make it easier to find a given disk or file. I still need to work on the program being able to distinguish a file from a disk or directory. Aaron keeps telling me this will be much easier with the new cmd set. I've yet to see the prototype of the new cmd set but it sounds like it'll make my life easier and get this program done quicker. I also rearranged the menus a bit to make them a littler more user friendly. I really need to work on my menu structure as it's kind of scattered about for now. This would make a good project for a couple of days. I may just do that.

The Killing of Pete and his brother Repeat... (01/02/2013)

HAPPY NEW YEAR EVRYONE!!

I have spent the past couple of days going through hundreds of lines of code trying to eliminate repeated routines, un-needed code, and debugging code. I was really suprised at how much space I'm freeing up. There are a lot of sections of code that are reused in other subs, so I'm trying to create general subroutines that these routines can call and not keep repeating the same sections of code. This alone is opening a lot of space in the program. I also had a lot of variables set up that were used in routines that eventually got scrapped and the variables were no longer used. If this keeps up, I may just be able to contain this in one program as I originally intended. Only time will tell as I've only started on the basics of the Dsik routines and a couple of the Midi routines. The disk database has yet to be created. This alone could use a lot of memory for the arrays unless I resort to using a database file to store the database. This would cause a lot of disk activity when accessing the database, but since we're dealing with Drivewire and not real disks, that may not be so bad. This way, I can keep the current PC disk directory in the memory array and add files to the database as they are selected. Then the directory path could be stored with the filename and I wouldn't have to worry about the memory I'm using. When you consider the length of some PC filenames and the length of the PC directory paths to these files, then multiply that by the number of records you intend to store in a database, this can grow to be quite a large array of data. Then add in a few flags covering the type of file, can it be loaded, can it be mounted, is it a directory... It starts to get pretty complex. Using a disk based database, I can just load a record as I need it based on it's index into the file just as if it was in memory. On an old disk based OS-9 system, this would be a lot of disk activity and extremely slow. Anyone who has used a disk based database on a Coco knows how slow this can be. But since this is exclusively a Drivewire manager, it's assumed that the default directory is on a virtual disk and disk access is pretty fast and amost transparent.

I'm going to continue to optimize DW4Man as much as I can to get the size down as much as possible with hopes of keeping this a one file program. I really don't want to break this up into several utilities as that really defeats my purpose.

Capan' I can't hold her any longer... she's breakin up... (12/29/2012)

I think I have finally come to the conclusion that DW4Man is going to end up as a suite of programs. The 64k workspace in OS-9 is just not large enough to hold all the routines needed to make up the full porgram. It's slowly beginning to look like I'll be writing a main menu system which will "fork" subroutines as needed. Kind of like the origianl "Deskmate" & "MultiVue" both of which had seperate programs operating under one windowing system. As a program was needed, it was forked into another 64k workspace but using the same window, therefore seeming to be one program. I will most likely be breaking up DW4Man into the various DW4 catagories.. Disk, Server, Config, Midi, & Net. This will allow more variable space for each form. Since DW4Man is set up using a menu structure similar to Sound Chaser, it will be easy to break things down as Sound Chaser itself does this very thing. Sound Chaser is just a menu structure that reads directories for music files and sorts their formats. Then as files are played, the proper "player" is forked in another 64k workspace and the file is loaded and played in that workspace. In DW4Man, individual programs will be loaded to work with dsk/vhd files, edit the config file, edit the Midi parameters, set the server, and modify the network.

I'm still playing around with the idea of using the get/put buffers as this would solve many of the memory problems but I think in the end, it's not the data I'm going to have a problem with but the size of the code itself. Working with large arrays of strings in C under OS-9 is a pretty complex task and takes a lot of coding. Especially dealing with the type of filtering I'm having to do for now. If Aaron get's the new cmd set to me soon, things may change as all the filtering can (hopefully) be eliminated. As it stands, it doesn't look like he'll have it done before the deadline for the CocoCoding Contest so I'm just going to work with what I have which is the "dw" cmd set. Only time will tell...

Breaking the bank... (12/28/2012)

Well... I couldn't stand it. I had to work on DW4Man some more. I've been working on test filters and a way to format the "off-the-wall" output of the Drivewire "dw" command set. I've actually been successful in getting the directories sorted out by using a method of "single byte" reading of the returning texts. It took about 4 filters and three or four comparisons to determine where one entry stops and the other begins, but for now it "just works"(TM). I have the disk manager to the point you can scroll through the PC directory listing and select files for the Disk Database as well as mounts disks directly from the listing. The only problem is I'm running out of memory. My 64k workspace is too small to actually add the database arrays. I don't think the program has grown that large as Sound Chaser is larger. I think the problem is in the way I have the arrays laid out. I will be working on this as well as removing unused variables that were put in for testing and never removed. If just the disk database arrays are eating this much memory, then I know the Midi and Config editors will suffer this problem as well. I'm going to have to pull the arrays out of the 64k workspace so the programs have room to run. I may try using the get/put buffers for data storage. I know I'm going to have to break each function down into smaller programs and work with the memory usage before adding them back into the main program. If things get too large, I can always make it a modular program with seperate routines forked from the main. I didn't really want to do this, but it's always an option with OS-9. I was hoping to keep everything contained in on file for easy installation and copying.

I'll keep pecking at it and see what I can come up with.

Lions, Tigers and Bears... oh my! (12/15/2012)

I've been working on getting DW4Man to return proper strings from the respnses from the Drivewire "dw" command set and it really has me pulling my hair out. I was working on putting the responses to a PC dir into arrays to create a database of "dsk" & "vhd" files. I thought I had it licked as the directory I was working from was printing out properly until I switched directories and come to the realization that Aaron had formatted the responses according to the length of the returned texts. If ten entries would fit in a 56 column line then it prints that way. If one entry is longer that 56 characters, the the whole listing is formated at single column. Basically, the number of columns in a list is determined by it's longest entry. So, different directories will have different column counts. This means some responses will be padded with tons of spaces between entries and some will not. This is not to mention the 256 character buffer that is used by the server. Each response is sent in 256 byte "packets" until the last packet which is based on the length of data left to send. In these 256 byte packets can be several entries complete with CR's and LF's. The LF's have to be filterd as OS9 hates them and the CR's are the end of a line so they need to be recognized for creating the database entry. The entry name can even be broken and part in one packet the rest in the next. There's no way of knowing in advance if a "line" will contain more than one entry so the only way of checking is for multiple spaces seperating the entries. If the length of two entries works out to include just one space between them there's no way of determining if this is an entry with a space in it or a break between entries as PC's will allow multiple spaces in a file/directory name. Aaron has informed me this issue has been addressed in the new API, so this project may just go on hold until I recieve the new version of Drivewire 4 with the new API installed. Writing a bunch of very complex text filters that will be discarded as soon as I get the new API is just not desirable at this moment.

So, I've officially put "DW4Man" on the back burner until the next release of DriveWire 4 which will include new cmd sets and a new API for machine control. Hopefully Aaron works on it over the holidays and I will have at least a beta copy to work with by Januaury.

Until then...

What goes out, must return... (12/14/2012)

I've made quite a bit of progress the past couple of days. After several grueling hours, I discovered that OS9 C and CGFX-7 does not like to "flush" strings without carriage returns until it feels like it. It seems there's a clash between C's buffer and CGFX7's buffer and niether wants to deal with the other. The easy way out is to terminate the string with a CR but sometimes I'm on the last line in a window and do not want it to scroll as it will once a CR is introduced. This basically makes the last line of a screen useless. On another note, I've got the program reading directories from the PC hard drive. storing them in arrays and then displaying them on the screen in such a way as to make it easy to select files using the arrow keys. I've still yet to investigate much further into mouse usage as the Multivue type menus are a bit much and require you to set up control areas and stick to their format. Personally, I like my format. I have the prorgam to the point that I have to decide on how I want the menus arranged and start dividing up the program into sections for ease of editing. From the way it looks so far, there will be config, Midi, disk database, disk maintanance, dos commands and an expert mode for direct entry of DW commands. As I start pulling some of these menu sections together, I will post on how they unrravel into the routines themselves.

To View... or nor to View... Multivue that is (12/11/2012)

I was messing with some of the functions in Dw4Man and found the mouse works perfectly fine on a hardware text screen. I thought I had read somewhere before that you could use a mouse on the text screens but that the mouse pointer would not be available. I found this to be the case and have been racking my brain trying to figure out how to impliment a mouse pointer with text. The easiest way I've seen it done in other programs is to invert the text under the mouse position much the same as a text cursor does. My problem is figuring out how to set up the pointer so that is active all the time unless I choose to turn it off. I guess the best way would be a VIRQ. Having wonderd if this could be done from C, I asked on the Coco forum and was told it "may" be possible. I've yet to test this idea as I've never used VIRQs and I'm a little hesitant about trying. I'll probabally try sometime in the next day or so. The worse thing that could happen is the program will crash.... How many times have I crashed it already <laughing>. If I could get this to work, this would be the first step to making DW4Man mouse controllable. This is one of the most requested features for Sound Chaser and if it works here, I will use the same techniques in the next update of that software as well. In reading the docs for CGFX-7 to find info on mouse control, I saw a lot of simple commands for various functions that I am currently writing complete routines for. There are function calls for a Multivue like windowing interface which I knew was already built into CoWin (WindInt). I never liked Multivue, but given the ability to use that type of interface in a hardware text window, it may be just the thing I'm looking for. I think the next step with the GUI, is to start a new version from scratch and start using some of these library calls I'm reading about. Between Mike Sweet's CGFX-7 and Karl Krieder's Clib.l, a lot of complete routines can be replaced with simple, one line commands. These libraries are already being included in the program for use of the menu functions so why not use them to their full potential. This would give me a fully mouse driven program using less memory than I'm already using with room for more features. Sounds like a winner to me.

So I guess the next few days will be spent rewriting the DW4Man GUI structure using the CGFX-7 library functions and creating a mouse driven GUI.

In the beginning... there were cassette players.. (12/10/2012)

When I started using Tandy Color Computers, I had a Color Computer 2 with 16k ram, Standard Color Basic (not ECB), a cassette tape recorder for loading/saving programs, and an Orchestra 90cc Stereo Music Synthesizer program pak.

The Tandy Color Computer has "come a long way baby..."

My "Coco" system now consists of a Tandy Color Computer 3, 1 meg memory expansion board, an Eagle AT keyboard interface, a Multipak Interface, Disk controller (J&M), 1x 5.25" 40trk DSDD floppy, 1x 5.25" 80trk DSDD floppy, 1x 3.5" 80trk DSDD floppy drive, a Burke and Burke HD interface, 2x Seagate ST-225 hard drives (20 meg ea), an Orchestra 90cc pak, a Glenside Midi Pak.... and Drivewire 4.

Drivewire 4 is a a PC Console that allow the Color Computer, through a serial cable, to access "virtual disks" on the PC's HD. This allows for virtually endless and fast storage for the Coco. Any Coco user not using Drivewire 4 has not moved their Coco into the New Millenium. As Gene Heskett says "It's the cat's meow"

This project started in my Sound Chaser program when I needed a way to access the Drivewire UI commands from within Sound Chaser to change MIDI parameters without forking the "dw" Drivewire utility. In trying to write a routine to set the MIDI parameters I was going through the Drivewire documentation and found that there was a lot of stuff that could be set/turned on from the Coco. The more I investigated, the more commands I found, then talking with the Drivewire developer, Aaron Wolfe, I found he had provided a way to completely control Drivewire from NitrOS-9 without going back to the PC console. He told me he had originally intended on writing a user interface for OS9 and Drivewire to be run from a "headless" server, but never got around to it. I decided this would make a good project and volunteered to do the job. DW4Man was born. DW4Man will be a complete Drivewire user interface for NitrOS9 Level 2 and the Coco 3 and maybe if I get this right, I'll try a version for NitrOS9 Level 1 and maybe even one for HDBDOS. Basically, anything that you can do in the Drivewire PC console, will be available in DW4Man.

(I hope).

From the work I had done on my Sound Chaser project (see sidebar), I knew I could easily build a stable menuing system on a hardware text screen and manipulate a database with just the arrow keys. What I needed was a good inline routine for accessing Drivewire from within a "C" program. So this was the first priority. I set up a small input program that allowed you to input Drivewire commands and then process them to the screen. I had used Aarons sources from the original "dw" command from the NitrOS9 source repo but trying to convert ASM code to C ended up being a disaster. Eventually I took advice from William Astle and looked at the code in it's simplest form and took the lowest route. It worked! After almost 4 weeks of trying complex routines and combined asm/C code, just plain simple reads and writes with a couple of system calls did the job. In trying to put all this together, Aaron had told me there was a special "ui" command set that had been designed specifically for this purpose and when I tried to use the "ui" command set from the Coco, it failed. There was something wrong on the server side and in the end, Aaron decided to write a completely new cmd protocol just for this purpose. He is currently working on this and until he gets me a copy of the new cmd protocol, I am using the "dw" command set so I can continue working on the user interface and have it ready when he gets the protocol done. So for now, I'm just setting up menus and deciding how I'm going to handle the various functions of Drivewire and what kind of storage arrays I need for creating databases to use for editing various features of Drivewire. Once I get the new protocol, things will move along fast in this project as most of the front-end work has now been done. I will be breaking down each catagory of Drivewire functionality and finding ways to edit the parameters and send them back to the console. The most useful thing will be the Disk Database. You will be able to browse your PC hard drive from the Coco and select virtual disks and VHDs to create a disk database in which you can select and mount a disk at any time directly from the Coco without touching the PC. Hows that for a manager?

Here are a few screenshots of what is coming soon...

Click the pictures to view full size

The pull down menu system A Midi device selection

The MIDI profile layout

More coming soon....

web counter