Initiation to the GFA Basic
(Partie 1)

By Exyl/Sector One

Remember of the big time where the Toxic Mag proposed various initiations among others to programming languages. And well this time is not bygone since starts today, in the year of grace 1999, an initiation to the GFA! Articles composing it will be provided because the release of the Toxic Mag is irregular and rare enough, it will allow the numerous :) readers not to spend too many times waiting for the following without nothing to make therefore. So, in spite of all, the rhythm is too slow for you, you will always write some articles for the Toxic Mag that misses a little volunteers these days. The topic is always therefore free don't hesitate... I would want to also specify that this initiation aims to create programs no-GEM therefore functions of the GFA dedicate to the GEM won't be landed.

Good, let's spend to the serious things.

I - The most useful instructions.

Some among you won't have, I think, not need to read this part entirely but I counsel you to browse it all the same in the event that some points would either have escaped you if you had taken bad habits. This part is long and little attractive for beginners but don't let rebuff you if you don't keep all, stop and go to throw a squint to the joined example programs. They will permit you maybe to give you account of the instruction utilization of which you will read the description better and he/it is true that nothing replaces a concrete example.

Let's see types of variables used not the GFA first or in all cases most useful.

1) types of variables.

In certain languages evolved (as the C for example) he/it is indispensable to declare the type of them variables before using them. This is not the case in GFA but it doesn't have that of advantages: indeed he/it is more tempting to use a big number of variables without worrying about that than they become after utilization. It is one of mistakes that we are going to try to avoid but us in sums not again there: let's begin by learning to not to waste.

Most them variables are numbers and one can give them the name that one wants. If I write " a=10 " at the time of the execution, her variable " a " will be worth 10 but I will have just as can call it " var " or " tartenpion " if I had wanted, it is necessary to use the same name rightly when one reuses it later.

One gave the value 10 therefore to " a " and there I say " Stop " not that me decide to deprive you of initiation to the GFA to protest against raising of them cucumber of sea in battery but her variable " a " is for the GFA a variable to comma and has a precision of 11 numbers what is a beautiful waste for a variable that only uses 2 of them and that is a whole. It is necessary to specify to the GFA that one wants therefore that this variable has another type:

" a| " seems me perfect here because the " | " indicates that this variable will be coded on an octet and that she/it will be able to take the understood whole values therefore between 0 and 255. For 10 it is therefore the ideal type.

If one foresees that her submissive variable to additions, subtractions, multiplications and other tortures that you will inflict him will evolve and will become negative or will pass 255, the coding on an octet that corresponds to the suffix " | " won't be more possible and you will be facing one message of mistake. One will use the suffix " & " that indicates a coded variable on two octets (a word as one says). Her variable will be therefore " a&" (or "tartenpion&"). Attention however to not to change a suffix during the program bus for the GFA " a ", " a| " and " a& " are three variable very distinct. You can use therefore of them variables whose names only defer by their suffix but it is a perilous exercise because the bug arrived quickly. One looks for then during 1 hour to finally realize that one has put " | " instead of " & "... Them coded variables on 2 octets can to take the whole values understood between -32768 and +32767.

In short if your value must pass these values use the suffix "%" who indicates a coded variable on 4 octets (long word) The value can to vary -2147483648 to +2147483647... that let you of the margin. A problem yet puts itself when one wants to use a number to comma... in this case one will use the type of variable seen in the beginning: without suffix.

One saw 4 types of variables encoded correspondent to suffixes therefore following: not of suffix, " | ", " & " and " % ".

He/it exists other types of variables: texts and a type a few particular of encoded variable: the booleans.

One uses the suffix " $ " for the variable texts. One can write for example: t$= " I like the Toxic Mag " and the variable " t$ " will contain it chain of characters entrance in inverted commas. Them variables containing chains of character are particular to handle but we will see it later.

In short the variable booleans have for suffix "! and are coded on only one bit. They can take therefore that two values, 0 or -1, in GFA one uses TRUE or FALSE (true or false, what). Their interest can appear limited you but they are sometimes very useful in certain cases.

2) the good habits.

To know types of variables permits to avoid to clutter the RAM: even if to put " & " instead of " % " makes only win 2 octets that is still that of taken and the speed of execution will be (for most operations) bigger. Don't hesitate then, when it is possible, to use the suffix.

Again to save the RAM, don't forget to erase your variables. Use for it the instruction follow-up CLR of the name of her variable to erase (without forgetting his/her/its suffix). It doesn't have in fact a primordial importance for them numeric variables that don't take immensely of room (but he/it is better to make it nevertheless, it is always that of taken). On the other hand it is very important to erase the variables text because chains of characters that they contain can go until 32768 octets! To that train, forgotten some chains and the free RAM decreased half...

3) basis instructions.

This part can also be pass by those that already have a certain experience of the GFA but verify nevertheless that you know all instructions that are described there.

- a - conditions.

They are essential and serve without stop. Here is the syntax:

IF condition

If the condition is verified, the part of the programme " thing " situated between instructions " IF condition " and " ENDIF " will be executed otherwise one will spend directly to the instruction according to the ENDIF without passing by the slot departure and to win 20 000 FS (ouh her I get lost... :) One will spend to this instruction without executing the block of instructions thing.

He/it exists a variant to this syntax:

IF condition

Here one added a " ELSE " (otherwise). Bidule will be executed if her condition is verified otherwise one will execute thing.

Conditions can be very various but they are often of the following shape: IF var=n. Var is an any variable (who would have been able very well to have a suffix) and n a number. One will have things therefore as:

IF a=3.4
IF v&=-16
IF a%=76348
IF key$= " frqs "
or then
IF test!=TRUE

One can also combine several conditions by the AND or OR.

IF condition1 AND condition2

In this case, thing will only be executed if the 2 conditions (the condition1 AND the condition2) are verified.

IF condition1 OR condition2

In this case, thing will be executed at least one of the 2 conditions so is verified.

One can put several conditions thus to the following separated by the AND or of them HOWEVER (one can put some more that 2 if it is necessary). Attention however to not to abuse some AND because the execution of a YEW including a lot of AND can be sometimes very long, is worth better in this case to combine the YEW as follows:

IF condition1
  IF condition2

That makes the same faster thing precisely.

It is always there a little difficult of himself to recover in conditions to the beginning but that comes very quickly.

- b - buckles.

Buckles are an element essential of the basic language and it exists several types of it:


This buckle is executed indefinitely: when the computer did the last instruction before LOOP, it comes back to DO and execute the instruction that follows. One can come out of this buckle with the instructions EXIT IF or GOTO. EXIT IF is not a condition as the one that one saw previously: one doesn't put not of block of instructions to execute if the condition is nor verified of ENDIF to mark the end, but if the condition is satisfied, the execution of it buckle will stop and the instruction according to the LOOP will be executed. One can have for example:


The GOTO instruction indicates that the execution must not continue linearly but that one must spend directly to a place marked not a stamp. Example:

  IF t!= TRUE
    GOTO mk

Here one executes the buckle until t!=TRUE then one passes directly to bidule without executing thing (because stamp mk is situated rightly before bidule).

One can come again out of a buckle DO LOOP with a UNTIL. The buckle is executed until the condition according to the UNTIL is satisfied. The first example is equivalent to:


One curls until t! either true.

Let's spend to the buckle FOR NEXT that is one of most useful now and whose syntax is the following:

FOR var=a TO b STEP c
NEXT var

It is a finished buckle that will only be executed a certain number of time. To the departure of the buckle, var " will be worth " has ", to every time that one will arrive to the next one will add " c " to " var " (c " can be positive or negative) then one réexécutera curls it and when var either passes equal the c " value " curls it ends.

Most the time one uses some buckles FOR NEXT without the parameter " STEP c " therefore the " step " is by default 1 and one will add 1 to " var " to every time that one will meet NEXT var. The following buckle will be executed in all 16 times (attention not to forget that she/it begins to 0)

FOR a&=0 TO 15
NEXT has &

Attention: The GFA seems to have some problems with the FOR buckles NEXT when her variable is coded on an octet (sufixe " |) and the negative STEP even though it variable always remains positive.

The utilization of FOR NEXT is especially advantageous because it permits to make buckles with a number finished of iterations on the one hand and of others part to have a parameter that can be used in the block of instructions contained in the buckle. Indeed one can use the value of her variable (has & in the previous example) to make calculations. Attention however not to modify the value of has & in the buckle because otherwise the meter will be disrupted, the number of stages won't be anymore the one wanted, etc.

He/it exists other instructions permitting to make buckles but they don't bring anything besides that those described above therefore I would not land them here. If he/it happens to me to use them in a program of example, I will annotate then to explain you their effect.

- c - communications with the user.

The peripherals as the keyboard and the mouse permit to communicate with the user, some instructions in GFA permit to recover information coming from these peripherals.

- The keyboard

The INKEY$ instruction sends back the pushed key just as she/it is executed. It is necessary to stock this value in a variable of the same type than her therefore a variable with the sufixe " $ ". If one makes a$=INKEY$, one will have in " a$ " the key pushed to the keyboard to the moment or the instruction has been executed. So no key one was not driven will have " a$ ", either one empty chain. Therefore if one wants to wait that a key is pushed one makes:


One curls indefinitely until the value sent back by INKEY$ either different of the empty character chain. It exists another instruction permitting to make the same thing but of manner more " system " it is ~INP(2). The " ~ " is an equivalent of " VOID " in old versions of the GFA and indicates that the sent back value must not be memorized. The interest of ~INP(2) is to be shorter to hit and clutter less the code.

It exists other instructions permitting to test the special keys notably again as arrows, function keys (F1 to F10) and the SHIFT keys, CONTROL, ALTERNATE and another one but us them will see not today.

- The mouse

He/it exists 3 instructions to manage the mouse:

MOUSEX indicates the abscissa of the plointeur to the screen
MOUSEY his/her/its neat
MOUSEK the state of buttons

For example, in ST Low, MOUSEX can vary 0 to 319 and MOUSEY of 0 to 199. Whatever is the resolution, MOUSEK can take 4 values:

0: pushed no button
1: pushed left button, lax right,
2: pushed lax, right left button
3: pushed left button, right pushed

One can ask to hide the pointeur of the mouse while using the HIDEM instruction and it doesn't affect results of instructions of test of the mouse: the arrow is hidden but the mouse still functions.

- The joystick

One can test the state of the shooting button with the instruction STRIG(1) that sends back TRUE (-1 in decimal) if he/it is driven and FALSE (0) if this is not not the case. The state of the button is coded therefore on only one bit so the variables in " ! " are adapted to stock it.

The direction of the handle is given by STICK(1). One gets:

High: 1 high-left: 5 center: 0
Low: 2 low-left: 6
Left: 4 high-right: 9
Right: 8 low-right: 10

Values of the direction of the handle go therefore of 0 to 10 the variables coded on an octet (|) agree best to stock the result of the test.

The utilization of these two instructions has an inconvenience: they oblige to change the interruption keyboard therefore prevents the management of the mouse. Once tests of the joy finished it is necessary to restore the management of the mouse while asking for example for a test button with MOUSEK.

- d - The management of the variables.

Let's begin by seeing an indispensable instruction even for programs that don't use the GEM, nor the melting system: PRINT this instruction permits to display to the screen a chain of character. She/it is indispensable because she/it is very convenient to control so, for example, one of your routine functions well. Since the beginning of this initiation did we see indeed, to use how of them variable but not how to write the résulat then to the screen how to be on that we didn't make a mistake if we don't have means to control the result? won't The instruction be certainly more present in the final versions of your programs but it is useful at the time of their development. See therefore how functions this instruction.


He/it is sufficient in fact to write follow-up PRINT of the name of her variable that one wants to make appear. If it is a chain of characters ($) she/it will write down herself/itself to the screen. If it is a coded number on an octet (|), a word (&), a long (%) or a number with a comma, it will write down itself under its decimal shape or in engineer notation if it is too big or too near of 0. If it is one boolean ("!) it will write down itself -1 (it corresponds to TRUE) or 0 (it corresponds to FALSE).

If several PRINT are asked for data will show off while spending to the line to every time. One can ask nevertheless that they show off to the particular places of the screen thanks to AT:

PRINT AT(8,5);var

This instruction will write down var while beginning to the 8th character of the 5th line. In ST Low one has 25 lines and 40 characters by line (one also says 40 columns), on ST Medium 25 lines, 80 columns, etc.

One can ask to write several chains while doing on the same line to follow PRINT of several variable or chains of characters separated by commas (to pass a big space between each) or of point-commas (not to pass a space).

As one already saw previously him, he/it is not necessary to declare variables to use them in GFA, on the other hand he/it is preferable to erase them with CLR, once you finished to use them. One will write therefore:

CLR var

or again, to erase several of them at a time:

CLR var,a&,compteur%,mem&,test!,ch $

(evidently names of variables used are only here of examples)

It is especially important to erase chains of characters because it is the type of variable that takes the more of memory in general.

One can also define pictures " that permit to manage easily a big number of variables. Let's imagine that one needs to stock 6 scores for hiscoreses of a game, one could use score1 &, score2 &,... but it would not be convenient to manage, one would use therefore:

DIM score&(6)

One defines a picture that will contain 6 values. The 6 variable so defined will be: score&(0), score&(1),..., score&(6). It permits to facilitate some operations notably, let's try to display them:

FOR i|=0 to 5
  PRINT AT(1,i|+1);score&(i |)
NEXT i |

Here one displays every score while spending to the line to every time. i | serves parameter in the AT (one adds +1 because the line 0 doesn't exist) and for the selection of it variable to display. This example shows the interest of them well buckles FOR NEXT and the one of pictures.

One can also define pictures to 2 or 3 measurements that in some cases can prove to be useful:

DIM a%(10,5)

Here one has picture to 2 measurements with 10*5, therefore in all 50 variable:

a%(0,0),... ,a%(0,4)
a%(1,0),... ,a%(1,4)
a%(9,0),... ,a%(9,4)

One is able well on to create pictures with doesn't import what types of variable, on the other hand the manner to erase them of the memory is different: one uses ERASE for example:

ERASE score&()

It is indispensable to erase pictures because if one wants to resize a picture of the same name (with a different size or no) whereas him in exist an already the program will bomb.

- e - Operations on the RAM and loading files.

In the beginning of a program one can book the memory for them variable.


The size will depend on the type of program: if you intend to only use some variables he/it is useless to reserve a lot, on the other hand, if your program will use of numerous variable and of long chains of characters, it is worth to reserve better more. Beware nevertheless to not to stock all variables and chains of characters as because it will oblige you to increase the RESERVED exaggeratedly and it will put you can be problem because this part of the RAM is not more usable even if you erase a big part of your variables under program. You will be therefore nearly géné by a zone empty but that he/it will be you impossible to allocate for another use.

In programs evolved he/it frequently arrives that one has need of to create a " buffer " containing some information. A buffer is one zone of memory that one allocates to stock information (results of precalculations, graphics, etc). The syntax is the following.


size% is the size of the block of RAM that you want to allocate. After the execution of this instruction, buf% will contain the address of beginning of the zone memory allocated 0 either if a mistake occurred. He/it wants better still to verify that the allowance functioned well because if one writes to the address 0... That bombs ! There are 2 main reasons of mistakes when one makes a MALLOC: either you ask not to allocate more RAM than he in free remainder (or there are not more of buffer of the size indicated in only one block: the RAM is broken up) or he/it arrives that you asked for the MALLOCS in too big number: indeed the number of zones memory allocated is limited therefore it is worth to allocate a few big buffers better that of about ten kids.

At the time of the creation of a program one often has need of dated (music, graphics, etc.). To stock them one has two solutions in GFA: either to load them in INLINE load them with the BLOAD. The two methods can have their advantages but see first how to use them.

INLINE truc%,taille

thing% will be the address to which will be situated in RAM the file in question and instead size you must write down the size of the file. When you hit this line in GFA it is necessary to come back then over and to push then on the Help key to click on Load and to select the file that you want to charge in INLINE. Thereafter the file will be included in the GFA source and protected at the same time as it in only one file.

ATENTION: If you modify zones of memory or are loaded files of inlines (here from the address thing%) they are not restored while returning to the publisher therefore if you protect thereafter, the modification will be recorded also.

One can also use the BLOAD instruction:

BLOAD "c:\092fichier.ext",buf%

The syntax is therefore in inverted commas then the path and the name of the file the address of the zone in RAM in it what it is necessary to load it. It is very important to pay attention that the zone in which you load the file is big enough because otherwise a part of the RAM no allocated will be crushed what the most often provokes a plantage. Therefore to load a file one can use a MALLOC and a BLOAD:

BLOAD " c:\092fichier.ext",buf%

As I told it the MALLOC+BLOAD methods and the INLINE have all two their advantages and their inconveniences to use a file of dates.

The principal favors the INLINE is that the file is inserted in the source and when one compiles it, him executable gotten won't have to load files without stop. His/her/its main inconvenience is that the loaded file size must not pass 32768 octets, that that is sometimes not sufficient. Besides the memory used for the INLINE cannot be restore to the system therefore under program even though a INLINE already served us and that one doesn't need his/her/its content anymore he is impossible to allocate this part of the RAM all over again.

The MALLOC+BLOAD is all the same more advantageous, even though him he obliges to load the file from a reader (disk, hard drive, etc.).

One can also modify information stocked in RAM thanks to the BYTE, WORD and LONG:

BYTE{adr%} =48

Here one places the value 48 in the octet whose address is adr%. One can make the same thing with on words or them long while using WORD respectively and LONG. The address must be between accolades and not in brackets. If you try to stock a value that cannot be coded on the chosen size (for example 15740 on an octet) your program won't function. In short on ST addresses of WORD must be they multiples of 2 and those of LONG of mulipleses of 4 then if these conditions are not filled you will have the right to 2 pretty bombs... ;)

It is also possible to extract information of the RAM thanks to these instructions and to stock them in them variables:


In short he/it exists an instruction permitting to copy a part of the RAM to another.

BMOVE source%,destination%,taille

source% is the address from which one is going to copy, destination% is the address of beginning of the zone where one is going to copy, and size is the size that one is going to copy. Here again attention not to copy to a place that has not been allocated before. This instruction is especially useful as soon as one makes programs evolved.

- f - The calculation.

He/it exists numerous instructions in GFA to do calculations on them variables and their utilization is intuitive enough but I go all of even to give you a fast preview of it.

To do of them sum, subtractions, multiplications and divisions one uses the usual signs (" + " for the addition, " - " for the multiplication, " * " for the multiplication, " / " for the division and " ^ " for the strength as well as them parenthesis to indicate the order of priority of them operation when she/it is not obvious)


If one works exclusively on them whole he/it is preferable to use ADD (for the addition), SUB (for the soustracion), MUL (for the multiplication) and DIV (good I believe that you understood;). The syntax for the previous calculation becomes then:

v& = MUL(ADD(10,3),(148 DIVS 2))

SUB functions with the same syntax that ADD, the only instruction with a particular syntax is DIV.

To already modify a variable existing one can make:


(or to use all other described above operations)

He/it also exists another syntax to modify a variable but that doesn't permit to make that only one operation:

ADD a&,4
SUB a&,4

Here one adds subtracts 4 either to has & (one could have put a variable instead the 4).

In short INC and DEC permit to either add to entrench 1 to her variable respectively:

INC a& (or DEC a&)

The only interest of the ADD instructions, SUB, MUL, DIV, INC and DEC is that they are faster than the classic operations but her restriction is that they treat some whole numbers solely.

The usual functions also exist in GFA:

SIN(a) (where has is an angle in radian)
SINQ(a) (where has is an angle in degree)

I believe that we saw instruction sufficiently can begin to code. We will see some of others with the progression of them programs.

II - The first programs.

All programs describe are here present in an archive. They are not present here because they would clutter the TOXIC for nothing, he/it was better to put them under an executable shape. Besides they are annotated sufficiently so that you can understand them without difficulties.

FIRST.GFA: an example that shows you to use some of instructions described in the initiation how and that contains some as some some in addition (with explanations evidently).

CALC.GFA: an example of buckle FOR NEXT and the different methods of incrémentation with a comparative of instruction speed.

One spends to the more serious things then: AFF_ECR1.GFA display a picture PI1.

AFF_ECR2.GFA display a picture while doing a vertical scrolling.

In these two last program you can change the picture easily displayed while loading another picture PI1 in the inline (the inline doesn't make that 32034 octets but the 32 octets won't be in addition simply charged and won't crush anything. Here, these last octets don't serve therefore why them to charge?

Here is a few explanation about the last two examples:

III - The memory video and them associated feature systems.

The structure of the memory video on ATARI is under shape of plans but I won't explain how it functions this time because it doesn't serve in examples.

In ST Low (320*200, 16 colors) a screen takes 32000 octets (it needs to 4 bits to code the worth of the color of every pixel (because 4 bits permit to code values of 0 to 15) and there are 320*200=64000 pixels therefore in all 64000*4=256000 bits is 32000 octets). A line makes 320 pixels therefore represents in memory 320*4=1280 bits is 160 octets. These information will serve us without stop and notably in the two files of example of picture display.

The screen is characterized by his/her/its resolution and his/her/its number of color. The ST is foreseen to have a duplicate screen, that is to say that in addition of the part of the corresponding RAM to the displayed screen (the physical screen), it exists another part of the RAM that contains the logical screen. The interest is that while the machine modifies the logical screen (that it " draws " if one can say) it doesn't see himself and one only displays when it finished. Of this manner, one doesn't see of things to draw " itself/themselves gradually " to the screen, but she/it appears suddenly. Even when he/it is very fast, the redessin sometimes appears then by an unpleasant flicker this so-called technique of the " screen swapping " is indispensable.

A function system permits to choose addresses of the screens physics and logical (as well as the resolution): XBIOS 5. In GFA the syntax is the following:

~XBIOS(5,L:adr_log%,L:adr_phys%,W:res &)

The first number indicates that it is a XBIOS 5, the " L: " indicate that the variable that follows must be transmitted under shape of a LONG (and under shape of a WORD for the " W: "). The first parameter is the address of beginning of the part of RAM that one wants to define new logical screen how, the second is identical but for the physical screen and the third permits to modify the resolution (0 for ST LOW, 1 for ST MEDIUM, etc.). The tilde (~) before the function indicates that the value sent back by the machine won't be preserved: in most cases it is useless for a XBIOS 5 because the machine is content with to send back -1 in cases of failure and 0 otherwise (it seems to me). If a parameter is put to -1 it means that this one won't be modified.

There is an important thing to know on ST: addresses of screens must be therefore they multiples of 256 it is necessary to transform the address when one makes a MALLOC because one doesn't necessarily get a multiple of 256. The method to modify the address is explained in examples.

He/it is important that a program let the system as he/it was before the execution when one leaves it therefore it is necessary to provide to restore the old addresses screen, the resolution and the palette for example.

He/it is easy to restore the addresses screen: indeed he/it exists two XBIOS functions (XBIOS(2) and XBIOS(3)) that send back these addresses therefore it is necessary, in beginning of program, to stock them in them variables and them, to restore in end of program with a XBIOS 5. One proceeds thus:

old_phys%=XBIOS(2)      (XBIOS(2) sends back the address of screen phys)
old_log%=XBIOS(3)       (XBIOS(3) the one of the logical screen).
... Here is the body of the program...

For the resolution one uses the function XBIOS(4) but the problem is that other resolutions have been added on the Falcon and the TT, therefore on these machines this function is not sufficient to restore the resolution. We will see to make how on these machines another time, let's satisfy us to restore the resolution on ST

... Here is the body of the programme...
~XIOBS(5,L:-1,L:-1,W:rez &)

Evidently one can restore screens and the resolution in only one XBIOS 5.

The palette is complicated to restore more because it is necessary to be going to look for directly in RAM (in fact it exists a XBIOS function but I don't appreciate him not because her fair once on 2 if there is a small thing that doesn't please him). In ST Low, the palette is situated to the address $FF8240 but it is necessary to pass in fashion supervisor to reach there (see examples to know how to pass the fashion user how to the fashion supervisor and reciprocally). Once one is in supervisor mode, he/it is sufficient to copy the 32 octets (a palette of 16 colors makes 32 octets) of the palette in a buffer allocated beforehand then in end of program to pass all over again in supervisor and to copy the content of the buffer in $FF8240 (one puts back what one had seen in beginning of program in fact).

To part to restore this palette, the function XBIOS 6 is more appropriated (except if you have really need of speed). When you want to change the palette, use the following syntax:


pal% is the address or are the 32 octets of the palette that you want to install.

In short as one told it in a little while, it is necessary to redraw on the screen logical then to display him (in fact the physical screen becomes logical and vice versa) but to be able to display him it is necessary to wait that the spotlight came back in loud on the left of the screen (phosphoruses of the screen are hit by a bundle of electrons that browses every line then passes to her following, the place where it is in given one instant is the spotlight). It is what one calls the VBL. If one doesn't wait for the VBL, the new, screen will only be displayed in part: during a VBL, the superior part of the screen will display the old screen and the bottom part the new... Therefore it is necessary to wait for the VBL. The VSYNC function permits the to make in GFA but, seen his/her/its efficiency, he/it is worth to use the address memory of the VBL meter better ($466). It is necessary to be in fashion supervisor to use this address. To see if one passes the VBL, it is necessary to have his/her/its value and to wait that she/it changes, when she/it changed, it is that one passed to the following VBL. The syntax is the following:

UNTIL l%<>LONG{&H466}

In fact one stocks a value in l% (or an another one variable) then one curls until the meter is different of the stocked value.

To make a swapping of screen one uses the following method therefore:

DO (beginning of the buckle)
  ... one redraws the screen as one wants...
  UNTIL l%\060\062LONG{&H466}
  SWAP ecran1%,ecran2%

To every picture one waits for the VBL, one makes a SWAP (one exchanges between them values of two screen addresses) then one makes a XBIOS 5 so that the change is taken in account.

Well, it is all for this issue. I hope that I was clear enough but if this is not the case don't hesitate to contact me by promenade. You can as to send me your programs to wonder my opinion or possibly why they don't run...

Some among will have you maybe a little pain to understand why the example 2 of display makes a vertical scrolling but it is only a question of logic, if indeed you understand so-called-the-I and I won't more clearly explain how that works.

To the next time for a new shutter of this initiation in the next Toxic Mag, as waiting, code well!

Exyl / SECTOR ONE --- ---

Edito Rubriques habituelles Planè Atari Internet Techniques et programmation Interviews Jeux Vidéo Humour Musique Chroniques, etc. Divers