[Coco] OT: new territitory for me

[L. Curtis Boyle]

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