Copy Link
Add to Bookmark
Report
Ictari Issue 32
ICTARI USER GROUP ISSUE 32 March 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 32
==================
ASSEMBLY Non-modal dialog box code.
Relative mouse handling routine.
C Dictionary game source code.
GFA Directory catalogue program.
STOS Starfield screen code.
Disk manager program.
MISC Ottos Resource Construction Set (ORCS) program.
ORCS review.
Card shuffling techniques.
Current membership list.
Index for issues 1-32.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Assembly Language Tutorial. Part 1.
C Window icon interface system.
File viewer program.
GFA Text adventure game.
STOS Using a large font in STOS.
Pie chart generator.
MISC Character Set Information.
SCSI FAQ file.
Programming pros and cons discussion.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
Another two members have joined the group this month, welcome to them.
SHUFFLING TECHNIQUES
--------------------
In the MISC folder is an interesting article by David Preston about a
card shuffling algorithm, however, there is example code in Basic, GFA
and STOS which would be of interest to programmers in any language.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: All
From: Derek Warren
I use the Kuma K-spread 2 spreadsheet program but, having no
instruction manual for it, suspect that I don't make full use of its
capabilities. I would be pleased to know of anyone who has a manual
which I could purchase or, if not purchase, perhaps borrow for a
short time?
----------------------------------------------------------------------
To: Qwen Rogers
From: Thomas Nilsen
The reason your GFA-GEM program will not let you enter any text in the
editable fields is simple. The Form_Do expects its parameters in the
following structure: Form_Do(tree%,first_editable_object&). So to get
your program to work correctly all you have to do is change the
Form_Do(tree%,0) to Form_Do(tree%,cmdline%). That would allow you to
use the editable fields the way you want. If you have more than one
editable field in the form, still use the first editable field in the
Form_Do() command, as GEM itself will handle the following editable
fields.
A little tip at the end. Before you do the Objc_Draw() make sure the
editable fields are cleared of the Masks you set up when creating the
RSC file. To clear an editable field, use...
CHAR{{OB_SPEC(tree%,cmdline%)}}=""
This will clear the editable filed named cmdline% and when you do the
Objc_Draw() the cursor will be displayed at the start of the field.
To: Jason Railton
Reading the mouse
-----------------
I do not know if this is exactly what you want but I have written a
small mouse-routine myself that I use in various environments.
I'll include the full routine and if Peter can find room for it he
will perhaps include it in the assembly folder... Peter?
*/ See the ASSEMBLY\RELMOUSE\ folder. /*
----------------------------------------------------------------------
To: ICTARI & Mrten Lindstrm
From: Jim Taylor
Many thanks for the advice on how to use GDOS in conjunction with my
drafting program MultiCAD. This sounds like an interesting way of
solving the problem.
In the meantime, for other reasons, I still need to know how to solve
the problem in the way I initially described. Which was to send VDI
vector graphics to a bitmap image in memory, bigger than the screen. I
wish to implement this solution first before I resort to using GDOS.
Does anyone know if this is actually possible? If so I would be most
grateful if anyone can shed any light on the subject. I know how to
reserve a block of memory with malloc and obtain its start address but
how do you get the VDI to send the graphics to it and how do you
specify its shape eg. 800 x 2000 pixels. v_opnvwk would seem to be
the prime contender but it does not have size, shape, or start address
parameters for the memory area.
If I crack this one I promise that I will also have a go at
implementing GDOS and write an article on how I got on with it.
To: C Singleton
The following will send a form feed to the printer.
lprintf("\f"); fflush(stdprt);
^
ie. '------------->\\ backslash
\' single quote
\" double quote
\? question mark
\a audible bell
\b backspace
\f formfeed
\n newline
\0 NULL character
\r carriage return
\t horizontal tab
\v vertical tab
\xhhh ASCII code hhh
Also consider the following which will cause the printer to do a cr/lf
and reset.
unsigned char prinit[]={13,10,27,69};
^ ^ ^ ^
| | | '-code to reset the printer
| | '-Esc. tells printer code is to follow
| '----line feed code
'-------carriage return code
Fwrite(3,4,&prinit);
^ ^ ^
| | '------address of data
| '-----------number of characters to send
'-------------output device (printer).
----------------------------------------------------------------------
To: Peter Hibbs
From: John Cove
If I recall you could not get the 68000 "game" to work. Well, you
will notice that the code loads up a data file, before it runs. The
loader will NOT work from a hard disk, so you must run it from the
disk. So, look for the fname line on line 770, reading;
fname dc.b 'saucers.dat',0
change it to:-
fname dc.b 'a:\assembly\saucers\saucers.dat',0,0,0
...and you will find it works fine!
*/ As you say, it works fine, quite what it is supposed to do I
haven't worked out yet. Anyway I think there is a lesson here for all
programmers, make sure your code will work from any folder/drive for
maximum user friendliness. PDH /*
----------------------------------------------------------------------
To: Anyone
From: Owen Rogers
Thanks to some of the members for helping me out with the editable
strings!. I'm making a drop down menu program in GFA Basic 3 where
you click on the menu entries and dialog boxes pop up. When you click
on the Exit button you are returned to the menu again to select some
thing else. The problem is that when you select the same dialog twice
in the program the button on the dialog box is already selected and
you have to deselect and then select the button again to exit. Please
can anyone help me because I am hoping to release it into the public
domain and it looks really terrible with this problem. I use the ORCS
resource editor.
*/ This is a fairly straightforward problem, the routine needs to
remember the object number of the button that was used to exit the
dialog and then just before you exit the dialog routine, use the
number to locate the object data and clear bit 0 in the 'object
states' field (offset 11). This subject was covered in the GEM Guide
Part 4 article by Mrten Lindstrm (Ictari 28) but if anyone has any
further information about this in GFA Basic, please send it in.
ICTARI /*
----------------------------------------------------------------------
To: *.*
From: John Levon
If you have Web access, you can examine the ICTARI Web page at :-
http://www.cs.man.ac.uk/~levonj5/movement/ictainde.htm
To: ICTARI
Could you possibly from now on rename all ICTARI.TXT files as
ICTARIXX.TXT where XX is the issue number? As I save all my
ICTARI.TXTs this would make storing them a mite easier.
*/ Thanks for the Web page. I can't see any problem with adding the
issue number to the filename, I'll just have to worry about issue 100
(November 2001) if we are still going then. ICTARI /*
----------------------------------------------------------------------
To: All
From: Tony Harris
1) I am writing a program that extensively uses rasters, however I
need to use the mouse but the rasters become very unstable when the
mouse is moved, I understand (through this column) that I would need
to make the mouse interrupt a lower priority than the TimerB
interrupt, but how?
2) Just out of interest, when were Blitter Chips put into ST's as
standard?
*/ We have published some code using rasters in issues 4, 5, 13 and 20
which may be of help. If anyone has any more info, please let us know.
I believe the blitter was first included in the STe machine as
standard. ICTARI /*
----------------------------------------------------------------------
To: David Preston
From: Jason Railton
Re: SeaPest.PRG
Not being able to run the compiled .PRG sounds to me like a STOS/TOS
incompatibility problem. The symptom you described (no mouse
response) is the sort of thing STOSFIX is able to rectify. Do you
have a copy? If you do, could you try it on my .PRG?
If you don't have TOS 2.06, but an earlier version, it should have
worked. As far as I know, I have the latest versions of STOS (2.6)
and the compiler (2.5). Can anyone else help?
To: C. Singleton
Re: Form feeds to a printer in C.
Have you tried simply printing the ascii character CHR$(12), or
whatever the C equivalent is, on the printer?
To: Peter Hibbs
Re: GEM and AUTO programs.
You're right in thinking that you can't use GEM and VDI calls in an
AUTO folder program, because it will execute before GEM is installed.
However, you can use all the TOS calls (BIOS, XBIOS, even GEMDOS) so
you can alter memory allocation and access the disk from an AUTO
program.
If you really need the GEM and VDI in your TSR's startup sequence,
there is a way round the problem, but it's only a dodgy theory at the
moment...
1. Write a TSR routine that installs itself in the GEMDOS trap (#1).
2. This routine should check to see if GEM is up and running (look in
COMPUTE!'s for a suitable system variable, or check the GEM trap
vectors for initialisation, or something). GEM is bound to use GEMDOS
at some point even without user input, if only to check the keyboard
buffer.
3. Once it spots GEM is installed, a second installer routine is
called that can restore the GEMDOS trap, and establish your main TSR
program. This can either be run from disk by the first TSR, or could
have been part of the original AUTO program. You can then use GEM in
the setup and installation of your main TSR.
----------------------------------------------------------------------
To: Jason Railton
From: Stephen Bruce
I couldn't get the mouse to work on the STOS Polygon demo on issue 31.
Is this a compatibility problem with STOS and STe's or a bugged copy
of the program.
*/ On my STFM (TOS 1.04) I just get a black screen and nothing else
happens ! PDH /*
----------------------------------------------------------------------
To: *.*
From: Mrten Lindstrm
Thanks to all of you who have responded to what I have written about
GEM programming. It is very rewarding to hear that someone is reading
what one writes, and completely wonderful when it is appreciated too.
I must point out, however, that I have little or no actual experience
of programming for MiNT, MultiTOS, MagiC or Geneva, my own ST being a
bit small (1 Mb) for them. So any experiences - by members who have
run, and programmed for, these - would be highly valuable.
One small thing that I became aware of, only after writing that
global[1]=1 for "singleTOS" and =-1 for MultiTOS, is that it might
also =16 for MagiC. The reason for this would be that global[1] was
documented as the maximum number of concurrently running applications
(not counting accessories), which is infinite for MultiTOS and Geneva
but apparently limited to 16 for MagiC. Could someone with MagiC
confirm this?
In any case, when looking for MultiTOS capabilities, you should
probably look for ANY (non-zero) value not equal to 1.
To: *.*
From: Mrten Lindstrm
ATARI WORLD
-----------
I have so far not seen a copy of the new Atari World magazine where I
live. But from all the talk about it, it seems to be good (while the
value of ST Applications was of course greatly reduced on the leaving
of Jon Ellis).
Could someone tell me what the subscription price is, for us EUROPEANS
OUTSIDE THE UK. And perhaps give me an address to which to write,
should I afford it.
To: *.*
From: Mrten Lindstrm
PAGE DESCRIPTION LANGUAGES AND WORD PROCESSOR FILE FORMATS
----------------------------------------------------------
I have now got the complete specification from Microsoft for RTF -
Rich Text Format (v1.3). Apparently it is freely distributable, but
unfortunately not in ASCII format - making use of various fonts and
styles - so I am now converting it to ASCII (and also tidying up the
slightly corrupted layout of some tables).
I intend to send it in next month together with some related material
(I hope Ictari will find room for it all, but then there is the
possibility to compress it).
Does anyone have specifications for other text formats/page
description languages - HTML, SGML, Post Script etc. - and if so,
could you please send them in to Ictari?
(At least HTML specifications should be available somewhere on
Internet, shouldn't they?)
As for simple word processor formats, If anyone is interested in how
Protext files are constructed, I could say something about that too.
(Though I have only got v5.51 and don't know how v6 does with pictures
for instance.) Anyone else who knows (or wants to know) about this or
other word processor - or DTP - formats?
To: *.*
From: Mrten Lindstrm
UNICODE - THE ASCII OF TOMORROW
-------------------------------
The topic of character sets has been covered before in Ictari, but
recently, when paging through some (PC) magazines, I found some
information that was previously completely unknown to me.
We have all become used to ASCII (American Standard Code for
Information Interchange) being the standard for character encoding
(the only pre-ASCII set that could possibly still be encountered is, I
think, something called EBCDIC - Extended Binary Coded Decimal
Interchange Code - of old IBM mainframes).
ASCII lets each character be represented by a BYTE, of which however
the uppermost bit is unused in pure ASCII, limiting the range of
possible codes to 0 through 127. Since, in addition, characters 0-31
and 127 are reserved for use as control codes (or application specific
purposes) there are only 95 actual ASCII CHARACTERS, 32-126.
This excludes all modified ("non-English") Latin letters of, for
instance, Swedish, and also the British pound sign (though the
American dollar sign IS an ASCII character).
The reason the uppermost bit was kept clear, was for it to be used as
a parity bit during serial transmission. In the days when all
computers were mainframes, communicating with stupid terminals, (and
also before today's transmission protocols), this was absolutely
essential, but today is not nearly as often needed. So all present
personal computers do make use of all bits of each byte, giving a
further 128 possible characters (128-255).
Unfortunately, when this second half of the 8-bit set was filled with
characters, there was not much coordination or planning, resulting in
a number of DIFFERENT 8-bit character sets, mapping one and the same
character to different code numbers.
Also, there are so many characters and symbols, you might want to
implement, that even these extra 128 characters may not be enough
anyway. Thus, special character sets with only symbols have been
defined - e.g. Dingbats - and, above all, a limitless number of
character set variations to support non-Western languages.
Not only does this create a lot of confusion when porting text between
different computers or countries, but when you come to East Asia
(China/Japan/Korea) - with thousands of characters - adherence to
ASCII can only be maintained if some characters (including the true
ASCII ones) are one-byte, while others are implemented as two-byte
characters, complicating programming (and also slowing down
performance).
Enter Unicode! This new standard, backed by all the leading computer
companies and since 1993 by ISO, simply lets each character be encoded
in a WORD (16 bits), instead of a byte. And all of a sudden we have
65536 characters - more than enough for all living languages of the
world, and few dead ones too; plus a vast number of mathematical and
other symbols. And, best of all, it will be as easy to program for
Unicode as for ASCII. In C you may even be able to write source that
can be used for either, if merely the variable type "char" (=a byte)
is replace with a 16-bit type (for some reason called "wchar_t"). All
the old conventions and techniques can then be applied to Unicode -
such as terminating character strings with a NULL (though a null WORD
rather than a null BYTE).
WHAT A WASTE - you may think - to allow text to gobble up twice the
memory and disk space it needs as ASCII. But the reasoning behind
Unicode is, of course, that in the age of "Multimedia" it is not text,
but images and sound that are gobbling up most of what space there is,
and Unicode won't change that much. (Also: if COMPRESSING text data,
they should end up the same size, whether originally 8-bit or 16-bit
encoded, if otherwise identical).
Don't doubt that Unicode WILL be THE standard for character encoding
in the future. Again, in the choice between simple Unicode and
multiple 8-bit sets (and convoluted variable-width encoding of East
Asian languages) the leading computer companies have clearly decided
the future to be Unicode. On PCs, Windows NT - the heavy-weight
version of Windows - (though not Windows 95) already uses Unicode for
most of its internal text handling.
One problem with WORD encoding is the different way in which Intel and
Motorola processors store words, requiring the bytes of each word to
be swapped if imported from a "foreign" processor. Unicode solves this
with a special BOM (Byte Order Mark) character $FEFF, normally stored
as the very first word of a "plain Unicode text" file. Now, should a
reader encounter the byte-swapped form, $FFFE, this should be taken to
signal a foreign processor format, since $FFFE itself is NO CHARACTER
under Unicode and shouldn't occur in Unicode text.
So, how does this concern us who program for Atari? As far as I know,
there is no Unicode support yet offered by any TOS extension, but it
must be only a matter of time before SpeedoGDOS and NVDI start
supporting it. The GDOS/VDI functions of these for OUTLINE fonts,
already support 16 bit character encoding, though unfortunately so far
using only the completely non-standard, font-dependent, internal
character INDEXES of each font. Microsoft has, however, recently
published specifications for a new pan-European True Type font, WGL4,
with 652 characters, referred to by Unicode numbers, and Atari/Compo-
/2B simply have got to make use of that.
In the meantime, if you are writing a word processor or similar, it
may be a good idea to at least try to write the code to be as easily
convertible to 16-bit characters as possible, to prepare yourself for
the future. If you are willing to convert between Unicode and Speedo
indexes, or even do the character rendering yourself, you might even
start programming for Unicode now.
+++<>+++
Also see the file CHARSETS with lists of all the common 8-bit sets,
better than the ones I have previously sent, plus some Unicode and
Speedo material. And if anyone knows more, please share!
To: *.*
From: Mrten Lindstrm
AES CALLS UNDER SUPERVISOR MODE
-------------------------------
According to Laurenz Práner in the German "ST Magazin" 5/91, AES
calls are officially allowed also in supervisor mode provided that a
number of precautions are taken:
1) A number of AES functions (undocumented which ones) return in
USER MODE. So the program must, after each AES call, check the
processor mode (with SUPER(-1)) and if necessary restore
supervisor mode.
2) A special supervisor stack, separate from the user stack, must
be used. (Thus you cannot, according to common practice, make
your user stack pointer into a supervisor stack pointer). This
is because the AES has the peculiar habit of saving data on
the user stack regardless of the processor mode, and when the
USP points in about the same memory area as the SSP, data may
be overwritten.
3) At the very least 12 free bytes must be available ABOVE
(AFTER) the super stack pointer, since the AES has the
peculiar habit of writing after the stack.
To: *.*
From: Mrten Lindstrm
TSR programs
============
Using GEM functions from within a TSR program is not trivial I think.
The problems would be:
1) AES calls in supervisor mode (under which a TSR program
normally is working) need special precautions, see above.
2) In whose name is the TSR program to make its call?
During the installation (taking place when the TSR program is
executed from the AUTO folder), a TSR program cannot register
itself as a GEM application with APPL_INIT, nor make any other
GEM calls, since all this happens before the GEM is
initialized.
And after terminating the installation, with PTERMRES, the TSR
program doesn't even exist as a GEMDOS process any more (it is
merely a "dead" block of memory, containing some sub-routines
for the system, to which some system vectors happen to be
redirected).
On the other hand, this may not be a problem at all. Maybe the
TSR program (or rather an installed routine of it) CAN bluntly
call APPL_INIT, after the initialization is done. (Not being
GEMDOS processes doesn't prevent ACCESSORIES from making GEM
calls).
That there has to BE a solution is proved by, for instance, new GDOS
versions (e.g. the AMCGDOS program on Ictari 25) which are capable of
calling up AES ALERT BOXES to show their error messages.
Maybe someone could experiment with calling APPL_INIT and other AES
functions from a TSR routine. (Or else disassemble AMCGDOS or some
other existing TSR that uses GEM).
Should this not work, I guess the TSR will have to hook into the GEM
vector (TRAP 2), watch others install themselves, copying the
necessary data, and then somehow pose as another real GEM process.
---------
A perhaps simpler solution maybe, as Peter Hibbs suggested, is to make
the TSR into a GEM accessory instead.
Or maybe a COMBINATION of TSR program and ACC. The TSR program would
do the dirty work of redirecting vectors, installing cookies and
generally allocating memory for new routines and data structures. The
ACC would take care of the GEM interface. Contact between them could
be made for instance via some address that the TSR advertises in a
cookie.
Jason Railton also contributed many valid suggestions on this subject,
but on points 1 and 4 I disagree:
1) The proposed structure of a new routine was
new_routine: bra do_stuff
old_vec: ds.l 1
my_id: dc.b "MY_PROG "
even
do_stuff:
* Your routine...
However, there now exists a STANDARD, called the XBRA protocol, which
instead prescribes the following structure:
dc.b "XBRA" ; XBRA protocol identifier
dc.b "MyID" ; 4-byte ID unique to program(mer)
old_vec: ds.l 1
new_routine:
* Your routine...
I.e. the ID and old vector should PRECEDE and not follow the address
of the new routine. (Not that it wouldn't be possible to combine both
structures, but that would be a bit redundant).
The XBRA protocol was probably invented (or at least established) only
AFTER the Compute book, referred to, was written. But it is now the
established standard among all professional Atari programmers, I
think. (Also see the assembly folder in Ictari 30).
The advantage of using a general standard is of course that not only
your OWN program can determine whether it was previously installed and
what the old vector was, but any other program can do the same. If ALL
programs, that redirect vectors, use the XBRA protocol this also means
that, by tracking the linked list of XBRA routines back you can:
A) find your own routine EVEN if other programs have afterwards
redirected the same vector again.
B) find the ORIGINAL (ROM) vector.
For any system vector you can check if the long at offset -12 is
"XBRA", and if so be certain that the long at offset -4 contains the
previous vector.
In particular if you want your programs to work well with OS
extensions such as MiNT etc. I think the XBRA protocol can be very
valuable.
(For ACCESSORIES, if not for TSR programs, adherence to the XBRA
protocol determines whether or not the CHAMELEON accessory will be
able to unload them).
------------
4) To wait for the space bar to be pressed the following routine was
suggested:
wait_space_bar: cmp.b #$39,$FFFFFC02.W
bne.s wait_space_bar
But ANY direct hardware access should come with the warning that it
might impair compatibility. And if, as in this case, there exists a
system call that can achieve the same thing, I think you should have
VERY good reasons before you forego the system call.
(You may find this remark finical, and it is true that the proposed
routine will probably work on all existing Atari machines. But I am
not so sure that it will work with, for instance, the MagicMac.)
An entirely equivalent system call version is:
wait_space_bar: move.l #$20002,-(SP) ;BCONIN - Console
trap #13
addq.l #4,SP
cmp.b #$39,D0
bne.s wait_space_bar
and will cost you 16 bytes assembled code, as compared to the 8 bytes
of the first version, but I still think it is worth it in the general
case. (Your situation will of course be different if you are writing
an action type game or animator or anything else that requires you to
abandon compatibility ambitions anyway).
Then again, although this is a matter of personal taste, I as a user
am not too hot on the idea of TSR programs halting the boot process at
all, and if anything would prefer something like:
test_any_key: move.l #$10002,-(SP) ;BCONSTAT - Console
trap #13
addq.l #4,SP
tst.b D0
beq.s test_any_key
which would check - NON-DESTRUCTIVELY - for any key press. This would
allow the user to press any key ONLY ONCE to possibly bypass multiple
TSR programs that are using the above routine.
Of course, what a TSR program should NOT do is to clear the screen
before it shows its installation message. That would unnecessarily
erase the messages of previous TSR programs (and yet I have come
across a few programs that do this).
------------
To: David Preston
From: Mrten Lindstrm
Yes, with OBJC_DRAW you can, just as well as the full dialog, redraw
only a part (subtree) of it by using the object number of the parent
of the part (subtree root).
objc_draw(treeaddr,subtree_root,objdepth,xclip,yclip,wclip,hclip)
If for instance the object number of a slider bar is used here (with
an object depth of 2 or more) then the slider bar and its child, the
slider, will both be redrawn but no other parts of the dialog.
You don't, for this call, need to know the exact screen position of
the object. As a clipping rectangle you can use the rectangle of the
full dialog box, or even of the full screen (as returned by
WIND_GET(0,5,...)). If drawing in a window you would probably use each
of the "visible rectangles" got with WIND_GET with modes 11 and 12.
But when you DO need the screen position, you are absolutely right
that the way to get it is with OBJC_OFFS for the x and y, by direct
reading of the object structure for the w and h. (Direct reading of
the X and Y, on the other hand, will give you the x and y relative to
the parent rather than relative to the screen).
The width and height are in the last two words of the object
structure, i.e. at offset 20 and 22. E.g. to access the width you can
use:
address of object width = treeaddr + objnum*24 + 20
To: Jim MacLeod
From: Mrten Lindstrm
form_keybd(tree%,edobj,key,nextobj,newobj,key) (AES function 55)
----------
form_keybd RETURN <- int_out[0]
tree% -> addr_in[0]
edobj -> int_in[0]
key IN -> int_in[1] (assembly: int_in+2)
key OUT <- int_out[2] (assembly: int_out+4)
nextobj -> int_in[2] (assembly: int_in+4)
newobj <- int_out[1] (assembly: int_out+2)
(Reference: Chapter 4 of the GEM Guide, in Ictari 28, - see the
function description and the FORM_DO REPLACEMENT routine.)
An interesting discovery is that the "nextobj" input variable is
simply copied to the "newobj" output variable if no new object is
selected by the user. And that this can be used to determine WHETHER a
new object WAS selected.
The same thing can, however, also be determined from the FORM_KEYBD
FUNCTION RETURN value (int_out[0]) and the OUTPUT KEY value
(int_out[2]). If the former is zero, then Return was pressed (=
selection of the default exit object), otherwise if the output key
value is zero then some other object was selected through press of Tab
or arrow keys.
(Otherwise the output key value can be passed on to OBJC_EDIT).
The recommendation to always use 1 for nextobj was actually AC's,
although your observation seems to imply that instead setting it =
edobj could possibly save us a line of code -
(namely the "Let newobj=edobj" if object wasn't pressed; see the
FORM_DO REPLACEMENT routine)
- ensuring that newobj is always the current object whether changed or
not.
POINTER OFFSETS AND ARRAY INDEXES
---------------------------------
Just to avoid misunderstandings between programmers of different
languages, when we are dealing with a WORD array such as int_out:
int_out+2 in assembly (or
WORD{gintout+2} in GFA Basic 3)
refers to the same word as
int_out[1] in C
or gintout(1) in GFA Basic 3
and even to the same word as
*(int_out+1) in C (due to the TYPED pointers of C)
Assembly programmers have a tendency, I think, to confuse the assembly
pointer expression int_out+2 with array element int_out(2) (correspon-
ding to assembly int_out+4). For instance, this mistake is consis-
tently made in Katherine Peel's, otherwise excellent, book "The
Concise Atari ST Programmer's Reference Guide" - the book I have used
the most over the years.
*/ The Atari World magazine is quite good, especially the programming
articles. As I happen to have a spare copy of issue 9 I have sent it
on to you, the subscription information for Sweden is on page 41.
I would be very interested in publishing the information on RTF and
any other text formats as well, this is the sort of information that
can be very useful to programmers. Perhaps any member with access to
the Internet could look out for any PD material which may be of use to
programmers, even PC or MAC information of a general nature could be
of interest to Atari users.
The Unicode system sounds very interesting (the character set info
will be in next months issue), does anyone else have any comments on
this. The only problem that I can see is that GEM uses byte size
characters, will an application using Unicode and GEM have to convert
every text string from word size to byte size before calling a GEM
text function?
Incidentally, the word 'finical' used by Mrten above means finicky or
fastidious and is not a word used much in English although it is in
the dictionary. ICTARI /*
----------------------------------------------------------------------
To: All
From: Peter Hibbs
I am writing a program which uses sprite graphics in low rez mode only
and I need to compress the graphics file in RAM to save memory space.
The compression time is unimportant as this is only ever done once,
the decompression time needs to be fairly fast (although it is not
that critical) and the compression ratio needs to be as high as
possible, i.e. the compressed data needs to be as small as posssible.
Does anyone have any ideas on the best compression method to use?
Since there are always 4 planes, the sprite data size will always be a
multiple of 8 although the size of each sprite will vary. I suspect
that the 'Run Length Encoding' method testing one plane at a time
(using word sizes) would be OK unless anyone knows of a more efficient
method.
In the same program I need to display a sprite as a mirror image
(flipped horizontally). It is not too difficult to modify the sprite
routine to display the graphics data starting from the right (instead
of the left as normal) but I would also need to reverse the order of
the bits in each word, for example :-
the word - 0010111001001101
would change to - 1011001001110100
The problem is that I need to do this very quickly in real time and as
there are thousands of words in some sprite images, time is critical.
I just cannot see any easy way to do this quickly even in machine
code.
For example, one method would be to shift each bit out to the C or X
registers using ROXR and then shifting them back into another register
with ROXL but since this operation can only be done one bit at a time,
it would need at least 32 instructions for each word plus some other
overheads. This could be done a byte at a time but would still be time
consuming. Another method would be to use a look up table but this
would need to have 65535 entries (or 256 for byte sizes) and would be
a bit impractical. I was hoping there would be some mathematical
relationship between the two values that I could use to convert from
one to the other but I can't see one. Does anyone have any other
ideas?
----------------------------- Advertisment ---------------------------
For Sale. AutoSwitch Overscan Unit. 20 o.n.o. (was 50 new).
This a hardware device which increases the size of the screen in all
three resolutions. Only works on STFMs (not STEs or Falcons) and
requires some soldering and track cutting. Includes manual and
software.
Contact Peter Hibbs on 01425 474415.
------------------------------ End of file ---------------------------
