** Regular, 2 pages HiSoft BASIC tutorial 3 / 1098 words ** IF you want something done, THEN do it yourself, ELSE don't bother! With the summer heat, why not stay in and do some programming? Paul Jones goes through the BASIC basics... FOR loops, although useful, don't make decisions and it's decisions which make programs useful. We make thousands of decisions everyday: ** non-prop on ** Normally I wake up around 9am and get a cup of tea ** np off ** Applying this to BASIC would give us: ** np on ** IF up THEN GET cup of tea ** np off ** OK, there's not much mileage converting real life examples into BASIC so let's get practical: ** Picture: GRAB01.GIF ** This loop increments a from 1 up to 100. IF a is equal to 25 (nothing more, nothing less) the computer outputs "Quarter way there..." and so on. We can extend the decision making process by asking the program to evaluate if a statement is true. IF the statement is true the program performs one task, ELSE it performs a different task: ** np on ** IF a=1 THEN PRINT "a is 1" ELSE PRINT "a is something other than 1" ** np off ** So if a contains one the program outputs "a is 1", otherwise (if a = 2 or -1 etc) the program outputs "a is something other than 1". Easy eh? Now try this: ** GRAB02.GIF here ** Using the INPUT statement we can print a prompt message on screen and ask the user to input (or get) a number/string for use within the program. We're assuming the user will input a number and assign this to a. The rest is pretty much self-explanatory so long as you're familiar with the less than "<" and ">" greater than maths functions. ** GRAB03.GIF here ** Here's another loop and decision variation which consists of an IF loop containing multiple ELSEIF statements - use as many ELSEIF's as required. Notice I've placed the actions on separate indented lines using the [Tab] key because it makes the code easier to read, especially if you have several loops running one inside the other - trust me! The program takes the input number and checks each statement in turn, outputs the result string of the first true statement then jumps to the end of the loop. HiSoft BASIC syntax dictates an "IF... THEN..." statement where the command isn't on the same line must include an ENDIF at the end. SUBscribe and FUNCTION normally... Next up are SUB routines and FUNCTIONs. These are useful for performing repeated tasks. The difference between SUB and FUNCTION is the later can return something whereas a SUB cannot. Consider this program: ** GRAB04.GIF here ** This simply prints "Hello!" ten times followed by ten "From Paul J."'s. Notice I've specified 'NEXT a' instead of 'NEXT' on its own - this makes it easier to keep track of multiple loops when creating large programs and is good practice. An alternative to having dozens of loops running inside each other (called nested loops) is to use a SUB routine: ** GRAB05.GIF here ** This program has exactly the same result as the previous example. We've created our first command - just like the built-in PRINT command. The CALL prefix before the strings isn't a requirement but does stop the compiler complaining (especially using v2). Anything between the brackets is called a parameter and "sent" to the "print_my_string" routine. Lets take this SUB routine apart: ** np on ** SUB print_my_string (s$) ** np off ** We've created a SUB routine called "print_my_string". It takes a parameter and puts it into s$ ready to use. Variables cannot be included in strings so this function ONLY prints strings - if you try to include variables the compiler will complain! ** np on ** STATIC a ** np off ** This only works in SUB/FUNCTIONs. It tells HBASIC we want to use the variable a in our SUB program. Every variable/string you use must be included here - s$ doesn't have to be declared using STATIC because HBASIC already knows about it. ** GRAB06.GIF here ** Whatever s$ contains will be printed ten times so by changing s$ the SUB routines can save writing almost identical separate loops. Everything you want to use in a SUB/FUNCTION, and is not used as a parameter has to be STATICed. Also, if you want to use the contents of a variable/string from the main program or another SUB/FUNCTION, you need a "SHARED" with the lists of strings and variables you want to use after it. ** np on ** END SUB ** np off ** This informs HBASIC the SUB routine has finished. The same format applies to a FUNCTION too, except a FUNCTION returns a number: ** GRAB07.GIF here ** We get two variable parameters, multiply them together and put them into the result variable. STATIC isn't needed because every number we're using is known to HBASIC. Because this is a function we want something to be returned, so, the result is put into the name of function. For example, if the name of your function was "FNdummy_test" then in the program you would have a "FNdummy_test=" and then the return number. We call the function a=FNmulti (2,4). This means a contains the result, but it doesn't matter what the variable/string input parameters are in the SUB/FUNCTION - "g=FNmulti (2,4)" would work just the same. The FN tells HBASIC we want to call a FUNCTION. In the HBASIC v2 compile dialogs there's a "No FN's in libraries" option which means you don't have to type in FN's - for compatibility reasons it's safest to leave them in. Also bear in mind you can't create a command which is already defined! ** Boxout 1 ** Where's PDO? I tried to install a coprocessor and damaged my Falcon losing the source code for PDO! However, PDO will return next issue and I'll be explaining the source. ** End boxout 1 ** ** Boxout 2 ** Feedback If you have any comments about the tutorial, problems with your code or code to contribute please get in touch: ** BC on ** Email: paulat.jones@zetnet.co.uk URL: http://www.users.zetnet.co.uk/pjones/home.htm Post: Via the Atari Computing office ** End boxout 2 ** ** Boxout 3 ** ** On Reader Disk logo here ** Number game As a consolation for the delayed PDO there's a number guessing game on the Reader disk complete with explanatory notes. ** End boxout 3 **