Copy Link
Add to Bookmark
Report
Ictari Issue 35
ICTARI USER GROUP ISSUE 35 June 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 35
==================
ASSEMBLY PICPAC update.
Assembly Language Tutorial. Part 3.
Mouse routines using Absolute Mode.
C Dynamic memory debug library.
File listing functions.
Progress bar.
GFA File selector routine.
STOS STOS demo code.
Pie Chart maker.
MISC Rich Text format spec Part 2.
3D Maze Demo program.
Iconify Server (ICFS) code and CPX.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Assembly Language Tutorial. Part 4.
C Monochrome fade functions.
GFA Date and time setting procedures.
STOS Mouse and Joystick test routines.
MISC NVDI information.
SCSI FAQ.
----------------------------------------------------------------------
EDITORIAL
=========
POSTAL CHARGES
--------------
As I'm sure you all know, postal charges are due to increase in July,
the second class stamp increases from 19p to 20p. I'm not sure at the
moment whether overseas charges will also increase but if there is any
need to change our charges I will sort it out next month.
RTF
---
In the MISC folder is a very comprehensive description of the RTF
format by Mrten Lindstrm, if you are considering writing any text
applications it should provide an invaluable reference guide. Be
warned, however, it runs to over 50 pages when printed out. The
RTFREADR.ZIP file is a compressed file which needs to be decompressed
first with a program like STZIP.PRG and is an RTF reader program
written in C (for the PC), if anyone could provide an ST version we
would be interested to see it.
DYNAMIC LINK LIBRARIES
----------------------
Over the last few weeks I have been looking at PC software (especially
programming software) and there are some interesting programming
techniques which could be used to advantage on the Atari. For example,
Dynamic Link Libraries (DLLs) are used extensively in Windows
Applications and can save the programmer a lot of development time
when writing complex code and which may already have been done by
another programmer.
A DLL is a stand alone program block which is stored in a sub-
directory on the disk and which is loaded into memory when an
application program requires it. Once the code is resident in memory,
any other application (or accessory) can then use the same code
without having to load it again thus saving some memory space.
Hundreds of DLLs are available on the PC which can provide all sorts
of facilities such image manipulations, sorting functions, etc, etc.
The advantage, for the programmer anyway, is that to use any of these
libraries he just calls up the code to perform the required function
without having to know how it works and also the DLLs will work when
used from any language. Another advantage is that the DLL code is
usually written in machine code so that a big speed increase is gained
when called from an interpreted language such as BASIC. The (slight)
disadvantage for the user is that he has to have the required DLLs
available on his disk at run time which on the PC is not a problem as
ALL PCs have hard disks.
I believe we could use this same technique to some advantage on the
Atari. The easiest way, I think, would be to write a DLL and save it
to disk with the usual re-location table attached and also allocate a
'cookie-jar' identification code. When another programmer wishes to
use the DLL, his program would first check the cookie jar to see if
the DLL has already been loaded into RAM by another application (on a
multi-tasking system) or an accessory. If it is present, the cookie
jar would provide the address in memory of the DLL code through which
all access to the function would be done. If the DLL is not present,
the program would look for it in a sub-directory called 'DLL' (or
whatever) in the root directory of the current drive. The program
would then load the program and install the cookie jar ID for use by
other programs.
The DLL would have its own DATA and BSS segments but would use the
main program stack pointer for stack operations. Any large memory
requirements would probably need to use 'malloc' to allocate and
release temporary memory. Since the code could be called by two (or
more) programs in quick succession, any variables would need to be
maintained by the calling programs to avoid data corruption. Data and
control codes would be passed to the DLL code (via the cookie jar
vector) by pushing them onto the stack in the same way as the GEM BIOS
does. Data or error codes would be returned in register D0 as normal.
The Atari does already have something similar to this, the GDOS for
example, but I think this system would be more flexible and easily
expandable. There are a number of functions which could be provided in
this format, perhaps a fast text sort function or possibly Mrten
Lindstrms PICPAC routines to load different picture image formats. I
think it would be a big advantage for Assembler, C, GFA BASIC, HiSoft
BASIC, PASCAL (and maybe even STOS) programmers to be able to use the
same code easily.
If anyone has any more thoughts on this subject, please let me know.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: All
From: Jonathan Leckie
I am sad to hear about Atari World going down the toilet, the various
musings on the state of Atari got me a bit depressed but I found my
happy thought and I am better now. Maybe all the Atari clubs can get
together and get something organised or is there a millionaire out
there with a magic wand and a global instant PC compatible virus?
To: David Preston
Re.: UDO
Yes I was a fool, a moronic fool, the kind of fool you get if you go
somewhere and ask for a fool (I am not very good at examples). I had
thought that it would convert a document format to another - in much
the same way as a word processing program would convert RTF to ASCII -
without any interference. But yes you are correct it takes a UDO
script (with strict syntax) and converts it into one of its supported
document types. I got UDO from the HENSA (not my 'Net connexion), I
found the commands (and document conversion) to be similar in style to
TEX, I suspect its illustrious author has done some studying of Knuth
and compiler writing.
----------------------------------------------------------------------
To:- George Hodgson
From:- Martin Milner
Hope the following is of assistance:-
There are two ways of incorporating data from a separate file into
your STOS programs. The first is by storing your data in a memory bank
in a pre-defined format, and then bsaveing it to a disk file. It could
then be loaded using the bload command. You'd have to have a means of
transferring in and out of the memory bank, perhaps with peek/deek and
poke/doke or by using a command from an extension such as the write
command from Les Greenhalgh's excellent Control extension which will
write a string into a memory bank.
The second and by far easier method is by using a simple serial file
to store the data and input # to read it and print # to write it
thus:-
111 rem ***** read in hi-score table *****
112 FIL$=CDRIVE$+FLDR$+"scores.hi" : open in #1,FIL$
113 for N=0 to 5 : input #1,PLYER$(N),PLYSCRE$(N) : next N
118 close #1
21101 rem level/hi-score save routine
21110 FIL$=CDRIVE$+FLDR$+"scores.hi" : open out #1,FIL$
21115 for N=0 to 5
21120 Z$="," : print #1,left$(PLYER$(N),15);Z$;PLYSCRE$(N)
21125 next N
The hi-score file would look something like this:-
bibble , 3100
bobble , 2500
blobby , 1800
wibble , 700
babble , 400
bubble , 200
The comma between each field is a field separator. Hope the above is
of some help.
To:- Jason Railton
From:- Martin Milner
It's worth giving the missing link joystick commands a try as well, as
they also provide support for 2 joysticks and seem to be TOS
independent.
STOS Games:- I'd be happy to try your games out on my STE and Falcon,
pre-fixed or not. You'd be surprised at the problems you can come
across. (See below). Just let Ictari know when you want the disks or
whatever.
To:- David Preston
From:- Martin Milner
YES!!! I too have had these problems, especially when moving programs
from the STE to the Falcon. (But also back again!) Most of my problems
seem to have arisen from using screen copy to display screens full of
graphics, (including scrolling text), and not waiting long enough for
the copy to finish. I've had problems with screen fades corrupting
palettes on the Falcon, (when tested initially on my STE), due to the
fact that the Falcon runs much faster. For a fade 2, wait at least 30.
I've also had initially very puzzling palette corruptions/
unpredictable results when testing programs on the STE that were
written on the Falcon. It seems as if the screen copy is carried out
on interrupt, and you must wait a similarly long time for them to
finish before continuing with the rest of your program as with the
fade. Or... use a faster command which doesn't run on interrupt, such
as blit from the missing link or turbocopy from Control. End of
problems. (For me anyway).
To:- *.*
From:- Martin Milner
Subject:- PC Contemptibly/Atari magazines, etc.
I'm as worried about the glossy situation as much as anybody,
but....think VERY carefully about abandoning your friendly Atari for a
PC. I use a 486/33 Mhz PC at work and it's slow and it crashes
...regularly. If you get any really up-to-date software like
Wordperfect 6, it takes an age to do anything, especially load, (30
seconds upwards sometimes), after loads of disk thrashing. Click the
mouse on OPEN, and 10 seconds later you might be allowed to enter a
file name! Don't forget to add VAT onto the already expensive prices
of software, and the market is so huge, that you'll find it very hard
to come up with applications that haven't been written already.
Solution:- Get a Falcon! ST/256/True colour graphics/extended
resolutions as standard, DSP chip, SVGA support, built in midi (if you
need it), 16 bit sound, runs your familiar TOS OS, pretty compatible
with most of your ST applications, fast, can connect to SCSI disks,
CD-ROMS, modems, etc. The more people that keep supporting Atari
computers the more likely ST Format and companies supporting Atari
computers are likely to continue. Think about all the Atari computers
in Europe, it's about time we started writing some software that
they'll buy off us and not the other way around. (I've got Magic 4,
NVDI 4, CAB, getting STIK, etc. for WWW browsing.) These programs give
Atari users many of the same facilities as their PC counterparts.
The best thing about the Atari using community is of course the fact
that there are things like Ictari where people can get help with their
problems. (Hopefully).
Anyway, that's enough of that for now. Food for thought, however.
----------------------------------------------------------------------
To: George Hodgson
From: Owen Rogers
To read a file I use the commands OPEN IN #n,"Filename" and then
read each line of text in by using INPUT #n,Variable. I finally close
the file using CLOSE #n. The n stands for a number from 1 to 10
which is called a channel. Many channels can be opened at once.
10 OPEN IN #1,"ADDRESS.DAT"
20 INPUT #1,NAME$
30 INPUT #1,ADR$
40 CLOSE #1
This would open a file called ADDRESS.DAT and store the first two
lines of text as the variables NAME$ and ADR$. It then closes the
file. The channel number is 1. See PAGE 201 of THE STOS USER MANUAL
for more info on loading and saving files.
----------------------------------------------------------------------
To: All Members
From: Paul Pickering
If anybody has any of the following ST Format disk No's
1,2,5,7,10,11,14,36B I would like to either buy them from you or if
possible a copy of them would be good. I am also interested in some
early ST Format magazines No's 1 to 19,22,27,29,31 to 34,38 to 41,43
to 48,51,52,54 to 58 and I will buy them from you. Also if anybody has
any books on the Atari ST they would like to sell please let me know.
If anybody is interested my address is in the MEMBERS.TXT file.
----------------------------------------------------------------------
To: STOS users
From: Jason J Railton
Re: Incompatibility
It turns out I've got TOS 1.02, not 1.04 as I had previously believed.
This could explain some problems people have had. Still, I've sent in
a program (PLODDERS.PRG) using the latest compiler and Generic STOS
fixer, so please test the different control modes in it and let me
know if any still don't work. If I ever get around to commenting the
code, I'll send that in too. It is fairly complicated and not much use
to anyone though. */ See next month for this program. ICTARI /*
To: *.*
From: Jason J Railton
Re: Polygon demo
The polygon demo has now been re-written in assembly, and a small 3-D
maze has been developed. Anyone whose mouse didn't work with it
before should now find it works perfectly, and a lot faster too. Let
me know if you have any problems with it. Press both mouse buttons to
exit it, by the way. It must be run from the same folder that
contains the two data files. */ See MISC folder. ICTARI /*
To: Assembly programmers
From: Jason J Railton
Re: Reading the mouse
I've also sent in two routines for reading the mouse in absolute mode.
The latter of the two actually processes the results to give relative
mouse movements. Rasters are used at the same time as the mouse, not
previously possible. Unfortunately, you'd have to re-write the entire
keyboard response interrupt (not just the mouse handler) to stop the
rasters wobbling when you press a key. It should be alright if you
only use the rasters for one or two palette switches however. Again,
both mouse buttons to exit.
To: *.*
From: Jason J Railton
Re: Atari / ICTARI
As Peter suggested in ICTARI #34, I think it's time to seriously
consider the future of Atari machines and the ICTARI group. However,
I've noticed that the discussion usually turns to a pessimistic view
of the decline in ST users and magazines. But why take such a
depressing view? Why not stop for a minute and consider the future of
YOUR machine in YOUR home?
Peter said that serious programmers are likely to consider moving to
the PC, because that is where the majority of users are. But who here
really thinks that they can produce a program that will make them a
fortune? If programming is your hobby, then why the urge to throw
away everything you've done so far and start from scratch again? Why
not keep tinkering with the ST?
If you intend to learn to use various facilities of a PC to help with
your work, then why not do it at work? Why bring it home with you? Go
on a training course or something, that way you get paid.
If you want to learn about PCs in order to get a job, then by all
means go ahead - although if you don't have a job, it may not be such
a good idea to spend that much money on a new computer.
If you want a PC for the family, that's worthwhile too. The software
is much more user-friendly. But why not keep your ST? No doubt
you've got some software you don't want to lose. And what else could
you do with it? You can't really sell it now.
I'll admit that new, professional ST software is somewhat thin on the
ground, but haven't you got everything you need by now? The only
thing missing, you'll agree, is a steady stream of new games. Now,
this I'll admit is a major issue. PC games are far in advance of the
latest crop of ST games, and are improving rapidly. However, I have a
simple response to this - PC GAMES ARE UTTER RUBBISH.
Why do I say this? Simple; I've got something better. At Christmas,
soon after I'd started work (I graduated in June last year), I
seriously considered buying a PC. I weighed up the advantages and
disadvantages, and realised that I wouldn't be happy unless I could
play the latest games. Certainly I wanted to keep programming
something, and be able to print letters and so forth, but I realised
that the programming is largely for my own amusement, and my 9-pin
printer in NLQ mode is quite adequate for basic correspondence.
Then two facts came to mind - firstly, I would need to spend upward of
a thousand pounds to acquire a suitable system for playing the best PC
games around, plus maybe one or two hundred a year to keep it up to
date; and secondly, that the best games around simply weren't
available on the PC. That is why, since February, I've been the proud
owner of a Sony PlayStation.
The PlayStation graphics and sound are far superior to even the most
powerful Pentium PC. The advent of PC 3D accelerator cards may go
some way to redress this balance, but bear in mind that these are a
year behind and are an extra cost. The PlayStation cost me 300 pounds
- I recently saw it down to 200 in Dixons. Games cost no more than
those on the PC, if not slightly less on average (particularly with a
growing, good quality second-hand market), plus you get an excellent
music CD player. Some PC games (Doom, Hi-Octane) have been converted
to the Playstation, and even though the results match these games
running on high-spec PCs, with better shading (the corridors in Doom
darken much more smoothly), they look far inferior to equivalent
PlayStation original titles (Alien Trilogy, Wipeout). And how about
Actua Soccer and F1, with actual interactive commentary by Barry
Davies and Murray Walker respectively, not to mention Dolby Surround
sound?
My point is, if you want something to play games on, buy a machine
dedicated to playing games. The PlayStation isn't clogged with Sega-
type kiddies games. Top PC stuff, improving upon even CD-ROM versions
of the games, is being ported across, and, best of all, you can get
Tekken on it. And, you can still power up your ST to play about with
programming. I doubt any home hobbyist really needs anything more
powerful.
What about the Internet? Well, you can go on-line (text-only, really)
with your ST. So you miss out on waiting hours for the ridiculously
large images or sounds to download - so what? Anyway, until BT sorts
itself out and more local service providers start up, you're going to
be spending a lot of money and getting very little out of it. Trust
me, I've used the Internet and Web and whilst there's a lot of
information out there, most of it is fairly irrelevant. It's all too
easy to get sucked in and think it's useful when it isn't. It won't
be long before you can access the Internet with a dedicated
machine/console at far less cost than with a PC. Such units could even
be leased by the service provider, like BT does telephones. Perhaps
this may be a long way off, but who knows? There may be something
worth connecting to by then (besides the ST web pages of course :-).
So, am I suggesting you become a self-sufficient luddite hippy? No,
I'm just suggesting that you sit down and think about what you want,
instead of what the publicity managers tell you that you need. A PC
costs a fortune, and the cost of constantly upgrading means that you
effectively replace the entire system every three to five years. PCs
may be getting more powerful, but this just serves to keep the prices
high. New software releases invariably waste the power and hard disk
on features you will never use, and are often full of bugs and
shortcomings to ensure you upgrade to the next version (this is not
paranoia - it is actually the standard marketing strategy). The PC
may be a general machine, but if you think about it you can do all
that you want from your PC far cheaper elsewhere.
I would love a brand new Pentium PC, Internet account and lots of new
CD-ROM games to play with, but I'd rather have the money to spend
myself.
I, for one, will stick with my ST for some time to come. I don't buy
ST Format very often, because there isn't much in it for me. However,
I would seriously miss ICTARI if it stopped. I'd still keep in touch
with anyone interested, although I wouldn't have the time to produce
anything on a regular basis. Even if there's just me left, I'll keep
tinkering.
----------------------------------------------------------------------
To: Mrten Lindstrm & Peter Hibbs
From: Jim Taylor
Re - virtual VDU's/off-screen bitmaps
I've had a go at converting the GFA code you gave in iss 34, to C++
and came up with the listing below. Since I have absolutely no
experience of GFA Basic, needless to say it does not work and I need
further help.
My v_opnbm does not seem to make any difference as the VDI still draws
on the VDU screen when the program reaches
v_circle(v_handle,100,100,50).
What am I doing wrong Mrten?
/* ================================================================ */
#include <aes.h>
#include <vdi.h>
#include <stdlib.h>
#include <osbind.h>
/* These are defined elsewhere in my main program */
extern short v_handle; /* screen handle */
extern short scw, sch, scbw; /* screen sizes */
extern int dpi; /* printer dots per inch (usually 300) */
extern short work_in[];
extern short work_out[];
/* My attempt at v_opnbm */
int v_opnbm(short xmax,short ymax,short wpix,short hpix,MFDB *mem)
{
short i, junk;
/* What is this parameter Mrten */
// _VDIintin[0] = 2+Getrez(); /* Using GDOS */
_VDIintin[0] = 1; /* Not using GDOS according to HiSoft */
for(i=1;i<=10;i++)
{
_VDIintin[i] = 1;
}
_VDIintin[0] = xmax;
_VDIintin[0] = ymax;
_VDIintin[0] = wpix;
_VDIintin[0] = hpix;
for(i=15;i<=19;i++)
{
_VDIintin[i] = 0;
}
_VDIcontrl[7] = (short)((int)mem>>16); /* bits 31-16 */
_VDIcontrl[8] = (short)mem; /* bits 15-0 */
/* according to the HiSoft C++ manual this should come next */
appl_init();
_VDIcontrl[6] = graf_handle(&junk,&junk,&junk,&junk);
v_opnvwk(work_in,&_VDIcontrl[6],work_out);
return _VDIcontrl[6];
}
int v_clsbm(short bm_handle)
{
_VDIcontrl[6] = bm_handle;
v_clsvwk(bm_handle);
/* according to the HiSoft C++ manual */
appl_exit();
return 1;
}
/* Draw on the virtual screen */
void draw_on_vscreen(void)
{
int old_handle; /* old window handle */
int mem_avail; /* memory available from system */
int mem_reqd; /* memory required for a page of graphics */
MFDB vscr; /* virtual screen Memory Form Def'n Block */
float drgs, drgl; /* drawing short & long edges (mm) */
/* INITIALISE */
drgs = 210; /* paper short side = 210mm */
drgl = 297 ; /* paper long side = 297mm */
old_handle = v_handle;
/* get available system memory */
mem_avail = (int)Malloc(-1);
/* Formula for calculating memory required */
mem_reqd = (((drgl/25.4)*dpi)*((drgs/25.4)*dpi))/8
ie mem_reqd = ( scw )*( sch )/8
ie mem_reqd = ( scbw )*( sch )
mem_reqd = (int)(((drgs/25.4)*dpi*(drgl/25.4)*dpi)/8);
/* If there is more memory than is needed use what is required
else use what is available */
if(mem_avail>mem_reqd)
{
mem_avail = mem_reqd;
}
Calculate the screen sizes */
scw = (int)(((drgl/25.4)*dpi)/8)*8; /* screen width in
pixels */
scbw = scw/8; /* screen width in bytes */
sch = mem_avail/scbw; /* screen height in pixels */
/* Setup the MFDB */
vscr.fd_addr = (void *)malloc(mem_avail);
vscr.fd_w = scw;
vscr.fd_h = sch;
vscr.fd_wdwidth = scw/16;
vscr.fd_stand = 1;
vscr.fd_nplanes = 1;
/* Get its handle */
v_handle = v_opnbm(0,0,scw,sch,&vscr);
if(v_handle)
{
/* We should now be able to draw on the virtual screen,
but in actual fact we are still drawing on the vdu !!?? */
v_circle(v_handle,100,100,50);
v_circle(v_handle,200,200,50);
}
else
{
/* print an error message */
}
/* Finished with the virtual screen */
v_clsbm(v_handle);
v_handle = old_handle;
}
*/ The NVDI article next month also covers 'off-screen bit maps' which
may help. ICTARI. /*
----------------------------------------------------------------------
To: Peter Hibbs.
From: Lou Maule-Cole.
I joined the ICTARI club because as a retirement project I wanted to
teach myself to program in C. My reason for doing so is because I
have found on many occasions when using a PC there are times when I
needed a simple little program to do just precisely what I wanted to
do without getting involved in the sometimes extremely complex
applications supplied by the commercial company's such as Microsoft.
I bought an ATARI STFM about 8 years ago and I have never felt really
frustrated with it, a comment I cannot make about 'IBM' type PC's.
I retired before Windows NT was available so I don't know what it's
performance is like but I do know that running Windows 3.1 on a 486 PC
at 60MHz was noticeably slower than my ATARI.
Now this comes to the point of my letter -
What a shame ATARI UK never managed to market it properly. Even now
the ATARI ST's have several advantages over PENTIUM PC's. For those
who want simply a machine to Word Process, Desk Top Publish for their
club or keep the accounts, home finance etc. For those who want simple
but effective video titling or want to do the odd architectural
designs such as laying out the new kitchen and also for those who are
into music, the ATARI is the cheapest and simplest machine which can
do all these things very well.
Here is what I advise my friends who feel they want to get to grips
with technology and get into word processing but really can't afford
to splash out 2000 to 3000 on a PC. Buy a secondhand ATARI 1040ST
and a ink-jet or laser printer. Buy a high res monitor to go with the
ATARI but don't bother with a hard disc drive. Buy a word processing
package such as 1st Word. Load up the word processor and don't switch
the machine off until you have completed all your typing.
The ATARI has such a low consumption that this will cost you about the
same in electricity as leaving your television on stand-by and will
make it far quicker and easier to use than having to wait for a PC to
boot up, and load a word processing program before you can use it. I
wouldn't recommend leaving a PC with a hard disc running for long
periods if your worried about cost of ownership!! Getting into
computers this way means that if you find it's not for you it hasn't
cost an arm and a leg and you can always sell the printer.
I'm certain there is still a wide market out there for an entry level
computer which can do these things and connect to the Internet at a
low price. The ATARI is ideal but nobody has marketed it properly, the
public think it's a games machine with no games.
On another subject, I am just completing my program, a gardening
database, which I have written using my completely self-taught C and
GEM and I hope that when it's completed someone out there will be kind
enough to Beta test it. I joined ICTARI because I thought that if I
got completely baffled I could always ask a member for help. I am
proud to say that, so far, I have been able to work out how to achieve
what I wanted to do by myself. On occasions it has taken a lot of
trial and error I must admit. What do you reckon my chances of being
able to do the same using a PC? I'm not into machine language and I
don't really want to be.
Good luck to you if you decide to get a PENTIUM. My son-in-law let me
use his the other day and upon switching on the DOS prompt said
"Select operating system:-
1. MS-DOS
2. Windows 3.1
3. Windows NT.
and at that point I switched off!!
I know the difference between them but what a thing to ask my wife for
instance. Later, I loaded up Word for Windows. Now I was the
WordPerfect expert for my company before I retired. All I wanted to
do was to put a date on the left hand side of a margin in a document.
It was not obvious how to do it. I clicked on Help and got the A to Z
index but it was then almost impossible to guess what subject I needed
in order to look up how to achieve that which I wanted to do. After
two hours and a lot of experimental clicking with the mouse I
eventually worked out how to do it. That is not good software.
----------------------------------------------------------------------
To: Richard Evans
From: Mrten Lindstrm
CLEAN SYSTEM-VECTOR CHANGES
===========================
As far as I know, there are three general rules:
1) Adhere to the XBRA protocol, i.e. precede your routine with
the 12-byte structure:
L: 'XBRA' ;So that others can see that this IS an XBRA routine
L: 'MyID' ;ID of your program, or perhaps of its author
L: The old vector (as read just before installation of your own)
Then comes your routine.
(Typically, the final action of your routine should be to read the
third longword of its XBRA structure - the pointer to the old routine
- and jump to this address.)
NOTE: Some routines need to preserve processor registers while others
don't. The Trap 2 vector is one where at least 2B make sure they don't
touch a single register, but e.g. an etv_timer routine is allowed
unrestrained use of all registers.
2) Use BIOS SETEXC in preference to direct memory accesses (since
this will allow MiNT or MagiC to register your vector
changes).
3) Try to confine any vector changes to AUTO-folder programs
only. If you break this third rule:
A) In a non-resident program you will, obviously, have to
uninstall your routine before program termination.
The cleanest way to do this must be to trace the XBRA
chain back to your own routine (other programs COULD
have installed their own routines on top of yours) and
then unlink your routine by copying the "old vector"
of your XBRA structure to the "old" (=your) vector of
any later XBRA routine (or, if your routine is still
on top, just restore the old vector).
If the XBRA chain has been broken by some sloppy devil
(overwriting the vector without adhering to XBRA) then
you CANNOT terminate normally with PTERM!!! (That
would lead to a crash). Instead you must use PTERMRES,
or you could perhaps tell the user of your
predicament and (on a multitasking system) ask him to
try and kill the vandal process in the hope that it
will tidy its mess and allow you too to unhook and
terminate with PTERM.
(Obviously, you can't use Setexc for manipulations in
the XBRA chain, but I think the real use of Setexc is
to allow the OS a chance to register NEW vectors of
NEW processes (e.g. for the management of process-
specific vectors or perhaps for changing the process
memory status). When the process terminates, the OS
probably knows everything it needs to know anyway.)
B) For the event that your program will find itself
running under MiNT (or MagiC ?), make sure that your
routine resides in "GLOBAL" or "SUPER" memory. An
AUTO-folder program exited with PTERMRES will
automatically have all its memory made global (or
super?), but the default is otherwise PRIVATE (which
means that, on a 68030 machine with MiNT, other
programs won't be able to access the memory).
The easiest way is to set bit 4 and clear bit 5 (or
vice versa) of the PRGFLAGS longword (at offset 22) in
the .PRG file header. (These flags cause no harm with
older TOS versions which merely ignore them.)
C) For MiNT (or MagiC?) use PSIGNAL ("GEMDOS 0x112") to
install a "signal handler" (i.e. a routine taking care
of any MiNT "signals"). This is somewhat similar to
redirection of the old etv_term vector but neater and
more sophisticated.
The signal handler should react on signals that can
kill the process by trying to unhook all changed
vectors (you don't have to worry about the signal
handler itself though) and then terminate with PTERM
or PTERMRES according to the success of this attempt.
(GEM calls are not allowed from the handler; other
system calls are.)
The installation of the signal handler could look like (in C):
Psignal(SIGTERM,handler); /* Watch for SIGTERM */
Psigsetmask(~(1L<<SIGTERM)); /* Block out other signals */
Where "handler" is the (pointer to the) signal handler.
Or, the same thing, in assembly:
pea handler(PC) ;where "handler" labels routine
move.l #$112000F,-(SP) ;Psignal - SIGTERM (signal 15)
trap #1
addq.l #8,SP
move.l #$FFFF7FFF,-(SP) ;Mask off all but SIGTERM (15)
move.w #$117 ;Psigsetmask
trap #1
addq.l #6,SP
Note that the above calls should be harmless to make even if
MiNT isn't there, since the ordinary GEMDOS will merely return
-32 = "Invalid function number".
One more note: To play it safe, it could be a good idea to first read
the old vector and write it to the XBRA structure before installing
your routine - avoiding any possible problems should your routine be
called before it knows the old vector. This means that TWO calls have
to be made of SETEXC (the first one merely inquiring the address by
using a parameter -1). You may think it paranoid but it IS how 2B do
their vector changes in the Enhancer program that I disassembled last
month as well as in NVDI.
In a non-AUTO program, running under pre-emptive multitasking, I can
see a potential further problem should another vector-changing program
intervene just when you have read the old vector but before you have
installed your own. Performing the whole operation in supervisor mode
would prevent that under current versions of MiNT (and probably (?)
MagiC too).
Those are the general rules. Now, you specifically mentioned the
etv_term vector, of which each process has its own version according
to your MagiC documentation. I THINK this applies to MiNT too, and it
would seem to be the only safe thing for a multitasking system to do.
The way it works must presumably be for MiNT /MagiC, on each task
switch, to copy the process-specific etv_term version to address
0x408. In any case, it isn't anything that your program needs to
concern itself with; the normal rules for vector changes can be used,
though it is probably safer than with other vector changes to break
some of them. But I think you should stick to rule 2: Use SETEXC!
Finally: I am NOT an expert on MiNT and I know even less about MagiC,
so if you would like to convey any useful info that your MagiC docs
reveals, or that your experience with MagiC has taught you, in an
article or two, that would be most valuable I think.
This obviously applies to anyone else too, with experience of MiNT or
MagiC (or Geneva)!
To: John Cove and all assembly programmers following his series
From: Mrten Lindstrm
First of all, the tutorial is very good, clear and to the point and
allows fast visible result from very few lines of source. But there
are some things I would like to comment on:
1) HARDWARE ACCESSES vs SYSTEM CALLS
------------------------------------
I think it should be pointed out (if by any chance anybody hasn't
already understood this) that John's series is highly geared towards
GAMES programming, where speed is the priority and compatibility is
not. Thus, most of the things he does by directly accessing various
hardware registers are possible to do with system calls (the "traps")
too (the notable exception being the screen frequency). The advantage
of using system calls, is that OS extensions or graphics card drivers
etc, may redefine the system functions to work with new hardware or an
improved OS, while if you access the Atari hardware directly, there is
no such chance and you are definitely stuck with the bog standard ST
configuration. (One further advantage of system calls is you can do
them from user mode - see my reply below to Stephen Bruce on super-
visor and user modes.)
On the other hand, the system calls are slower than directly accessing
hardware registers. Taking the screen colours for example: if you only
change them a few times, there is no problem ("slow" in this context
still only means small fractions of a millisecond). But for advanced
colour trickery, like in the Spectrum 512 paint program and in some
games, you need to change colours in a few MICROSECONDS and have no
alternative to accessing the hardware directly.
I also recognize that there may be an educational value in direct (and
concrete) hardware accesses compared to (more abstract) system calls.
(Plus the former usually require less code lines than the latter.)
Even if you later are to use system calls, it may also be of interest
to know how, in the end, the system will probably do it if you don't
yourself.
But in ONE case - the key_loop routine presented last month - I think
John may have overdone it a bit, when he even had to throw in a call
of VSYNC to make the direct reading of the keyboard ACIA chip work. I
cannot see much point in accessing this particular hardware directly
anyway and would strongly suggest the following, less problematical
and not really more complicated, alternative:
key_loop move.l #$20002,-(SP) ;BCONIN - Console (= keyboard)
trap #13 ;BIOS
addq.l #4,SP ;(Correct the Stack Pointer)
cmp.b #' ',D0 ;Space character?
bne.s key_loop ;Loop back if not
2) DS and DC
------------
In part one I did notice an error (or two even). The line:
sts_colour_bank dc.l 16
was used to allocate storage space for an ST hardware palette. But it
really should have read:
sts_colour_bank ds.w 16
( or sts_colour_bank ds.l 8 )
Of course this must have been only an oversight on John's part, but
for the assembly learners here is the explanation:
DS means that the given number of "storage units" (Bytes, Words or
Longwords) will be placed in the program, just where you wrote the ds
line. All of them initialized to zero.
DC, on the other hand, means that single units (bytes, words or long-
words) will be allocated, INITIALIZED TO THE GIVEN VALUE.
Thus "dc.l 16" will give you a single longword initialized to the
numeric value 16. "ds.w 16" will allocate 16 WORDS (initialized to
zero) which is just the amount of space needed for an ST hardware
palette.
By the way, the following two lines:
dc.w 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ;16 zeros
ds.w 16
are entirely equivalent.
3) Assembler directives - processor instructions. Data - code
-------------------------------------------------------------
(This is not in response to John's tutorial, but to last month's
discussion - Stephen Bruce and the Ictari reply - relating to it.)
Just to straighten out some possible misunderstandings here:
In assembly contexts I think there is normally a distinction made
between "INSTRUCTIONS", referring to commands to the PROCESSOR i.e.
what will eventually make up the program, and "DIRECTIVES" = commands
directed purely to the ASSEMBLER. Examples:
+ "RTS" (ReTurn from Subroutine) is an instruction - that the
assembler will directly translate to a certain hex code $4E75
- associated with a specific processor action (on encountering
it the processor will pop a longword - presumably the return
address - from the stack and load it into the PC register,
causing a jump to this address).
+ "DC" (Data Constant), on the other hand, is an assembler
directive. There is no specific processor action associated
with DC, and the only hexcode(s) that a DC directive will
result in, is what is used for its operands, and could be
anything.
You COULD, if it amuses you, write "DC.W $4E75" instead of "RTS" and
the end result (in the assembled program) would be entirely
equivalent. But in most cases you will use DC only for DATA. (The most
notable exception is Line-A "instructions" which per definition aren't
real instructions and have to be written with DC. E.g. "DC.W $A000"
for a call of L-A Init.)
"Self-modifying code" is something that should be avoided in any
program intended to run on machines with instruction caches (including
MegaSTEs and all 68030 machines: TTs and Falcons). But for this
purpose you really only need define the "code" of your program as
those bytes and words that might actually be traversed by the PC
(Program Counter - an address register always pointing to the next
instruction to execute), and executed as processor instructions.
Again, memory locations created with DC or DS directives are usually
NOT in this category, simply because you will normally not place these
directives in the middle of the instruction flow.
And don't confuse the DC (Data Constant) of the assembly language with
constants of high level languages. The name of DC is really
misleading, since it only means that the memory (bytes, words or
longwords) allocated by it will be INITIALIZED to the given values.
There is no prohibition against CHANGING it (except, again, in those
very rare cases were DC is placed in the instruction flow to serve as
a processor instruction).
To: Stephen Bruce
Supervisor mode vs User mode
----------------------------
There are, I think, essentially two reasons to remain in user mode:
1) System variables and hardware addresses are protected, meaning
that unintended writing to them (due to program bugs) is
prevented and instead leads to a bus error exception. This may
reduce the effects of a program crash, in particular with
debuggers, TOS extensions and newer TOS versions capable of
intelligently trapping bus errors and other error exceptions.
Plus a bus error is easier to spot (and correct) during
debugging than a corrupted system variable.
2) Under (current versions of) MiNT/MultiTOS, no task switches
occur while in supervisor mode - i.e. the pre-emptive
multitasking doesn't work.
In addition, AES calls are trickier to do from supervisor
mode, (although still possible, see my message in Ictari 32).
But, as long as you (1) are sure your program contains no bugs that
could be alleviated by the user mode, and (2) don't care about GEM or
MiNT, I guess you could run constantly in supervisor mode, without
problems.
To: Kevin Cooper
From: Mrten Lindstrm
PC GEM
------
I have only seen PC GEM once in my life, and very briefly. It was on a
PC running DynaCADD - the Canadian ST power CAD program ported to the
PC. (Now that I have a PC it might perhaps be fun to have PC GEM
though, but where would I get it?) Nevertheless here is what I
BELIEVE. Provided that ...
A) you have a C compiler with GEM libraries on the PC as well as
one on the ST
B) you don't use any XBIOS (or BIOS) or low-level accesses of
hardware or system variables (i.e. use only GEM and (GEM)DOS)
... I THINK you should be able to port your Atari GEM programs to PC
GEM without too much trouble.
GEM file formats are much the same on PC and ST. Thus, GEM Metafiles
(.GEM files) are in Intel format on both Atari and PC, IMG files are
in Motorola format on both Atari and (I recently found out) PC. GEM
bitmap font files (.FNT files) have a Motorola format flag, but in
practice are nearly always in Intel format on the Atari as on the PC.
Regarding GEM resource files (.RSC files) I am uncertain (they are in
Motorola format on the Atari). But, on the other hand, you can always
convert them into C source (there are many RSC-to-C converters in the
PD and maybe there was one published in Ictari?).
Some of the more recent GEM functions may not be the same on PC and
Atari, but I KNOW that at least Bzier curves came to PC GEM before
they were implemented on the Atari, and I would be highly surprised if
they aren't entirely compatible with Atari FontGDOS and SpeedoGDOS.
On a PC in "16-bit mode", which I'm sure is what PC GEM uses, memory
addresses are represented in a very peculiar way. On the other hand,
the C language may to some extent be able to conceal these differences
from you, if you don't make any too tricky and low-level pointer
manipulations.
(You may possibly also have to redefine pointer types and integer
types with some DOS calls (?).)
If you do carry out this project, even with just a very small GEM
program, it would be interesting to hear your experiences.
To: Owen Rogers
From: Mrten Lindstrm
Changing AES objects
--------------------
If you study the structures that make up the different kinds of AES
objects, you will be able to manipulate them in all kinds of ways, at
runtime or, if you like, in the RSC file. (For instance, I wrote an
article for Ictari about GEM resources, published in Ictari 21. The
GFA Basic 3 manual also contains some info.)
Your specific question concerned BOXTEXT (= type 22) objects, and in
these the OB_SPEC field (see below) is the address of a "TEDINFO"
structure. The first longword of the TEDINFO, in its turn, is the
address of the (null-terminated) text string, and changing this
address to point to some other null-terminated text string means that
the text of the BOXTEXT object will be changed. However, if the new
string is of different LENGTH, you will also have to change the word
at offset 24 in the TEDINFO, which gives the string length including
the ending null byte. You may possibly also have to change the OB_W
field in the OBJECT structure, giving the object width in pixels. On
the other hand you could dimension the object with some extra space
from the start.
* OB_SPEC is the longword at offset 12 in an object structure;
in GFA Basic 3 you can access it with OB_SPEC(tree%,obj&)
* OB_W is the word at offset 20 in an object structure; in GFA
Basic 3 you can access it with OB_W(tree%,obj&)
NOTE: In objects prepared for use (e.g. loaded with RSRC_LOAD)
all coordinates and dimensions are given IN PIXELS (in RSC
files on disk, on the other hand, they are given in
characters).
Call GRAF_HANDLE(width,...) to get the width of a system
character, if you need it in calculations of new object
widths.
You COULD instead use 8 pixels per character but that would
NOT be the 100% clean way since, although any normal system
font is always 8 pixels/character wide, other widths ARE
conceivable.
Users of GFA Basic (and probably of other Basics too as well as
Pascal) should note that the native strings of your language are NOT
null-terminated (but the ones of C are). However, you can create a
null-terminated string simply by adding a null character CHR$(0) to
the end of a normal string. Users of GFA Basic 3 also have the
alternative to read and write null-terminated strings with CHAR{addr%}
To: Any users of my PICPAC library (for picture packing/unpacking)
From: Mrten Lindstrm
NEW PICPAC ?
------------
I have sent in corrected versions of some of the files published in
Ictari 24, and these may perhaps be found on this disk. However, when
starting to dig in my PICPAC source again, I have realized that the
library could have been made neater in many ways, so you should
perhaps be warned that PICPAC soon MIGHT (?) reappear in a (once
again) revised form.
Don't take this promise (threat?) TOO seriously since for the time
being I have got many other things to do, but the changes and
additions that I would LIKE to make are as follows:-
1) Colour sorting and remapping routines. Colour remapping can be
generally useful to adapt the palette of one image to that of
another. But, as I have come to realize the more I have
thought about it, GEM programs in particular need this
capability in order to minimize interference with the GEM
"system palette"!
Atari recommends that the first 16 VDI pens be left as system
colours* and not changed by applications, and although that
may be hard to strictly abide by (in particular on a display
that doesn't have more than 16 colours), it would be worth
something if picture colours could be remapped to their
closest "system" equivalents (retaining at least the system
white, black and red perhaps).
2) Fully integrated VDI use in the library (so that for instance
GEM colour sorting can be integrated, and perhaps easy-to-use
VDI sprite-blitting routines too).
I have so far refrained from that, partly because I didn't
want to rely on the Devpac - or any other - GEM libraries
(sure, most assembly GEM programmers probably use these but
still) and partly because I didn't want to internally call
V_OPNVWK for all the potential problems that could create (not
least with GEM ACCESSORIES which in principle shouldn't open
any VDI workstation except when loading).
I now intend to leave out the opening of a VDI virtual work-
station, but require that its HANDLE be passed to PICPAC,
which will then perform any further required VDI calls, low-
level and without requiring any macro libraries to assemble.
3) A single unified routine for unpacking and perhaps one for
packing (instead of one for each picture file format). And
instead of passing a pointer to a memory block with the
already loaded file, I would like the routine to simply take a
FILE SPECIFICATION and perform the loading itself (as well as
the analysis of what file format it is).
If this is implemented, would there be any interest for still
keeping the functions unpacking pre-loaded files in memory?
4) Perhaps support of the PICTURE MASK of IFF ILBM pictures (and
possibly other formats). Peter Hibbs recently asked about some
system for compressing sprites, and one simple solution could
be to save the sprite collection as one or a few ordinary IFF
ILBM images, of arbitrary dimensions, WITH a mask. The
vertical word compression of this (Deluxe Paint) format is
quite effective.
......................................................................
* "FOOTNOTE" TO THE ABOVE REMARK ON "SYSTEM COLOURS": PC Windows, on a
screen in palette mode, also reserves a number of system colours: the
first 16 of these are the only ones used for colour icons (further 4
are apparently (?) reserved in the event that the user wants a non-
standard colour for the desktop or something).
The 16 "PC icon colours" are: black and white, two shades of gray,
two shades each of red, green, blue, yellow, cyan, magenta.
As you see, very similar to the default (first 16) Atari colours (as
long as we don't go into the ORDER of the colours). But a difference
is that - instead of the Atari LIGHT (or pale) red (="pink"), light
(pale) green etc. - DARK versions are used. There is no doubt that the
PC dark colours are more usable than the Atari pale ones (e.g. dark
red or dark yellow can be used for brown, and all dark colours can
provide "shadow" for the intense versions). But any Atari user - or
configuration program - could change that of course. Thus, may I -
just for icons and similar GEM purposes and provided that enough
colours are available - suggest that everybody tries to use the "PC
icon colours" (given below in VDI colour pen order, NOT Atari or PC
hardware colour order, and on an intensity scale 0-255 - i.e. 255=max
intensity, 128=half intensity):
pen:red,green,blue
0: 255,255,255 4: 0,0,255 8: 192,192,192 12: 0,0,128
1: 0,0,0 5: 0,255,255 9: 128,128,128 13: 0,128,128
2: 255,0,0 6: 255,255,0 10: 128,0,0 14: 128,128,0
3: 0,255,0 7: 255,0,255 11: 0,128,0 15: 128,0,128
The first 10 VDI pens have (approximately) the normal Atari default
colours while the last 6 are changed (darkened). (In my view the dark
colours are a bit TOO dark, and I prefer to turn up their intensity
slightly, but that's not a big issue.)
Neodesk (allowing colour icons on bog standard STs too) is one program
that defaults to, approximately, the above.
----------------------------------------------------------------------
To: Jason Railton
From: Stephen Bruce
R.E. Polygon demo, ICTARI 31
Just a short note to let you know that the generic STOS fixer supplied
on ICTARI 34 was successful at enabling the mouse on your polygon
demo. Previously, there was no response from my mouse, but I must say
I was surprised by its speed now that I've seen it. N.B. My system is
a plain 520STe with 1 Meg RAM & 2 floppies.
To: All
From: Stephen Bruce
I've just invested in a copy of Instant C Programming by Ivor Horton.
It seems to be very well presented & easy to understand but I trust I
can rely on your support should I run into any problems. I'm currently
trying to get a pseudo 3D landscape running in real time (as in Virus)
but I would like to know if using C's floating point math library
routines will slow things down greatly, or should I use precalculated
look up tables. I've already figured out most of the theory behind the
maths involved, but I'd like to establish this before I start actually
programming. Most of my routine relies on basic triangulation (Sines,
Cosines, etc).
P.S. I will NOT be defecting to the PC. At present my
old Atari serves
all my 'serious' computer needs, & I've just bought a PlayStation for
games. If anyone else is considering upgrading to a PC, I strongly
suggest you look at the Sony first if games are what you want as the
price has just dropped to 200. Some PC titles are already available
on PlayStation & many more are to come (e.g. Dark Forces).
------------------------------ End of file ---------------------------
