Using GFA BASIC - Part 10
GREETINGS
Before leaving Oz to return to the United States, I promised to continue with an occasional addition to my “Using GFA BASIC” series of tutorials. As is so often the case, my promise seemed to be OBE (Overcome By Events). My apologies to all who were following this column, but better late than never I suppose.
NEW GFA PRODUCTS
GFA Data Media, the European distributor for all GFA products, has recently released a few new utilities aimed specifically at the GFA BASIC programmer. One of these is the GFA GEM Utility Package, known more affectionately as “GUP”. This is a standalone program which provides a means to implement some of the more esoteric GEM features of GFA BASIC. It allows programmers to include procedures in their own GFA BASIC 3.0 source code to support pull-down menus, windows, icons, dialog boxes and more. It is indeed a full-featured package but based upon my admittedly limited experience with it so far, it will still be quite a handful for the novice programmer. It promises a lot, but it’s ease of use seems tenuous at best. I’ll try to take an indepth look at it (might as well since I bought it!) and report back to you with my findings in a future column.
Another product is the GFA COMMAND SHELL. I have not purchased or reviewed this product as yet, but it appears to be a utility from which you can use the GFA BASIC interpretor AND compiler simultaneously. In other words, from within the shell, you access the interpretor to edit your GFA code as usual, then with a simple mouse click, you can compile and test the code then return to the interpretor again. There would be no need to return to the desktop, execute the compiler, then return to the interpretor again. If you use GFA BASIC a lot, this may be a worthwhile addition to your utilities library. I imagine it will require a minimum of 1 Mb of RAM, however.
The latest version of GFA BASIC 3.0 is 3.5E. Not exactly an earth-shattering major revision, but it does correct some of the bugs which existed in the earlier 3.07E version, particularly when used with the compiler. Speaking of which, the latest version of the compiler is 3.5E also. As the modifications are fairly minor, I would not necessarily recommend you upgrade from earlier versions of 3.0 right away, unless you were experiencing a particularly annoying bug which may have been corrected with 3.5E. Of course, if you are still using GFA BASIC 2.0, I strongly recommend you purchase the 3.0 version due to its many worthwhile enhanced features which I have often mentioned before.
USING THE INLINE COMMAND
One of the more interesting but seldom used commands in the huge GFA BASIC 3.x repetoire is INLINE. Put simply, this instruction reserves an area of memory within a program and may be “loaded” with data from an external file. When you save your program, this memory area is saved as well. Confused? You should be! Perhaps a practical example will help clarify INLINE’s use.
As we have demonstrated in earlier columns, it is an easy matter for GFA BASIC to load a DEGAS format picture from disk and display it on screen. But wouldn’t it be nice if you could “suck up” the data that makes up a picture file and save it in your BASIC program? That way, you would not need to keep a separate picture file on disk as it would become an integral part of your program itself. Here is an example bit of code that uses the INLINE command to do just that.
’ ---------------------------------------------------------------
’ INLINE Demo
’ Demonstrates the use of the INLINE command to LOAD a DEGAS
’ format picture file from reserved memory.
’
CLS ! Clear the screen
do_inline ! Execute the procedure
DO
LOOP
’
’
PROCEDURE do_inline
’ NOTE: Place NO comments on the next line!
INLINE x%,32066
adr%=XBIOS(2) ! Start of screen memory
FOR cnt%=80+32 TO 32066-32 STEP 80 ! Count the screen data
BMOVE x%+32066-cnt%,adr%,cnt% ! Move data to screen
NEXT cnt%
RETURN
’
’ ----------------------------------------------------------------
Now this is a bit tricky, so stay with me, OK? When you type in the line with the INLINE command, position the cursor on that line and press the HELP key on your keyboard. When you do so, the upper row of your interpretor function key screen display will change to the INLINE menu commands: LOAD, SAVE, DUMP, CLEAR
LOAD is used to load a machine code program or data into the reserved area. SAVE will save the contents of this area to a disk file. DUMP will send a hexadecimal printout of the area to your printer and CLEAR will fill the reserved memory area with zeros.
What we want to do here is LOAD the reserved area with the data that makes up our DEGAS format picture file. So with the INLINE menu commands on screen, press the “L” key on your keyboard for LOAD. This will bring up a fileselector box. Select any standard, uncompressed DEGAS format picture file of the appropriate screen resolution and press RETURN. When you finally save your program, you will note that it has grown larger by more than 32000 bytes! That’s because the DEGAS picture data is now stored in the reserved memory area x%.
So x% is the adress of the beginning of our reserved memory area that will hold the DEGAS picture data. The variable adr% is the beginning of screen memory which we found from the XBIOS(2) command. And cnt% is just our counter variable that uses the ultra-fast BMOVE command to move the picture data from its storage place (x%) to the screen (adr%).
Note that since this is a DEGAS format picture we have to take account of the 32 header bytes of non-picture data info that all DEGAS pictures contain. This is the stuff that designates what the screen resolution is, what the colour palettes are, color cycling data, etc. We don’t need this info to display the picture, so we just bypass it.
You will note that when the program is run, the screen picture is built from the top down and has a rather wierd appearance as it juggles the bytes of screen info around. For aesthetics, you may wish to temporarily turn the screen off with a SETCOLOR 0,0,0 instruction while the picture loads, then turn it back on once it’s done.
This is just one example of using INLINE. You can also use it to save external machine code programs or even resource files for use within your program. Increased security is another added benefit. Once you compile your finished program, you virtually eliminate the chance of anyone altering the picture file or whatever you stored with INLINE. It does make your program larger, however, so you need to be aware of the tradeoffs.
WRAP IT UP
That’s enough for this time around. Hope you try out the INLINE command and come up with some interesting uses for it.
I’ll be back again soon with some more hints and tips for using GFA BASIC.
And remember... keep on hackin’!
John Hutchinson