Article published in Lima newsletter

[Charles W Good]

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 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

[Charles W Good]

ORIGINALLY PUBLISHED IN LIMA NEWSLETTER APRIL 1993

JOHN PHILLIPS
by Bill Gaskill


I would venture a guess that most people who have owned a TI-99 for
more than a couple of years have run across the name John Phillips
before. He is a near legend in the TI-99/4A cartridge and assembly
language programming community and can claim authorship, co-authorship
or significant involvement in over a dozen cartridge programs produced
for the 99/4A, not to mention numerous articles written about the inner
workings of the 4A's architecture.

Phillips will be 32 years old this year (1993) but he was only 21 when
he was hired by Texas Instruments in 1982 right after graduating from
Illinois State University. He started his career with TI in Dallas
doing COBAL programming for business applications but it took him only
6 months to get a requested transfer to Lubbock where the "real" action
was. John had purchased a 99/4 during his senior year in college and
was already familiar with the Home Computer's architecture and he had
wanted to program video games since purchasing his first cartridge,
which was Munchman. Phillips didn't know TMS9900 assembly language but
it didn't take him long to learn it.

His first project at Lubbock was Moonmine, followed by Hopper, which he
co-authored with Michael Archulata. Hopper was followed by Word Radar,
which he wrote in 2 weeks, for Developmental Learning Materials (DLM),
the firm started by Bill Maxwell and Jerry Chaffin.

After completing Word Radar TI sent Phillips to Japan where he met with
several companies who were being recruited to write software for the
99/4A. Following his return from Japan he became involved in almost
every piece of software that was slated for production or that was
actually produced for the 99/4A. When TI announced the end of the Home
Computer Division Phillips was offered several incentives to stay at TI
but turned them all down because none involved work with the 99/4A.
Instead, he and fellow employee Michael Archuleta went to work for DLM,
which had continued to work on products for the TI-99/4A even though it
was no longer being produced.

In December 1983 John Phillips announced to the TI Community that he
was available to any User Group for seminars, demonstrations and
question and answer sessions related to the TI-99/4A. He would travel
to virtually any location if the User Group would pay round trip
airfare from Dallas, Texas plus lodging? While he could only make
himself available on weekends, it was a pretty generous offer.

Both Phillips and Archuleta eventually left DLM (probably because the
work there dried up too) and started their own firm in February 1984
called Video Magic. Video Magic also came to an end in too short a
time, I suspect because it was becoming painfully obvious that one
could not make a living trying to write software for the 99/4A.

At Texas Instruments Michael Archuleta was responsible for the 99/4A
Technical Hotline and for 99/4A software quality assurance. Phillips
was a third-party software development consultant and programmer in the
education/entertainment section of the Consumer Products Division. Both
men would get together again in 1986 to collaborate on the 4A FLYER
game cartridge that was commissioned by Triton Products. To date, that
is the last time we've heard from the John Phillips/Michael Archulata
team.

Archuleta and Phillips were involved in, or responsible for such TI-99
favorites as:

ANGLER DANGLER - Phillips worked on this project as the debugger of the
final code, but the project never reached completion before the bailout
so Angler Dangler was never officially released. It does exist in GRAM
file format however, so it probably was not too far from being a real
product when someone at TI made the decision to pull the plug. If you
look at the October 23, 1983 IUG price list you will see Angler Dangler
listed as being available.

BEYOND PARSEC - This cartridge, which Bill Moseid's DataBiotics firm
released for the 99/4A during the third quarter of 1988, started life
in early 1984 as one of two game cartridges John Phillips was writing
for CorComp's new CCI-99/64 (aka Phoenix) computer. The other game was
Star Wars. Both efforts came to a screaching halt however, when TI
objected to the use of the Parsec name, and George Lucas' company
apparently objected to the use of the trademarked Star Wars name. The
Star Wars code must have actually been finished at the time though,
because I have the game on disk as a GPL file. It was ultimately
renamed Star Trap and released in cartridge form by Exceltec in 1985
and then by DataBiotics during the third quarter of 1988.

BEYOND SPACE - This is a John Phillips creation that was completed in
May 1984, but not released until the first quarter of 1985 when
Exceltec/Sunware marketed it. It was picked up by Unisource Electronics
for their catalog/encyclopedia but pretty much floundered and then just
disappeared. It has never resurfaced since both Unisource and Sunware
went out of business in 1986.

The game involved two players with each having a ship of equal firing
power. The area in space where the two ships confront each other is
littered with asteroids which may be moved by firing the ship's laser.
The object of the game was to push asteriods into your opponent's space
ship to crush and destroy it. The only review I've ever seen written on
the program claimed that its speed was too fast to play the game very
long, so that may be why it has slipped into oblivion?

BURGERTIME - Phillips provided the final debugging for Burgertime.

D STATION - This John Phillips creation has the distinction of being
the only program ever released by the International 99/4 User Group on
the Romox ECPC cartridge. You may recall that during the fourth quarter
of 1983, Charles LaFara promised "a library" of programs from the IUG
on the Romox ECPC (Edge Connector Programmable Cartridge). D Station
was just the first, but it also turned out to be the last.

When the IUG ECPC library failed Exceltec (aka Sunware) picked up the
program and marketed it for a short time in 1985. Triton finally
introduced D Station in their Fall 1988 catalog along with a brand new
D Station II game, also written by John Phillips.

D STATION II - See D Station.

FACEMAKER - Phillips collaborated with Intersoft's Jerry Spacek on this
project. Spacek you may recall wrote Defend the Cities, which was the
first commercial Mini-Memory assembly language game ever written. In
the Facemaker project Spacek translated Spinnaker's source code to
TMS9900 assembly language and Phillips ported it to cartridge format.

HOPPER - Michael Archuleta and John Phillips co-wrote Hopper, which was
the only cartridge developed entirely on the TI-99/4A Home Computer,
using the Editor/Assembler cartridge for all of the programming. All of
the other TI-99 cartridge software programs were developed on a TI
Mini, not the 99/4 or 4A.

JAWBREAKER II - Phillips converted the original Sierra On-Line source
code to TI-99/4A code.

MINI MEMORY'S LINE-BY-LINE ASSEMBLER - Phillips claims responsibility
for its development, but I am not sure exactly what that means.

MOONMINE - Programmed by John Phillips from a design by Bob Hendren.
You may remember that Hendren was also the project engineer behind
Parsec and the person who recruited Aubree Anderson to do the voice for
the Parsec game.

PETER PAN'S SPACE ODYSSEY - Phillips and Archuleta collaborated on this
program while employed at DLM. It was never officially released but is
available as a GRAM file that can be run from P-Gram, Gramulator or the
GramKracker.

SLYMOIDS - Slymoids was written by James R. Von Ehr II. The cartridge
conversion was accomplished by John Phillips.

STAR TRAP - See Beyond Parsec.

SUPER DEMON ATTACK - Phillips worked on this project, but I have no
information on the specific contributions he made to its completion
other than possible debugging of the final code. I do know that he
actually worked on Demon Attack, not Super Demon Attack, but they are
probably the same project with the actual marketed product just having
a slightly different name.

THE GREAT WORD RACE- John Phillips authored.

TREASURE ISLAND - Phillips provided the final debugging for this game
cartridge, which had apparently become stalled by a bug that no one
could find.

WORD RADAR - John Phillips authored.
.PL 1
U $UUUUUUUUUUUUU $UUUUUUUUUUUUU $UUUUUUUUUUUU

[Paul Urbanus]

I would like to clarify and correct some of the statements made in
the original posting of the below article. To help substantiate my
comments, I will start with a history of my relationship with
the TI 99/4A Home Computer.

I was hired by TI in December of 1979 as a coop student, and spent
six months working for the Home Computer Divison of TI in Lubbock.
During this time, I did such
diverse things as gather statistics on the distribution of data
in the various GROM chips and program an HP test station to verify
that the RF modulators were meeting FCC and TI specifications. In
my spare time, I purchased a surplus IBM terminal keyboard (a really
nice one) and interfaced it to the 99/4. This was the first REAL
keyboard for the 99/4. I even added logic to do auto-repeat and
mapped the IBM cursor keys to function correctly. My coop term
expired, the fun ended, and I went back to school (New Mexico State
University) for a year.

I returned to TI in Lubbock in the summer of 1991 to serve a second
stint as a coop student (and earn some money!). In my absence,
the TI99/4 had undergone puberty and blossomed into the TI99/4A.
In addition to the new keyboard, there was also a new video chip.
The TMS9918 had been replaced by the TMS9918A. At this point several
things were happening, and the confluence thrust me into a rather
unique position at TI.

My first assignment was to perform some
testing of the new video chip and plot a chart of chip operation versus
supply voltage and temperature. While waiting for the temperature
chamber to stabilize during these tests, I was reading the detailed
chip specification and came to a startling discovery - there was a
new graphics mode in this chip which would allow neat new applications.
At the same time, the Editor/Assembler (E/A) cartridge was in the early
stages of alpha (internal) testing. I used the E/A cartridge to play
around with the new graphics mode (Graphics Mode II). One of the first
programs I wrote was a simple line-drawing program which I called "Lines".
This is the same program which was bundled with the Mini Memory module.

After I wrote the Lines program, management moved me from the hardware
to the R&D group and suggested that I collaborate with Jim Dramis on a
new game. I thought this was better than sex (ok, I WAS kinda naive) -
getting paid to write a video game. Just for reference, Jim had written
some of the best TI games available at that point - Car Wars and MunchMan.
We quickly agreed that we wanted to write a space game and we wanted to
have smooth horizontal scrolling to give the illusion of flying over the
surface of a planet. As some of you may know, there is NO hardware support
for scrolling the screen on a pixel basis in the 99/4A video chip. After
lot's of pondering, I hit upon the solution - copy the inner loop of the
scroll code into the fast 16-bit RAM of the 99/4A. Since this code is
responsible for 80% of the execution time of the scroll loop, substantial
speed gains were made by moving the loop to fast RAM. In today's world of
486s and Pentiums, this RAM would be referred to as cache RAM. I then
handed this code off to Jim so he could incorporate it into the game.

The next thing I wanted to do for the game was to come up with some really
neat sound effects. Since the sound chip on the /4A was only capable of
generating square waves, I wanted to use the speech chip. The speech chip
operates by using a model of the human vocal tract, and I reasoned that if
people could make really strange noises, then so could the speech module.
After studying the speech chip specification, I made an important discovery:
the speech chip didn't need new data very often (it sure helps to understand
hardware when writing software). This fact could be combined with one of
the new features in the 99/4A software architecture - the User video interrupt.
The net effect of this combination was that the speech chip could be used
while the game was going on. When I went to the software folks with my
discovery, they told me that "you coun't do that". Only after I showed them
did they believe.

I created the asteroids in Parsec in TI Logo. I wrote a small Logo program to
animate them, and iterated the shapes until they were satisfactory to me.
Then I wrote an assembly program to convert the asteroid bitmap from the
binary TI Logo data file to ASCII data statements for use with the 9900
assembler.

All of the above programming was done on the 99/4A using the Editor/Assembler
package. EVERYTHING I wrote for the 99/4A was written using the Editor/Assembler
cartridge. I liked it much better this way, because I could work at home, and
I could fix the /4A system if it went down, unlike the 990 minicomputers.

As Jim continued to progress with Parsec (we brainstormed on ideas, but he did
most of the game flow implementation), the Mini Memory cartridge was developed.
However, there was no software available to make it do anything useful. So I
suggested that this would be a great tool for letting people experiment with
assembly language without having to have any peripherals other than a cassette
recorder. The Line-by-Line Assembler was a derivative of the code used in a TI
single board computer which had been developed for microprocessor courses at
the university level. This single board computer was called the University
Board (model no. 990/189). When I returned to school after my first coop
session, I had borrowed one of these from TI and it was an excellent learning
tool for me so I assumed that a similar capability on the /4A would also be good.
We were able to get the source code for the assembler from another TI group.
All the I/O routines expected a dumb terminal, and so they had to be converted
for use with the /4A keyboard and screen. I also added a routine to dump the
symbol table. In retrospect, the code could have been a lot cleaner and more
compact, but I can probably say that about any program I write today after I have
finished it. We decided to include the Lines program as an example of how to
program the new video chip, as well as instant gratification for Mini Memory
customers.

My final task was in this coop session was to go out to La Jolla, California and
work with Control Data Corporation and educate and support them in their efforts
to port the Plato series of computer-based courseware to the 99/4A. I spent
about a month out there, and in that time I wrote the graphics and disk I/O
package for the Plato interpreter. A byproduct of this work was an intermediate
tool, DISKO, which was used for debugging the disk I/O package. I understand
this program eventually made it into the public domain. For those of
you familiar with this tool, there is a whimisical menu choice,
"Resign/Go to Black's Beach". Black's Beach is a nude beach in La Jolla :)

I returned to school in the fall of 1992, but only lasted for one semester. At
that time I joined with my Parsec partner, Jim Dramis and the author of
TI Invaders, Garth Dollahite, along with two business types and we formed a
company called SofMachine. Our charter was to author, produce and market
game cartridges for the TI 99/4A. Kind of like the TI version of Activision.
While Sofmachine was in existence, we wrote three games of our own and converted
two games for Atarisoft. The games we wrote during that time were:

Title Author Company
-------- ------------ ------------
Spot-Shot Jim Dramis Sofmachine (ourselves)
Barrage Garth Dollahite Sofmachine (ourselves)
Jumpy Paul Urbanus Sofmachine (ourselves)

Pole Position Dollahite/Urbanus Atarisoft
Jungle Hunt Dramis/Urbanus Atarisoft

Because our business partners were unsuccessfull at securing the required
venture capital funding, combined with TI's exit from the home computer market,
we were unable to manufacture and market our (Sofmachine's) three games.
However, due to a sequence of events beyond our control the Sofmachine games
were pirated and eventually freely exchange around the TI 99/4A community.
A valuable lesson was learned: NEVER trust anyone with your own livelihood.
Lesson number two: Don't believe what a "business" guy tells you just
because they're the business guys and you're the technical guys, ESPECIALLY
if it goes against your gut instincts.

A number of years later, the Sofmachine games were released in a cartridge
form by Databiotics under license by Sofmachine.

All games programmed by Sofmachine used the TI 99/4A as the development
platform, along with the Editor/Assembler cartridge. Two of us programmers
purchased a Myarc 10 MByte hard drive for $1800 EACH! I just sold it about
6 months ago for $100. OUCH!

Wow! I intended for this to be a brief history for the purpose of
lending credence to my following comments on the John Phillips article.
Sorry for the long windedness, but the recollection of these times is
good and I almost couldn't stop typing.

Please see below for my rebuttal to specific points.

Thanks and regards,

Paul Urbanus
the "Urbite" in Parsec
u...@onramp.net

*** Warning - - - Urbite ships attacking! ***

In article <45lruh$c...@charm.magnus.acs.ohio-state.edu>, cg...@magnus.acs.ohio-state.edu (Charles W Good) says:
>
>ORIGINALLY PUBLISHED IN LIMA NEWSLETTER APRIL 1993
>
> JOHN PHILLIPS
> by Bill Gaskill
>
>
> I would venture a guess that most people who have owned a TI-99 for
> more than a couple of years have run across the name John Phillips
> before. He is a near legend in the TI-99/4A cartridge and assembly
> language programming community and can claim authorship, co-authorship
> or significant involvement in over a dozen cartridge programs produced
> for the 99/4A, not to mention numerous articles written about the inner
> workings of the 4A's architecture.

< lot's of stuff snipped from here>

>
> HOPPER - Michael Archuleta and John Phillips co-wrote Hopper, which was
> the only cartridge developed entirely on the TI-99/4A Home Computer,
> using the Editor/Assembler cartridge for all of the programming. All of
> the other TI-99 cartridge software programs were developed on a TI
> Mini, not the 99/4 or 4A.

All of the programs for the Mini Memory cartridge were programmed exclusively
using the 99/4A and Editor/Assembler cartridge. As noted at the beginning of
this article, all 5 of the titles developed by Sofmachine were also programmed
using only the 99/4A. I suspect that many of the third-party games were also
programmed in this manner, but I can't say for sure.

> MINI MEMORY'S LINE-BY-LINE ASSEMBLER - Phillips claims responsibility
> for its development, but I am not sure exactly what that means.

I developed the Line-By-Line Assembler excusively. John Phillips was not
even working in the Home Computer division at that time. And I can't claim
responsibilty for writing all of the code, only for porting it from the
990/189 University Board single board computer. Also, I wrote the Lines
program. I am not aware of ANY contributions which John made to the programs
in the Mini Memory.

> MOONMINE - Programmed by John Phillips from a design by Bob Hendren.
> You may remember that Hendren was also the project engineer behind
> Parsec and the person who recruited Aubree Anderson to do the voice for
> the Parsec game.

Bob Hendren had ABSOLUTELY NOTHING to do with the development of Parsec in
regards to content, playability or technical direction. With respect to
his role in the recruitment of Aubree Anderson, I really don't know about that.
Parsec was strictly a collaboration by Jim Dramis and myself. Parsec was
not directed or defined in any way by management or anyone else. We were
merely instructed to "..get together and see what you can come up with...".
Although we received much input from our coworkers as they played with Parsec
during the development process,
almost all of Parsec was what came from our imaginations. I think I can
speak for Jim when I say we are still pleased with our efforts more than
10 years later. We both hope that everyone who has played Parsec has
enjoyed it as much as we enjoyed both writing AND playing it.

< lot's of stuff snipped from here>