THE ST NEWS MENU
A TALE OF GFA PROGRAMMING AND LITTLE HAMSTERS
by Stefan Posthuma
The world must be a wonderful place for a 10-day old hamster.
Full of wonderful smells, incredible food and endless stretches
of enormous cage to explore.
About four weeks ago, I caught my two hamsters in the act so to
speak, I hurried to separate the two sinners but time told me I
was too late. The little black hamster (Nephilim is her name)
swelled to about twice her size and one dark night I came home
and heard some infinately tiny noise coming from the little house
Nephilim lives in. So I lured the hamster from her house with a
piece of apple and peeked inside.
There they were, seven little pink creatures, squirming around,
making tiny noises as they called for the sweet nipples of mama.
I quickly replaced the lid of the little house and a very worried
mother returned and lay herself down for her siblings to suckle
That night I also sat down at my ST and got an idea. Actually it
was something that lingered in my mind for a long time and I
finally decided to do something about it after receiving some
Email (my address: email@example.com) from Lord Hackbear telling me
how easy it was to hack the hidden articles in the previous
issues of ST NEWS.
I wanted to write my own drop-down menus in GfA. This would
solve a few problems, first of all I wouldn't be plagued by the
bug in TOS 1.0 that causes GEM to crash when a menu is too large.
Also, I wanted to do cascading menus (when you highligh an item
in a dropdown, another menu pops up besides it (I always found
this a shortcoming in GEM). This would elmiminate the need for
the silly submenus (remember 'Non computer stuff' and 'DeltaForce
ICCC#2' in 6.2). And last but not least, it would enhance the
control I had over the menus, allowing a lot more nice ways of
getting to hidden articles.
But before I started programming, I did some serious thinking,
how exactly would I go about writing something like this?
Meanwhile, the baby hamsters grew and grew, and soon they
started to get hair on their little bodies and I was able to see
what kind of color they would become. Now I was very curious for
the mother is pitch black (brought with me from the Respectables
Pet Store in Trier, Germany) and the father (Natanga, the big
dopey hamster) is a traditional white-and-gold hamster.
It turned out to be hamsters all shades from black to golden,
some of them grey with streaks of white and others dark brown
with white and golden patches. Every night when I came home I
checked on them, careful not to touch them for the strange smell
would surely excite mother too much. In fact, when a hamster has
young and it is disturbed too much, it will eat them in despair.
Pretty cruel huh?
The next weekend I sat down again and did it. But before I did
the programming, I first decided how I would handle multiple
resolutions, for ST NEWS has to work both in Monochrome as in
The solution I came up with is quite nifty and will work on all
resolutions, and all screen sizes.
What I did is, I based my screen coordinate handlers totally on
the size of the used font. One of the first things I do in
ST NEWS is checking Xbios(4) and setting some variables first:
fw% width of the font in pixels (8 in all ST resolutions)
fh% heigth of the font in pixels (8 in low/med, 16 in high)
fc% correction value (1 in low/med, 2 in high)
font% font number for GEM (DEFTEXT ,,,font%)
sw% width of screen in pixels
sh% heigth of screen in pixels
All of these are clear I suppose except the correction value.
This one is used to get the y coordinate to put text. If I draw a
box at 100,100 and I want a line of text directly below the top
of it, the y coordinate of the font will be 100+fh%-fc%.
I set these variables in a SELECT Xbios(4) statement, but real
programmers probably retrieve them from the Line A information
So if I want to draw a box that has to contain 3 lines of text
and that must be 20 characters wide, the statement will be:
You probably want to adjust these values with two or something
to make sure the edges of the box don't touch the text and make
it look not too splendid. If you program carefully, and make
sure you consequently use this method, it will work on all
resolutions. I entirely wrote the menu routines in high res, and
it worked in medium as well as in low without modifying a single
After about 10 days, the little ones are big enough to walk, and
you should see the little adorable creatures try and find their
way around the cage. Their eyes are still shut, so they have to
navigate by touch and smell. I can sit there for hours and watch
one of the tiny hamsters try and pick up a peanut the size of its
head. It will take it in its little mouth and try to walk, sway
dangerously and finally fall over, little legs sprawling, but
still holding on to the peanut as its life depends on it. Now
Nephilim has created a little food supply just outside the house
and sometimes the entire family comes out to eat. I was surprised
to see these small hamsters already put things in their pouches
and try to wash themselves (This requires sitting on their hind
legs, something they haven't mastered yet and they fall over
quite comically). Also, you should see the feasts they have over
an apple core or a sweetcorn that I have partially eaten.
After a while, mother decides that they've had enough and starts
carrying her children to the house one by one. You can almost see
the frustration on her face when she brings one to the house, and
turns around to get another one, it is already crawling out of
the house again, ready for more adventures.
So I resolved the resoltion program, on with the actual menu
programming. Now I feared that one of the drawbacks of the new
system would be the speed. If the program had to draw the menus
every time they would be selected, it would be way too slow. So I
decided I would GET a menu after it was drawn the first time, and
the next time it was selected, I would simply PUT it on the
screen, and with a blitter or a fast screen handler installed
this would be nice and fast. Drawback of this is that it costs
memory, so the program first checks to see that there is enough
memory free. (about 32K should be enough)
Then there is the issue of reading the menu items. How do you
make it so that you can specify the entries to be put in the menu
in an easy way? Well, in Basic we use the DATA statements of
course, with menu items and some kind of identifiers following
them to tell us what kind of item we are dealing with.
But we also need to know exactly which item was selected, so we
need a number that is returned by the menu routine. But then
again, a special item like a title or a separator cannot be
selected, so why not combine the two into one number? Great. Now
I think it is safe to assume that nobody is insane enough to make
a menu with more that 1,000 items so numbers >= 1000 are special
controllers indicating special items. An example:
DATA Menu 1, 1000
DATA Item 1, 1
DATA Item 2, 2
DATA - NICE -,1003
DATA Another item,3
DATA Menu 2,1000
DATA It's not easy,5
DATA To think of,6
DATA Random menu items,7
This would create a menu with two dropdowns, labeled "Menu 1"
and "Menu 2" (original huh?). "Menu 1" would have a submenu
(cascading), specified at the end. The number following the item
has three functions, depending on the value:
x < 0 : call cacading menu -x
0 < x < 999 : normal item, returns x when selected
> 999 : 1000 = dropdown title
1001 = non-selectable item (separator)
1002 = end of menu specification
1003 = submenu (cascade) following
The only tricky thing about this is the cascading menus. I
needed a way to refer to them in an easy way, without special
names or something. So I number them in order of appearance, and
use that number (negative that is) to call them. So if there was
another submenu following the one above, it would be called with
'-2' as number behind the calling item. This also implies that
submenus can be called from within submenus. Pretty neat, but
quite nasty to program, we come to that later.
Time prevents me from finishing this article so we have to call
this part I and we shall see about part II, most probably in
ST NEWS 7.2...
You can find the complete source in the PROGRAMS folder. GfA
Basic .LST file that is.
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.