Serial ports

The computer must have a serial port, either called that or marked
RS232C (or its slight variant RS423), or V24, which is the official
designator of RS232C used outside the USA, though not often seen on

micros.
The very cheapest micros, like the ZX81, Spectrum, VIC20, do not
have RS232C ports, though add-on boards are available. Some of the
older personal computers, like the Apple or the original Pet, were
also originally sold without serial ports, though standard boards are
available for all of these.
You are probably aware that the RS232C standard has a large number
of variants, and that not all computers (or add-on boards) that claim
to have a RS232C port can actually talk into a modem.
Historically, RS232C/V24 is supposed to cover all aspects of
serial communication, including printers and dumb terminals as well
as computers. The RS232C standard specifies electrical and physical
requirements.

Everything is pumped through a 25-pin D-shaped connector, each pin
of which has some function in some implementation. But in most cases,
nearly all the pins are not used. In practice, only three connections
are essential for computer to modem communication:
Pin 7 signal ground
Pin 2 characters leaving the computer
Pin 3 characters arriving at the computer
The remaining connections are for such purposes as feeding power
to an external device, switching the external advice on or off,
exchanging status and timing signals, monitoring the state of the
line, and so forth. Some computers and their associated firmware
require one or other of these status signals to go 'high' or 'low' in
particular circumstances, or the program hangs. Check your
documentation if you have trouble.
Some RS232C implementations on microcomputers or add-on boards are
there simply to support printers with serial interfaces, but they can
often be modified to talk into modems. The critical two lines are
those serving Pins 2 and 3.
A computer serving a modem needs a cable in which Pin 2 on the
computer is linked to Pin 2 on the modem.
A computer serving a printer, etc, needs a cable in which Pin 3 on
the: computer is linked to Pin 2 on the printer and Pin 3 on the
printer is linked to Pin 2 on the computer.
If two computers are linked together directly, without a modem,
then Pin 2 on computer A must be linked to Pin 3 on computer B and
Pin 3 on computer B linked to Pin 2 on computer A: this arrangement
is sometimes called a 'null modem' or a 'null modem cable'.

There are historic explanations for these arrangements, depending
on who you think is sending and who is receiving--forget about them,
they are confusing. The above three cases are all you need to know
about in practice.
One difficulty that frequently arises with newer or portable
computers is that some manufacturers have abandoned the traditional
25-way D-connector, largely on the grounds of bulk, cost and
redundancy. Some European computer and peripheral companies favour
connectors based on the DIN series (invented in Germany), while
others use D-connectors with fewer pin-outs.
** Page 17
There is no standardisation. Even if you see two physically
similar connectors on two devices, regard them with suspicion. In
each case, you must determine the equivalents of:
Characters leaving computer (Pin 2)
Characters arriving at computer (Pin 3)
Signal ground (Pin 7)
You can usually set the speed of the port from the computer's
operating system and/or from Basic. There is no standard way of doing
this; you must check your handbook and manuals. Most RS232C ports can
handle the following speeds:
75, 110, 300, 600, 1200, 2400, 4800, 9600
and sometimes 50 and 19200 baud as well. These speeds are selectable
in hardware by appropriate wiring of a chip called a baud-rate
generator. Many modern computers let you select speed in hardware by
means of a DIL switch. The higher speeds are used either for driving
printers or for direct computer-to-computer or computer-to-peripheral
connections. The normal maximum speed for transmitting along phone
lines is 1200 baud.
Depending on how your computer has been set up, you may be able to
control the speed from the keyboard--a bit of firmware in the
computer will accept micro-instructions to flip transistor switches
controlling the wiring of the baud-rate generator. Alternatively,
the speeds may be set in pure software, the micro deciding at what
speed to feed information into the serial port.
In most popular micro implementations the RS232C cannot support
split-speed working (different speeds for receive and transmit). If
you set the port up for 1200 baud, it has to be 1200 receive and
transmit. This is a nuisance in Europe, where 75/1200 is in common
use both for viewdata systems and for some on-line services. The
usual way round is to have special terminal emulator software, which
requires the RS232C hardware to operate at 1200 /1200 and then slows
down (usually the micro's transmit path) to 75 baud in software by
means of a timing loop. An alternative method relies on a special
modem, which accepts data from the computer at 1200/1200 and then
Hacker's Handbook
file:///E|/Books/Hackers Handbook.htm (19 of 133) [11/28/2000 5:58:48 AM]
performs the slowing-down to 75 baud in its own internal firmware.
Terminal emulators
We all need a quest in life. Sometimes I think mine is to search
for the perfect software package to make micros talk to the outside
world.
** Page 18
As in all such quests, the goal is occasionally approached but
never reached, if only because the process of the quest causes one to
redefine what one is looking for.
These items of software are sometimes called communications
packages, or asynchronous comms packages, and sometimes terminal
emulators, on the grounds that the software can make the micro appear
to be a variety of different computer terminals. Until recently, most
on-line computer services assumed that they were being examined
through 'dumb' terminals--simply a keyboard and a screen, with no
attendant processing or storage power (except perhaps a printer).
With the arrival of PCs all this is slowly changing, so that the
remote computer has to do no more than provide relatively raw data
and all the formatting and on-screen presentation is done by the
user's own computer. Terminal emulator software is a sort of
half-way house between 'dumb' terminals and PCs with considerable
local processing power.
Given the habit of manufacturers of mainframe and mini- computers
to make their products as incompatible with those of their
competitors as possible (to maximise their profits), many slight
variants on the 'dumb' computer terminal exist--hence the
availability of terminal emulators to provide, in one software
package, a way of mimicking all the popular types.
Basic software to get a computer to talk through its RS232C port,
and to take in data sent to it, is trivial. What the hacker needs is
software that will make his computer assume a number of different
personalities upon command, store data as it is collected, and print
it out.
Two philosophies of presenting such software to the user exist:
first, one which gives the naive user a simple menu which says, in
effect, 'press a key to connect to database' and then performs
everything smoothly, without distracting menus. Such programs need an
'install' procedure, which requires some knowledge, but most
'ordinary' users never see this. Normally, this is a philosophy of
software writing I very much admire: however, as a hacker you will
want the precise opposite. The second approach to terminal emulator
software allows you to re configure your computer as you go on--there
is plenty of on-screen help in the form of menus allowing you to turn
on and off local echo, set parity bits, show non-visible control
codes and so on. In a typical hack, you may have only vague
information about the target computer, and much of the fun is seeing
Hacker's Handbook
file:///E|/Books/Hackers Handbook.htm (20 of 133) [11/28/2000 5:58:48 AM]
how quickly you can work out what the remote computer wants to 'see'
- and how to make your machine respond.
** Page 19
Given the numbers of popular computers on the market, and the
numbers of terminal emulators for each one, it is difficult to make a
series of specific recommendations. What follows there- fore, is a
list of the sort of facilities you should look for:
On-line help You must be able to change the software
characteristics while on-line--no separate 'install' routine. You
should be able to call up 'help' menus instantly, with simple
commands --while holding on to the line.
Text buffer - The received data should be capable of going into the
computer's free memory automatically so that you can view it later
off-line. The size of the buffer will depend on the amount of memory
left after the computer has used up the space required for its
operating system and the terminal software. If the terminal software
includes special graphics, as in Apple Visiterm or some of the ROM
packs used with the BBC, the buffer space may be relatively small.
The software should tell you how much buffer space you have used and
how much is left, at any time. A useful adjunct is an auto-save
facility which, when the buffer becomes full, stops the stream of
text from the host computer and automatically saves the buffer text
to disc. A number of associated software commands should let you turn
on and off the buffer store, clear it or, when off-line, view the
buffer. You should also be able to print the buffer to a 'line'
printer (dot-matrix or daisy wheel or thermal image). Some terminal
emulators even include a simple line editor, so that you can delete
or adjust the buffer before printing. (I use a terminal emulator
which saves text files in a form which can be accessed by my
word-processor and use that before printing out.)
Half/full Duplex (Echo On/Off) - Most remote services use an echoing
protocol: this means that when the user sends a character to the host
computer, the host immediately sends back the same character to the
user's computer, by way of confirmation. What the user sees on his
computer screen, therefore, has been generated, not locally by his
direct action on the keyboard, but remotely by the host computer.
(One effect of this is that there may sometimes be a perceptible
delay between keystroke and display of a letter, particularly if you
are using a packet-switched connection--if the telephone line is
noisy, the display may appear corrupt). This echoing protocol is
known as full duplex, because both the user's computer and the host
are in communication simultaneously.
However, use of full duplex/echo is not universal, and all
terminal emulators allow you to switch on and off the facility. If,
for example, you are talking into a half-duplex system (i.e. no
echo), your screen would appear totally blank. In these
circumstances, it is best if your software reproduces on the screen
your keystrokes.
Hacker's Handbook
However, if you have your computer set for half-duplex and the host
computer is actually operating in full duplex. each letter will
appear twice--once from the keyboard and once, echoing from the host,
ggiiwiinngg tthhiiss ssoorrtt ooff eeffffeecctt. Your terminal
emulator needs to able to toggle between the two states.
Data Format/Parity Setting - In a typical asynchronous protocol, each
character is surrounded by bits to show when it starts, when it ends,
and to signify whether a checksum performed on its binary equivalent
comes out even or odd. The character itself is described, typically,
in 7 bits and the other bits, start, stop and parity, bringing the
number up to 10. (See chapter 2.) However, this is merely one very
common form, and many systems use subtle variants -- the ideal
terminal emulator software will let you try out these variants while
you are still on line. Typical variants should include:
Word length Parity No stop bits
7 Even 2
7 Odd 2
7 Even 1
7 Odd 1
8 None 2
8 None 1
8 Even 1
8 Odd 1
(NB although the ASCII character set is 7 bit, 8 bits are sometimes
transmitted with a ~padding~ bit; machine code instructions for 8-bit
and 16-bit machines obviously need 8-bit transmissions.)
Show Control Characters - This is a software switch to display
characters not normally part of the text that is meant to be read but
which nevertheless are sent by the host computer to carry out display
functions, operate protocols, etc. With the switch on, you will see
line feeds displayed as ^J, a back-space as ^H and so on; see
Appendix IV for the usual equivalents.
Using this device properly you will be able, if you are unable to
get the text stream to display properly on your screen, to work out
what exactly is being sent from the host, and modify your local
software accordingly.
Control-Show is also useful for spotting 'funnies' in passwords and
log-on procedures--a common trick is to include ^H (backspace) in the
middle of a log-on so that part of the full password is overwritten.
(For normal reading of text, you have Control-Show switched off, as
it makes normal reading difficult.)
Macros - This is the US term, now rapidly being adopted in the UK,
Hacker's Handbook
for the preformatting of a log-on procedure, passwords etc. Typical
connecting procedures to US services like The Source, CompuServe, Dow
Jones etc are relatively complicated, compared with using a local
hobbyist bulletin board or calling up Prestel. Typically, the user
must first connect to a packet- switched service like Telenet or
Tymnet (the US commercial equivalents of BT's PSS), specify an
'address' for the host required (a long string of letters and
numbers) and then, when the desired service or 'host' is on line,
enter password(s) to be fully admitted. The password itself may be in
several parts.
The value of the 'macro' is that you can type all this junk in
once and then send off the entire stream any time you wish by means
of a simple command. Most terminal emulators that have this feature
allow you to preformat several such macros.
From the hacker's point of view, the best type of macro facility
is one that can be itself addressed and altered in software:
supposing you have only part of a password: write a little routine
which successively tries all the unknowns; you can then let the
computer attempt penetration automatically. (You'll have to read the
emulator's manual carefully to see if it has software-addressable
macros: the only people who need them are hackers, and, as we have
often observed, very few out-and-out hacker products exist!)
Auto-dial - Some modems contain programmable auto-diallers so that
frequently-called services can be dialled from a single keyboard
command.
Again the advantage to the hacker is obvious--a partly- known
telephone number can be located by writing some simple software
routine to test the variables.
However, not all auto-dial facilities are equally useful. Some
included in US-originated communications software and terminal
emulators are for specific 'smart' modems not available
elsewhere--and there is no way of altering the software to work with
other equipment. In general, each modem that contains an auto-dialler
has its own way of requiring instructions to be sent to it. If an
auto-dialling facility is important to you, check that your software
is configurable to your choice of auto-dial modem.
Another hazard is that certain auto-diallers only operate on the
multi-frequency tones method ('touch-tone') of dialling used in large
parts of the United States and only very slowly being introduced in
other countries. The system widely used in the UK is called 'pulse'
dialling. Touch-tone dialling is much more rapid than pulse dialling,
of course.
Finally, on the subject of US-originated software, some packages
will only accept phone numbers in the standard North American format
of: 3-digit area code, 3-digit local code, 4-digit subscriber code.
In the UK and Europe the phone number formats vary quite
Hacker's Handbook
considerably. Make sure that any auto-dial facility you use actually
operates on your phone system.
Format Screen - Most professional on-line and time-share services
assume an 80-column screen. The 'format screen' option in terminal
emulators may allow you to change the regular text display on your
micro to show 80 characters across by means of a graphics 'fiddle';
alternatively, it may give you a more readable display of the stream
from the host by forcing line feeds at convenient intervals, just
before the stream reaches the right- hand margin of the micro's
'natural' screen width.
Related to this are settings to handle the presentation of the
cursor and to determine cursor movement about the screen-- normally
you won't need to use these facilities, but they may help you when
on-line to some odd-ball, non-standard service. Certain specific
'dumb' terminals like the VT52 (which has become something of a
mainframe industry standard) use special sequences to move the cursor
about the screen--useful when the operator is filling in standard
forms of information.
Other settings within this category may allow you to view
characters on your screen which are not part of the normal character
set. The early Apples, for example, lacked lower case, presenting
everything in capitals (as does the ZX81), so various ingenious
'fixes' were needed to cope. Even quite advanced home computers may
lack some of the full ASCII character set, such oddities as the tilde
~ or backslash \ or curly bracket { }, for example.
Re-assign - keyboard A related problem is that home micro keyboards
may not be able to generate all the required characters the remote
service wishes to see. The normal way to generate an ASCII character
not available from the keyboard is from Basic, by using a Print
CHR$(n) type command. This may not be possible when on-line to a
remote computer, where everything is needed in immediate mode. Hence
the requirement for a software facility to re-assign any little-used
key to send the desired 'missing' feature. Typical requirements are
BREAK~ ESC, RETURN (when part of a string as opposed to being the end
of a command) etc. When re-assigning a series of keys, you must make
sure you don't interfere with the essential functioning of the
terminal emulator.
For example, if you designate the sequence ctrl-S to mean 'send a DC1
character to the host', the chances are you will stop the host from
sending anything to you, because ctrl-S is a common command (sometimes
called XOF) to call for a pause--incidentally, you can end the
pause by hitting ctrl-Q. Appendix IV gives a list of the full ASCII
implementation and the usual 'special' codes as they apply to
computer-to-computer communications.
File Protocols - When computers are sending large files to each
other, a further layer of protocol, beyond that defining individual
letters, is necessary. For example, if your computer is automatically
Hacker's Handbook
saving to disk at regular intervals as the buffer fills up, it is
necessary to be able to tell the host to stop sending for a period,
until the save is complete. On older time-share services, where the
typical terminal is a teletypewriter, the terminal is in constant
danger of being unable mechanically to keep up with the host
computer's output. For this reason, many host computers use one of
two well-known protocols which require the regular exchange of
special control characters for host and user to tell each other all
is well. The two protocols are:
Stop/Start - The receiving computer can at any time send to the host
a Stop (ctrl-S) signal, followed by, when it is ready a Start,
(ctrl-Q).
EOB/ACK - The sending computer divides its file into a blocks (of any
convenient length); after each block is sent, an EOB (End of Block)
character is sent (see ASCII table, Appendix IV). The user's computer
must then respond with a ACK (Acknowledge) character.
These protocols can be used individually, together or not at all.
You may be able to use the 'Show Control Codes' option to check
whether either of the protocols are in use. Alternatively, if you
have hooked on to a service which for no apparent reason, seems to
stop in its tracks, you could try ending an ACK or Start (ctrl-F or
ctrl-S) and see if you can get things moving.
File transmission - All terminal emulators assume you will want to
send, as well as receive, text files. Thus, in addition to the
protocol settings already mentioned, there may be additional ones for
that purpose, e.g. the XMODEM protocol very popular on bulletin
boards. Hackers, of course, usually don't want to place files on
remote computers.....
Specific terminal emulation - Some software has pre-formatted sets of
characteristics to mimic popular commercial 'dumb' terminals. For
example, with a ROM costing under £60 fitted to a BBC micro, you can
obtain almost all of the features of DEC's VT100 terminal, which
until recently was regarded as something of an industry-standard and
costing just under £1000.

Other popular terminals are the VT52 and some Tektronix models, the
latter for graphics display. ANSI have produced a 'standard'
specification.
Baudot characters - The Baudot code, or International Telegraphic
Code No 2, is the 5-bit code used in telex and telegraphy -- and in
many wire-based news services. A few terminal emulators include it as
an option, and it is useful if you are attempting to hack such
services. Most software intended for use on radio link-ups (see
Chapter 10) operates primarily in Baudot, with ASCII as an option.
Viewdata emulation - This gives you the full, or almost full,
graphics and text characters of UK-standard viewdata. Viewdata tv
Hacker's Handbook
sets and adapters use a special character-generator chip and a few,
mostly British-manufactured, micros use that chip also-- the Acorn
Atom was one example. The BBC has a teletext mode which adopts the
same display. But for most micros, viewdata emulation is a matter of
using hi-res graphics to mimic the qualities of the real thing, or to
strip out most of the graphics. Viewdata works on a screen 40
characters by 24 rows, and as some popular home micros have 'native'
displays smaller than that, some considerable fiddling is necessary
to get them to handle viewdata at all.
In some emulators, the option is referred to as Prestel or
Micronet--they are all the same thing. Micronet-type software usually
has additional facilities for fetching down telesoftware programs
(see Chapter 10).
Viewdata emulators must attend not only to the graphics
presentation, but also to split-speed operation: the usual speeds are
1200 receive from host, 75 transmit to host. USA users of such
services may get them via a packet-switched network, in which case
they will receive it either at 1200/1200 full duplex or at 300/300.
Integrated terminal emulators offering both 'ordinary'
asynchronous emulation and viewdata emulation are rare: I have to use
completely different and non-compatible bits of software on my own
home set-up.