ORIGINALLY PUBLISHED IN
LIMA NEWSLETTER MARCH 1994
 
    PASCAL WITH THE TI 99  
  by Anders Persson 
 
  Charles Good wrote an article in the
January issue of the Lima newsletter
this year, concerning the p-code card
for the TI 99/4A. When reviewing
software, it's usually impossible to
use it enough to really find out how to
take the best advantage of the program.
That's especially true when the review
concerns something as complex as the
UCSD p-system.  Since I was mentioned
in that article, I couldn't restrain
from adding some of my own comments. 
   
  The idea of the p-system 
   
  Charles asks what's portable with
UCSD Pascal? As things has turned out,
the answer to that question is,
unfortunately, nothing. Due to the
problem with different disk formats,
there has never really been any
portability between different
implementations of UCSD Pascal. It's of
course possible to transmit the source
code via serial ports, with or without
modems, between different computers,
but that's about it. 
  However, there is something that
really is portable with UCSD Pascal.
The original Pascal definition, by
Nicklaus Wirth, is practically useless
for real world interactive programming.
That led to different, more or less
clever extensions to the original.
Some extensions were targeted to
improvement of the language's behavior
in limited memories, while others
improved the ability to program
operating systems in Pascal. 
  Since features introduced with
version IV.0 (the one implemented on
the TI 99) has been an inspiration for
various designers of Pascal compilers,
a lot of Pascal code can be typed in
and executed on the TI.  This is true
also for code neither originally
intended for the UCSD system in
general, nor for the TI in particular.
I have myself transferred a substantial
program (compiled EXE file on the PC is
55 kbytes) from the TI to Turbo Pascal
version 4, with only minor source code
changes. These were mainly related to
the 80 character wide PC screen and
somewhat different file handling
procedures. 
  Since Turbo Pascal is continually
being developed, in order to meet both
new hardware (faster, bigger) and new
operating environments (like Windows),
the difference does of course grow with
time. As Charles pointed out in his
article, there is no current
development of the p-system. 
   
  The TI implementation  
   
  The unique feature of the TI
implementation is the p-code card
itself. One reason for this card was
probably the always apparent fear that,
unless it was made impossible, people
might copy software and execute it on
their 4A's. By making the hardware
p-code card an essential part of the
Pascal system, that was much more
difficult. But an advantage with this
idea is that you get a ROM-disk,
containing the operating system and the
p-code interpreter, without wasting
valuable RAM memory. We must remember
that this was more than ten years ago,
when 64 kbytes of RAM in a
microcomputer was about as much as
anyone had ever heard about. This was
also a time, when running Pascal on a
home computer, resulted in an impressed
"Wow" from all computer friends that
looked at it. 
  Since UCSD Pascal IV.0 wants to do a
lot of things, it depends heavily on
its memory management. There simply
isn't room for everything at the same
time.  This results in a lot of disk
activity when using the system. In the
beginning, that was quite a nuisance,
but since I made a RAM disk for my
computer, that problem isn't so severe
any longer. Adding four 360 kbyte disk
drives (CorComp controller) also makes
the system run better, since all system
software can be on line at the same
time, together with the application
under development. 
  With this system, I've done the major
part of all software development on my
computer. Built in memory management,
the capabilities for structuring your
programs that's inherent in Pascal,
easy assembly interface and the
adaptability of the system are some of
the reasons. I've modified the p-system
to include true pre-emptive
multitasking, full screen turtle
graphics and to take advantage of my
redesigned 80 kbyte RAM console. 
  A disadvantage of the TI
implementation is that it's not
complete. The unit KERNEL, for example,
isn't included on the disks, at least
not with the interface section intact.
That unit is essential for easy system
programming. Another program that's
missing is the Native Code Generator,
which converts p-code programs to the
assembly instructions of the processor
used with the target machine, the 9900
in this case. This utility, when
available, is used to speed execution
of programs at the cost of code size. 
   
  To use the p-system 
   
  To make the system run faster, the
SYSTEM.STARTUP program should copy all
essential system files to a RAM disk,
to begin with. That makes loading the
Filer, a disk manager with features
still difficult to find in later
programs, fast enough. 
  I haven't had the chance to run any
of the never released programs that
Charles obviously has access to, but I
can at least sort one thing out. A
"fixed pitch printer" is one that
prints like a typewriter, while a
"variable pitch printer" is one capable
of proportional spacing in its
printout. Not an obvious feature for
all low cost printers more than ten
years ago. 
  It's not necessary to press "I" to
initialize each time disks are
replaced. The p-system allows you to
refer to disks by name, not by number,
and automatically tracks where a
particular disk is located. If you move
a disk to another drive, the system
will look for it only once, and then
remember where it's inserted. Myself, I
rarely use the drive numbers, but refer
to my disks with their names. Together
with the ability to refer to the system
disk with an asterisk and a prefixed
disk with a dollar sign, you actually
end up typing less than you do with the
DSK# system. 
  It's true that you first have to
format a disk and then Z(ero its
directory before you can use it with
the p-system, but you don't need an
ordinary disk manager to accomplish
that. The DFORMAT utility takes care of
formatting a disk. Unfortunately, the
original DFORMAT program, supplied on
the Utilities disk, can't handle double
sided disks, although it claims it can.
I've developed an alternative, which
handles every disk format supported by
TI and CorComp controllers, including
utilizing the CorComp variable
interlacing feature. That means
creating disks that are speed optimized
for Pascal. 
  The V(olume command displays all
units currently available to the
p-system. Unit 1, CONSOLE, is the
keyboard and computer screen. Number 2
is SYSTERM (SYStem TERMinal), which is
the same thing as CONSOLE, except that
there is no implied echo on the screen
of characters typed on the keyboard.
Good if you want to read a key without
displaying the character, since there
is no equivalence to the CALL KEY
statement in Pascal. Better still is to
use an assembly routine that looks into
the type ahead queue, to see if there
is a new character stored there. 
  Units 7, REMIN (REMote INput), and
8, REMOUT (REMote OUTput), refer to the
same physical port. Usually this is a
serial port. On the TI, that's RS232/1
or RS232/2, dependent on where you have
your printer connected. Setting the
name of the physical port used for
these units, as well as for unit 6,
PRINTER, is done by the MODRS232
program on the Utilities disk. The
source code of this program is
included, together with the suggestion
(in the manual) to use this procedure
when you want to change the
configuration within your own program.
The REMOTE unit is mainly intended for
communication purposes other than
printing. 
  Unit 14, OS, contains the procedures
that actually are the operating system.
Most of these reside in a file called
SYSTEM.PASCAL. From a hardware point of
view, this is the GROM chips on the
p-code card. The ROM chips contains the
PME (P Machine Emulator, that
interprets p-code) and low level I/O
routines. 
   
  Pascal programs 
   
  Charles mentioned in his article that
the p-system editor is an 80 column
editor, using windowing left/right.
That's true, but it's also true for the
entire p-system. All programs executing
under the p-system, has access to an 80
column screen. 
  It's a common misunderstanding that
the eventual structure of a Pascal
program should depend upon the
structure of the language itself.
That's absolutely untrue. It's
perfectly possible to misuse Pascal to
such an extent, that the resulting code
couldn't be understood even by the
original creator. The structure of a
program is always a result of a
structured programmer, not any
particular language. However, Pascal
delivers the tools a structured
programmer may need to accomplish his
task, of writing understandable code.
The main benefit of Pascal is not the
indentations that are allowed (but not
compulsory), but the data structure
concept. Unlike traditional BASIC,
which knows nothing more complex than
the array, Pascal allows a programmer
to declare his own data structures,
containing any mixture of data types
required to handle a specific problem. 
  In conjunction with the separately
compiled unit concept, designed mainly
to facilitate memory management, it's
also possible to declare a package of
procedures and data structures. The
benefit of this construction is, that
these procedures work only with their
intended data structures. That reduces
the risk of hard to find errors,
resulting from the correct procedure
applied to wrong data. Apart from the
fact that the unit is static (new
copies can't be created during
execution), this is similair to the
class concept, found in many more
modern and object oriented languages. 
  Charles states that he has found the
p-code card as useful as the Thermal
Printer, which I understand wasn't used
too much. I fully agree with him in
that there isn't much ready to run
software available. Still I think it's
the p-code card that has motivated the
existence of my 99/4A. But that's only
because of its overall performance as a
development system for complex
software. The p-system gives quite a
lot of useful things, like a library
system for commonly used procedures,
memory management with automatic roll
in and roll out of code segments, easy
assembly language interface, floating
point capability when needed and
integers elsewhere and a lot of
technical information about how it
works. It also gives compatibility with
, if not portability between, Pascal
compilers designed for other computer
systems. 
                         
  Getting technical 
   
  The p-code card is located at CRU
address 1F00. The reason for this is
simply the fact that the p-system never
releases control, once it's got it.  In
order to allow all other cards to
execute their power up routines, the
p-code card was best placed last in the
search chain. What about the CorComp
controller, then? 
  Well, since the disk controller is
allocated CRU address 1100, another
solution was used with the CorComp
controller. That card takes command,
but also takes responsibility for
executing the power up routines of all
other cards. The CorComp card assumes
these cards to behave nicely, i.e.
release control to the caller upon
completition of their tasks. Usually,
the only drawback with this scheme is
that power up routines in GROMs are
never found. These routines are rare,
but do exist, for example in the
Terminal Emulator II module. 
  When confronted with the p-code card,
the usual takeover by the CorComp disk
controller is prevented. The p-code
card never returns from its power up
routine. This explains how the p-code
card appears to take control before the
CorComp disk controller. 
  My solution to the somewhat
egocentric behaviour of the CorComp
controller is new EPROMs. These were
once available on the market. Together
with some other minor modifications,
they put an end to the idea of taking
control of the 99/4A before anything
else. Definitely recommended. 
 
  If anyone are interested in
commenting this article, you are
welcomed. Either in Bits, Bytes &
Pixels, or directly to me: 
   
  Anders Persson 
  Drottninggatan 35 
  S-341 36 LJUNGBY 
  Sweden 
.PL 1