[Coco] OT: new territitory for me

[Wayne Campbell]

You are correct, Curtis. I am familiar with syscall and getstat. I can write 
the call to check for the status of the port now. :)

And thank you, Aaron.

Wayne

----- Original Message ----- 
From: "L. Curtis Boyle" <curtisboyle at sasktel.net>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Friday, January 01, 2010 3:09 AM
Subject: Re: [Coco] OT: new territitory for me


> Just use the SYSCALL subroutine to call all system calls (including 
> getstat/setstat calls) from Basic09.
>
> Sent from my iPhone
> L. Curtis Boyle
>
>
> On Jan 1, 2010, at 2:31 AM, Aaron Wolfe <aawolfe at gmail.com> wrote:
>
>> When writing a program to work with the new DW server, TCP/IP
>> connections are presented to your program as a serial port, and data
>> is sent and read using exactly the same calls as a terminal program or
>> BBS would use.  There are some special commands that can be sent over
>> this port that cause DW to make an IP connection  Not too different
>> from talking to a modem and telling it to dial, in fact if you want to
>> use existing telecom software, DW includes a Hayes compatible mode
>> where you can 'dial' internet addresses using ATD.
>>
>> Using these virtual ports is actually much easier than writing
>> software for a real serial port, because there are no baud rate or
>> parity settings to worry about, and no flow control in necessary.  The
>> DW server has an effectively infinite buffer for both incoming and
>> outgoing data.  All your program has to do is read and write to the
>> port when it wants to do so.
>>
>> There are a number of tried and true strategies for dealing with
>> incoming data that can happen at unpredictable times (keyboard input,
>> an IRC message from the server).  The simplest is called polling.  In
>> a program that is dealing with a small, fixed number of potential
>> inputs, this is probably the best technique to use.
>>
>> To use a polling design, you must find some may to determine whether
>> or not an input source has data ready for you.  Your program has a
>> small loop that checks all possible inputs for data, and hopefully
>> sleeps for a while to avoid what's called "busy waiting", basically
>> wasting lots of CPU waiting for something to happen.
>>
>> You can check whether the virtual port has data waiting for you with
>> the os9 system call GETSTAT and the argument SS.Ready.  It will return
>> E$NotRdy if there is nothing, or set the calling routine's B register
>> to the number of bytes available if there is data waiting in the
>> buffer.  I don't know how you access this from basic09, but I'm sure
>> it's possible.   There should be a way to check for a keystroke in a
>> similar manner, I am not familiar enough with OS-9 to tell you how
>> though.
>>
>> The key is that you never do a READ unless you already know there is
>> data ready to be read.  This avoids "blocking", your program won't
>> grind to a halt waiting on input from one stream while missing input
>> from the other.
>>
>> In this strategy you must also read and process input very quickly.
>> While you are handling input from the virtual port, you aren't reading
>> keystrokes.  They'll be buffered and waiting for you when you get
>> there to read them, but you need to be quick about it so that the user
>> has a good experience.  I've found in testing the DW routines that
>> 100ms is pretty acceptable for a response to a keystroke.  Coco can do
>> a lot in 100ms, but keep that in mind when writing code that handles
>> input.
>>
>> In a polling design, any processing that going to take more time than
>> is acceptable must be started in a separate process so that the
>> polling loop can continue handling input.  chances are this won't be
>> an issue in an IRC client.
>>
>> Hope that helps,
>> -Aaron
>>
>>
>>
>>
>> On Fri, Jan 1, 2010 at 1:27 AM, Wayne Campbell <asa.rand at gmail.com> 
>> wrote:
>>> One of the things that I have not understood in the past, and am  not 
>>> sure I understand even now, is network communications. I've  never 
>>> actually tried to write a terminal, or bbs, or message-board,  or a 
>>> server or client of any kind before. I know how to parse text- based 
>>> messages, which is what the internet is based on, and which  irc is 
>>> based on, but knowing how to handle the incoming and  outgoing data 
>>> streams has been elusive. In trying to do something  with it, I am 
>>> finding myself remembering another thing I have never  really 
>>> understood, event-driven programming, as opposed to  procedural, which 
>>> is what I am most familiar with.
>>>
>>> I find myself looking at the streaming issue, and seeing where I  need 
>>> to be able to handle things in a similar manner to the event- driven 
>>> style. Because I have to constantly read and process the  incoming 
>>> stream, while at the same time processing the messages  being typed by 
>>> the user. In addition, I have to manage the output  so that each thing 
>>> appears in the appropriate place on the screen,  or is held in the right 
>>> table for access as a sub-menu. I really  don't understand how this is 
>>> done, even though I did learn  something about it when I had my old Mac 
>>> Quadra 605. I do know  that, if I don't do it right, the interface will 
>>> be slow and kludgy.
>>>
>>> Parsing character streams usig strings, and building message  strings, 
>>> is easy in comparison. I may have questions, as I go.  Aaron Wolfe is a 
>>> great help, and has already given me a few clues  to build on. I am 
>>> working on them now, to see if I can produce  something that will 
>>> communicate with a irc server.
>>>
>>> Wayne
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco