Copy Link
Add to Bookmark
Report
Ictari Issue 20
ICTARI USER GROUP ISSUE 20 March 1995
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* 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 20
==================
ASSEMBLY Using Calamus fonts in user programs.
Multi-colour Screen raster routines.
Making CPX accessory files.
C GEM Tutorial by J White. Part 10.
Digitized Sound play code for STFMs.
STOS STOS fix code for different TOS versions.
PASCAL Miscellaneous example programs.
MISC GIF/TIFF file information.
Using languages other than English in programs.
Program for using line drawing in text files.
CPX maker utility program and source code.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Various maths function rorutines.
RSC Macros and RSC routines.
Overscan routines.
Joystick routines.
RSC file inclusion in program plus demo program.
C Questions and Answers file.
GFA Football game code.
STOS Text display program code.
Fast sprite drawing routines.
MISC DXF format text file.
Resource file format information.
RSC to source file converter program.
For future issues :-
Polyline drawing routines in machine code.
Bezier curve drawing routines.
Picture compression routine for IMG pictures.
HP DeskJet/LaserJet compression routines (Mode 2 TIFF).
Picture switching techniques.
Printer driver code for printing mono/colour images.
Sorting algorithms.
Using the BitBlit routines.
Code for using the File Selector.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
We have had two new members join this month, welcome to them.
CALAMUS FONTS
-------------
In this issue I have published my Calamus fonts routines. I have also
written a program (called CFN_CHCK) which will display or print
Calamus font data in a more readable format as well as being able to
print out samples of any font. This program is to be included on an ST
Format cover disk in a month or two but if any member would like a
copy in the meantime just send me a disk and postage and I will return
a copy of the current version.
ARTICLES
--------
If the index above looks a bit sparse this month, it isn't really.
It's just that several of the articles are quite large so the disk is
still pretty full. Keep the articles and source code coming in, we
have had several very interesting ones arrive this month which we will
be publishing over the next couple of months. We would also like to
have more programming questions and comments to include in the
correspondence section.
Incidentally, this month is the last installment of Jonathan Whites
excellent articles on GEM in C. Although we seem to get quite a few
contributions in assembler, GFA and STOS we have not had much in C.
Perhaps you C coders would like to come up with something.
In a month or two we are going to publish some line drawing routines
including bezier curve drawing. Does anyone have some code for drawing
other types of images such as arcs, circles, splines, etc. We are
particularly interested in assembler code for drawing very fast lines
such as that used in the NVDI or QuickST programs.
----------------------------------------------------------------------
CORRESPONDENCE
==============
From: Mrten Lindstrm
To: James Collett
Correct me anyone if I am wrong, but I don't think there IS a blitter
in the TT. As I recall it, Atari never bothered to develop a TT
compatible blitter arguing that the TT is fast enough as it is. (A
standard TT is still faster than a standard Falcon). Presumably they
also felt that 'sprite-blitting' wasn't worth going for on the
'serious' TT.
To: Dick Teuber
RESOURCE FILES
I can see three ways to incorporate GEM resources in the program file
itself:
1. You can include an existing RSC file as it stands in the code
as a binary file (the Devpack directive for this is INCBIN, in
GFA Basic there is INLINE, I don't know how to do it in C). If
this method is chosen you need to include code sequences to do
what the call of RSRC_LOAD otherwise does, namely:
1: Relocate each longword pointer in the resource (i.e. add the
address of file start to each pointer).
2: Convert measures and coordinates from characters into pixels. There
exists an AES call, RSRC_OBFIX, to do this for one object.
Also you cannot use RSRC_GADDR to get the addresses to trees and other
structures, but it isn't too complicated to find out these things
anyway.
2. A slightly more ambitious project would be to write a utility
that can convert an RSC file into a piece of source text. This
would save you the need for explicit relocation (since like
with any other labels and pointers in the program this would
be taken care of automatically during the loading of the
program). But you would still have to do the conversion from
characters to pixels, unless you feel that you can make
assumptions about the character size. Actually, I think there
already exist such programs for at least conversion to C
source - e.g. I have seen a mention of a program called RCS2C
- and it would be strange if there wasn't one for assembler as
well. Maybe someone else knows?
3. Finally, you can write your own resource manually, directly as
source text. This is probably an option for very small
resources only, but for the odd little menu or small dialogue
box it could be worth considering. (Again, you would probably
have to let the program convert coordinates at runtime).
I send in, with this message, the following:
1) A text file with general info about GEM resources and objects.
2) Assembler routines for relocation, coordinate conversion and
for getting the address of a tree from its RSC number.
3) Devpac 3 macros to simplify writing of trees and resources
directly as source text.
Hope this will help you out! */ See next month for these. ICTARI /*
By the way, when writing the resource info file it struck me that
those fancy looking dialogue boxes seen in some non-GEM programs would
actually be possible to do even in a 100% clean GEM program - with the
help of PROG_DEF objects. If you don't understand what I mean, see the
info file.
To: Peter Hibbs
HOW TO MAKE A MAIN PROGRAM REACT ON ACCESSORY ACTIVATION
I think I have seen this exact question come up somewhere else very
recently but I cannot remember where. As I recall it the proposed
solution was based on the periodical watch approach and since, as you
say, the AES will inform no-one of an accessory activation but the
accessory itself, I think this is the only way.
So, to the list of other events you may have ordered from the AES
through EVNT_MULTI, you would have to add a timer event of suitable
length. Each time you get this event you would then have to make some
sort of check to see if someone else has taken over the show, and I
think the best bet is to make a call of WIND_GET with mode WF_TOP
(=10). This will tell you the handle of the window on top, which you
can compare with all the windows of your own. If it's your own window
- or zero (=Desktop) - then just return to EVNT_MULTI, otherwise take
necessary actions.
(TOS 4 seems to offer more neat solutions - in particular there is a
WM_UNTOPPED message (30) to look for - but that is of course a poor
consolation for us who want our programs to run unchecked on ST's
too).
To: Peter Hibbs
WRITING PROGRAMS FOR MANY COUNTRIES
When I saw the request in Ictari 17 for input regarding this subject,
I naturally felt I just HAD to write something. Sorry that it comes
this late but I have been too busy (doing nothing during the
Christmas). */ See LANGUAGE.DOC in MISC folder. ICTARI /*
To: Mark Baker and Jonathan White
evnt_multi and (avoidance of) task switching
--------------------------------------------
Mark Baker is absolutely right, of course, about the benefits of
frequent and long-lasting use of evnt_multi in any cooperative
multitasking GEM environment - including not just Geneva but also the
bog standard TOS of most STs (remember that even this multitasks with
accessories and with the AES screen manager itself). The only addition
I'd like to make is that task switches, according to what I have
heard, can occur at ANY AES call, NOT JUST the EVNT library calls. An
evnt call, on the other hand, will make certain the task switch (plus,
of course, it lets a process with nothing useful to do avoid stealing
time from others).
The practical importance of this may not be profoundly big, but it
does mean that if you want to AVOID task switches (within some
delicate disk operation sequence etc). then merely refraining from
EVNT calls won't help you one bit if you make other AES calls within
the sensitive code sequence. Only complete abstention from AES will
avoid cooperative task switches. (Then again, under a PRE-EMPTIVE
multitasking OS - e.g. MiNT/MultiTOS - nothing at all will help, of
course, except possibly entering supervisor mode - and even this isn't
guaranteed to work under future MiNT versions).
Use of wind_update(BEG_UPDATE) and wind_update(BEG_MCTRL) may always
offer some remedy since they will detain at least those processes that
are waiting for input or about to output to screen.
To: *.*
It seems to me that we have a shortage of questions to Ictari, which I
take must be because all members are expert programmers (I mean, it
wouldn't be possible that anyone is holding back a question for fear
of it being too basic). Here is one concerning a relatively basic and
fundamental issue: - whether or not MALLOC (GEMDOS 72) could return
memory blocks on odd addresses.
When I, many years ago, read Katherine Peel's warning in her book that
MALLOC could return odd addresses, I was naturally stricken with
terror and, in a paranoid frenzy, started to even up every address
returned by MALLOC. I furthermore could see that other programmers did
likewise. Since then however I have stopped doing it, but only because
I have noticed that other, new programs take even addresses for
granted, and because newer documentation (e.g. Atari Compendium)
doesn't at all mention "the problem".
Have I missed an official statement about this? Was there ever an
early TOS version returning odd memory block addresses, or was it just
a false alarm from the start (not unusual in old Atari documentation)?
(I take it that all ROM TOS versions - including TOS 1.0 - always
return even addresses).
With this message I have sent in a small program - PC LINES - which
changes Atari specific characters into line graphics like on the PC
and most printers. Apart from serving as an example (for assembler
programmers) of how the system fonts can be changed, it is my hope
that it will be of some use for anyone who writes an Ictari article or
documentation with charts, etc. One small example of what I mean, is
the keyboard maps (file KBD_MAPS) that I also send to Ictari. The idea
is that if the small PC_LINES program (2Kb) is on the disk then ANYONE
could view documents with line graphics with no need for a PC (or
Protext).
It would be very interesting to hear how stupid you think this idea
is.
To: All assembler programmers.
Sorry everybody (anyone?) who were waiting for GIF and TIFF additions
to the PICPAC library. This has to come next month (I think). Thank
you Poshpaws for the Falcon info.
I now finally have got Devpac 3 (ordered directly from Hisoft as soon
as Sweden was an EU member - yes this does make a considerable
difference). Unfortunately the bug (proposing the name of an existing
file when saving the message window) reported by Peter Hibbs, almost a
year ago I think, is still there. And I was slightly disappointed to
see that my other assembler - the German 'Easy Rider' - still beats
Devpack in 68000 optimization options and string handling directives
(most useful within macros). (It would have been nice to at least have
had the option to assign strings to symbols). Also, Easy Rider has its
linker built in (i.e. object files can be INCLUDEd just as easily as
source files). This said, I have to say that Devpac is on the whole
much friendlier, with its integrated and powerful debugger and many
other things, and is what I found myself most often using even when I
only had Devpac 2.
Is everybody using Devpac? (3?) I assume this is THE standard on Atari
computers, but if any assembler programmer is using anything else I
think it would be interesting to hear about it.
*/ So would we but we doubt if anyone does use anything else. Some
years ago when I first obtained my ST and was looking around for an
Assembler I rang a firm called Computer Concepts which were
advertising their Assembler called FastASM. I asked them what it was
like and how it compared with other Assemblers and they told me that
they were actually using DevPac to write their own assembler which I
thought was a good enough recommendation for DevPac.
While on the subject of HiSoft's assembler I think that, although it
is very good at assembling, the source code editor itself could still
be improved. For example, I would like to see an option to export a
highlighted block to the 'clipboard' so that the marked text could be
copied into another program such as Harlekin, for example. I would
like to see the first few characters of each 'bookmark' location
displayed in the information line of the window so that I can remember
which 'bookmark' is which. I would like to have a 'move block' option
where a block of text can be moved in one operation rather than having
to 'copy' and then 'delete'. I could probably think of a few more as
well if pushed. If anyone else has any other additions they would like
to see, please send them in and perhaps I will send them all to
HiSoft. They might even implement them if they come from a programmers
group, well you never know !
Regarding the use of Mrtens PC_LINES program, we think it is an
excellent idea and it is included on this disk. It would make any
ASCII text files that need line drawings much neater and easier to
display. The program should be run before using your text editor to
load a text file or, even easier, copy the program to your AUTO folder
and run it automatically at boot up. We have tested it with the
following text editors/WPs and it works perfectly without any adverse
side effects as far as we can tell.
These are Mortimer (EDIT), Everest, Tempus 2, MasterBrowse, EdHak,
WordWriter, Redacteur, 1st Word Plus and, of course, Protext. The
Harlekin text editor has its own built in IBM font. PC_LINES does not
work with Revenge or Write_On at all (I think these programs reformat
the text in graphics modes). The only slight drawback is that most
simple text editors do not have facilities for using line drawing
built in so the original document would probably have to be written
with Protext which does. So, in any future contributions, feel free to
use line drawings in text files and copy PC_LINES into your AUTO
folder. ICTARI */
----------------------------------------------------------------------
To: *.*
From: Geoff Smith
When I last wrote (issue 13) I was trying to find a way to play sound
samples from within Lattice C on a standard ST. I have now managed to
do it and include some source code in case it is of interest to anyone
else. The code handles AVR format sound samples but is restricted to
rates of between 1kHz and 16kHz, I hope the example is simple enough
to be self explanatory. */ See C\SOUNDS folder. ICTARI */
I have used an assembler routine by Tristan Hunting that I found on
Goodmans PD disk number GD1397. I have to admit that I have no idea
how the assembler routine works, but with the aid of a friend and a
reference book we managed to hack the interface so that it could
easily be called from Lattice. However when the routine is assembled
from within Lattice v5.52 I get the following warning :-
MOVE.B (A1,D1.W),D0 read data from sound table
Warning 46: opcode generated for "MC68020/MC68030/MC68040"
Maybe someone can tell me why this should be, things seem to work fine
but I don't like unresolved warnings.
----------------------------------------------------------------------
To: ICTARI
From: Iain Mcleod
1) What is the *fastest* way to clear the screen. I have seen a few
small separate articles on this but they all seem to claim the best
way.
2) I use BLOWUP030 in one of my programs, it is a non-GEM truecolour
picture viewer. At the start of the program, I inquire the details of
the screen (oldmode = Vsetmode(-1)) then when I exit from the program,
I set back to this oldmode but it returns me to 640*480 not my
enhanced 896*608 and so the screen is all jumbled. Do I have to use
VsetSync()? and how?
3) What the *AMIGA* does ICTARI stand for ?
*/ We don't normally condone foul language in this magazine but we
will overlook it this time. When Nick Bates started the group he used
the pseudonym Ictari on the BBS that he was using at University at the
time. The name itself was taken from a D&D character he used and was
elven for something or other. The Email users mailed him as Ictari and
referrred to Ictari's group and the name stuck when he started the
programming group. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Jim Taylor
To complement the Bezier line drawing routines in my CAD application
I would like some information/C code on Spline curve generation.
I am also on the lookout for information on the implementation of the
various vector-based font data structures.
*/ Hopefully the Calamus font code in the Assembly folder should help
with the font request. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Steve Gale
I am writing a program in which I would like to transfer data to or
from other programs via the system 'clipboard' but there does not seem
to be any information available about this. Is there any standard
format for this transfer, is the data stored in RAM or on disk, etc.
Does anyone have any information on this subject ?
----------------------------------------------------------------------
To: all
From: Tony Harris
I know there are ways of avoiding some of the standard GEMDOS calls,
that is by going directly to the hardware, but is there any way of
doing this for the file calls, ie, f_open, f_read and f_close ?
Is there a way of preventing the mouse from entering part of the
screen ? i.e. to prevent corruption when redrawing. At the moment I
turn off the mouse if it strays into the barred area, but what I
really want is the effect of not being able to go any further.
*/ It would be possible, of course, to write directly to the disks via
the disk controller chip (after all the BIOS does it) but this would
be very tricky and fraught with danger unless you really know what you
are doing. The question is, why would you want to. Using the standard
BIOS calls would surely do the job much easier.
In ICTARI issue 7, Simon Rigby provided a very useful assembler
routine which allowed the program to set the cursor position to any
point on the screen. This could probably be adapted to limit the
cursor movement to certain areas of the screen. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Terry King
There's been some talk about LZW compression recently but all
the descriptions I ever read seem to say basically the same thing
without going into the 'workings' of the algorithm. If anyone could
give a running example or source code in GFA, assembly or C
(in that preference) then I would be very grateful.
Does anyone out there have some experience with 3D ? I would like
to contact people who have a rudimentary knowledge of direction
cosines, base vectors and ideally someone who has been successful in
creating there own world or has ideas of how to.
Has anyone got the necessary equations for controlling a pinball
? Something which copes with gravity, springs, ricochets and
possibly ball spin.
*/ In issue 16 of ICTARI we published the MicroSoft Technical
Memorandum on TIFF and LZW compression systems which goes into the
algorithms in some detail and there was also some excellent C code to
compress and uncompress LZW files by Kevin Preece on the same disk.
For information on 3D drawing you need a book by Andrew Tyler called
'Real-Time 3D Graphics for the Atari ST' from Sigma Press (ISBN 1-
85058-217-3' which provides a complete program (in assembler) for a
flight simulator flying around a simulated 3D world. It covers, among
many other things, base vectors, coordinate transforms, direction
cosines, vector rotation, etc, etc and costs about 13. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Lee Russell
I am part way through writing a program to crop .IMG format pictures.
Has anybody got some 'C' code they want to donate to save a block of
memory in that format ? I've already written a loader but can't see
the point in re-inventing the wheel again if I can avoid it.
Also, I have an STFM and an unfinished routine to replay sound
samples. Does anybody have any ideas on how to do this in 'C' ? (I'm
using Lattice C v 5.5).
*/ Perhaps the easiest way would be to use the VDI 'vro_cpyfm'
function which will allow a rectangular screen image to be copied to a
memory location. If you need more info on this, let us know.
Maybe the sound playing routine from Geoff Smith on this disk will
help and if you can solve the error message problem, please let us
know. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: David Seaman
HELPME!
-------
HELP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I'm having problems using STOS on my new Hard Drive! It doesn't
like it!
The thing is, if I use commands such as DIR, DRIVE$, etc, STOS
generates an error message. It does this AFTER SUCCESSFULLY
PERFORMING THE OPERATION which leads me to believe that there is
simply something that STOS is getting (or thinks it's getting) a wrong
address somewhere along the line. If anyone knows what is going on,
then PLEASE HELP!!
My wonderful program, STock Controller v.1.5, and others, could
never see the light of day if I can't get round this problem! If
you can help, your name will be up in lights (well, monitors
anyway) in the credits of AT LEAST 2 of my forthcoming releases.
There may be the possibility of future rewards, as well......
Sorry to go on about it like this, but please, please, please, please,
please help!
*/ Over to our STOS experts I think. Incidentally, while we are on the
subject of drives, is there any way in STOS of accessing drives 'I' to
'P' from the standard STOS file selector. Any source code
contributions that I receive are copied to partition 'I' on my hard
drive ('I' for ICTARI see) but when I want to try them out the file
selector only shows hard drive partitions 'C' to 'H' so I have to then
leave STOS and copy them to another drive before I can load them which
is very irritating. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Peter Hibbs
Does anyone have an old Word Processor program called K-Word. I am
writing a program which uses words and I would like to be able to pass
a word from my program to a Thesaurus accessory program called K-Roget
which would then display the various synonyms for that word. K-Word
(from Kuma Computers who no longer support the ST) had the ability to
pass a word to K-Roget, the question is how ? I have the K-Roget
program but not K-Word. Does anyone know, or would like to have a go
at 'hacking' into the programs to find out how, to pass a word into K-
Roget from an external program. I suspect that they probably use the
AES 'appl_read' and 'appl_write' functions to transfer data via a
message buffer but that is only a guess. There is no information in
the K-Roget manual and Kuma themselves were not very helpful. If
anyone wants to help I can lend them the three K-Roget disks for
testing, please contact me in this case.
Also, thanks to various members for suggestions about disabling some
menu options when opening a desk accessory. I have got the code
working very successfully although my program only seems to work with
a timer delay of zero, any longer delay causes problems with screen
updates but that is prbably something wrong with my program.
----------------------------------------------------------------------
To: *.*
From: Richard Gage
I still have the following Atari items for sale at even more reduced
prices, please contact me on 0843 851706 if you are interested.
Hardware
--------
4MB Falcon/270MB MiniS hard drive/Desktopper/MC68882/PowerUp2
plus Systems Solution 14" SVGA monitor. 650+p/p
Sofware
-------
Atari Works (V1.207) 35
Mastering Atari Works 8
Home Accounts 2 (V1.13) 11
Molgraph 2 (V2.0) 5
Addams Family 5
Archipelagos 5
Blood Money 5
Defender II 5
Nine Lives 5
Star Raiders 5
Tempest 5
The Secret of Monkey Island 5
Books
-----
Atari ST Explored 5
Compute Machine Code Guide 5
ST Applications Issues 1-50 20
PD and Shareware
----------------
50 DSHD PD Disks 20
32 ST Format cover disks (37-48, 53-61,67) 9
45 ST Review cover disks (6-12, 14-35) 9
27 ST User cover disks (Aug 92-May 93, Aug 93-Nov 94) 9
*/ One or two bargains here I think, especially the Falcon + Monitor
and the STA magazines. Wish I had some money ! ICTARI /*
--------------------------- End of file ------------------------------
