* * * *›   Modular Programming in Atari Basic.›             Part II---- by Ron Fetzer››      Have you ever envied the  people› who  can  write long programs. Do you› say to yourself, programming  is  too› hard.  I  do  not have any talent for› programming. If you say these  things› then  you  are missing 90% of the fun› of computing. Now there  is  an  easy› way  of  programming. You do not need› any  special  talents.  No  one  ever› showed you the easy and  fun  way  of› programming.  It  has  been  kept   a› secret    from   BASIC   programmers.› Everyone can  write  great  programs!› The  answer  to  writing  programs is› modular programming. Once you try  it› you will love it.››      Be  sure  to have the listing of› ENVELOPE.ATR (which will be found  on› the  MAY/JUNE  OL' HACKER NEWSLETTER,› and in the  ATARI CLASSIC disk) handy› so  you  can follow the discussion in› this  2nd part  of  the  series    on› programming. Also see  "SKELETON.ENV"› on side 2 as part of this tutorial.››      In the first part of this series› I showed you how to  write  out  your› ideas  for  a program in English. How› to construct a block diagram and  how› to  create  a  skeleton  program. You› created a blue print for  your  final› program.  In this section I will show› you how to  flesh  out  the  skeleton› program and how to polish it up.››      To  begin  with  every   program› should have a line 0,1 and 5. On line› 0 it should say  '0  GOTO  10'.  Thus› when  you  write RUN the program will› go to line 10 and execute.  Line  one› should        say       '1       SAVE› "D:FILENAME.EXT":CLR' in  my  program› it  is '1 SAVE "D:ENVELOPE.ATR":CLR'.› This is a very useful line  when  you› are  developing a program. Every time› you want to save part  or  the  whole› program  you  type  'GOTO   1'.   The› program  will  now  be saved with the› same filename all the time. You  will› not  have  multiple  versions  of the› program but just one version all  the› time.  The  CLR  just   removes   any› previous DIM so that the program will› run without any trouble.››      Line 5 is the title line of  the› program. It should have the following› information. 1.  The  author  of  the› program.  2. The name of the program.› 3. The version number of the program.› 4.    What   language   the   program› requires. 5. The date it was written.› For  an  example  see  line  5 of the› listing. You can  also  include  your› address  if you want to so a user can› contact you.››       We   will  now  flesh  out  the› skeleton   program.   The    skeleton› program  is also part of this series.› Start  each module with a REM and the› module name plus asterisks to fill  a› total of two screen lines. This makes› a very visible divider.››      The first module that we have is› the  CONTROL MODULE. When I clear the› screen   I  always  use  ?  CHR$(125)› because every printer  can  list  it.› Special  characters  cannot always be› listed. The CONTROL MODULE is already› finished  as  it  appeared   in   the› skeleton program›› 10 REM  CONTROL  MODULE *************› 20  ?  CHR$(125):GOSUB   500:REM  DIM›    SECTION› 30 GOSUB 1000:REM SCREEN COLORS› 40 GOSUB 1500:REM RETURN ADDRESS› 50 GOSUB 2000:REM MENU› 60 GOTO 50››      I go to the  DIM  Section,  then› the  SCREEN  COLOR  MODULE  then  the› RETURN  ADDRESS  MODULE  and then the› MENU MODULE. Notice  line  60.  After› each  menu selection is completed the› program returns to line 60.  Line  60› directs it again to line 50. Thus you› always return to the menu. This  kind› of   program   is   called   a   Case› Structured type of program. It is the› most  common  type   of   programming› structure used.››      As  you can see fleshing out the› skeleton program is very easy to  do.› Our  next  module is the DIM SECTION.› The first thing you do is  to  remove› the PRINT statement from the skeleton› program. It is  not  needed  anymore.› There  is  nothing  strange  in  this› module. Just put in the DIM variables› the way they are  needed.  If  a  DIM› variable  here  appears  in the front› then you know it is in the  beginning› of  the  program  etc.  Do not forget› that the RETURN statement now  has  a› new line number.››      In  each  module  the  1st  line› after    the    REM   line   is   the› housekeeping  line  for  the  module.› Such     things    as    initializing› variables,   PEEKS,   POKES,   string› lengths,  special  codes  etc will be› put in this line. I do this the  same› way  for every module. Consistency is› the   hallmark  of  a  good  program.› Notice line 1010 R$ is set  to  equal› 13  empty  spaces.  Rather than using› the  POSITION  command  for  my  menu› selection I put R$ in  front  of  the› options.  If  I  want  to  center the› options I just  have  to  change  the› length of R$. I want the user to have› a choice  of  the  4  popular  screen› colors while he is using the program.› Error trapping  should  be  extensive› and it should always be done the same› way in every module. When a choice of› color  has  been implemented then the› program  exits  to  the  end  of  the› module.   This  module  and  all  the› modules follow the  law  of  straight› sequence. You enter at the top of the› module and you exit at the bottom  of› the  module. It makes it easy to read› and   understand  your  program.  All› modules must follow this rule.››      The next is the  RETURN  ADDRESS› MODULE.  Remove  the  PRINT statement› from the skeleton program. The  first› line    after    the   REM   is   the› housekeeping line. I only  need  a  ?› CHR$(125)  in this module. Then I ask› for INPUTS for  name,  street,  town,› state,       Zip       Code       and› country(optional).   I   write   many› letters  overseas  so  the country is› important to  me.  This  is  straight› forward  programming. The module ends› with a RETURN in line 1590.››      The  next  module  is  the  MENU› MODULE.    In    the     housekeeping› line(2010)    I   have   an   'LPRINT› CHR$(27);"8"'. This  is  the  control› code  to TURN OFF PAPER SENSOR for an› Epson printer. I want this sensor off› because  I will constantly be feeding› envelopes into my printer. If you  do› not  know  the  code for your printer› this is what you can do.  Remove  the› paper  from  the  printer. The sensor› will now sound. Take a strip of paper› and  slip  it  in  to  the paper feed› until   the  sensor  goes  off.  Then› temporarily scotch tape it to the top› of  your  case  so it will not be fed› through the rollers. Now you can feed› envelopes  without  any  trouble  and› without  the  noise.  Be sure to have› and END option in the menu  selection› so  the user can exit. Error trapping› again is the same  as  in  the  other› modules.  The  module  exits  with  a› RETURN in line 2100.››      In  the  module  on   FORWARDING› ADDRESS I initialize all variables to› an empty string in  the  housekeeping› line  in  2510.  This  module will be› accessed repeatedly. I want  to  make› sure  that  the strings are empty. In› all other respects it is the same  as› the RETURN ADDRESS MODULE.››      The  CHRISTMAS  CARD MODULE, the› BUSINESS   ENVELOPE  MODULE  and  the› LARGE   ENVELOPE   MODULE   are  very› similar. In the housekeeping  line  I› initialize  the  variables and set B$› equal to the required spaces. I  call› for  sub  module  FORWARDING  ADDRESS› (GOSUB  2500)  and  sub  module PRINT› RETURN ADDRESS (GOSUB 5000).  Then  I› print then name, street, town, state,› Zip Code and country on the envelope.› I  exit  with  a  RETURN that goes to› line 2100 and  then  to  the  control› module  line  60,  which in turn puts› you back into the menu module.››       The  last  module  is  the  END› MODULE. On the  housekeeping  line  I› use  POKE  752,1  to  turn  off   the› cursor. Then I print "END OF PROGRAM"› in the middle of the screen. I change› the screen color back to default with› a GRAPHICS 0  command  and  turn  the› cursor back on again.››      You  can now see how easy it was› to complete each module and the whole› program.  Even  if you are a beginner› you  can  read  and  understand  this› program.  It  is  consistent  and  it› follows the law of straight sequence.› You  enter at the top and exit at the› bottom of the modules.  You  now  can› easily  modify this program by adding› other modules for different  envelope› sizes  if  you  want to. There was no› frustration in writing these modules.› It  was  fun and very satisfying. You› do not have to be a super  programmer› to  complete  a program like this. If› you use modular programming  the  fun› of computing will come back again and› your programs will be a joy  to  read› and run.››      The  final step is to polish the› program. Make  sure  that  tiles  are› centered  on  the  screen,  variables› initialized  or  set  to   0,   Error› Trapping  is  in  place.  As the last› step I renumber the program.  I  load› it  into  TURBO  BASIC  which  has  a› renumber  command  and  write   RENUM› 10,10,10.  This  will   renumber   my› program  from  line  10  on with a 10› line interval. Now  your  program  is› finished.››      You  have  seen all the things a› good program should  have.  Here  are› some  of  the  things that you should› avoid.››      Do not create a fancy graphic or› logo  screen  as  the  first  module.› Remember  the  user  has  to use your› program repeatedly. A  fancy  opening› screen  says only one thing "Look how› clever a  programer  I  am".  Conceit› like this is hard to bear repeatedly.› It is O.K. to have  a  fancy  opening› screen  on  your  documentation  file› because it will be accessed only once› or twice and thus can be tolerated.››      Writing good documentation is as› important  as writing a good program.› Documentation should be complete  and› as  brief  as  possible.  Reading   a› documentation  is  inherently boring,› so make it brief. Do not  include  in› your  'doc'  file  all   the   clever› programming  tricks  you used. Do not› become verbose. It is O.K. to include› printer control codes that might have› to be changed but other than that  it› should  have  no  programming code in› it. Also include in the  'docs'  your› address so a user can contact you.››      Do  not  compile a program if it› is not necessary. There are only  two› good reasons to compile. One you need› a faster speed and two  you  want  to› hide  your  code.  A   program   that› depends for its speed on a peripheral› device   should  never  be  compiled.› There would be no point in  compiling› this  program  because  its  speed is› determined by the printer.››      Do not  use  obscure  PEEKS  and› POKES  if  a  regular  structure   is› available.  Overused  PEEKS and POKES› are   only  justified  if  your  free› memory is running  out.  Obscure  and› overused PEEKS and POKES say just one› thing "I  am  so  clever.  You  can't› follow  me."  It  is  another form of› program conceit.››      As a last remark I am  aware  of› Dave  Small's contempt for structured› programming but even he would  admit › that  a  clear  organized  program is› better than spaghetti code.  I  am  a› long time  member  of the:› OL' HACKERS  ATARI  CLUB USERS GROUP,› Inc. in in Oceanside NY Your comments› and reactions to these articles  will› be appreciated.  Please write to me:›› RON FETZER› 22  MONACO  AVE.› ELMONT N.Y.  11003, USA.›              * * * *›