COURS209.TXT

Languages:

English  • français

   ******************************************************************
   *                                                                *
   *               68000 ASSEMBLER COURSE ON ATARI ST               *
   *                                                                *
   *                      by The Ferocious Rabbit (from 44E)        *
   *                                                                *
   *                           Second series                        *
   *                                                                *
   *                         Lesson number 9                        *
   ******************************************************************

   This little course will be a bit special, because it will provide 
   directions on how to create GEM programs that work correctly. 

   There are indeed a few "tricks" to follow. On MAC, programmers
   have access to books about software ergonomics. What is that? Well,
   it's simply a set of rules to follow so that the user is not lost
   from one program to another. Indeed, it's important to remember that
   you are a programmer and that your work will be used by users! Let's
   think a bit: what does a user look for in a drawing program:

   1) having a file save with a special compression algorithm that 
   compresses more than the others.

   2) being able to retrieve drawings as easily as possible in other 
   software.

   It seems obvious that the second solution is the right one!
   Yet we are witnessing a proliferation of file formats, all more stupid 
   than each other! Ah, of course, the file compressed with the drawing 
   software Bidulmuche is smaller than the file from Degas, but it is 
   recognized by no one! Why seek to impress the gallery with new 
   formats? Why not load and save in PI1, PI2, PI3, PC1, PC2, PC3 and 
   that's it? First rule: therefore, think of the user and don't look 
   for twisted tricks! The first menu is the copyright one, the second 
   one deals with files and, at the bottom, the Quit option. How annoying 
   to have to search for the Quit option at the end of a menu because 
   the programmer wanted to stand out!

   Additionally, by convention, menu entries that lead to dialogue 
   will be followed by 3 dots.

   Think about large screens and the TT!!!! When you poke into 
   documented system addresses, plan for 32-bit addressing. For example, 
   $FF8800 will work on ST but will crash on TT.
   It's indeed an invalid address if you try to use it in 32 bits 
   (with the 68030). So, you should use $FFFF8800 which will work on all 
   machines.

   Don't test the resolution with Xbios4! It's risky because, with a 
   large screen, you will receive anything! For the maximum opening of a 
   window, ask GEM for the size of the workstation (see the source with 
   the window). Need to do a block copy? Use Vro_cpy function, but if it's 
   a copy with the screen, there's a simple solution: you will have to 
   make an FDB (Form Definition Block) structure. It's a structure that 
   indicates the width of the work surface, its length, the number of 
   planes, etc... Instead of asking GEM for all the data, fill it with 
   0, and GEM will know by itself that you are talking about the screen, 
   and will manage on its own!

   For your accessories, test your resources in low resolution!
   An accessory, as the name suggests, must be minor, that is, 
   work without interfering with the rest of the machine: 
   Small size (a formatting accessory of 100Ko, ummm!!!).

   Only one resource file. This implies not using drawings and 
   building your resource with the SNAP option active in K_Resource. This 
   option allows the buttons to be well placed whatever the resolution of 
   use of the resource. If possible, place the resource inside of the 
   accessory by relocating it (see the accompanying relocation listing) 
   to avoid handling multiple files when moving accessories.

   Do not hesitate to put keyboard shortcuts in your resources.
   If you use K Resources you will see that there is access to unused 
   bits for the objects. Indeed, if we take, for example, the bits 
   defining the flags of the object, we realize that only bits 0 to 8 
   are used. However, the coding is done on a word, so we still have 7 
   free bits. These bits are left to the programmer to store what he 
   wants. As an indication, here is what I put in:

   Extended_type    scan code of the shortcut key for
                    this object.

   Extended_flag    Key(s) that must be pressed simultaneously to
                    make this shortcut valid.
                    Bit 15 -> Alternate
                    Bit 14 -> Control
                    Bit 13 -> Left Shift
                    Bit 12 -> Right Shift
                    Bit 11 and 10 -> position of underline.
                    (0=no underline, 1=underline the first
                    letter, etc...)

   Extended_state   Indication of the tune on one byte
                    associated with the selection of this object
                    0 no tune
                    1 ding
                    2-63 digits
                    64-127 Xbios(32)
                    128-190 sound in Gist format
                    191-255 music in Mad Max or Musexx format

   All this allows me to have keyboard shortcuts written IN
   the resource which allows for ultra-fast modifications. For 
   shortcuts, preferably use the Alternate key because its use with 
   another key does not generate any character. However, 6 keyboard 
   shortcuts use Control. They come from the MAC and tend to become 
   widespread. These shortcuts are used in forms with editable fields 
   (among other things) to do cut/paste between these fields.

   CONTROL X        | to cut (places in buffer by erasing
                    | beforehand)

   SHIFT CONTROL X  | to cut (add to the end of the buffer);

   CONTROL C and    | As with X except that in the case of X, the 
   SHIFT CONTROL C  | editable field is erased, whereas with C, it
                    | retains its content.

   CONTROL V        | pastes the contents of the buffer by erasing 
                    | the editable field beforehand.

   SHIFT CONTROL V  | the same but without erasing the editable field.

   Another note regarding forms with multiple editable entries: 
   I've noticed that users, out of habit, hit RETURN when they've 
   finished filling in a field, and often, the CANCEL button is 
   defaulted: pressing RETURN, therefore, exits the form!

   So, I decided to eliminate default buttons when there are editable 
   entries and manage RETURN differently, which then allows to move to 
   the next editable field (like TAB).

   I also added a few other keys. While with TAB, it is possible to move
   to the next editable field, I added Shift+TAB to go back to the 
   previous editable field. CLR HOME to return to the first editable field
   of the form. It would be possible to add UNDO.

   Rewriting a complete form management (taking as a starting point 
   an article from ST Mag which did that in GFA for example) is not 
   very hard. What is also nice is adding a small square in the top right, 
   to move the form.

   For all these options, you can, of course, do it your own way, but the 
   keyboard shortcuts I'm talking about are already a bit used. It's better 
   to continue so that the system becomes widespread, rather than trying to 
   stand out with inconvenient tricks.

   I will finish this chapter on GEM by inviting you to discover the 
   GEM Communication Protocol. To access it, unpack the PROTOCOL.AR file 
   with ARCHIVE.PRG. You place this file in ram_disk (for example D). You 
   prepare a blank diskette, you run Archive, you choose Unpack with 
   D:\PROTOCOL.AR and as destination A:\*.* and you wait.

   There are all the sources, the library, the doc, the examples etc...
   All your software must be compatible with this system if they want to 
   be trendy!!! It's easy and allows for quite fabulous deliriums!

   Happy GEM programming!!!!!

Back to ASM_Tutorial