COURS208.TXT
****************************************************************** * * * 68000 ASSEMBLER COURSE ON ATARI ST * * * * by The Fierce Rabbit (from 44E) * * * * Second series * * * * Lesson number 8 * ******************************************************************
I hope you are not approaching this course immediately after having finished reading the previous one, but, on the contrary, you have plunged into line A with joy!
We are now going to approach a topic which, I must admit, scared me a bit at first: the GEM.
In fact, in programming as in many other subjects, one starts working simply when one is forced to. So I had only done very small things with the GEM in assembler, things like office accessories that allow you to put the screen in reverse video, with a choice in an alert box, before finding myself faced with the description of software that a Parisian company proposed to me. I must admit that the first days were a bit tough, but in the long run, I found that GEM is really a fabulous thing, not very hard to master, and the possibilities are more than sufficient to fill with joy any programmer worthy of the name!!! So I hope that you will take as much pleasure as me in programming under GEM once you have read this chapter.
First of all, the remarks that are at the beginning of the chapter on line A, deserve to be reread. So, look for documentation without worrying about the language. You will find in the last course of this series a bibliography in which I have tried to list various very nice articles.
GEM is accessible through TRAP #2, but in fact thanks to this trap we have access to several parts of the GEM, a bit like if the trap #1 at the same time led to GEMDOS and BIOS. GEM is, indeed, composed mainly of 2 parts:
AES and VDI.
VDI routines - VIRTUAL DEVICE INTERFACE - take care of graphics;
drawing of circles, ellipse, lines, rectangles etc...
On the other hand, the display of typical GEM objects:
windows, alert boxes
is performed by the AES - APPLICATION ENVIRONMENT SYSTEM -.
As you discover the VDI and AES functions you will realize their interaction.
The great advantage of this system can be explained simply: it seems obvious to everyone that outputting a drawing on a screen, a diskette or a printer, it's not the same thing.
WRONG! For the GEM it's the same!
In fact, one can say that you have to prepare your drawing and to
say "I am sending it." Where? Ah, there, it's as you wish because for the VDI
the screen,
the plotter,
the disk,
the printer
etc...
are just peripherals. It is enough to designate the peripheral of our choice and it does the job all alone!!!!
The only problem: the truly independent routines of the peripherals are found in GDOS - this name surely makes you shiver with fright...
-- Several programs at the same time? The principle of GEM is very attractive but must lead us to think a little bit about the potential mixing of data. In fact, even if it is not truly multitasking (to be multitasking consists in being able to run applications exactly at the same time, which is anyway impossible with a 68000) GEM, therefore, allows having several programs active at the same time, in this case a main program and 6 accessories. For GEM there is fundamentally no difference between a PRG and an ACC and, for this reason, in GEM vocabulary, we call them "applications". GEM can therefore find itself with managing 7 applications, each potentially having several windows. One can easily imagine the mess in memory!!!
-- How does GEM manage it?
At the launch of an application, it calls the AP- PL_INIT function (Application_Init). This function notifies GEM that our application wants to become active, and GEM responds by providing us with a number, the APP_ID (Application Identifier) which will now serve as a reference. Our application will therefore be for example number 3, and will be recognized as such by GEM. Attention, the APP_ID is only given to the application for the duration of its presence in memory. If I launch an ACC on Monday, it can inherit the APP_ID 4 but if I launch it again on Tuesday under different conditions, it can get the APP_ID 5. However, it will keep this APP_ID for all its activity.
When we open a window, it's the same principle. GEM provides what we call a HANDLE, that is to say, a number corresponding to the window. In fact, the HANDLE is the identification number of a window but potentially also of a device.
-- Multitasking?
One of the most important parts of GEM concerns the management of events. An event is an action from the user of the machine: mouse click, pressing a key etc... In fact, under GEM the applications spend most of their time waiting. Imagine a PRG with an open window and a dropdown menu, and at the same time in memory 3 accessories. I go to the accessories menu. The menu unfolds and the titles appear in reverse video when the mouse passes over them. All this is done by GEM, all alone like a big boy. I click on the title of accessory 2.
GEM detects the click, knows that I am in the accessories, looks at which entry I clicked on. As GEM assigned the entries to the ACCs, it sends a message to accessory 2 to tell it "you need to open up". So it opens up, and displays a window on the screen. So we have 2 windows at the same time. I click on the PRG's window, GEM looks to whom the window belongs and sends a message to the PRG to tell it "we have activated your window number XX" etc... So we are going to build in our GEM programs, a core of actions monitoring, and we will react according to these actions.
-- To call GEM functions.
Calls are made with parameters that we pass in arrays. As we use DEVPACK, we will use its library. Indeed, for calls to GEM, the parameters are numerous and to be placed in very specific places in the arrays. For these reasons, macros are very useful here. We will therefore call the GEM functions with the macros contained in the DEVPACK library. However, it is also necessary to know the arrays, in order to be able to perfectly understand the principle of operation.
For AES, 6 arrays are needed:
CONTROL, GLOBAL, INT_IN, INT_OUT, ADDR_IN, ADDR_OUT.
For VDI, 5 arrays are needed:
CONTRL, INTIN, INTOUT, PTSIN, PTSOUT.
Pay attention to the slight spelling difference between INT_IN and INTIN ! To indicate, during the call to GEM, where it will find these arrays, their addresses are placed in 2 lists:
One for AES: aes_params dc.l control, global, int_in, int_out, addr_in, addr_out and one for VDI: vdi_params dc.l contrl, intin, ptsin, intout, ptsout
Here are the arrays as they are defined in the DEVPACK GEM library:
control ds.w 5 global ds.w 14 int_in ds.w 16 int_out ds.w 7 addr_in ds.l 3 addr_out ds.l 1
contrl ds.w 1 contrl1 ds.w 1 contrl2 ds.w 1 contrl3 ds.w 1 contrl4 ds.w 1 contrl5 ds.w 1 contrl6 ds.w 1 contrl7 ds.w 1 contrl8 ds.w 1 contrl9 ds.w 1 contrl10 ds.w 1 contrl11 ds.w 1
intin ds.w 128 min 30 intout ds.w 128 min 45 ptsin ds.w 128 min 30 ptsout ds.w 128 min 12
You will notice the strange setup of the CONTRL arrays (array for VDI). Indeed it is often necessary to pass parameters 'by hand' into this array. With this system, it will be possible to perform an operation like MOVE.W #10,CONTRL2
Pay attention, this numbering of CONTRL corresponds to the number of words because each of the entries is defined by DS.W and not by DS.B!!! This is explained by the fact that 99% of the documents related to GEM are for 'C' and that is the type of command that is made in 'C'. Thus you will find often; "put 10 in contrl(2)"; you just have to do MOVE.W #10,CONTRL2 and it's done.
-- Why so many arrays? Because each of these arrays is meant to receive or to return a certain type of data. Let's see a quick description of these arrays.
AES Arrays
** control
Designed to contain, in order:
number of the function (.W), number of bytes of INT_IN (.W), number of bytes of INT_OUT (.W), number of long words of ADDR_IN (.W) number of long words of ADDR_OUT
** global This array is a bit special, and the explanations concerning it are of no use in the context of these courses. Once well absorbed the rest, you can always look into it, but currently, this would only confuse you! (See bibliography for more)
** int_in This array is intended to receive integer values (Integer In) that AES will need.
For example, a window number.
** int_out The opposite of the previous one, this array returns results, for example if you ask for the available surface for a window, you will have the dimensions here.
** addr_in List in which you can place addresses
** addr_out and here, you can read them! In fact, it suffices, like always, to read the name of the array to deduce what it contains!
VDI Arrays
** contrl In contrl0 we place the opcode of the function, as it is called its number.
In contrl1 we place the number of data that will be put in the INTIN array
In contrl2 we place the number of points (so pairs of data) that will be placed in the PTSIN array
In contrl3 we will place the sub-function identifier. For example, the drawing of circles, ellipses, rectangles etc... is done with function 11. A sub-code is therefore necessary to define which module within function 11 we wish to use.
In contrl6 we place the handle of the device. (see above) Starting from contrl7 there are sometimes pieces of information to pass, depending on the function.
** intin and ptsin We will then fill the INTIN array with the integer parameters required by the function and the PTSIN array with the coordinates required by the function. Once the function is called, we will retrieve:
in contrl2 the number of pairs of coordinates of ptsout and in contrl4 the number of words of intout.
Here is a call to GEM. This function displays a sentence where one wants on the screen, unlike Gemdos (9) which is limited to lines and text columns. Moreover, this function allows to display text with effects (bold, underline, etc...) with the font of our choice:
LEA MESSAGE,A1 address of the sentence
LEA INTIN,A0 receiving table
MOVEQ.L #0,D2 init the letter counter
HERE3 CLR.W D0
MOVE.B (A1)+,D0 takes in bytes
BEQ GO_ON end of the text
ADDQ.B #1,D2 we count the letters
MOVE.W D0,(A0)+ transfer to INTIN (in words)
BRA HERE
GO_ON MOVE.W #100,PTSIN X position
MOVE.W #150,PTSIN+2 Y position
MOVE.W D2,CONTRL3 number of letters
MOVE.W #1,CONTRL1
MOVE.W CURRENT_HANDLE,CONTRL6
MOVE.W #8,CONTRL opcode
MOVE.L #VDI_PARAMS,D1
MOVE.W #$73,D0
TRAP #2
AAAAAAAAAARRRRRRGGGLLL!!!!!! It's a horror, isn't it!
You must arm yourself with patience and dissect the multiple calls to GEM.
To help you with your tests, you will find enclosed a file named GEM. It contains the source of an ACC that displays an alert box, of a PRG that manages a resource (listing from WERCS) and of an accessory that manages a window. Regarding resource editors, I work with K Resource which is very nice and does not crash, unlike Wercs!
Try to understand the principle well: display an alert box with a single button, then with several, make small simple resources, then more and more complicated ones etc... The principle will always remain the same no matter how big your application is. Try to make small accessories such as disk formatters, with a small form that asks if you want to format disk A or B, simple or double-sided etc...
With these examples, you should be able to manage. That's how I started! Also take a look at the bibliography, there are some interesting things!
Back to ASM_Tutorial