Copy Link
Add to Bookmark
Report
Ictari Issue 38
ICTARI USER GROUP ISSUE 38 September 1996
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* 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 38
==================
ASSEMBLY ST Assembly Language Workshop. Chapter 3.
C Richard Harvey. C Tutorial Part 2.
Window dialog system.
GFA More font routines.
Clipboard functions for GFA.
STOS Geometry demo program and code.
MISC Beta version of WordGrid game.
More Icon images.
In next months issue of ICTARI (this may change) :-
ASSEMBLY ST Assembly Language Workshop. Chapter 4.
C Richard Harvey. C Tutorial Part 3.
GFA Accessory communication protocol.
STOS
MISC Tanks game demo.
----------------------------------------------------------------------
EDITORIAL
=========
WDIALOG
-------
The Window Dialog .LZH file (in the C folder) will need to be de-
compressed before use with a program such as UNLZH172.PRG. We would be
interested to hear if anyone successfully uses this code in an
application as it looks quite good.
WORDGRID GAME
-------------
David Preston has sent in a simple Word Grid game for beta testing.
Please send in any comments when you have tried it out. My only
comments are that the grid itself (in Hi Rez anyway) could be made
larger to make it easier to line up the words, especially diagonally.
Also, showing the selected words in a small font size makes it even
more difficult to pick out the other words, perhaps they could just be
shaded or shown in inverse video instead. It might be nice to show the
timer counting up all the time (if possible) rather than when the
puzzle has been completed and also to refresh just the word being
changed rather than the whole form to stop the flash each time a word
is selected.
The only bug I came across was when I tried to print the data, the
message - 'Device I/O error at line 491 on #256' was displayed. I was
using Hi Rez with TOS 1.04.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: *.*
From: Martin Milner
Here's some more up-to-date info on the demise of the glossies and
about the launch of the new magazine, Atari Computing.
Apparently, Atari World went down because of cash flow problems. I
believe that at the time they had around 8,000 subscribers. STF were
axed by Future because of (among other reasons) pressure to reduce the
number of titles from W H Smith and an effective advertising boycott
from some Atari publishers. I have heard that at the time they had
around 8-10,000 subscribers.
There is obviously quite a lot of people who still want an Atari
newstand magazine. However, you are right about the difficulties
involved in running a newstand magazine, especially a glossy one in
full colour.
It is for these reasons that Atari Computing is starting out as an
initially bi-monthly mono subscriber only magazine. If things go well,
and circulation gradually increases then there is always the
possibility of colour and monthly issues in the future. We already
have over a hundred people who have sent in advance subscriptions for
the first 3 issues, and more are coming in all the time. The magazine
will hopefully have the best elements from both Atari World and ST
Format, and the first issue will include a survey form to find out
what readers want from future issues of the magazine.
The first issue will be available at either of the upcoming Atari
shows, or if you send in an advance payment (for either just the first
issue or a subscription for the first 3 issues), then a copy will be
posted to you soon after the shows have finished.
Most of the well known Atari supporting companies are taking out
advertising space, and international distribution is currently (mid-
August) being sorted out. The producers of the magazine, The Atari
Computing Group, based on CIX (and non-profit making) are also in the
process of setting up a web site. The subscription and single issue
rates are shown below.
****** All prices in UK Sterling where = British Pounds ********
+----------------------------------------------------------------+
| | | | | |
| Evaluation Copy | UK | EUROPE | USA/CANADA | OTHER |
|----------------------------------------------------------------|
| Magazine only | 3.00 | 3.50 | 4.00 | 5.00 |
| With Reader Disk | 5.00 | 5.50 | 6.00 | 7.00 |
+-------------------+---------+---------+------------------------+
| | | | | |
| Subscription | UK | EUROPE | USA/CANADA | OTHER |
|-------------------+---------+---------+------------------------|
| Magazine only | 9.00 | 11.50 | 12.00 | 13.00 |
| With Reader Disk | 15.00 | 17.50 | 18.00 | 19.00 |
+----------------------------------------------------------------+
If anyone would like to place an advanced subscription for the first 3
issues, then either email me at manifold@cix.compulink.co.uk or write
to me at:-
1 Portland Avenue, Burton on Trent, Staffs. DE14 3GD. England.
and I'll send you a subscriptions form. If you would just like to
reserve a copy of the first issue, then send the appropriate payment
to the above address and I'll pass on your payment and details to the
appropriate people to ensure that you receive your copies.
----------------------------------------------------------------------
To: ICTARI
From: Robert Manning
It is good to see that you are continuing with ICTARI and I hope that
you will continue supporting the Atari platform. Now that ST Format
has ceased to be I thought those of us using Atari machines would be
without any sources of information other than the internet. As I am
not an internet user then I thought I was going to be forced onto the
PC platform. As a PC user at work I like to come home and use my
Atari 520STFM and my feature rich applications which cost a fraction
of those I use on the PC.
As a thought for future disks I was wondering whether when somebody
submits a program to go on the disk whether they could write a few
words on what they used to develop the program and any special tricks
that they used. Features on new techniques that others could
incorporate into their own programs might be a nice idea and any
libraries or add ins might be useful so that others could utilise the
same ideas. This is something that gets done a lot on the PC platform
under Windows where you buy add ins to programs like Visual Basic to
save having to write the same code as other people. With details of
libraries used and handy subroutines it may be possible to get a whole
range of modern applications that have a standard interface.
Personally I would be interested in libraries for Lattice C5 and
HiSoft Basic that help in producing Non-Modal dialogues and menus
within windows.
I look forward to the first issue of the new magazine, Atari
Computing.
----------------------------------------------------------------------
To: Everyone
From: Jason J Railton
Re: 3-D maths
The basic principle of my maze demo is that it's all done on a flat 2-
D map, like Gauntlet or any other maze game. It just uses vectors
instead of graphical blocks. This 2-D approach simplifies a lot of
the maths. Anyway, I've sent in a demo of the maths required to work
out co-ordinates in such a map relative to the viewer. Later on I'll
give a demo of how to turn these into a proper 3-D display.
Oh, and I haven't done much this month because I've been too busy
playing PlayStation 'Resident Evil'. I'd just like to say to anyone
who bought a PC, hoping to play good games: "BIG MISTAKE!"
----------------------------------------------------------------------
To: Jim Taylor and C programmers (Ref: Ictari 36 & 37)
From: Mrten Lindstrm
LOW-LEVEL VDI CALLS FROM LATTICE C
==================================
I really hope there is a Lattice C expert among us to help you, Jim.
"vdi()" is the function name, for low-level VDI calls, suggested in
the Atari Compendium and apparently used by Pure C, but other possibi-
lities exist of course. (Looking into the DEVPAC ASSEMBLER library
files I find the names "LowLevelVDI", "LOW_VDI" and "CALL_VDI".)
COMBINING MACHINE CODE WITH C
=============================
On PCs there are C compilers with some support for inline assembly,
allowing you to write simple assembly routines directly in your C
source. I don't know if Lattice C supports this, however (but see a
general solution below). The customary method is otherwise indeed to
write and assemble your machine code routines into separate object
files, then linked with the object files produced by your C compiler,
but for the details, help from a Lattice C expert is again needed.
"Inline" machine code in ANY C
------------------------------
If you find no other way to incorporate a small assembly routine into
your C program, I think the following general method should work with
ANY C compiler:
Define the function as a (global) ARRAY of shorts or longs containing
the HEX CODES for the machine instructions. Then, when you need to
call the function, CAST the array name into a function pointer. For
instance:
unsigned long vdicode[] =
{
0x7073223CL, /* moveq #115,D0 ; move.l #...,D1 */
(unsigned long) _VDIpb, /* longword for the preceding move.l */
0x4E424E75L /* trap #2 ; rts */
};
typedef void (*PVOIDFN)(); /* In order to simplify later casts */
Then whenever calling "vdi()" do it with:
((PVOIDFN) vdicode) ();
Obviously, you could simplify even further with a preprocessor macro:
#define vdi ((PVOIDFN) vdicode)
after which you can make your low-level VDI calls with just:
vdi();
---<>---
The _VDIpb used above is, as in my example in Ictari 36, assumed to be
the "VDI parameter block" i.e. an array of pointers to the VDI arrays.
If this isn't defined either, in your libraries, it can be defined:
short * _VDIpb[] =
{
_VDIcontrl,
_VDIintin,
_VDIptsin,
_VDIintout,
_VDIptsout,
};
---<>---
PS: If you wonder how I can know the hex code of each and every
assembly instruction, then I obviously don't. I simply assembled the
routine in Devpac and studied the result in its debugger.
Alternatively, any disassembler should be able to produce a listing
containing both hex codes and corresponding assembly mnemonics. Just
remember to give pointers to memory locations special treatment - like
_VDIpb above - and don't merely copy their hexadecimal representation.
To: All
From: Mrten Lindstrm
WDIALOG
=======
I send in the WDIALOG documentation, that I have now translated from
German to English, and also a WDIALOG.PRG file with some text strings
translated through plain and unsophisticated file byte editing.
I have however still not done much in the way of actual experimenting
with it, but it expands the AES with three libraries of functions:
ù wdlg_xxx for handling window (= non-modal) dialogs
ù lbox_xxx for handling list boxes
ù fnts_xxx for handling a font selector (modal or non-modal)
The belief I expressed last month that it also could make available
extended object types was apparently a misunderstanding though.
Instead there is a separate C source file ADAPTRSC.C (included in the
package), containing functions for this and other purposes.
Before using the WDIALOG functions, from within your own applications,
you must first call:
appl_find( "?AGI" )
If the return value is not -1, then it's safe (regardless of TOS
version) to carry on and call:
appl_get_info( 7, &ag1, &ag2, &ag3, &ag4 )
Use bitwise AND on the returned ag1 parameter with 7; if the result =7
then all WDIALOG functions are available.
Callback procedures
-------------------
The bad news, for everybody who uses a high-level language other than
C, is that the only thing that you will probably be able to
conveniently use without C or assembly is the font selector.
This is because both window dialogs and list boxes, as implemented by
the Behnes in WDIALOG, require pointers to functions, within your
program, to be passed to the system. And GFA Basic and other non-C
languages don't unfortunately allow you to play around with function
pointers (maybe in GFA Basic 4 - ha ha). In MS Windows, where this
concept is heavily used (yes, I have admittedly now started to learn
PC programming) such functions are called "callback" procedures, since
they allow the SYSTEM to call (routines within) your PROGRAM whenever
needed. In GEM, the only other case of callback procedures, that I can
think of, are the routines associated with PROG_DEF objects and called
by the AES whenever such an object needs to be (re)drawn. (Though in a
way, every lowly, program-installed, interrupt routine could perhaps
also be considered a kind of callback procedure.)
----------------------------------------------------------------------
To: ICTARI
From: John Noakes
I am very much interested to know whether the rest of the members have
had the same problem. Recently I ordered a product from HiSoft only to
have it sent two weeks later, the same with Gasteiner. True I could
have paid extra for a faster service but when I phone using a credit
card action only for them to state two to three days delivery I think
GREAT.
Is it me, with my phone manners of please and thank-you on the order
that puts them off, or is it that the dwindling Atari market has them
slacking in service. You probably ask "why didn't I complain", well
there's an old R.A.F. Supplier saying, "Hide your shame in file 13",
that file is a rubbish bin.
So I like to say "I LIKE YOUR PRODUCTS BUT YOUR SERVICE STINKS".
----------------------------------------------------------------------
To: ICTARI
From: Jim Macleod
I am self taught in assembler and there are many things you discuss
that are beyond me as yet. To this end I cannot get the bitmap to work
using vro_cptfm. It sets up OK, returns a handle, I can set screen
colours without affecting the screen proper but any v_gtext appears on
screen no matter what. I have copied screen to bitmap and back to a
new location but to no avail. If you have a working example any chance
of it being on disk, even a mini-program can be dissasembled if it's
easier.
Thanks for all your effort in keeping Atari alive.
----------------------------------------------------------------------
To: All
From: Peter Hibbs
Does anyone know if it is possible to use an 'editable object' in a
dialog form in small text. It is possible with WERCS to display text
in Large or Small sizes using the TEXT object but editable objects
seem to need the text set to large even though WERCS will allow the
editable text size to be set to Small. If this is done, however, the
users entries are scrambled and cannot be displayed properly. If
anyone has any ideas I would be interested to hear them.
------------------------------ End of file ---------------------------
