Copy Link
Add to Bookmark
Report
Ictari Issue 39
ICTARI USER GROUP ISSUE 39 October 1996
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* m a g a z i n e *
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I C T A R I U S E R G R O U P
63 Woolsbridge Road, Ringwood, Hants, BH24 2LX Tel. 01425-474415
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
INDEX FOR ISSUE 39
==================
ASSEMBLY ST Assembly Language Workshop. Chapter 4.
Example of constructing a dialog box by hand.
C A mousetrap accessory (Squonk).
GFA Accessory communication protocol.
MISC Tanks game demo.
ANSI code text converter program.
In next months issue of ICTARI (this may change) :-
ASSEMBLY ST Assembly Language Workshop. Chapter 5.
C
GFA Text manipulation/search routines.
GFA VDI functions.
STOS
MISC Hypertext Markup Text Language - 2.0 Information.
----------------------------------------------------------------------
EDITORIAL
=========
C TUTORIAL
----------
This months installment has not turned up yet, hopefully next month.
ARTICLES
--------
We have got very little for next months disk so if anyone can
contribute something it would be a great help.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: *.*
From: Pete Bailey
I present here a small piece of code (see C folder) which, over the
course of the last few nights, has slowly but surely driven me
barking mad (although there are those who will claim that this is
nothing new). Now, the reason for its existence is this: last weekend
I spent a pleasant afternoon tidying up the hard drive on my Falcon
and trawling through old coverdisks looking for useful bits and
pieces. In the course of this exercise I found, sitting disabled in
the auto folder, a program called SAFEMENU (sorry but the author's
name escapes me for the moment; my apologies to him). I remembered
immediately that this was a menu-trapping routine (i.e. it makes the
menus pull-down rather than drop down), and since I have often felt a
pressing need for such a thing, I wondered why I'd stuck it in the
auto folder of the hard drive and then disabled it. Having re-
enabled the thing and rebooted, it all came flooding back to me. The
thing works for a few minutes, then deactivates. Going into the
relevant CPX in the control panel switches it back on, but having
to do that every two or three minutes soon wears thin. The problem
may be caused by a bug in the program, or it may be caused by
interference from other programs, or it may be a shareware
restriction for all I know and since I can't track down the
original, I can't even find out whether SAFEMENU *is* shareware,
but since I'm not using it I don't feel guilty.
Anyway, I decided on the spur of the moment to have a shot at
writing something similar myself. Now, I've tried this before some
years ago. On that occasion, I tried to sneak into the system at
packet-handler level and my efforts were a dismal failure. This
time, I decided to take the simplest, most obvious approach I could
think of; I would attempt to use the vex_butv and vex_motv VDI calls
to hook into the necessary vectors. I also decided to make the thing
an accessory (my previous attempt was an auto-folder program) so
that it could be switched on and off easily, and also so that I
could build into it the recommended fix for the double-scrolling
bug which afflicts later TOS versions.
So, what we have is a small C routine (compiled by SOZOBONX) which
does the outer-level stuff (initialisation, event loop etc) and two
small assembler routines which are installed into the mouse-movement
and button-change vectors via the VDI calls. Since I have no useful
documentation on these calls, I had to figure out empirically what
to do to achieve the desired result (where "empirically" means, of
course, by trial and error). To my astonishment, I actually
managed to write the thing and get it working in a single evening.
Furthermore, it works the way I feel comfortable with: click on a
menu title and down pops the menu, click an entry or click outside
the menu and away it goes. Or click and hold to select the entry
that's under the mouse pointer when you release the button - both
methods work. Of course, if you examine the code you'll probably
realise that this will cause problems for programs which use the
whole screen - painting programs etc - but since it can be
switched off easily when necessary, that isn't too great a
problem. The real fly in the ointment is this: it works like a
charm on the Falcon (where I developed it), but confuses the hell out
of my STFM!
On the face of it, it seems to me that the two TOSes (4.04 and 1.02
respectively) are handling their mouse-clicks in very different
ways. The Falcon seems to respond as soon as the button goes down,
whereas on the STFM nothing happens until the button goes up again.
I have tried every strategy I can think of, but I simply can't find
one which works reliably on the STFM, let alone one which works
consistently on both machines. Can anyone shed any light on this? I
only code assembler occasionally (to keep my hand in), but there must
be some experienced vector-snatcher out there who knows how to make
this work. I would also value opinions on the following
questions:
* Is this a sensible, safe method of tackling the job, or is
there some nasty, lurking problem which simply hasn't occurred to me
yet?
* Having played around with the program for a few nights, I've
found that it, too, suffers from the same problem of sudden
disablement as SAFEMENU (worse still, it refuses to re-enable
without a reboot). It seems to be caused by running particular
programs which, presumably, pinch the vectors back and don't
bother to restore mine. Or perhaps something is provoking Gem into
resetting the vectors. In any event, is this approach to menu-
trapping ever likely to work reliably, or is it as totally misguided
as I'm beginning to believe it to be?
* I know that, in an ideal world, I should be considering
XBRA'ing my vectored routines, but this is still a quick and
dirty piece of code at the moment. Is it worth losing sleep over?
* In Katherine Peel's book, (under vex_motv and vex_butv) she
mentions disabling interrupts. Does she mean while installing the
vectors, or for the duration of the vectored routines, or both? At
the moment, the program doesn't explicitly disable interrupts at all,
and so far it hasn't caused any problems (probably would if I jiggled
the mouse enough at a crucial moment).
* Ms Peel also suggests saving and restoring registers in the
vectored routines. My program does this for safety, but
experiments have shown that the Falcon, at least, really isn't that
fussy. Maybe I was just lucky.
I've included separate notes on program functioning with the
source. Incidentally, I have noted the recent Ictari
correspondence concerning mixed C/Assembler programming. This
program is such a program, and with SOZOBON C in-line assembler is
also possible (with care). If anyone wants to know more I'd be happy
to oblige, but what's possible with SOZOBON ain't necessarily
possible with Lattice or whatever, so it probably wouldn't help
much.
-=*=-
To: *.*
From: Pete Bailey (again)
Sorry to go on at such length, but this is something I feel
strongly about. Please, PLEASE, ***PLEASE***, let's all support the
new Atari Computing magazine and help to make it a success. I've
already placed my subscription - I hope that most, if not all,
Ictari members will do the same. No, I'm not Joe Connor's mum, and
I'm not Frank Charlton's hairdresser - it's just that if I have to
face the rest of my life without the prospect of a proper, printed
Atari magazine to look forward to then I really will go incurably,
terminally, barking mad (see previous section). We wouldn't want
that now, would we? The last time they tried to put me in an
asylum, I got thrown out for weird behaviour.
----------------------------------------------------------------------
To: *.*
From: Kevin Cooper
Subject DLL's
-------------
DLL's, I think they are a great idea, after looking at Picpac I had
come across a similar idea and set up some research, could I get
information on file formats and the answer is yes. I have gained a
number of books from the library on file formats detailing 80 (yes 80)
different types which could be used as DLL modules. These are of
various types which consist of Database, spreadsheet, word processing,
graphic, sound, movie and page description. This I think is an ideal
starting point for the file format side of DLL's as a programmer never
need worry again. Now the question, the standard graphic format will
be the standard device independent format but what is the standard
spreadsheet format, or word processor format, the DLL must convert the
input file into a standard but what will it be ?
To: *.*
From: Kevin Cooper
Subject: Internet HTML/VRML
HTML is a known language, the Atari platform like most others has a
HTML browser but the new standard VRML, a fully 3D internet has
arrived and only a few systems have browsers, I have come across a
book from the library on this new world and I am very interested,
what's more there is a CD on the back containing example files and
source code to different parts of a VRML browser. What do you think
of a VRML browser, would it be worth me implementing ? It took ages
for the Atari platform to get a HTML browser, do we want to be in the
same situation for a VRML browser.
To: Stos users
From: Kevin Cooper
Subject : Extensions
I am planning on making an extension which would mainly revolve around
graphics. For example I have made a texture mapping routine but
currently it is in pure STOS and slow but will be in assembly soon.
Are there any graphic orientated commands you would like, if so say in
Ictari.
To: *.*
From: Kevin Cooper
Looking at CD rom compilations and seeing the amount stored is amazing
and I would like to make my own CD but prices are 500 and upwards for
a CD writer and I am already thinking of getting a syquest removable,
then I thought why not combine the two, would anyone out there be
interested in 135MB of data for around 20 ? In the same way as you
would buy a CD ROM. On one cartridge you could get all issues of
Ictari with all programs compiled so there's no need to run the
interpreter/assembler and with all issues of Stosser, AEO, etc. Or
just 135MB of themed PD. I could easily do this if enough are
interested.
To: *.*
From: Kevin Cooper
While browsing the Internet I came across an unofficial Jaguar server
kit, it enables you to program the Jaguar, I'm thinking of getting it
myself, I'll give you more information if I do. Maybe now some real
programmers can produce for it.
*/ What do other members feel about a VRML browser for the Atari, I
personally think it would be an awful lot of work for very little
reward considering the dwindling number of Atari platforms using the
InterNet, I suspect that the PC has cornered the market in this area.
What do other members think ? ICTARI /*
----------------------------------------------------------------------
To: All
From: Mrten Lindstrm
INTERNET
========
I too have now got Internet access. For the next few months you should
be able to reach me on
marten.lindstrom@skelleftea.mail.telia.com
I will however probably soon change to another Internet provider (and
another e-mail address), since there is a healthy price war now raging
in Sweden, and my current provider doesn't seem to keep up.
You may already be fed up with all the talk about Internet, showering
over you from everywhere. But it really IS fun. I found a childish joy
just from clicking myself from Web page to Web page, linked into a
seemingly endless tree or ... well, hmm, WEB, and physically located
on servers all over the world. One moment in Sweden, then one mouse
click and I am in Australia or somewhere else. And all of this for the
cost of a local telephone call (plus a fixed monthly fee of course).
If you can't find any more interesting links to click on, then turn to
a search engine. I tried feeding the word "ictari" into the Alta Vista
search engine and a blink later it had searched its memory (physically
located in the USA) and up on my screen here in Sweden come 8 links to
the pages it could find in the world, that contain the word "ictari".
As it turns out, 5 of them were actually the Ictari pages of John
Levon, but there were three others - one in the UK, one in the Nether-
lands and one in Germany - with links to John's pages.
To: John Levon and everybody else
THE CHARACTER SET OF HTML
=========================
Viewing the Ictari web pages, with my MS Windows browser, I found that
some characters didn't look right. As you might guess these were the
characters in the second, non-ascii, half of the Atari character set -
including British pound signs and the '' and '' I use in my own
name. When viewing the same pages with the Atari browser CAB under
Gemulator, however, pound signs and my Swedish name looked OK.
So is there no standard for these characters in a HTML text?
Yes, there is:
The character set of HTML is the "ANSI" (ISO 8859-1) set!!!
(I.e. the character set used by, among others, MS Windows)
But is the Atari browser then bugged, since it shows non-ANSI, Atari-
specific, characters OK?
No, CAB (and its old version, HTML Browser) correctly converts
all defined ANSI characters into Atari equivalents before
displaying them. The thing is that characters 128-159 - among
which Atari , and happen to be - are NOT defined in the
ANSI set, and CAB chooses to simply display them untranslated.
Since this is what the Windows browser does too, these
characters will look different under Windows than under TOS.
(I personally would have preferred them to be interpreted
according to the almost-standard, Microsoft Windows extension
to ANSI, but there isn't much to say about how CAB deals with
them.)
On closer inspection I did find other characters that were as
corrupted in CAB as they were in my Windows browser; - e.g. the over-
line character "ÿ" (Atari number 255) displayed as "" in both.
____ THE SOLUTION: ____
Simply convert any and all Atari characters to ANSI equivalents before
placing the HTML page on the Web.
I have sent in a simple conversion program - ANSIFIER - to do just
this.
(Actually there is one other solution, namely to use the character
"entities" of SGML and HTML: e.g.
£ for
¯ for ÿ
å for
ö for
Ö for
Observe the letter case. See further in HTML documentation.)
To: All
HTML versions
=============
Trekking the web I found out that the HTML 3.0 draft specification,
published in Ictari34, has been DROPPED by the World Wide Web
Consortium. Apparently it was too incompatible with HTML 2.0 (?).
Instead there is now a HTML 3.2, which isn't final either but
presumably much more so than HTML 3.0 was. If, on the other hand, you
want to be 100.0% certain of no changes, then you should probably
stick with HTML 2.0 which is still the only official standard.
I send in the reference documentation of HTML 2.0 and HTML 3.2 as I
found them on the Web. Note however that the HTML 3.2 spec. is in HTML
format.
For more info, go to the World Wide Web Consortium at -
http://www.w3.org/pub/WWW/
To: Jim Macleod
From: Mrten Lindstrm
OFF-SCREEN BITMAPS
==================
Are you referring to the off-screen bitmaps provided by the "VDI
Enhancer" (that came with Ictari 34)?
These are opened in much the same way as a normal, on-screen, VDI
virtual workstation, but there are some differences in how you fill in
the VDI arrays before making the trap #2 call.
In particular contrl[5] must be set =1 for v_opnbm as opposed to 0 for
v_opnvwk, and contrl[3] must be set =20, since v_opnbm takes 20
intins. (I.e. in Devpac assembly:
move.w #1,contrl+10 ,
and move.w #20,contrl+6 .)
Also, as with ANY use of multiple VDI workstation, you must remember
to always set the correct workstation handle, when switching the VDI
output between them. (To the extent that you use the Devpac pre-
fabricated VDI macros, just make sure that the WORD at label
current_handle always contains the, well, current handle.)
If you still haven't been able to make off-screen bitmaps work, I
could send in a fuller description for assembly programmers.
GFA Basic and C programmers have hopefully no further problems with
what has already been said regarding these languages?
----------------------------------------------------------------------
To: ICTARI
From: Giles Greenway
I'm just writing to tell you that a basic ICTARI Web page is up and
running. The URL to my page is :-
http://www.elis.demon.co.uk/
The ICTARI specific stuff is all at :-
http://www.elis.demon.co.uk/ictari/ictari.htm
which avoids all the other stuff on my page, including my odd sense of
humour ! The page starts with a nice scanned ICTARI logo along with a
picture of an ST. After that there's a brief introduction and links to
the e-mail facility and the download section. Next I just included the
passage from the disks about how the postal subscription is organised.
The download section follows with all the issues for 34 to 38 in .ZIP
format. They come with the contents section of each issue in a nicely
tabulated form. The section starts with the most recent issue, then
works backwards. The top of the section also has links to go directly
to the earlier issues further down. I've still got 4Mb free, but if I
start to run out of space I'll probably cull some earlier issues. Some
more general links might be a nice idea, perhaps to the Sozobon and
GCC binaries, and programming tutorials on the 'net. I'll also
investigate a way of linking directly to the
comp.sys.atari.programmer group.
Even with 'net access, ICTARI still has a role to play. With all the
example files and tutorials it would be too unwieldy to get the same
effect by e-mail or newsgroups alone. 250Kb binaries are a bit big for
alt.binaries.atari ! ICTARI seems a good compromise between a 'zine
and a discussion group. Perhaps the site will allow everyone to cut
down on postage and disks. It should certainly draw in a larger
membership. Has no one suggested this idea before ? How many current
subscribers have net-access ? To date, I have announced the site on
the comp.sys.atari.st and comp.sys.atari.programmer newsgroups. Some
of the people with pages containing links will also give it a mention,
maybe it will be featured in "Atari Computing" and "Current Notes".
One day I will get round to registering with some search engines. I
haven't even put in a web counter yet. Tell me if there is anything
about the page you would like to change.
*/ Thanks for the information and the work you have put into this. Yes
the idea of a Web page has been suggested before but as I don't have
access to the Net and no one else at the time volunteered to provide a
page, it did not progress further. The only thing that concerns me a
bit is that programmers may download the magazines and use the info
without sending anything back to ICTARI for future issues. As we
depend almost entirely on members contributions we would (and are in
fact) run very short of material for the mag if no one provides any.
It might be useful to include a BOLD message on the Web page to the
effect that anyone who downloads ICTARI data should also return some
letters, programming queries, source code or even just general
programming information that can be used for publication. I presume
that if this happens you would be good enough to send it on to me on a
disk.
The membership numbers have dropped considerably over the last few
months but of the remaining members, about 6 have provided e-mail
numbers although I suspect a few more probably have access to the
Internet at work or University. ICTARI /*
----------------------------------------------------------------------
To: Peter Hibbs
From: David Preston
WordGrid game
Thanks for your comments regarding WordGrid. Hmmm... It's all very
well asking for feedback and bug reports and stuff, but then you've
got to set about sorting them out! So far as the main dialog goes, I
think it's all down to me using 'form_do'. This is because my skills
with the AES are limited to say the least, and don't yet stretch to my
own dialog-handling routines. I'm going to have to figure out partial
redraws and the like!
The printing problem is a bit more of a mystery however. It works ok
on my system (STe, TOS 1.62) and your problem comes as a bit of a
surprise. It's probably down to extreme laziness on my part. Printed
output was only added as an experiment, using 'lprint' statements,
(no, I didn't bother opening a channel to the printer) and was left in
because it seemed to work. I'll rewrite that bit and see if it fixes
the bug you've identified.
To: Robert Manning
I share your interest (Ictari 38) in background info about the
development of progs. I wasn't particularly specific about what I used
for WordGrid (see above), but it was written in Power Basic and
compiled (I think) using Hisoft Basic 1. Why? Well, I had Power Basic
and then found the coverdisk version of Hisoft Basic at a car boot
sale, and since they are compatible I used the Hisoft Basic compiler
to compile it. The resource file was constructed using K-Resource
(another coverdisk). I prefer K-Resource to WERCS but that's probably
just me. The resource was a bit of a b*st*rd to get right because it
contains so many separate objects - each letter in the grid is an
object, 144 of them, for example.
Although that isn't the complete history - the program started out in
Turbo Basic on the 800XL. (By the way, just in case anyone didn't know
(and is interested), Turbo Basic was GFA Basic's grandfather. Frank
Ostrowski wrote Turbo Basic as a (very major) improvement over the 8-
bit's built-in Atari Basic while remaining completely compatible and a
direct replacement, and released it as freeware. That impressed so
much that he was invited to write a Basic for the new 16-bit Atari -
the ST - and GFA Basic was the result. And here's something that not a
lot of people know (you'll have to fill in your own Michael Caine
impression) - Turbo Basic added procedures, which the original didn't
have, and used 'ENDPROC' to terminate each one. Now then, GFA Basic
uses 'RETURN' to end procedures, but if you enter 'ENDPROC' (yes, into
GFA Basic), it will be interpreted as 'RETURN'! And no, I don't know
_why_ because surely porting a program written in 6502 assembly
language wouldn't have been much help in developing one in 68000
code!)
Then there was a version in STOS, which still exists if anyone would
like a look. When I have a programming idea I stick with it! If I ever
get past the stage of having a head full of cotton wool as far as C is
concerned there will probably be a version written in C as well, some
time in the future...
To: *.*
On the current thread of magazines, I have to admit that when I bought
the STe I stopped getting Page 6's New Atari User. Whatever happened
to that one, anyone know?
*/ In the light of your comments I have done a bit more research on
your WordGrid program printing problem. When I click on the 'Printer'
button the first dialog box appears, ("Please ensure printer is on
line") but when I click on 'OK' the "Device I/O error at Line 491 on
#256" appears at the bottom of the screen. It would appear that the
problem only occurs when the AUTO folder MORTIMER program is resident.
On further investigation I found that if I switch the printer spooler
facility off within MORTIMER, your program then prints OK. Why this
should make a difference I have no idea. Anyway, hope that helps a
bit. PDH /*
----------------------------------------------------------------------
To: Mrten Lindstrm
From: Peter Hibbs
I noticed in the source code for your assembler programs that you
write the register names, A0-A6/D0-D7/SP, etc in capital letters
rather than lower case while the labels, comments, instructions, etc
are all in lower case letters. I am just curious to know the reason
for this since using upper case means using the shift key quite
frequently which slows down the typing and I can't see that it
improves readability of the code at all, just the reverse in fact (in
my opinion). I know it makes no difference to the operation of the
program but if there is any other logical reason I would be interested
to hear it.
------------------------------ End of file ---------------------------
