Copy Link
Add to Bookmark
Report
Ictari Issue 11
ICTARI USER GROUP ISSUE 11 June 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 11
==================
FOLDER SUBJECT
ÿÿÿÿÿÿ ÿÿÿÿÿÿÿ
ASSEMBLY Binary to decimal conversion routine.
Decimal to binary conversion routine.
Code to play chip music in interrupts.
Code to set up time and date when booting up.
Routine to convert number to a binary string.
Routine to convert number to hex string.
Routine to enter hex number from keyboard.
C GEM Tutorial by J White. Part 1 Introduction.
Using floating dialogue boxes in Lattice C.
Porting IBM PC RSC/Doodle to Atari GEM.
GFA Code to generate circles, spheres, etc.
Picture image cutter and saver program for GFA.
PASCAL Code to display boolean expressions as a Karnaugh map.
STOS Code for number guessing game that talks to you.
MISC Blitter chip manual.
Click anywhere title box using Resource File editor.
Index for issues 1-10.
Membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Loading files.
Palette fading routines for STFM and STE.
User defined mouse shapes for GEM programs.
Sprite drawing routines.
Sprite tutorial. Part 1.
C Fractal drawing code.
GEM Tutorial by J White. Part 2
GFA GFA Manual Section 1 of 3.
GFA Alert form designer.
STOS Bootview program code.
Pipe Perfect game code.
MISC Analyzer program to display info on system crashes.
Atari Questions and Answers file No 1.
STE hardware information.
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).
Using the Xbtimer chip.
Playing sound samples on non STE machines.
Picture switching techniques.
VBL queue information.
Printer driver code for printing mono/colour images.
Sprite tutorial and code.
C Graphics extensions.
C functions using dialog boxes.
-----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
ÿÿÿÿÿÿÿÿÿÿ
The ST Applications magazine, issue 42, has now published a full page
article on the ICTARI group and we have had a few inquiries as a
result. A few more programmers have joined the group this month which
gives us a membership of about 44 including the committee.
HELP68 ACCESSORY
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
In issue 8 I complained that the HELP68 accessory which displays the
68K instruction set and their various parameters, etc, etc did not work
on my machine and asked if anyone could fix it. I have since discovered
that it does work OK but will not work if the GEM speed up program
QUICKST3 is also loaded, which I usually use. Does anyone know why and
whether it works with the NVDI or Warp 9 accelerators.
TEXT and IMAGES
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Regarding the use of pictures in text tutorials, the few that replied
suggested that separate .IMG files in conjunction with a standard ASCII
file would be the preferred option so that anyone who wants a print out
can make up their own documents using their own WP/DTP program. We can,
for a small fee, also provide Laser printed copies of any of the
text/picture files that are published in ICTARI. Please contact us if
you are interested.
CIRCUIT DIAGRAMS
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Does anyone have a circuit diagram of the Atari computer and/or the
Monochrome monitor SM124 which they could let us have a copy of. We
will, of course, pay for any photocopying costs.
-----------------------------------------------------------------------
CORRESPONDENCE
==============
Hello ICTARI members! I'm Ralph Lovesy and I've been programming in
68000 assembler for 3-4 months. I've owned an ST since 1985 and a 2 meg
STE since 1989 and I now specialise in STE programming. I've written a
shareware Pacman-style game called Snacman which has STE-enhanced sound
and graphics and I'm currently working on a 1 meg STE-only game called
Supreme Soccer which will be commercially released later this year.
P.S. If anyone has a copy of ST Internals, I would be very grateful if
you could let me know, as I need to photocopy 50 pages or so...
-----------------------------------------------------------------------
To *.*
From Jim Taylor
I desperately need definitive and complete info on the DXF (Drawing
eXchange File) structure so that I can implement it in a CAD type
application I'm developing in C++. I have some info from a PD source
but I do not fully understand it. Can anyone help.
I would also appreciate help with info on HPGL (Hewlett Packard
Graphics Language).
Thanks in advance.
*/ Can anyone help with the DXF information, perhaps if we published
the PD info you've got, someone might be able to expand on it and
produce a better explanation. ICTARI /*
-----------------------------------------------------------------------
To *.*
From Paul Brookes
Can anyone give me basic information on the DSP chip in the Falcon. For
example, how to perform simple communications with the chip (in any
language) like writing two values to it, adding them together and
returning the result, or whatever. A simple tutorial would be very
helpful.
-----------------------------------------------------------------------
To ICTARI
From Paul Laddie (BYTEMAN)
Does anyone fancy doing a tutorial on using RSC files and using windows
in GFA BASIC 3.5, I have written programs in GFA 3.5 which use GEM
pull down menus and simple windows, but I would like to write GEM based
programs which display pictures in windows, which can be resized and
scrolled, etc. I currently use AUTOZEST to create the interface for
my Hi-Rez programs, but I would like to be able to use GEM to its
full advantage.
I noticed in the letters section in issue #10, that a future article
will be on playing sound samples in BASIC, I have written a GFA BASIC
routine which plays a large sample straight from a hard disk, it only
uses two channels of the sound chip. I will tidy it up and send it in
to a future issue.
I think any diagrams or pictures in future issues should be included
as just plain IMG files on the disc, then they will be
accessible to more people, besides the graphics handling in First Word
Plus is pretty basic anyway.
That's all folks!
*/ Any offers on a RSC/Windows tutorial. We look forward to the sound
sample playing code. Starting next month we are publishing a very
comprehensive three part GFA manual by Han Kempen which does cover GEM
windows, menus, dialogues, etc albeit fairly briefly. ICTARI /*
-----------------------------------------------------------------------
To ICTARI U.G.
From Mic Barnard
To our dear esteemed editor.
Sorry I didn't send anything in for the last issue, it's a combination
of being disorganised, having my mum-in-law here and having my STE
break down on me. I don't know which was worse... but, I've tried to
catch up with this letter. Hope it's not too long.
You'll be glad to know that your postage arrangements have been fine
with me so far. There seems no need to spend money on jiffybags.
This may seem silly, (IT IS, very!) but I havn't got an anti virus
program. Until now I haven't got disks from friends as no one I know
uses an Atari and I only ever buy original disks. (See my halo?). I
think I'm clean, I've never had any problems other than hardware ones,
but I'll have to make sure. UVK it is.
The 'Explorer Journal' bit from the States was quite good although, of
course, not all bits are anywhere near my (low) level of understanding.
It'll be good to see more of it.
*/ When we can get some more we will use it. ICTARI /*
Sorry about the 'Puuurrrrr' bit. I read it on the disc and my blood ran
cold. I don't know why I did it. I really am 37 years old!
Also, I'm not a prude. I swear enough both at home and at work, but
somehow seeing a bit of swearing in one of the files in your editorials
also made me cringe a bit. Remember, this stuff's liable to be read by
anyone. Let's make it look good.
That makes me ask. Is ICTARI being sent to PD libraries too, or are we
members the only ones who get to read it? Does Ictari hold a copyright?
Can any non-Ictari members use the source? I only found out about
Ictari from a PD library, so if it is released we could increase the
membership. Just a thought.
*/ We don't send the ICTARI disks to any PD libraries (see below). As
far as we are concerned any source code published in the magazine can
be used by anyone, ICTARI member or not, since there would not be much
point in publishing it otherwise. If any members wish to put any
restrictions on the code they send in, they should put a note in the
code or the associated text file to that effect. However, if members
use another members source code in a published program, we think it
would be courteous to acknowledge the members contribution in the
program documentation. ICTARI /*
Wordprocessors. I'm writing this on Protext V4.3 as given away by ST
Format issue 41. (Document mode, standard ruler.) I hope it's easier
for you. And, as you use Protext regularly, can you tell me how to
alter the border colour to black to match main screen 'paper' colour? I
can change all the settings from within the config program but not the
border.
*/ We use Protext in monochrome so the problem doesn't arise. We did
try it on our colour monitor, however, and changing the colours with
the CONTROL panel accessory it seems that Arnor have used colour 0
(which is used for the border) in the main part of the display so that
changing this colour to black will mess up the text area. We would
assume from this that it can't be done but if anyone knows different,
please let us know. ICTARI /*
I've also got Calligrapher Pro (ST Review 24), First word plus (ST
Review ? ), Write on (ST Review 13 & ST Format ? ) and Word Flair (ST
Format 52). So, whichever one you decide on as the standard for Ictari
is OK by me. You're right about the printing speed of Cal Pro. There's
a crippled snail in there somewhere.
Now to ask for more help. I need to understand more about the logical
and physical screen concepts. As I understand it the ST's O/S keeps
track of 2 addresses. That of the physical screen, the area of memory
which the hardware uses to send as data to the monitor and the logical
screen, the area of memory used by the O/S to write to. On bootup they
are the same, the ST writes to the displayed screen memory.
Using XBIOS 5 - SETSCREEN I can alter these addresses. Therefore, by
reserving 32k of memory (on a 256 byte boundry) somewhere in RAM I can
use it as a second screen, passing the parameters to TOS via xbios 5.
So far so good. I did that. I passed the contents of my screens new
addresses to my variables, waited for the VBL then passed the
parameters to TOS via xbios 5. I should now have 2 separate screens,
with all O/S output going to the screen who's address is held as the
logical screen.
I then wrote a message using GEMDOS 9 - PRINT LINE. It should go to the
logical screen. It wasn't displayed so it must be written as I wanted
to the logical (hidden) screen. I did a screen swap. The message
appeared. Also good, I was now looking at the previously hidden screen.
Now I wrote a second message with gemdos 9. I thought it should be
written to the logical (hidden) screen, i.e. my previously physical
screen. But it immediately appeared next to the first message on the
physical screen. Now I'm confused.
The obvious answer is that I failed to swap the addresses or to pass
them to the O/S. But, I have followed them with MONST and the variables
change correctly. I also put XBIOS 3 - LOGBASE in the code at a few
strategic places and found the addresses had been swapped within the
O/S where I expected them to and to the correct values. So whats wrong?
Does GEMDOS not write to the logical screen address a second time?
I've included the files 'MICSMACS.S' (my budding macro file) and
'TESTMACS.S' (the file with my problem. I was/am testing my macros
before I use them to tidy up my mouse shell.) Help, please.
To Si(gh).
Thanks for the comments on my listings in issue 9. But it does leave me
with one or two (or three) questions. Such as...
Why use 'bsr.s' and 'bsr' instead of 'jsr'? Looking these instructions
up in my timing tables (which everyone must have because no one
contacted me for a copy) it seems that 'jsr' takes between 16 and 22
cycles, 'bsr' takes 18 cycles and I don't know how many cycles 'bsr.s'
takes because it's not listed as a separate instruction. So 'jsr' can
be quicker than 'bsr'. Or is it the amount of memory they take up? I
could save up to 4 bytes using 'bsr.s' but is it worth the hassle of
finding at assembly that your code has grown since you used it and it
now produces an assembly error? Also, surely it's not so critical to
worry about the few cycles saved for jumping to subroutines? Now loops
are critical. They may be repeated thousands of times so the couple of
cycles adds up tremendously, but subroutine jumps? Don't get me wrong,
please, it's just that I want to know WHY one thing is better than
another, not just to be told that IT IS!
You say "It's quicker to add words to address registers as all 32 bits
of address registers are still affected!". Again, I say why? According
to my timing tables:
addq (b/w) 2 bytes 4 cycles for data registers
addq (b/w) 2 bytes 8 cycles for address registers
addq (l) 2 bytes 8 cycles for all registers
Adding words OR longs to address registers seems to take 8 cycles. I
have the same problem with your comment "Use clr.l instead of move.l
#0". I read them as both taking 28 cycles in absolute addressing mode.
Am I misreading the tables?
*/ I tend to use BSR and BRA in preference to JSR and JMP instructions
in my programs because JSR and JMP instructions require absolute
addresses while BSR and BRA are relative branches. All absolute
addresses have to be relocated when the program is loaded which
increases the size of the program (the relocation table anyway) and
also slows down the loading time slightly. Obviously this is not a
major consideration on small programs but could be more significant on
very large programs. Also, if you are using Devpac, it is not necessary
to use the .w or .s on instructions since Devpac assumes these anyway.
Even the .l indicator is not needed on address register instructions
(i.e. add.l #10,a0) since Devpac uses the correct instruction code
when address registers are used as the destination operand. Si(gh) may
have other reasons, of course, maybe he will enlighten us. PDH /*
You'll be glad to know I agree fully with your comments about the logic
of my mouse routines and that I've fully rewritten them and they work!
Thanks. It's the core of a basic shell I'm (trying) to do next, and
when it's done I'll send it in. Now all I need to do is draw the
pointer...
As for my jumping about the code, I was more interested in trying to
get it to work. I tend to tidy it up later. Sometimes. Not that I've
written much to tidy yet.
The loop counter was accidentally left in. I was trying to count how
many times a frame I could read the mouse.
My maths is terrible. Being logical, with maths like mine I shouldn't
be looking at code let alone try to write it! Still, I'm learning and
that's what this disc is about isn't it.
Again, thanks Si(gh).
To James Collett.
Just a short note. Watch out for the copyright for the Repton games. I
know they are out of date as such, but someone must own the copyright
to them, unless they were PD. If you get any old disks or tapes write
to the publishers who's addresses are on them and ask for their
permission. As they haven't released it for the ST (I assume) and they
are old hat, they would probably agree. I've just read an article about
this same thing in the June '94 issue of PC HOME magazine. (Page 124,
an article called 'RETROSPEC'). Someone is re-writing old Spectrum
games for the PC. He's been given permission by a couple of companies
and apparently refused by none. Good luck.
To Steven and Andrew, Diamond Software.
You have offered to release some of your routines. First, thanks, but
secondly could the fast sprite routines be one of the first out as I
need to be able to draw/undraw/redraw, etc, my mouse pointer as quickly
as possible. At the moment I just have a simple but slow routine. How
is it done much quicker? Hope I don't sound greedy.
To everyone. Be safe and ta for your help and patience.
Mic.
*/ Steven and Andrew have already sent in some sprite routines which we
will publish next month, Nik Bates has also sent in a sprite tutorial
which we will also start next month. Since sprites are a fairly major
aspect of programming on the Atari, we would like to see other members
code on this subject, especially for the higher resolutions of the
Falcon (at least seven members have Falcons at this time). ICTARI /*
-----------------------------------------------------------------------
To ICTARI
From Andrew Martin & Steve Jordan <Diamond Software>
Afetr passing a few ICTARI disks around various friends the general
impression was that the disk was not presented well. The introduction
of a DESKTOP.INF file to boot the desktop in medium resolution would
make a great deal of difference. We presume the reason you have not
done this is because of members with hard disks. This is fair enough to
the people who own hard disks and have a DESKTOP.INF file set up to
their own needs but the vast majority of people (including those who
purchase the disk from PD libraries) don't have hard disks and
therefore boot their computer with the disk in the floppy drive. This
results in a rather ugly looking low resolution desktop appearing,
which is most unfriendly when beginners are trying to read text files.
We also feel that the group needs a more varied spread of members. How
this will be achieved we're not sure, the only way we can think of is
by time.
We understand your concern with boot sectors and will, therefore, no
longer be sending in any disks with bootsectors on them.
*/ Point taken about booting in medium rez, DESKTOP.INF file now
included. Incidentally, according to the membership questionaires, out
of the 40 or so current members we have at present, 24 have hard
drives, an absolute essential for programmers we think. We don't
actually distribute the ICTARI disks to PD libraries for two reasons,
(1) the costs and (2) we want potential programmers to join the group
so that they will contribute programming material rather than just
receive it from a library. We have, however, written to all the main PD
libraries informing them of ICTARI and we hope they will pass this
information on to their customers. ICTARI /*
-----------------------------------------------------------------------
TO: All
FROM: Mark Baker
The second edition of the Atari Compendium is now available, it fixes
many of the errors in the first edition.
If you have the first edition there is an official errata available
which lists all errors known when the second edition was published and
therefore now fixed. I found the following message which lists some
other errors, almost all of which are still in the second edition.
###################################################
The Atari Compendium
by Scott Sanders
Additional Errata
Compiled by Mark S Baines (msbaines@cix.compulink.co.uk)
09 06 94
6.46 (appl_getinfo)
Available from AES 4.00 not 3.40. ap_gtype 4 and above are available
from AES 4.10.
6.63 (evnt_mesag)
MN_SELECTED - msg[4] contains the object number of the menu item or the
submenu item if submenus are available.
msg[5], msg[6] and msg[7] contain this data as from AES 3.30 not 4.0.
msg[7] contains the parent object index of the menu item or the submenu
item.
WM_TOPPED - the wind_set parameters should be wind_set(handle, WF_TOP,
0, 0, 0, 0). msg[3] contains the handle.
WM_ARROWED - msg[4] indicates which action was actually selected not
msg[3] which contains the handle.
6.64 (evnt_mesag)
WM_HSLID - msg[4] contains the new slider position not msg[3] which
contains the handle.
WM_VSLID - msg[4] contains the new slider position not msg[3] which
contains the handle.
6.99 (menu_attach)
Caveat
menu_attach on AES 3.40 has a problem with scrolling sub menus if more
than 1 sub menu is in the OBJECT tree. The solution is to only have one
submenu per OBJECT tree. (Simon Robins)
B.7 System variables
Which of these are available for a particular TOS is very confused as
laid out here. The Addendum notes don't fully explain either.
Addresses $400 - $4FE TOS 1.0
Addresses $400 - $57E TOS 1.2
Addresses $400 - $5A0 TOS 1.4
Addresses $400 - $5B0 TOS 1.6 and later
There is an additional system variable at $600 patchzone, used as an
area for patching TOS and other routines. If empty it is set to
$0BADC0DE.
B.15 System variables
ramtop should be called fmemtop
ramvalid should be called fmemvalid both in accordance with
nomenclature used elsewhere.
#########################################################
Letter extracts published in ST Applications Issue 42 page 41 David
Bolton
For someone starting to program in assembler and wanting to use GEMDOS,
BIOS or XBIOS calls they will need to do some hunting unless they have
any other reference books for the o/s.
Mr Sanders has omitted to mention that return values are to be found in
d0.L. Each of the relevant sections in the book has a part entitled
"Function Calling Procedure" but none of them tells the reader where
return values can be found! Since the procedure is given in assembler I
feel this is a bad oversight.
The remaining errors/omissions I've found so far have been in the AES,
VDl and CPX sections. Those in the AES are associated with the table of
opcode/control values on page 6.38. The statement at the start of the
table about no AES calls using addrout is wrong: rsrc_gaddr uses it to
pass back the address of the object being looked for. Some entries in
the table have the wrong values;
the entries should read for:
appl_search 18, 1, 1, 3;
rsrc_rcfix 115, 0, 1, 1;
appl_getinfo 130, 1, 4, 0
The VDI section mentions device drivers but unfortunately Scott Sanders
hasn't taken the opportunity to pass on any information or guidelines
on how to write them (a subject that has been mentioned on more than
one occasion in STA). The errors are:
v_bez_on p7.29, contrl[1] should equal 0 not 1;
v_load_cache p7.59, contrl[3] should be i not --i (intin[0] holds the
mode so the last i++ counts that word also);
vqt_cachesize p7.104, the assignment to *size should access intout[0]
and [1] not the corresponding intin fields;
vgt_fontheader p7.109, the opcode should be 232;
vqt_name p7.113, the assignment to fontname requires a cast as intout
is a word array and fontname is a char/byte array, ie fontname[i] =
(char)intout[i + 1].
The v_bez (and v_bez_fill) explanations on p7.26/27 have a couple of
errors and are not as clear as they should be (or maybe I'm as thick
as two short planks!).
The control points are actually expected in the following order:
anchor - 1, control - 1, control - 2, anchor - 2
(if you believe the book then there are some interesting curves
produced!). The first line in the first "for" loop is rather curious
as
it won't achieve the desired result. Each word of intin should contain
two consecutive characters from bezarr, the code given will only pass
the first half of bezarr to the VDI and with $00 between each value.
The following code should give the desired effect:
for (i = O; i < count; i += 2)
intin[i / 2] = ((WORD)bezarr[i]) * 256 + (WORD)bezarr[i + 1];
When bit 0 of a value in bezarr is set the control points start in the
NEXT corresponding position in the pxy array, the use of bit 1 is also
important. Here are a two examples (the origin is at the top left in
each case):
count = 4
bezarr = 3, 0, 0, 0, 0
pxy = 50, 50 ignored here
400, 50 anchor - 1
400, 200 control - 1
300, 50 control - 2
300, 200 anchor - 2
Resetting bit 1 to give
bezarr = 1, 0, 0, 0, 0
results in this second curve where the first point in pxy is now used.
[ images of 2 bezier curves not included here ]
v_bez_fill behaves in the same way but additionally the first and last
points are connected with a line before doing the fill. Using the same
values as above gives:
[ images of 2 filled bezier curves not included here]
The section on the extensible control panel has some omissions in its
explanation. The flags structure in the header (p10.3) is actually a
word with each flag in the corresponding nybble. Also for some reason
known only to Atari the values in the two colour words are not stored
as you would expect.
The icon colour (i_color) is in the high nybble of the word as 0xi00,
and the text colour (t_color) in the low nybble of the high byte of the
word as 0x0t00. For anyone writing CPX's in assembler all the cpx_***
functions expect the return value to be passed back in d0.L.
++++ End of file ++++
