[Coco] NitrOS-9 boot configuration tool

[L. Curtis Boyle]

Heh.. this is something else that Bill and I had planned for NitrOS9 and never got to. We were going to have the user making the bootfile pick out the device descriptors they needed (this is where the database part would come in… to show which version of /d0 one was picking for example: Floppy, no Halt Disto floppy, no halt Sardis floppy, etc.)), but it would use the device descriptor itself to figure out which driver and file manager was required for each, since the names of those is stored in the descriptor already anyways (and used by the OS itself).
Of course, there are “fixed” ones that every normal boot would need (RBF, SCF, IOMAN, etc.) that would always automatically be put in (maybe an option for “customized” versions).

L. Curtis Boyle
curtisboyle at sasktel.net



> On Nov 8, 2014, at 8:50 AM, David Gettle <david17361 at gmail.com> wrote:
> 
> 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
>