Copy Link
Add to Bookmark
Report
Ictari Issue 15
ICTARI USER GROUP ISSUE 15 October 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 15
==================
ASSEMBLY DMA sampled sound play routines.
PSG sampled sound play routine and editor program.
Sound sample conversion routines.
C Falcon DSP sound playing routines.
GEM Tutorial by J White. Part 5.
GFA GFA Manual Part 3.
DMA sound playing routines.
STOS Disco display and sound play program with notes.
Dot matrix count up timer routine.
MISC Algorithm Corner. Date to day conversion algorithm.
Atari Questions and Answers file No 4.
Information on sampled sounds and PSG chip.
PSG Musical note/register code listing.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY IMG picture decoding routine.
PI3/PC3 picture decoding routine.
TNY/TN3 picture decoding routine.
PCX picture decoding routine.
PAC picture decoding routine.
C TNY picture decoding routine.
LZW TIFF compression definitions and algorithms.
GFA CrackArt picture compression/decompression code.
Spectrum (SPU) picture format information and code.
Tiny picture decompression code.
STOS Using 80 column text in low rez.
VDU dump program.
MISC Video Master picture file format information.
Falcon screen resolution detection.
The IMG, IFF ILBM formats plus the EDT sprite file.
Atari Questions and Answers file No 5.
For future issues :-
Polyline drawing routines in machine code.
Bezier curve drawing routines.
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.
Using Calamus fonts.
Sorting algorithms.
Using the BitBlit routines.
Programmers view of the MagiC OS and using GEM C with MagiC.
Code for using the File Selector.
DevPac Macro AES/VDI reference sheets.
Using multiple rasters in machine code.
GFA Mandlebrot pattern generator.
Prime number generator in C.
GFA menu locate techniques.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
Membership continues to increase with another 5 members joining this
month including one from Finland although a couple have also cancelled
their membership. Also this months edition of Atari ST User magazine
have published a letter I sent to them which, hopefully, will attract
a few more members.
ALGORITHM CORNER
----------------
This month we are starting an 'Algorithm Corner' section by Simon
Rigby in which a software problem is described as an algorithm rather
than actual code. This has the advantage that the programmer can use
his preferred language to convert the algorithm into the required
source code. If you have any programming problems that could be
defined as an algorithm and which may be of interest to other members,
please send them in to us at ICTARI.
SOUND LAB
---------
As you can see we are publishing a number of items concerning sound
sampling in various languages this month. However, before you can play
a sample, you need to be able to sample a sound and test it or use
samples that can be obtained from PD libraries. A program called Sound
Lab by Damien Jones is available from various PD libraries which can
play, edit, convert and alter various different sound formats and we
would recommend it to anyone who does not already have a suitable
sound editing program. The version we have is V1.0, if anyone has a
later version we would be interested to know about it.
ARTICLES
--------
Although we have a few articles in hand for the next two disks we
still need material for future issues. If you have not contributed yet
to the magazine please try and put together an article or source code
and send it in to us. Feel free to contact us by telephone if you
would like to discuss a particular subject.
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.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: John Logan and others
From: Peter Hibbs
Having used the excellent SIF maths routines in some bezier curve code
I was interested in the two books you mentioned in the article.
Unfortunately, according to my local book store, the 'Microprocessors
and Microcomputers - Their use and programming' is no longer available
and the 'Computer Arithmetic - Logic and Design' costs 58.95. Is
there any chance that you (or anyone else that has similar computer
related text books) could write a short review of the contents of the
books so that we can decide whether it is worth spending large amounts
of money on such books.
----------------------------------------------------------------------
To: Steven <Diamond Software>
From: Kevin Preece <kev@qsilver.demon.co.uk>
A while ago I started to write a TIFF decoder, but for many reasons it
never really got off the ground. I did however write some routines to
compress/decompress files using the LZW scheme that this standard
requires. Anyway here they are. LZW.C, LZW.H and UNLZW.C are the
sources.
The source is standard ANSI C and you should be able to compile it
with any decent compiler. I tried it with GNU C and DICE.
I have not had time to check that they work properly, though I am
confident that the compression side is ok. The decompressor as it
stands crashes horribly, but the basic routine is good. If I get time
I'll work on them for the next issue ... no promises though.
Compression rates are not spectacular when compared to the current
'state of the art' routines such as LZH or ZIP, but they give about
40% for text files and about 25% for binary (programs). Pictures may
give more if they contain a lot of redundancy.
A note on the source. The input file is broken up into blocks, the
size of which is given by the #define BLOCK_SIZE. Increasing the size
of the blocks improves compression, because the routine can build
better string tables that hold longer strings. If you do change the
value of BUFFER_SIZE though make sure that you change MAX_CODE and
HASHMAX too - these must be at least as large as BUFFER_SIZE. Note
also that to minimise the number of hash table clashes, HASHMAX must
be a prime number and must be >= MAX_CODE.
Speed wise it is fair, taking about 30-40 secounds (a guess) for a 50k
file. It is not too hungry for memory either (although it could be
improved).
Somewhere I have source code for ZIP (de)compression. I'll see if I
can find it, again for the next issue.
*/ See next month for these files. ICTARI /*
----------------------------------------------------------------------
To: Various members
From: Mark Baker
I'm working on a shell for Lattice C that will work correctly under
MultiTOS and MagiC allowing you to compile in the background. It will
leave the project open in a window and you double click on a file
there to load your favourite text editor. Does anyone have any
suggestions of what I should include in this? I might also be looking
for á-testers, but that's some way off still.
To: Jim Ford
============
>I am using GNU C and C++ (versions 2.1)
The latest version I have heard of is 2.5.8.
To: Richard Davey
=================
>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 ???
In what video mode is that?
Try using the Falcon specific VsetRGB() call (xbios 93) which takes
the index of the first colour to change, the number of colours to
change and a pointer to an array of longs which each contain a 24bit
colour value.
Or you could use the vdi vs_color() call.
>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.
I'm not sure how you would do it in Hisoft Basic. One possibility
would be to write a program that converts it to DATA statements.
Another would be to store it all in one big string or array as
appropriate, again you can write a program to convert it
automatically. GFA Basic has an inline statement which makes it very
easy but I don't know if HSbasic has a similar option.
To: Ian MacLeod
===============
>What's the best way to map a bitmap on to a polygon ? Using C or
>Assembly - or even DSP.
>
>*/ ... 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. /*
I thought he meant stretching a picture to a funny shape, like the
distort functions of some art packages. For a quadrilateral it's
fairly easily, you split two opposite sides into the number of pixels
across the bitmap and the other two sides into the number of pixels
down the bitmap. Joining opposite sides gives a grid of quadrilaterals
one corresponding to each pixel of the bitmap. I can't think how you
would even begin doing any other shape though.
>Jonathon White's GEM programming tutorial
>=========================================
>Hello again. Time to take a further look at the intricacies of GEM
>programming. Some of you may know that GEM is a WIMP interface, a posh
>name for a GUI though? Well no, actually; the WIMP idea is very
>important. The four things those letters stand for :-
>[cut]
>
>are the four essential requirements the research team at Xerox first
>identified as being required for a properly functioning Graphical User
>Interface. If you don't have all of these all you have is a fancy menu
>system.
>
>WIMP was the original name AIUI. When Microsoft released Windows which
>didn't use icons (not to represent files in the way the Atari does)
>they invented the term GUI for it.
>
>Menu Word Contents
> 0 10 (will be defined somewhere as MN_SELECTED, so you
> can use that)
> 3 Object number of menu title
> 4 Object number of menu item
Also 5 and 6 together contain the address of the object tree. This is
used with submenus, to identify which menu it is from. In this case 7
contains the number of the item of the submenu's parent.
>Note you TECHNICALLY cannot enable / disable menu titles. However,
>there is an undocumented feature such that if you call this with the
>top bit of the object no set to 1 (requires bit-twiddling), the AES
>will disable the title. I haven't been able to verify which versions
>of the AES this works in, so really you ought to do this by directly
>altering the object structure, which we'll know how to do soon enough.
According to the Lattice C manual you can enable/disable titles on TOS
1,2 and above, it doesn't mention setting the top bit. I tried this
and they do then behave as disabled but are still shown in black (in
MultiTOS if you switch to a different application and back again they
are then grey). I assume altering the structure will have the same
effect of altering it but not redrawing.
BTW, I'm don't think your description of the menu structure is
correct. According to the Compendium the root has two children, one is
a white bar containing the titles, the other is an IBOX big enough to
contain all the menus which are its children. The desktop background
is totally separate.
>Othello program
>===============
>The makefile doesn't do any compilation, it just links AFAICS! I'm
>sure this is just an oversight.
To: J Levon
===========
>When I set a dialogue to colour 8 in WERCS (the Falcon grey, as in
>WinRec), in 2-colour mode it changes to black (as it should). This
>makes the dial unreadable. In WinRec and similar Falcon programs, the
>dial is white in 2-colour mode. How do I accomplish this ? Do I have
>to dig into the resource file and change the colour to 0 (White) when
>my program detects a 2-colour mode ?
No, all your dialogues should be white and unfilled. You set the
FL3DBAK flag (`Background' in the Flags menu of WERCS) and GEM will
draw it grey - or whatever colour the user selects - on the Falcon.
Buttons should be FL3DACT or FL3DIND (`Activator' or `Indicator') as
appropriate if you want them rendered in 3D.
>Also, I can't get FLDLIB (from ICTARI 11) to work in an accessory.
>Why not ?
I don't know, what happens exactly? This may be fixed as it was not
the latest version.
If you have access to internet email the authors email address is :-
martin.maisey@mnn.mettav.exnet.com
>Lastly, when using FLDLIB in conjunction with Let-Em-Fly (with Dials
>to Mouse ON) the title bar of fld_do can corrupt the menu bar (when a
>program is not using the menu bar). Is there any way to avoid this ?
The problem is that when LTMF chooses where to put the dialogue it
doesn't know that FLDLIB is going to draw a title bar above it. Look
in the source for FLDLIB and you will find it does form_center() and
then wind_calc() to calculate where to put the window. If you add a
rc_constrain() to keep it into the desktop area which you get by
wind_get(ROOT,WF_WXYWH...) then it should work.
To: Leslie Dewhurst
===================
>I was interested to see that Mark Baker has obtained official
>Errata for the first edition. How does one get this? I sent
>the registration card from the back of the book off to
>America (not very hopefully!) but have had no reply. I
>bought the book from Hisoft at an exhibition.
I haven't got any official errata, I said that they existed and listed
only the errors corrected in the second edition (ie. first _revision_)
I have had no reply to the registration card either, I was hoping to
get tosdefs.h as there are a lot of #defines in there I don't want to
type in :)
>The Atari Compendium says that the first of the seven tables to
>which this function points, contains a "Master Mapping".
>Does anyone know what this latter contains, what it means,
>and how it is used?
No, Modern Atari System Software doesn't explain it either. BTW, do
Truetype fonts contain more than 256 characters, and how are they
mapped?
>Speedo GDOS function "v_ftext16()".
>
>The Atari Compendium shows that there is a parameter "wstrlen",
>whereas Hisoft's book "Modern Atari System Software" on page
>144 omits it or anything like it from the binding for
>"v_wc_ftext" (which is apparently another name for the same
>function).
>
>Is this deliberate or is it a mistake? If deliberate, how does
>one specify the length of the string? What is the form of
>a "16-bit wide string" anyway? An array of word-length
>elements? If so, the last element of the array must
>presumably contain two null bytes, not one. But surely this
>could be taken to be the Bitstream IDX value of a space
>character, and could not therefore be used as a string
>delimiter?
v_ftext() _always_ takes an array of words. The normal binding takes a
character string and unpacks it to the word array, v_ftext16() aka
v_wc_ftext() copies from a word array, but it calls the same vdi
function.
Actually two null bytes are taken as a string delimiter - so they
cannot be used as a space character, you have to use those later on in
the character set.
*/ Ref: Othello 'makefile', we just publish whatever is sent into us.
If there is anything wrong with the files we probably would not know
although we do try out SOME source files. Members sending in any of
their own code or PD material should make sure, as far as possible,
that everything is complete. Our view is that, even though a program
may not be usable as it stands, the individual functions/routines/etc
may be of some use to programmers. ICTARI /*
----------------------------------------------------------------------
To: Diamond Software
From: James Collett (Professor)
Thanks for the greet back on August`s disk (issue #13) guys,
most appreciated! I`m afraid I`ve been busy with other things
recently, but I have lots of nice GFA codings on the way (see below
for more details)! In the meantime, here`s a quick shadebobs screen
(see GFA folder) */ Sorry. No room on this months disk, hopefully it
will be on next months. ICTARI /*.
Back on August`s disk, you were asking for a SPU viewer and a
BMP viewer. Well I`ve written a SPU viewer, don`t know if Pete`s
going to include it this month or next month though. I`ve not had
time to look at BMPs yet, but I will (if you can wait a couple on
months). */ The SPU code and explanations are excellent and will
definitely be on next months disk. ICTARI /*
With regard to your full screen GFA overscan code, I would be
very interested in a copy and also have a GFA 3.5e compiler. If you
could include it next month, I`ll compile it for you and
return the executable the month after that (probably December?) By
the way, do you have a GFA 3 interpreter? If not it`s **well
worth** buying - the *best* language for ATARI machines (in my
opinion).
Finally, and still with August`s disk, if you get a 680x0 ProTracker
or NoiseTracker replay, I would be interested in a copy of that too!
Cheers alot,
To: Richard Davey
=================
Last month you were enquiring about playing samples on the FALCON
using DMA. The FALCON is DMA compatible, so you can play samples,
but it does not have a microwire, so you can`t adjust
volume/treble/base/etc as you can on the STE.
May I suggest you look at my DMA toolkit, included on this months
disk, for information & routines for playing samples using DMA. These
should be easy to convert to HISOFT Basic, or any other high level
language for that matter.
You were also enquiring about displaying NEO pictures using the
correct palette. If you can wait a couple of months I`ll look at
NEOs in detail, (I`m afraid I`m busy at the minute - see below to
find out what I`m up to). If you can`t wait a couple of months,
here`s a couple of tips:
* Make sure you`re on an ST compatible screen, by selecting one
from the "set video" box - this will ensure the machine uses ST
compatible color registers and not the FALCON color registers,
* Try using XBIOS(6,L:addr%) instead of PALETTE, where addr% is
the start address of the 32 byte (16 word) palette block.
Hope that helps.
Subject: The Advanced Sphere Library (is on its way - honest!)
Delayed....
===========
You may remember, back in June on ICTARI disk #11, I promised the
'advanced sphere library', containing GFA sources such as:
* Raytracing hi-color spheres & cones on the ST
* Raytracing hi-color spheres & cones on the FALCON
* "Wrapping" images around spheres & cylinders
[Note this list is provisional & hasn`t been finalised]
The 'advanced sphere library' =is= coming, it`s just been delayed:
Unfortunately I`ve recently started work, and after programming a
Unix box from 9am to 5pm, you don`t feel like doing much other coding
in an evening! That spare time I have had (mainly weekends),
I`ve been spending coding my latest demo screen: 'HALLUCINOGEN'.
This will be VIRTUAL INFINITY`s *biggest* release so far, and will
feature many stunning effects including:
* 4 bitplane, realtime, bouncing scrolltext
* Loads of massive 4 bitplane sprites
* 'Pre-coded' JPEG images
* 'Pre-coded' MPEG animation
* All running synchronously at 50Hz!
* All coded in pure GFA (except musyc)!
'Hallucinogen' will (hopefully) be released Halloween `94, and will
be well worth the wait!! As soon as this demo screen is released
I will complete & release the 'advanced sphere library'!
Apologies for all the delay! Keep an eye on ICTARI disk!
----------------------------------------------------------------------
To: Richard Davey
From: Keith Baines
HiSoft Basic 2.10
=================
Libraries
---------
HGT.T already includes a LIBRARY statement for the gemaes, gemvdi,
gemdos and xbios - it's in the toolbox source file TOOLBOX.BAS. So you
shouldn't need a LIBRARY statement in your own code for any of these
libraries. If you need another library, e.g. the bios, then put in a
library statement with just that - there's no problem with having more
than one LIBRARY statement provided they don't name any of the same
libraries.
Including Data Files in the PRG
-------------------------------
So far as I know, the only way to do this is to put the data in an
assembler file and use Devpac3 to assemble it into Lattice linkable
format. (Or you could do the same in C and use the Lattice compiler.)
This can then be linked with the Basic program. This *doesn't* put the
data into variables that Basic can access directly. The best approach
in assembler, at least for read-only data, is probably to simulate an
array with a function which returns the values according to an index
variable.
The code would look something like this:
TEST.BAS
~~~~~~~~
DEFINT A-Z
DECLARE FUNCTION MYDATA CDECL (BYVAL I&)
PRINT "Some values from the included data"
FOR I&=0 to 10
PRINT MYDATA(I&)
NEXT I&
STOP
TEST1.S
~~~~~~~
opt lattice
xdef _mydata
_mydata lea array,A0 Address of our data
move.l 4(SP),D0 Get index passed from Basic
asl.l #1,D0 x 2 for short integers
move.w (A0,D0.L),D0 Get the value into D0
rts ... and return it to Basic
array DC.W 1,2,3,5,7,11,13,17,19,23,29
(This could be improved by adding checks that the index value passed
to it is in range!)
TEST.LNK
~~~~~~~~
FROM TEST.O+TEST1.O
TO TEST.TOS
After compiling TEST.BAS and assembling TEST1.S, you will have two
Lattice linkable files, TEST.O and TEST1.O. (Basic makes a linkable
file automatically when it sees CDECL in the declaration, but you must
set it to compile to disk.) Link them together with a command line
CLINK WITH TEST.LNK
Of course, you could have several simulated arrays each with its own
function, and it is possible to return other data types, including
strings. (Return a pointer to a null-terminated string in D0). Linking
Basic with assembler and C is covered in Appendix F of the Basic 2
Technical Reference manual.
I find that the most convenient set-up for mixed Basic and Assembler
development is to put CLINK and the TTP version of GEN in the Basic
editor's Tools menu and run everything from inside the editor. This is
quite happy to edit .S and .LNK files, and by using the %. and %?
parameters in the tools' configurations, filenames can be passed to
CLINK and GEN automatically.
----------------------------------------------------------------------
To: ICTARI
From: Lee Russell
I am in the process of writing a picture converter and have been using
Dave Baggett's article 'ST Picture Formats' available from the Public
Domain. However, the section on the IMG format is a bit misleading.
When describing the scanline run data type it states that after the
flag byte has been read "the data for the next scanline follows". This
does not mean that one scanline of literal bytes follow; the scanline
data uses all the available compression methods. Maybe this hint can
save someone else a bit of time.
I also found the Lattice C's description of the vrt_cpyfm() function a
hindrance. Programmers should be aware that the logic operation
parameter 'wr_mode' is different to the same parameter for
vro_cpyfm(). The valid codes for vrt_cpyfm() are :-
1 - Replace
2 - Transparent
3 - XOR
4 - Reverse transparent
*/ Next month we will be publishing some picture decoding routines in
various formats and languages. If anyone has written a picture
decoding or encoding routine perhaps they would like to send it in
immediately for the next issue. We are also preparing an article about
the BitBlit routines including the A Line ($A007) version for a future
issue. ICTARI /*
----------------------------------------------------------------------
To: Mark Baker (and anybody interested)
From: Mrten Lindstrm
STYLE GUIDE DEBATE -
STANDARDIZED MAPPING OF KEYBOARD FUNCTIONS (see Issue 12)
I was very sorry to hear that the keyboard shortcuts given in the
Atari Compendium weren't the standard I thought them to be. I found
them on the whole to be rather logical. If you would report to Ictari
on any results from the ongoing style guide debate - perhaps
complementing the key list below - for the benefit of me and others
without modems /money for the telephone bills, I would be grateful.
And thank you very much, by the way, for the invaluable information on
legal use of the right mouse button in GEM (Ictari 10). I cannot
believe Atari has kept this a secret for all these years.
UNDEBATABLE FIXED ATARI KEYBOARD FUNCTIONS
In an old issue of German ST Magazine I found something about keyboard
standards and from this I have put together the following list of
keyboard commands that I think are undebatable (i.e. that I think that
Compendium and German Profibuch agree on. I don't have the Profibuch
though so I don't know this.) Could anyone who knows more, please fill
in /correct:
Ctrl-Q Quit
Ctrl-N New
Ctrl-O Open
(I am not sure about a CLOSE command - the Compendium says Ctrl-W)
(Ctrl-S = 'Save' OR 'Save as ...'. I am not sure of which. The latter
is according to the Compendium, which wants us to use Shift-Ctrl-S for
'Save'.)
Ctrl-X Cut
Ctrl-C Copy
Ctrl-V Paste
Ctrl-F Find
Ctrl-R Replace (I'm not sure but think all agree)
Ctrl-P Print - " -
Ctrl-A Select All - " -
Help Help (of some kind)
Undo Undo last (block) operation
Ctrl-LeftArrow Cursor left one word
Ctrl-RightArrow Cursor right one word
Shift-LeftArrow To start of line
Shift-RightArrow To end of line
Shift-UpArrow Page Up
Shift-DownArrow Page Down
Shift-ClrHome To end of document
(ClrHome = To start of document according to German standard, but 'To
top of window' according to the Compendium. The Compendium states
Ctrl-ClrHome for 'To start of document'.)
----------------------------------------------------------------------
To: *.*
From: M Wells
Hi, does anybody know how to use Calamus fonts from GFA Basic, as I
don't have a clue.
*/ I am writing some machine code routines to use Calamus fonts from
user programs which I will be publishing in a future issue. I don't
know whether it will be possible to use them from GFA Basic, maybe our
GFA experts will be able to provide the necessary code at a later
date. Peter Hibbs /*
----------------------------- End of file-- --------------------------
