Barrie's MSDOS GFA Basic Page

Music Now Playing: 'Light My Fire' By The Doors speaker.gif - 1.64 K

At last... a big welcome back to my GFA Basic page - by popular demand!... Well a couple of people e-mailed me to ask where it had gone, and that's good enough for me!

I only got rid of it because I didn't seem to be getting any response from it. I thought no-one else was using DOS GFA Basic because they had switched to the Windows version or some other language through lack of support. But, when I zapped it, people complained. Anyway it's here again so what am I going to put on here?

Well, before that, who am I and what do I know about GFA Basic anyway? Well let's start with a potted history...

Once Upon A Time...

I first used GFA Basic on the 8-bit Atari when it was known as 'Turbo Basic' - years before Frank Ostrowski was asked by GFA in Germany to write a 16 bit version for the then new and powerful Atari ST. When my mate Andy and I bought our ST's shortly after the release of GFA Basic Version 1, the interpreter was the first thing we bought and as it borrowed heavily from the Pascal oriented 8-bit version, I didn't have to learn a completely new language from scratch.

With it, Andy and I wrote a range of commercially available programs for the ST under the name of AB Software, including AB Animator, Picstrip, Mastermat, and a range of educational titles featuring a character called 'Uncle Oscar' - Add With Oscar, Spell With Oscar and Oscar's Paintbox being the most popular. ST owners from back then with good memories may remember that I re-wrote AB Animator and it appeared as 'Animaster' on the coverdisk of ST Format - a magazine in which I was for a long time the 'resident' GFA Basic agony aunt.

The first thing we noticed when we ran into problems writing these programs was that GFA support was a little thin on the ground, so we decided to create some for the few users out there at that time. We decided on a monthly magazine, and that's how GFA User Magazine was born. Without a UK distributor, initially we were handling readers problems by dealing directly with GFA in Germany and with a thousand subscribers, it lasted some four years until I found myself with not enough time on my hands to be the editor and hold down a job at the same time, so sadly it was wound down. I'm sure that anyone who subscribed to it found the information it contained, well worth the subscription fee and despite taking up every waking moment I had, it was an enjoyable experience...

During the life of the magazine, we saw the first UK publisher of GFA Basic - Glentop - appear and later relinquish control to Les Player, formally one of the top men at Atari, when GFA UK was formed and our close links with both, resulted in us writing the English versions of a number of GFA product manuals for the ST. I'm also proud to say that had I not plucked the German version of GFA Raytrace out of the bin during a visit to Glentop, GFA's second biggest selling ST product here in the UK would not even have been released!

Also while we were working on the magazine, versions 2 and 3 of the ST interpreter were released, as were the Amiga and eventually the MSDOS PC version, (the Windows version followed later). The Amiga version died a death I guess because of a mixture of piracy and the fact that the machine itself was crap for anything other than games, (yes, I did actually own one).

We tried in the magazine to cover all platforms, but after a bit of 'reader debate' we junked the Amiga and integrated the PC support with the ST. To maintain the support, Andy decided to concentrate on the Windows PC version, while I stuck to the MSDOS version - something we have kept to, long since GFA User Magazine disappeared.

So, maybe I'm partly responsible for some of you GFA programmers out there having heard of GFA here in the UK at least - especially old ST users moving up to PC's and wanting to continue GFA progging. I suppose had Andy and I not bothered with GFA User, then the PC version may not have happened here in the UK and GFA may never have been heard of. There again, maybe not...

Finally, before I start, can I make it quite clear that I ONLY use the MSDOS version of GFA Basic. I have NEVER used the Windows version, so please, please, please don't e-mail me with your Windows problems - I can't help! The DOS version however, is different.

Why DOS?

A computer program is a work of art. A computer programmer is an artist. When Constable started a painting, he began with a blank canvas. When I start a program, I like it to be the same. My programs have my individual look and feel to them and with DOS programs, you can design a graphical look in a way Windows doesn't allow. No-one is saying "you will use a window like this..." or "you must use buttons like that...". Sadly, DOS is now all but dead, however two thing stop me from giving up on it. Firstly, I now program for fun and secondly, even with Windows 95, you can still run DOS programs, so you can still distribute your masterpieces to other users! Apart from that, it runs so much faster...

GFA Programming Tools

SPRITED

OK, OK, what goodies have I got for you? Well, first up, is a rather useful sprite editor tool, imaginatively called SPRITED which I knocked together to make sprites for a little game from way back that someone said they couldn't find anywhere. Having first written the game using ASCII characters, I thought that sprites would look better, so I decided to write an editor to make producing them easier. It doesn't do animation (yet!), but it does have a few useful features like a painting toolbox, vertical and horizontal flipping, rotating, mirrored drawing and auto mask creation. It also comes with a GFA Basic routine for loading them into your own programs and the source code for very basic use of sprites in a pretty naff version of Space Invaders. I am going to refine it a little, but for now, you can get hold of SPRITED in it's current, (and perfectly usable), state.

As it is a programming aid, SPRITED is a compiled .EXE file, so you don't get the source code to it. You do however, get to use it and report back on bugs and suggest new features for it. And... if you write a game with it like 'Apples' below, send it to me and I'll put it on here for others to download. Maybe we can build up a little collection...

Download SPRITED.EXE (55K ZIP) - The GFA DOS Sprite Editor

Apples

My son Craig and I both wrote a version of Tron/Line Wars, call it what you will, and his mates played his version at college. One of his mates asked him to write a version of an old program, (the name we can't remember), where a caterpillar-type insect is guided around the screen eating apples. Each time one is eaten, the body length grows. You can't crash into the borders or yourself. For amusement, I wrote the game 'Apples' based on this idea. To make things more interesting, blocks appear once you get past a certain level and eating apples means more segments means more legs, so you go faster! You get 100 points per apple eaten and a free life every 10000 points.

Apart from being a vehicle for the sprites created by SPRITED, it also has another feature which may be of interest to GFA DOS programmers - 'inline sprites'. Well that's what I call them anyway!

Download APPLES.EXE (41K ZIP) - DOS Game With Example Sprites

SPR2DATA

The program SPRITED creates .SPR files which are normally loaded off disk by a program when it first runs, (the routine is supplied with SPRITED). So, the program Apples was originally an .EXE file and a dozen or so .SPR files. If you download APPLES, you will notice that it is now a single .EXE file - no .SPR files. This is thanks to another small GFA program of mine called SPR2DATA which takes the sprite files created with SPRITED and converts them into lines of GFA code which you merge into your program. A supplied procedure then creates the sprites at run-time. Then, when the file is compiled, your sprites are embedded into the EXE. Those of you from the GFA ST world will remember a GFA command called INLINE which allowed a similar thing. The PC version lost the INLINE command, but that's where I got the term 'inline sprites' anyway.

Download SPR2DATA.EXE (ZIP) - Sprite To GFA Code Converter

GFA Source Code

What do you need? Problems with a routine, or want a workaround for a bug? Try me. For now, the following routines may be of help.

Timer

PC's today are fast. A program written in GFA on an earlier 486 will probably be unplayable on a P200 or faster. So, you need to have a way of ensuring your programs don't run too fast on faster machines - or too slow on slower machines.

GFA gives you the PAUSE and DELAY commands, but these tend to slow down your program too much. For example, DELAY(1) is a one second delay - much too long for say animation loops and values less than one aren't too successful. An alternative is to use a FOR...NEXT loop in your program, but if it's an empty loop, when you compile it the compiler will completely remove it in the name of optimization! What you need is the following routine which uses the PC's timer routine to give you precise timing control down to millisecond precision.

With this procedure in your program, delays can be reated by simply entering @wait(value) where value is the number of milliseconds delay you want. In the program APPLES, the initial delay variable 'speed%' is set to 200. This value is steadily reduced as apples are eaten - the effect being to speed up the catterpillar.

Replacement INKEY$

An odd one this... Have you noticed that graphic programs can act unpredictably when updating the screen if you use INKEY$ at the same time? For example, if you use PUT to place graphics on the screen under control of the cursor keys, or you want your graphics program to stop if you hit the Esc key, then you have to use INKEY$ to poll the keyboard. What happens when you do is that you suffer from drastic slowing down of the PC. This causes your graphics to flicker heavily or your screen output slow down.

Try entering in the following routine (leave the // on the third line for now):

You should have got a pretty spirally dot pattern. If you did, take out the // rem from the a$=INKEY$ line and run it again.

On some machines, the dot pattern is produced at a drastically reduced speed - speeding up if you hit a key. If this happens on your PC then the work-around below, which emulates the INKEY$ command using DOS interrupt calls, may be of help. Use it instead of INKEY$ and bingo, the flashing graphics disappear.

What the above routine does is call the keyboard interrupt $16 subfunction 1, (non-wait keyboard poll), and then checks the zero bit of the flag register. If this is set to 0 then a key has been pressed, otherwise it will be 1. As soon as a 0 is detected, the ASCII code is dumped into i% from return register _AH and the IO buffer is cleared. The variable i%, (or whatever you use) contains the same value as if you had done:

Well that's it for now. Please e-mail me if you have any specific problems or requirements for routines. I'll add to these as and when I can and continue to update the programming tools as often as I can.