S P A C E

NEWSLETTER January, 1996

President's Corner

By Mike Fitzpatrick

As you are all aware the weather forced a cancellation of the Christmas Party. Many thanks to:

and others who passed the word along.

Also, we had help from KOOL-108 and WCCO radio in getting the message out over the radio waves.

The plan is to have a party at the January meeting. Please try to bring what you signed up for plus a little bit for yourself. The sheet cake that eve picked up was well received by all our neighbors at our impromptu snow removal party the night of the canceled SPACE meeting.

The method <maximum frustration> of contacting folks was exacerbated by the loss of the BBS, with all the member records, two days prior to the meeting. Hopefully that will never happen again. I do think that a calling plan for a member daisy chain of contacting might be a point to consider.

Here's hoping that you had a great Holiday Season and 1996 will be filled with Health, Happiness, and Prosperity to you all.

There is one item that I'll save for Lance to discuss in January about new developments for the classic Atari 8-bit computer

BBS Report

As you know the BBS went down on the 6th of December. A REALLY horrible event. The problem with the BBS was the hard drive. The older MFM & RLL drives were warranted for 500 hours of service life. Well in six months time 4500 hr's is the norm. This will be an increasingly growing problem as those types of drives are only available as used; true condition unknown. For the technical folks: a post mortem on the drive indicated that the bearing(s) lost the permanent lub. Friction and heat did the rest.

Imbedded SCSI's are available but they tend to be expensive. I would also save that type of drive for the ST where the full potential of the drive can be utilized.

It appears that I was able to save the user dat file so that few if any had to re-log on. There is still a minor problem with the 3rd party f-mail and I plan on working that out with K-Products and Steve Cardin (BBS Express-Pro progammer).

As of this writing the files have not been reloaded but the plan is to do it on Superbowl Sunday when few if any will be bbsing.

Minutes of Space meeting

December 08,1995

It was the night before the Space annual Christmas party and all through the house, nothing was stirring except me. I was busy preparing the big 13-pound turkey for our Christmas party, Friday, December 8, 1995. I put it in the oven to cook over night. In the morning I pulled a delicious looking turkey out of the oven. I then put it in the ice box. In the evening I was going to add it to all the delicious food at the party. You all know the rest, the club party was canceled by MOTHER NATURE. Luckily we have a chance to celebrate a Christmas party at our January 12, 1996 meeting. We can also include celebrating a new year. For all members that signed up to bring something on the Christmas potluck list, please bring food in for the Christmas party in January. Be prepared to have a fun time too!

The midwinter Madness show is rapidly approaching. It will be held on February 10, 1995 at Blaine Sports Center in Blaine. Be sure to bring plenty of money because there will probably be plenty of bargains.

Last of all, because we didn't have a club meeting in December because of MOTHER NATURE, there aren't any minutes to report. See you at the January Space meeting, and be prepared to PARTY HARDY and FEAST LIKE KINGS !

Michael Weist
Club Secretary

SPACE'S 13TH CHRISTMAS
PARTY POTLUCK SIGN-UP LIST

PERSON          POTLUCK ITEM

Terry Streeter        chicken salad
Millie Fitzpatrick    cake 
Greg Leinter          meat tray
J. Overbaugh          veggies 
D. Wold               Salad 
Bill Cotter           Meatballs 
Glen Kirschenmann     48 cans pop 
Al Noble              Special K Bars 
Don Langford          BBQ Smookies 
Lance Ringquist       Cookies 
Larry Serflatten      ??????????? 
Ray Wafer             Potatoe salad 
Mike Weist            ????????????
Mike Schmidt	Plates, napkins, utensils

+----------------------------------------+
|                Larry's                 |
|            ACTION! TUTORIAL            |
+----------------------------------------+
#17              VICTORY
------------------------------------------
From the last issue:
The 12 different boxes of product need 
11 gates to provide 12 conveyors to the 
12 automatic shelves.  My set of eleven 
tests began with a scale weighing out 
any package less than 15 Lbs.  If your 
solution has something different, that is 
perfectly acceptable, provided it meets 
the needs of the job.  Basically the first 
test should divide the group of products 
roughly in half, but it is not mandatory. 
The important part is that it performs as 
required, and you can check that by using 
your flowchart to see where each box 
would get diverted to.  The criteria was 
that the boxes should end up on separate 
shelves.  You might imagine the supervisor 
may want to invest more cash into the 
system and ask you to add in the needed 
equipment to reject certain boxes which 
fail in a unique way, and return all 
rejects on a new conveyor to the plant.

Such is the way it goes in programming, 
just when you think your done, somebody 
shows up and wants to change the program. 
A good flowchart helps in modifying an 
already complete program.  With a flow 
chart, the programmer can make necessary 
changes to the algorithm, and can quickly 
add in the needed code in the proper spot. 
This is just a reminder to always document 
your programs, either by the use of a flow 
chart, or in the source code itself.  You 
never know when you may decide to add more 
stuff to a finished program.

Moving from words in a flowchart, to code 
on the computer can be made easy to do. 
The more details included in a flowchart, 
the easier it is to translate into code. 
Flowcharts also help in optimization of 
algorithms.  Careful inspection of a flow 
chart can reveal redundant loading of a 
variable, or testing of a value, that may 
be consolidated or reduced.  Looking at 
the whole process, might give insight to 
a different algorithm, or method, that 
will do the same thing even quicker.  Some 
times a better algorithm will be enough, 
and should be attempted first, but there 
are occasions when assembly is the best 
choice.  Remember you need only to rework 
the code that causes a delay, or that will 
make a perceptable difference.  There is 
no big advantage in optimizing the part of 
a program that is already performing well.

As if to fly in the face of good advice, 
look back at issue #12's procedures.  Here 
we had a few good routines that were made 
even better by translating part of them to 
machine code (AscToInt).  EchoS has a loop 
in it, one of the most basic programming 
structures, and the most time consuming. 
Translating this routine to machine code 
will provide an example of the loop 
structure as it appears in machine 
language.

First the flowchart:

1.  Save STRING address
2.  Calculate DESTINATION address
3.  Initialize counter
4.  Load byte from STRING
5.  Save byte to DESTINATION
6.  Decrement counter
7.  Test for end condition
8.  Loop to "4" until done
9.  RETURN

Now the code:

PROC EchoS=*(BYTE ARRAY S)
   ;1. Save STRING address
[$85 $A2       ;STA $A2  Save S LO
 $86 $A3       ;STX $A3  Save S HI
   ;2. DEST=(Y*40)+SAVMSC+X
 $A5 $54       ;LDA $54  Y pos
 $A2 40        ;LDX #40
 $20 MultiplyB ;JSR MultiplyB
 $18           ;CLC
 $A5 $58       ;LDA $58  Screen LO
 $65 $55       ;ADC $55  X pos
 $65 $A0       ;ADC $A0  (Y*40) LO
 $85 $A4       ;STA $A3  DEST   LO
 $A5 $59       ;LDA $59  Screen HI
 $65 $A1       ;ADC $A1  (Y*40) HI
 $85 $A5       ;STA $A4  DEST   HI
  ;3. Init counter
 $A0 $00       ;LDY 0
 $B1 $A2       ;LDA ($A2),Y
 $A8           ;TAY
 $88           ;DEY
  ;START=START+1  S(0) is string Length!
 $18           ;CLC
 $E6 $A2       ;INC $A2
 $D0 $02       ;BNE 2
 $E6 $A3       ;INC $A3 
   ;4.  LOOP start, load byte
 $B1 $A2       ;LDA ($A2),Y
 $20 AscToInt  ;JSR AscToInt
   ;5. Store byte 
 $91 $A4       ;STA ($A4),Y
   ;6 Decrement counter 
 $88           ;DEY
   ;7 & 8. Test and Loop until done 
 $10 $F6       ;BPL (LOOP)
   ;9. RETURN from whence we came
 $60]          ;RETURN

As you can see, most of this procedure is 
spent setting up the parameters for the 
loop.  The loop itself is quite small, 
only 10 bytes (Two bytes are used to 
indicate where AscToInt is located).  This 
loop can still be optimized further, if 
desired, by moving all the code from the 
AscToInt routine to its proper place in 
the loop.  This results in eliminating the 
need for jumping (using time to store 
values on the processor stack and in the 
program counter) which is time consuming 
when done repeatedly.  The code from the 
AscToInt routine is needed for this loop 
to function, so moving it 'in line' will 
make the loop larger, but will actually 
reduce the execution time.
------------------------------------------
Were you wondering how to call a procedure 
using machine language?  You can also call 
ACTION! routines that you have written. 
ACTION! passes variables using the A and X 
registers, and returns function values in 
$A0 and $A1.

+----------------------------------------+
|                Larry's                 |
|            ACTION! TUTORIAL            |
+----------------------------------------+
#18        BREAKING THE RECORD!
------------------------------------------
BYTES, CARDS, POINTERS, and ARRAYS can be 
used for most of your programming.  There 
comes a time when you must work with a 
large amount of data, and a mixed set of 
BYTES, CARDS, and ARRAYS.  At times it 
makes sense to organize your data so that 
it may be easily processed, other times it 
makes just as much sense to organize your 
data for optimum use with files on a disk. 
Records are used to help in both of these 
areas.

Records allow a programmer to group the 
fundamental data types together (BYTES, 
CARDS, and INTEGERS).  The grouping must 
be declared before it is used. The records 
become real useful when you set up a block 
of memory to hold an array of records. 
This is no more than a BYTE array, which 
is divided into individual records, one 
record right after the other.  Each record 
can be accessed using a record POINTER, 
which steps through the array, in steps 
the size of one record.

TYPE DAY=[BYTE hi,lo   ;Record FORMAT
          INT change]

BYTE ARRAY memory(400) ;Records storage

DAY POINTER temp       ;Record ID

DEFINE RECORD_SIZE="4" ;2 BYTES + 1 INT 
DEFINE MAX_DAYS="9"    ;99 max!

PROC Make_Record() 
BYTE i,r=53770,oldtemp 
INT chg

  temp=memory             ;# 1a

  oldtemp=75 
  FOR i=0 TO MAX_DAYS 
  DO
    chg=r&7
    chg==-4
    temp.change=chg
    temp.hi=oldtemp+chg
    temp.lo=temp.hi-5-(r&3)
    oldtemp=temp.hi
    temp==+RECORD_SIZE    ;# 1b
  OD
RETURN

PROC SHOW() 
BYTE i

Make_Record()

Graphics(0) 
PrintE(" ")

printE("DAY   High   Low   Chg")

  FOR i=0 TO MAX_DAYS
  DO
    temp=memory+(RECORD_SIZE*i) ;# 2
    PrintF(" %U     %U     %U    %I",
       i,temp.hi,temp.lo,temp.change)
    PrintE(" ")
  OD
RETURN

You can read your manual to get further 
information on declaring records.  This 
program is nothing special, it creates a 
list of each days high and low temperature 
and indicates the change of the high temp 
from one day to the next.  Take note, 
there are two methods used to access the 
records.  Method #1 sets 'temp' to the 
start of the storage area (1a) and steps 
through each record by adding RECORD_SIZE 
to 'temp' (1b) each pass through the loop. 
Method #2 calculates the proper location 
of each record (#2).  This random access 
method of locating each record is simple 
to use and works well for records that 
reside completely in memory.

Because each record can be accessed in a 
uniform manner, the need for special data 
handling code is reduced.  To give you a 
little practice in using records, try to 
write a routine that would allow you to 
enter the data for this program.  You can 
have the user input the high and low 
temperatures, and the computer calculating 
the amount of change in high temperature 
from the previous day.  When you have that 
routine working, write a program to keep 
track of the time of the sun rising and 
setting each day.  Also keep track of how 
many hours of daylight there are in each 
day and the change in daylight hours from 
one day to the next.  The more practice 
you get, the better you become.
------------------------------------------
Records are a very useful tool.  As will 
be shown next month, they can be used to 
provide an easy means of working with data 
objects (the manual calls them 'virtual 
records'), we're going to call them worms!


DISCLAIMER

Published by the Saint Paul Atari Computer Enthusiasts (SPACE), an independent organization with no business affiliation with ATARI Corporation. Permission is granted to any similar organization with which SPACE exchanges newsletters to reprint material from this newsletter. We do however ask that credit be given to the authors and to SPACE. Opinions expressed are those of the authors and do not necessarily reflect the views of SPACE, the club officers, club members or ATARI Corporation.


Return to the SPACE Home Page


Maintained by Michael Current, mcurrent@carleton.edu
Last updated: Saturday, April 20, 2002