Copy Link
Add to Bookmark
Report
Ictari Issue 14
ICTARI USER GROUP ISSUE 14 September 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 14
==================
ASSEMBLY STFM Overscan techniques.
Nick Bates, Sprite tutorial Part 3.
Code to calculate position of bouncing sprite.
Sign Integer Fraction maths routines.
C GEM Tutorial by J White. Part 3.
Othello game source code.
League table solution.
GFA GFA Manual Part 2.
Dialog box designer program.
STOS STOS accessory to display text files.
Rebound football game.
Plazma screen display code.
MISC Atari Questions and Answers file No 3.
STE hardware information.
Current membership list.
Index to issues 1-13.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Sampled sound play routines.
Sampled sound play routine and editor.
Sound sample conversion routines.
C Music score writing program code.
GFA GFA Manual Part 3.
STOS Disco display and sound program.
Timing routine
MISC Date to day conversion algorithm.
Atari Questions and Answers file No 3.
Information on sampled sounds and PSG chip.
PSG Musical note/register code listing.
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).
Picture switching techniques.
Printer driver code for printing mono/colour images.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
As a result of a mention in ST Format magazine we have had a total of
27 enquiries about ICTARI since the middle of July and so far 11 have
joined the group (including two from Sweden). Hopefully some more will
join later, anyway welcome to all the new members.
SURVEY
------
We have done a small survey on languages used and hardware owned. The
percentages refer to the numbers used compared with the total number
of members (60) although a lot of members do program in more than one
language.
Languages.
C 34 83% (Mainly Lattice C)
Assembler 31 51% (Mainly DevPac 2 or 3)
GFA BASIC 18 30%
STOS BASIC 13 21%
HISOFT BASIC 11 18%
PASCAL 10 16%
COBOL 2 3%
FORTH 1 1%
LISP 1 1%
PROLOG 1 1%
FORTRAN 1 1%
APL 1 1%
LOGO 1 1%
SMALLTALK 1 1%
MODULA2 1 1%
CORAL66 1 1%
Hardware.
STF/STE 50 83
Falcon 11 18%
TT 0 0%
Mega 1 1%
Hard Drives 38 63%
Scanners 13 21%
Printers 24 40%
Modems 10 16%
Sound samplers 11 11%
MIDI keyboards 1 1%
Tabby pens 3 5%
These figures are very rough, however, because the questionnaire did
not ask for the type of computer used (STF/STFM/STE) and also most
Falcons have already got hard drives built in. We also suspect that
more members have printers but didn't bother to mention it.
Although we cover C, Assembler and the various Basics fairly well we
haven't published any Pascal code recently. If any of the Pascal users
would like to send something in we would be happy to use it in a later
issue. Also, the figures mentioned above refer to the information
provided in the questionnaires. If you have upgraded your hardware
please let us know so that we can keep our records updated.
SAMPLED SOUND
-------------
Next month we are publishing a number of articles on sound sampling on
the STFM and STE. If anyone has something available on this subject,
please send them in straight away so that we can start putting
together the disk mag.
PICTURE IMAGES
--------------
In the November issue we will be publishing some articles on encoding
and decoding various picture file formats. If you have written any
code in any language on this subject, please send it in as soon as
possible.
DISK FORMAT
-----------
Due to the large amount of data on this disk we had to format it with
10 sectors per track (80 tracks). Please bear this in mind if making
copies of the disk.
LETTERS
-------
We would like to publish more letters in the correspondence section so
when you return a disk please include some comments if you can. A
programming query, what you would like to see on future disks or
whatever. We also still need articles for future issues so if you have
not sent anything in yet and there is something you think you can
contribute, please send it in when you can. The ICTARI group relies
almost entirely on its members for its material so if nobody sends
anything in we will not have anything to publish.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: GNU C and C++ GURUS.
From: Jim Ford
I am using GNU C and C++ (versions 2.1) and have run into some
problems that you gurus out there might have some answers to.
1: Using the 'curses' library, I can't get the 'scanw' function or its
relatives 'wscanw' and 'mvscanw' to work. The following code
demonstrates the problem:-
int main(void)
{
char ch = 'A';
initscr();
erase();
mvprintw(LINES - 1, 0, "Enter a char: ");
refresh();
scanw("%c", &ch);
mvprintw(10, 10, "The char was:%c", ch);
refresh();
endwin();
return 0;
}
Whatever the input, 'A' is always printed. If 'char' is not
initialised then garbage is printed. The same problem occurs with
other data types. A 'workaround' for this problem is to get the data
using 'wgetstr' and convert the string to a double using 'atof()', but
I'd rather have a proper fix for the problem so I don't have to
remember not to use 'scanw'.
2: I'd like to use the 'curses' library with C++ using the C++ idiom,
but when I include the 'xcurses.h' header the preprocessor doesn't
like what it finds and typically reports:-
'xcurses.h:88 macro 'getyx' used with only 2 args'
The problem appears to be that when macro substitution, invoked by the
'curses.h' header (included by 'xcurses.h') takes place, the
preprocessor doesn't recognise that the functions are missing an
argument because they are overloaded.
This 'do nothing' code doesn't get past the preprocessor because of
this:-
#include <xcursesw.h>
int main (void)
{
return 0;
}
3: The last problem relates to the C++ 'cin' function. I want to input
a sequence of floating point numbers using a while loop. The code:-
float number;
while (cin >> number)
{
.
.
.
}
ought to work - 'cin >> number' should return an ostream object that
is true as long as 'number' is of the expected type - in this case a
float. If data of another type e.g. the char 'a' is input then the
returned value is 0 and the loop terminates. What happens is that the
floats are input OK, but when attempting to exit with a 'q' or other
alpha, garbage is printed and the program crashes (2 bombs).
I would be grateful for any advice or info where I can get copies of
libraries with these problems fixed.
----------------------------------------------------------------------
To ICTARI
From Mrten Lindstrm
ICTARI seems to be exactly what I have been looking for. A forum for
exchange of ideas, techniques and not least information. Finding
information is, in my experience, the hardest part of programming. One
needs information on the system (TOS and Atari computer) but as much,
and harder to find, on the file formats and programming standards etc.
that could make programs live and work in harmony with each other, and
with each others data. So I am very much looking forward to the
announced ICTARI effort to clarify sound on the Atari.
Text formats: For anyone interested I could describe the Protext file
format. I could also say something about the First Word and ST Writer
formats, although someone else is bound to know more about these (but
could perhaps fill me in).
*/ Would anyone be interested in these Word Processor formats, please
let us know. We think the Rich Text Format (RTF) would be useful to
publish so that anyone writing text editing programs could include
this format. If anyone has a detailed description of RTF please send
it in. ICTARI /*
To Mike Barnard, ICTARI and all others
______________________________
Comments on the VBL interrupt.
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Mike Barnard explained most about the VBL interrupt in ICTARI 13, but
made a request for some "gap-filling", and this is an attempt at that.
Firstly, there should be no problems with using the stack in your VBL
routines. Any VBL routine will always run in SUPERVISOR mode (even if
your main program runs in user mode), and the ban in the books,
against touching the USER stack pointer, must be just an advice that
you don't, for any strange reason, use a command like "move A0,USP",
since that may obviously create problems when execution is returned to
the main program (in user mode) after the VBL.
To the description of the VBL-interrupt I'd like to make the following
additions (using the same numbering as Mike):
2 and 13. VBLSEM (Word at $452) is initialised at bootup to 1 (one).
It is decreased (-1) at start and increased (+1) at end of each VBL.
If the decrease makes VBLSEM negative (i.e. if it is ó0 before VBL)
the VBL will be skipped completely except for updating FRCLOCK (and
restoring VBLSEM to what it was before the decrease).
Thus, by subtracting one from VBLSEM, the VBL can be turned off, and
by adding one it can be turned on again. And these "commands" can be
nested - i.e. the actual turn-on will happen only when all routines
(possibly including a VBL) that issued "turn-offs" are ready and have
issued "turn-ons" again.
5. Screen mode and monitor type are checked as follows (on an ST/E):
The hardware Video Shifter mode register (Byte at $FF8260) is read,
and from this it is determined what resolution (high/medium/low) the
screen is currently in. (The register - or its two lowest bits - will
be 2 for high, 1 for medium and 0 for low.) A corresponding check is
made of bit 7 in byte $FFFA01, which is hardware connected to a pin in
the monitor port and will be zero if a mono-monitor is connected.
In case of a mismatch between screen mode and monitor type, the screen
mode is changed, i.e. written to byte $FF8260. (If the change is from
high to a colour rez, the actual rez - low or medium - will be that of
defshiftmod: Word at $44A. This change will be done immediately while
a change from colour to high will be preceded by a pause of about 3
milliseconds.) After a change, the VBL will execute the "subroutine"
pointed to by SWV_VEC (Long at $46E) which will actually be
initialised simply to a computer reset (pointer to OS-start).
8. BOTH physical AND logical screen are set according to the one
pointer in SCREENPT. In addition SCREENPT is not, unlike COLORPTR,
automatically zeroed after being used. So I personally do not see why
anyone would like to use it. (And I haven't seen that the system does
either.) Use XBIOS call SETSCREEN instead.
9. The floppy VBL routines. Before these are run, the variable FLOCK
(Word at $43E) is checked; if FLOCK is non-zero the floppy routines
are skipped. (FLOCK signals that someone is accessing disks at the
moment. It is set automatically by all system calls for reading/-
writing disks, and should be checked and set - and cleared when ready
- by any disk routine not using system calls.)
The floppy routines do exactly the two things stated by Mike Barnard:
a) Check for possible floppy disk change
b) Deselect floppies when controller signals it has turned motor off.
The first of these - a) - is actually a check of the write-protect
flag for drive A and B (every 8th VBL, or every 16th VBL for each
drive; this unremitting activity can be detected by anyone as a faint
flicker in the drive lamp). If the write-protect flag is set, a note
is made that the disk may have been taken out of the drive (thus
leaving a "hole" where the write-protect tab is supposed to be), and
that - when a disk-access is to be made after a certain time delay - a
further check may have to be undertaken by TOS (a comparison of the
disk serial number with the one read earlier).
b) will only be done if the drives were used with a system disk call.
(The VBL routine checks an internal flag before bothering to check the
motor-on bit.) A routine that doesn't use system calls for disk access
has to wait for the floppy controller to zero the motor-on bit (about
a second after last access) and then deselect floppies itself.
----------------------------------------------------------------------
To *.*
From Kevin Preece
A request, I have written routines to perform 4-way hardware tile
based scrolling on my STE, but now I would like to extend it to do 8-
way scrolling. Does anyone have any routines to do this on an STE, or
can anyone explain it in English? Book or Internet references would
be fine. Thanks in advance.
----------------------------------------------------------------------
To Nick Bates and anyone else interested in C
From Dick Teuber
Last month I mentioned HiSofts C Interpreter program as a possible
alternative to Lattice C. In case you haven't seen any magazine
adverts lately, HiSoft are now selling the C Interpreter program for a
mere 9.95 and since the manual alone is worth more than this I would
suggest that now is the time to purchase it. Also the Lattice C 5.52
program and manuals are available for only 39.95 and Power BASIC for
19.95 which are also good bargains.
*/ Perhaps HiSoft should be paying us a commission for this hard
selling. ICTARI */
----------------------------------------------------------------------
To: Everyone
From: Richard Evans
When running Gulam under the VT52 emulator included with MagiC, the
text cursor often vanishes when GEM programs return back to the CLI
after execution. I thought that a simple program sending the VT52
enable cursor code (ESC e) would be enough to redisplay it. However,
although this works sometimes, it appears that these text cursor codes
are nested much in the way that the graf_mouse M_OFF and M_ON routines
are, since I sometimes have to run my program 6 or more times in a row
before the text cursor re-appears. Obviously this isn't much good. I
know that the mouse cursor can be displayed from any depth by calling
linea9 with INTIN[0]=0. Does anyone know if there is a similar call
that will display the text cursor from any depth, or am I wrong in my
assumptions altogether?
P.S. I need the Kawai K4 driver for Lizard V1.0, If anyone has one, or
knows how I can get one, please get in contact with me. Thanks.
----------------------------------------------------------------------
To ICTARI
From Richard Davey (fog@walusoft.centron.com)
Some problems with HiSoft Basic 2.10
= Why can I not use the HGT.T token file and use the GEMVDI library
in the same program? I keep getting errors reporting I have redefined
some functions, although I know it was nothing my code has done.
Once I remove one or the other the code compiles fine but obviously
does not run.
= Does anyone know how to load and display a NEO picture on the
screen with the correct palette installed on a Falcon? The picture
appears but all hell breaks loose in the colour department. I
tried using the PALETTE x,&hxxx command to set the palette to that
of the picture but for some reason it still didn't work. Help
anyone???
= Is there any way to include required files WITHIN the actual
compiled PRG file. So for example if I had 5 text files, how could
I have them already in memory instead of having to have them on disk
and then load them up into the array? This would certainly tidy up
my programs and also means a little more protection would be given
over my data files which anyone can 'rip' at present.
= My final problem is with DMA sound. I cannot seem to get the
STESOUND library commands to work, this can't be due to my Falcon can
it? After all they do share the same DMA chips. If someone has
some example source code (and indeed a sample) to show me how to play
a sampled sound via the DMA it would be very much appreciated.
----------------------------------------------------------------------
To ICTARI
Fron Iain McLeod
It would be nice to know what percentage of users own TTs, Falcons,
STEs, etc..
What's the best way to map a bitmap on to a polygon ? Using C or
Assembly - or even DSP.
*/ See above for membership survey. We presume you want to display a
bitmap image within an irregular polygon in the same way that the GEM
fill function does. Does anyone have a suitable algorithm or source
code for this operation ? ICTARI. /*
---------------------------- End of file -----------------------------
