Bitchin100 DocGarden - User contributions [en]

BASIC Efficiency Tips

2009-06-28T19:56:56Z

Ronw: Regarding "Initialize all variables before you start the main body", added the nuance regarding how to arrange the order in which variables are defined influences speed of interpretation.

(From a Letter in Portable 100, Richard Horowitz):

# All variables should be typed at the beginning of the program. Use DEFINT, DEFSNG, etc. Even string variables should be typed because the "$" used with each such variable takes a byte of storage.
# Use integers wherever possible, especially in counting loops. The time savings is dramatic. Integers are 2 1/2 times faster than the default of double precision.
# Eliminate the variable argument on the NEXT portion of For-Next loops. Here is a real kicker. Besides the savings of one byte of storage for each such occurrence, integers are 60 percent slower, reals are 50 percent slower, and double precision is 80 percent slower when you specify the variable than when you simply specify NEXT.
# Eliminate final quote marks on all literals that appear at the end of lines. A byte is saved for each.
# Use as many multiple statements per line as you can since for each line number eliminated, you have a net savings of four bytes (the five needed for each separate line less the one byte used for each ":").
# Eliminate spaces. Your archival copy should have them for intelligibility, but your running copy will save one byte for each space that is removed.
# Put all initialization code at the end of your program and do a GOTO to a GOSUB. Little used routines at the end make for a dramatic improvement in speed since BASIC must search from the beginning for each line referenced.
# Put all time critical code at the beginning of the program for the same reason.
# Initialize all variables before you start the main body of the code. This creates a stable, linear table of variables that are accessed more rapidly. Moreover, optimize the order in which you define the variables so that the most frequently referenced variable is the first to be defined, the second most frequently referenced variable is the second to be defined, and so on. Thus when the BASIC interpreter encounters a previously defined variable, the time it consumes to find said variable among the linear table of variables will be comensurate with the importance (i.e., frequency of reference) of the variable and consequently BASIC program interpretation time is optimally short.
# Do not use the supposed short-cut of raising a number to the 0.5 power to save time over the SQR routine. Inaccuracies in the 11th and 12th decimal might tend to screw up any further calculations in which you might use the result.
# Assign literals used more than once in a program to a variable. Do this in your initialization code. Almost one byte per characters is saved for each such duplication eliminated.
# Use SPACE$(X) to assign X number of spaces rather than STRING$(X,32).
# Another surprise: use REM instead of "'". This saves two bytes per occurrence. Of course you should remove all REM statements of both types from your running copy.

BASIC Efficiency Tips

2009-06-28T19:41:32Z

Ronw: Corrected "net savings" regarding consolidation by use of multiple statements per line versus the quantity of eliminated lines.

(From a Letter in Portable 100, Richard Horowitz):

# All variables should be typed at the beginning of the program. Use DEFINT, DEFSNG, etc. Even string variables should be typed because the "$" used with each such variable takes a byte of storage.
# Use integers wherever possible, especially in counting loops. The time savings is dramatic. Integers are 2 1/2 times faster than the default of double precision.
# Eliminate the variable argument on the NEXT portion of For-Next loops. Here is a real kicker. Besides the savings of one byte of storage for each such occurrence, integers are 60 percent slower, reals are 50 percent slower, and double precision is 80 percent slower when you specify the variable than when you simply specify NEXT.
# Eliminate final quote marks on all literals that appear at the end of lines. A byte is saved for each.
# Use as many multiple statements per line as you can since for each line number eliminated, you have a net savings of four bytes (the five needed for each separate line less the one byte used for each ":").
# Eliminate spaces. Your archival copy should have them for intelligibility, but your running copy will save one byte for each space that is removed.
# Put all initialization code at the end of your program and do a GOTO to a GOSUB. Little used routines at the end make for a dramatic improvement in speed since BASIC must search from the beginning for each line referenced.
# Put all time critical code at the beginning of the program for the same reason.
# Initialize all variables before you start the main body of the code. This creates a stable, linear table of variables that are accessed more rapidly.
# Do not use the supposed short-cut of raising a number to the 0.5 power to save time over the SQR routine. Inaccuracies in the 11th and 12th decimal might tend to screw up any further calculations in which you might use the result.
# Assign literals used more than once in a program to a variable. Do this in your initialization code. Almost one byte per characters is saved for each such duplication eliminated.
# Use SPACE$(X) to assign X number of spaces rather than STRING$(X,32).
# Another surprise: use REM instead of "'". This saves two bytes per occurrence. Of course you should remove all REM statements of both types from your running copy.

TEENY.EXE MANUAL

2009-03-27T05:50:58Z

Ronw: /* Bonus */ trivial grammatical correction

This manual has five sections. They are in the order that is naturally
occurring for TEENY.EXE usage. The first section answers questions of
where, how, and why with respect to TEENY.EXE invocation.

The next two sections bear on your interaction with TEENY.EXE while it
controls your PC, and how your interactions relate to your current and
future circumstances.

The last two sections are meaningful after TEENY.EXE control of your PC
has ended. Be sure to read the "Bonus" section, lest your PC screen
display fool you into believing that TEENY.EXE still controls your PC.
Both of these last sections cover DeskLink invocations: by TEENY.EXE,
and manually by you.

== TEENY.EXE Placement and Syntax ==

TEENY.EXE is an executable file for a PC. The ideal locale for this
file is C:\ROOT in a fixed disk drive, and A:\ROOT in a floppy
diskette. Place it there now!

The command name is TEENY. The command TEENY /? explains everything,
and the syntax it reveals is especially important. Do the TEENY /?
command now!

<pre>
-------------------------------------------------------------------------------
C:\ROOT> TEENY /?
-------------------------------------------------------------------------------
Purpose: Boot the Tandy laptop Model 100, 102, or 200 with TEENY for later use.
The boot speed applies now, the working speed of TEENY applies later.
Syntax: TEENY [/p] [/BS] [/S] [/IDSR] [/DOS] [pace]
/p is COM port number. Range: 1 to 4. Default: 1.
/BS is boot speed at 9600 Baud, rather than 19200 Baud.
/S sets TEENY to 9600 Baud working speed, rather than 19200 Baud.
/IDSR makes TEENY insensitive to DSR control line (i.e., DSR unused).
/DOS declares Op Sys as DOS in order to have no pace (i.e., override).
pace is useful only if the Op Sys is Windows, rather than DOS. Where
you don't specify pace, the Op Sys is surveyed: for Windows a
medium pace is set, DOS has no pace. The value set by the survey
is reliable in most cases. Low pace values work well, high values
work fast but can fail. Range: 10 to 99. Set by survey: 40.
Examples:
Port 1 Boot at 19200. TEENY set to 19200, DSR is used. If Windows, pace by 40.
TEENY
Port 1 Boot at 9600. TEENY set to 9600, DSR is used. If Windows, pace by 40.
TEENY /BS /S
Port 2 Boot at 9600. TEENY set to 19200, DSR unused. If Windows, pace by 40.
TEENY /2 /BS /IDSR
Port 3 Boot at 19200. TEENY set to 19200, DSR is used. Windows, pace is 25.
TEENY /3 25
Port 4 Boot at 9600. TEENY set to 9600, DSR is used. DOS declared, no pace.
TEENY /4 /BS /S /DOS
C:\ROOT>
-------------------------------------------------------------------------------
</pre>

TEENY boots the laptop. The end result is creation of an incarnation
of laptop command file TEENY.CO within the laptop.

The switches /1, /2, /3, and /4 steer the boot to any of four COM ports
of the PC: COM1, COM2, COM3, or COM4. If you don't explicitly supply
one of these switches, the default is boot to the COM1 port.

There's a /BS switch for boot at 9600 Baud. This is needed for a PC
where its COM port(s) can not operate any higher than 9600 Baud. If
you don't explicitly supply this switch, the default is boot at 19200
Baud. Note: do not confuse this /BS switch with the /S switch.

There's a /S switch for creation of an incarnation of TEENY.CO that
works at 9600 Baud. If you don't explicitly supply this switch, the
default is creation of TEENY.CO that works at 19200 Baud. Where the
Tandy Portable Disk Drive 2 is the slave device, it only operates at
19200 Baud -- do not supply the /S switch. Where the Brother Disk
Drive FB100 is the slave device, it only operates at 9600 Baud --
supply the /S switch. For the other Disk Drives (note #1), you have a
choice: 19200 Baud, or 9600 Baud. Where the cable to the slave device
runs through an area of high electrical noise, select 9600 Baud so you
have some immunity to noise. If you plan to use Disk Drive emulation
by "some PC" (note #2) and its COM port(s) can not operate any higher
than 9600 Baud, then select 9600 Baud.

<blockquote>
Note #1 Prior to the use of TEENY.CO with the Tandy Portable Disk Drive
or the Purple Computing Disk Drive, you must establish its
operational speed so that it matches the working speed of
TEENY.CO. See the "Slave Disk Devices" section of the "TEENY
MANUAL" for detail.
</blockquote>

<blockquote>
Note #2 The PC used for TEENY.EXE is not, necessarily, the "same PC"
which you might subsequently use for Disk Drive emulation. See
"About DeskLink" for Disk Drive emulation and 9600 Baud detail.
</blockquote>

There's a /IDSR switch for creation of an incarnation of TEENY.CO that
is insensitive to the DSR control line (i.e., DSR unused). If you
don't explicitly supply this switch, the default is creation of
TEENY.CO that is sensitive to the DSR control line. Where the cable to
the slave device is an inferior arrangement that has no connection to
DSR at the laptop side (e.g., a PalmOS device with a deficient serial
HotSync cable), you consequently must make TEENY.CO insensitive to the
DSR control line -- supply the /IDSR switch.

There's a /DOS switch that in all cases is not needed but in certain
cases may be desirable to use. If you don't explicitly supply this
switch, the boot operation might proceed in a slow-paced fashion that's
appropriate for a Windows Op Sys despite that fact that the Op Sys
which currently controls the PC is a DOS Op Sys. For example, some
dual-boot arrangements are cases that allow a PC to be controlled by
either a Windows Op Sys or a DOS Op Sys. Also there are cases where
removal of a Windows Op Sys from a PC is incomplete in the sense that
the PC environment still retains traces of the former Windows Op Sys
while the current Op Sys is a DOS Op Sys. In such cases you may, by
supplying the /DOS switch, declare the Op Sys as DOS in order to have
no pace (i.e., fastest possible boot operation) which overrides pacing
that would occur for a Windows Op Sys.

There's a "pace" argument you might need to supply to avoid failure of
the boot. If you don't explicitly supply this argument, the operating
system is surveyed: for Windows the boot is conducted at a medium pace
of 40, for DOS the boot is conducted as quickly as possible without any
pace. If you do supply this argument, there is no survey (i.e.,
Windows is assumed) and the boot is conducted at the pace you specify:
from 10 to 99 characters per second.

Initially you don't know whether to supply a pace argument or not. The
practical approach is to not supply it and see what happens. If the
boot completes, you're done. During the boot, the PC screen shows a
reducing down-count to indicate progress toward completion. Also, a
[Wait] shows during any period of suspension and it disappears whenever
boot progress continues. Should the boot fail, the [Wait] persists and
the down-count hangs (i.e., stops), but no harm occurs. The PC screen
also shows the pace value and explains how to escape from the hung-up
condition at both the PC and at the laptop. If it fails, just use the
TEENY command again with a lower value for the pace.

What lower value of pace should be tried? Nobody can know that. It's
a matter of how Windows "mediates" the COM ports of your PC, and that
depends upon a lot of things -- things that change. But it has nothing
to do with the hardware in your PC. Clock speed of the CPU doesn't
matter. Type of UART at the COM port doesn't matter. And restarting
Windows in so-called "DOS mode" doesn't help because Windows still
mediates the COM ports in that mode. Just guess at a lower value of
pace and try it!

== Primary Objective ==

TEENY.EXE has one primary objective -- creation of an incarnation of
command file TEENY.CO within the Tandy laptop. Once file TEENY.CO is
created, you might not ever need to use TEENY.EXE again! Note that
TEENY.CO has three traits that it "inherits" from TEENY.EXE.

* working speed -- either 9600 Baud or 19200 Baud, based on whether you did or did not supply the /S switch when you invoked TEENY.EXE.
* DSR sensitivity -- either insensitive (i.e., DSR unused/ignored) or sensitive (i.e., DSR used and expected), based on whether you did or did not supply the /IDSR switch when you invoked TEENY.EXE.
* laptop Model type -- either type 10x or type 200, based on the Model of Tandy laptop that TEENY.EXE detected via the COM port of the PC.

TEENY.EXE interacts with you; read and follow the directions that
appear on the PC screen. TEENY.EXE directs you step by step. In some
steps you are directed with terminology that's peculiar to a Tandy
laptop. For example, "At laptop, type an End address and press Enter"
does not precisely tell you what to type, but "End address" is peculiar
to a Tandy laptop in regard to .CO type files. Perhaps you have no
idea about what is an appropriate End address for file TEENY.CO -- the
PC screen gives you some limiting guidance such as "Do not use an End
address higher than 62959" which corresponds to "stuff" TEENY.EXE has
extracted from your Tandy laptop. In other steps you are directed in
precise ways. For example, "At laptop, type ?HIMEM:CALL9643 and press
Enter" does tell you precisely what to do.

== Option ==

After it creates an incarnation of file TEENY.CO, TEENY.EXE then leaves
you an option. Said another way, the primary objective has been
achieved but you have a decision to make now that might matter to you
in the future. The decision is not critical, there is no right or
wrong choice -- just choose! Do you want to:

* conserve memory in the Tandy laptop. The Tandy laptop now is consuming memory that holds BASIC statements, should you purge the statements to recover the memory they consume? NEW recovers the memory.
* be able to re-create TEENY.CO without using TEENY.EXE, a PC, and a null-modem cable. Such stand-alone ability now is held within the Tandy laptop, should you retain it for future use? SAVE"TEENY retains it in the form of a BASIC program file named TEENY.BA.

File TEENY.CO, like any conventional .CO file, is immutable. TEENY.EXE
has cast an incarnation of file TEENY.CO in concrete -- so to speak.
It inherits laptop Model type, working speed, and DSR sensitivity as
traits. It has an End address that you specified. These fit your
circumstance now, but the future may present you with a different
circumstance that requires another incarnation of file TEENY.CO that is
different. Consider the future -- TEENY.EXE leaves you an option for
how to handle a future circumstance: use TEENY.EXE again, or use
TEENY.BA. Using TEENY.EXE, you can select a different working speed
and/or DSR sensitivity and/or specify a different End address. Using
TEENY.BA, you can only specify a different End address.

== Bonus ==

Make no mistake about it, TEENY.EXE finishes! It knows when it is
done, and it ends. When TEENY.EXE ends, it no longer has control of
your PC. It has done its work -- end of story, finito, that's all
folks.

TEENY.EXE has a bonus that is related to DeskLink and it gives you that
bonus if it can. If it is technically possible, TEENY.EXE gives you
the bonus when it finishes. You may get the bonus, you may not get it.
If you do get the bonus then your PC screen shows two listings of
"laptop-type" file names, and directly below these two file name
listings "To exit Desk-Link, press F10." is seen.

The bonus is that TEENY.EXE invokes DeskLink on your behalf just after
TEENY.EXE lists, on the PC screen, laptop-type file names that it finds
within:

* the memory of the Tandy laptop. File names TEENY.CO and TEENY.BA are not in this (first) listing.
* a particular drive and directory of the PC. The particular drive and directory (e.g., C:\ROOT) are indicated above this (second) listing.

If you plan to immediately use TEENY.CO at the Tandy laptop to transfer
laptop files to or from the PC, then this bonus has value to you. With
manual invocation of DeskLink, a "brag screen" is all that appears at
the PC -- it does not list any file names whatsoever. The bonus is
that TEENY.EXE provides two listings of file names and then it invokes
DeskLink in a way that leaves the screen intact.

It is DeskLink that has control of your PC. So don't expect to see any
change in the file name listings at the PC screen while you are using
TEENY.CO to transfer files. TEENY.EXE gave you a bonus, not magic
intervention in a session of DeskLink.

== About DeskLink ==

DeskLink (also known as BOOSTER-LINK) is freeware placed in the public
domain by Club 100. Sessions of DeskLink provide Disk Drive emulation.
DeskLink is useful to Personal Computer (PC) owners who also own a
Tandy laptop or NEC notebook, and have a suitable null-modem cable.
The "Null-modem Cable" section of the "TEENY MANUAL" details what is
suitable for DeskLink. DeskLink freeware is distributed as the PC
command file DESKLINK.COM.

Although your usage of TEENY.EXE might invoke a session of DeskLink,
you must manually invoke it for other sessions. So placement of
DESKLINK.COM and its command line syntax for manual invocation are
necessarily detailed here. Certain desirable aspects of DeskLink that
pertain to its operation as a slave to TEENY.CO, and generally do not
pertain to other masters, are explained in the "Slave Device Nuance"
section of "TEENY.CO MANUAL".

DESKLINK.COM is a command file for a PC. The ideal locale for this
file is C:\ROOT in a fixed disk drive, and A:\ROOT in a floppy
diskette. Place it there now!

The command name is DESKLINK. The command DESKLINK /? explains
everything, and the syntax for its switches has much in common with
the syntax of TEENY.EXE. Do the DESKLINK /? command now!

<pre>
-------------------------------------------------------------------------------
C:\ROOT> DESKLINK /?

DESK-LINK (version 1.05)
(c) 1987, Traveling Software, Inc.

Usage: DESKLINK dir
Function: PC disk emulation of a TANDY Disk Drive via "COM1:" at 19200 baud.
Notation: dir - root directory name (\ROOT used if omitted).
Switches: /2 - to communicate through "COM2:".
/S - to communicate at 9600 baud.

C:\ROOT>
-------------------------------------------------------------------------------
</pre>

DeskLink makes a COM port of a PC respond, to stimulation, in the slave
fashion that a Disk Drive (e.g., Tandy Portable Disk Drive) exhibits.
Although the disk media of a PC differs considerably from the media of
a Disk Drive, stimulations and responses are alike. Thus, DeskLink is
an emulator of a Disk Drive. Thus, the stimulations by a master such
as TEENY.CO evoke operations which involve "laptop type" files and some
file repository within a PC.

There's a "dir" argument so you can specify what directory in the PC
current drive you want to use as the repository of "laptop type" files.
If you don't explicitly supply this argument, the default directory
\ROOT of the current drive is the repository.

There's a /2 switch which steers operation to the COM2 port of the PC.
If you don't explicitly supply this switch, the default is the COM1
port.

There's a /S switch for 9600 Baud operation. This is needed for a PC
where its COM port(s) can not operate any higher than 9600 Baud. Where
the null-modem cable runs through an area of high electrical noise,
supply the /S switch for immunity to noise. If you don't explicitly
supply this switch, the default is 19200 Baud operation.

Extraordinary String Animals

2009-03-02T15:28:05Z

Ronw: Spelling and grammer corrections only.

Ron Wiesen, in response to a question from Wilson Van Alst:

To your first question: the situation of $trings (i.e., where they sit) in
the $tring-space can set the stage for a compelled 'garbage collection' that
takes place, as a neccessary prelude, to a subsequent $tring operation. In
other words, the $tring-space holds existing $trings which are not adjoined
(unused gaps of space are between $trings) and then the BASIC interpreter
encounters some $tring operation. The total volume of unused $tring-space
is sufficient to support the $tring operation. But that total is fragmented
due to the way existing $trings are situated in the $tring-space. This
compels the BASIC interpreter to suspend interpretation, conduct 'garbage
collection' in order to consolidate the unused volume into one contiguous
span, and then continue with interpretation -- performing the $tring
operation.

To your second question: you've overlooked the "extraordinary" $tring
animals. These creatures begin their life born as ordinary $tring animals
(typically 0-length nuls). They then mutate into "extraordinary" $tring
animals of some finite (often substantial) length. What makes these
creatures "extraordinary" $tring animals is that their related $tring
content is ROM-based (not RAM-based in the the $tring-space). Below is an
example of how an "extraordinary" $tring animal is brought into existance.

E%=32676:E$="":
POKE0+VARPTR(E$),25:POKE1+VARPTR(E$),E%MOD256:POKE2+VARPTR(E$),E%\256

E$ was born as an ordinary $tring animal with a LENgth of 0 (nul). In the
ROM-space, address 32676 is the locale of a 25-cell that holds a bunch of
values that are ASCII character codes.

Note that the $tring variable called E$, like any other type of variable,
lives in the variable-space within RAM. In the case of a $tring variable,
the variable-space holds two attributes: LENgth, and Address_of_content.
The function VARPTR, as applied to a $tring variable, returns the locale of
the LENght attribute. So 0+VARPTR(E$) is the locale for LENgth of the
$tring variable called E$. In the variable-space for a $tring variable, the
LENgth attribute is immediately followed by the Address_of_content
attribute. So 1+VARPTR(E$) and 2+VARPTR(E$), respectively, are the Least
significant and the Most significant halves of the locale for
Address_of_content of the $tring variable called E$. Via three POKEs, the
creature called E$ mutates into an "extraordinary" $tring animal.

Sure, go ahead. Do a PRINT E$ statement in order to discover what the
ROM-based content looks like (you can't resist the temptation).

What makes the "extraordinary" $tring animals so extraordinary in contrast
to ordinary $tring animals? Although both of these creatures live in the
variable-space, as do creatures of all variable types, they obtain their
runs of character codes from radically different media. The ordinary $tring
animal "feeds" from RAM media: within a BASIC statement in the case of
"literal" food, or within the $tring-space in the case of changeable food.
The "extraordinary" $tring animal "feeds" from ROM media where all food is
"literal" in the sense that it's cast in stone (i.e., silicon).

To your third question: you've overlooked whether or not the BASIC
interpreter recognizes the difference between an ordinary $tring animal and
an "extraordinary" $tring animal. Offhand, I don't have a concrete answer.
Whenever I have occasion to create "extraordinary" $tring animals, most of
the time they are of very substantial LENgth yet there is no operational
program activity that would amount to exposure to "garbage collection"
events. However, I dimly recall investigating the question a long time ago.
As I recall, I was delighted and surprised to discover that the BASIC
interpreter does recognize the difference between ordinary $tring animals
and "extraordinary" $tring animals such that the potential for, and management of, "garbage collection" events is not impacted by the existence of
"extraordinary" $tring animals. At least that's what I recall. My
recollection likely is accurate given how the BASIC interpreter already
recognizes those ordinary $tring animals that have "literal" food in a BASIC
statement -- to the BASIC interpreter, those creatures perhaps "look the
same as" any existing "extraordinary" $tring animals with respect to
"garbage collection" considerations.

[[Category:Model T Developer Reference]]