Copy Link
Add to Bookmark
Report
Ictari Issue 37
ICTARI USER GROUP ISSUE 37 August 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 37
==================
ASSEMBLY ST Assembly Language Workshop. Chapter 2.
Raster and mouse control routines.
C Richard Harvey. C Tutorial Part 1.
Garden Database program.
GFA Various font routines.
STOS Alert box routine for STOS.
Fill demo and source code.
MISC Mouse icon images.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY ST Assembly Language Workshop. Chapter 3.
C Richard Harvey. C Tutorial Part 2.
GFA Various font routines.
STOS
MISC NVDI Guide Information.
Icon images.
----------------------------------------------------------------------
EDITORIAL
=========
DELAYS
------
I should apologise if this disk is a little late but I have been on my
hols and 'her indoors' wouldn't let me come back early to prepare this
issue (some people are so inconsiderate).
FEEDBACK
--------
As usual we would like to hear some feedback on the programs and code
provided on the disk as this will be very helpful to the contributors.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: *.*
From: L. Maule-Cole.
Please would some kind person Beta test my Garden program (in the C
folder). This is my first attempt at writing an application and as I
am entirely self taught (with the help of a few books) I would very
much appreciate some helpful comments. One of the problems I couldn't
solve for myself was - how do you move the mouse pointer on the screen
without moving the mouse? Some sample code in C would be very
helpful. The program in the GARDEN folder is my Demo version. Apart
from the annoying label that pops up, the demo version limits the
number of labels that can be entered to 100 otherwise every function
should work.
*/ We did publish some code (in machine code) to do this some time
ago, perhaps someone could send in a version in C. ICTARI /*
----------------------------------------------------------------------
To: Scott Stringer
From: Jason J Railton
Re: CACE demo
The STOS demo looked fine on my 2.5Meg STFM, but it sounded awful. All
I got was a horrid buzzing sound. Clearly a demo specifically for STE
owners (or the hard of hearing). Sorry. I'm sure it sounds lovely on
DMA playback...
To: Everyone
From: Jason J Railton
Re: Maze demo
Thanks to everyone who tried my 3D maze demo. It's inspiring to know
that it's appreciated by other people. Now, what should I do about
the controls? I'd rather not use a joystick because I would have to
program in a fixed rotation/movement speed. This is then either in
small units, which makes movement slow, or large units, which makes
movement difficult to control accurately. I intend to stick with the
mouse.
I appreciate that the right button would be better used as a 'walk
forwards' button, so I'll probably move the sidestep control to the
keyboard. Personally, I like having the sidestep on the mouse, but
with a fire button as well (later...), I'm running out of mouse
buttons. So what do you want the mouse buttons/keyboard to do?
With doors working now, I also need an 'operate' button. At the
moment, this is achieved by clicking the right (sidestep) button. If
the 'walk' or 'fire' button doubled as this purpose, it could lead to
mistakes when playing - operating things when the intention is to
shoot or run away. So, I either put the 'walk' or 'fire' control on
the keyboard (Alt and Shift keys are the easiest to read), or I have
two keyboard keys for 'sidestep' and 'operate/open'. Then again, I
could even have sidestep left/right on the two mouse buttons and all
the other controls on the keyboard.
How about if you just move the mouse forward, and you keep walking
until you pull the mouse back again? (To walk backwards though, you
have to keep moving the mouse as before, so you don't have to centre
the mouse exactly to stop walking forward, just pull it back until you
start to back up)?
To: Everyone
From: Jason J Railton
Re: More demos
The stuff I sent in last month didn't arrive in time to make it to
disk 36, so it may be floating around on this disk with a few
messages. Either that or Peter just thought it was a load of rubbish
and binned it... Who knows? Anyway, I've sent in my two-player TANKS
game, but it is about 200K so I don't know if that will appear for a
while.
I've included a new mouse/raster routine for Peter, who wanted rasters
on specific lines of the screen. I suggest you print out the whole
source listing and go through it with a red biro, making notes on how
it all fits together. There are loads of comments in the code to
help. The interesting twist on the last two mouse/raster listings is
that I actually have four different raster interrupt routines now, and
each one installs the next one on the fly. The spacing varies too,
but you have to control that one interrupt in advance.
Note that the raster routines can do this because the system hardware
causes all interrupt routines to run in Supervisor Mode.
Also I've sent in a demo of how I fill all those polygons in my 3D
maze. Basically, I just draw the top edge of each polygon and then
smudge the screen down, overlaying each line on the line below. Close
objects (lines high up the screen) then obscure distant objects (lines
further down the screen), so all the depth-sorting is done
automatically. The top and bottom halves of the screen are exact
mirror images, so one is simply a copy of the other. (NOTE: I did not
hack into SubStation for this! I figured it out myself, although
those streaky walls were a bit of a clue.) I've included a simple
demo of this principle, and also the source code of this demo in STOS
basic.
I'll go into the 3D maths in detail at a later stage, but for now,
look at the graphical technique.
Of course, I use machine code for mine (not STOS), but the code is so
specialised that it's unreadable. In addition to the STOS demo, I
draw my lines ANDed with one of several coloured stippled patterns, so
the line darkens as it goes down the screen. This makes the whole
wall (when the line is smeared downwards to make a solid wall) look
shaded. I also smudge the lines of the screen in twos, to preserve
the stipple instead of making it streaky.
I still haven't seen this SubStation running by the way, only static
screen shots. Anyway, bye for now. I'm off on me hols. I've just
been to the fair, and I'm tired, but I'm still trying to get this
finished. I got two plushies (sorry - technical term there. I mean
'cuddly toys') from the fairground grab-cranes, so I'm in a happy (if
tired) frame of mind. I can supply tips on getting results from these
machines too, if anyone's interested. It's a perfect chat-up though,
if you go into a pub with an armful of cuddly toys... just stick to
the right part of town. Oh, what am I saying? It must be bed time. I
hope Peter has the sense to edit all this waffle out... We'll see.
*/ In the Maze Demo, could you not have a row of icons along the
bottom of the screen for moving in any direction with additional ones
for fire, open door, attack, or whatever (i.e. similar to Dungeon
Master). This would make the screen area slightly smaller but would
give more scope for other controls.
The files you sent are on this disk although I don't seem to have the
TANKS game and I can't quite remember whether it was on the last disk.
Perhaps you could send me another copy if you think it would be of
interest to other members.
Thanks for the raster code, I will study it in detail shortly and let
you know how I get on in due course. PDH /*
----------------------------------------------------------------------
To: All
From: Mrten Lindstrm
NVDI
====
Beginning of this year I wrote to 2B and asked for NVDI info, but - I
told you a few months ago - I got no reply. Well, I just now HAVE got
a letter from Wilfried Behne (apologies to him) together with a disk
with the NVDI Programmer's Guide. By unfortunate coincidence I got it
only after it was published in Ictari 36, but since the version I got
directly from Germany is newer - it covers NVDI 4.1 - I send it in.
(As I suspected, character mapping mode 2 now stands for Unicode;
1=ASCII+Atari and 0=direct indexing as appearing in font file.)
NOTE TO PEOPLE WHO HAVEN'T YET LOOKED AT THE GUIDE: It covers not only
NVDI-specific functions and features, but is a complete list of all
VDI functions, including the old VDI and (Speedo)GDOS ones. And with a
number of useful tips on how to tackle common problems.
WDIALOG
=======
On the same disk I got an AUTO-folder program WDIALOG.PRG. Just like
the VDI Enhancer provides some of NVDI's VDI extensions to non-NVDI
users, WDIALOG will make available MagiC AES extensions to non-MagiC
users. The terms are identical, i.e. WDIALOG is in principle freely
distributable as long as no profit is made from it. (If distributed
with commercial programs of value more than 50 DM ÷ 22, the written
consent of 2B is required.)
Unfortunately I have not yet had the time to look any further into it,
but the functions of WDIALOG seem aimed to simplify the implementation
of window dialogs (= non-modal dialogs) as well as of list boxes and
non-standard fonts, and apparently other non-standard objects too, in
dialogs. WDIALOG does NOT give 3D appearance on older TOS versions,
but DOES use 3D effects on those AES versions that support them.
There are sample executables (with C source code) to give a quick idea
of what extras WDIALOG can help you with (you only need to copy
WDIALOG.PRG into your AUTO-folder first). Plus there are screen
snapshots (in IMG and 16-colour XIMG format) both on an old TOS (1.04)
and with a modern AES (MagiC 4) - to give an even quicker idea.
The documentation is (unlike the NVDI Guide) in untranslated German.
If I get the time, I might translate it into English later (if no-one
else volunteers to do it).
I send both the NVDI Guide and WDIALOG in the form I got them - as two
LHZ packed files. Since they contain quite a significant number of
files - including example source files and, not least, space-demanding
images - I suspect that Our Editor will have to keep them compressed
(or maybe just extract the main text documents + the WDIALOG.PRG
file?).
German news and views
=====================
I just bought a copy of the German "ST Computer". It's a double issue
- July/August 96 - and yet less than half (62 pages) of what it was in
the good old days (I did for a period subscribe to it). On the other
hand, though it for a while was trying to extend itself to both Atari
and Mac users, it has now at least reverted back into being a pure and
unpolluted Atari magazine. And the pages there are, provided
interesting reading - among other things:-
New AESs
--------
Julian Reschke is still writing his Atarium, this time concerned with
new AESs. There currently seems to be two projects in progress, both
with the aim of creating a freeware multitasking GEM system: one
Britain-based "XaAES" and one Swedish "oAESis". Anyone with Internet
access who wants to participate in this (or is just curious) should
visit the following addresses (according to Reschke):
For XaAES: http://www.i-way.co.uk/~c_graham/home.html
For oAESis: http://www.mdstud.chalmers.se/~d2cg/oaesis/
Beta versions and source files should be available.
But then there is of course the brand new and ready COMMERCIAL system,
N.AES, from the German company Overscan. Apparently, N.AES beats the
old MultiTOS in both speed and stability, and adds a few tricks in its
functionality too.
Needless to say, all of these new AESs are based on MiNT (the "new
GEMDOS") and compatible with MultiTOS.
MagiC, on the other hand, does from what I understand lag behind a bit
in its MiNT support, and though Geneva, in its latest version, should
work with MiNT, Julian Reschke hasn't seen it - has any Ictari member?
HADES
-----
There is also an extensive review of the new super TOS computer Hades,
in its maximum configuration with a 60MHz 68060, and a crude
experiment (running some matrix calculations) seemed to indicate that
it is about 3 times faster than a 90MHz Pentium PC. Then again, you
will have to pay about 1900 or so for it, which could buy you quite a
powerful PC. (Equipped with a "humble" 64MHz 68040, the price is
"merely" 3675 DM or slightly less than 1600.)
Like a PC, Hades has slots for both ISA and PCI cards and comes
equipped with a PCI graphics card. Its OS is a TT TOS (3.06) modified
to cope with the Hades hardware, and its memory can be expanded beyond
any practical limits (the test machine had 40 Mb RAM).
Most programs tried by the Germans seemed to run OK, though they had
some problems with a few older programs, some of which using self-
modifying code. MiNT (and N.AES), however, is apparently not liked
well by Hades - though work is in progress to rectify this. Since
MagiC won't work either, the only current multitasking option is
Geneva.
GNU C++
-------
Recently GNU C++ was apparently upgraded to v 2.72. Don't ask me what
this means practically, but it shows that someone is at least keeping
the Atari version up-to-date (v2.72 is the most recent Unix version
too, that I have seen).
I could see a CD with this GNU C++ advertised, though I presume it
must be possible to get via some Internet address too (does someone
know?) or through a conventional PD floppy disk library.
To: Stephen Bruce
From: Mrten Lindstrm
Supervisor mode
===============
==> Q: When do you need it?
==> A: Whenever you access absolute addresses below $800 (system
variables) or in the intervals $FF8000-$FFFFFF - or $FFFF8000-
$FFFFFFFF - (the hardware addresses). Otherwise you will get a Bus
Error exception (two bombs).
You also need it in order to execute a few "privileged" instructions:-
RESET and (allowing access of the User Stack Pointer even from
Supervisor mode) MOVE USP,An and MOVE An,USP - but most importantly
any instruction (including RTE) that accesses the full Status
register.
The LOW byte of the Status register - containing the condition flags
and the X-bit - can be accessed from USER mode using an operand "CCR"
(for Condition Code Register). It can also, usually more effectively,
be accessed implicitly by any instruction that affects these flags
(e.g. MOVEQ #1,D0 will clear all flags except the X-bit).
The FULL 16-bit Status register can be accessed with an operand "SR"
(it will also be loaded from the stack by an RTE - "ReTurn from
Exception" - instruction) but ONLY FROM SUPERVISOR MODE.
The most probable reason you would want to do it - if ever - is to
turn off the interrupts, which you can do with the instruction:
ori #$700,SR (or move #$2700,SR)
Or possibly (for advanced colour trickery on the screen) to turn ON
the HORIZONTAL BLANK, which normally is off. Do that with:
move #$2100,SR
If you try to do anything of the above in user mode you will get a
"Privilege Violation" exception (four bombs). Restore the interrupts
with:
move #$2300,SR
Or save SR before you change it and then restore it.
==> Q: Could it cause problems to run "user-mode code" in supervisor
mode?
==> A: Anything that can be done in user mode should, in principle, be
possible to do in supervisor mode too. One exception is AES calls,
which require special precautions if they are to be made from super-
visor mode, but that is just because of the weird habit of the AES to
write on both stacks (other system functions write only on the
current, = supervisor, stack).
==> Q: How big is the speed increase if system calls can be skipped?
==> A: From the TOS listing in Atari ST Internals I could count an
overhead for BIOS/XBIOS calls of roughly 60+ microseconds (ON A
STANDARD ST), and similar figures can probably be assumed for other
system calls. This means that direct hardware accesses are often, or
even USUALLY, many times faster than system calls. On the other hand,
even if we count 100 æs per call, we can make 10 system calls in a
millisecond and 1000 calls in just a tenth of a second. So if we make
a finite number of system calls, I think it safe to say that the
overhead is indeed negligible. Then again, if system calls are made in
a loop, that is run hundreds or thousands of times per second, then we
are in a different situation obviously.
The periodical interrupts are a special case. The VBL runs between 50
and 71 times per second, and the system interrupt 50 times/second, so
speed optimization could mean something here. More importantly, all
interrupt routines (and other exception routines) ALWAYS run in super-
visor mode anyway (even in an otherwise "user-mode program"), which
make it natural to make direct hardware accesses from these. (Clean
GEM programs should in any case avoid installing any interrupts of
their own, preferably leaving this to AUTO-folder programs.)
If a HBL routine is used, it must, needless to say, not contain any
system call, since it is called more than 10000 times/second.
*/ I seem to remember reading somewhere (although I can't put my hands
on it at the moment) that application programs should normally be run
in User mode (except where the program needs to access a protected
memory address) because the Supervisor stack memory is fairly small
which severely limits the application program's stack memory. It is
possible to change the Supervisor stack address within the program but
the programmer must remember to restore it before leaving the program
or the system will crash on exit. I can't see any real advantage in
using Supervisor mode for a whole program since it is relatively easy
to switch to Supervisor mode and then back to User mode when required.
If anyone has any more thoughts, please let us know. ICTARI /*
----------------------------------------------------------------------
To: C programmers & Mrten Lindstrm
From: Jim Taylor
LOW-LEVEL VDI CALLS (Ref: The VDI Enhancer - Ictari 34)
-------------------
My thanks to Mrten Lindstrm for the corrections to my conversion of
his GFA enhancer code to C++. I am, however, left with one
outstanding problem.
ie. how to implement the vdi() call.
You say, Mrten, that the simple vdi() function (or similar) will
hopefully be defined somewhere in your C libraries. If not, it can be
defined based on the following small assembly routine:
_vdi: move.l #_VDIpb,D1
moveq #115,D0
trap #2
rts
Well, so far I cannot find anything similar in the HiSoft Lattice C++
libraries and have not been able to figure out how define it myself.
There is some information in the manual which is supposed to show you
how to implement assembler code from C but so far I have found it
incomprehensible. It would be handy if there was a suitable routine
in HiSoft's Lattice C, but it would also be very useful to know how to
call assembler from C.
I have had several attempts based on the example in the manual but I
cannot make them work. There is obviously something I am missing -
for example do you have to write the assembly routine with an
assembler such as MONST, compile it to object code first before it can
be used from C ? This indicates my fundamental lack of knowledge in
this area of programming and once again I look to fellow members of
ICTARI to help me out.
I have had a look through the ICTARI index for topics on calling
assembler from C but could find nothing.
----------------------------------------------------------------------
To: Ictari members
From: John Oakes
Bad news has come, in the way of the only magazine on offer has now
ended. ST Format issue 86 quotes -
"This is the final issue, we're sadly closing down. Don't be
disheartened though - there are loads of ways in which you can still
keep up to date with what is happening in the world of ST, Falcon and
Jaguar, including disk magazines, bulletin boards, the Internet and
via various software companies". Nick Peers. Editor.
I feel that having taken over Atari User, ST Review and ST World you
are left with no competition to work against. Hence you stagnate and
eventually suffer. Like most things in life, people like to see what's
on offer. It may seem doom and gloom but I do hope there is a Phoenix
from the flame soon.
*/ See letter from Martin Milner below for your Phoenix. ICTARI /*
----------------------------------------------------------------------
To: All
From: Stephen Bruce
Re: ST Format demise
I've just bought ST Format issue 86 only to discover that this is the
last issue. This concerns me for two reasons.
1) The selfish reason:
Without ST Format I have no news of Atari or its
products. I know much information can be gleaned on
the 'net but I don't have a modem & I'm not sure I
want one. We do have an Internet cafe in Aberdeen
which I could use but there is so much info out there
I don't know where to look.
2) The business reason:
Without ST Format there is nowhere to advertise
products, leading to lost sales & possibly resulting
in many companies dropping Atari support. No reviews
of new products leads to a similar situation.
What I want to know is if there are any other publications on the
market either in the U.K. or overseas (preferably printed in English)
which carry out a similar role to ST Format. Diskzines would be okay
as long as the content was well supported by the users (as in Ictari).
One possible solution would be to expand Ictari to include a
news/reviews section for the more important information & releases.
Apologies to Peter Hibbs if this increases your workload unduly.
Perhaps we could establish a system of shared information between
Ictari & other disk magazines, forming a network of contacts providing
info that is published on all of the diskzines.
Any comments from other users? I've had to keep this short as I'm late
in posting this disk & hope for feedback next issue. Maybe I will just
have to save for a modem & the ensuing bills, but I hope not.
*/ Sorry, I would not have enough time to expand ICTARI but see next
letter anyway. PDH /*
----------------------------------------------------------------------
To: *.*
From: Martin Milner.
Thought you might like to know, (if you didn't already) that a new
Atari magazine will be being launched in the next couple of months.
Below are some brief details:-
Mike Kerslake, a magazine publisher with 4? years experience has
signed up Frank Charlton, ex features editor for ST Format and Joe
Connor, ex Reader Disk/Public Arena editor for Atari World as joint
editors for a NEW printed Atari magazine called Atari Computing.
Atari Computing Issue 1 will feature 60 pages of A4 monochrome crammed
with quality editorial wrapped in a glossy cover. We're delighted to
welcome contributions from respected and well known journalists
including Graeme Rutt, Jon Ellis, Denesh Bhabuta and Kev Beardsworth.
Atari Computing Issue 1 will be launched at the forthcoming shows on
Saturday September 28th in Birmingham and Sunday September 29th in
London, for more details about the shows contact: Goodman
International, Telephone 01782 335650.
The shows are still going ahead, despite the demise of ST Format. If
anyone would like more info or better still would like to indicate
their wish to subscribe when the mag comes out, (the price will be
about 3 pounds an issue, I believe), write to me at 1 Portland Avenue,
Burton on Trent, Staffs. DE14 3GD. England or email me at:-
manifold@cix.compulink.co.uk.
and I'll either send you more detailed info or pass your intention to
subscribe on to the appropriate people.
*/ Perhaps you could keep us informed about future progress on the
magazine. This project sounds very interesting, the problem, I would
have thought, is that if there are not enough readers to keep the
glossy magazines going, are there going to be enough for a new
magazine to survive for long. I believe that ST Applications is still
publishing but even they seem to be struggling with different formats.
Time will tell I suppose. ICTARI /*
----------------------------------------------------------------------
To: ICTARI
From: Peter Brewster
Alien Technologies
36 Markenfield Road, Jennyfields, Harrogate, HG3 2TR
Following the recent demise of ST Format and the general lack of
corporate interest in the Atari computers, I felt it is long past time
that some attempt is made to keep a good old workhorse (no offence
intended!) out of the knackers yard.
Please allow me to introduce myself. I am currently an employee of
Marpet Developments, you will almost certainly have come across our
Xtra-RAM Deluxe at some point and no doubt probably torn out some
amount of hair installing your first ever 'deluxe'. I have worked with
Ataris for some time, being a home computer user going right back to
those heady 8 bit days of programs on audio tapes and wonky black and
white pictures on a spare TV set. My hope is to be able to continue
some of the service provided by Marpet for the Atari community and
extend this further by being foolish enough to develop new products
for ST's, STE's and Falcons. It is also my intention to continue to
supply the Xtra-RAM Deluxe and the FMCII.
To get the ball rolling I will, with immediate effect, be supplying
Deluxe kits at a special price, working from home with no overheads I
am aiming to supply (genuine) Marpet kits for about 10-15 (details to
be finalised and somewhat dependent on response to this mailshot). I
will also be offering replacement floppy drives and taking in repair
work.
Possibly the deciding factor in this is you and the user group to
which you belong. Suggestions are encouraged, what can I do for you ?
I hope that you take this with same dogged stubbornness that has kept
the Atari going! We're on our own now! I look forward to your reply
and am available most nights on 01423 500861, please get in touch.
------------------------------ End of file ---------------------------
