• 1 Project Status
• 2 Introduction
  • 2.1 Intended readership
  • 2.2 Download Information
  • 2.3 Mailing List
  • 2.4 References and Acknowledgements
• 3 Appendix A: Protocol Documentation
  • 3.1 Overview of the remote link
  • 3.2 The PLP Protocol
    • 3.2.1 Description
    • 3.2.2 Frame Formats
  • 3.3 The NCP Protocol
    • 3.3.1 Description
    • 3.3.2 Frame Formats
  • 3.4 The LINK application
    • 3.4.1 Description
    • 3.4.2 Frame Formats
  • 3.5 The SYS$RFSV application
    • 3.5.1 Description
    • 3.5.2 Frame Formats
  • 3.6 Other user applications

I've been beaten to it (again) - Philip Proudman released his stack (plp) and Fritz Elfert extended it (plptools). So, I've abandoned work on my own protocol stack, and am concentrating on extending plptools. My efforts towards this can be found here.

The only part of this project likely to survive is the NCP protocol analyser, and the Linux Kernel modules - I'll create new pages for these as and when I find time.

2 Introduction

Release 0.02 on hold.

What may be of use to you (if you're a developer) are the scope and ncpscope programs, contained in the package. They are a general-purpose RS232 line monitor/logger (This is now a separate package - see scope for more details) - and a PLP/NCP/RFSV protocol analyser. The first is relatively finished, the second isn't, but still very useful. There is also a captured session, created by scope, when I was copying files etc. between my Psion 3c and PsiWin1.1. Run this through ncpscope to find out what's going on...

I'll continue refining ncpscope, so check back here from time to time...

I've crashed my Psion 3c several times during development of my driver program (not scope or ncpscope) - once, erasing the entire internal ramdrive, otherwise just resetting it, requiring a re-installation of icons and preferences.

This surprised me somewhat - I can understand my software being buggy, but it shouldn't crash the remote system. (I'm told that if a loadable device driver panics, it causes a SIBO kernel fault. Sounds suspiciously like a reboot to me!)

You can grab it here: linux-ncp-0.01.tar.gz.

Although the ncp program source is included in this package, it won't build (since it's not finished yet). All you get is scope and ncpscope. Feedback on this software is most welcome, either to me directly, or to the following mailing list...

2.3 Mailing List

To subscribe, send a message to majordomo@geekstuff.co.uk, containing the message subscribe linux-psion.

2.4 References and Acknowledgements

• Olaf Flebbe and Michael Pieper, for their assistance in documenting the Psion Link Protocol. The appendix of this document is a condensation of their work. We all owe Olaf and Michael a big "danke" for their work!
• The maintainers of the linux-psion@geekstuff.co.uk mailing list, and the members of that list, for giving me the impetus to start this project.
• Linus Torvalds, Richard Stallman (and a cast of thousands), for the Linux Kernel and GNU project.
• Bram Moolenar et al for "vi improved" -- the ultimate editor for those who don't yet need Emacs ;-)
• Red Hat, for their splendid distribution for Intel and Sparc.
• Psion, for the Series 3.

For information on writing Linux Device Drivers/Filesystems/Line Disciplines, I have to thank:

• Allessandro Rubini, for "Writing Linux Device Drivers",
• David A. Rusling, for "The Linux Kernel",
• Paul Fulghum of Microgate Corporation, for releasing the source code to their Line Discipline driver under the GPL.
• Linus Torvalds, et al. for the Linux Kernel

It isn't finished.

3.1 Overview of the remote link

• The physical layer concerns the serial driver, the baud rate used, framing etc.
• The logical link layer, which is denoted in the references as PLP (Psion Link Protocol), which provides a reliable link for the...
• Transport and Multiplexing layer, known as NCP (Network Control Protocol). This in turn is used by the...
• Application layer, typically Psion's remote file server (RFSV), or the LINK program. It can also be used by other user applications.

So, the first phase will handle physical, logical, network layers, and provide a LINK server and SYS$RFSV server. The second phase will provide a RFSV client that maps Linux VFS requests into RFSV protocol frames, routed over NCP/PLP.

I may separate PLP and NCP into a line discipline module - I haven't decided yet.

3.2 The PLP Protocol

PLP is a simple protocol, designed to fit into small amounts of memory, based on the MicroCom Network Protocol (MNP). It provides a symmetric full-duplex link, with error-detection being aided by the CCITT 16-bit CRC, with polynomial x¹⁶+x¹²+x⁵+1 (i.e. starting value 0x1021).

Frames are numbered, multiple retransmissions are allowed, and the the window size is only one, so the link is probably not very efficient (but it doesn't need to be).

Every frame that is sent must be acknowledged. If no acknowledgement is received within some as-yet unascertained tineout period, the frame is resent.

Frames may be up to 300 bytes, and the frame size is variable. PLP (or is it NCP?) will segment large transmissions into 300-byte chunks as necessary.

PLP is a data transfer protocol, not a file transfer protocol - additional application layers need to be added which supply file access and management facilities. PLP protocol passes undifferentiated bytes.

3.2.2 Frame Formats

    SYN HEADER TYPE DATA FOOTER CRC

• SYN is ASCII 0x16
• The HEADER is composed of the bytes 0x10, 0x02
• The TYPE is one of:
  • 0x0? : ACKNOWLEDGEMENT of a previously-sent DATA frame. The low nibble (?) contains the sequence number of the frame being acknowledged. There is no DATA section in an ACKNOWLEDGEMENT frame. Frame numbers are modulo 15 (they wrap to zero at 0x0F)
  • 0x1? : DISCONNECT. Sent when the Psion's remote link is turned off (Psion-L) The low nibble (?) is unspecified, and is zero.
  • 0x2? : LINK REQUEST. Requests a new link session. When responding to this, an ACKNOWLEDGEMENT frame must be sent with the sequence number reset to zero. There is no DATA section in a LINK REQUEST.
  • 0x3? : DATA. The DATA part of the frame holds an NCP frame. The low nibble (?) contains the sequence number, and this frame must be replied to with an ACKNOWLEDGEMENT frame containing the same sequence number. Since only one frame can remain "on the wire", unacknowledged, the process or protocol layer sending data must block until an acknowledgement has been received. CRC errors will result in no acknowledgement being sent. The retransmission timeout period is unknown.
• The FOOTER is always 0x10, 0x03
• The CRC is the CCITT 16-bit CRC. It is calculated from the TYPE byte to the end of the DATA part, and does not include SYN, HEADER or FOOTER.

Once a physical connection has been made (the driver sees the DSR signal, i.e. the remote side's DTR), the Psion's PLP layer will send a LINK REQUEST message to the PC, which must be acknowledged.

Then, the Psion NCP layer exchanges logon messages with the remote side. The logon messages contain a version number and the time at which the NCP layer started. This allows connections to be re-started in the event of a logical or physical layer failure. SIBO computers tend to reply with a version3, whereas PsiWin is version 2.

These logon messages are sent as NCON_MSG_NCP_INFO frames. The Psion's frame is received and acknowledged, and then the PC must send one, which will be acknowledged. The NCP link is then active.

NCP provides eight logical channels, multiplexed over the physical link. Channel 0 is used by the NCP protocol driver itself, to communicate with its remote counterpart, and is the only channel that does not have to be explicity connected to.

Applications talk over the remote link, over a given channel. NCP talks to NCP over channel zero. For instance, the timestamp frames explained above are sent over channel 0. The remaining seven channels are available for applications (Although LINK and SYS$RFSV take up two, automatically).

Applications can send frames of arbitrary sizes; NCP performs fragmentation and reassembly.

3.3.2 Frame Formats

    TX-CHANNEL RX-CHANNEL DATA

• TX-CHANNEL is a byte indicating the channel number of the sending process
• RX-CHANNEL is a byte indicating the channel number of the receiving process (The channel that this message is concerning, as in a CONNECT to channel 3, this byte would hold 0x03)
• The DATA is only of consequence to NCP if the TX-CHANNEL is 0, i.e. if this is a control frame for the remote NCP layer to process. If the TX-CHANNEL is not zero, then this data is passed to the process bound to that channel. For instance, SYS$RFSV or LINK.

Need to finish description of NCP, and start on...

3.4 The LINK application

LINK also handles IPC (Inter-Process Communication) messages. Applications may send the following messages to the LINK process:

• LINKMSG_TERMINATE - terminate the LINK application, close the SYS$RFSV, and close SYS$NCP.
• LINKMSG_LOADREMOTE - load a process on the remote system. The remote side will load the program named in the protocol frame, and this process will then open an NCP channel. The remote LINK then sends the process ID and full process name back to the local LINK, which passes back the name and process ID to the application on the local machine that initiated the LINKMSG_LOADREMOTE.
• LINKMSG_CONFIG - pass information to the remote LINK, for use during a device driver reconfiguration.

In phase I of this implementation, only the RFSV server will be provided, allowing you to access the Linux filesystem from your Psion. Phase II is to write a userfs daemon which converts userfs/VFS requests into RFSV frames, channeled over NCP so that the Linux system can mount the Psion's drives. i.e. an RFSV client.

3.5.2 Frame Formats

    FRAME-NUMBER COMMAND SIZE DATA

• FRAME-NUMBER is a byte, indicating a fragment number in a large transmission. For small (< 300 bytes) frames, the FRAME-NUMBER is 1. Larger operations, such as a large RFSV_FWRITE operation may fragment their data over multiple frames, starting with a high FRAME-NUMBER (say, 5), and decrementing this with each frame, until it reaches 1, which is the final frame. Note that frames with a FRAME-NUMBER > 1 will not contain any COMMAND - the protocol remembers that it is in a write, and just needs the data.
• COMMAND is a little-endian word as shown in the table below.
• SIZE is a little-endian word giving the amount of data that follows in the DATA area.
• DATA is data required by the command in question, of variable format.

To be continued...

3.6 Other user applications