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

Sat Oct 10 20:32:01 EDT 2015

I'm actually the one at fault here. When Stephen was having issues getting 
the dw command working I suggested just loading the missing modules rather 
than building a new bootfile until he could test it out. It works so it is 
definitely time for a new boot file.

----- Original Message ----- 
From: "Bill Nobel" <b_nobel at hotmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Saturday, October 10, 2015 5:23 PM
Subject: Re: [Coco] How to import source code into NitrOS-9?

> 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
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
> 