Newton 2.x Q&A Category: Endpoints & Comm Tools

Copyright © 1997 Newton, Inc. All Rights Reserved. Newton, Newton Technology, Newton Works, the Newton, Inc. logo, the Newton Technology logo, the Light Bulb logo and MessagePad are trademarks of Newton, Inc. and may be registered in the U.S.A. and other countries. Windows is a registered trademark of Microsoft Corp. All other trademarks and company names are the intellectual property of their respective owners.


For the most recent version of the Q&As on the World Wide Web, check the URL: http://www.newton-inc.com/dev/techinfo/qa/qa.htm
If you've copied this file locally, click here to go to the main Newton Q&A page.
This document was exported on 7/23/97.

Endpoints & Comm Tools

What is Error Code -18003 (3/8/94)

Q: What is error code -18003?

A: This signal is also called SCC buffer overrun; it indicates that the internal serial chip buffer filled, and the NewtonScript part didn't have time to read the incoming information. You need to either introduce software (XON/XOFF) or hardware flow control, or make sure that you empty the buffer periodically.

You will also get -18003 errors if the underlying comms tool encounters parity or frame errors. Note that there's no difference between parity errors, frame errors, or buffer overruns; all these errors are mapped to -18003.

See the diagram for an explanation of what is going on concerning the serial chip, the buffers and the scripting world.

The SCC chip gets incoming data, and stores it in a 3-byte buffer. An underlying interrupt handler purges the SCC buffer and moves it into a special tools buffer. The comms system uses this buffer to scan input for valid end conditions (the conditions which cause your inputSpec to trigger). Note that you don't lose data while you switch inputSpecs; it's always stored in the buffer during the switch.

Now, if there's no flow control (XON/XOFF, HW handshaking, MNP5), the network side will slowly fill the tool buffer, and depending on the speed the buffer is handled from the scripting world sooner or later the comms side will signal a buffer overrun. Even if flow control is enabled, you may still receive errors if the sending side does not react fast enough to the NewtonÍs plea to stop sending data. In the case of XON/XOFF, if you suspect that one side or the other is not reacting or sending flow control characters correctly, you may want to connect a line analyzer between the Newton and the remote entity to see what is really happening.

If you have inputScripts that take a long time to execute, you might end up with overrun problems. If possible, store the received data away somewhere, quickly terminate the inputSpec, then come back and process the data later. For instance, you could have an idleScript which updates a text view based on data stored in a soup or in a slot by your inputSpec.
Q&A Diagram

Newton Remote Control IR (Infra-red) API (6/9/94)

NTK 1.0.1 and future NTK development kits contain the needed resources to build applications that control infrared receive systems, consumer electronics systems and similar constructs.

This development kit is fairly robust, and will produce send-only applications.

Note: The NTK 1.1 platforms file is required to produce code that will execute correctly on the MessagePad 100 upgrade units.

cookie := OpenRemoteControl();

 Call this function once to initialize the remote control functions. It returns a magic cookie that must be passed to subsequent remote control calls, or nil if the initialization failed.

CloseRemoteControl(cookie);

 Call this function once when all remote control operations are completed, passing cookie returned from OpenRemoteControl. Always returns nil. cookie is invalid after this call returns.

SendRemoteControlCode(cookie, command, count);

 Given the cookie returned from OpenRemoteControl, this function sends the remote control command (see below for format of data). The command is sent count times. count must be at least 1. Returns after the command has been sent (or after the last loop for count > 1). (see diagram)

Each command code has the following structure:
struct IRCodeWord {
    unsigned long name;
    unsigned long timeBase;
    unsigned long leadIn;
    unsigned long repeat;
    unsigned long leadOut;
    unsigned long count;
    unsigned long transitions[];
};

name identifies the command code; set to anything you like
timeBase in microseconds; sets the bit time base
leadIn duration in timeBase units of the lead bit cell
repeat duration in timeBase units of the last bit cell for loop commands
leadOut duration timeBase units of the last bit cell for non-loop commands
count one-based count of transitions following
transitions[ ] array of transition durations in timeBase units

    Note that the repeat time is used only when the code is sent multiple times.

    See Remote.¹, Sony.r, RC5.r, and RemoteTypes.r files for examples. The .rsrc files have templates for ResEdit editing of the Philips and Sony resources. See Remote IR Sample code for more details.

    Things To Know Before You Burn The Midnight Oil:

    If the Newton goes to sleep, the IR circuits are powered down, and any subsequent sends will fail. If you want to override this, you need to have a powerOffhandler close the remote connection, and when Newton wakes up the application could re-open the connection.

    If two applications are concurrently trying to use the IR port (beaming and remote control use for instance), this will cause a conflict.

    Sample Code

    The Remote IR Sample is part of the DTS Sample code distribution, you should find it on AppleLink and on the Internet ftp server (ftp.apple.com).

    By way of a quick summary: the sample has an array of picker elements with the resource definitions bound to the index (ircode inside the application base view). 

    You specify the constant that is an index to the array, get the resource using the NTK function GetNamedResource and when you send data, use the constant as the resource used.

    OpenRemoteControl is called in viewSetupFormscript, and closeRemoteControl is called in viewQuitScript. Note that these are methods, not global functions; same is true of SendRemoteControlCode.

    More Information

    Consult the IR samples available on ftp.apple.com (Internet) and on the Newton Developer CD-ROMs.
Q&A Diagram
 Communications With No Terminating Conditions  (6/9/94)

Q:    How do I handle input that has no terminating characters and/or variable sized packets?

A:    Remember that input specs are specifically tied to the receive completion mechanism. To deal with the situations of no terminating characters or no set packet sizes, you need only realize that one receive completion is itself a complete packet. Set the byteCount slot of your input spec to the minimum packet size. In your input script, call Partial to read in the entire packet, and then call FlushInput to empty everything out for your next receive completion.

    If this is time-delay-based input, you may be able to take advantage of partialScripts with partialFrequencies.  Call the Ticks global function if necessary to determine the exact execution time of a partialScript.
 What Really Happens During Instantiate & Connect  (6/14/94)

Q:    Does Instantiate, Bind or Connect touch the hardware?

A:    Exactly what happens depends on the type of endpoint being used.  In general:

    The endpoint requests one or more communications services using endpoint options like this:

{
  type:      'service,
  label:     kCMSAsyncSerial,
  opCode:    opSetRequired
}


    <see diagram section A> 

    The CommManager task creates the appropriate CommTool task(s) and replies to the communications service request.  Each CommTool task initializes itself .  In response to the Bind request the CommTool acquires access to any physical hardware it controls, such as powering up the device.  The endpoint is ready-to-go.

    <see diagram section B>

    An endpoint may use multiple CommTool tasks, but there will be a single NewtonScript endpoint reference for them.

    When the endpoint requests a connection, the CommTool interacts wih the physical hardware (or a lower level CommTool) as necessary to complete the connection, depending on the type of communications service.  For example, ADSP will use the endpoint address frame to perform an NBP lookup and connection request.  MNP  will negotiate protocol specifications such as compression and error correction.

    <see diagram section C>

    The CommTool completes the connection and replies to the connection request.  Note that if this is done asynchronously, the Newt task continues execution, giving the user an option to abort the connection request.

    <see diagram section D>

    Disconnect functions similarly to Connect, moving the endpoint into a disconnected state.  Unbind releases any hardware controlled by the CommTool. Dispose deallocates the CommTool task.
Q&A Diagram
 Unicode-ASCII Translation Issues  (6/16/94)

Q:    How are out-of-range translations handled by the endpoints?  For example, what happens if I try to output "\u033800AE\u Apple Computer, Inc."?

A:    The first Unicode character (0338) is mapped to ASCII character 255 because is it out of the range of valid translations, and the second Unicode character (00AE) is mapped to ASCII character A8 because the Mac character set has a corresponding character equivalent in the upper-bit range.

    All out-of-range translations, such as the 0338 diacritical mark above, are converted to ASCII character 255.  However, the reverse is not true!  ASCII character 255 is converted to Unicode character 02C7.  This means you will need to escape or strip all 02C7 characters in your strings before sending them if you want to use ASCII character 255 to detect out-of-range translations.  Character 255 was picked over character 0 because 0 is often used as the C-string terminator character.

    The built-in Newton Unicode-ASCII translation table is set up to handle the full 8-bit character set used by the MacOS operating system.  Although kMacRomanEncoding is the default encoding system for strings on most Newtons, you can specify it explicitly by adding one of the following encoding slots to your endpoint:

encoding:  kMacRomanEncoding;    // Unicode<->Mac translation

    encoding:  kWizardEncoding ;        // Unicode<->Sharp Wizard translation
    encoding:  kShiftJISEncoding ;        // Unicode<->Japanese ShiftJIS translation

    For kMacRomanEncoding, the upper 128 characters of the MacOS character encoding are sparse-mapped to/from their corresponding unicode equivalents.  The map table can be found in Appendix B of the NewtonScript Programming Language reference.  The upper-bit translation matrix is as follows:

short gASCIIToUnicode[128] = {
        0x00C4, 0x00C5, 0x00C7, 0x00C9, 0x00D1, 0x00D6, 0x00DC, 0x00E1,
        0x00E0, 0x00E2, 0x00E4, 0x00E3, 0x00E5, 0x00E7, 0x00E9, 0x00E8,
        0x00EA, 0x00EB, 0x00ED, 0x00EC, 0x00EE, 0x00EF, 0x00F1, 0x00F3,
        0x00F2, 0x00F4, 0x00F6, 0x00F5, 0x00FA, 0x00F9, 0x00FB, 0x00FC,
        0x2020, 0x00B0, 0x00A2, 0x00A3, 0x00A7, 0x2022, 0x00B6, 0x00DF,
        0x00AE, 0x00A9, 0x2122, 0x00B4, 0x00A8, 0x2260, 0x00C6, 0x00D8,
        0x221E, 0x00B1, 0x2264, 0x2265, 0x00A5, 0x00B5, 0x2202, 0x2211,
        0x220F, 0x03C0, 0x222B, 0x00AA, 0x00BA, 0x2126, 0x00E6, 0x00F8,
        0x00BF, 0x00A1, 0x00AC, 0x221A, 0x0192, 0x2248, 0x2206, 0x00AB,
        0x00BB, 0x2026, 0x00A0, 0x00C0, 0x00C3, 0x00D5, 0x0152, 0x0153,
        0x2013, 0x2014, 0x201C, 0x201D, 0x2018, 0x2019, 0x00F7, 0x25CA,
        0x00FF, 0x0178, 0x2044, 0x00A4, 0x2039, 0x203A, 0xFB01, 0xFB02,
        0x2021, 0x00B7, 0x201A, 0x201E, 0x2030, 0x00C2, 0x00CA, 0x00C1,
        0x00CB, 0x00C8, 0x00CD, 0x00CE, 0x00CF, 0x00CC, 0x00D3, 0x00D4,
        0xF7FF, 0x00D2, 0x00DA, 0x00DB, 0x00D9, 0x0131, 0x02C6, 0x02DC,
        0x00AF, 0x02D8, 0x02D9, 0x02DA, 0x00B8, 0x02DD, 0x02DB, 0x02C7
};

 How To Specify No Connect/Listen Options  (2/1/96)

Q:    How do I specify that there are no options for the Connect and Listen methods of protoBasicEndpoint?

A:    Different endpoint services use the options parameter differently.  Some check for nil before attempting to access the array, while others assume they will always be passed an array of options.  Some also assume that the array will always contain at least one element.

    The correct work-around for this unspecified behaviour is to pass an array containing a single nil element.  This works for all endpoint service types.  For example:
    ep:Connect([nil], nil);
 Why Synchronous Comms Are Evil  (2/1/96)

Q:    Why does the following loop run slower and slower with each successive output? If the data variable contains a sufficiently large number of items, the endpoint times out or the Newton reboots before all the data is transmitted. For instance:
    data := [....];
    for item := 0 to Length(data) - 1 do
        ep:Output(data[ item ], nil, nil);


A:    When protoBasicEndpoint performs a function synchronously, it creates a special kind of "sub-task" to perform the interprocess call to the comm tool task.  The sub-task causes the main NewtonScript task to suspend execution until the sub-task receives the "operation completed" response from the comm tool task, at which time the sub-task returns control to the main NewtonScript task, and execution continues.

    The sub-task, however, is not disposed of until control returns to the main NewtonScript event loop.  In effect, each and every synchronous call is allocating memory and task execution time until control is returned to the main NewtonScript event loop!  For a small number of sucessive synchronous operations, this is fine.

    A fully asynchronous implementation, on the other hand, is faster, uses less machine resources, allows the user to interact at any point in the loop, and is generally very easy to implement.  The above loop can be rewritten as follows:

ep.fData := [....];
ep.fIndex := 0;
ep.fOutSpec := {
    async:        true,
    completionScript:
        func(ep, options, error)
        if ep.fIndex >= Length(ep.fData) - 1 then
            // indicate we're done
        else
            ep:Output(ep.fData[ ep.fIndex := ep.fIndex + 1 ],
                      nil, ep.fOutSpec )
    };
ep:Output(ep.fData[ ep.fIndex ], nil, ep.fOutSpec );


    Of course, you should always catch and handle any errors that may occur within the loop (completionScript) and exit gracefully.  Such code is left as an excercise for the reader.
 Maximum Speeds with the Serial Port  (9/19/96)

    Here are some rough estimates of the speeds attainable with the Newton serial port in combination with various kinds of flow control. These numbers are rough estimates, and depending on the protocol and amount of data (burst mode or not) you might get higher or lower transmission speeds. Experiment until you have found the optimal transmission speed.

    •    0 to 38.4 Kbps
    No handshaking necessary for short bursts, but long transmissions require flow control (either hardware or XON/XOFF).

    •    38.4 Kbps to 115 Kbps
    Require flow control, preferably hardware, but XON/XOFF should also work reasonably reliably.

    •    115 Kbps +
    You will encounter problems with latency and buffer sizes.  Speeds in this range require an error correcting protocol.

    Both hardware and XON/XOFF flow control can be set with the kCMOInputFlowControlParms and kCMOOutputFlowControlParms options.  In the case of hardware handshaking (RTS/CTS) you should use the following options:

{    label:    kCMOInputFlowControlParms,
    type:        'option,
    opCode:    opSetRequired,
    data:        {    arglist: [
                        kDefaultXonChar,
                        kDefaultXoffChar,
                        NIL,
                        TRUE,
                        0,
                        0,    ],
                    typelist: ['struct,
                        'byte,
                        'byte,
                        'boolean,
                        'boolean,
                        'boolean,
                        'boolean,    ],
                },
},

{    label:    kCMOOutputFlowControlParms,
    type:        'option,
    opCode:    opSetRequired,
    data:        {    arglist: [
                        kDefaultXonChar,
                        kDefaultXoffChar,
                        NIL,
                        TRUE,
                        0,
                        0,    ],
                    typelist: ['struct,
                        'byte,
                        'byte,
                        'boolean,
                        'boolean,
                        'boolean,
                        'boolean,    ],
                },
}

 Why Are User Modem Settings Ignored  (1/15/97)

Q:    Our customers are complaining that modem preferences such as Ignore Dial Tone are getting ignored in our product. We are not doing anything special to set up the modem so why are the system settings ignored?

A:    The user modem settings do not come for free. You must configure your endpoint based on the user settings. You can get these using the MakeModemOption call.

    In general, we recommend that you always use MakeModemOption when setting up options to intiailize an endpoint. So you would call MakeModemOption to get your initial option array, then add your own custom options after that.  MakeModemOption will return correct options based on the user settings for ignore DialTone, use PC Card Modem, etc.
 Handling a -36006 Error When Disconnecting  (1/17/97)

Q:    Sometimes -36006 is thrown when I call my endpoint's disconnect method.  What is happening?

A:    This error will occur when Disconnect is called on a dropped connection.  In fact, any time the endpoint state does not match the expected state of the calling method, a -36006 exception will be thrown.

    To work around this problem, include an EventHandler method in your endpoint.  When the connection drops, the EventHandler will be called and passed an event with an eventCode of 2.  Simply add a delayed call to unbind and dispose of your endpoint.    Do not use a deferred call to unbind and dispose of your endpoint: a bug in the deferred call mechanism can cause unpredictable results with communications code.
 InputSpec Input Form 'Frame or 'Binary Buffer Bug  (1/22/97)

Q:    I have an inputSpec of form 'string.  When its inputScript triggers, I switch to an input form of 'binary.  When the binary inputScript triggers, the first few bytes of the data are garbage, and sometimes the inputScript doesn't trigger at all.  The same behavior occurs when switching to the 'frame input form.  Why?

A:    Binary and frame (B/F) input forms do not buffer incoming data the same way other input forms do.  For maximum performance, the data is written directly into the destination object, rather than into an intermediate NewtonScript buffer for endSequence and filter processing.

    Unfortunately, all data that has been buffered using a non-B/F input form is lost when switching to a B/F input form, resulting in corrupted data at the start of input, incorrect byteCount, or end-of-packet (EOP) detection failure.

    The only workaround for this problem is to have the sender wait until the receiver has switched input forms and has flushed the input buffers before sending the binary data.  In other words:
        1.  receive data using a non-B/F input form
        2.  flush the input buffer
        3.  switch to a B/F input form
        4.  tell the sender you're ready to receive more data
        5.  receive data
 How to Debug Communication Endpoint Code  (3/21/97)

Q:    Is there any way I can use the NTK Inspector while running communications code? How do I debug my endpoint code? 

A:    If you are using a serial or MNP serial endpoint, you can use a serial PC Card to do your comms, freeing the standard serial port for the NTK Inspector. If you are using a serial or MNP serial endpoint, you must  also modify your endpoint's instantiate options to use a PCMCIA slot instead of the built-in serial port.  Here is the option you should add directly after the endpoint service option:
{
    type:          'option,
    label:          kCMOSerialHWChipLoc,
    opCode:         opSetRequired,
    form:           'template,
    result:         nil,
    data:           {
        argList:  [kHWLocPCMCIASlot1, 0],       // or kHWLocPCMCIASlot2
        typeList: ['struct, ['array, 'char, 4], 'uLong]
      }

    }

    If you are using Newton Internet Enabler (NIE) endpoints, you can use a PC Card Modem instead of a serial PC Card, but you do not have to add any special endpoint options. NIE will handle this automatically, provided you correctly set up your modem in the Modem preferences in the Prefs application.

    This should allow your endpoint code to use the PC Card (serial card or modem card) instead of the built-in serial port. Connect the NTK Inspector to the built-in serial port as you normally would.  If you are using an AppleTalk endpoint, you can simultaneously use the NTK inspector connected via AppleTalk.
 XOn/XOff Software Flow Control Options  (4/3/97)

Q:    XOn/XOff software flow control isn't working.  What could I be doing wrong?

A:    A quirk in the way Unicode characters are packed into 'char fields in the endpoint option is preventing the correct flow control characters from being set in the serial driver.  The solution is to use the 'byte symbol rather than the 'char symbol for these fields, thus avoiding the Unicode-to-ASCII conversion that would normally take place.  The Newton Programmer's Guide is incorrect; the correct option frames are as follows:

{ label:    kCMOInputFlowControlParms,
  type:     'option,
  opCode:   opSetRequired,
  result:   nil,
  form:     'template,
  data: {
    arglist:  [
      unicodeDC1,           // xonChar  
      unicodeDC3,           // xoffChar 
      true,                 // useSoftFlowControl 
      nil,                  // useHardFlowControl 
      0,                    // not needed; returned 
      0,  ],                // not needed; returned 
    typelist: ['struct,
      'byte,                // XON character
      'byte,                // XOFF character
      'boolean,             // software flow control
      'boolean,             // hardware flow control
      'boolean,             // hardware flow blocked
      'boolean, ],  },  },  // software flow blocked

{ label:    kCMOOutputFlowControlParms,
  type:     'option,
  opCode:   opSetRequired,
  result:   nil,
  form:     'template,
  data: {
    arglist:  [
      unicodeDC1,           // xonChar  
      unicodeDC3,           // xoffChar 
      true,                 // useSoftFlowControl 
      nil,                  // useHardFlowControl 
      0,                    // not needed; returned 
      0,  ],                // not needed; returned 
    typelist: ['struct,
      'byte,                // XON character
      'byte,                // XOFF character
      'boolean,             // software flow control
      'boolean,             // hardware flow control
      'boolean,             // hardware flow blocked
      'boolean, ],  },  },  // software flow blocked

 Sharp IR Protocol  (4/9/97)

    
    1    Serial Chip Settings
    Baud rate    9600
    Data bits    8
    Stop bits    1
    Parity       Odd


    2    Hardware Restrictions
    The IR hardware used in the Sharp Wizard series (as well as Newtons and other devices) requires a brief stablizing period when switching from transmitting mode to receiving mode.  Specifically, it is not possible to receive data for two milliseconds after transmitting. Therefore, all devices should wait three milliseconds after completion of a receive before transmitting.

    3    Packet Structure
    There are two kinds of Packets: "Packet I" and "Packet II". Because the IR unit is unstable at the start of a data transmission, DUMMY (5 bytes of null code (0x00)) and START ID (0x96) begin both packet types. At least two null bytes must be processed by the receiver as DUMMY before the START ID of a packet is considered.  After this (DUMMY, START ID) sequence the PACKET ID is transmitted.  Code 0x82 is the packet ID for a PACKET I transmission, and code 0x81 is the packet ID for a PACKET II transmission.

    3.1    Packet I
    This packet type is used to transmit the following control messages:

    3.1.1    Request to send                        ENQ (0x05)
    3.1.2    Clear to send                        SYN (0x16)
    3.1.3    Completion of receiving data        ACK (0x06)
    3.1.4    Failed to receive data                NAK (0x15)
    3.1.5    Interruption of receiving data        CAN (0x18)

    The format of this packet type is as follows:

             Byte length    Set value in transmission    Detection method in reception    
DUMMY        5              0x00 * 5                     Only 2 bytes are detected when received.    
START ID     1              0x96
PACKET ID    1              0x82
DATA         1              above mentioned data


    Packet I example:

DUMMY                     START ID    PACKET ID    DATA    
0x00, 0x00, 0x00, 0x00    0x96        0x82         0x05    



    3.2    Packet II
    This packet type is used to transmit data.  The maximum amount of data that may be transmitted in one packet is 512 bytes. If more than 512 bytes are to be transmitted, they are sent as several consecutive 512-byte packets.  The last packet need not be padded if it is less than 512 bytes and is distinguished by a BLOCK NO value of 0xFFFF.

    The format of this packet type is as follows:

             Byte length    Set value in transmission    Detection method in reception
DUMMY        5              0x00 * 5                     Only 2 bytes are detected.
START ID     1              0x96
PACKET ID    1              0x81
VERSION      1              0x10                         Judge only bits 7-4
BLOCK NO     2 (L/H)        0x0001 ~ 0xFFFF
CTRL CODE    1              0x01                         Don't judge
DEV CODE     1              0x40                         Don't judge
ID CODE      1              0xFE                         Don't judge
DLENGTH      2 (L/H)        0x0001 ~ 0x0200
DATA         1 ~ 512
CHKSUM       2 (L/H)

 
    BLOCK NO in last block must be set to 0xFFFF.

    CHKSUM is the two-byte sum of all of the data bytes of DATA where any overflow or carry is discarded immediately.

    Send all two-byte integers lower byte first and upper byte second.

    Packet II example:

DUMMY                      START ID    PACKET ID    VERSION    BLOCK    NO      CTRL CODE
0x00, 0x00, 0x00, 0x00     0x96        0x81         0x10       Low      High    0x01


DEV CODE    ID CODE    DLENGTH            data    CHECKSUM
0x40        0xFE       Low        High    ????    Low         High



    4    Protocol
    Data will be divided into several blocks of up to 512 bytes each.  These blocks are transmitted using type I and II packets as follows:

    4.1    Transmission Protocol

    4.1.1    The initiating device (A) begins a session by sending an ENQ (type I) packet.  The receiving device (B) will acknowledge the ENQ by transmitting a SYN packet.

    4.1.2    When (A) receives a SYN packet, it goes to step 4.1.4 below.

    4.1.3    When (A) receives a CAN packet, or when 6 minutes have elapsed without a SYN packet reply to an ENQ packet, (A) terminates the session.  If (A) receives any other packet, no packet, or an incomplete packet, it begins sending ENQ packets every 0.5 seconds.

    4.1.4    When (A) receives a SYN packet, it transmits a single type II data packet, then awaits an ACK packet from (B).

    4.1.5    When (A) receives an ACK packet, the transmission is considered successful.

    4.1.6    If no ACK packet is received within 1 second from completion of step 4.1.4, or if any other packet is received, (A) goes to step 4.1.1 and transmits the data again. Retransmission is attempted once. The session is terminated if the second transmission is unsuccessful.

    4.2    Reception Protocol

    4.2.1    The receiving device (B) begins a session by waiting for an ENQ (type I) packet. If no ENQ packet is received after 6 minutes (B) terminates the session.

    4.2.2    When (B) receives an ENQ packet, (B) transmits either a SYN packet to continue the session or a CAN packet to terminate the session.

    4.2.3    When (B) receives a valid type II packet (for example, the checksum and all header fields appear to be correct), (B) transmits an ACK packet.

    4.2.4    If one or more header fields of the data packet are not correct, or if the time between data bytes is more than 1 second, (B) goes to step 4.2.1 and does not transmit the ACK packet (this will cause (A) to retransmit the packet after a one second delay).

    4.2.5    If the header fields of the data packet appear to be correct but the checksum is incorrect, (B) transmits a NAK packet (this will cause (A) to retransmit the packet immediately).

    Because of the restriction in hardware mentioned in item 2 above, it is not possible to receive data for two  milliseconds after a data transmission.  Please wait three milliseconds before transmitting a response to the other device.

    (see diagram)
Q&A Diagram
NEW: Using Procrastinated Actions from an InputScript  (7/2/97)

Q:    Calling AddProcrastinatedCall or AddProcrastinatedSend repeatedly with the same symbol from my input specification's InputScript method sometimes causes an out of memory exception on pre-Newton 2.1 devices.  What's going wrong?

A:    If you post a procrastinated action from an InputScript, it may not be executed until a much later time. Due to a bug in the way procrastinated actions with the same symbol are queued, it's possible to queue so many events that you run out of NewtonScript heap memory.  This bug is fixed in the Newton 2.1 OS.

    Here are two possible workarounds:

    1) Use AddDelayedCall or AddDelayedSend in place of a procrastinated action.

    2) Buffer the incoming data (perhaps into a temporary soup).  Once the download has completed, perform the necessary operations on this data.  This method also provides transactional integrity in the event the communications connection is unexpectedly torn down while downloading.
NEW: Using the EventHandler Event Time Slot  (7/2/97)

Q:    The Newton Programmer's Guide states that the 'time slot of the event frame passed to an endpoint's EventHandler is in ticks.  After some experimentation, I've discovered that it is not in ticks.  What is this time value?

A:    The time value is actually the number of milliseconds since the Newton device was last reset.  The Newton Programmer's Guide incorrectly states that it is the number of ticks since the unit was last reset.  Note that because the unit of time is milliseconds, you can exceed NewtonScript's integer representation fairly quickly.  

    When you do run out of bits of precision for the millisecond value, the number will wrap to the smallest representable integer in NewtonScript.  According to two's complement binary representation, that number is 0x3FFFFFFF, or -536870912 decimal. Therefore, the time  value will start counting at zero, count up to 536870911, wrap to -536870912 then start to count back up to 536870911.