Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/624b.lha/MonopolySrc/README.pp/README

Text File | 1992-03-03 | 9.5 KB | 160 lines

4 January 1992

Back in June 1986 I purchased my Amiga 1000. At that time I also
purchased Commodore's Amiga C--a software package for C language
programmers. The documentation was photo-copied loose pages
inserted into a PeeChee style folder, and an incomprehensible
small manual. Lattice was the software developer, and eventually
offered an upgrade to an early Lattice version, as Commodore
never supported the software.

Way back in the dark ages (1969) I took a programming class at
Duke University, a degree requirement even then for psychologists!
Imagine, a huge building with an air-tight sealed basement,
stuffed with whirring noises and shadow-less nooks. This massive
collection of machinery was less powerful and had less storage
capacity than the Amiga 3000 I am using today! Programmers sat at
large machines which cut holes in cards, these cards held the
program and data. the program. on cards was submitted through an
air-lock drawer to a technician gowned for surgery in white, head
to toe. Hours or days later a printed output would appear
upstairs, available for the programmer's inspection. Typically,
the result was not what the programmer expected, and the whole
process:  punch cards, submit, wait, examine output, was repeated
(and repeated and repeated and repeated and repeated and
repeated and repeated and repeated and repeated and repeated)
until a satisfactory program yielded a satisfactory output (all
output was just typewriter style letters and numbers.) Each
student was allotted just so much processing time per semester,
called time-sharing, and a run-away program could easily
consume most of the time-share owned by the student! The language
used was Algol, supposedly tailor made for scientific use.

Time marched on, progress was made, I transferred to the University
of California at San Diego (UCSD [really in La Jolla]) to complete
my degree. I needed an extra math class for general requirements,
and found that computer programming was under the math department.
I had enjoyed (alright so I'm a masochist) my Algol class, so I
thought that I would try programming again. This was about 1975,
and UCSD had just acquired a revolutionary new tool, the individual
terminal. Fifteen of these units were installed in an old
language lab--no special precautions against dust, temperature nor
humidity were required, though the main processor still was
protected and very massive. Each terminal comprised a keyboard
and a monochrome monitor screen. All fifteen terminals shared a
single tape drive as their only means of storing and loading data.
Now picture this tape drive: a machine the size of a kitchen
refrigerator, with tapes made of paper, about one inch wide and
a few hundred feet long. This was a permanent tape, no changes
could be made--any corrections to program or data required that a
new tape be made! The programming language was Basic and the text
was a comic book style workbook.

After graduation, I drifted into electronics, as the general
manager of La Jolla Electronic (a small group dedicated to
one-of-a-kind electronic proto-typing.) I expected to handle
paperwork and office chores, but found that I needed to
learn the basics from chip logic, circuit diagrams, pc boards,
wirewrapping, debugging hardware, on down to manufacturing. This
was a challenging job, and I had the opportunity to work on a
number of important projects. From my programming classes I
recognised that many of my routine tasks could be handled better
using a computer, but computers cost many tens of thousands of
dollars then (even the cheapest) and those companies advertising
often were fly-by-night developers selling vaporware--as we found
out to our financial distress! We finally managed to acquire a
proto-type computer because we helped develop the man-machine
interface on a device which allowed non-speakers to type in letters
to make very short phrases visible on a wrist-watch type display
(only each letter display was about two inches tall--very small
for those days, the height of miniaturization.)

Nature called, and I chose to spend the next ten years as a hermit,
camping out from Mexico to Canada, high up in the mountains,
coming out to civilization only rarely. You can imagine my
reaction when I first saw a Commodore 64 in 1985--my first contact
with computers since 1975! What a difference a decade made. I had
been living without benefit of electric power for many years, and
suddenly I had to hook up my backwoods cabin to the power company--
I had already purchase a C-64 system, and was eager to start
playing with it. I started writing a computer game in 1985,
working title:  "Generic War Game", language:  Basic, platform:
C-64. The game soon outgrew the 64K memory available, so I started
paying attention to Amiga advertisements. The memory! The colors!
The attraction was too great, I had to have one. Only one problem
was obvious:  what to do with the old C-64? I gave it to my niece
for Christmas, then started saving for my Amiga (I kept
visitation rights until I could get my Amiga together.) In May 1986
I got a good bonus and rushed down to pick up my Amiga, I found
that very little software was available, no games, just Deluxe
Paint (the savior of the Amiga--if it can be saved!) So I bought a
C-128 to play games on as well! The C-128 got a years worth of
heavy use, the niece moved out (C-64 and all) and I gave the C-128
to my nephew. By then software was more available for the Amiga.

I had re-written "Generic War Game" in AmigaBasic, but it soon grew
too big to be easily managed. After talking with many hot-shot
programmers, I chose to learn the C programming language. I bought
"C Primer Plus" by Waite, Prata, & Martin, and Inside the Amiga by
Berry--both published by Sams, as well as the official Kernighan
and Ritchie description "The C Programming Language". I set myself
the task of self-learning C, then chose to produce a Parker
Brothers' Monopoly simulation as my "final exam". The
award-winning game included with this file is that project's
culmination.

I am releasing this archive because I have received
some requests for the code. In going back into my dusty old disk
storage boxes, I had to piece together these files from a few
corrupted disks. Specifically the source files for all IFF
functions were lost. I had changed two files (ilbmr.c and
readpict.c) to support my monopoly screen and window, as opposed to
opening a new screen and window. Other IFF files may have had minor changes
as well. I do have the correct object files for all these
functions and have included them. The other C source code was all
last compiled under Lattice 3.x using link_monopoly to call BLINK and a
"with file" link_mono_with (which may have to be modified to reflect
the directories in which another programmer chooses to keep the
object files.) The picture file monopoly.board may need to be located
someplace assigned to "monopoly.c:". Geltools.c is modified from the
original Rom Kernal Manual example to be program specific. The file "index"
lists which function is in which module, and s.c calls main(). The bob
file was an example from which I worked to get my blitter object routines,
and was included as extra study material--may be needed because the tokens
appear to have corrupt data under 2.0 and SAS.

I remain interested in C programming, and have a commercial game
almost ready for delivery. It is a major rework of "Generic
War Game", comprising a geo-political, socio-economic simulation of
galactic expansion and empire building. My favorite games all lend
some background to the game: "Imperium Galactum", "Reach for the
Stars", and "Empire"; though the original concept is my very old
C-64 Basic code, the game is completely Amiga specific, and has a
business program hidden inside. The working title (copyright 1989)
is "Sphreres of Influence" and it plays on any Amiga with at least
512K of memory, running any operating system from 1.2 through 2.0.

P.S. Just for fun, after writing this note, I tried to compile and link this
set of source code files under SAS C version 5.10b, running the 2.04 OS,
Kickstart 37.176, Workbench 37.67, and using the 2.04 Libraries and Includes.
By turning off all warnings and changing one source file (I have a table of
mainly two digit numbers with two exceptions: zero and nine, to make the table
more readable I used 00 and 09 for my data--worked fine under 3.x, but caused
an error under 5.10b) I was able to successfully compile and link all modules.
I took a short look at main.c and one other module and found some really
glaring mistakes--not functionally, but in succinct succinctness and style.
Remember, this was my first C program, a project that snowballed out of
control! It may actually be of benefit to beginners, just learning the ropes,
because it has no tricky code, nor obtuse variable names, uses no custom
structures, and avoids the use of pointers where possible. Much of the system
interface code is right out of the Rom Kernal Manual (errors fixed up), and
the IFF routines are presented as object modules so that early contact with
the entertaining IFF source code is eliminated (thus better assuring their
use!) For more advance programmers, I simply modified the IFF source code
which opens a custom screen and/or window into which the bitmap data is
written; originally hard coding in my global screen and window variable names,
then in newer projects passing a pointer to my custom structure Destiny. This
may be accomplished with the IFF type defined ILBMdestination appearing in the
newest iff.h file--I hope, but I have not updated my iff routines yet, and
will probably not do so until after completion of "Spheres of Influence".