[Coco] How to import source code into NitrOS-9?

Sat Oct 10 20:23:31 EDT 2015

Hey Stephen,  I have been a lurker on this thread.  I think I figured out what your problem is,  the OS9Boot file you mention IS the bootfile.  The command to identify what is in that file use the utility ‘ident’ from the CMDS directory, i.e. ‘ident /dx/os9boot -s’ changing x to the drive where your os9boot file is.  This will produce a list of the system modules merged together to make up the OS9Boot file.  That file is the one you need to edit with any of the boot file editors available, to have it contain what you need.  My favourite is ‘ kwikgen' from Wes Gale.  The core of OS9 is a little trickier to modify.  KRN has extra data outside of itself that map to the very top of RAM for the Reset and IRQ vectors.  Also the boot track must be perfectly padded to achieve boot. 

As William Astle, in a post in another thread says… “if you actually trace the boot process, it's pretty clear that the original form of OS9 Level II was a hack piled on top of a kludge.”

Bill Nobel

> On Oct 10, 2015, at 2:07 PM, Stephen Pereira <spereira1952 at comcast.net> wrote:
> 
> Hi Bill,
> 
> You are an absolute saint for sticking with me on this.  Thanks very much, once again, for your detailed explanations and your guidance.
> 
> I got everything you said in your last message.  Before I embark on a new effort to get the scdwv file into my boot process, I decided to try another NitrOS-9 boot disk.  I went to the NitrOS-9 Project page on Sourceforge and I downloaded a new copy of nos96809l2v030300coco3.zip <http://sourceforge.net/projects/nitros9/files/releases/v3.3.0/nos96809l2v030300coco3.zip/download>.  They say that the CoCo3FPGA is supposed to operate exactly like a CoCo 3 with floppy disks, and Drivewire is supposed to be invisible, so I used a normal CoCo 3 boot disk from the .zip file.  
> 
> Yes, it boots on my CoCo3FPGA system just fine.  Where SMAP said I had 16K RAM free before, with this load SMAP says I have 24K RAM free.  So, I did the MERGE you suggested again for this boot disk, and I did the ATTR to get the permissions right.  I did the LOAD and LINK, all just as before.
> 
> The only problem here is that with this new boot disk, I get the ERROR 216 (path name not found).  SIGH.
> 
> So I dumped all that and went back to my original boot disk where I at lease can get the Drivewire Server command somewhat working.
> 
> I did all of your suggestions for editing the startup file.  Commenting out utilpak1 and rebooting does not change the behavior of my system at all.  I can still do:  dw server list c:/filename.ext  and see it scroll by on the screen, and when I try to redirect the output to a file on a disk, it indicates that memory is full.
> 
> So, can you tell me where to find my boot file?  I see a file called OS9Boot, but it appears to be machine language, as I can’t LIST it.  If I can find the file you are speaking about, I can attempt to edit it to contain the files you suggest.  Is there a special command for editing the boot file?
> 
> Thanks very much, again.  I hope that others are learning things along with me.
> 
> smp
> --
> Stephen M. Pereira
> Bedford, NH  03110
> KB1SXE
> 
> 
>> On Oct 10, 2015, at 1:54 PM, Bill Pierce via Coco <coco at maltedmedia.com> wrote:
>> 
>> 
>> Stephen, This kind of error is actually pretty common when loading what 'should' be bootfiles into the system ram as you are doing with scdwv. The error #207 is reporting you are out of "system" ram.. (it's actually used for both system and machine memory) that means it didn't have enough ram in the system workspace (64k) to load a needed module. All running modules occupy a block(s) in system memory. This is part of how OS9 multitasks.. When you load a module, it loads into system ram, the OS9 copies it to a workspace in user memory for it to run from there. If you are already running a module (already in system mem) and want to run another instance of the same module in another window, it just copies a new instance from system memory to a new 64k worksapce and creates the instance.
>> 
>> Mfree reports 'machine memory'.. which is total 'free' ram available on that machine. To get system memory, try 'smap'. Smap will show a chart of the 64k system ram in 256 byte blocks and displays what is allocated and what is not and reports how much system ram you have free at the bottom.
>> 
>> What it boils down to, it that your boot is too large or too many things are loaded after the boot (i say the later).
>> OS9 loads modules in 8k blocks... meaning no matter how small or large, the memory allocates multiples of 8k. If a module is only 256 bytes, it allocates 8k. If a modules is 9k in size, it allocates 16k and so on... This is why I told you to 'merge' those modules because to have loaded them individually, it would have used 24k, and merged they only use 8k (os9 sees it as one module though it's really 3).
>> 
>> One thing you can possibly do... I'm pretty sure since I've seen this on just about every 'premade' bootdisk I've delt with (except my own) that your 'startup' script (which runs on boot) loads 'utilpak1' which is an 8k block of cmds. This is done so some of your 'basic' cmds (load, del, dir etc) are loaded on startup therefore saving a lot of disk access each time you use them. There is also a block of cmds merged with 'shell' but shell would use 8k anyway, so it's safe to fill the rest of the 8k up with cmds.
>> 
>> So, as a test to see if system memory is your problem, comment out the 'Load utilpak1' line from your 'startup' script. The 'startup' file should be in your root directory of '/dd'.
>> If 'minted' is in your cmds dir, it can be used to edit the startup file. To get help with minted, just (from the cmd line) type 'help minted'. To get startup into minted, just type "minted /dd/startup". Minted should start and lo9ad startup to the screen.
>> 
>> Once 'startup is on the screen, scroll with the arrows down to the line containing 'load utilpak1'. At the beginning of that line type '* ', which is * plus a space.
>> Then press <cntrl><S> to save it, then <BREAK> to exit.
>> Reboot you system and try using 'scdwv again.
>> 
>> If you want to add the line back in to startup, just use the above instructions and use <shift><right> to delete the * and space. <cntrl><S> to save again.
>> 
>> The absolute best way to solve this problem is to put those modules in your bootfile. They will take up much less memory and always be there. If the DriveWire drivers are there (rbdw,dwio), then 'scdwv', the '/Nx' descriptors (at least '/n' & '/n1'), 'scdwp', '/p', '/midi' and at least one '/Zx' descriptor should be left in the boot. These files are specifically for dw4 use and can make life with dw4 much easier. People remove them mostly because they have no clue what they can do. They are very powerful modules and they should be on all dw boots and only removed if the user wants them removed.
>> 
>> Just so you know....
>> The standard OS9 'merged' files loaded on boot (on all repo disks)...
>> 
>> Utilpak1 contains:
>> attr, build, copy, del, deldir, dir, display, list, makdir, mdir,merge, mfree, procs, rename, & tmode.
>> 
>> Shell contains:
>> shell, date, deiniz, echo, iniz, link, load, save, unlink.
>> 
>> I changed these on my system looong ago as I have found better (and more useful) cmds to replace those.
>> 
>> 
>> 
>> 
>> Bill Pierce
>> "Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull
>> 
>> 
>> 
>> My Music from the Tandy/Radio Shack Color Computer 2 & 3
>> https://sites.google.com/site/dabarnstudio/
>> Co-Contributor, Co-Editor for CocoPedia
>> http://www.cocopedia.com/wiki/index.php/Main_Page
>> Global Moderator for TRS-80/Tandy Color Computer Forums
>> http://www.tandycoco.com/forum/
>> 
>> E-Mail: ooogalapasooo at aol.com
>> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco