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

Sat Oct 10 16:46:07 EDT 2015

Stephen, from your link, I have no idea which dsk you tried as that is a zip of several disks. But it sounds like you tried a standard Coco 3 disk which will NOT run dw.
Yes, DW is invisable (when installed)... but NOT on a normal Coco3 boot (not installed). The drivers must be present. The one for your FPGA has the DW "disk" driver already there, just not the scdwv stuff... The disk drivers (rbdw, dwio) are the root of ALL dw4 operations and so they're not on a 'normal' Coco 3 bootdisk, ONLY on DW bootdisks. The whole problem is that whoever made the FPGA boot disk, eliminated the 'scdwv' driver and it's descriptors... why? I don't know, but it was not a good move. This makes that boot (as far as dw is concerned) just a DW file sharer... not a PC utility, TCP/IP gateway, TelNet server/client, virtual printer, MIDI player, remote terminal, etc. Without the virtual ports (scdwv, scdwp, Nx, P, MIDI, and Zx... it's just a file server system.
If you're going to try a repo disk, use the proper disk for your purpose:

>From the posts I'm seeing on the CocoFPGA, I'm not sure whether the FPGA uses the Becker Port, or standard DW4???
I was under the assumption the FPGA used the Becker port (I thought it was developed for it), but now I'm no longer sure....

So for Becker Port (most likely) use:
http://sourceforge.net/projects/nitros9/files/releases/v3.3.0/disks/nos96809l2v030300coco3_becker.dsk/download

or if that doesn't work try the standard DW4 disk, use:
http://sourceforge.net/projects/nitros9/files/releases/v3.3.0/disks/nos96809l2v030300coco3_dw.dsk/download

One of these is the proper disk for a 6809 L2 DW boot on the FPGA. Just stick it in DW slot 0 and type DOS (if you have dw access from DECB)

You will NOT have to load the drivers with these disks as they already have them in the boot. Just try the dw cmd without all the merge stuff.

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

-----Original Message-----
From: Stephen Pereira <spereira1952 at comcast.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sat, Oct 10, 2015 4:08 pm
Subject: Re: [Coco] How to import source code into NitrOS-9?

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