Simtel MSDOS 1992 June

home *** CD-ROM | disk | FTP | other *** search

/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / cis / cis_b.arc / BPROTO.DOC < prev next >

Wrap

Text File | 1988-04-22 | 106.4 KB | 2,784 lines

CompuServe Information Service VIDTEX 4.0 Standards for Terminal Emulator Programs Copyright 1985 by CompuServe Incorporated, Columbus Ohio April, 1985 NOTE The information in this document is subject to change without notice and should not be construed as a commitment by CompuServe Incorporated. CHAPTER 1 INTRODUCTION 1.1 PURPOSE The CompuServe information service is a low cost remote computing service designed for use by the general public. It is simple to use, yet has many very powerful capabilities. Similar in some respects to European "viewdata" systems, the service is based on a tree structured, menu driven data base. The data base consists of individual pages or "frames." Currently CompuServe supports a terminal standard for terminal emulation programs. CompuServe provides a series of terminal executive programs called VIDTEX which implements this standard. These executives implement a common set of features given the widely varying capabilities of microcomputer systems. This document describes the features of the VIDTEX 4.0 software. VIDTEX implements error detection and retransmission protocols for the purpose of file transfer and program loading. This protocol is called the "CompuServe B Protocol". This document outlines the VIDTEX 4.0 implementation of the following capabilities: Video Processing Medium Graphics (128 x 96) Fine Graphics (256 x 192) Cursor positioning Terminal Loop Processing Meta Key Processing B Protocol Error detection.retransmission File transfer In general, the Host computer will not attempt to use any of the advanced features unless the <ESC>I interrogation response is implemented by the remote. The interrogate response tells the Host which capabilities are implemented in the terminal. If no response or an unknown response is received from the <ESC>I interrogation, the terminal is assumed to be totally "dumb", with no cursor control, graphics, color capability. Page 1-2 An important exception to the interrogation prerequisite is a user request for file transfer when the terminal type is known by the host. The host software will present a menu of file transfer methods instead of sending <ESC>I. Page 1-3 1.2 CONVENTIONS USED IN THIS DOCUMENT Throughout this document the following conventions are used: <xxx> - denotes an ASCII control character where xxx is the standard name of the character (e.g. <ESC> is the ASCII Escape character, 1B hex). <x> - denotes a printable ASCII character (e.g. <A> is an ASCII upper case "A", 41 hex). <nnn> - denotes the ASCII character whose value is nnn decimal. Whenever an expression is given, it is always in decimal. lower case denotes a variable which is actually substituted by a string of ASCII characters or a decimal value. UPPER CASE denotes an ASCII character string exactly as shown. CHAPTER 2 USER INTERFACE REQUIREMENTS 2.1 COMMUNICATIONS If the computer has an internal modem, it must conform to either the Bell 103 or Bell 212 modulation standards. To communicate with CompuServe, the modem must be set to originate mode and full duplex. 2.2 KEYBOARD A full ASCII alphanumeric keyboard is required, although lower case and most control codes are optional. Carriage return (control-M) is necessary to log on. If it can be detected that a key has been held down for approximately two seconds, it should auto-repeat. If hardware permits, the user should be able to transmit a break sequence. VIDTEX 4.0 utilizes the concept of "meta keys" to permit access to many of the advanced features. The keyboard implementation must provide a means for the user to type these meta keys. Meta key encoding has precedence over control key encoding. Control key encoding has precedence over shift key encoding. For example, Meta and Control and "a" is Meta-A. Meta and "a" is also Meta-A. Some keyboards lack labeled keys for typing such characters as "{", "|", "}", and "~" (7B though 7E hexadecimal). VIDTEX should redefine keys to allow the entire ASCII character set to be transmitted. An effort should be made to relate the label on the redefined keys and the characters generated. For example, shift-[ could be "{" or control-! could be "|". A line of input from the keyboard is obtained in the following manner. The user is allowed to type any displayable character (See Minimum Video Display Requirements). As a character is entered it should be echoed to the screen. The line of input can be terminated by a carriage return or an ESCAPE. Except in the case of file names, the carriage return will be included in the line of input. The ESCAPE terminates the line but is not included. Other control codes and meta keys are not permitted in the input line. During entry, the control codes backspace and control-U will provide a simple editing facility Page 2-2 for the user. Note that backspace is destructive and control-U clears the entire entry line. The entry of control-C is treated as a control-U. If the user enters a Meta-A the line input function is terminated and the abort status is passed to the calling routine. 2.3 MINIMUM VIDEO DISPLAY REQUIREMENTS A minimum of 32 characters per line and 16 lines is required. If the terminal line width is 64 characters or greater, a double width character option is desirable and should be implemented (see Escape Sequences). The display should support the full ASCII character set although lower case is optional. The displayable characters are defined as the ASCII characters <SPACE> through <~>, inclusive (20 through 7E hexadecimal). If lowercase is not supported, all lowercase characters must be mapped into the equivalent upper case characters. If the display hardware does not support the correct display of some ASCII characters, the video driver should map these characters to those of similar shape. Examples of commonly unimplemented characters include "{", "|", "}", "~", "_", "^", and "\". CHAPTER 3 VIDEO DRIVER REQUIREMENTS 3.1 TERMINOLOGY In order to specify the video functions some terminology needs to be introduced. The home position refers to the upper left most character position on the screen. A screen line is a grouping of adjacent character positions which appear on the same physical screen line. The character position preceding the first character on a screen line is the last character position of the previous line, except for the home position which has no preceding character position. The character position following the last character on a screen line is the first character position of the next line, except for the last character position on the last line which has no following character position. A video operation is an operation which changes the contents of one or more character positions, changes the cursor position, or alters the mode of video operations. A video operation can be as simple as displaying the next character or as complex as positioning the cursor or changing screen colors. The cursor is a means of representing the active character position. A video operation may reference the current cursor position. The current cursor position may be different following a video operation. 3.2 VIDEO INITIALIZATION At program execution the display screen should be cleared and a program identification message displayed. The message should be in the following format: "name Vv.e" The first item is the program name, "name". The numbers "v" and "e" are the version and edit number, respectively. The default mode is normal text mode and the default screen colors should be chosen for display readability. Page 3-2 3.3 TEXT MODE PROCESSING 3.3.1 Cursor Display The cursor must be displayed on the screen by some means such as reverse video, an underscore, or a graphic block. The cursor should be displayed following most video operations. The cursor should not be displayed if it was not defined after the last operation or during the processing of a video operation, including the reception of arguments during escape processing. 3.3.2 Text Display A text character will be displayed by placing the character on the screen at the current cursor position. The cursor is placed at the following character position. 3.3.3 Scrolling If a character is placed in the last position of the last line, the cursor will be placed at the first column of an imaginary line below the bottom line. The screen will not scroll until an attempt is made to actually display a character there. 3.3.4 ASCII Control Codes The terminal must respond to the following ASCII control codes: 3.3.4.1 <BEL> - Bell If the terminal has sound capability, it should produce a bell (beep) sound. 3.3.4.2 <BS> - Backspace The cursor is moved back one character position and replaces the character which was previously there with a space. If the cursor is on the first position of a line, it should move to the rightmost position of the previous line. If the cursor is in the top left corner of the screen, no action should be taken. Page 3-3 3.3.4.3 <HT> - Horizontal Tab The cursor is moved enough character positions to place the cursor at the next tab stop. Tab stops occur in the first column and every eight columns after that (i.e. columns 1,9,17,...). When at or past the last tab stop on a line, a tab will move the cursor to the first position of the following line. 3.3.4.4 <LF> - Line Feed The cursor is moved down one line without changing its relative horizontal position. If the cursor is on the bottom line, move the cursor down a line and scroll the screen one line so that the cursor is on the bottom line again. 3.3.4.5 <FF> - Form Feed Clear the screen to blanks and position the cursor in the upper left corner. 3.3.4.6 <CR> - Carriage Return Move the cursor to column one of the current line without destroying the character there. Note that if a <CR> is received after a character has been placed in the last column on a line, the cursor will have wrapped to the first position on the next line. In that nothing has been displayed, the carriage return requires the cursor to move up one line. The cursor should not be displayed (turned on) following a carriage return. 3.3.4.7 Unimplemented Control Codes The video driver should ignore all other control codes. 3.3.5 Word Cleaning The function of word cleaning is to attempt to prevent breaking words due to line wrapping. This is accomplished by moving entire words (or cleaning) to the next line. Page 3-4 If a character has been displayed on the last character position of a line and the next character is a space, word cleaning is not necessary. If the next character is a displayable character, then scan the line backwards looking for a space. Scan no more than 20 positions. If a space is not found, then place the next character in the first position on the following line. Having searched and found a space, copy each character between the space and the end of the line to the next line and place a space in the character's original position. Place the character received in the next available location. This makes it easier to read text which is wider than the screen width. For example, without word cleaning the following might be displayed: Now is the time for all very good progra mmers to come to the aid of their countr y. With cleaning, this would be displayed as: Now is the time for all very good programmers to come to the aid of their country. 3.4 VIDEO ESCAPE SEQUENCES The Host computer will not attempt to use the following video functions unless the <ESC>I interrogation is implemented. The following escape sequences are defined to be emulated by all VIDTEX 4.0 compatible software. In each case the given character is preceeded by an escape character (1B hex). The terminal is responsible for converting the standard protocol data into machine dependent functions and codes. Data that is inapplicable to a particular terminal should be simply discarded (e.g., chroma bits on a black and white unit). All characters not specifically mentioned are reserved by CompuServe Incorporated for future expansion. 3.4.1 Video ESCAPE Sequence Summary The following table summarizes the video escape sequences and the functions they perform. Note the difference between lower and upper case; this is very important! Page 3-5 Sequence Effect on Terminal <ESC><A> Move cursor up one line <ESC> Move cursor down one line <ESC><C> Move cursor right one space <ESC><D> Move cursor left one space <ESC><G><mode> Change graphics mode <ESC><H> Move cursor to the top left corner <ESC><K> Clear from cursor to end of line <ESC><J> Clear from cursor to end of screen <ESC><j> Clear page - same as an ASCII Form Feed <ESC><l> Set normal character width <ESC><m> Set wide character width <ESC><Y><lin><col> Set cursor position 3.4.2 <ESC><A> - Cursor Up The cursor is moved up one line without changing its relative horizontal position. If the cursor is on the top line, it wraps to the same horizontal position on the bottom line. The cursor must not destroy the character which was previously there. 3.4.3 <ESC> - Cursor Down The cursor is moved down one line without changing its relative horizontal position. If the cursor is on the bottom line, it wraps to the same horizontal position on the top line. The cursor must not destroy the character which was previously there. 3.4.4 <ESC><C> - Cursor Right The cursor is moved right one column. If the cursor is at the last column, it wraps to the first position on the next line. If the cursor is at the bottom right corner, it wraps to the top left corner. The cursor must not destroy the character which was previously there. 3.4.5 <ESC><D> - Cursor Left The cursor is moved left one column. If the cursor is at the first column, it wraps to the last column on the previous line. If the cursor is at the top left corner, it wraps to bottom right corner. The cursor must not destroy the character which was previously there. Page 3-6 3.4.6 <ESC><H> - Home Cursor The cursor is moved to row one, column one. The cursor must not destroy the character which was previously there. 3.4.7 <ESC><Y><lin><col> - Position Cursor The cursor is positioned at the screen location specified by the next two characters. The first character is the line number plus 31 and the second character is the column number plus 31. The home position is located at cursor position line one, column one. If a line or column code falls outside the range of valid values, the invalid code is replaced by the valid code of nearest magnitude. 3.4.8 <ESC><G> - Graphics Mode Control Graphics control is done by a three character sequence. The third character determines the specific function. 3.4.8.1 <ESC><G><N> - Normal Mode The video mode is reset to "normal" mode (text only). The screen should not be changed until the display of the next character. In this mode the parity bit is unpredictable. Upon entering normal mode, the previous state of the graphics screen is unknown. No graphic character or image can be presumed to propagate to normal mode. The return to normal mode is typically followed by a clear screen to remove any graphic residues. 3.4.8.2 <ESC><G><H> - High Resolution Graphics The screen is cleared to black and high resolution graphics mode (256 x 192 pixels) is entered. In this mode data is sent as pairs of run length encoded characters. The first character of the pair indicates the number of background pixels and the second character indicates the number of foreground pixels. Each character of a pair is the actual count plus 32. In this mode, the parity bit is ignored; thus, the maximum count that can be transmitted is 128-32, 96. For example, the ASCII sequence <L><W> indicates fourty-four background pixels and fifty-five foreground pixels. The line drawing should also wrap from the last position on a line to the first position on the next line. Thus, if the last pixel set on a line was in position 250 and a sequence of 0 background and 10 foreground is received, then the last six pixels are set on the current line and the first four pixels are set on the next line. The keyboard should also be left active while in this mode. Page 3-7 3.4.8.3 <ESC><G><M> - Medium Resolution Graphics The screen is cleared to black and medium resolution graphics mode (128 x 96 pixels) is entered. This mode is identical to high resolution except for the pixel size. 3.4.9 <ESC><K> - Clear To End Of Line The screen is cleared from the current cursor position to the end of the current line. 3.4.10 <ESC><J> - Clear To End Of Page The screen is cleared from the current cursor position to the end of the page. 3.4.11 <ESC><j> - Clear Page The display is cleared and the cursor is positioned in the top left corner. This may also be accomplished by a form feed (0C hexadecimal). 3.4.12 <ESC><l> - Set Normal Character Width The display is set to its narrow character size. Note that normal width character mode has more columns than wide character width mode. 3.4.13 <ESC><m> - Set Wide Character Width The display is set to wide characters provided that wide mode has at least 32 columns. CHAPTER 4 TERMINAL LEVEL PROCESSING 4.1 INTRODUCTION Terminal level refers to the highest level of program operation. The terminal level allows "time sharing" between the various input and output functions. Mainly terminal processing involves the transmission of characters typed by the user and the processing of characters received from the host. 4.2 TERMINAL ESCAPE PROCESSING Terminal level escape processing provides a means for coordinating the activities of the host and the terminal. 4.2.1 <ESC> - Interrogate Remote The terminal responds with a string which identifies its capabilities. The format of the string is: <#>code<,>option list<CR> The <#> implies the device is a VIDEOTEX-compatible unit. The code is a three character string which identifies the manufacturer and model of the terminal. This is optionally followed by a version and modification number. Codes must be arranged by negotiations with CompuServe Incorporated in order to maintain compatibility with our host software. The option list is a string of codes which indicates the features the terminal supports. The option codes are separated by commas. Each option code implies that the terminal supports one or more escape sequences. The <CR> marks the end of the response. For example, the response: Page 4-2 #FRB24,CC,CW,G4,HC<CR> indicates that the machine is a Frobitron computer running version 2.4 of the VIDTEX program which supports cursor control, wide characters, semigraphics 4, and a printer. 4.2.2 Video Enable And Disable When an <ESC><e> sequence is received, the video is disabled and subsequent characters are not displayed. The video is enabled again when an <ESC><f> sequence is received. <ESC><e> and <ESC><f> may be used in conjunction with <DC2> and <DC4> to direct output to the printer without displaying it. 4.2.3 Keyboard Lock And Unlock When an <ESC> sequence is received, the terminal will lock the keyboard and not transmit any more characters typed. Meta key processing will also stop in that the keyboard is locked. This condition is reset when an <ESC><c> sequence is received. These sequences can be used by a host program which does not want to be interrupted during critical processing. 4.2.4 <ESC><ESC> - Hardware Specific Escape This is available for hardware specific functions not otherwise available. Their definition and implementation is the responsibility of the hardware manufacturer. CompuServe reserves the right to not support any hardware specific escapes in its host software. The development and support of the host software is the responsibility of the hardware manufacturer. The VIDTEX 4.0 software should incorporate the following escape-escape sequences. 4.2.4.1 Capture Buffer Control Some common definitions for data capture control are: <ESC><ESC><O> - Open Ram Buffer The copying of incoming text to the capture buffer should begin. <ESC><ESC><C> - Close Ram Buffer The capture buffer copying should stop. <ESC><ESC><Z> - Zero Ram Buffer The capture buffer should be emptied of all data. <ESC><ESC><V> - Transmit Ram Buffer Page 4-3 The current contents of the capture buffer should be transmitted to the host. <ESC><ESC><Y><pmt> - Transmit Ram Buffer with Prompt The current contents of the capture buffer should be transmitted to the host. After transmitting a carriage return, VIDTEX should wait until the single character prompt is received before transmitting the next line to the host. 4.2.4.2 <ESC><ESC><W><lin1><col1><lin2><col2> - Window Control Providing that the terminal supports a text display window, the size and location of the window on the physical screen are to be set. Each argument is a row or column position masked by the addition of 32. The argument pair, <lin1><col1>, specifies the upper-left-hand corner of the window. The argument pair, <lin2><col2>, specifies the lower-right-hand corner of the window. The values for line and column codes follow the rules of cursor positioning and the size of the text window must be 4 rows by 11 columns or larger else the window is removed automatically. Word cleaning is disabled for windows smaller than 20 columns. The SS option code allows the host to interrogate to determine the size of the terminal's screen. The values are transmitted in a manner similar to absolute cursor positioning sequences. The number of lines is added to 31 before transmission. The number of columns is added to 31 before transmission. 4.3 FLOW CONTROL VIDTEX must recognize the standard ASCII flow control characters, <X-OFF> (control-S or DC3) and <X-ON> (control-Q or DC1). If VIDTEX receives an <X-OFF> from the host, it must halt transmission immediately. If an <X-ON> is not received in approximately five seconds, transmission can be resumed. VIDTEX expects the host to observe the same rules. Flow control is used by VIDTEX for delaying the host during remote processing and by the user for regulating the rate of text display from the host. There are several instances where an <X-OFF> is sent to stop transmission from the host temporarily (RAM buffer almost full, printer buffer full, menu selected). Each time VIDTEX begins a remote process which requires the host to wait, it will transmit an <X-OFF> to the host. Some remote functions can contain multiple processing levels. Each level may user flow control. To account for this nesting of flow control transmissions, VIDTEX will count the number of internally-generated <X-OFF>'s. When a level of processing completes, it will request the transmission of an <X-ON>. When an <X-ON> is received by the host it will resume transmission immediately, regardless of how many <X-OFF>'s it has received. When an <X-ON> request is made, VIDTEX will first decrement Page 4-4 the count of <X-OFF>'s sent. If the count is zero then the highest level of flow control has been reached and an <X-ON> is sent. If the count is non-zero then no <X-ON> is sent. The user's use of flow control will have priority over flow control use by VIDTEX. When the user transmits an <X-OFF> OR <SOH> (control-A), VIDTEX will not transmit any <X-ON>'s until the user types an <X-ON>. When the user's <X-ON> is transmitted, the count of <X-OFF>'s sent by VIDTEX will be reset. If the host does not respond to flow control, characters may be dropped. 4.4 PRINTER Since a display type terminal leaves no record the user can refer back to, hardcopy support is a desirable feature. This is particularly applicable to terminal emulator programs for microcomputers since most microcomputers can support a hardcopy printer. The terminal should allow both the host computer and the terminal user to control the printer. The user can access the printer using a meta key. The VIDTEX printer driver will convert standard ASCII into the form used by the printer. Many printers lack horizontal tabs (as defined in the video driver specification). If necessary, VIDTEX will substitute the proper number of spaces for an horizontal tab. Printer output of tabular data should be identical to video output of the same data. If the printer performs a <carriage return><line feed> operation when given a carriage return, VIDTEX will ignore all line feeds that immediately follow carriage returns. This will prevent the printer output from appearing "double spaced." When a <DC2> is received from the host, the terminal should start copying all received data to the printer. When a <DC4> is received from the host, the terminal should stop the copying. The terminal should have a buffer for the printer where characters may be placed if the printer is busy. When the buffer becomes within ten characters of being filled, then the terminal should send a <DC3> to stop the transmission of data. The terminal should continue to empty the printer buffer until the buffer is within ten characters of being empty at which time a <DC1> should be sent to the host to resume data tranmission. This buffering and flow control allows the use of a slow printer at a higher data transmission rate. CHAPTER 5 SIMPLE META KEY FUNCTIONS Meta keys allow the user perform many local functions that users often find to be valuable. For greatest speed and efficiency, most operations are typically accessed by holding the meta key and pressing the key corresponding to the desired function. Less-used functions are accessed via menus. 5.1 COPYING DATA TO THE PRINTER If you type a Meta-R on the keyboard, a copy of all subsequent characters received will be sent to the printer. A Meta-T stops the copying. 5.2 SCREEN PRINT A printed copy of the entire screen should be provided by means of a meta key. The particular key choice is not standard although Meta-* and Meta-: are currently in use. This function cannot be performed remotely. Unless the printer supports graphics, print screen should ignore graphic images. If the printer is not ready when screen print is requested, the cursor will reappear. The screen print can be aborted by typing a Meta-A. 5.3 THE HELP PAGE Meta-H should display a list of redefined keys and a list of those characters substituted for improperly displayed ASCII characters. The user must key carriage return for terminal mode. Page 5-2 5.4 MENU PAGE Meta-M lists all available remote operations. While looking at the menu, the user need only press the letter for the operation they want. The meta key is not required. Pressing carriage return will return to terminal mode. The menu message will provide information concerning the state of the Ram Buffer typically shown as follows: Used: 00000 Free: 00000 The number following "Used:" in the menu indicates how many characters are currently stored in the RAM buffer. The number following "Free:" indicates the number of unused characters available in the RAM buffer. As an option, the menu message may contain a means of flagging the current status of certain features. Possible items to flag include the status of word cleaning on/off and RAM buffer open/closed. 5.5 LOCAL VIDEO CONTROL VIDTEX provides two local video control functions with optional wide mode and text window control. 5.5.1 Screen Clearing A meta key will be chosen to allow the user to locally clear the screen. Meta-CLR is an obvious choice. 5.5.2 Word Cleaning Control A Meta-B will disable the word cleaning function of VIDTEX. This may cause words to start on the right edge of the screen and end on the next line. This mode is useful when you are typing out tables and do not want extra spaces inserted. A Meta-E will enable the word cleaning function. 5.5.3 Wide Character Mode Control If hardware permits a wide character video display mode (32 columns by 16 lines minimum), two meta keys should be designated to allow the user to switch between wide and normal display modes. Meta-W for wide mode and Meta-N for normal mode are currently in use. Page 5-3 5.5.4 Text Window Control As an optional feature, the VIDTEX video driver can allow the user to define the size and location of the "text display window." At execution, the size of the window is the entire screen. Some meta key should be designated to allow the user to set a new size and location. Meta-W is currently in use. A set of instructions should be displayed at the top of the current screen. The user should be allowed to position the cursor anywhere on the screen to indicate where the upper left hand corner of the new text display window should be set. When the cursor is positioned, the user presses carriage return. The cursor is then positioned to set the lower right hand corner of the text window, and carriage return is pressed. The window is now created. The window must be at least 4 lines by 11 columns in size or the window will be set to the full screen. If the window is less than 20 columns word cleaning is disabled. After the window has been created or removed, the cursor is positioned to the upper left-hand corner of the window. Pressing Meta-A at anytime during the window creation sequence should abort window creation and break the window to the full screen. While the window is in effect, all new text will appear inside the window, including the menu and help pages. The video driver should function within the window. All functions valid in normal and semigraphics 4 mode should work in "window mode." Medium and high resolution modes will remove the text window upon entry into these modes. The text window will be set to the full screen upon exit from medium and high resolution modes. The window creation process specifies a rectangular area of the physical screen to be treated as the current screen for all video processing. Each logical screen line begins at the same physical column position. Similarly each screen line ends at the same column position. All character positions outside the "active window" should never be acted upon by the video driver. Notably, when the cursor is moved to the undefined character position past the last character position on the last line, the cursor should not appear. 5.6 VIDTEX 4.0 DISK VERSUS TAPE VIDTEX is typically a disk-based program. VIDTEX can alternately be written as a tape-based program. A tape version of VIDTEX will be severely limited in terms of advanced capabilities. The following descriptions will presume a disk-based system. Page 5-4 5.7 INPUT TO DISK OPERATIONS Whenever VIDTEX requires a file name for a local operation, a descriptive prompt will be displayed. The user may enter a file name. The file name will be a line of keyboard input (See Keyboard). If the user enters a blank line at a file name prompt, VIDTEX may optionally supply an appropriate file name. This function is not advisable for certain operations such as "delete a file." If a default name is not supplied, VIDTEX should abort the function. On multi-drive systems, VIDTEX may optionally supply a default disk drive identifier. The file name string will be mapped into the character set normally used by the computer's disk operation system. VIDTEX should provide some means to notify the user in the event of any disk errors. If the operating system provides error message text this text should be displayed to the user. VIDTEX should also display a standard error text identifying that an error has occurred. If VIDTEX is not is autolog mode, the user should be prompted to press return to continue. The standard does not specify what action should be taken if VIDTEX is in autolog mode. 5.8 FUNCTION KEYS VIDTEX will provide function keys, each of which can be defined as any arbitrary text string the user chooses. The minimum implementation will include ten function keys, typically Meta-0 through Meta-9. In application, the function keys are useful for frequently typed commands. 5.8.1 Executing A Function Key The execution of a function should provide the user with convenience. To execute a defined function key, the user should need only to press a dedicated function key or hold down the Meta key and press the number of the function key. This will start the transmission of the key definition. Typing Meta-A should abort a transmission once it has started. 5.8.2 The Function Key Menu The creation and storage of function key definitions are not frequent operations so these are handled from a menu accessed by typing Meta-F. After typing Meta-F, the user should be presented with a menu. For example: Enter D to display the function key definitions or L to load definitions from disk or S to save definitions to disk Page 5-5 or the key to define (0-9): The user may type Meta-A to return to terminal mode directly. 5.8.3 Defining A Function Key The definition of a function key begins with Meta-F to access the menu. The user should be prompted to press the key they wish to redefine. The user need not press carriage return. VIDTEX first erases the the existing definition. The user may then enter the new definition. The creation routine should accept all printing characters and control codes. The routine need only display those control codes supported by the video driver. Unimplemented codes do not display. If a carriage return is entered into a definition, a line feed will also be displayed. This is done to make the display readable. To end the definition, the user must type another Meta-F, all other meta keys are discarded. The user may clear a function key by selecting it for redefinition and immediately typing a Meta-F. This will cause the old definition to be erased without entering a new definition. The total number of characters for all the function key definitions will not exceed 255. 5.8.4 Displaying The Function Keys To display the current definitions of all the function keys, the user should type a Meta-F and select the display option (D). Each key number will be displayed followed by a colon and the key definition. When the definitions are displayed, a line feed is automatically displayed after a carriage return. This makes viewing multi-line function keys easier. Note that only the carriage return is transmitted when the function key is executed. Once the function keys are displayed, the user can press the number of the key they want to execute (the Meta key should not be required) or they can press "F" to return to the function key menu. 5.8.5 Function Key Disk Operations The load and save function key options allow the user to keep several sets of definitions with different filenames on disk at one time. When VIDTEX is first executed, the function keys will be automatically loaded from a specified file name. Page 5-6 5.8.5.1 Saving The Function Keys To save the function key definitions to disk, the user should type a Meta-F and select the save option (S). VIDTEX will then prompt for a file name. If the file specified already exits on disk, VIDTEX will delete the existing file without notifying the user that it existed. The definitions will then be written to the file specified. A Meta-A at the file name prompt should abort the save option and return to terminal mode. 5.8.5.2 Loading The Function Keys To load the function key definitions from a previously saved file, the user should type a Meta-F and select the load option (L). VIDTEX will then prompt for a file name. The existing definitions will be cleared and replaced by those from the file. Typing a Meta-A at the file name prompt should abort the load option. VIDTEX automatically loads the definitions from a specified file name when it is first executed. 5.9 ABORTING A META FUNCTION Most meta key operations should be aborted using Meta-A. Meta-Abort during window creation will set the window to the full screen. Meta-Abort will terminate any function key or RAM buffer transmission. To abort the creation of a new auto-logon file, type Meta-A at the file name prompt. Once the file name is entered, the Autolog file creation cannot be aborted. 5.10 EXITING VIDTEX Meta-X will exit VIDTEX. To prevent an accidental exit, VIDTEX may optionally display a message and request the user to verify the exit request. To continue the terminal session, the user must reload and execute VIDTEX. As an optional feature, VIDTEX will automatically load and execute a program (written in the native language of the computer) if certain conditions are met at time of exit. A typical implementation requries three components, all located one after another in memory. First two key letters such as "EX" must be present. Next in memory will be the length of the file name to search for. The length will be range checked for validity. Finally the file name itself will be stored ascending in memory. All of this information has to be present at the time of exiting from of VIDTEX if auto load and execute on exit is to work. CHAPTER 6 THE RAM BUFFER VIDTEX will allow the user to save a copy of all characters received in the unused portion of RAM (the RAM buffer). This is also known as data-capturing since the received data is saved instead of being discarded as soon as it is received. The RAM buffer allows the user to capture text from the host and save it for future reference. 6.1 DATA CAPTURE When VIDTEX is first run the RAM buffer is empty and closed. To open the RAM buffer and start saving the data, the user types a Meta-O. An informative message should be displayed. All subsequent received characters will be added to the RAM buffer. The RAM buffer is closed by typing a Meta-C. Again the user should be informed. the RAM buffer may be opened again to add more to it. The RAM buffer can be zeroed (emptied) by typing a Meta-Z. The message displayed should show if the RAM buffer was empty or if it was emptied by the Meta-Z. If the RAM buffer becomes almost full, a message will be displayed and a control-S transmitted which immediately suspends host output. This gives the user a chance to save the buffer, zero it, and continue. The user must type the control-Q to resume transmission from the host. If the host does not stop transmission or the user types an control-Q without zeroing the buffer, it will automatically be closed. 6.2 SAVING THE SCREEN A copy of the screen can be added to the RAM buffer by typing a Meta-G (for get screen). This function is similar to the screen print function. Each line is copied into the RAM buffer up to the last non-blank character on the line. After the last character on a line, a Carriage Return/Line Feed is added. If a line is entirely blank, only a Line Feed is added. Page 6-2 6.3 VIEWING THE RAM BUFFER The contents of the RAM buffer can be displayed by typing a Meta-D. The display should stop immediately if a control-S is typed. To resume the display, the user types a control-Q. The display can be stopped at the end of a line (after the next line feed character) by typing a control-A. To cancel the display, the user types control-O or control-C. A message indicating that display has been cancelled and a prompt to press carriage return to continue will be displayed. When the display of RAM buffer contents is done, a message indicating end of buffer will be displayed and the user will be prompted to press carriage return to return to terminal mode. The RAM buffer will be printed by typing a Meta-P. The printing of the RAM buffer will be aborted by typing a Meta-A. 6.4 TRANSMITTING THE RAM BUFFER Typing a Meta-V will transmit the RAM buffer continuously. The user will be informed that the transmission has begun. The transmission will stop only after all of the RAM buffer has been transmitted. Flow control (Control-S and Control-Q) from the host is recognized during the transmission. The transmission can be aborted by typing a Meta-A. Typing a Meta-Y will initiate a prompted transmission of the RAM buffer. First VIDTEX will prompt for a prompt character; then a message displaying the prompt character will be displayed, and the RAM buffer will be transmitted one line at a time. After each line has been transmitted (a carriage return has been transmitted), VIDTEX will wait for the prompt character specified to be received. Note that the first line of the RAM buffer is transmitted before prompt seeking begins. The transmission can be aborted by typing a Meta-A. The keyboard remains active during a RAM buffer transmission. The keys typed by the user should be transmitted with highest priority, that is, without regard to prompt seeking or the transmission of a line from the RAM buffer. 6.5 SAVING THE RAM BUFFER TO DISK There are two ways to save the RAM buffer to disk: edited and unedited. The edited save converts the ASCII data in the RAM buffer data to the character set normally used by the computer. An attempt should be made to map as many components of the ASCII and semigraphics 4 character sets into the native character set as the native character set/video driver will allow. The unedited save will save a copy of exactly what was received. If the RAM buffer is empty, a message should be displayed informing the user that the buffer is empty and the save function aborted. Typing a Meta-U will save the RAM buffer to disk unedited. VIDTEX Page 6-3 will first prompt for the filename to save the RAM buffer to. The user may abort the save by typing a Meta-A at the file name prompt. Typing a Meta-S will save an edited version of the RAM buffer to disk. VIDTEX will first prompt for the filename to save the RAM buffer to. The user may abort the save by typing a Meta-A at the file name prompt. The edited save should be used for saving data to disk for processing by another program. 6.6 LOADING THE RAM BUFFER FROM DISK Typing a Meta-L will load the RAM buffer from a disk file. First VIDTEX will prompt for a file name to load from. Meta-A will abort the load function. All data in the file will be added to the current contents of the RAM buffer. If the file is too large to load or the buffer becomes full after the load, an error message will be displayed. If the error message is displayed, the user should be prompted to press RETURN to continue. During a RAM buffer load, text is inserted into the buffer until the buffer is full. CHAPTER 7 AUTOLOG Autolog allows the user to keep logon information for many different systems. It also has the capacity to act in place of the user for a number of applications. 7.1 CREATING A NEW AUTOLOG FILE A new Autolog file will created with the following steps as described from the user's point of view: 1. First type a Meta-I. You will then be prompted for the Autolog file name to write. If you only press carriage return, a default file name will be used. If the file already exists, it will first be deleted. To abort the autolog creation, type a Meta-A at the file name prompt. 2. You will then be asked for a prompt to wait for from the host. If you do not want to wait for a prompt, just press carriage return. Otherwise enter the host's prompt. The prompt sequence is translated to upper case when it is entered. All received characters are translated to upper case for testing against the prompt. The maximum length for a prompt from the host is typically 20 characters. A prompt length of four to five characters or less is recommended. You may press the carriage return or ESCAPE key to terminate the prompt. However, the carriage return or ESCAPE is not included as part of the prompt. 3. You will then be asked for a response to transmit. Enter your response terminated with carriage return or the Escape character. The carriage return will be transmitted with the response. The Escape will transmit no terminator when the response is sent. If you enter just an Escape for a response, an empty response is indicated. The maximum length for a response is typically 64 characters. A response longer than the maximum number of characters per line can be transmitted by entering the response in two or more parts, each less than the maximum characters and entering a null prompt between each part of the response. 4. Repeat the prompt/response sequence as many times as is neccessary Page 7-2 to complete your logon sequence. When you have completed the sequence, enter a null entry at both a prompt and a response. After you have completed the sequence, VIDTEX will return to terminal mode. The prompt and response entries will be accepted as lines of keyboard input (See Keyboard). Note that the file may be optionally encrypted on disk to protect the user's logon information. 7.2 EXECUTING AN AUTOLOG To execute an autolog file, the user will press Meta-J. VIDTEX will then prompt for the Autolog file name to read. Pressing only carriage return will select a default file name. Note that autolog lacks the capability to verify that the file specified is a true autolog file. To abort the initiation of an autolog execution, the user must type a Meta-A at the file name prompt. If the file exists VIDTEX will enter autolog mode. VIDTEX will automatically exit autolog mode when all prompts are found and all responses are sent. The execution of an autolog can be aborted by typing a Meta-A. The keyboard remains active during an autolog execution. This allows the user to type during an autolog execution. The keys typed by the user should be transmitted with highest priority, that is, without regard to prompt seeking or the response if currently being transmitted. 7.3 ADDITIONAL AUTOLOG FEATURES VIDTEX 4.0 Autolog can do more than simply log onto a host system. The prompt seeking function allows VIDTEX to act in the place of the keyboard to provide a response to a host program. Prompts can be any text that the host displays. The response from autolog can be any text, control characters, or a command to VIDTEX to perform most any of the local meta functions. The user can enter a control character into the response by typing an UP ARROW then type the letter of the control key. A meta key command is entered into the response by typing LEFT ARROW then type the letter of the meta key. The user may obtain a delay of one half second by entering Meta-& (Meta-ampersand) into a response. A delay of two seconds is obtained by entering Meta-% (Meta-percent) into a response. If hardware permits carrier detection, VIDTEX should implement Meta-+ (Meta-plus) as a meta key autolog response to delay until the modem indicates that carrier is present (carrier detection). VIDTEX will delay after carrier is present for 2 seconds to assure that carrier is stable. Similarly, a delay until the modem indicates that carrier is lost is obtained by entering Meta-- (Meta-minus) into a response. Meta-&, Meta-%, Meta-+, and Meta-- can only be entered into an autolog Page 7-3 response and are not available from the keyboard or the Menu. A single UP ARROW character is entered into a response by entering two consecutive UP ARROWs. Similarly a single LEFT ARROW character is also entered by two consecutive LEFT ARROWs. 7.4 AUTOLOG FILE CHAINING The execution of a new Autolog file can be started from an already executing autolog file. When the Meta-J is executed from an Autolog file, the current file is closed and the file specified is then executed. The contents of the Autolog file after the "Meta-Jfilename<RETURN>" is ignored. 7.5 AUTOLOG EXAMPLES A sample autolog creation sequence to logon to CompuServe is shown below. Creating New Auto Logon Enter file name: compuserve auto Select the file Prompt: <ESCAPE> Don't wait for prompt, transmit immediately Response: ^C<ESCAPE> (<Up arrow><C>) Transmit a control-C with no carriage return Prompt: ID: Wait for 'USER ID:' Response: 70000,1 Then send '70000,1' Prompt: word: Wait for 'PASSWORD:' Response: SECRET Then send 'SECRET' Prompt: ! Wait until DISPLA prompts for input Response: GO HOM-1 Transmit 'GO HOM-1' Prompt: <ESCAPE> Terminate the input Response: <ESCAPE> sequence by entering no prompt and no response Page 7-4 The following Autolog could be used to get to the CB simulator program from most any other menu on CompuServe. The function key file named "cb keys" must define key number 1 to be 'GO HOM-XX' where "XX" is the page number of CB and key number 2 as the handle you want to use while in CB. HOM-21 is used for illustration only. In this example a left arrow is represented by "-". Creating New Auto Logon Enter file name: cb auto Select the file Prompt: <ESCAPE> Don't wait for prompt Response: <-FLcb keys Load Function Keys from "cb keys" Prompt: <ESCAPE> Don't wait for prompt Response: T Send T for TOP Prompt: ! Wait until top menu is displayed Response: <-1<ESCAPE> Transmit Function Key One Prompt: ? Wait unitl CB prompts for handle Response: <-2<ESCAPE> Transmit Function Key Two Prompt: <ESCAPE> Terminate the input Response: <ESCAPE> sequence by entering no prompt and no response The following shows how the autolog might execute. It is initiated by typing a Meta-J and responding with the the name "cb auto". T CompuServe Page CIS-1 CompuServe Information Service 1 Home Services 2 Business & Financial 3 Personal Computing 4 Services for Professionals 5 User Information 6 Index Enter your selection number, or H for more information. !GO HOM-21 CompuServe Page HOM-21 Request Recorded, One Moment, Please Thank You for Waiting CB Simulator Ver 3(45) What's your handle? (your handle) (Channel) users tuned in Which channel: 1 (1,Susana) Hi, CB'er Page 7-5 The following example shows how the Autolog feature could be used to set the communications parameters to even parity, flow control disabled. See the section "Modifying Communications Characteristics" for details on the Meta-Q function. In this example a left arrow is represented by "<-". Creating New Auto Logon Enter file name: setcom auto Select the file Prompt: <ESCAPE> Don't wait for prompt Response: <-Q<ESCAPE> Select Meta-Q Prompt: <ESCAPE> Don't wait for prompt Response: E<ESCAPE> Set even parity Prompt: <ESCAPE> Don't wait for prompt Response: N<ESCAPE> Set no flow control Prompt: <ESCAPE> Terminate the input Response: <ESCAPE> sequence by entering no prompt and no response The following example also performs the same function and then initiates the Autolog file "login auto". In this example a left arrow is represented by "<-". Creating New Auto Logon Enter file name: setcom auto Select the file Prompt: <ESCAPE> Don't wait for prompt Response: <-QEN Set the communications parameters Prompt: <ESCAPE> Don't wait for prompt Response: <-Jlogin auto Start the Autolog file "login auto" Prompt: <ESCAPE> Terminate the input Response: <ESCAPE> sequence by entering no prompt and no response 7.6 AUTOLOG AUTO START UPON EXECUTION VIDTEX will automatically enter autolog execution if certain conditions are met. A typical implementation requries three components, all located one after another in memory. First two key letters such as "AL" must be present. Next in memory will be the length of the file name to begin the autolog with. The length will be range checked for validity. Finally the file name itself will be stored ascending in memory. All of this information must be present at the execution of VIDTEX before auto start will work. Page 7-6 7.7 MODIFYING COMMUNICATION CHARACTERISTICS Meta-Q allows the user to enable/disable flow control, change the Parity mode, select the Baud Rate (if possible), change the Duplex mode, and other communication parameters such as printer baud rate. Pressing Meta-Q will display the communications menu. The menu should indicate the current state of each feature. The user may then make new selections for each feature. Each time the user makes a new selection, the display should be updated. The user types carriage return to return to terminal mode. The disable flow control feature will disable the recoginition of received flow control characters, but VIDTEX will still transmit flow control to the host. The parity modes available are 1) disabled, 8 bit data, 2) Even, 3) Odd, 4) One, and 5) Zero. This feature only effects the parity of characters typed by the user, or auto transmitted from an autolog response, function key execution, or RAM buffer transmission. In Half Duplex mode, The character is echoed locally by calling the video driver to display the character at the time it is placed in the transmit buffer. As an option, all ESCAPE characters typed to the host will be diplayed as "$" to aid readability. CHAPTER 8 B PROTOCOL: PRIMITIVES 8.1 PURPOSE The CompuServe B Protocol is used to provides an error-free means of exchanging information between a remote terminal or computer and a CompuServe host computer by means of error detection and retransmission. The CompuServe B Protocol will only be used if the remote device responds to an <ESC> sequence with PB in its option list. B Protocol disk transfer will only be used if the interrogate response of the remote device includes the DT option. 8.2 GENERAL TERMINOLOGY 8.2.1 Terminal Mode Terminal mode refers to the videotex terminal processing described in the first part of this document. 8.2.2 Protocol Mode Protocol mode refers to the special processing associated with protocol transmissions and function processing. Protocol mode implies an eight bit data path, disabled keyboard processing, nondisplay of received data, and disabled termimal mode processing. Protocol and terminal modes are mutually exclusive in function. 8.2.3 File Transfer Mode File Transfer mode refers to a special mode within protocol mode which is characterized by an uninterrupted protocol mode session in which the transfer of a file is accomplished. Page 8-2 8.2.4 Host The host refers to the "master" portion of the protocol, the computer running the "master" protocol and its associated telecommunications network. Only the host can initiate a B Protocol session. 8.2.5 Remote The remote refers to the "slave" portion of the protocol and the microcomputer or smart terminal running the "slave" protocol. 8.3 FLOW CONTROL Flow control in protocol mode will regulate the transmissions of the remote only. When an XOFF (<DC3>) is received, the transmission of data must cease immediately. The transmission resumes upon reception of an XON (<DC1>). The remote should never transmit flow control to the host. 8.4 PROTOCOL BUFFER LEVEL TERMINOLOGY 8.4.1 Protocol Block Transmission A block transmission refers to the transmission of a block and the positive acknowledgement that the block was received correctly. The protocol block has several parts. 8.4.2 Block Number Each block transmitted has a block number associated with it. The block number is modulo 10, thus the block number after 9 is 0. The block number verification logic refers to the number of the current block and to the number of the last previously verified block. At program execution, the last block number is set to 0. The current block is therefore 1. Each time a block is verified the terminal emulator should increment the current block number. The host protocol logic must syncronize its block number with the terminal emulator, not vice versa. 8.4.3 Command Field The command field contains an ASCII string which specifies a function to be performed. (See B Protocol Functions.) Page 8-3 8.4.4 Block Contents The content of the protocol block is the data needed to perform the function specified. The data is transmitted "transparently" so as to allow the receiver to distinguish between data and control codes. 8.4.5 Transparency Since some control characters are used by the protocol, control characters within the data are masked. Control characters in the data are transmitted transparently by the sequence <DLE><character+64>. Using this rule a control-A (<SOH>) would be sent as <DLE><A>. This allows all 8 bit data to be transmitted unambiguously. Currently, the only characters that NEED to be transmitted transparently are ETX, DLE, and ENQ. The host may mask any other control characters during transmission, however, and thus the microcomputer must be able to accept the masking of any character. These rules apply to the data only during transmission; the data is converted to the original character immediately upon reception. 8.4.6 Checksum The "checksum" is a value used to detect any errors. At the beginning of every attempt to send a protocol block, the checksum is initialized to zero. Then, for each character in the block starting with the block number and ending with the <ETX>, the following algorithm is applied. The old checksum is rotated left one bit with bit 7 being rotated into bit 0; the new character is added; if carry occurs, one is added to the checksum. The checksum is computed from real data only (that is, after transparency masking has been removed.) The checksum is sent as a transparent character. 8.5 HOST PROTOCOL INITIALIZATION The information required for the host to begin a protocol session consists of verifying that the remote has B Protocol and synchronizing the host internal block number with the remote. The host can determine if the remote has B Protocol by sending an <ESC> in terminal mode. The remote interrogate response must contain "PB" for B Protocol and in addition "DT" for file transfer mode. (See Terminal Escape Processing) The host may at any time during terminal processing transmit an <ENQ> to the remote to obtain a positive acknowledgement which contains the block number of the last block correctly transmitted. Page 8-4 8.6 BLOCK TRANSMISSION The transmission of a protocol block involves four parts: the preparation, the actual sending of the block, and the logic to error-detect and retransmit a bad block, and the logic to recognize the receiver's positive acknowledgement. 8.6.1 Preparation For Transmission The remote will only transmit a protocol block in response to a protocol function request from the host. Generally, the remote will perform the required function before sending the positive acknowledgement of the host protocol block. Because of this arrangement, the actions taken to prepare for buffer reception will still be in effect for buffer transmissions to the host. The remote will begin reception of a protocol buffer when it receives a <DLE>. When the reception of a protocol buffer is intiated by the host, the remote should (1) remember the current UART masking mode (seven or eight bit) and enter eight bit mode; (2) close the capture buffer to prevent the received block from being copied to the Ram Buffer; and (3) disable the keyboard. 8.6.2 Actual Block Transmission The actual transmission of a single protocol buffer involves the following: Page 8-5 8.6.2.1 Components Of A Block The format of the B Protocol block as it is transmitted is: <DLE><blknum+48><command><contents><ETX><checksum> <DLE> in this context indicates the beginning of a Protocol transmission. indicates the start of a B protocol block. <blknum> is the sender's current block number. The receiver should store the received block number for later comparison to its own internal block number. <command> field is an ASCII string which indicates the desired function. <contents> field is the transparent data required by "command". <ETX> marks the end of the block. <checksum> is a value used to detect any errors. The checksum is initialized to zero. The received checksum is transmitted transparently and must match the receiver's internally calculated checksum. 8.6.2.2 User Assurance During long protocol sessions the user may come to believe that the protocol has died. To avoid this situation the remote should diplay a "+" on the user's screen for 32 characters received or transmitted during a file transfer session. 8.6.2.3 Maximum Block Length The maximum block length, from the initial <DLE> to the final checksum, not including transparent characters is 512. If the terminal does not detect an <ETX> within this length, it has been lost due to line noise and the block is bad. 8.6.3 Error Detection And Retransmission The protocol logic will handle the following error conditions: Page 8-6 8.6.3.1 Unidentified Protocol Block The protocol block reception begins with <DLE>. If the next character received is not then the remote will display the character on the screen and exit protocol mode. 8.6.3.2 <NAK> Negative Acknowledge The receiver will send a <NAK> if any of the following situations occur: 1) If the block number is incorrect (that is; the received block number is neither the receiver's current nor last block number) 2) the receiver times out 3) the checksum is incorrect 4) an <ETX> is not received within the maximum block length 5) an <ETX> is received in terminal mode If the remote is in file transfer mode, the value of the last correctly acknowledged block number should be displayed on the screen when a <NAK> is transmitted to the host. The sender will attempt to retransmit a block ten times before aborting its attempts and switching back to non-protocol communication. If the remote is the sender and an <ENQ> is received, the remote will assume failure and retransmit the block. 8.6.3.3 Failure Acknowledge In the event that an error occurred during function processing by the receiver, it responds with a protocol block with a "command" field of <F> (for failure) and the "contents" field containing a single letter error descriptor. The error descriptor can be one of the following: <N> the function is not implemented <C> there is a capacity problem (for example, there are not that many pages, or there is no RAM at that address) <E> an error occurred during processing (for example, disk errors) <A> the user typed a Meta-A to abort the protocol function Once the failure block has been acknowledged by the host, the remote will exit protocol mode and file transfer mode if active and return to terminal mode. Page 8-7 8.6.3.4 Time Outs It is necessary to define some time outs which allow the protocol to continue even if some control sequences get garbled. This allows the protocol to properly recover and continue. After the checksum for a block has been transmitted, the sender initiates a 10 second timer. If some type of acknowledge is not received within that time, the sender transmits an enquire to determine the status of the receiver. The sender will wait ten more seconds before transmitting another enquire. The sender will issue ten enquires before aborting the protocol and returning to non-protocol mode. When a block is being received, the receiver should wait for ten seconds for a character. If one is not received in that time, it should assume that the <ETX> was garbled and transmit a negative acknowledge. 8.6.4 Positive Acknowledgement Once a block has been transmitted and processed without error, the receiver should send a positive acknowledgement to the sender. A special case of error handling occurs when the received block number is not the current block number but the block number of the last block that was correctly processed and the positive acknowledgement was sent. If the positive acknowledgement is grabled, the sender will retransmit the block again. In this case the receiver should discard this duplicate block (since it has already been processed once) and send a positive acknowledgement to the sender. If the sender receives a positive acknowledgement on the last block correctly acknowledged, it will ignore the acknowledgement and await the positive acknowledgement for the current block from the receiver. The normal case is when the received block number matches the receiver's current internal block number. If no other error has occurred, the receiver will proceed to process the block. Depending on the function, the receiver may transmit the positive acknowledgement before or after the processing of the contents of the block. If an error occurs after the the protocol block has been determined to be correct, the error cannot be communications related. The remote should transmit a failure block with a "contents" field that describes the error. Once the positive acknowledgement has been transmitted to verify the correct reception of a protocol block, the receiver will increment its internal current block number. Upon reception of the positive acknowledgement, the sender will increment its internal current Page 8-8 block number. If the sender receives a <DLE> indicating the initiation of reception of a new block, the last block sent is implicitly acknowledged. During the time the remote is awaiting reception of an acknowledgement from the host, any unrecognized characters received will be displayed on the user's screen. 8.6.4.1 <ENQ> Enquire When the remote receives an <ENQ>, it responds with a positive acknowledge of the last block correctly received. If an <ENQ> is received before any block is received, the receiver responds with a logical acknowledge of block 0. If <ENQ> is received during the reception of a block, the remote should abort the reception, send the positive acknowledge of the last block correctly received, and return to terminal mode. The host can also send an <ENQ> without placing the remote in protocol mode. This allows the host to synchronize its internal block number with the remote's internal block number. Since the remote must respond to XOFF, the XOFF received flag should be reset in case data 93 hexadecimal was received. 8.6.4.2 <DLE><blknum+48> Positive Acknowledge When a block has been correctly received, i.e. checksum and block number correct, the receiver acknowledges the block by sending a <DLE><blknum+48>, where "blknum" is the block number. If the checksum is correct but the block number is logically one less than the expected block number, the receiver transmits a positive acknowledge and ignores the block because it has already been processed but the acknowledge must have been garbled. Note that block 9 is logically one less than block 0. Since the remote must respond to XOFF, the XOFF received flag should be reset in case data 93 hexadecimal was received. During file transfer mode, the transmission of a positive acknowledgement will also display the current block number on the screen. Page 8-9 8.6.4.3 <DLE><;> Wait Acknowledge When a block has been correctly received but it may take some time to process the block, the receiver requests the host to wait by sending a <DLE><;>. This tells the sender to wait for ten seconds and then send an enquire. The receiver should then respond to the inquire with another wait acknowledge or a positive acknowledge. During the sender wait period the remote can send any valid protocol response (after function processing is complete). The remote may send multiple <DLE><;>'s one after another to obtain prolonged wait periods between <ENQ>'s. 8.7 EXITING PROTOCOL MODE The remote will exit protocol mode as follows 1) enable the keyboard if not in file transfer mode, 2) restore the status of RAM buffer capture, and 3) restore the data mode (7 or 8 bit) to its pre-protocol status. CHAPTER 9 B PROTOCOL: FUNCTION PROCESSING The functions which presently can be performed with the B Protocol are described below. 9.1 <LSB><MSB> BINARY LOAD Memory is loaded with the data from the "contents" field starting at the location <msb><lsb>. This provides a mechanism for patches and off-line programs to be loaded into the terminal or computer. Address space is limited to 16 bits, data to 8 bits. 9.2 <G><LSB><MSB> EXECUTE MEMORY Control of the processor is transferred to the location <msb><lsb> via a subroutine call. The terminal must not hang up the modem and must continue to function when control is returned via a return from subroutine. The positive acknowledge is sent before control is transferred so the host must allow time for the subroutine to execute before attempting futher B Protocol communications. Address space is restricted to 16 bits. CHAPTER 10 B PROTOCOL: FILE TRANSFER MODE 10.1 INTRODUCTION The B protocol provides a method for transferring files from the Remote computer to the Host and vice-versa. Most any type of file can be transferred directly from disk to disk. Files residing on the Remote computer's disk can optionally be erased or renamed from the Host. The B protocol is normally a noncontinuous protocol since the Remote returns to text mode between each packet. However, during file transfer the Remote is be captive and is not allowed to return to text mode until the transfer is completed. For example, when a file is being transferred from the Remote to the Host, the Remote is continuously sending data and receiving responses. In order to preserve protocol integrity, the Remote must remove itself from all control of the user. The only possible exception is allowing the user to abort a transfer from the keyboard. The Remote should provide an indication to the user that the transfer is proceeding by displaying block numbers and plus signs. 10.2 FILE TRANSFER TYPES There are three types of file transfer: ASCII, binary, and image (machine dependent). The ASCII transfer is used to transfer standard ASCII text. The binary transfer is used to transfer binary data. This could be used to facilitate the transfer of pure data from one microcomputer to another. The image transfer is used to transfer machine specific files (e.g. object code, executable files). 10.2.1 ASCII Transfers The download of an ASCII text file from the Host will produce a text file on disk containing an edited version of the text file in the the Remote's native character set. An ASCII upload to the Host performs the conversion from the native Page 10-2 acharacter set to ASCII. Any graphic characters that do not map to ASCII will be replaced by space on upload. Non-graphic characters that do not map to ASCII will be ignored. 10.2.2 Binary File Transfer A binary upload will transfer the contents of the Remote's disk file to the Host. The contents of disk file will be uploaded exactly as it is on disk. The Host will store the file contents in an arbitrary form for later download. On download, the Host will provide the Remote with the contents of the file just at it was earlier uploaded. If the Remote computer supports file types, the default file type on download will be chosen to be the type most descriptive of binary data. 10.2.3 Image File Transfers Image file transfer will transfer a header containing whatever information is necessary to accurately recreate the file on download and the contents of the Remote file. The header will contain 1) a two byte (16 bit) header length (transmitted Least Signifigant Byte, Most Signifigant Byte) and 2) the machine identification code (See Interrogate Codes) as the next three bytes. Additional bytes in the header (if any) will contain whatever information is necessary for exact reproduction of the file. On upload, the Remote will create the header and transmit it. The contents of the disk file will follow. On download, the Remote will first receive the header. The remote will use the information contained in the header to properly download the disk file. Note that the header length is generalized to 16 bits and that the header may span a protocol buffer. If the machine identification code of the header does not match the machine identification code of the Remote, the Remote will inform the user that the file may not be compatible with their computer and prompt the user to type "Y" for Yes, continue download or "N" for No, abort transfer. If the user continues, the header will be discarded. If the user aborts, the Remote will respond to the host with a Failure Abort block. 10.3 INITIATING A TRANSFER Only the Host can initiate a transfer. When the file transfer initiation block is received, the remote will enter file transfer mode. The transfer initiate block is as follows: Page 10-3 <T><direction><type><file name> and <direction> is or <D> and <type> is <A> or or <C> or The <T> indicates a file transfer mode control command. The <direction> character is either for upload from Remote to Host or <D> for download from Host to Remote. Note that the <T> command has other arguments. The <type> defines the type of the transfer to be performed as follows: <A> ASCII Binary Image The <file name> is the name of the file that the Remote will use to download to or upload from. 10.3.1 <T><D> Download This initiates the transfer of a file from the Host to the Remote computer. If the file already exists on the Remote computer's disk, it responds with an Failure Error block; it must not overwrite an existing file. If there is not enough space on the disk, the Remote will respond with a Capacity Failure block. If an error occurs during download, the Remote will delete any portion of the file that as already been witten out to disk. This will prevent the user from ever mistaking a file fragment for a complete download. 10.3.2 <T> Upload This initiates the transfer of a file from the Remote computer to the Host computer. If the file is not found, the Remote responds with an Failure Error block. 10.4 <N> TRANSFERRING DATA After a transfer has been initiated, the actual data is transmitted. Each block of data has a "command" field of N for Next packet. No relationship exists between a packet of data and a physical or logical record on the Host or the Remote. Several records may be contained in a packet and a record may span several packets. The end of a packet does not signify the end of a record. The remote remains in file transfer mode throughout data transfer. Page 10-4 10.5 <T><C> COMPLETING A TRANSFER When the sender of the file (Host or Remote) detects the end of the file, it sends a block with a "command" of <T><C> for Transfer Close (the file). The receiver closes the file and sends an acknowledgment on the close request. The transfer is then complete and the Remote exits file transfer mode and returns to terminal mode. 10.6 ABORTING A TRANSFER If the Host determines that the transfer can not be completed for any reason (e.g. line too noisy) or the Remote determines that the user wants to abort the transfer, a Failure Abort block may be sent in response to or instead of a data block. If the Remote is sending a file, it closes the file and returns to terminal mode. If the Remote is receiving a file, it closes the file, deletes it, and returns to terminal mode. 10.7 <T><E> ERASE A REMOTE FILE This optional function is used to erase a file on the Remote's disk. The function block is as follows: <T><E><file name>. The command of <T><E> refers to Transfer Erase a file. The "contents" field is the name of the file to be erased. If the file does not exist, is protected, or can not be erased for any other reason, the Remote responds with an Failure Error block. This could be used to upload a file from the Remote and once it has been sucessfully transmitted, erase it. 10.8 <T><R> RENAME This optional function changes the name of a file that exists on the Remote computer's disk. The function block is as follows: <T><R><present><NUL><new> The command is <T><R> for Transfer Rename a remote file. The contents of the block is 1) <present> - the present name of the file, 2) <NUL> - an ASCII null as a delimiter, and 3) <new> - the new name for the file. APPENDIX A CURRENTLY DEFINED OPTION CODES CB - Capture Buffer. <ESC><ESC> O,C,Z,V,Y CC - Cursor control. A, B, C, D, H, J, K, Y, and j CW - Wide character mode. l and m DT - B Protocol Disk Transfer (in addition to PB). GH - High resolution graphics. GH and GN GM - Medium resolution graphics. GM and GN HC - Hard copy. e and f (and <DC2> and <DC4>) SS<lin><col> - Screen Size (<lin> lines by <col> columns). PB - CompuServe B protocol. WC - Window Control. <ESC><ESC><W> XX - Null Option Code. APPENDIX B THE AMERICAN STANDARD CODE FOR INFORMATION INTERCHANGE (ASCII) ________ ASCII Octal Hex Decimal Character Value Value Value NUL 000 00 000 SOH 001 01 001 STX 002 02 002 ETX 003 03 003 EOT 004 04 004 ENQ 005 05 005 ACK 006 06 006 BEL 007 07 007 BS 010 08 008 HT 011 09 009 LF 012 0A 010 VT 013 0B 011 FF 014 0C 012 CR 015 0D 013 SO 016 0E 014 SI 017 0F 015 DLE 020 10 016 DC1 (X-ON) 021 11 017 DC2 (T-ON) 022 12 018 DC3 (X-OFF) 023 13 019 DC4 (T-OFF) 024 14 020 NAK 025 15 021 SYN 026 16 022 ETB 027 17 023 CAN 030 18 024 EM 031 19 025 SUB 032 1A 026 ESC 033 1B 027 FS 034 1C 028 GS 035 1D 029 RS 036 1E 030 US 037 1F 031 ASCII Octal Hex Decimal Character Value Value Value SP 040 20 032 ! 041 21 033 " 042 22 034 # 043 23 035 $ 044 24 036 % 045 25 037 & 046 26 038 ' 047 27 039 ( 050 28 040 ) 051 29 041 * 052 2A 042 + 053 2B 043 , 054 2C 044 - 055 2D 045 . 056 2E 046 / 057 2F 047 0 060 30 048 1 061 31 049 2 062 32 050 3 063 33 051 4 064 34 052 5 065 35 053 6 066 36 054 7 067 37 055 8 070 38 056 9 071 39 057 : 072 3A 058 ; 073 3B 059 < 074 3C 060 = 075 3D 061 > 076 3E 062 ? 077 3F 063 ASCII Octal Hex Decimal Character Value Value Value @ 100 40 064 A 101 41 065 B 102 42 066 C 103 43 067 D 104 44 068 E 105 45 069 F 106 46 070 G 107 47 071 H 110 48 072 I 111 49 073 J 112 4A 074 K 113 4B 075 L 114 4C 076 M 115 4D 077 N 116 4E 078 O 117 4F 079 P 120 50 080 Q 121 51 081 R 122 52 082 S 123 53 083 T 124 54 084 U 125 55 085 V 126 56 086 W 127 57 087 X 130 58 088 Y 131 59 089 Z 132 5A 090 [ 133 5B 091 \ 134 5C 092 ] 135 5D 093 ^ 136 5E 094 _ 137 5F 095 ASCII Octal Hex Decimal Character Value Value Value ` 140 60 096 a 141 61 097 b 142 62 098 c 143 63 099 d 144 64 100 e 145 65 101 f 146 66 102 g 147 67 103 h 150 68 104 i 151 69 105 j 152 6A 106 k 153 6B 107 l 154 6C 108 m 155 6D 109 n 156 6E 110 o 157 6F 111 p 160 70 112 q 161 71 113 r 162 72 114 s 163 73 115 t 164 74 116 u 165 75 117 v 166 76 118 w 167 77 119 x 170 78 120 y 171 79 121 z 172 7A 122 { 173 7B 123 | 174 7C 124 } 175 7D 125 ~ 176 7E 126 DEL 177 7F 127 APPENDIX C CONTROL CHARACTER DEFINITIONS NUL Null, all zeroes DC1 Device control 1 (X-ON) SOH Start of heading DC2 Device control 2 (T-ON) STX Start of text DC3 Device control 3 (X-OFF) ETX End of text DC4 Device control 4 (T-OFF) EOT End of transmission NAK Negative acknowledge ENQ Enquiry SYN Synchronous idle ACK Acknowledge ETB End of transmission block BEL Bell, Alarm CAN Cancel BS Backspace EM End of medium HT Horizontal tab SUB Substitute LF Line feed ESC Escape VT Vertical tab FS File separator FF Form feed GS Group separator CR Carriage return RS Record separator SO Shift out US Unit separator SI Shift in SP Space DLE Data link escape DEL Delete APPENDIX D ESCAPE SEQUENCE SUMMARY Video Escape Sequences Sequence Effect on Terminal <ESC><A> Move cursor up one line <ESC> Move cursor down one line <ESC><C> Move cursor right one space <ESC><D> Move cursor left one space <ESC><G><mode> Change graphics mode <ESC><H> Move cursor to the top left corner <ESC><K> Clear from cursor to end of line <ESC><J> Clear from cursor to end of screen <ESC><j> Clear page - same as an ASCII form feed <ESC><l> Set normal character width <ESC><m> Set wide character width <ESC><Y><lin><col> Set cursor position Terminal Level Processing <ESC> Interrogate Remote <ESC><e> Disable Display <ESC><f> Enable Display <ESC> Disable Keyboard <ESC><c> Enable Keyboard <ESC><ESC><O> Open Ram Buffer <ESC><ESC><C> Close Ram Buffer <ESC><ESC><Z> Zero Ram Buffer <ESC><ESC><V> Transmit Ram Buffer <ESC><ESC><Y><pmt> Transmit RAM Buffer with prompt <ESC><ESC><W><lin1><col1><lin2><col2> Window Control APPENDIX E B PROTOCOL SUMMARY Block Format: <DLE><blknum+48><command><contents><ETX><checksum> Currently defined commands are: Remote Memory Reference B Load memory G Go execute at an address File Transfer Mode TE<file name> Erase a file TR<present><0><new> Rename a file TU<type><file name> Transfer from Remote to Host TD<type><file name> Transfer from Host to Remote N Next block of data TC Close file <type> is: A - ASCII B - Binary I - Image Failure Blocks FA Failure - Abort FC Failure - capacity problem FE Failure - error during processing of last block FN Failure - function not implemented TABLE OF CONTENTS Introduction . . . . . . . . . . . . . . . . . . . . . . 1-1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Conventions used in this document . . . . . . . . . . . 1-3 User Interface Requirements . . . . . . . . . . . . . . . 2-1 Communications . . . . . . . . . . . . . . . . . . . . 2-1 Keyboard . . . . . . . . . . . . . . . . . . . . . . . 2-1 Minimum Video Display Requirements . . . . . . . . . . 2-2 Video Driver Requirements . . . . . . . . . . . . . . . . 3-1 Terminology . . . . . . . . . . . . . . . . . . . . . . 3-1 Video Initialization . . . . . . . . . . . . . . . . . 3-1 Text Mode Processing . . . . . . . . . . . . . . . . . 3-2 Cursor Display . . . . . . . . . . . . . . . . . . . 3-2 Text Display . . . . . . . . . . . . . . . . . . . . 3-2 Scrolling . . . . . . . . . . . . . . . . . . . . . . 3-2 ASCII Control Codes . . . . . . . . . . . . . . . . . 3-2 <BEL> - Bell . . . . . . . . . . . . . . . . . . . 3-2 <BS> - Backspace . . . . . . . . . . . . . . . . . 3-2 <HT> - Horizontal Tab . . . . . . . . . . . . . . . 3-3 <LF> - Line Feed . . . . . . . . . . . . . . . . . 3-3 <FF> - Form Feed . . . . . . . . . . . . . . . . . 3-3 <CR> - Carriage Return . . . . . . . . . . . . . . 3-3 Unimplemented Control Codes . . . . . . . . . . . . 3-3 Word Cleaning . . . . . . . . . . . . . . . . . . . . 3-3 Video Escape Sequences . . . . . . . . . . . . . . . . 3-4 Video ESCAPE Sequence Summary . . . . . . . . . . . . 3-4 <ESC><A> - Cursor Up . . . . . . . . . . . . . . . . 3-5 <ESC> - Cursor Down . . . . . . . . . . . . . . . 3-5 <ESC><C> - Cursor Right . . . . . . . . . . . . . . . 3-5 <ESC><D> - Cursor Left . . . . . . . . . . . . . . . 3-5 <ESC><H> - Home Cursor . . . . . . . . . . . . . . . 3-6 <ESC><Y><lin><col> - Position Cursor . . . . . . . . 3-6 <ESC><G> - Graphics Mode Control . . . . . . . . . . 3-6 <ESC><G><N> - Normal Mode . . . . . . . . . . . . . 3-6 <ESC><G><H> - High Resolution Graphics . . . . . . 3-6 <ESC><G><M> - Medium Resolution Graphics . . . . . 3-7 <ESC><K> - Clear to End of Line . . . . . . . . . . . 3-7 <ESC><J> - Clear to End of Page . . . . . . . . . . . 3-7 <ESC><j> - Clear Page . . . . . . . . . . . . . . . . 3-7 <ESC><l> - Set Normal Character Width . . . . . . . . 3-7 <ESC><m> - Set Wide Character Width . . . . . . . . . 3-7 Terminal Level Processing . . . . . . . . . . . . . . . . 4-1 Introduction . . . . . . . . . . . . . . . . . . . . . 4-1 Terminal Escape Processing . . . . . . . . . . . . . . 4-1 <ESC> - Interrogate Remote . . . . . . . . . . . . 4-1 Video Enable and Disable . . . . . . . . . . . . . . 4-2 Keyboard Lock and Unlock . . . . . . . . . . . . . . 4-2 <ESC><ESC> - Hardware Specific Escape . . . . . . . . 4-2 Capture Buffer Control . . . . . . . . . . . . . . 4-2 <W><lin1><col1><lin2><col2> - Window Control . . . 4-3 Flow Control . . . . . . . . . . . . . . . . . . . . . 4-3 Printer . . . . . . . . . . . . . . . . . . . . . . . . 4-4 Simple Meta Key Functions . . . . . . . . . . . . . . . . 5-1 Copying Data to the Printer . . . . . . . . . . . . . . 5-1 Screen Print . . . . . . . . . . . . . . . . . . . . . 5-1 The Help Page . . . . . . . . . . . . . . . . . . . . . 5-1 Menu Page . . . . . . . . . . . . . . . . . . . . . . . 5-2 Local Video Control . . . . . . . . . . . . . . . . . . 5-2 Screen Clearing . . . . . . . . . . . . . . . . . . . 5-2 Word Cleaning Control . . . . . . . . . . . . . . . . 5-2 Wide Character Mode Control . . . . . . . . . . . . . 5-2 Text Window Control . . . . . . . . . . . . . . . . . 5-3 VIDTEX 4.0 Disk versus Tape . . . . . . . . . . . . . . 5-3 Input to Disk Operations . . . . . . . . . . . . . . . 5-4 Function Keys . . . . . . . . . . . . . . . . . . . . . 5-4 Executing A Function Key . . . . . . . . . . . . . . 5-4 The Function Key Menu . . . . . . . . . . . . . . . . 5-4 Defining A Function Key . . . . . . . . . . . . . . . 5-5 Displaying The Function Keys . . . . . . . . . . . . 5-5 Function Key Disk Operations . . . . . . . . . . . . 5-5 Saving The Function Keys . . . . . . . . . . . . . 5-6 Loading The Function Keys . . . . . . . . . . . . . 5-6 Aborting a Meta Function . . . . . . . . . . . . . . . 5-6 Exiting VIDTEX . . . . . . . . . . . . . . . . . . . . 5-6 The RAM Buffer . . . . . . . . . . . . . . . . . . . . . 6-1 Data Capture . . . . . . . . . . . . . . . . . . . . . 6-1 Saving the Screen . . . . . . . . . . . . . . . . . . . 6-1 Viewing the RAM Buffer . . . . . . . . . . . . . . . . 6-2 Transmitting the RAM Buffer . . . . . . . . . . . . . . 6-2 Saving the RAM Buffer to Disk . . . . . . . . . . . . . 6-2 Loading the RAM Buffer from Disk . . . . . . . . . . . 6-3 Autolog . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 Creating a New Autolog File . . . . . . . . . . . . . . 7-1 Executing An Autolog . . . . . . . . . . . . . . . . . 7-2 Additional Autolog Features . . . . . . . . . . . . . . 7-2 Autolog File Chaining . . . . . . . . . . . . . . . . . 7-3 Autolog Examples . . . . . . . . . . . . . . . . . . . 7-3 Autolog Auto Start Upon Execution . . . . . . . . . . . 7-5 Modifying Communication Characteristics . . . . . . . . 7-6 B Protocol: Primitives . . . . . . . . . . . . . . . . . 8-1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . 8-1 General Terminology . . . . . . . . . . . . . . . . . . 8-1 Terminal Mode . . . . . . . . . . . . . . . . . . . . 8-1 Protocol Mode . . . . . . . . . . . . . . . . . . . . 8-1 File Transfer Mode . . . . . . . . . . . . . . . . . 8-1 Host . . . . . . . . . . . . . . . . . . . . . . . . 8-2 Remote . . . . . . . . . . . . . . . . . . . . . . . 8-2 Flow Control . . . . . . . . . . . . . . . . . . . . . 8-2 Protocol Buffer Level Terminology . . . . . . . . . . . 8-2 Protocol Block transmission . . . . . . . . . . . . . 8-2 Block Number . . . . . . . . . . . . . . . . . . . . 8-2 Command Field . . . . . . . . . . . . . . . . . . . . 8-2 Block Contents . . . . . . . . . . . . . . . . . . . 8-3 Transparency . . . . . . . . . . . . . . . . . . . . 8-3 Checksum . . . . . . . . . . . . . . . . . . . . . . 8-3 Host Protocol Initialization . . . . . . . . . . . . . 8-3 Block Transmission . . . . . . . . . . . . . . . . . . 8-4 Preparation for Transmission . . . . . . . . . . . . 8-4 Actual Block Transmission . . . . . . . . . . . . . . 8-4 Components of a Block . . . . . . . . . . . . . . . 8-5 User Assurance . . . . . . . . . . . . . . . . . . 8-5 Maximum Block Length . . . . . . . . . . . . . . . 8-5 Error Detection and Retransmission . . . . . . . . . 8-5 Unidentified Protocol Block . . . . . . . . . . . . 8-6 <NAK> Negative Acknowledge . . . . . . . . . . . . 8-6 Failure Acknowledge . . . . . . . . . . . . . . . . 8-6 Time Outs . . . . . . . . . . . . . . . . . . . . . 8-7 Positive Acknowledgement . . . . . . . . . . . . . . 8-7 <ENQ> Enquire . . . . . . . . . . . . . . . . . . . 8-8 <DLE><blknum+48> Positive Acknowledge . . . . . . . 8-8 <DLE><;> Wait Acknowledge . . . . . . . . . . . . 8-9 Exiting Protocol Mode . . . . . . . . . . . . . . . . . 8-9 B Protocol: Function Processing . . . . . . . . . . . . 9-1 <lsb><msb> Binary Load . . . . . . . . . . . . . . . 9-1 <G><lsb><msb> Execute Memory . . . . . . . . . . . . . 9-1 B Protocol: File Transfer Mode . . . . . . . . . . . . 10-1 Introduction . . . . . . . . . . . . . . . . . . . . . 10-1 File Transfer Types . . . . . . . . . . . . . . . . . 10-1 ASCII Transfers . . . . . . . . . . . . . . . . . . 10-1 Binary File Transfer . . . . . . . . . . . . . . . . 10-2 Image File Transfers . . . . . . . . . . . . . . . . 10-2 Initiating a Transfer . . . . . . . . . . . . . . . . 10-2 <T><D> Download . . . . . . . . . . . . . . . . . . 10-3 <T> Upload . . . . . . . . . . . . . . . . . . . 10-3 <N> Transferring data . . . . . . . . . . . . . . . . 10-3 <T><C> Completing a Transfer . . . . . . . . . . . . 10-4 Aborting a Transfer . . . . . . . . . . . . . . . . . 10-4 <T><E> Erase a Remote File . . . . . . . . . . . . . 10-4 <T><R> Rename . . . . . . . . . . . . . . . . . . . . 10-4 Currently Defined Option Codes . . . . . . . . . . . . . A-1 The American Standard Code for Information Interchange . B-1 Control Character Definitions . . . . . . . . . . . . . . C-1 Escape Sequence Summary . . . . . . . . . . . . . . . . . D-1 B Protocol Summary . . . . . . . . . . . . . . . . . . . E-1