Copy Link
Add to Bookmark
Report
Ictari Issue 34
ICTARI USER GROUP ISSUE 34 May 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 34
==================
ASSEMBLY Assembly Language Tutorial. Part 2.
Dialog box code.
C Alert message function.
C Manship code Chap 23 (see correspondence section).
GFA Hi Rez scaling program demo.
Various mouse related routines.
STOS Generic STOS fix program.
STOS menu code.
MISC HTML information (compressed).
Rich Text format spec Part 1.
VDI Enhance program and documentation.
PC to Atari disk reader.
Current membership list.
Index for issues 1-33.
In next months issue of ICTARI (this may change) :-
ASSEMBLY PICPAC update.
Assembly Language Tutorial. Part 3.
C Dynamic memory debug library.
File listing functions.
Progress bar.
GFA File selector routine.
GFA Time/date routines.
STOS STOS demo code.
Pie Chart maker.
MISC Rich Text format spec Part 2.
SCSI FAQs
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
A couple of members have cancelled their membership this month and one
new member has joined, welcome to him.
READING ICTARI DISKS ON THE PC
------------------------------
I know that some members read the ICTARI disk text files on their PCs
(at work or wherever) before trying them out on the Atari.
Unfortunately disks which are formatted in a non-standard mode cannot
be read by the PC DOS, the program in the PC_TO_ST folder is a PD
program which should allow non-standard Atari disks to be read. We
haven't tried it yet and we do not accept any responsibility for any
problems it may cause on the PC system.
HTML/RTF FILES
--------------
Note that the HTML document file in the MISC folder has been
compressed and will need to be decompressed before use, a program like
UNLZH172.PRG or equivalent can be used to decompress the file. The
decompressed file requires about 367Kb of disk space. Note also that
the RTF_SPEC.TXT file runs to about 90 pages when printed out.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: Peter Hibbs
From: Lee Russell
Peter, I haven't contributed anything for a while so I thought I would
offer some source code from my latest project. What I am working on is
a simple program to cut rectangular portions out of .IMG files. The
program is not complete but I have enclosed two functions which
display a 'creeper bar' on the screen while the data is being loaded.
It's getting harder all the time to resist buying a PC (photo quality
graphics, etc) but I'm managing ! Does anyone think that a small
Encarta-like package would be possible on the ST ?
*/ I suppose anything is possible, the question is whether it would be
worth the effort, I doubt it somehow. ICTARI /*
----------------------------------------------------------------------
To: Anyone
From: Owen Rogers
Please could anybody tell me how to change the text in a BOXTEXT etc
in a resource file. I use GFA Basic 3.
Atari World
ÿÿÿÿÿÿÿÿÿÿÿ
For people wanting a refund from a subscription to Atari World (like
me!!) it is best to write directly to Specialist Magazines. COMPO
Software, who published Atari World, has also gone out of business.
Atari World closed because COMPO closed. The magazine itself was doing
very well! Specialist Magazines can be contacted at -
Specialist Magazines,
Salisbury House,
Station Road,
Cambridge,
CB1 2LA.
If anyone has any success please write back to Ictari and tell us what
action we should take to get our money back!!
NB There is a small chance that SYSTEM SOLUTIONS may take it over. I
am going to wait for a month or two just in case they do take it over.
*/ I subscribed to Atari World and this month I received a notice from
my bank saying that Specialist Magazines had cancelled my standing
order and refunded my last subscription so I guess that they are no
longer in business. PDH /*
----------------------------------------------------------------------
To: ANY STOS PROGRAMMERS
From: George Hodgson
" HELP HELP HELP "
Can anyone help me get my head around the idea of loading data into a
program from a file ? I know this must sound daft "BUT" there is so
little detailed information on the subject that it's hard to pick it
up (for me that is ??).
What I am trying to do is write some lottery programs that need a data
file to store the lottery numbers in, and the file to be up-dated each
week with the new numbers !
I have the programs working, but at present am using the read data
statement to get the data required into the program and, of course,
the data is in the listing !
"HOW DO I USE A SEPARATE DATA FILE FROM DISK ?"
Please try to help as I would like to compile the programs to see how
fast they are ?
Any help, however small, would be very much appreciated ! So come-on
lads, write explaining, send me a disk with examples on, (I'll return
and refund postage + send some prgs !) or give me a bell with your
phone No and I'll ring you back !
To: John Cove
I have just read the Intro doc by John Cove on the Assembly Tutorial,
sounds good ! Just what us learners need.
----------------------------------------------------------------------
To: Peter Hibbs
From: Raymond Reid
With regards to the Saucers source code on Issue # 31 of Ictari, this
is ** NOT** a game, but a sound and motion demonstration in assembly
language, as the opening comment states.
I have included the source and DAT file again along with the compiled
program which does run although the SAUCERS.DAT file must be in the
same directory. This source compiled and ran OK on my STe which has
4mb memory, hopefully this helps clarify its status as a 'game'.
I have also included a source file from C-Manship Complete by Clayton
Walnum, CHAP_23.C (from chapter 23!!) which I am having problems with
trying to compile it using Prospero C.
The error message I keep getting is: 'ptr-to-fn initializer is non-
NULL integer' when it gets to the "TEDINFO rs_tedinfo[] = {" etc. I
have worked through most of the book but I am still at a loss on how
to correct this although I have been able to adapt and alter other
files from this book to run with Prospero - even some header files.
Can anyone help???? please!!!!!
Not being a competent programmer in C, I desperately would like advice
on how to correct this - thanks in advance.
*/ See the C\C_MAN_SH.IP folder. ICTARI /*
----------------------------------------------------------------------
To: Tony Harris
From: Jason J Railton
Re: Mouse Interrupt Priorities
You said in ICTARI #32 that you were having trouble with rasters
wobbling as you use the mouse. I can see myself coming up against the
same problem in something I'm working on. As far as I know it is not
possible to reduce the priority of the mouse interrupts to stop this
happening. Thomas Nilsen's mouse handler, also on ICTARI #32 would (I
suppose) have the same problem, because it uses the same interrupt
method for handling the mouse as the system does. (So, thanks Thomas,
but I don't think it'll work with rasters).
The problem is that the standard mouse reading procedure, called
RELATIVE mode, can interrupt at any time. If it interrupted at
regular intervals, it could be controlled. Since it doesn't, it
interferes with the rasters by a varying amount each frame, causing
them to jump about.
It actually interrupts when the mouse is moved in any direction by a
certain threshold distance. It forces a jump to a pre-defined
handler, which should note the relative movement reported since the
last event.
The only solution I can think of is to put the mouse in ABSOLUTE mode,
in this mode, the keyboard chip should monitor the mouse, recording
its position on a definable X/Y grid. You actually have to ask for
the mouse position, then an interrupt occurs to report the co-
ordinates.
Since you then have to request a mouse report (the interrupt and
report sequence is called a 'packet'), you can control when these
occur. Then you can either do this 'above' your rasters (immediately
after your v_sync interrupt has occurred); or check something (a
colour register for example) to tell when the rasters have just
finished, before calling.
However, I haven't tried this myself. Does anyone out there have an
ABSOLUTE mouse reader they can demonstrate? I haven't got round to
this yet - I'm working on 3-D graphics, a STOS game, etc...
To: Peter Hibbs
Re: STOS Compatibility
Interesting to hear that my 3D demo gives you a blank screen. I've
got the same version of TOS as you - 1.04. Still, I'll try and pre-
fix it once you give out the fixer.
I've written a short demo (although compiled it gets to about 80k) to
try out controls in a STOS compiled program. It uses the STOS
joystick, one of the STE Extension joysticks, and the STOS mouse
routine. I'd be grateful if you could put it on a later disk (I'll
pre-fix it and send it in once I get ICTARI #34) for people to test
out the control methods. I use the STE extension because it has a
convenient twin-joystick routine.
Anyway, on this demo you move a small light patch around the screen,
which is chased by one of two robots. These robots aren't just
animated as they move around the screen; they are actually made up of
separately programmed moving parts and walk in quite bizarre, but
nevertheless realistic and convincing movements. Hence the size of
the demo.
If you don't think you'll have room for it, I could just send in a
short control tester, but it would be nowhere near as entertaining.
To: Martin Milner
Re: STOS Compiler 2.7
I've actually got STOS 3D, but I didn't realise it had a Compiler
update. It doesn't mention this in the manual and as I already had
STOS 2.6 I never used the updater. Anyway, with Compiler 2.7, and
that pre-fixer off this disk (I'm going to look pretty daft if Peter
misses it off this one), my troubles should be solved.
Thanks for the tip, anyway.
To: David Preston & Peter Hibbs
Re: Total NBA
The videogame with the basketball players you've seen is Total NBA,
from Sony, running on the Playstation. The players are actually all
texture-mapped polygons, not sprites, and the reflections are made by
mirroring the players' lower legs and feet mathematically in 3-D, to
just below the floor, and drawing them in semi-transparent polygons.
Stadium hoardings and lights are done in the same way, and it looks
brilliant. (Mind you, if you watch real basketball, it's the players
bright shirts and shorts you see reflected, not their legs, but I
suppose that's too many polygons).
Still, I think Peter was asking about mirroring a sprite left-to-
right, so his sprite can face/walk/slither in either direction,
without having to store two sets of sprites.
Peter - there is no simple mathematical relationship between a word
and its reflection. Ideally, the reflection should be done to build
up a library of images in memory, and use these for real-time display.
A lookup table is possible for real-time display, but still gives a
significant drop in speed. Remember that to mirror a word, you have
65536 combinations, but need twice this to store the results of the
flip (131072 bytes). You have to double the word you're going to
mirror, and use the offset as a 32 bit number. You then pull a word
(two bytes) from that address.
If the mirroring is done in preparation, there is no need for speed,
so the shifting method is simplest.
Of course, you can get the problem seen in some games where your
character changes from being right-handed to being left-handed, or
other small details are reversed. The Ferrari horse on the back of
the car in OutRun is a good example, across several formats (even the
arcade game, so I've heard, though I've never noticed), and the
fighters in Super Street Fighter II Turbo X Alpha Pro-Plus Extra Ex-
Lax Etc. (whatever they're on now).
To: Peter Strath
Re: File Viewer
It works on my 520STFM, TOS 1.04, 2.5Mb contraption. What's the
betting my STOS stuff doesn't work on yours though? Is it meant to
handle graphics, or just text? Peter mentioned .IMG files, but will
it be able to do any others (e.g. .NEO)?
To: Peter Hibbs
Re: STOS Games
I have two STOS games I'd like people to try, once I've re-compiled
them. One is a two-player TANKS game - like VCS 'COMBAT', although I
wouldn't know because I've never played 'COMBAT'. Anyway, steer one
tank and shoot the other one. It has the addition of mortars,
bonuses, guided missiles, homing missiles, counter-measures,
interactive scenery (fancy talk for "you can shoot things that don't
move too") and a countdown timer that goes 'ping'. The other,
'Buzzsaw', still isn't quite finished but should be very soon. I
think it's best described as Tetris with the 'gore' option on. (Best
described by that particular phrase because you're even more confused,
but intrigued at the same time).
How can I get these around? I'd like them tested before I send them
to a PD library, but they're huge, and together would probably fill a
disk. Could you dish out copies, if people sent you an extra disk, or
shall I ask for stamped-addressed envelopes and disks from people?
And what would everyone else like? If one of these programs were put
on the ICTARI disk, the magazine would have to be cut down by half to
fit it on. Would folk mind? Don't send anything yet though anyone!
I've still got some work to do before they'll be ready!
*/ We will have to think about that when the time comes. ICTARI /*
----------------------------------------------------------------------
To: Peter Hibbs & Marten Lindstrom
From: Jim Taylor
Yes Peter, I also thought of this idea of using logbase & physbase in
conjunction with malloc but like yourself could not figure out how to
alter the size and shape of the screen. As you say, there MUST be a
way of doing it. When you think about it the VDI must get its
information from somewhere as to its drawing area limits and sizes - I
can't imagine these will be embedded into the system code - or could
they?
In my ST Internals book it describes a variables block which can be
accessed with line-A $a000. Here a few which seem relevant:
Offset Name Size Function
------ ---- ---- --------
00 v_planes word number of planes
02 v_lin_wr word bytes per scan line
NB: No mention of numbers of scan lines
also
54 _CLIP word 0=clipping !0=no clipping
56 _XMN_CLIP word upper LH corner of clipping area
58 _YMN_CLIP word upper LH corner of clipping area
60 _XMX_CLIP word lower RH corner of clipping area
62 _YMX_CLIP word lower RH corner of clipping area
Are any of these the ones you tried changing? Did you try altering the
clipping values?
I have also spotted a fragment of code in the same book in the BIOS
listing which is interesting.
************ Scrdmp, hardcopy ***********
005a60 sub.l a5,a5 Clear a5
005a62 move.l $44e(a5),$654(a5) v bs ad, screen output
005a68 clr.w $658(a5) Offset to null
005a6c clr.w d0
005a6e move.b $44c(a5),d0 Sshiftmd, screen resolution
005a72 move.w d0,$662(a5) Save
005a76 add.w d0,d0 Times 2
--> 005a78 lea $5ad4(pc),(a0) Table for screen resolution
--> 005a7c move.w 0(a0,d0.w),$65a(a5) Get screen width
--> 005a82 move.w 6(a0,d0.w),$65c(a5) Get screen height
005a88 clr.w $65e(a5) Left
005a8c clr.w $660(a5) and right to zero
005a90 move.l #$ff8240,$666(a5) address to colour pallette
005a98 clr.w $66e(a5) Clear mask pointer
005a9c move.w $a8c(a5),d1 Get printer configuration
.
.
.
.
************* Parameter table for hardcopy **********
005ad4 dc.w 320,640,640 Screen widths
005ad8 dc.w 200,200,400 Screen heights
Lines $5a78, $5a7c and $5a82 certainly seem to suggest that the screen
sizes are hard coded and that this piece of code uses the values at
locations $5ad4 - $5ad8. It does, however write them to $65a and
$65c. I don't know if these are the VDI working locations for the
screen parameters and if they are alterable.
I have also noticed elsewhere in the BIOS listing, in a section to
clear the screen, that it uses an immediate value of $8000 for the
screen size - this is not good news since it suggests that the screen
area is not variable. However I am still not convinced that a screen
configurable RAM (SCRAM) area is not possible. My reason for this is
as follows:-
A couple of weeks ago I received a phone call from a chap in Australia
asking for info on my drawing program. He also told me about a piece
of PD software called MONSTER and wondered if it could be implemented
in my program to get over the problem of long screen refresh times
with large drawings. Apparently this piece of software tricks the ST
into thinking it has a monster screen area and allows the user to jump
to any section of it without any refresh delay. I've contacted
Goodmans and they say they can supply me with a copy. If it works in
the way I hope, I'll try and get some info' from the author.
*/ Jim has sent the programs mentioned but I think the next letter may
solve the problem (thanks once again to Mrten). ICTARI /*
----------------------------------------------------------------------
To: Phil Hodgkins
From: Mrten Lindstrm
Thanks for the enlightenment on VDI usage in the AUTO folder. I had
heard before that this was possible but don't think I had realized
that the physical, rather than a virtual, workstation had to be used.
Thinking about it, though, it does make sense that the one physical
screen workstation, to which all virtual ones relate, has to be opened
first, whether by an AUTO-folder program or - later - by the AES.
To: Jim Taylor and everybody else too
From: Mrten Lindstrm
ATTENTION, ATTENTION, ATTENTION!!!
OFF-SCREEN BITMAPS AND OTHER NEW VDI CAPABILITIES
-------------------------------------------------
Just a few days ago I happened to stumble across what must be the
ideal solution to your problem, and doubtless to other problems too. I
cannot understand that I (and seemingly all other Ictari members too?)
have failed to discover this vital info until now. (Though Richard
Evans did, in Ictari 27, mention news on an NVDI 3 users manual - in
German - in the public domain; I tried writing to 2B, but have so far
not received any answer.) What I have now found, was in a file
"ENHANCER" under "TOSFIXES" on a CD with Atari PD (Gemulator Gold CD).
If ANYONE has found any newer material, e.g. the NVDI manual mentioned
by Richard (maybe on one of the many German Atari CD-ROMs, or in some
German Internet site?), then DO send it in!
--------------
NVDI 2.5+ adds NEW VDI FUNCTIONS for handling off-screen bitmaps (and
also for returning more info on the screen than the ordinary v_opnvwk
and vq_extnd functions reveal). This in itself may not be so great
since many Atari users don't have NVDI. But 2B have released a small
stand-alone program that provides these functions to EVERYBODY ELSE
TOO. The program, called the 'VDI Enhancer', is basically freely
distributable as long as no profit is made from it. It should be OK to
deliver with any freeware or shareware program or budget commercial
one up to a value of 50 DM (ca 22 or 220 Swedish kronor); with more
expensive programs the written consent of the Behnes may be required.
With this message, I have sent the Enhancer PLUS a bug-fixed version
(disassembled, bug-fixed and reassembled) that I think should be OK to
distribute as long as the original is included (otherwise I might (?)
make a complete rewrite for which the source too could be published).
You may be interested to hear that the Enhancer uses just the ideas
presented by Peter Hibbs last month: for each VDI call, related to
off-screen bitmaps, it temporarily changes the logical screen address
and a number of Line-A variables (to be precise: the words at offsets
-4, -12, -666, -692, -690, -2, 0, 2, -346 and -598) and internally
makes use of a separate virtual workstation.
The advantage of the VDI Enhancer, compared to program-internal
solutions, is of course that its functions are forming an existing
and, it now appears, well-documented STANDARD, since they are
available with every version of NVDI (2.5+). While the Enhancer itself
should work on every standard Atari computer screen, its function
calls will also work on any GRAPHICS CARD (or MagicMac etc.), as long
as an NVDI version (or anything else that is VDI-Enhancer compatible)
is available for it - and I understand there are NVDI versions for a
wide range of cards.
With Atari themselves apparently gone from the scene of OS develop-
ment, we will have to rely on companies such as 2B, C-Lab etc. and
hope that they coordinate things between them, or at least document
own extensions and adopt those of others. We too can contribute to the
harmonization by supporting good ideas, as I think this one is.
All that the end user has to do, is to copy the ENHANCER.PRG (or
ENHFIXED.PRG) into his AUTO folder - unless he has NVDI when he
doesn't have to do ANYTHING. Should he have SpeedoGDOS, then
ENHANCER.PRG must be placed after it (a message will otherwise be
written on screen).
All that the application programmer has to do, is to make sure that a
cookie 'EdDI' is present - as it should be if the user has done as
above. Then use the new VDI functions.
--------------
¯¯¯¯ THE NEW VDI FUNCTIONS ¯¯¯¯
VDI Enhancer v1.00 (or NVDI) makes available the functions :-
v_opnbm Open bitmap (as a VDI workstation)
v_clsbm Close bitmap
vq_scrninfo Inquire screen info ("extended vq_extnd")
and in addition claims to fix a faulty behaviour of the old
V_GET_PIXEL on Falcon high-colour screens (?).
The main OP code, and most of the parameters, of the new functions are
the same as of v_opnvwk, v_clsvwk and vq_extnd respectively (which
internally are called by the Enhancer). But each of them in addition
require the SUB-OP code (contrl[5]) to be set =1.
¯¯¯¯¯ V_OPNBM ¯¯¯¯¯
v_opnbm in addition differs from v_opnvwk in taking a pointer, in the
longword in contrl[7..8], to a standard 20-byte MFDB (see VDI raster
operations) for the bitmap, and in taking 9 extra intin (or work_in if
you like) elements for a total of 20 intins; make sure to set
contrl[3]=20:
intin[11]: Width-1 (will be rounded up to 15, 31, 47, 63 etc)
intin[12]: Height-1
intin[13]: Width of a pixel in æm OR =0 for screen resolution
intin[14]: Height of a pixel in æm OR =0 for screen rez
intin[15..19]: =0 (reserved)
If you clear the contents of the MFDB before passing it to v_opnbm
(actually only the first longword + the word at offset 12 need be
zeroed) then v_opnbm will allocate memory for the bitmap, clear it (=
make it WHITE, which on a high-colour bitmap means setting all bits)
and fill in the MFDB. The bitmap will have the same number of colours
as the screen.
Alternatively, you can always set the (bits/pixel) word at offset 12
to =1, to open a MONOCHROME bitmap.
And, finally, you have the option of setting the first longword in the
MFDB to point to a pre-allocated bitmap, in which case v_opnbm will
NOT clear it. Instead the word at offset 10 (the format flag) will be
used to determine whether the bitmap needs to be transformed from VDI
standard format (whole bitplanes) to device specific format.
IMPORTANT: All bitmaps opened with v_opnbm are in device specific
format. Meaning that 100% clean programs in principle shouldn't
directly manipulate them, but rely solely on VDI calls to draw and
copy to and from them - until they are transformed back with vr_trnfm.
¯¯¯¯¯ VQ_SCRNINFO ¯¯¯¯¯
vq_scrninfo works like vq_extnd, except when called with mode 2 when
it returns 272 words info on hardware screen and colour
representation.
This is just the function that I have been looking for a long time!
See further information with the Enhancer in the MISC folder.
To: Falcon users
From: Mrten Lindstrm
V_GET_PIXEL ON HIGH-COLOUR SCREENS
----------------------------------
According to the Atari compendium this function, on a 16-bit screen,
returns
as 1st output parameter (intout[0]): The colour value of the pixel
as 2nd output parameter (intout[1]): 0
But the v_get_pixel implemented in the VDI Enhancer by 2B returns
(from what I can see during disassembly, not actual experiment):
as 1st output parameter (intout[0]): The colour value of the pixel
as 2nd output parameter (intout[1]): -1
Could you perhaps test this function on a real Falcon, without the
Enhancer (or NVDI?), and see what is returned (2B in the Enhancer
documentation says it doesn't work on high colour screens). Or maybe
you have some information from elsewhere?
(Even stranger is any 32-colour mode where AC has the colour value be
returned low-word - high-word, while 2B - through their Enhancer - do
the opposite: high-word - low-word, + writes a -1 as a third word.)
ALSO: Could you, with the ENHFIXED installed, try opening an off-
screen bitmap and use v_get_pixel on it, to see if I - as I hope -
have managed to fix this function (it was faulty in 2B's original).
To: Thomas Nilsen
From: Mrten Lindstrm
CLIPPING THE DRAWING IN (PARTIALLY COVERED) WINDOWS
---------------------------------------------------
No, the problem is not with OBJC_DRAW. This function clips and draws
only a single rectangle, but you would be in exactly the same
situation if clipping and drawing with the VDI.
Instead, what you have to do whenever drawing anything at all in any
window, is to do it in a LOOP that finds, clips and draws each visible
rectangle of the window, one at a time.
The single "dirty rectangle" that you get with AES redraw messages
(received with EVNT_MULTI) is, as you have discovered, only a HINT as
to what area needs to be redrawn; ensuring that no time needs to be
wasted on drawing OUTSIDE the dirty rectangle, but telling nothing
about its INSIDE (which may cover other windows).
WIND_GET with modes 11 and 12 returns the visible rectangles (OK to
draw within), and the full drawing routine would look something like:
'~~ (Re)drawing contents of a window using OBJC_DRAW ~~
'
~WIND_UPDATE(1) ! Request permission from the AES to start drawing
~WIND_GET(wh,11,x,y,w,h) ! Get first visible rectangle
WHILE w OR h <> 0
' -> If the drawing is done in response to an AES Redraw message
' then calculate the intersection of visible rectangle with the
' "dirty rectangle" given with message.
' This step isn't functionally necessary (the full visible
' rectangle could be used and the dirty rectangle ignored) but
' saves time by reducing the area clipped and drawn.
~OBJC_DRAW(tree%,0,$7FFF,x,y,w,h) ! Draw tree clipped to x,y,w,h
WIND_GET(wh,12,x,y,w,h) ! Get next visible rectangle
WEND
~WIND_UPDATE(0) ! Window contents drawn. Allow others to screen again
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When instead VDI is used for drawing, the routine would be essentially
the same, except that the mouse needs to be hidden:
'~~~~~ (Re)drawing contents of a window using VDI ~~~~~
'
~WIND_UPDATE(1) ! Request permission from the AES to start drawing
~GRAF_MOUSE(256,0) ! Hide mouse to avoid corrupting drawing
~WIND_GET(wh,11,x,y,w,h) ! Get first visible rectangle
WHILE w OR h <> 0
' -> Do intersection calculation here.
' -> Clip here (In GFA Basic simply "CLIP x,y,w,h"
' In other languages x,y,w,h must be converted into VDI coordinates
' usable with VS_CLIP - i.e.: "VS_CLIP(x,y,x+w-1,h+y-1)" .)
' -> Do the drawing here
WIND_GET(wh,12,x,y,w,h) ! Get next visible rectangle
WEND
~GRAF_MOUSE(257,0) ! Show mouse
~WIND_UPDATE(0) ! Window contents drawn. Allow others to screen again
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To: All who use my PICPAC library (assembly, GFA Basic 3 and others)
From: Mrten Lindstrm
I only just now discovered a tiny but completely disabling bug,
introduced during my revision of PICPAC (Ictari 24), in the routine
IMGPAC for packing images in IMG format. Luckily, no-one seems to have
tried to use it, since I haven't heard anyone say anything about it.
If you had tried it, then it would have always exited, returning an
error (LBMPAC, on the other hand, works fine).
I cannot explain how such an obvious bug could slip by, without me
noticing it, except that, as you might deduce, I haven't until now
actually saved any IMG files with the revised PICPAC (only IFF ILBM
ones). I guess I thought the change (checking for memory overflow) was
so small that I didn't need to test it much, considering that the
packing itself was solidly tested before.
I send a corrected version of the file PICPAC2.S to Ictari with this
message. (I also send a new PICPAC1.S with the only change being safer
blitter handling, by GETFM and PUTFM, according to Programmers' Forum
in ST Application about a year ago).
*/ See next month for the PICPAC files. The off-screen bit map info
looks extremely interesting, I haven't had a chance to try it out yet,
if Jim Taylor does get it working in his program, we would be
interested to hear about it. ICTARI /*
----------------------------------------------------------------------
To: Peter Strath
From: Stephen Bruce
Re: File viewer Beta test
I've only given this a brief run through, but on the whole I'm happy
with the program & WOULD consider changing to this from my current
favourite once it's been completed. A small registration fee would not
be offensive as I'd like to see more of your work. However...
As with Peter Hibbs, I would like to see the main file selection menu
enlarged and/or made sizeable, both to increase the number of files
selectable and to allow longer EFIs.
On the subject of EFIs, it would also be useful if at least one
default EFI list was loaded on entering the file viewer, as it's a bit
of a pain having to load them separately each time it's run but they
are a neat idea. To keep everyone happy this option could be made
selectable via an on/off option in the menu bar. Assuming you accept a
default EFI list, it then becomes useful to have a secondary EFI list
for those occasional disk accesses i.e. one EFI list with your
standard defaults and another specific to the disk you are searching.
One suggestion for working this would be for the program to read the
second EFI list from the root (or perhaps an EFI) directory of the
drive you are searching on the initial reading of the disk. This may
be too unwieldy in practice, but you did ask for ANY suggestions.
(P.S. Since writing this I've examined the program further & suspect
you've partially covered this with the FV.EFI file being loaded).
Peter also suggested that there was no reason for the re-read &
previous directory options in the file selection menu. While I agree
that the previous directory can be accessed by hitting the close box
on the window, the re-read option IS useful when working with floppies
(as I have to do). For example, when searching for a particular
listing or article from previous issues of ICTARI, I don't have to
wade through the directory tree & can quickly jump to inside the
relevant folder (A:\ASSEMBLY, A:\C, or whatever), simply by inserting
a new disk & selecting this option. So scrap previous directory, but
retain re-read directory and I'll be more than happy.
More useful than the above would be the ability to change drives
without having to go all the way back to the very first menu entry. My
suggestions would be to have the A:, B:, etc ALWAYS shown as the first
option in the file list regardless of the position in the directory
tree, OR have a drive selection option on the menu bar.
The only actual bug I've found was that the program incorrectly
identifies TOS 1.62 (later STE TOS) as TOS 1.98. I've seen this
problem (along with an explanation of why it happens) somewhere, so if
you can't fix it I'll rummage through my old ST magazines for this
info. Not a terrible shortcoming in the program I'll admit, but we can
do without confusing less experienced users.
Lastly, it would be useful to have some basic file editing facilities,
as I'm personally more inclined to give up my limited memory to a
program that's more of an 'all rounder'. Yes, a file viewer is handy,
but I can also view files in a text editor, which is what I've done up
till now, despite the impressive capabilities of other viewers. I'm
being picky here I know, but that's me all over.
To: John Cove (or Tronic if you prefer)
From: Stephen Bruce
Re: Assembly tutorial
As a relatively inexperienced assembly programmer, I found part 1 of
the tutorial useful, as so far I've been muddling along on my own. It
was reassuring to know that I haven't been making (m)any fatal
mistakes regarding my use of supervisor mode, but I tend to put my
programs into this mode & leave them there. Is this dangerous for the
system, or am I safe to do this? I only ask as I can't see the
benefits of using user mode. Maybe this is covered in later tutorials,
but if not, can anyone help me?
Also, the info on the DC.? instruction helped clear up a problem
that's really annoyed me in the past, as I always thought that a DC.W
or DC.L could have lower bytes manipulated by .B & .W commands
respectively. Clearly this is not the case, but how about the DS.?
command? Can I use other operators to work on these, or must they also
retain the same operator size as the definition?
Finally, I just wanted to say thanks for putting me straight really,
as the article has given me a renewed enthusiasm for programming.
So... T H A N K Y O U (grovel, grovel).
*/ It is possible to manipulate any part of a DS.L or DS.W memory
store if you really need to although it should be used with care and
only if you know what you are doing. For example, the longword store -
store ds.l 1
could be loaded with some data, for example -
move.l #'1234',store
which is just four bytes holding the value 1234 in ASCII. If you now
want to change the '4' (the fourth byte) into a '7' you would use -
move.b #'7',store+3
which would copy the value '7' into the label address 'store' plus an
offset of three. This can also be done with DC.? stores but is NOT
recommended as this would be effectively self-modifying code which may
not work on machines (such as the TT) which have program code cache
memory. ICTARI /*
----------------------------------------------------------------------
To: Anyone
From: Richard Evans
Could anyone provide me with information about the following,
preferably from a 'C' viewpoint:
1) How to install a clean up routine in the etv_term vector (0x408)?
(MagiC documentation states that each process has its own etv_term
vector - how does this work?).
2) Is there a reliable way to install interrupt driven routines?
----------------------------------------------------------------------
To: All
From: Theo Ros
Is there anyone who can dive into the algorithms concerning picture
dithering? I see wonderful programs like IMAGECOPY do it, but I keep
wondering HOW...
----------------------------------------------------------------------
To: Jonathan Leckie
From: David Preston
Re: UDO
-------
There was a version of UDO on a recent ST Format coverdisk (which you
may have got yourself by now) and having had a look at it, I think you
might be disappointed. As I understand it, UDO is a utility to enable
e.g. programmers releasing software to include the program
documentation in a variety of formats (HTML, ST-Guide, ASCII etc). The
way this works is that you produce your document in UDO's own script
file format, and it generates the various file types from this. I may
have got hold of the wrong end of the stick, but this is a one way
only process, it doesn't translate back from those various formats.
To: Mrten Lindstrm and *.*
PC Contemptibles
----------------
Mrten, as always, talks a great deal of good sense (Ictari 33). One
point that Mrten's comments reinforced to me as something I suspected
all along was that home computers are getting to be like cars. I'll
explain. If you're a car enthusiast you might very well have a classic
like a Morris Minor (or an ageing Saab or Volvo if you're in
Scandinavia) to tinker with and enjoy in your leisure time, but for
day-to-day transport use something far more up to date and
technologically advanced, and far more complicated under the bonnet.
ST's are the classic - just like a classic car, you can tinker with
them, understand every nuance of what they are doing and spend the
weekend with your head under the bonnet if you want to. The PC is like
your everyday transport - you don't mind _how_ it does it so long as
it does it, quickly and reliably (er, well ok perhaps it wasn't that
great a comparison...).
To: *.*
STOS compiled program problems
------------------------------
Has anyone experienced the situation where a compiled program doesn't
do exactly what the interpreted version did? I've been messing about
with a little scrolling message demo for submission to Ictari, but
it's driving me to distraction. The compiled version seems to be doing
different things with the palette from what the interpreted version
was doing. Anyway, it's too late to submit the damned thing now
(sorry, Peter, if this disk reaches you a bit late), but I'll work on
it some more. In the interim I'd love to hear from anyone who has had
any similar experiences.
----------------------------------------------------------------------
To: *.*
From: Kevin Cooper
My name is Kevin Cooper and I am wondering if anybody could help me,
currently I need to find out information on emulators, how they work
and what I need to do to make one. Also I have a friend who has a PC
which runs GEM, if I program in C do I have to use any special
compilers, etc, if I want to program for Atari GEM and PC GEM without
making any changes except recompiling on the other system. I have a
number of projects under development which help the programmer by
taking away certain problems including (what I will most likely
release as shareware) a Vector Speedo Font engine so it is in reach of
more people. So now everyone should support GDOS as you could
distribute the shareware version along with your programs letting them
test your programs to the full. When finished, my programs will make
your programs more comprehensive by taking away some of the fiddly
bits so you can concentrate on more important things (more when they
are ready).
To: *.*
Looking at the current Atari programs many of them are good, they work
well, some better than the supposedly superior PC counterparts so I
started to think, really as programmers we can program anything but
most of the time we don't know what people want so perhaps a
questionnaire could be made asking what people want and what options
would you want in that program. For instance, they could say an art
program with normal options and a masking tool, club members would
print these questionnaires asking people what they need, they would
ask everyone, not just computer users, a technical drawer would want a
computer program that lets them do 3D modelling, producing many
different types of drawing, colouring them correctly, he/she would
write down all the different views that are needed e.g isometric,
planometic, oblique, etc, whereas a programmer may only make a
standard perspective drawing. By asking many people who want the same
thing we will get more information on what is needed and by looking at
theses questionnaires it will increase productivity in the Atari world
which is always for the better. One of the questions would be if I
gave you ten billion pound budget to develop a word processor what
would it do, list everything, we would then brainstorm this
information. The questionnaires will be sent back to ICTARI to be
published in the MISC folder, this way we can concentrate on what
people want.
To: Jason J Railton
I liked your polydemo it was very interesting, I have been thinking
about making a STOS extension for a while now, and I think, using this
code, a new 3D extension could be made as the old one was rubbish. I
would be interested in doing this so contact me if you want to go
ahead. My address is in the membership list.
To: *.*
Has anyone else tried out the new OMEn operating system, it is a full
multitasking operating system with full cross platform compatibility.
It has been written in pure assembler and will run on a standard 520
STFM and still have room for programs. It has the ability to share
files between programs e.g an art package and a DTP sharing the same
picture file, so the DTP's programmer does not have to write a word
processor if he doesn't want to as he can use other peoples.
I recommend you try it, the demo version is available from Floppyshop
and a demo version of the development kit is also available, full
versions are also available but I haven't decided whether to buy or
not as yet.
To: *.*
Does anyone out there know any good books, I would like anything
really but programming orientated is what I want most, such as is
there a book on writing HMTL documents as it may be possible to
reverse engineer it to make a HMTL viewer, I would be interested in
lots of things like that. Does anyone know where I can get a book on
Image processing.
To: *.*
I am very worried about the state of the Atari Magazines. This month I
haven't had either, I know Atari World has gone under along with Compo
but what about ST Format, why hasn't it come, is it just me or is it
everyone. You may or may not have heard but Sam Tramiel is now in
hospital, his father Jack Tramiel (from way back when the ST came out)
took over the company and now they have merged with a disk drive firm,
Atari now has a new boss, so what are his views on the ST's and
Jaguar? Also many Jaguar games have come out but they haven't been
stocked by Special Reserve, what is going on ?
*/ The questionnaire idea sounds good in theory but I suspect that it
would not work so well in practice. The first problem, as we have
found in the past, is to get people to contribute ideas on what they
want and also you will find that most end users (as opposed to
programmers) don't really know what they want a program to do until
they actually start using it. The second problem is that ICTARI caters
solely for programmers who probably don't know what artists, technical
drawers, etc, etc, would want a program to do. One solution would be
to find a user who has experience on the type of program you are
writing and get him to offer advice and do any beta testing of the
program as it is being written. Of course, there may even be some
ICTARI members who can help and we would be happy to publish any
requests for advice on specific programming projects.
The state of the Atari magazines does give some cause for concern. As
you say, Atari World has ceased and I very much doubt whether it will
be resurrected. ST Format magazine is still being published although
not many newsagents seem to stock it now. Also the subscription
renewal forms for ST Format (according to a colleague of mine) are
being issued for six months only now which I think could be
significant. When you consider the size, price, content and number of
advertisers using ST Format now I would not be surprised to see the
magazine go the same way as Atari World within six months although
they have said publicly that they have been allocated a budget for 12
months. The subscription based ST Applications magazine is also
declining at a rapid rate and I would expect that one to go at some
time in the near future (that's just my opinion and not based on any
inside information). If (or perhaps when) ST Format does cease to
exist, it will leave Atari users and programmers with a major problem,
where do we buy new software (what little there is) and for
programmers, how do you market and distribute new programs. I suspect
that the Atari PD Libraries would also find it very difficult to
continue with no Atari magazines to advertise their software. Using
and/or writing software on the Atari in these circumstances would be
like working in a vacuum, i.e. not very practicable.
I think the time is quickly approaching when serious Atari users will
have to consider switching to another platform, which, I suppose,
really means the IBM PC. From a serious programmers point of view
there are big advantages, a huge potential market for new software
(although writing an application that hasn't already been done will be
more difficult). There are also masses of software orientated books
and magazines available and the InterNet can probably provide any
further information required. Also the programming environment on a PC
is now very attractive, high resolution 256 colour screens,
sophisticated programming languages such as Visual Basic, C++ and
Delphi which are much better than anything on the Atari and, at last,
with Windows95, an operating system which is now better than the
Atari's. The biggest disadvantage of changing is probably financial
depending on ones requirements. A fast Pentium system with 16Mb RAM
and CD ROM would cost over 1000 although a lower spec '486' system
will cost considerably less and would be adequate for most
programmers.
I have to confess here that I am seriously considering purchasing a PC
sometime in the next few months. I have begun to notice recently when
looking through ST Format in W H Smiths that I am getting sympathetic
looks from other PC magazine buyers. The main reason for changing,
however, is, like most programmers, I want to write software that
other people can use (and maybe even make a little money from them
too). Of the two utility programs that I have had published over the
last two years there have been less than six registrations (OK they
may not be very good programs) but I think it is also an indication of
the declining number of Atari users available.
So what does all this mean for ICTARI. Over the last few months we
have lost a number of members, some of whom I know have moved to the
PC and we have also gained a few new members in the same period. The
current membership stands at about 60 including myself. I am prepared
to continue running the group for the next few months at least
although when I do eventually get a PC I think it will be impractical
to run the two systems together, I just don't have the room so if
anyone is interested in taking over the editors role, please let me
know. In fact I would like to have some feedback from ALL members on
how they see the future of ICTARI. Naturally I will be reluctant to
give up the Atari and ICTARI as I have learnt a lot from members
contributions over the past two years but we do have to live in the
real world (which, as we all know, is now run by Bill Gates). PDH /*
------------------------------ End of file ---------------------------
