Sphinx.doc v2.6x
		 © 1992, Nicolas Dade. All Rights Reserved
 permission is hereby granted for non-commercial duplication and distribution
		  doc file for the SPHINX: AmigaDOS device
 last revised: May 16th, 1992

		    - - - - - - - - - - - - - - - - - -

Incompatibilities & Strange Differences between SPHINX and CON/NEWCON

SPHINX does not have a RAW mode.

The first SPHINX window opened prints an opening message before anything
else.

The input buffer holds 255 bytes. Most characters take only one byte,
allowing 255 characters/line, not including the final LF, like NEWCON.
However characters C-@,C-A,C-B,C-C and C-D ($00 through $04) take three
bytes to store.

When a SPHINX is shutting down, its window's title is cleared while the
memory used by the text is being freed (before the window itself is closed).
This is in order to give you a visual cue that SPHINX is shutting down.

When the first BELL character ($07) is printed, the bell file is loaded into
memory. Thereafter that data is shared between all the SPHINX windows that
are using the same bell file name (no longer just those that have the same
configuration).
Of course if the file is not found, if none is specified, or if the file is
not understood, the screen is flashed, like NEWCON and CON (DisplayBeep()).
When a BELL is seen in text being drawn to the window, the bell is rung (or
the screen flashed) while the text is being drawn, and the BELL character is
not saved. Thus the BELL character will not show up when you clip text. In
order to ring the bell, a seperate task is created, which is used by all the
SPHINXs. This task is given the same priority as the SPHINX that created it,
which currently would be the first SPHINX set running in the machine.
This allows the BELL to be used as an attention signal at the end of a long
script: put an
 echo "G"
(control-G, of course, not just plain G) (and in fact, RA-L,C-G since C-G
alone will just be interpreted as a command to un-defer the scrolling and
un-stop the output)
where you desire the bell to be rung, when the script reaches that point, the
bell will be rung, making noise, which is better for attention getting
purposes than flashing the screen (if you're, say, doing something in another
room). Of course there are a multitude of other ways of achieving this same
end, but it doesn't hurt to have one more.

When a FF (form feed, $0c) character is written to the window, instead of
clearing the window and putting the cursor in the upper left corner, like
CON/NEWCON, the current line is finished, and an embossed line is drawn
from the end of the current line to the right margin. The line following
the startup message in the first window is an example of this.

When a TAB ($09) is written to the window, the cursor is moved to the right
modulo 8*(write font width) pixels from the left margin. If this is beyond
the right edge, the a new line is started.

When a window is to be opened, but it is not going to fit in the screen, it
is moved and/or shrunk so that that may be opened.

There are some programs that add menus to a CLI window. Some of these
programs do not expect the window to not be handled by console.device, and
may crash. (To be honest I have not found any which do not crash)

The only CSIs (command strings) understood by SPHINX are a window bounds
request (CSI0 q) and those which deal with the color and style of the text
(SGRs: Bold, Italics, UnderLine, Negative, TextColor, BackGroundColor and
Reset). Also the only ESC codes understood by SPHINX are ESC[ as an equivalent
to CSI and ESCc as a RESET. All others are stripped out of the text and
ignored. This had to be done because things that made sense with the
console.device no longer do so with SPHINX (like cursor up or down a line,
etc...). Because of this, programs that use the cursor positioning facilities
of CON/NEWCON to draw complicated text will print the same text with SPHINX,
but on lines that follow each other, so the picture will come out wrong.

The CR (carriage return, $0d) and LF (line feed, $0a) characters are treated
both as "finish current line, and move down one line and to the left margin."
Therefore programs that write (Write()) lines of text that end (or start) with
a CR, which with CON/NEWCON would have drawn over the old text, draw their
text on a new line with SPHINX. This isn't so bad as it seems because SPHINX
saves all these lines, so you can go back and look at them. (for example,
search, diskformat & diskcopy do this)

When a block of text (one Write() or 32K or the tail of the old write buffer,
which ever is smaller) is written to the window and that block would cause the
window to scroll if it were drawn, the window is scrolled first, and then the
visible tail of the block is drawn (CON/NEWCON would draw the text one line at
a time, scrolling as they went). For large writes, this is much faster then
drawing the text and then having it scroll off the window (you can always go
back and look at that text any how) (to see the difference, try this in a
SPHINX CLI and a NEWCON CLI: (if you are using arp, make sure that BCPL is
TRUE by first typing
 set BCPL TRUE
)
 copy longtextfile to *
The NEWCON window will scroll along displaying the file. The SPHINX will jump
along drawing only the tail of each Write() from copy).

Since I save the search string when searching, when you exit searching with
S-DOWN I can restore the input buffer to what it was. NEWCON just leaves it
blank.

When SPHINX receives a keystroke it does not understand it inserts it as if
it were a literal, instead of ignoring it like CON/NEWCON do. This gives you
a cue that SPHINX has not done something internal in response to this key,
but rather just doesn't understand it. This also applies to ascii commands
inside a string returned from a key mapped to a string (mapped by the default
keymap, not SPHINX); the offending command is inserted into the input buffer.

See also below

		    - - - - - - - - - - - - - - - - - -

Bugs & Problems & Things to Watch Out For with SPHINX:

There is a bug somewhere in the scroll gadget code. Sometimes whe cursor ends
up in wild places (imagery only). FIX: if you notice this then resize the
window (iconifying won't do it) (but RA-O will); a resize causes a lot of
things to be recomputed from scratch, including the X,Y coordinates of the
cursor.

SPHINX insists that the font you use fit at least one character per line. if
it does not, SPHINX just draws over the borders of the window. This does not
crash the machine, nor even SPHINX; it is just visually unsettling.

When the write font is drawn in italics, it can cover part of the borders of
the window, and the parts of it that stick out are not scrolled with the
rest, leaving you with little dots on either side of the window. This can
also happen if either font is using kerning (and the kerning value is
non-zero). All of this is harmless; just the imagery is messed up.

		    - - - - - - - - - - - - - - - - - -

Extra for programers and equivalently knowledged users:

SPHINX dynamically allocates and frees memory as it goes along. If you are
trying to tell if a program of yours is using memory by watching a memory
meter, then you must not touch any SPHINX windows, nor cause any text to be
written to them, etc... . SPHINXs do not allocate and free memory except in
response to some external event (they don't wake up without you either
causing some intuition msg or packet, or the timer's reply due to a
WaitForChar packet you sent previously or the FileInserter bringing back
some text...)

SPHINX does not use the console.device except for RawKeyConvert(). Therefore
if you are hacking console.device (why would that marvelous piece of code
need hacking?) you may use SPHINX for a console if you let SPHINX use
RawKeyConvert().

SPHINX understands these packet types:
OpenOld, OpenNew, Update, Read, Write, WaitForChar, Close, DiskInfo. It does
not understand Die.

		    - - - - - - - - - - - - - - - - - -

How to speed SPHINX up:
(approximately in order of greatest difference to least)

things to do to SPHINX:
1) Iconize the window.
2) Scroll backwards so that the cursor is out of sight/disable automatic
   scrolling (SC-S).
3) Reduce the window's size.
4) Enable the half-wd scrolling option and/or the monochrome option.
5) Use the default font (or whatever font is speed up) for the write font (and
   speed that font up using FF, BlitzFont, etc...). (WB1.3 only)
6) Change cursors: underline is fastest, followed by thinline, then thickline,
   then block.

(things to do to the program talking to SPHINX:
1) BUFFER YOUR OUTPUT. Sending it one character at a time is not fast with
   any device. Sending it one line at a time is better. SPHINX likes it even
   more if you send it all in one great block (although note that doing this
   with NEWCON can lead to text scrolling off the window without the user
   being able to stop it; C= recommends 256 bytes at a time in the 2.0
   devices RKM).
)
		    - - - - - - - - - - - - - - - - - -