ftp.barnyard.co.uk/2015.02.ftp.barnyard.co.uk.tar/ftp.barnyard.co.uk/cpm/walnut-creek-CDROM/BEEHIVE/GAMES/CRAM36.ARC/CRAM.DOC

Text File | 1990-07-21 | 12KB | 331 lines

                        CRAM version 3.6

                   Written for Bondwell 14 by:
                         Robert Johanson
                         ph [phone]
                            08/05/87

  Originally written by Hardin Brothers (80 Micro 2/84:108-124)


GAME OVERVIEW

CRAM is a rather simple game, which inspite of this simplicity is
rather addictive and enjoyable to play.

To Play, use the arrow keys to move the cursor around the screen.
As it moves,  the cursor leaves a trail behind it.  If the cursor
runs into its trail,  or a wall,  the game ends. The score is the
number of pixels successfully filled in. To add a little variety,
there are some other modes of play.  One starts off with a number
of  obstacles which must also be avoided.  The other  dynamically
adds obstacles in random locations as the game progresses  (tough
luck if it happens to be right in the way of the cursor!).

The  game opens with a title screen,  which includes the  current
High  Score  Table (one for each level of  difficulty).  It  also
plays a tune.  If you press <RETURN>, you will be asked to select
the  difficulty level (1 - 9).  The game commenses with the  next
key press.  If, like me, you get sick of having to press <RETURN>
everytime,  you  may bypass that and select the difficulty  level
directly  from the title screen.  Pressing ^C (that's <CTRL>  and
<C> together) will return to CP/M, saving the high scores if they
have  been updated.  Also at the title screen,  you may vary  the
volume  of the sound by use of the UP or DOWN ARROWS.  Just  hold
the arrow down until the desired volume is obtained.  This  sound
level will be remembered for next time.

HIGH SCORES

In the simplest mode, the highest possible score is about 10,800.
I  have personally obtained 7,500,  but have left the high  score
table  blank so as not to discourage the young children (for whom
this game would be more suited!).  When your score is  determined
to  be  higher  than the previous high score for  that  level  of
difficulty,  you will be asked to fill in your name, so that your
feat will be remembered forever.  The name input routine uses the
CP/M  editing that you will all be familiar with (if not,  have a
look  at  the table on page 3-5 of the CP/M 3 User's  Guide  that
came with the Bondwell).  The most useful to remember is that  ^W
recalls any previous input, so you don't have to keep typing your
name when you're running hot!

DISCLAIMER

CRAM.COM  will only run on a BONDWELL 14.  No  responsibility  is
accepted  for any mishap related to the use of this program.  The
program  has the ability to access disk files,  and therefore  if
your copy is corrupted, has the ability to destroy.

If  you  have  a copy of CRC.COM,  run it.  A  result  of  11  21
indicates a valid copy.

HISTORY

Cram first appeared to my knowledge as a simple BASIC program for
the  TRS-80  in 80 Micro 8/82:234-239.  It was written by  Harden
Brothers.  In  that issue,  it was described as being "simple  to
play but hard to master,  in short a real frustrator! Playing one
game of cram is like trying to eat just one potato  chip.  Betcha
can't play just one!!".

As an encore, Harden Brothers used similar game strategies for an
assembly  language tutorial program which he titled CRAM  2.  (80
Micro 2/84:108-124).

As  a  learning exercise,  I decided to adapt the program to  the
Bondwell  14 hardware/software environment.  It turned out to  be
relatively  easy,  as  most ROM calls for the TRS-80 have a  CP/M
equivalent,  or in any event were not difficult to emulate. Also,
both  computers have a memory mapped display,  and so most of the
game logic worked as published.

CRAM version 3.0
     This was the first result.  It had sound for the title page,
and  played at the character level (as did cram 2).  It also  had
some  very  bad points.  As the block graphics character  on  the
Bondwell is 3 pixels high and only 2 pixels wide, the game played
faster  if  you  were  on a vertical run than if you  were  on  a
horizontal run. It also got rather boring to play after a while.

CRAM version 3.1
     This  was  the  first  major  departure  from  the  original
program. It went to pixel level graphics.

Cram version 3.3
     This used a different mode of play - as the game progressed,
random  pixel obstacles were turned on.  This was an  attempt  to
keep  the players on their toes.  It suffered from the problem of
being  jerky - I was using simple arithmetic to scale the  random
numbers,  which  was actually causing a random pause everytime  a
random number was scaled.

Cram version 3.4
     This  got  around  the problems of  3.3  by  generating  yet
another mode of play.  At the beginning of the game,  a number of
pixel obstacles were turned on.  The higher the difficulty level,
the more pixels were turned on. It was when I had this version up
and running that my harshest critic (my dear wife) poked her head
into My Room,  and said: "So where's the high score table". So it
ended up with one of those.

Cram version 3.5
     This was to be the final version. I was starting to get sick
of  this  admittedly trivial game.  I used a much  faster  random
number  generator,  and  instead of scaling  the  result,  simply
discarded any value outside the range of the screen.  It had  the
works  - 3  different  modes of play,  all with  three  different
speeds.  A  highest  score  for each of  these  nine  levels  was
maintained  in  a  separate file.  The program also  developed  a
snigger everytime you crashed.

Cram version 3.6
     As I was intending the program to go onto my computer  users
group BBS,  it bothered me that the program required two files to
be  downloaded for it to work successfully.  I then came up  with
the  idea  of using the first two sectors of the  actual  program
file to store the high scores.  In addition,  some people who had
tried  the  game  were  bothered by the sound,  so  I  added  the
variable  volume.  This is stored in exactly the same way as  the
high  scores,  so whatever level is present when the  program  is
finished  will  be maintained next time the program is  run.  The
volume ranges from completely off to very loud. I remain bothered
by  the fact that the user cannot rename the program file without
either reassembling or patching the new name, but tough!


TECHNICAL ASPECTS

Pixel level graphics
     I  used some of the ideas developed by Wilfred Kazoks  (Your
Computer Feb 86 pp 72-73) for handling the individual pixels, the
major difference being that his routines were in Turbo Pascal and
mine  are in Z80 machine code.  There is also a major  conceptual
difference.  He  viewed the screen as a 2  dimensional  cartesian
plane, with points (x,y). (0,0) was at the top left corner of the
screen,  and  (159,74)  was the bottom right hand corner  of  the
screen.  I  chose  to  view  the screen as  a  contiguous  block,
completely analogous to the way CRAM was able to view the  screen
at  the  character level.  Pixel # 0 was the top  left,  Pixel  #
11,999  was  the bottom right.  For any pixel on the screen  (#n)
(excluding  those  on  the  boundaries),   there  was  a   simple
relationship between adjoining pixels:

                         n-160

                    n-1    n    n+1

                         n+160

The  two methods for pixel numbering can be easily interconverted
using the formulae:

for pixel (x,y), pixel # = x + (y*160)

for pixel # n, x = n MOD 160

               y = INT(n/160)

Using  the pixel #,  it was possible to retain the original logic
of the high level subroutines.

The pixel level subroutines used by CRAM are called MEMPOS, MASK,
RANGE, SET, and POINT, and are based on the  folowing  formulae:

Memory Address of screen character containing pixel # n:

Address = 0F800H + (80 * INT(n/480)) + INT((n MOD 160)/2)

Bit Mask required to deal with a given pixel #n contained in  the
screen character:

If n is even, C = 1. If n is odd, C = 0.

R = 2*((n MOD 480) DIV 160)
  = 0, 2 or 4

Pixel bit = R + C             1 0
          = 0 -> 5   -->      3 2
                              5 4

The bit mask is then generated by setting the pixel bit.
eg:
 Pixel bit       Mask
     1         00000001
     4         00001000

To SET pixel,       newchar = oldchar OR mask

To RESET pixel,     newchar = oldchar XOR mask

(The  subroutine RESET was not required for CRAM,  but is similar
to SET, and shares common code)

If a given pixel is set,
                    (oldchar AND mask) <> 0

If any character to be manipulated is > 080H,  then it must first
be adjusted:
                    oldchar = oldchar XOR 0BFH

Similarly,  if any manipulation produces a character > 01FH, then
it must be adjusted before being stored back in screen memory:

                    newchar = newchar XOR 0BFH



Sound
     When I bought my Bondwell, I envisaged the voice synthesizer
as being a built in speech processor chip, with perhaps a text to
allophone  convertor chip alongside!  It would ideally have  been
set  up as a CP/M physical device to which programs could  direct
text to be spoken.  Of course,  the salesman didn't go out of his
way  to  disillusion  me.

     The  Bondwell  does  not  in fact have a  a  built-in  voice
synthesizer as we were all wrongly informed,  but has a  built-in
digital  to  analogue  converter  which is wired up  to  a  small
amplifier.  With fairly complex software,  this can be driven  to
sound like speech.  It is quite a simple matter to get the output
to  sound  like  various notes.

     The  audio register is located at I/O port 50H.  Any  number
output to this location is latched to the DAC. If you alternately
output  a  high  number and a low number,  the  signal  from  the
amplifier will be a note with a pitch determined by the speed  of
the alternation,  and a volume determined by the magnitude of the
difference between the two numbers.

     The  sound  routine that I have used is almost identical  to
the many sound generating programs published for the TRS-80,  and
suffers from similar disadvantages. It is quite adequate for game
sound effects,  but is definately not Hi-Fi quality.  It produces
clicks every now and then which I assume are the result of sudden
discontinuities. I tried a number of complex strategies to reduce
this,  but none totally eliminated the effect,  so I reverted  to
the  original simple routine.  Also,  if you use the routines  to
play  a  tune,  you will find that the duration of each  note  is
influenced  by  the  pitch.  The  obvious solution  to  all  such
problems is to get a proper games computer (like a Commodore 128)
- but for me, the Bondwell is quite good enough!

     The 'snigger' at the end of each game is the result of using
the contents of the memory-refresh register (effectively a random
number 0-127) as the pitch value.


Screen Flash
     The  flash  routine  depends  on the fact  that  all  screen
characters can be inverted by toggling Bit 7.

     One  problem  with the screen flash is that there is no  way
(that  I  know  of) to coordinate screen memory access  with  the
video blanking period. This results in an annoying flicker as the
screen is being inverted.

































































^[P^[x^A