Copy Link
Add to Bookmark
Report
Ictari Issue 12
ICTARI USER GROUP ISSUE 12 July 1994
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* 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. 0425-474415
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
INDEX FOR ISSUE 12
==================
ASSEMBLY Load file routines.
Colour palette fading routines for STFM & STE
User defined mouse shapes for GEM programs.
Sprite drawing routines.
Sprite tutorial Part 1. Beating the 16 pixel boundary.
Updates for Cookie find & Mouse routines.
C Fractal drawing code.
GEM Tutorial by J White. Part 2. Initialising GEM.
GFA GFA Manual Part 1 of 3.
GFA Alert box designer program.
STOS Bootview program code.
Pipe perfect game.
MISC Analyzer program to display info on system crashes.
Atari Questions and Answers file No 1.
Warning for DevPac 3 and Lattice C users.
Current membership list.
Index for issues 1-11.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Setting up system timers.
Vertical Blanking List (VBL) notes.
Colour cycling on raster lines.
Sprite tutorial Part 2.
Keyboard equate file.
Compare/Case routines.
C C Graphics extensions.
Various C functions for use with GEM dialogs.
GEM Tutorial by J White. Part 3.
GFA GFA Manual Part 2 of 3.
Sound sample play routines.
STOS STOS extra extensions.
STOS accessory.
MISC Atari Questions and Answers file No 2.
For future issues :-
Polyline drawing routines in machine code.
Bezier curve drawing routines.
Picture decompression routines for IMG, Degas, Tiny, PCX, PAC, etc.
Picture compression routine for IMG pictures.
HP DeskJet/LaserJet compression routines (Mode 2 TIFF).
Playing sound samples on non STE machines.
Picture switching techniques.
Printer driver code for printing mono/colour images.
Signed integer fraction maths routines.
GFA Dialogue box designer.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
ÿÿÿÿÿÿÿÿÿÿ
As a result of recent publicity we have had five new members join this
month, including one from Greece, welcome to them. To date we have had
22 inquiries about joining the group and 15 have actually joined. I
wonder why the others didn't, oh well.
ARTICLES
ÿÿÿÿÿÿÿÿ
Earlier this month I started to upgrade my hard disk from 65Mb to
170Mb by swapping the bare SCSI drives. Unfortunately, during the
transfer of data from hard disk to floppies to hard disk, I had a
major problem with some disks which resulted in the loss of some of
the data from one partition. Most of my own source code was backed up
and I recovered this OK, unfortunately some of the ICTARI material
which has been sent in was not stored separately and some of this was
lost. I do keep rough records of who has sent in what and I have
contacted those members who sent in articles/source code for
replacements. However, if you sent in some material in the last 4
months and I have not contacted you about replacing it, perhaps you
would send in another disk with the same material. The only article I
know I have lost and I cannot remember who sent it in is one about the
STE hardware, could the member who sent it please send me another
copy.
LANGUAGE CONVERSIONS
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
We often publish source code for various functions in one language
which would probably be of use to other members but in a different
language. On this disk there are several routines and programs such as
the GFA alert box designer, mouse shape change routine, colour fade
routine, etc which could be of use to programmers in other languages.
If any member who is clever enough to be able to write in more than
one language would like to provide alternative versions of any code
published in the ICTARI magazine I am sure a lot of our members would
be grateful.
NEW ARTICLES
ÿÿÿÿÿÿÿÿÿÿÿÿ
We still need articles/source code for future magazines in all
languages. We do have some Public Domain material in hand but we want
to keep the use of this to a minimum since some members will already
have seen it. Out of the 50 or so members that we now have, just 16
have sent in material that they have written themselves. So if you can
send us any code (or programming queries) over the next few months,
please do.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To *.*
From Martin Cubitt
I need your help in writing three separate routines in assembler.
Although it is really the algorithm that I require, the source would
obviously save me a lot of time and hassle.
Firstly, I need a routine which will allow me to scroll a screen (32K
block of data holding either a picture or more likely text) in the
method used by the film Starwars. The illusion is that the text is not
just running up the screen but is fading into the background giving a
three dimensional perspective of the scrolling. I want to write code
in STOS but I am sure it would be too slow and cumbersome (unless
anyone can prove me wrong!). I can however write the code in assembler
and call the routine from STOS. Any takers ?
Secondly, I would like the source to a clearly written routine which
allows me to format discs with extended format options, such as extra
tracks and sectors per track.
Finally, in the STOS EXTRA extension (*/ see next month /*) I wrote a
new command called PPSC, Pixel Perfect Screen Copy. The routine is
fairly slow as it literally takes every bit of every plane within a
selected block on the screen and copies that bit to another block of
the same size. A facility exists in STOS to do this, called screen
copy, but it limits the user to a word boundary for the block. Has
anyone an algorithm to allow sections of one screen to be copied to
another (in any of the standard three resolutions) ? An option would
also be required to allow a selection on the number of planes to copy
so by selecting only the first plane the whole operation is very fast
but only a few colours will be affected. The parameters passed to the
routine would be the source address, destination address, source start
x, source start y, source end x, source end y, destination start x,
destination start y and the number of planes. Oh, this is for STOS and
as STOS does not use GEM please do not suggest or use any GEM
functions. I tried a series of loading bytes and shifting them into a
buffer and eventually placing them into the destination but I just
could not get my head around it. One for the clever people I think !
Any joy you can give will be greatly appreciated and any resulting
code will be fully acknowledged as being yours. I will not profit in
any way from using the proposed code so I am afraid I can only credit
you in the program and not financially.
*/ Can anyone help with the above. It sounds as though the BitBlit
function which can be used via the ALine calls (and so does not
involve using GEM) would do the job but we haven't used it ourselves.
Does anyone have any code to do this. ICTARI /*
----------------------------------------------------------------------
To *.*
From Nick Bates
I have decided I am not going to do any more C coding unless I get
myself a decent C compiler, namely Lattice C. Unfortunately it's a bit
expensive to buy new, therefore if there are any ex C coders out there
with a copy to sell please contact me. My address is in the members
file.
----------------------------------------------------------------------
To *.*
From Carl Pattinson
Has anybody got any info (or if possible source code) for writing the
compiler extensions for STOS in assembly language. I already know how
to write the basic extensions and would gladly exchange that knowledge
in return for the info on the compiler extension. It would help in an
extension that I am hoping to produce. My address and phone number is
in the MEMBERS.TXT file for any correspondence, or even better forward
the information to ICTARI so that all of the members can have access
to it.
----------------------------------------------------------------------
To: ICTARI
From: Paul Laddie Aka BYTEMAN
I have recently started writing a disk copier & formatter, at the
moment I am writing the basic framework to copy & format disks, I
will design the interface later, but I have encountered a problem, is
it possible to format a disk with 11 sectors per track using the XBIOS
10 (flopfmt) routine, I cannot get it to do this at the moment, I
would appreciate anybody's help on this.
----------------------------------------------------------------------
To ICTARI
From PoshPaws
RS232 Bugs:
Most versions of TOS have a problem with Hardware Handshaking on the
RS232 port. The RTS/CTS routine can be assumed not to work properly on
almost all TOS versions. This is the only RS232 bug that I know of and
has many AUTO fixes in PD. I think it caused a raising and lowering of
RTS/CTS on every byte sent, rather than at high and low tide marks
(buffer nearly full/nearly empty).
Falcon Compatability:
The main points to note about the Falcon are that LineA is not fully
implemented for modes above 16 colours and that the "guarenteed not to
change" variable for the memory configuration is not usable as a guide
to memory fitted as it equates to 256K on 'all' Falcons. Use Memtop &
Membot instead if you need to know what memory is fitted.
Most other things work O.K. although the lowest frequency setting of
STE DMA Sound will produce silence on the Falcon. Use the next higher
frequency.
Exceptions use a larger stack space so always return using RTE and
most importantly DON'T USE SELF MODIFYING CODE (or Inline parameter
passing!) as the 68030 has separate data & instruction caches, so
won't know if instructions have been changed on the fly.
From memory, that's it - send me a Beta test if it's any help.
Sub-routines:
I notice you say to save and restore all registers used within sub-
routines, but I have found it better to write all sub-routines to
follow Atari's own philosophy - Use A0-A3/D0-D3 freely in any sub-
routine (as TOS does this) and make all library sub-routines save any
registers they use above this. That way you know, no matter what
library routine you pull in, you only have to worry about A0-A3/D0-D3
getting corrupted, anything else is safe!
What I want:
I want to know anything at all about SPEEDOGDOS Fonts; how the font
files are made up and what the new commands actually do. I have the
official Atari developers book, but it's written by a Techno Boffin in
shorthand! I also have the Hisoft book, but that's just an
programmer's translation from Techno Boffin into standard Font Jargon!
I also want a SPEEDOGDOS driver for either a Canon BJC-600 or an Epson
LQ2550, but I suppose I will just have to wish. How about info on how
to make *.SYS drivers (old and new)?
Why don't we get the info we need to keep to their rules. IS THIS
REALLY TOO MUCH TO ASK? - ATARI SAY YES - ALL THE ABOVE IS NOT
AVAILABLE!
End of Whinge - End of Whinge - End of Whinge - End of Whinge
ICTARI 11
=========
To: Mic Barnard
From: Simon Rigby
Subject: SetScreen
In answer to your question the BIOS does NOT recognise the setting of
either Physical or Logical Screens and will continue to write to the
PHYSICAL Screen it started with. Only GEM & LineA will write to the
LOGICAL Screen! (Also you do not need to wait for Vblank before the
change as it will do that as part of the call).
Now, to tell the BIOS that you have changed screens, you need to pass
the resolution as something other than -1. Even if you use the same
resolution as it's currently in, it will update the BIOS. The problem
with that is that it also clears the (new) Physical Screen and will
still only write to the Physical Screen.
Subject: Assembly.
BSR xxx always uses 18 cycles on the 68000.
JSR (Ax) takes 16 cycles but you have to load Ax.
JSR xxx.W takes 18 cycles but the address is in the bottom 64K of
memory.
JSR xxx.L takes 20 cycles and is the only viable alternative to bsr
for single sub-routine branches.
Note: If you write a sub-routine, it is because more than one part of
a program is likely to use it. This makes it potentially similar to a
loop in large programs, as it may be used many times.
Your comments on addq #x,Ay are correct but add.W #x,Ay is quicker
than add.L #x,Ay. Comments on clr.l $xxxx & move.l #0,$xxxx are
correct. Sorry for any confusion!
To: All
From: Simon Rigby
For those of you that use graphics routines with integers, here is a
quick outline of how to do integer square roots.
1] Take a Long Number in d1 & d2
2] Put a one in d0
3] Test if d1>4
4] If yes, shift d1 right by two, shift d0 left by one, goto step 3
5] d0 now contains first guess (word size)
6] Put d0 in d3 for later comparison (d3 is last guess)
6] Put d2 in d1
7] divide d1 by d0
8] Add Answer.w from step 7 into d0
9] Shift d0 right by one (Average of two answers)
10] if d0=d3 then goto step 13 answer is d0
11] if d0=d3+1 or d0=d3-1 then goto step 13 - d0 is less than 1 from
answer
12] goto step 6
13] STOP answer is in d0
Hope this helps someone - its all I've got time to give right now!
P.S. NewTwist still bombs if you leave it long enough, something to do
with the text buffer overflowing I think?!.
Si(gh).
----------------------------------------------------------------------
To ICTARI
From John Phillips
WOOD LICE. ICTARI 7
This sending wood lice through the mail has got to stop. It is illegal
to post any item that is likely to alarm, discomfort or otherwise
embarrass one of Her Majesty's mail carriers. A treasonable offence if
I'm not mistaken.
Tangents and Splines. ICTARI 8
Tangents are something I wouldn't want to touch with a bargepole.
There would appear to be two main approaches to this, the first
analytical, the second iterative. The method will vary depending on
what you are trying to do - draw a tangent at a point ON the curve or
draw a tangent from an outside point TO a curve. The following
considers the first case only.
The analytical approach is reasonably straightforward but is only
possible if the curve has been generated from a known function
(ideally expressed as a power series). If it is then it should be a
simple matter to form enough of the derived function to calculate the
tangent accordingly. Any basic text on calculus will explain the
method. Certain curves have properties that mean you won't need to
resort to calculus. The normal to a curve passes through the centre of
curvature for that point, so with any curve for which the C of C is
known, the slope of the normal can be easily calculated. This would
obviously be the preferred method for circles or arcs of circles.
Again any text on analytical geometry will give details.
The iterative approach would require only the set of defined points
that make up the curve and a good guess to start things off. One
approach might involve progressively adjusting the position of the
guess line until the number of pixels both to the right of the line
and left of the curve is zero (or whatever). A second approach might
be to draw a chord through the starting point and some neighbouring
point and then moving a line parallel to this until it just touches
the curve, this will then define a second point with which the process
can be repeated to a limit. Or again you might like to try fitting
circles to the curve in the required region and using the centre of
curvature properties.
The core of any of these methods would involve developing a routine to
find the intersection(s) of a line with a curve.
All these processes would be very hit and miss and only really
suitable for well behaved functions (something that is nicely convex
would be ideal), The whole process would be fraught with danger, not
the least because this requires floating point arithmetic acting on
sets of purely integer values. How you would cope with singularities,
assymtopes, points of inflection, and re-entrant curves will also take
a lot of thought. As I say, not something I care to get involved in.
I've seen some code for generating spline curves somewhere, I'll try
and sort it out for next month if I can find it again.
W_VDI109.GFA ICTARI 10
The whole of the VDI 109 routines in this program can be replaced with
the single command RC_COPY. GFA supplies this command (designed to
complement the RC_INTERSECT function) for exactly this purpose of
redrawing windows. Copying from screen to memory is even more easily
accomplished in this example by dumping the whole lot with BMOVE. Note
that RC_COPY only operates on screen size blocks, for other sizes you
could use the VDI version of the BITBLT command (the one with
s_mfdb(), d_mfdb(), p()) instead.
The memory handling is very suspect and will not operate in the way
the author intended. In the real world you could expect all sorts of
trouble if window number 1 is closed and there are other programs
claiming memory in the system.
Watch out for the typo in line 139.
I've dug around for a big chunk of code to send you and have come up
with the inevitable Mandelbrot thing called MANIBROT.GFA. This was
written in pre TOS 1.4 days and includes its own FSEL routine, I just
couldn't take the ATARI mess of a file selector any longer. This is
less of a problem now that alternative file selectors are available
and the program would probably be better without it nowadays.
('Selectric' looks as if it will be good, but it still has obvious
bugs and I don't trust it at present - version 1.10).
Same applies to the GEM Alert boxes which are not very adaptable so
I've provided my own version sfbox(). There should be plenty of other
routines of interest to GFA users, sorting, directory handling,
formatting, the IFF format (Degas .BL1) etc. though I'm afraid there
is not much in the way of comments, I rely far too much on variable
names and structure to make sense of my work. Anything you don't
understand - ask. The code doesn't really represent the way I program
nowadays, I've moved much more towards lower level routines to secure
better GEM compatibility.
This program benefits tremendously if it is compiled. In fact the
whole thing could do with a good going over, it's been put together
from bits and pieces so there are rather a lot of odd little fixes.
What is the derivation of the mysterious 'foobar' so beloved of 'C'
programmers ?
*/ Thanks for the code John, we shall be publishing it later in the
year. ICTARI /*
----------------------------------------------------------------------
To: All
From: Mark Baker
Anyone who has read the Compendium will have realised that the key
shortcuts in the style guide differ slightly from those used by
programs like Everest, Papyrus etc. These are following a different
style guide in the German Profibuch. A number of people on the
Internet are discussing a single more comprehensive style guide. If
you want a say in this and have an Internet mail facility, send an
email to :-
major-domo@world.std.com
with message text
subscribe gem-list my_internet_address
This will put you on a mailing list so you will receive copies of all
mail sent to the list. To post mail to the list and therefore to
everyone on it, send an email to :-
gem-list@world.std.com
------------------------------- End of file --------------------------
