Download issue 2.4: Acrobat - tim

Base conversion is very simple in itself but we have (of course) a further problem to
deal with. The computer is quite content to honk along without ever telling us what is
going on. Furthermore, it has no use whatsoever for English. After all we made all that
up in order to get fed (and keep from being a meal). Since most computers do not eat,
they have no use for our language. The need does exist for us to know what our little
inventions are doing, and from time to time, to send this information to other devices
or computers. To do this, a standard (ho, ho, ho) code was established called ASCII.
Like every other standard that I know of in this industry, it isn’t.
The purpose behind ASCII is so that when a byte (in English) is sent to a printer or
another machine, the character sent is understood at the other end. Where this breaks
down is as follows: ASCII only accounts for seven bits out of the eight bits in a byte.
This means that while the values 0 through 127 are more or less accounted for, the
numbers 128 through 255 are up for grabs. In fact, even within a single manufacturers
product line, that manufacturer seldom is sooth (this last for D & D fans) regarding
their purpose. As an example, in a Model III, 128-191 are used for graphics, and 192 to
255 are space compression codes. An "alternate set" can be switched in which wipes out
space compression and gives you the greek alphabet and other assorted junk. (On the Mod
4, reverse video occupies these codes as yet a third alternative.)
This puts an additional conversion sequence into any code because the number "3" when
typed at the keyboard is not represented by the value 0000 0011, but by the value
0011 0011 (ASCII). (Can you guess what must be done to convert it?)
I want you to understand that these conversions are standard in every applications
program written in assembler that obtains input. Therefore, let us establish a series
of subroutines necessary to convert all
this stuff. BASIC handles much of this
automatically (see "&H"),
especially the ASCII conversion. But consider, when the
statement INPUT A is encountered, BASIC already knows that the information coming from
the keyboard will be ASCII decimal numbers only (English - you see), and it rejects any
non-decimal characters. A better appreciation of our problem is seen by the statement
LINEINPUT A$.
Now BASIC merely accepts a character stream until the <ENTER> key is
pressed or 255 characters have been received.
In assembler, all of our keyboard inputs are exactly like that. We have no idea what
characters are coming in, so we must examine every character for its relevance and act
accordingly.
Most of the needed conversion routines can be found in a program which
takes in a number of any of the mentioned bases, and displays the converted results in
all three bases.
Let’s define the program in English:
1. Take in an ASCII binary, decimal, or hexadecimal number.
A. A number with suffix "B" is binary
B. A number with suffix "H" is hex
C. A number with no suffix or suffix "D" is decimal
2. Convert the input from ASCII to binary.
A. ASCII-binary to binary
B. ASCII-decimal to binary
C. ASCII-hex to binary
3. Display the ASCII representations.
A. Binary to ASCII-binary
B. Binary to ASCII-decimal
C. Binary to ASCII-hex
Rather than duplicate this process in BASIC, I will simply include it in the comments.
To make life easy on
us, we will demand suffixes for the declared number. I do NOT
recommend doing things "the easy way", but we must walk before we decathalon.
It can be seen that we need a main line program which takes a number from the keyboard
and whips it to one of three subroutines to get it into binary. We could then write
code which determines which was input and not convert it, but why bother? The results
are calculated so quickly that little (if any) time will be lost. Therefore, we will
simply convert the number through all three "back to ASCII" routines, one of which,
Page 41