Copy Link
Add to Bookmark
Report
Ictari Issue 27
ICTARI USER GROUP ISSUE 27 October 1995
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* 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 27
==================
ASSEMBLY Routine to double screen height.
C Tim Oren GEM Tutorial. Part 16. Interface Potpourri.
Variable length edit fields.
BASIC LOGO/Turtle emulator code.
GFA Directory Tree displayer.
STOS PUTKEY command info.
Sort routines.
MISC Mrten Lindstrm, GEM Guide. Part 3.
Portable Network Graphics (PNG) specifications.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Using the BitBlt VDI calls.
Pop-up menu routines.
C Tim Oren GEM Tutorial. Part 17. PC/ST Resource conv.
Sub-menu source code library.
Basic Database program.
GFA Low Rez formatting program.
STOS Syntax Helper accessory.
MISC MODEM programming guide.
Mrten Lindstrm, GEM Guide. Part 4.
Mark Baker, Using SpeedoGDOS. Part 1.
----------------------------------------------------------------------
EDITORIAL
=========
PORTABLE NETWORK GRAPHICS
-------------------------
A couple of months ago Mrten Lindstrm mentioned the Portable Network
Graphics (PNG) picture standard. In this months issue we have
published the complete specification together with some C code. There
are also a few image files with which to test the code. We also have
another 120 or so images although what the images are is unknown since
we don't have a program which can display them. Perhaps someone would
like to write a program to display the images, also some machine code
routines to decode and encode the PNG file format would be very
useful. If anyone would like the extra PNG image files for testing
purposes please send a disk and some postage and we will return them.
EINSTEIN USER GROUP
-------------------
We have had a letter from the above group asking for publicity in our
magazine in exchange for publicity in theirs. I know it's a bit
unlikely but if any member knows of anyone with or has an interest in
an EINSTEIN computer perhaps they would contact Mr A Adams at Ivy
Cottage, Church Road, New Romsey, Kent, TN28 8TY.
ARTICLES
--------
As usual we are still very short of new articles for future issues. If
you can provide something, please send it in.
----------------------------------------------------------------------
CORRESPONDENCE
--------------
To: *.*
From: Jim Taylor
Does anyone know how to create a virtual screen in memory a different
size and shape to the actual physical screen and have all of the
graphical GDP's draw to it and obey the usual clipping rules etc.
I need to be able to create a virtual screen the same size in bits as
an A4 sheet at 300 dpi. This works out at approximately 2400 bits (300
bytes) wide by 3300 scan lines high; roughly 1 megabyte.
At present I am displaying my CAD graphic in blocks to the screen and
reconstructing them in a reserved area of memory and subsequently
sending this data to my HP Deskjet 520. This works OK but is mind
numbingly slow as, on big drawings, the vector graphics (and as we all
know are notoriously slow to refresh) has to be redrawn as many as 36
times. In this way some of my drawings, at this resolution, are taking
well over half an hour to print out.
Another problem I have encountered is that although I am sending the
graphics data to the printer at a continuous rate, the printer waits
about 10 seconds between passes when printing. This creates yet
another inordinate delay.
I reckon that if I can solve these problems I can reduce my printing
time from about 40 minutes to about 3 or 4.
Finally, I'd like to be able to produce those cute little menus that
pop out of other menu items. I need also to be able to determine which
of the little pop-out items has been selected. Some code or other info
relevant to HiSoft's Lattice C++ and WERCS would be greatly
appreciated. However, any insight would be welcome.
*/ Regarding your CAD drawing program I think the answer is to convert
it to use SpeedoGDOS. I suspect that it would be a fairly big job but
a CAD program is a 'serious' type program and would be ideally suited
for using GDOS as you would not then need to generate a bit image and
pass it to the printer as GDOS would do this for you. You would also
get access to lots of vector fonts and the program would also work on
any printer that the end user has. You could even use colour drawing
perhaps. The next problem is - how to use SpeedoGDOS in your program.
Starting next month we are publishing a couple of articles by Mark
Baker on how to use SpeedoGDOS which should help. If anyone has any
specific questions on using SpeedoGDOS, please send them in straight
away so that Mark can make sure the points are covered in the
articles.
Regarding the sub-menu and pop-up menus, next month we will publish
some C code which describes how to do this. I have also written a
machine code routine to display a 'pop up' menu system which will also
be in next months issue. However, I have not yet worked out how to
implement sub-menus, maybe I will by next month. ICTARI /*
----------------------------------------------------------------------
To: Anyone
From: Owen Rogers
Does anyone know where I can get the STOS Basic Manual as I have lost
my own. If someone knows could they please tell me where I can get it
through ICTARI ?
----------------------------------------------------------------------
To: All
From: David Preston
Since I've only just joined, I'll keep the shopping list short (just
three questions for now...).
I'm using Power Basic and K-Resource, can anyone help with defining
and using sliders in dialogs? The sort of thing I mean is often used
in file selectors etc. I've studied various resource files and they
seem to use different methods. I suspect I would understand better if
I knew the distinction between EXIT and TOUCHEXIT attributes but I may
be barking up the wrong tree altogether...
The idea (Adrian Lovatt's) of a Hisoft Basic toolkit is a good one,
but how about a GEM version as well? The reason I ask is that Power
Basic is compatible with Hisoft Basic (or vice versa), which begs
another question - does anyone have any information on the extent of
this compatibility?
And finally, I seem to recall from an article in New Atari User ages
ago that there is a way of calling SPEAKTEX.TOS from within STOS
programs. Does anyone have any information?
Any help on any of the above would be most welcome.
*/ The main difference between the EXIT and TOUCHEXIT objects is that
the EXIT object takes effect when the mouse button is clicked and then
released while the TOUCHEXIT object takes effect immediately the mouse
button is pressed. The main reason for this is so that when a
TOUCHEXIT object is selected, the program can execute some code while
the user still has the button pressed, e.g. scrolling a window like
that in a file selector or whatever. Various tutorials in previous
issues have covered the use of GEM, etc. I think that to implement
sliders in dialog boxes, however, you will have to design your own
dialog handling code which is a bit trickier. If anyone has
information on this, please let us know.
In ICTARI issue 11 we published a STOS program by Martin Cubitt which
generated speech (although I don't think it used the SPEAKTEX.TOS
program). In ICTARI issue 24 we published a GFA program called Naval
Battle which uses the STSPEECH.TOS program which I would guess is
similar to the SPEAKTEX.TOS program. In ICTARI issue 25 we also
published some C and GFA code using the SPEAKER.PRG program which,
again, is probably the same speech synthesis program. If Martin or
anyone else can help with this particular version of the program,
please let us know. ICTARI /*
----------------------------------------------------------------------
To: ICTARI
From: Robert Manning
Subject: HiSoft BASIC / Lattice C
I am using the above two programming languages and would like to be
able to use menus within windows and also other more modern features
(eg. Scrollable list boxes, real radio buttons, check boxes etc.).
Does anybody have any routines or ideas that I could incorporate,
ideally source code but a library file would be equally appreciated.
I have a form of menu within a window by using the new popup feature
of the HiSoft BASIC but this seems a bit messy.
*/ I'm not entirely sure what you mean by 'real' radio buttons or
'check boxes' but the sub-menu and pop-up menu code next month may
help. If it doesn't, let us know again. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Steven Ward
How can a file be intercepted between an application and the disk
drive? Is there a way to interrupt an application before disk access,
and obtain the source/destination address of the data to be
loaded/saved, along with its length?
I want to write a desk accessory which can alter a file before it is
imported into an application from the disk drive, or exported from an
application to the disk drive, whilst also remaining totally
transparent to that application.
*/ I suppose it would be possible to intercept the 'read file' and
'write file' vectors (TRAP #1 $3F and $40) and then alter the data in
memory either before it is written to the disk or after it has been
read from the disk. Both BIOS calls pass the address of the memory
buffer and file size to the system which could be accessed. I think it
could still be a bit dodgy, however, since you would need to know you
were using the correct files (especially on a Multi tasking system)
perhaps by checking the file handle value. If anyone can provide any
more detailed information, please let us know. ICTARI /*
----------------------------------------------------------------------
To: Tony Harris
From: Mark Baker
"I managed to get myself a printer recently - a Panasonic KX-P1170 9
pin. I have the little problem that it won't print the # instead it
prints , this is annoying when I print up listings."
Because the standard 7-bit ASCII character set doesn't include, for
example, a pound sign, nor does it have room for one to be added,
nationalised versions of the character set were invented. In the case
of the British version, there is a pound sign instead of a hash.
However, the Atari, like every other computer around, doesn't use the
standard British character set, it uses an 8-bit character set where
the first half is US ASCII, and the second half contains other
characters including the pound sign.
Your problem is that your printer is set to British. If you set it to
US it will correctly print the hash. Better still, use the IBM
character set - most printers allow you to do this. The IBM character
set is not identical to that used by the Atari, but it is fairly
similar.
"On some dialog boxes I have come across there has been an
underscore to highlight a keyboard shortcut, alas I am unable to
discover how to achieve this underline - is it an undocumented feature
?"
No, you can't do it. The programs you have seen doing it are drawing
the buttons themselves using progdef objects. (Actually, most will be
using a library to do it for them). Basically you write a routine that
when passed information about the size, state, etc of a button will
draw it complete with underline. Then you have to search your object
tree for all buttons and change them to progdefs so it runs your
rendering routine.
*/ Has anyone actually written some code using the Progdef function,
if so we would be very interested to see it. ICTARI /*
To: Terry King
From: Mark Baker
A couple of issues back I replied to a letter from you, where I said
that all STE sound would work on the Falcon, and I couldn't explain
why you had observed some games to be silent on the Falcon.
I recently saw the answer in the Atari Compendium. Although the Falcon
has the same registers as the STE and is designed to be compatible, it
does not support the 6.25 kHz sample rate (which is the lowest the STE
will do). Since the sound is DMA there is hardly any performance hit
from using a higher sample rate anyway, so if you want to make sure
your programs work on the Falcon, just avoid this rate.
----------------------------------------------------------------------
To: Steve Gale
From: Richard Evans
"Does anyone know of any 'legal' way to stop 'overshoot' when
scrolling through a document, i.e. stopping the scrolling sequence
immediately when the up or down arrow key is released. Presumably
this is caused by the keyboard buffer storing keypresses even after
the key has been released."
There is a simple way of preventing this overshoot problem - you need
to turn off the keyboard repeat after you detect a keypress, and back
on just before you test for the next keypress. This stops endless
keypresses being stored in the keyboard buffer. Whilst it may be
technically bad to alter global system variables (in this case
'conterm'), it causes no known problems, and is used in a number of
commercial releases.
The keyboard repeat is turned off by clearing bit 2 of 'conterm' (char
at memory location 0x484). You must enter supervisor mode before
changing this variable, using Super or Supexec.
The following fragment was written in Lattice C5.6:
static char conterm; /* Stores conterm value */
/*********************************************************************
Function saves current conterm setting and sets it to stop key repeat
*********************************************************************/
long repeat_off_conterm(void)
{
conterm = *(char *)0x484; /* Save previous setting */
*(char *)0x484 &= 0xfd; /* 0xfd == 11111101 in binary */
return(0L); /* Supexec expects a long returned */
}
/***********************************************
** Function restores previous conterm setting **
***********************************************/
long reset_conterm(void)
{
*(char *)0x484 = conterm; /* Restore previous setting */
return(0L); /* Supexec expects a long returned */
}
To call these functions from your program, use Super or Supexec e.g.:
#include <osbind.h>
Supexec(repeat_off_conterm); /* Key repeat off */
Supexec(reset_conterm); /* Key repeat on */
---------------
To: *.*
From: Richard Evans
Supexec problem with MagiC and Lattice C
There appears to be a small problem with the MagiC Supexec
implementation (on V2.01 at least). If programs are compiled on
Lattice C with stack checking enabled, the program will always fail at
a Supexec call with a stack exhausted message. The solutions are
simple - compile with the stack checking option off, or use the Super
function instead as this does not seem to cause any problem. I can
remember seeing a patch in the public domain which claimed to correct
this problem with MagiC - if anyone has this program, could they send
it to me. Naturally I will pay all postage and disc costs.
To: *.*
I think that we are correct in supporting GDOS instead of a new system
such as the previously proposed UPD. There are far too many existing
programs using GDOS, and I don't believe it would be worth the time
and effort in getting a new system up and running efficiently. I have
noticed that most people seem to be talking about supporting Speedo
GDOS. I would suggest placing emphasis on NVDI instead, as it is a
much more efficient replacement. NVDI 3 also allows the user to write
their own printer drivers in most cases. 2B released a German NVDI 3
users manual into the public domain a while ago, with the promise that
an English version would be following; I'm not sure if it has been
released, but how about Ictari contacting 2B officially to get
information about NVDI 3 and/or GDOS - it must be worth a try. It
would also be nice if there was a postscript driver for GDOS/NVDI;
whilst Timeworks has one, I don't think it is a universal driver.
Presumably it is possible, and would someone consider looking at the
Timeworks driver to see what is happening?
*/ Any offers ? ICTARI /*
----------------------------------------------------------------------
To: ICTARI
From: Stephen Bruce
Okay, so I received my first issue (#26) of ICTARI, here are a couple
of my initial thoughts.
1) The programs appear to be well commented, however there are no
headers or text files included telling members what any given program
does or why it was written. For example I personally found the 3D line
routines interesting, but I don't know why they were written or what
they are for (are they a one off exercise or part of a larger
project). This would be helpful to all members and may even provoke
more comments or criticisms for the letters page. If it were my own
work under scrutiny, I would prefer friendly criticism from the group
rather than unsavoury press reviews and this feedback could help user
friendliness in our progs.
2) I enjoy tinkering with my programs, but my main problem is lack of
direction. There are just so many possibilities I never know what to
do and rarely see my projects through to the end (unfortunately I
wiped most of my cast offs, so I'm starting from scratch pretty much
with my contributions). How about suggesting projects or routines to
be written in a variety of languages and publishing the best on the
disk. This could/would tie in with existing projects such as Adrian
Lovatt's HiSoft Basic 2 toolkit. It would also mean the groups users
might benefit from programs/utilities tailored to their needs. One
example I've never got around to but am curious about is a GEM based
sample editor that would let me 'draw' sections of the waveform when
it has topped out due to too high a volume when sampled. I would have
done this myself but I'm not too comfortable with GEM programming
(yet). I don't know if this is a good example in 'usefulness' terms,
but I would like to know the results of sample editing in this
fashion.
Well, that's all I've got time for this month (I left it 'til the last
minute to write this), but if I think of anything else or produce
anything usable I'll send it in.
P.S. I'm glad it's not all fonts and DTP being discussed, it's good to
see you have some 'showy' progs on this and previous disks (3D
routines/tracker players/border busting etc....). This is definitely
where my personal interests lie. To quote Des Lynham, "How do they do
that..."
*/ We quite agree that source code contributions should be accompanied
by a text file which describes what the code does, how to use it, etc.
Unfortunately, however, programmers do not always seem to have the
time (or inclination !) to do this but it would help everyone else if
they would. One should also bear in mind that some of the articles are
taken from the Public Domain rather than ICTARI members and so we have
even less control over them.
We have tried in the past to implement a 'joint project' idea but with
not much response. I think the problem here is that most members who
are actively programming have their own projects and do not have time
to start another one for someone else. However, if there are any
programmers out there who are looking for something to write, please
let us know what sort of programs you are interested in and in what
language and we will try and find a useful project for you. ICTARI /*
----------------------------------------------------------------------
To: Tony Harris
From: Mrten Lindstrm
PRINTER CHARACTERS
------------------
I don't know about the KXP1170, but I had a KXP1081 a few years ago,
and as I recall this had DIP switches somewhere, one of which could
select a national character set. You should use the USA character set,
which is the true ASCII set. The British (or Swedish) character set
deviates from this, and is a remnant from the time when all characters
had to be crammed within a mere 7-bit character set. On the Atari the
British pound sign - and Swedish letters - are found in the second
half of the 8-bit character set, and for them to be printed correctly
the IBM set, rather than Epson, must be selected - for which there
should be a further DIP switch.
(If you can't find any DIP switches there must, of course, be some
other method to select default settings; my NEC P2200 uses a
questions-and-answers method, which is triggered by pressing a
"Select" button at power-on).
Again, if you can get the program used for printing to send an initial
sequence of control codes before printing starts, you have no problem:
ESC,"R",0 (= 27,82,0) selects ASCII (USA characters 0-127)
ESC,"t",1 (= 27,116,1) selects IBM set (for characters 128-255)
ESC,"6" (= 27,54) makes sure IBM characters at all printable
(These codes should work on any reasonably modern dot-matrix printer.)
DIALOG BOXES WITH UNDERLINED TEXT AND OTHER WEIRD OBJECTS
---------------------------------------------------------
Underlined text - or round buttons or buttons crossed instead of
inverted when selected or any other type of object you might dream up
- are not included in the standard arsenal of object types, but they
can be implemented as "program-defined" objects. (Object type = 24.)
The "object specification" (the pointer at offset 12 in the object
structure) of such an object is a pointer to an APPLBLK (also called
USERBLK) structure:
APPLBLK (8 bytes):
L: Pointer to routine for drawing the object.
( L: Data to be passed to this routine. Optional. )
Note: This may be difficult to implement in languages other than C or
assembler, since most other languages don't allow use of pointers to
routines. The only general solution for these may be to somehow
include an assembler routine - or C compiled module - for the task.
For the special purpose of creating LINES there is however one other
solution - see the final note in this message.
The given routine will be called by the AES each time the object needs
to be redrawn. Only VDI calls - and no AES calls - can be used for the
drawing (use a VDI handle for your own virtual workstation even though
the routine is called from the AES rather than from your own program).
Care must also be taken to neither make any extensive use of the stack
(avoid nested subroutine calls for instance) nor to destroy register
contents. Though I think registers D0-D2 and A0-A2 plus 6 or so
longwords on the stack are OK to use.
The routine will be given a pointer on the stack (assembler
programmers read long at 4(SP)). This points to a PARMBLK structure,
set up by the AES:
L: Pointer to tree
W: Object number within tree
W: Previous state (as object is shown on screen at time of entry)
if Previous = Current state, then nothing is on screen at entry
W: Current state (to be drawn by routine or left for the AES to do)
W: X of object
W: Y -"-
W: Width -"-
W: Height -"-
W: X of clip rectangle to be set by routine
W: Y - " -
W: Width - " -
W: Height - " -
L: The program-defined data from the APPLBLK
--------
15 words (30 bytes)
The routine can use the data in this block to first set a clip
rectangle and then draw the object. I think the "Previous state" can
be essentially forgotten though. Although it could in theory be
compared to the Current state, to possibly let the routine merely
update the state of an already drawn object, I think in practice the
routine must always draw the object from scratch.
The routine should return (in D0.W) the Current state (from offset 8
in the PARMBLK) to inform the AES of the states to add to the drawing,
possibly with some state bits cleared corresponding to states that the
routine has taken care of itself. (It seems that the shadowed state as
well as the selected state for a selectable object must always be
drawn by the custom routine.)
=== HOW TO DO IT ===
No "program-defined" objects are offered by a resource construction
set, so you'll have to use the standard types of objects when making
up the layout of the dialog box. You should however be given the
choice to mark some objects as "special", through use of the
"extended" object type.
The extended type is the upper byte of the type ID word (at offset 6
in object structure). It is normally set to zero but is not used by
the system in any way (except in menu items with sub-menu attachments
of newer AES versions), so you are free to use it as a code that only
your program will read and care about.
(Apart from when MENU_ATTACH is used on a menu item, the extended type
byte should be guaranteed to always remain safe from system use. Atari
did try to use it for 3D effects, when introducing these in the AES,
but were confronted with such forceful protests from GEM programmers,
that they had to rethink and move the 3D info to were it is now - bits
9 & 10 in ob_flags.)
Regarding the special case that you mention - underscoring a single
character in a text string - I would suggest the underscore to be
implemented through a separate object, placed on the character to be
underscored. This could during the layout RCS work be represented by a
1-character invisible box (object type 27) with a visible border
(thickness 1 pixel inwards), but given an extended type of non-zero.
In your program code you must then include a routine (after loading
the resource) that prepares the dialog, or entire resource, by
checking each and every object for an extended type, and making the
corresponding change to marked objects - replacing the object type ID
with 24 and the object specification with a pointer to a suitable
APPLBLK. The first long of the APPLBLK should point to a routine that,
after setting the clipping rectangle, simply draws a line with V_PLINE
at the bottom of the specified object area.
=== FINAL NOTE ===
Marking objects with non-zero codes in the upper type byte - the
extended type - can be used for other purposes than changing the
object type into 24, G_PROGDEF (G_USERDEF).
For instance, a line could alternatively be implemented as a standard
box object (type 20) with solid fill, no border and a height of only 1
pixel. The convenient way to get this box in place would still, I
think, be to use an invisible character-size box during layout work,
as described above. But - during program execution - instead of
changing it into a G_PROGDEF it could be changed into an ordinary
G_BOX, while moving it to the bottom of its old area and reducing its
height to 1 pixel and its border to zero. (Make sure the fill is
solid.)
Another easily implemented one-shot run-time modification would be the
centring (or right-aligning etc.) of an object within its parent. You
might even want to reserve one of the bits in the extended type as a
bitflag for this purpose.
Or you might want to mark objects not for the purpose of changing them
at all, but as a convenience, for instance to facilitate general
recognition of OK buttons, Cancel buttons etc. without knowing their
precise object numbers in each and every dialog box.
For a full description of the structures of objects and resources see
Ictari 21.
----------------------------------------------------------------------
To: *.*
From: Peter Hibbs
I am writing a program which requires some sound effects like those
found in the Dungeon Master game. Does anyone know how the sounds are
stored in DM or where I can find some that are very similar. I have
got most of the sound effects disks from various PD libraries but
there is nothing suitable on them.
------------------------------ End of file ---------------------------
