[Coco] Network Access for my COCO

Aaron Wolfe aawolfe at gmail.com
Mon Jan 6 20:23:32 EST 2014


On Mon, Jan 6, 2014 at 7:33 PM,  <billg999 at cs.uofs.edu> wrote:
>> With such vague details I can only guess, but the default memory limit
>> for Java programs is rather small on some operating systems (8 or 16MB
>> total).
>
> I put up an XP Box and ran it on that.  Would something else be
> recommended? I have an UltraSPARC sitting around doing nothng and I
> considered Solaris.  I also have a couple of Alpha boxes (one is a
> small Multis, but still a lot of horsepower).  How about one of them
> running Linux?  What is considered the wise choice?

Any of those should work, but your XP box is fine too.  Basically any
computer with at least 8MB ram can probably run the server part of DW,
and with a bit more you can run the UI.  You can also run the GUI on a
different computer than the server if that is more convenient (or run
the UI on multiple computers, all connected to the same server.  Or
connect to multiple servers with one UI.. etc,etc).  Basically, you
can use whatever equipment you want and it won't make much difference
to DW.

>
>>          DW can operate in these conditions, but if you leave the GUI
>> open and have logging turned on it will eventually run out of room.
>> At that point it halts logging and anything else that it can (the
>> message you mentioned) in an attempt to keep services alive to the
>> coco, but it can only do so much.
>
> The logging it is doing is right out of the box.  I have not tried
> any configuration so far as I don't know enough about it yet.  I am,
> of course, still concerned about the error messages.
>
> On the DWUI Window:
> Unknown API comand: 'FAIL 010 Unknown API FAIL'"
>
> and on the COCO Console:
> READING DATA FROM NETPATH
> 'FAIL 010 Unknown API FAIl'
> SS.SSIG ON NETPATH
>
> These spew out 5-6 per second.
>

That is very not good.  The CoCo is echoing the server's output back
at the server, creating a nasty feedback loop.

This usually happens when the descriptors for the /N devices don't
have eko=0 in their mode bits.  For some reason this bug seems to
recur in the NitrOS9 source from time to time.

Where did you get your NitrOS9?  The disks on the nightly build page
seem to be OK, but I think the disk you have has buggy device
descriptors.

With the log settings at default, you should never see a recurring
message.  You'll see a few lines when you start up, reboot the coco,
or insert a disk, but nothing that keeps happening on its own.
Anything like that is a serious problem.



More information about the Coco mailing list