COURS209.TXT
Jump to navigation
Jump to search
******************************************************************
* *
* 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