Copy Link
Add to Bookmark
Report
Ictari Issue 31
ICTARI USER GROUP ISSUE 31 February 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 31
==================
ASSEMBLY Saucers game source code.
Line drawing routines source code.
C SCSI Interface Library for C programmers.
GFA GFA Interface dialog utility code & program.
STOS Polygon demo program.
Stock Controller data files.
MISC Pexec function Cook-Book.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Non-modal dialog box code.
C Dictionary game source code.
BASIC Card shuffling techniques.
GFA Text adventure game source code.
STOS Starfield screen code.
Disk manager program.
MISC Ottos Resource Construction Set (ORCS) program.
ORCS review.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
Another two members have joined the group this month, welcome to them.
Also some members addresses have changed this month so it is advisable
to always use the current membership list when contacting fellow
members.
KEYBOARD SHORT CUTS
-------------------
In this months Atari World, Jon Ellis mentions the GEM Standard
keyboard short cuts that programmers should use for GEM type programs.
This information which is available on Compulink (at address
gemkeys@ogal.compulink.co.uk) may be useful for Ictari members who do
not have access to the Internet. If any member with access would like
to download it and send me a copy I will publish it in next months
issue. There is a similar list published in the Atari Compendium but I
don't know whether they are the same.
SAUCERS GAME
------------
In the ASSEMBLY folder is a Saucers game source file. I can't get it
to work on my machine, perhaps someone could have a look at it and
find out why. I have had a quick look and it seems that the problem
(the first problem anyway) is the stack pointer position, the
programmer seems to have set the stack pointer address to the bottom
of the hidden screen which seems a bit odd. Maybe it only works
properly on a 1M or 500K machine. Anyway, if anyone can get it
working, send it in to me for a later issue. Of course, whether the
game is any good is another matter.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: Jason Railton
From: David Seaman
Thanks for at least trying to help with Stoc Controller. To the best
of my knowledge, the only commands I used in it from the Misty
extension where MOUSE ON and MOUSE OFF, which I used to try and
speed up certain routines by disabling the mouse pointer. I would
love to submit the MISTY extension for ICTARI to put on this disk,
but unfortunately Top Notch are a bit, erm, touchy about people
putting their stuff on disks without asking first. I know it's a
pain, but if you delete all the occurrences of the commands, the
program will still work just as well, only a tiny bit slower. Or, of
course, you could get the Misty extension from a PD library...
I'll try to remember to put what extensions I've used in future, too!
To: David Preston
Regarding the Squasher extension, perhaps my comments were a bit
unfair since I haven't really used it much, as I use my trusty Pack-
Ice and the Missing Link to decompact it. If you find pleasure in
using the Squasher, then all the best to you!
STock Controller... well, there are basically two problems.
I can't remember which version I gave Peter; there's the original
version, and a version that I'd fixed to bypass the disk problem,
which always used the default directory. By the way, if you don't
have a hard drive this problem wouldn't have occurred anyway so that
is maybe why you didn't notice it!
Here's a bit more information on the disk problem:
The only two commands which cause a disc error (after
successfully performing the operation) are:
DIR
DRIVE$
Commands which do not cause a disc error include:
PREVIOUS
DIR$=
DIR FIRST$
OPEN IN #1,
ETC, ETC.
This problem has only existed since I got a hard drive. STOS is run
from drive H, the drive (a Gasteiner 270 meg) is partitioned C-P.
(DRVMAP=65535) The extensions I have installed are as follows:
BLITTER
COMPACT
COMPILER
CONTROL
EXTRA
GBP
THE MISSING LINK
MIDI
MISTY
NINJA TRACKER
STOS TRACKER 14KHZ
The other problem is related to the sort code. Although I'd spent
absolutely AGES getting it to work perfectly (it was on an issue of
ICTARI even.... oops!), it seems not to work properly still and I
can't find what's wrong with it. I've also sent some sample STC
files (which are hopefully on this disk) with the corresponding
STOCK.DAT file. Try printing a stock take or price list and
you can see what I mean. HELP!!!!!!!! */ See STOS\STOC_CON
folder /*
From: David Seaman (for the last time this issue, I promise!)
To: Everyone
Also on this disk (or soon, anyway) is Disk Manager 2.0, which is
hopefully both useful and a good example of structured code. It's
certainly the tidiest, most structured code I've ever written, and,
best of all, gets round the disc problem mentioned earlier (has
anyone else had problems getting STOS to behave on a hard drive?!)
by using the file selector. I hopefully can use the same sort
of technique in STC, but I'd rather not have to resort to such
drastic measures... (I still hope to avoid doing a nearly complete re-
write...) */ See next month /*
Finally, while I'm on the subject of STOS extensions (well, I
wasn't actually, but still..), could anyone do a deflation
routine for ZIPed files? I know it would be mega-slow in BASIC,
but surely it's a practical possibility? If you do it, please let me
know!
----------------------------------------------------------------------
To: All
From: Jim MacLeod
By way of intro, this being my first letter, I am a self!! taught
assembly programmer crashing merrily about the system but not, as yet,
producing anything of note.
I have tried writing an extremely basic non-modal dialog, ie only one
window on screen, and include a working version + listing. Although in
M/C code it uses macros and I have put notes before each section so
that hopefully anyone should be able to make sense of it. */ See next
month. /*
If anyone wants to write/ring be glad to hear from you.
To: Marten Form_keybd,tree,ed_obj,key,ed_obj
In your excellent & informative articles, for which thank you, you
advised that the second ed_obj should be set to '1'. After various
experiments I believe I now see why. If 'key' is Up/Down arrow keys,
Tab/shift+Tab or the Return key, int_out(2) returns the relative
object number. However if 'key' is alpha-numeric then int_out(2)
returns whatever value is placed in the second ed_obj.
So, call form_keybd, compare ed_obj and int_out(2). As long as they
are the same then go straight to objc_edit function 2
(validate/update). Obviously if different, user is changing ed_obj's
or exiting the dialog so handle accordingly.
To: David Preston Object redraws
Calling objc_offset for obj_n returns the X/Y co-ordinates of that
object which is actually the offset relative to the screen. In fact
the X/Y of obj_0 will always be screen relative, while its children
all have offsets relative to it. All the AES probably does is add them
to those of the object you want to give the result.
Each object data is 24 bytes long held sequentially in memory. If you
get the tree address, the X/Y/W/H are held in 2-byte blocks at offsets
of 16, (for X), 18 (for Y), 20(W) & 22(H), ie if you called
objc_offset for obj_0 the returned values should be the same as those
at tree+16 & 18.
To find the W/H for any object add 24*obj_number to the tree start
address and then read the data at offsets 20 & 22. As you see, it
could be just as quick to read the X/Y of obj_0, read X/Y/W/H of obj_n
and add the X's & Y's to get the result.
To: Owen Rogers Reading GFA editable objects
Somewhere I have some GFA v2 routines which I will try and dig out for
you. Meantime here are a couple but I can't guarantee that they won't
bring things to a halt. Basically you need the start address of the
tree, a manual should show you how, which is shown as T% below. The
object number is N%.
Tv$="" Space for the returned string
@G_text(T%,N%,*Tv$) Tree start addr, editable object number
Procedure G_text(T_%,N_%,Tx%)
Local X_$
X_$=Space$(80)
T_%=Lpeek(Lpeek(T_%+24*N_%+12)) Get editable object address
Tx_len%=Dpeek(Lpeek(T_%+24*N_%+12)+24) Get text length
Bmove T_%,Varptr(X_$),Tx_len% Read string into variable
*Tx%=Left$(X_$,Instr(X_$,Chr$(0))-1 Get string length
Return
If you want to try something safer first, try changing an object's
status from Normal (0) to Selected (1) and back.
Procedure G_state(T%,N%,X%)
*X%=Dpeek(T%+24*N%+10) Object status flags are offset by 10
Return X% holds current status of object N%
Procedure S_state(T%,N%,X%)
Dpoke(T%+24*N%+10),X%
Return X% is the status to set eg 0 or 1
To: Jonathan Double linked lists
I've got a book with single & double linked lists in it, but they're
in assembler. If they could be of help ring/write & I'll be happy to
send/fax them to you
To: John Oakes 68000 programming
If you're totally new to 68K I found quite a good book is "First Steps
in 68000 Assembly Language" by Robert Erskine, Glentop Press Ltd
Standfast House, Bath Place, Barnet, Herts EN5 5XE. I've also got odd
mag articles which may be of interest, glad to help.
To: Peter TSR's
Again somewhere I had a TSR routine which used one of the spare Traps.
It set itself up on boot-up and then ran when the Trap was called from
within a program. I had an idea though that TSR's were supposed to be
completely self-contained, ie no M_alloc calls etc, so I don't know
how that would affect loading a file?
*/ See letter from Jason Railton below. PDH /*
----------------------------------------------------------------------
To: All
From: Mark Foot
Does anybody have any useful information on using LISP/XLISP on the
Atari. I have the XLISP v2.1 disk from FloppyShop but would like more
information.
----------------------------------------------------------------------
To: ICTARI / Jonathan Leckie
From: David Preston
File conversion utilities
Having had a quick look through my Atari Worlds (all bar No.1,
regrettably), I couldn't find the program Jonathan referred to in
Ictari 30. However there was a program on ST Format coverdisk #62
called TUC which might (probably with some work) do some or all of the
the jobs you wanted. I've included it (\TUC102), though whether or not
you put it on the Ictari disk is up to you. Another possibility as I
understand it is that Protext can be programmed to do all sorts of
clever things (see Mark Baines' article in Atari World #8), but only
having the coverdisk version 4.3 of Protext (in truth 90% of my
software is from coverdisks! sad but true...) so I'm no expert on the
finer points of its use.
*/ I'll try and include the TUC program on a later disk as it may be
of interest to some programmers, if Jonathan or anyone else needs a
copy urgently, please send a disk and I will return a copy. ICTARI /*
To: Owen Rogers
I think the problem with your editable strings is that the second
parameter to form_do should be the index of the first editable text
object in the form ie. ex%=FORM_DO(tree%,comline%) if that's the first
editable item.
To: Jason Railton
Seapest
Nice game, nice code. However, the executable (PRG) locked up and
didn't seem to accept any mouse input. The BAS file loaded, ran &
compiled fine. It's not terribly important, but I thought you should
know. I have a 1meg STe if that has any bearing on the problem.
----------------------------------------------------------------------
To: Peter Hibbs
From: Jason J Railton
Re: TSR programs
Last month's TSR listing was fairly straightforward, and you shouldn't
have any problems basing your code on that. However, you could do
things a bit neater so that if you make a few mistakes you don't bring
the whole system down.
1. Firstly, if you intend to intercept (i.e. steal) an existing
vector, it's a good idea to make the first command of your function a
jump, to skip over the next few bytes. Next you put a copy of the
original vector, then a key word (such as the name of your program in
eight characters), as follows:
new_routine:
BRA do_stuff
old_vec:
DS.L 1
my_id:
DC.B "MY_PROG "
EVEN
do_stuff:
Your routine...
Then, your program can take the value of the sum:
(my_id - new_routine)
and add the current value of the vector you intend to redirect.
Compare the eight bytes starting at this address with the eight bytes
held at 'my_id'. Thus your program can tell if it's already been
installed. (Don't forget the EVEN command, just in case your key word
has an odd number of letters).
I don't know if you can get one TSR routine to wipe out another and
free up its memory, but if you store the original contents of the
vector at 'old_vec', just before the key word, then your installation
program can not only identify previously installed routines, but it
can kill them off by picking up the original vector, and re-installing
it. This is useful in development, so you don't have to keep
resetting the machine when you want to try a new version of your
program.
Also, if you do this at the start of all your routines (rather than at
the end), the data is always in the same place, relative to the
modified vector, so your programs can identify each other.
2. Another safety device is to give your routine its own stack space.
Do this by adding some extra space to the amount of memory you tell
the system to preserve around your TSR program. Calculate the address
of the end of this free space, and use that as your stack pointer.
Save this address in four bytes reserved at the end of your program.
When your routine is called, it should save the current registers to
the normal stack, then copy the value of the stack pointer to four
bytes reserved at the end of your program. Then, load your new stack
pointer and carry on. When you come to exit your program, you don't
need to tidy up the stack. You can save the new stack pointer, or you
can just lose it and start from the top again next time your program
is called (safest). Then, load the stack pointer value you saved on
entry, and restore the registers from there.
The memory preserved around your program consists of the program
itself, 256 bytes preceding it, called the basepage, plus any data
space after your program that you want to keep free for your program
to use. If the TSR program needs a lot of spare RAM, you can't rely
on being able to request it from the system when activated. If your
routine is triggered whilst another program is running, that program
may not have freed the RAM it doesn't need, so all the memory will be
allocated to it with none available for the system to allocate on
demand.
3. If your installation program is fairly large, you can always put
your new routine first in the listing, with a jump to the installer
just beforehand (below). Then, you need only tell the system to
preserve the memory up to the end of the TSR routine, and its data,
and cut off the installer code. After all, you don't need it once the
TSR code is installed.
start:
BRA installer
new_routine:
This is your new routine, followed by
its variable storage area.
cut_off:
installer:
This is the procedure that installs
'new_routine', and is programmed to
exit, preserving the amount of
memory between 'start' and 'cut_off',
plus 256 bytes plus data space.
If you reserve extra memory for workspace, some of the installer
routine could end up as part of this workspace. Don't worry about
over-writing it once it's done its job.
4. If you're going to have an installation message, put a keypress
pause after displaying it, so at least it can be read.
test_space_bar:
CMP.B #$39,$fffffc02.w
BNE test_space_bar
...is an old favourite, which waits for someone to press the SPACE
bar. It's also very useful if you're playing around with vectors,
since it enquires of the keyboard chip directly - it doesn't rely on
system keyboard interrupts. Switch all the interrupts off, and it
still works.
By the way,
"COMPUTE!'s Technical Reference Guide
ATARI ST
VOLUME THREE
TOS
by Sheldon Leemon"
ISBN 0-87455-149-8
$24.95, or 22.95 from Foyle's, Charing Cross road, London - where I
got my copy -
...is a brilliant book on this sort of thing. I mean, I've never
written a TSR routine myself, but look at all the stuff I've managed
to come up with... And hunting round Foyle's is a great day out in
itself...
*/ Thanks for the extra info Jason. Actually I seem to remember
reading somewhere that it is not possible to use any GEM/VDI calls
(which I need to do) from an Auto folder program because GEM hasn't
been initialised at that point in the boot up sequence. If this is the
case I will probably have to install the program as a standard
accessory first and then hook into the keyboard vector so that the
user can call up my program with a key combination (even if the main
program does not allow access to the menu bar) which is what ImageCopy
does. Any further information on this subject from anyone would be
very interesting.
I have got the Compute series of books, the problem with them is that
there is so much information in them that I tend to just read the
chapters that I am interested in, I will have to have another look
through them. I actually visited Foyles myself a couple of weeks ago
and purchased a book called 'Practical Algorithms for Programmers'
which looks very interesting although it is not Atari specific, in
fact the number of Atari books available there, seems to be getting
less each year. PDH /*
----------------------------------------------------------------------
To: ICTARI.
From: C Singleton
Can anyone tell me how to send a FORM FEED code to a printer using
Lattice C5.6. All I seem to get for my effort is a printing of the
control code 'FF'. Thanking someone in anticipation of a reply.
----------------------------------------------------------------------
To: All
From: Peter Hibbs
Are you good at drawing graphics ? I am in the process of writing a
Dungeon Master type game (in fact it is almost identical to DM) and
while the basic layout of the dungeon will be the same, I would like
to add some different monsters to the game. If anyone is interested in
designing some new monsters, please let me know (or telephone) and I
will send you a disk with some example images (in Degas .PC1 format)
and information on what is needed. There is no fee payable I'm afraid
although you would get a free copy of the game, of course, when it is
finished.
------------------------------ End of file ---------------------------
