[Coco] NitrOS-9 boot configuration tool

Wed Nov 12 23:52:13 EST 2014

Hi Bill!
I apologize for not testing the last version of MShell you had sent me an
email about.  Have you made any further changes lately?  Is the latest
version available on your Web site?  It seems like I remember you had to
temporarily disabled MShell's ability to use Drivewire 4 to ftp download
Mshell updates.  Please catch me up.  Thanks a bunch!

Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/Kip_Koon

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Bill Pierce
via Coco
Sent: Saturday, November 08, 2014 2:51 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] NitrOS-9 boot configuration tool

David,
Since there seems to be some interest in a boot dependacy tree, I might just
finish up my list tonight and get into the public eye. I hadn't realized
there was no such list (or that anyone would be intersted). The closest
thing is the bootlists on the distro disks and they are incomplete and do
not cover all the modules offered in the repo.
I had it almost finished before, but at that time, we were still at v3.2.9
in the repo and changes were been made, names were being changed etc... so I
decided to wait until things were finished there. Now that the repo is at a
stable v3.3.0, I feel the changes are permenent and a valid tree can be
made.
I will go through my old list, make the changes and try to finish it up. I
know Tormod want's to put a copy in the repo, but I may put a page up on my
site and link it here as well.

And yes, the BootMajik system will have a way to "update" it's list, and
maybe a little further on down the line, may even have it's own repo online
as my MShell system can download from FTP sites to the Coco through
DriveWire4. Hopefully, I will be demonstrating the full power of MShell real
soon as I'm about to make a youtube video of what the file manager can do.
It's pretty amazing to see it copy to and from Os9 drives, RSDOS drives and
the DW4 PC server host's drives, making moving files from almost anything to
OS9 (or back) almost effortless. I'm just finishing up some bug fixes then I
have to test it on Linux and Mac DW4 servers (I run Windows) and then I will
make the video and possibly a release of MShell.

Bill Pierce
"Today is a good day... I woke up" - Ritchie Havens

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: David Gettle <david17361 at gmail.com>
To: Bill Pierce <ooogalapasooo at aol.com>; CoCoList for Color Computer
Enthusiasts <coco at maltedmedia.com>
Sent: Sat, Nov 8, 2014 9:50 am
Subject: Re: [Coco] NitrOS-9 boot configuration tool

Sounds like a very useful application when you get it completed, will you be
including a way to update the dependencies in the event additional changes
to NitrOS9 are made in the future? ie. new storage media devices or the
like?

Also would you please include me in the list to get a copy of the text for
module dependency, I would like to have it for reference also, I have the
original OS-9 dependencies in the manuals, but have not worked with that in
years, and have not created a working boot disk in years either, (quite
frankly I don't remember all the dependencies any more it's been too long
since I've worked with it).

or better yet how about posting it for download on the NitrOS9 download site
so everyone in the community can have a copy if they want, as it would be a
good reference for all of us. It may even open a way to streamline the OS
even more.

On Sat, Nov 8, 2014 at 9:33 AM, Bill Pierce via Coco <coco at maltedmedia.com>
wrote:

Tormod,
When I get back to work on BootMajik, I will send you a copy of the boot
dependacy tree. My tree is actually in an array form with all kinds of flags
for "optional" or "required" but it will be a simple matter to make it into
a "text" list in "tree" form for examination.
Right now, (IIRC), it's about 75% finished (the tree), and I should be back
to work on it after the first of next year (or maybe sooner).
I had to stop the project due to running out of memory for the arrays and
that's when I decided to use virtual memory for the arrays, so I then
started putting MShell together which is really the GUI for everything else
to come later.. BootMajik, DW4Edit, SndChaser2, MSEd, FTPMan, and many
others, all in some form of preproduction or conversion from their older
project forms (pre-virt memory).
I will get the list to you as soon as I can :-)

Bill Pierce
"Today is a good day... I woke up" - Ritchie Havens

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: Tormod Volden <lists.tormod at gmail.com>
To: Bill Pierce <ooogalapasooo at aol.com>; CoCoList for Color Computer
Enthusiasts <coco at maltedmedia.com>
Sent: Sat, Nov 8, 2014 6:34 am
Subject: NitrOS-9 boot configuration tool

On Thu, Nov 6, 2014 at 6:58 PM, Bill Pierce via Coco wrote:
>
> Gene,
> The way BootMajik will work is just that, dynamically linked arrays 
> that flag
a dependacy tree. When one item is selected, any "required" links in the
tree
(modules) are automatically selected, the "optional" modules are user
selected (all point n click). The hard part is to make the tree. One needs a
"complete"
list of all known modules in the NitrOS9 repo (which I have), then
theoretically, the array tree for an RBF or SCF driver would be:
Driver(Manager(Subs(Descriptors))) (some will vary)
> To step the user through, I have devised a system of point-n-click
selection:
> Coco Model 1, 2, or 3
> NitrOS9 Level 1 or 2 (L1 will be autoselected for Coco 1 & 2) CPU 6809 
> or 6309 Boot Method DW4, Floppy, HD, ect..
>
> From there, the driver/descriptors step through RBF, SCF, Pipe, and Clock.

Bill,

Can you share this dependency tree with us?

Ideally, I think we should also document module dependencies in the source
code itself. Each module source should declare which modules it depends
upon, for instance using a magic comment line. Then a simple tool can
automatically reconstruct a dependency tree in a machine-readable format.

The selection and assembly of the boot file can be done outside of NitrOS-9.
I think it would be an advantage to not need a running
NitrOS-9 system to start with. For instance a user-friendly program can run
from BASIC/RSDOS, or on a PC to allow the selection of drivers and assemble
a boot file. It can produce a disk image, or a boot file/list for Brett's
bootloader.

This would be an alternative to Bill's all-NitrOS-9 solution, but some
competition would not hurt here :)

I don't know how difficult this is going to be though. I don't know enough
about NitrOS-9 to even understand why the boot configuration is so delicate,
or for instance what "cobbling" of boot tracks means. I will need to read
the documentation. Thanks for the links you posted, Frank.

Regards,
Tormod

> And yes.... it's a long list but by using virtual memory (very similar 
> to the
way MyRam does, but using 8k get/put buffers), I can keep VERY large arrays
in memory. Also, each section can be loaded from a disk file as needed so
the whole thing doen't need to be in memory at once.
> Using this method, I even have room for a short 1/2 line description 
> when
needed. I've been working this out and trying various parts of it for about
2 years now. I've even thought about including a "user's modules" list for
the user's "custom" modules that are not in the repo. This way you can add
your own modules to the list. The file list and the actual modules wile be
stored in it's own disk or directory on the HD. To update the repo... just
change the disk or recopy the files to the HD (disk or HD will be user's
choice).
> The virtual memory routines are functional and already in use in 
> MShell. I can
store my complete CMDS dir with file attributes and stats for each entry,
not to mention various flags for system use. Each record entry is about 58
bytes. My CMDS dir has about 526 files... (do the math...)  all in memory at
once. In fact, the array will max out at about 1129 records and could be
much larger, but I doubt many people have any directories much larger. The
PC dirs are 270 bytes per record (to account for long filenames) and will
max out at about 480 records and will probably be larger in the finished
program. MShell displays 2 such lists!!  This also makes storing large
directories of the DW4 server PC's HD dirs possible. Even with the long
filenames, and yes... it will access the server's files so you can move
files from PC to OS9 to PC :-)
> The display for BootMajik will be the same GUI used for MShell which 
> is built
on Mike Knudsen's "Ultimuse3" GUI which is clean and uncluttered, also very
stable. The graphics handler for the GUI does 28 lines in 80 columns on the
screen in 640x192 / 2 color mode, so there' plenty of screen real estate,
and the 2 panels are scrollable (3-4 panels in BootMajik). In BootMajik, the
leftmost panel will display the initial driver list of type RBF, SCF, Pipe,
or Clock. The next panel displays the managers (if any) available from the
left selection, the next panel gives the descriptor list from the selected
manager, then the last panel will show the complete selected system (so far)
in proper order, adding new files as they are selected. This last panel can
be edited by selection to add/remove sections as need or when you realize
you made a wrong choice.
> So yes, it can be done, and I will do it :-)
>

>
>
> -----Original Message-----
> From: Gene Heskett
> Sent: Thu, Nov 6, 2014 8:59 am
>
> I think that is a great idea.  But there is one showstopper problem.
>
> Exactly none of the I/O devices we have today, is capable of being 
> interrogated on the hardware level, and returning an $Id string.
>
> So you are still stuck with asking the user to identify his hardware 
> and its configuration.  For those who have had their stuff for yonks, 
> likely no problem, we know what we have.  But for the new bee, whats 
> an MPI, or whats a 1Gb hard drive, scsi or ide?  Addressed as CHS, or LBA?
>
> I think you can see where I'm going.  You are going to wind up 
> building the list on non-volatile media, and chain linking the various 
> bits and pieces because its going to be a rather lengthy program when
done.
>

--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco

--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco