[Coco] NitrOS9 with Deluxe RS232 Pak

[Gene Heskett]

On Wednesday 17 June 2015 23:35:52 Ron wrote:
> Hi Gene,
>
> I started reading through the OS9 Level 2 documentation and it helped
> me quite a bit.
>
> The ramdisk sounds very interesting!  I only have 512K of RAM (like
> most folks).  Wish there was a 2MB upgrade readily available to use
> for your ramdisk.  Perhaps someday.

It can be used with 512k, just not as big.  I have a 2 meg kit, and at 
one time played with a 1.7 meg ramdisk, but it wasn't being anywhere 
used while building rzsz, so I dropped it back to about  1/2 a meg, 
still worked for big C compiles.

Ram problems in Nitros9/OS9 aren't generally main ram, but system ram, 
the ram the OS uses to keep track of things, so those with more than 
128k don't often see main ram failures.

We've made a few attempts to setup a 3rd ram allocation by separating the 
scf and rbf modules into their own space, but haven't been successful 
with the level3 effort, particularly with drivewire living in both scf 
space and in rbf space.  I have an idea of how we might separate sysram 
from main ram in order to be able to allocate another 8k block of memory 
for use only when it is in system mode, but its not at all well fleshed 
out, and unless a younger mind jumps on it (I'm 80, and TBT my interests 
are more directed to cnc metal/wood carving machines these days, and I 
am probably about a month from first chips on a new Grizzly GO704 
milling machine, being told by a flea powered computer where to cut & 
how fast, at an accuracy in the <.001" range) I suspect that will not 
happen either.  Furniture carved to that level of accuarcy is a treat, 
as are parts or stocks for one of my BP rifles.

> I have been using Drivewire, though it's been limited to DECB.
> Impressive way to replace the antiquated floppy drives.  Frees up more
> desk space (which is a good thing).  I'm amazed at the speed at which
> that bit-banger port operates!
>
It works just as well under Nitros9, once you figure out which modules 
need to be swapped out for the drivewire equivalents.  That can be 
tedious for the new bee though.

> Thank you, sir!
>
> -Ron
>
> On 6/17/2015 8:27 PM, Gene Heskett wrote:
> > On Wednesday 17 June 2015 20:32:57 Ron wrote:
> >> Hi Gene,
> >>
> >> I appreciate you taking the time to reply to my numerous questions
> >> and comments.  What you've said makes sense.  It looks like I have
> >> a lot more to learn (i.e. tboot command, /t2 parameter changing and
> >> saving, creating new bootfiles, etc.).
> >>
> >> I'm still looking for a good sources of documentation (beyond the
> >> nitros9.org website).  Is OS9 documentation still relevant when
> >> using NitrOS9?
> >
> > Quite a bit of it is.  Occasionally we'll figure out a better way. 
> > The dsave is one command that has had a syntax change, and
> > tmode/xmode are all built from the same src file, so the operative
> > syntax diffs have disappeared.  XMode/DMode have been dressed up a
> > bit, and both can now work on disk files by prefacing the pathname
> > with a leading - sign.
> >
> > Some of us have written replacements for existing utilities but with
> > more bell & whistles.  I wrote a ramdisk quite a few years back that
> > can be made operational for a compile, and then return every byte
> > back to the system when its no longer needed.  Doesn't need an
> > initial format before use as it actually does it in the few
> > milliseconds delay you see if you do a dir /r0, as it detects the
> > command, and holds it until it can show you the empty directory. 
> > Access speed is essentially the same as a good scsi circuit,
> > essentially the speed the cpu can move the data, 11 seconds for a
> > megaread on a 63x09 equipt machine, 13 or so for a 68x09.
> >
> > Other folks are encouraged to blow their own horns when the
> > opportunity presents itself.
> >
> > You will want to get acquainted with drivewire at some point, so get
> > ready for the loss of the use of /t1, drivewire uses it, at speeds
> > up to 110 kilobaud to access files on your pc that are disk storage
> > to the coco.  Faster than a real floppy!
> >
> > The future is bright, so you may want to wear shades. :)
> >
> >> Thanks again!
> >>
> >> -Ron
> >>
> >> On 6/17/2015 5:20 PM, Gene Heskett wrote:
> >>> On Wednesday 17 June 2015 17:04:34 Ron wrote:
> >>>> Hello everyone,
> >>>>
> >>>> I'm just just getting started with NitrOS9, but being familiar
> >>>> with Linux has help considerably to navigate around the OS.
> >>>>
> >>>> I have a Coco 3 with a MultiPak.  Slot 4 has an SDC controller
> >>>> and I've mounted the NitrOS9 SDC version
> >>>> (nos96809l2v030300coco3_cocosdc.dsk
> >>>> <http://www.nitros9.org/latest/nos96809l2v030300coco3_cocosdc.dsk
> >>>>>) . Slot 1 has a Deluxe RS232 Pak.  I've connected this pak to my
> >>>> PC with a NULL modem cable.  RS232 pak seems to work fine with my
> >>>> PC (tested it at 9600 baud) using the RS built-in term program
> >>>> from DECB.
> >>>>
> >>>> I am, however, unable to connect to the Coco (running NitrOS9)
> >>>> from my PC.  Information is a bit spotty online, so I apologize
> >>>> in advance if this is well documented and I just missed it.
> >>>>
> >>>> I run the following command to initiate a shell:
> >>>>
> >>>> shell i=/t2&
> >>>
> >>> This is correct.
> >>>
> >>>> I believe this telling NitrOS9 to use the Deluxe RS232 Pak and
> >>>> not the bit-banger port.  I'm unfamiliar with how to verify the
> >>>> proper driver is being loaded for /t2 and unable to get the
> >>>> correct syntax for the xmode command to verify what the default
> >>>> term settings are. I'm also thinking there may be a way to
> >>>> communicate faster than 9600 baud using the Deluxe RS232 Pak
> >>>> (from within NitrOS9) as well.
> >>>
> >>> There is, but in the long run when the coco is on the receiving
> >>> end of that data, it cannot go faster than about 5500 baud if
> >>> overruns are to be avoided.  Particularly if using an error
> >>> correcting transfer protocol such as rzsz.
> >>>
> >>>> I must say, I'm thoroughly impressed by the power of the Coco
> >>>> running NitrOS9.  It was so far ahead of it's time.
> >>>
> >>> There is also a time limit that I have not discovered the cause
> >>> of, that says if I don't start, or have already running, a copy of
> >>> minicom, there comes a time when the /t2 port is no longer
> >>> responsive to the incoming login from minicom.  10 minutes late,
> >>> and the coco will need rebooted.
> >>>
> >>> As for the xmode command bear in mind it only works on an unopened
> >>> path, so for playing with /t2's params live, you use tmode .0 or
> >>> .1, or even .2, where 0 is stdin, 1 is stdout, and 2 is stderr.
> >>> Permanent changes to /t2.dd need to be done using xmode, and then
> >>> generating a new bootfile useing the modified /t2.dd.  Or you can
> >>> transfer the changes to the in memory copy, and then save it for
> >>> use in a new bootfile. We actually have several methods of
> >>> skinning that cat. ;-)
> >>>
> >>>> Thank you!
> >>>>
> >>>> -Ron
> >>>
> >>> Cheers, Gene Heskett
> >
> > Cheers, Gene Heskett

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>