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 thing ENDIF
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 bidule ELSE thing ENDIF
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.4or
IF v&=-16or
IF a%=76348or
IF key$= " frqs "or then
IF test!=TRUE
One can also combine several conditions by the AND or OR.
IF condition1 AND condition2 thing ENDIF
In this case, thing will only be executed if the 2 conditions (the condition1
AND the condition2) are verified.
IF condition1 OR condition2 thing ENDIF
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
thing
ENDIF
ENDIF
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:
DO ... LOOP
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:
DO thing EXIT IF t!=TRUE LOOP
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:
DO
thing
IF t!= TRUE
GOTO mk
ENDIF
LOOP
thing
mk:
bidule
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:
DO thing LOOP UNTIL t!=TRUE
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 thing 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 thing 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:
DO LOOP UNTIL INKEY$\060\062""
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.
PRINT var
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.
RESERVE size%
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.
buf%=MALLOC(taille%)
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:
buf%=MALLOC(taille) 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:
a&=WORD{adr%}.
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)
v=10+3*(148/2)
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:
v=v+5
(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) COS(a) COSQ(a) TAN(a) TANQ(a) LOG(a) etc.
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... . ~XBIOS(5,L:old_log%,L:old_phys%,W:-1)
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
rez&=XBIOS(4) . ... 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:
~XBIOS(6,L:pal%)
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:
l%=LONG{&H466}
REPEAT
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...
.
l%=LONG{&H466}
REPEAT
UNTIL l%\060\062LONG{&H466}
SWAP ecran1%,ecran2%
~XBIOS(5,L:ecran1%,L:ecran2%,W:-1)
LOOP
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!
|
|