Download TMQ Vol I.iii - tim

Volume I.iii
THE MISOSYS QUARTERLY - WINTER 1987
separate control file.
yours.
The choice is
The problems with too many editors is the
reason that CED uses the standard BASIC
editing commands as a foundation. You can
always use any ASCII editor you choose to
use for EnhComp; however, the S mode is
only usable with CED since both the editor
and the compiler need an interface to
operate under S. That can't be done for
any generic editor unless S was completely
redesigned - which we don't plan to do.
I believe that the statement name "EQV"
stands for "equivalence" and the statement
"IMP" stands for "implication". They are
terms arising in the field of logic,
someiimes addressed as philosophy.
Volume I.iii
done.
Now the EnhComp INPUT handler had code to
turn the cursor ON before calling @KEYIN
and code to turn the cursor OFF after
return from @KEYIN. The LINEINPUT handler
did not. Of course, on the Model III, both
routines worked properly because the INPUT
support code was redundant - the ROM
turned the cursor ON then OFF - and
LINEINPUT did not need the code. I missed
this when I ported the compiler over to
the Model 4. Thus, when you use INPUT, the
handler engages the cursor but LINEINPUT
does not. You can circumvent this problem
by surrounding your LINEINPUTs with a
PRINT CHR$(14); and a PRINT CHR$(15);.
PRINT: with EnhCoinp
Here's a
correction to
last issue's
BC62/FIX. It turns out that there was a
mistype for the BC62/FIX when the file was
made up.
The line which started out
"D29,E5=09 25" should actually read
"D29,E5=09 2F" - the second patched byte
should be a "2F" and not a "25". Since my
original test was off a version manually
patched by FED, I didn't "catch" the
error. THE PATCH CORNER in this issue has
the correct fix.
Here's some scoop on the video cursor
while running a program compiled by
EnhComp. EnhComp was developed by Phil
Oliver for the Model III. I ported it to
the Model 4. A big task when I had to
first learn how the compiler worked so I
could port it. Both the INPUT and
LINEINPUT statement handlers
in the
SUPPORT/DAT library use the machine
provided @KEYIN handler. On the Model III,
this is a ROM routine. On the Model 4,
this is a DOS service call. The Model III
and 4 routines behave similarly except for
their handling of the cursor. The Model
III routine ALWAYS turns the cursor ON as
the first thing it does and ALWAYS turns
the cursor OFF as the last thing it does.
It does this regardless of the state of
the cursor upon entry. Thus, if your
program had the cursor OFF, it would be
turned ON after a @KEYIN call. The Model 4
routine was purposely coded to not touch
the cursor. It could have kept the state,
turned it ON, then restored it to the
entry state upon exit - but that wasn't
MISOSYS Products' Tidbits
- 94 -
(Fm:
Hamilton Gaillard) The following
typical statements are commonly used in
interpretive BASIC but are catastrophic
under
PRO-EnhComp,
producing
unintelligable
error
statements
in
numerous and syntactically correct
statements involving strings (but not in
purely numerics).
10 PRINT"MESSAGE" :PRINT :PRINT
20 PRINT"NESSAGE"
Line 10 must read
10 PRINT "ME S SAGE": PRINT" ":PRINT"
You may wish to include an alert in the
README file. It took me an hour or two to
recognize what
was wrong. The clue
actually came
from experience as my
printer will not accept LPRINT without the
quoted blank.
So far, I've tried only one old program
involving a lot of double-precision
arithmetic. It loads and executes very
rapidly, especially loading as it
eliminates load BASIC, load NYPROG, and
RUN.
Documentation is comprehensive and well
organized, but I wouldn't recommend it for
a rank beginner in BASIC.
MISOSYS Products' Tidbits