Copy Link
Add to Bookmark
Report
Ictari Issue 22
ICTARI USER GROUP ISSUE 22 May 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 22
==================
ASSEMBLY Graphics image outliner routine.
Intro demo program code.
Mouse position test routine.
Upper/lower case conversion routines.
Mouse movement limiting technique.
C Progress report function.
Tim Oren GEM tutorial. Part 11. GEM hooks & hacks.
BASIC Demo program on disabling menu items.
GFA Picture clipping code and program.
Bingo card number generator and program.
GFA Tool Kit book review.
STOS Bank display program code.
Chaos engine.
MISC Using the system clipboard.
Terry King's GFA Extension kit demos.
Current membership list.
Index for issues 1-21.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Overscan routines.
STE 8 way hardware scrolling routines.
Blitter routines using A line $0007 call.
C Tim Oren GEM Tutorial. Part 12. GEM Events.
Replacement standard library functions with Alcyon C.
GFA Hi Rez format program.
Library Creator for GFA programmers.
STOS Menu Shell code.
Screen saver code.
STOS Extension selector.
MISC GDOS information file.
Character conversion tables.
---------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
We have three more new members this month, welcome to them. Also a
few seem to have dropped out, at least they haven't sent any money or
disks for the last or this months issue. If you decide that you don't
want to receive any further issues, please let me know and if you do
want further issues, please send a disk or money as soon as possible
after receiving the current disk. If you do send in a disk, please
put something on it. If you can't manage an article, a letter for the
correspondence section below will do, I just hate getting blank
disks.
GFA EXTENSION KIT
-----------------
This month Terry King has sent an advert for his extension kit for
GFA programmers as well as a number of demos and games that have been
written with the kit (see the end of this file for more details). For
any GFA programmer interested in graphics and sound programming I
think this package would be invaluable, the demo games are extremely
well done although I am generally not a games player, I particularly
like the Bomber game. The two demo programs are included on this disk
(in the MISC folder) and run in low rez, the source code and other
games can be obtained from Terry. It still surprises me how powerful
GFA Basic is, I was amazed to learn from an article in Atari World
magazine that the all singing, all dancing word processor Papyrus was
written in GFA Basic.
UNIVERSAL PRINT DRIVER
----------------------
It has always been a problem when writing software that needs to send
graphics images to a printer, to be able to cater for any type of
printer that the end user may wish to use. I have come across a
number of PD programs (some by ICTARI members including me) which
work with only one type of printer which can be very annoying for the
end user.
Commercial software houses get around the problem by writing a
'printer driver' for their own software that outputs text and/or
graphics, with a suitable printer driver file for each printer type.
I believe that it would be very useful for the group to write a
Public Domain printer driver system which would then be available to
all non-commercial programmers. This would allow any PD programmer to
write a program which can output standard text attributes (bold,
underline, etc) and graphics images to any type of printer and know
that it will print correctly without having to try it out on lots of
different printers.
The question is then, is this possible and if so, how. Firstly, how
do printer drivers work anyway. Having examined several from
different programs there seems to be a number of different approaches
to the problem. Protext, for example, uses a purely ASCII text file
which has various groups of letter sequences to define the printer
control code sequences and even command structures such as if...else,
etc. By contrast, First Word Plus, Calamus and other printer drivers
just have a sequence of binary values.
It would probably be relatively straightforward to cater for
different text attributes such as bold, underline, italics, etc. If a
specific byte or word size value was allocated to each attribute
(i.e. 128 for bold, 129 for underline, etc) which was then passed to
the printer driver code which, via a look up table in the appropriate
printer driver file, converted the code into the required printer
control codes which would then be sent on to the printer.
A more difficult problem is printing graphics images. How can a
printer driver control routine know how bit image data is sent to the
printer. The German drawing program MegaPaint allows four basic bit-
image printing modes, i.e. 9 pin, 24 pin, HP DeskJet/LaserJet and
Atari Laser Printer SLM 804. The method of printing graphics data is
different on each type of printer and any individual printer may have
different control code sequences to initiate bit-image mode. These
control code sequences are entered into the printer driver by the
user from within the program. If these are the only methods of
printing bit-image data then it would be fairly simple to write a
standard routine which can send a data stream to the printer with the
appropriate printer driver file defining which type of printer is
being used. The printer driver file would also provide the required
control codes to start up bit-image mode and in the case of the dot
matrix printers, the number of micro-line steps required to move the
print head after each raster line.
Another consideration would be graphics resolution. The dot
resolution of each printer obviously varies considerably and even on
the same printer there are usually different resolutions available.
Could our printer driver routine automatically adjust the output
resolution so that each printer prints an image at the correct size.
This sounds a bit too difficult to do in practice and in any case it
may be better for the application program to have full control over
the output resolution, any ideas?
On modern printers there are also colour printing facilities, a
comprehensive printer driver would probably have to include controls
for this. How does colour work on different printers?
On HP DeskJet and Laser printers (and maybe on some dot matrix
printers) the data stream to the printer can be compressed in order
to speed up the print operation. I have written routines for the HP
printers to do this which could also be incorporated into the driver
code. Is this a standard protocol or are there different systems in
use on other printers ?
How would a flexible printer driver system work. It would need to be
available for any computer language so it would probably be stored as
an object file and linked into the program source code at
assembly/compilation time. Another alternative may be to run the
driver routines as an executable program module from the user program
using the p_exec function, any parameters being passed to the
routines at execution time. A third alternative (and the method we
favour) is to include the object code as a binary file and call it as
a function, procedure or sub-routine. Obviously, at initialisation
time, the absolute addresses would have to be relocated in the same
way as a .PRG program is processed after loading and this could be
done automatically during the printer initialisation sequence.
The driver code would probably consist of three separate routines, an
initialisation routine, a routine to handle text codes and a routine
to handle graphics data. It would probably be easiest to have one
entry point and use a system of command codes passed to the driver
routine (via the stack) to select the required function in much the
same way as the AES functions do.
When the application program is first run, the initialisation routine
would need to access the selected printer driver file which has been
loaded from disk into RAM by the applications program and set up any
RAM buffers, look up tables, etc. The printer driver file would
probably be best constructed as an ASCII file (perhaps something on
the lines of a GDOS assign file) which then makes it easier for the
user to generate new driver files with any text editor. An ASCII text
file would also make the file easier to read and easier to expand
with further control codes later. The text handling routine would
receive all text data for the printer and when an attribute control
code was detected (say in the range $80-$FF or whatever) the routine
would substitute the appropriate printer control codes from the
driver file and pass them on to the printer.
The graphics data handling is a bit trickier. A special control code
in the printer driver file could define which graphics mode is to be
used, i.e. 9 pin, 24 pin, DeskJet/LaserJet or Atari Laser (it might
be better to ignore the last one since it is very limited). To send
graphics images the applications program could first generate a bit
map image in a memory buffer and then call the graphics handling
routine. The width of the image (in bytes) and the resolution could
be passed to the routine together with the address of one raster line
of data. The driver routine can then store or process that raster
line depending on the printer graphics mode required. For example,
for a Laser printer the data could be sent immediately, for a 9 pin
printer the routine will need 8 lines of data before it can be sent
to the printer and for a 24 pin printer it would need 24 lines. The
sequence would then be repeated for all raster lines. A typical
printer driver might look something like :-
;Printer driver for HP Laser Jet printer
PN="HP Laser Jet" ;Define printer name
GM=3 ;Graphics Mode 3 (LaserJet/DeskJet)
RZ=300x300,150x150 ;Resolutions available =300 and 150 dpi
TC=1 ;Text compression mode 1 on
$80=27,40,115,51,66 ;Bold text
$81=27,38,100,48,68 ;Underline
$82=27,40,115,49,83 ;Italics
etc...
etc...
END ;No more data
The above example is, of course, somewhat over simplified. There are
numerous other problems which would have to be addressed. For
example, the embedded control codes used here are byte size and in
the range $80-$FF which implies that ASCII characters in that range
(i.e. the sign and other foreign characters, etc) cannot be sent to
the printer direct. Is 128 codes sufficient anyway, looking through
the Laser Printer manual there are many more printer options than
that available, but then would we need all of those anyway, Protext
uses quite a small number of text attributes codes. The applications
program could send more specialized codes direct to the printer
itself, if required although this would defeat the object of the
exercise to a certain extent.
What other facilities should be built into the printer driver code ?
What about a facility to swap an ASCII character code with another
one, what about designing new characters within the driver file, what
about plotters and, most importantly, how can we make the driver code
future proof as far as possible. With new printers coming out all the
time it would be nice, if not essential, to be able to cater for new
advanced printer designs.
All of the above, at this stage, is just a discussion document. No
code has been written yet (unless some member has done something on
these lines already). Looking through the membership questionnaires
it appears that most members have a printer of some kind with about
12 different types of printers represented although not everyone put
down which particular printer they have. I would, therefore, like
every member who has a printer, and especially our more experienced
programmers, to let me know whether (a) this project is feasible or
even desirable and (b) what features would need to be included, how
this could be done in the various different computer languages, etc.
Providing I get sufficient feedback on this project (and I hope I
will) I will publish more details and ideas in the next issue. If I
get a poor response I will have to assume that no one is interested
in the project.
If we can come up with a good system between us which works well I
will then present it to the Atari community at large via the glossy
magazines for the benefit of everyone.
---------------------------------------------------------------------
CORRESPONDENCE
==============
To: All
From: Tony Harris
I have heard some horror stories that the line_A functions are not
supported by the Falcon and are not even guaranteed to work on other
FM/STE's !! Is this true or have I been the butt of a bad programmers
joke ?
Does anyone have any code to replace the normal desktop with a
picture which adjusts the picture depending on the resolution ?
I have been using the palette switching trick using Timer B but
whilst it is stable when the mouse doesn't move, it bounces a few
lines when the mouse is moved. This is very annoying and I don't know
how to stop this without losing the mouse which I need.
Which is better, HiSoft's Video Master or Vidi-ST ?
---------------------------------------------------------------------
To: Tony Harris
From: Peter Hibbs
In issue 20 you asked if it was possible to prevent the mouse moving
into a specified part of the screen. In the ASSEMBLY\MS_CHECK\ folder
you will find some source code and demo program on this which may
help.
---------------------------------------------------------------------
To: *.*
From: Terry King
What's the correct use for FORM_DIAL ? I've had this working before,
but in my latest program (Library Creator) I just couldn't get it
working. Each time I called FORM_DIAL(3, ...) to erase the dialog box
it just drew a green box ! Even though the system had plenty of free
memory and no other dialog box had already used FORM_DIAL and
FORM_DIAL(0,..) returned no error it still seemed not to work. What
could be going wrong ?
Are there any standard methods of calculating the position of a
slider ? In GFA Basic 3 this is the code that I am using for a
vertical slider :
back_slider is the object number of the slider
fore_slider is the object number of the slider button
height is the maximum of lines in total
lines is the maximum of lines visible
line is the current position
~OBJC_OFFSET(tree%,back_slider,bx&,by&)
bh&=OB_H(tree%,back_slider)
per#=100*height/lines
fh&=bh&*per#/100
OB_Y(tree%,fore_slider)=bh&*line/lines
OB_H(tree%,fore_slider)=MIN(fh&,bh&)
Although this code works fine it results in a tiny error so that
sometimes the bottom of the slider leaves a gap or overshoots.
Is the EnhancedGEM interface available in England and will it work
with GFA or Sozobon C ?
There's a program called WINLUPE which I think is written by the same
guy who wrote EnhancedGEM which displays a magnified section of the
screen in a window. This window is updated (very quickly) even if
it's behind many other windows with only a small part of it showing.
How is this done ? My own theory is that the program creates a one
bit plane mask the size of the screen and draws the dimensions of all
the windows on it and then uses this as a mask before BITBLK copying
the result to the screen. How does this sound ?
Finally, is it possible to free a memory resident program ?
To: Peter Hibbs
I'm fairly new to GEM programming but I was interested in your
problem regarding information in a window being printed on even when
the menus have been accessed. I think that all you need to do is call
WIND_UPDATE with a value of 1 at the start of any window printing and
then call WIND_UPDATE with a value of 0 at the end of any window
printing.
The value of 1 means that as soon as the menu is accessed that
program freezes on the WIND_UPDATE command and stops any printing
occurring. If however you activate an accessory the printing will
start again so you need a further check to see if your window is
active with a call to WIND_GET with a value of 10 which returns the
current topped window.
---------------------------------------------------------------------
To: Peter Hibbs
From: Mrten Lindstrm
PREVENTING CLASHES ON SCREEN BETWEEN PROGRAMS AND THE SCREEN MANAGER
--------------------------------------------------------------------
In answer to your problem with clashes between cursor flashing and
menu:
Yes, there is a simpler - and cleaner - way to prevent this. Its name
is WIND_UPDATE. (Quoting Laurenz Práner of ST Magazin, WIND_UPDATE
is "the most misunderstood of all GEM calls". Possibly partly because
of its name - don't be fooled by it into believing it is something to
do with windows only - but mainly because it has been so badly
described in most TOS books and documentation.)
To ensure that never more than one process at a time (including the
AES screen manager) is drawing on screen, all well-behaved GEM
programs are REQUIRED to ask permission from the AES before making
any changes whatsoever to the screen. And this is done with a call of
WIND_UPDATE(BEG_UPDATE) (where BEG_UPDATE is an OP-code = #1):
WIND_UPDATE(BEG_UPDATE) = Request permission to draw on screen!
If any other processes are currently drawing on the screen, the AES
will put your program on hold until all processes before it in the
queue are done with their output (= have issued END_UPDATEs = #0).
(For instance will the AES screen manager issue its own BEG_UPDATE
before letting down a menu box and will not issue an END_UPDATE until
the box has been removed again.) So after the BEG_UPDATE you can
confidently make any output you like, such as inverting the cursor,
without interference from others. When done you must call:
WIND_UPDATE(END_UPDATE) = Output done; Screen free for others to use
... until it's time for next "cursor flash" or whatever other screen
output operation you might want to perform.
NOTE: The rule is to call WIND_UPDATE(BEG_UPDATE) before any
operation that (whether by VDI calls, AES calls or - in a less clean
program - by other means), explicitly or implicitly, may cause
changes to the screen display. I.e. even before such a thing as
turning off the mouse pointer. Some AES calls have built in
BEG_UPDATEs/END_UPDATEs, but it never does any harm to make your own
explicit calls, since BEG_UPDATEs can be nested (each END_UPDATE
cancels only the latest BEG_UPDATE).
NOTE 2: BEG_UPDATE/END_UPDATE could be used even by a program that
doesn't intend to draw anything, just to detain others that do.
Specifically they SHOULD be used by accessories needing to load files
(including RSC files) or reserve memory (including opening VDI work-
stations) at bootup time (the only time it is safe for an accessory
to reserve memory). A BEG_UPDATE will hold the GEM Desktop while the
accessory undisturbed can go about its business. (There were some
bugged versions of TT-TOS drawing the Desktop without issuing any
BEG_UPDATE, but for all other TOS versions it should hopefully work.)
NOTE 3: The OP-codes given in the Atari Compendium are wrong. The
correct codes are #1=BEG_UPDATE, #0=END_UPDATE (and #3=BEG_MCTRL,
#2=END_MCTRL).
By the way: BEG_MCTRL effectively does on the INPUT side (it takes
over all mouse AND keyboard input) what BEG_UPDATE does on the output
side. It is however much less often needed since input clashes are
much less of a problem. (E.g. any program owning the top window will
get all keyboard input anyway.) It must be used in some situations,
normally together with BEG_UPDATE, in particular before sending up a
dialogue box (to avoid "click-through" when not owning the top
window). Another example is if you temporarily want to make use of
the full screen area, overwriting even the menu bar, when use of both
BEG_UPDATE and BEG_MCTRL will again completely shut out all others
from both output and input (though you must then make sure of course
that the screen is restored afterwards).
PROGRAMMING FOR BIG SCREENS, GRAPHIC CARDS ETC.
-----------------------------------------------
As far as I know there are only two rules to consider if you want to
make your program work with any TOS computer screen, with or without
graphic card or other screen enhancer. Including all resolutions of
Falcons, (Magic)Macs, PCs (with Gemulator 4) etc.
1) Never assume anything about screen dimensions or number of
colours or bitplanes (but get this information either from
WORK_OUT array after VDI calls V_OPNVWK and VQ_EXTND or from
Line-A variables). The call GETREZ is just about useless
except for one thing: To select an appropriate screen font
size when using GDOS. (When calling V_OPNVWK, with GDOS
present, word 0 of the WORK_IN array could be set to
GETREZ+2.)
2) Never assume anything about the organization of screen memory
or in other words NEVER ACCESS SCREEN MEMORY DIRECTLY. (The
screen is not even guaranteed to reside contiguously in
memory.) Either (in a GEM program) use VDI/AES for all screen
output, or else (in a non-GEM program) use GEMDOS/BIOS
character output only. And when you are dealing with image
blocks in device specific format, copied to/from screen with
VRO_CPYFM (or VRT_CPYFM), you should of course make no
assumptions regarding these either. If you need to manipulate
such an image block in any way - or save it as a picture file
- you should always transform it first with VR_TRNFM into the
device-independent format.
(Since any graphic card must come with a 'screen driver' which
replaces the respective VDI calls as well as DOS/BIOS character
output and Line-A variables appropriately, I think everything should
be taken care of if you just rely on the above rules.)
Needless to say this places some limitations on the SPEED with which
things can be written to screen (it would be hard to make a sprite-
bouncing, joystick-wiggling game not appear a bit jerky), but as to
WHAT is displayed anything would still be possible by copying it
(after transformation) as image blocks to screen. Logical
combinations of e.g. sprites and backgrounds could be done either
within the context of the VRO_CPYFM call or you could use any hand-
crafted routines of your own design on the image block - in device-
independent form - before transformation and copy.
Only if you want to break the rules to gain extra speed do you need
any extra information particular to the screen-driving hardware used.
E.g. most of the native Atari screen-modes are stored sequentially
and word-interleaved (an overscan unit should presumably not change
that (?) ) and this information may allow you to directly manipulate
device-specific image blocks or possibly even the screen memory
itself.
This does definitely not mean that I would be uninterested in info on
cookies or other identifiers of graphic cards and other screen-
enhancers and some details on how they organize screen memory. Did
you get information on this, for your Autoswitch Overscan unit, which
you would like to share?
*/ I have now got the AutoSwitch OverScan unit working now and it is
very good. It has shown up one problem on my Mono monitor though, the
normal area of the screen is grey compared with the edges which are
very white. Moral, make sure you use those screen saver programs to
save the screen being damaged (I now use the Harlekin saver).
Unfortunately the programming information that came with the unit is
very poor. However I am converting my existing (badly written)
programs to work with the large screen and I may report on
programming techniques at a later date. PDH /*
To: Mark Baker
"There should be no need for a programmer to know the keyboard map"
you say. No, sure, AS LONG AS ALL RULES ARE FOLLOWED, and yet, a few
lines later, you say that, in defiance of the Atari style guides, you
like to use Alt shortcuts. Well, SO DO I, which is precisely one good
reason why I think keyboard maps could be of use. (The expressed
argument for Atari's dissuasion from use of Alt shortcuts is the use
of the Alternate key to access characters on non-English keyboards.)
E.g. one thing that can be seen from the maps is that although the
key positions vary between nationalities for letters A-Z, these
letters seem never (?) to share keys with "Alternated characters", so
that at least Alt-A to Alt-Z always are unproblematical to use for
commands. For many programs you only need a few commands which can be
easily assigned keys without breaking any rules at all, but when a
program is as crowded with functions as e.g. Protext, where just
about every key is used for one or more commands, I honestly can't
see how you could do without keyboard maps, if you want your key
assignments to be reasonably compatible between different
nationalities.
You could also have said that "there should be no need for a
programmer to know hardware addresses". This would be even more true
(since a clean program shouldn't access hardware addresses), but
extra knowledge never hurts and is even useful when you want/need to
bend the rules a bit in as neat and harmless a way as possible.
And no, we Swedes too would understand a date expressed as '24 Mar
95', we could even write it as '24/3 1995'. My note, and the Atari-
defined _IDT cookie, only applies to 6-digit date expressions xx-xx-
xx, as most often used for instance to present file dates. With these
the Swedish practice - and e.g. in letterheads or for birth dates
("birth numbers" which form part of each Swede's "person number" =
civic registration number) - is to put year first and day last - i.e.
95-03-24 (most significant numbers first). You do have a point in
that using name instead of number for the month would eliminate any
risk of confusion, though you would then of course have to vary the
spelling of month names slightly between different languages. (With
names reduced to three leading letters the differences will be very
few between western languages, but there are of course some.)
Finally, I have to thank you for your notes about ISO and ANSI and
for pointing out that the normal character set under Windows is the
ISO set and not the IBM set (used under DOS). I must admit that when
writing my notes I was only aware that the ISO set was used by Amiga
and Archimedes. (There must still exist some easy ways for Windows
users and programmers to get at the old IBM/DOS set too, doesn't it?)
To *.*
Complementing my notes on "multinational programming" in Ictari 20, I
send in character conversion tables (Atari - IBM - ISO - Macintosh)
to give a more detailed idea of which Atari characters are usable
with IBM and which ones are convertible to ISO/ANSI (=Windows/Amiga/-
Archimedes) and Macintosh (without changing the character sets).
To: other non-British Ictari members
Am I the only non-British member to write anything to Ictari? It
isn't the English language that's holding anyone back, is it? I
cannot believe my own English is that magnificent, and you should
also know that Ictari has a very kind and understanding Editor who
has corrected many stupid mistakes of mine.
I think it would be interesting to hear your views, and info, on the
"multinational programming" subject. (E.g. just a short note on the
preferred date format in your country.)
*/ We would also like to hear from members in other countries (or in
this country for that matter). We have just four members in European
countries, two in Sweden, one in Finland and one in Belgium. How
about a letter guys. ICTARI /*
---------------------------------------------------------------------
To: Ictari and in fact everyone!
From: David Seaman
Firstly, I must thank J Davidson for his STOS text-displaying
routine, which I have now modified slightly to become the basis
for the shell program for my new diskzine, "E's Got It!" (Blatant
plug #1) It is the world's first (well, second actually but the
other one only lasted one issue) STe-only diskmag. (AVAILABLE
DIRECT FROM ME FOR JUST 1.50 ON THE 15TH OF EACH MONTH FROM MAY
1995! Blatant plug #2) By the way, what happened to the
"MEMBERS.TXT" last issue ? */ Not enough room on the disk. ICTARI /*
My STOS-hard drive problem is still there, so can someone please
help! As I said two issues ago, it causes an error AFTER it
successfully performs the operation, so I think it must be getting
a wrong address somewhere. Otherwise, STOS itself saves and loads
from the drive no problem. STock Controller v.1.5, which
threatens to become a legend in its own lifetime even if it doesn't
actually get released (because I keep going on about it) will only
be released if -
1) This problem gets sorted out or
2) I make the program less powerful and flexible in terms of
disk access (which I don't want to do... i.e. it loads and saves
all files from the same directory the program itself is in).
*/ Perhaps you ought to send in a code fragment which demonstrates
the problem, this would be easier to check than trying to guess what
you have done wrong, if you have done anything wrong. Also don't
forget to send details of your set up, i.e. TOS version, STOS
version, RAM size, Hard disk type & size, etc. ICTARI */
For all you budding STOSers out there, here's a quick list of every
extension available that I know of... (in no particular order).
Compact (comes with STOS... compact Degas and Neochrome
screens- useful)
Compiler (turns your basic files into executable machine code-
this is the extension you MUST have)
STE (hardware scrolling, DMA sound, extended colour palette,
joystick ports- and excellent extension)
Blitter (various blitter commands, but unfortunately very slow-
if it was faster, this would be and essential addition for STE-
owners)
512 (show Spectrum 512 pictures)
Cyber (play cyber sculpt animations)
GBP (various commands and STE commands- not a bad extension at
all)
Missing Link (super-fast sprite routines, play (SAD) chip music,
various screen routines- can be a little tricky to get used to the
commands, but many STOS users would swear by this extension it
gives them so much more power!)
Misty (suicidally fast and versatile screencopy routines, turn
the mouse off and other routines- an excellent extension that no
self respecting STOS user should be without)
Control (fast sprite routines with more flexibility, font
routines and more- I find this a little easier than The Missing
Link to get to grips with, although it's a tiny bit slower
in some commands; highly recommended)
Ninja (tracker module player for STE, still in early stages I think,
so I won't pass judgement on it yet)
Tracker (ye olde version, not bad sound quality but you have to
convert the MOD files before it can play them- still, not bad
really (have you heard the intro music for Grandad 2?!))
3D (use 3D objects, not bad if you like that sort of thing- I don't,
so I can't really say much about it, although I know some use it)
Stars (display starfields like Elite without taking up too much
processor time- again, if you like that sort of thing it would be
useful (is anyone trying to write an Elite 2 beater, for instance?))
MIDI (use the MIDI ports... possibly to connect two ST's for multi-
player games?- it has been done, and the results where very
good)
Extra (assorted printer, disk and other commands- a superb
extension, in fact priceless for just the disk format and disk
copy commands! The printer commands have been emulated elsewhere,
but this just goes to show how useful they were in the first place!)
There are others, including Maestro, Maestro Plus, and a
blitter extension by GBP (which is NOT PD, you can get it when
you register the GBP extension). If there are any that I've
missed, and you would like them to be included in my exhaustive
round-up in issue 2 of "E's Got It!", then please send them to me!
(Blatant plug #3)
In answer to your question about the STOS file selector, there is no
way of accessing drives I-P without writing your own custom
routine. (If I get time, I'll write one and send it in). I
found this out the hard way, by copying my STOS and COMPILER
folders, etc onto drive M of my new hard drive, only to find that I
couldn't access anything with the file selector!
I'm also sorry to hear that you're running short of "stuff" to put on
future issues, so I've sent in some more code for you. And, of
course, you could publish what I've already sent you...
By the way, if anyone has any STe specific code, could you be kind
enough to send it to me for inclusion in "E's Got It!"? (Blatant
plug #4, the last one so don't worry...)
Anyway, happy coding to one and all, and come on, keep
bringing out new software for the good old ST!
*/ Thanks for the code, we hope you will also mention ICTARI in your
new magazine. ICTARI /*
--------------------------- ADVERTISEMENTS --------------------------
From: Peter Hibbs
If anyone would like to buy some books the following ones are for
sale from me :-
Tricks & Tips of Atari ST (Data Becker) 5 inc P&P
The concise Atari ST 68000 Programmers Reference Guide 4 inc P&P
Atari ST Internals (Data Becker) 8 inc P&P
Atari ST GEM Programmers Reference (Data Becker) 8 inc P&P
Peeks and Pokes (Data Becker) 3 inc P&P
The Atari ST Companion (Sunshine) 3 inc P&P
Contact me at ICTARI if you are interested in any of these.
---------------------------------------------------------------------
SPRITE WORKS
What is Sprite Works ?
----------------------
Sprite Works is a development package specifically for use with
GFA Basic programmers who want to produce games or demos. With
over 111 dedicated machine code commands that can be added to GFA
it will out-perform anything written in STOS even with all of its
available extensions.
But it's not just for GFA programmers, it's also invaluable to
assembly programmers as the full assembly code to the commands are
also included.
Also in the Sprite Works package is a fully fledged art package,
two map designers and a sample editor so no other external
programs are needed. Extensive documentation is given on disk and
an optional printed manual is also available, every command is
given an example for you to run and it even comes with the full
source for one demo, two semi-complete games and two complete
games, including a dynablaster type game.
Here's a full list of the commands :
Command Use
animate_block Set a map block for animation
animate_clear Clear animation entries
animate_map Animate map blocks
backdrop Fast one bit plane tile printer
blit_clip Clip window for blitter chip (BLITTER)
blit_copy Copy block using blitter chip (BLITTER)
blit_get Get block using blitter chip (BLITTER)
blit_put Put block using blitter chip (BLITTER)
box Replacement pbox command
borders_on Turn on top/bottom border removal
borders_off Turns off border removal
box_hit Box collision detection
change_flag Changes map location flags
change_map Changes map location sprite
chip_fx Plays one of 75 sound chip effects
chip_playing Returns whether a chip sound is playing
clip_draw Set up clipping window for draw commands
clip_explosion Set up clipping window for explosions
clip_kopy Set up clipping window for kopy command
clip_on Turn on drawing clipping
clip_off Turn off drawing clipping
clip_sprites Set up clipping window for sprites
clr_lines Clear screen lines
clr_planes Clear selected screen bit planes
cls Fast clear screen
compress Degas Elite screen compressor
copy_line Copies screen lines
copy_screen Fast screen copy
counter_on Installs frame counter
counter_off Removes frame counter
decompress Degas Elite decompressor
depack Depacks ICE & AUTOMATION packers
erase_sprites Erase all sprites printed with print_sprites
explode Creates pixel explosion from screen graphics
fade_to Fades from current palette to new palette
fade_to_black Fades current palette to black
fade_to_white Fades current palette to white
fast_invmask Print preshifted inverted mask of sprite
fast_mask Print preshifted mask of sprite
fast_sprite Print preshifted sprite
fuzz Produces out-of-tune fuzzy TV effect
get_flags Gets the map location flags
get_map Gets the map location sprite
h_wipe Horizontal screen wipe
install_rasters Create raster colour bars
joystick_on Turns on new joystick controller
joystick_off Turns off joystick controller
kopy General purpose copy
line Replacement line command
locate Locates map address, use with print_map
locate_flag Locates map flag address
mapper Print multi-directional scrolling maps
mem_fill Fills memory will bytes
mouse_on Installs new mouse controller
mouse_off Removes new mouse controller
move_parallax Move parallax star field
move_stars Move 3D starfield
music_off Turns off soundchip music
path_calc Calculates bullet path
path_kill Kill bullet path
path_state Returns bullet status
path_update Update bullet position
path_xy Retrieve bullet x/y coordinate
pixel_hit Pixel collision detection
play_bigalec Play Big Alec soundchip music
play_countzero Play Count Zero soundchip music
play_madmax Play Mad Max soundchip music
play_megatizer Play Megatizer format music
play_sentry Play Sentry format music
plot Replacement plot command
plot_explosion Plot selected time frame of explosion
plot_parallax Plot parallax star field
plot_stars Plot 3D starfield
print_invmask Print sprites inverse mask
print_map Print a map screen
print_mask Print sprites mask
print_sprite Print single 16x or 32x sprite
print_sprites Sprite handler, print sprites in one go
protracker Play Protracker module music
reset_palettes Removes palette switching
reset_rasters Remove raster effects
reverse_lines Copies screen lines in reverse
sam_convert Converts between signed/unsigned samples
sam_play Play sample using soundchip
sam_playing Returns whether a sample is playing
sam_stop Stops sample player
sam_wait Waits for sample to end
scroll_banner Updates the banner scroll
set_banner Sets up banner scroll
set_mouse Sets new mouse x,y and max x,y
set_palettes Installs palette switching
set_rasters Sets raster offset
setup_parallax Sets up 3 layer parallax stars
setup_stars Sets up 3D starfield
shrink Shrink sprites in real time
split_screen Dual screen hardware scroller/splitter (STE)
ste_mapper Fast multi-directional mapper command (STE)
ste_playing Check if DMA is playing sample (STE)
ste_sample Play a sample using DMA (STE)
ste_sound Set sound parameters on DMA (STE)
store_kopy Save block in kopy format
store_sprite Save block in sprite format
swap_sync Waits a number of frames and swap screens
text Print 40 column font
text_pro Proportional font text printer
turn_onc Turns on interrupt C - 200 Hz timer
turn_offc Turns off interrupt C
unpack_spc Unpack Spectrum 512 SPC format
view_512 Displays spectrum 512 pictures
v_mapper Prints vertical scrolling maps
v_wipe Vertical screen wipe
wait Waits a number of frames
Some of these commands haven't been seen in any language, let
alone BASIC. ie, pixel explosions, top & bottom border removal
with compatibility with samples !, sprite scaling and STE split
screen hardware scrolling and more ...
Don't take my word for it ...
-----------------------------
'You will not believe the quality of the games that can be
produced with Sprite Works ... Sprite Works is one of the best
things that's happened to GFA BASIC ... genuinely useful
documentation' FIVE STARS - ST Review Issue 23
That was a review of version 1.22 and now the much improved
version 2.0 is available,just how much better can FIVE STARS get ?
What's needed ?
---------------
A colour system with double sided drive and preferably 1Mb or
more memory, although the package does work on 1/2 Mb machines,
and, of course, a version of GFA Basic 3.xx.
How much ?
----------
Just 7.00 for the two disk package.
Where can I find out more ?
---------------------------
Send a blank disk with return postage to:
Mr T.King
Ninth Wave Software
172 Spencers Croft
Harlow
Essex CM18 6JR
------------------------------ End of file --------------------------
