Copy Link
Add to Bookmark
Report
Ictari Issue 33
ICTARI USER GROUP ISSUE 33 April 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 33
==================
ASSEMBLY Assembly Language Tutorial. Part 1.
Non-Modal dialog boxes source code.
C Window icon interface system.
File viewer program.
GFA Text adventure game.
Object change code.
STOS Using a large font in STOS.
STOS Falcon patch program.
STOS Compiler patch.
MISC Character Set Information and UNICODE standard.
SCSI FAQ file, part 1.
Programming considerations (INTERNET).
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Assembly Language Tutorial. Part 2.
Dialog box code.
C Alert message function.
Monochrome fade function.
GFA Scaling program demo.
STOS Generic STOS fix program.
Pie chart generator.
MISC HTML information.
Rich Text format spec.
SCSI FAQ file, part 2.
----------------------------------------------------------------------
EDITORIAL
=========
ATARI WORLD
-----------
According to Goodmans PD Library, the ATARI WORLD magazine has closed
down although there seems to be a very small chance that System
Solutions may take it over but I wouldn't part with an subscription
money until the situation has been resolved. It would be a great shame
if it does close since Jon Ellis's contribution was the only decent
programmers column (apart from ICTARI of course) around.
BETA TEST PROGRAMS
------------------
When any new program is written I think it is useful, if not
essential, to get someone else to try it out before it is released for
general use. This 'beta' testing can often show up minor bugs or
deficiencies which can be corrected before thousands (well dozens
then) of users start using it. This is where ICTARI can play a useful
role since between all our members there is probably every different
type of TOS version, RAM size, screen types, etc on which the program
can be tested.
In this issue Peter Strath has sent a File Viewer program for testing
(in the C folder) which members might like to try out. I have listed
some of my own comments below, perhaps other members could provide
some more and also send in their own programs for testing.
I actually found the program very useful, I especially liked the fact
that it works in all resolutions (on my machine anyway) and also that
.IMG images could be loaded and displayed in all resolutions. I did
find one small bug, if you have a folder called XXXXXXX.IMG (where the
X is any character) the program freaks out. I guess the program
assumes it is an image file before checking to see if it is a folder.
Some other facilities I would like to see are the filenames to be
sorted in order of filename, extension type and/or file size (like
most fileselectors). I think also the main window could be made
bigger, or allow the user to resize it, so that more filenames can be
displayed. It would be useful to be able to load more picture formats
although I suppose colour images would be a problem. It would also be
useful when displaying the drive letters to also display the drive
names (that normally appear underneath the icons on the desktop), this
would save having to remember which drive is used for what, I know you
can enter a name but if there is one already there, one might as well
use it. I'm not quite sure why the 'Re-read directory' and 'Previous
directory' lines are shown at the beginning of each window, these
would seem a bit superfluous since the 'close window' gadget returns
to the previous window and re-reading a directory is not really
needed. I would also like to see the total number of bytes displayed
at the top of the window shown as the number of bytes the files use on
the disk rather than all the file sizes just added together. Most
programs of this type make this mistake, the actual size of a file is
irrelevant for most purposes, it is the amount of space it takes on
the disk which is usually more important, which is the file size
rounded up to the nearest 1K (although if the file blocks are larger
on high capacity hard disks, this value will be higher). A very useful
feature (for me anyway) would be the ability to display (and save as
ASCII) any type of text file as well as just ASCII, for example
Protext, 1st Word, HTML, Rich Text format and one or two others (see
next months issue for RTF and HTML info) although I suspect this would
be rather a major project.
If anyone would like to add any more constructive comments, please let
us know.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: Peter Hibbs
From: Phil Hodgkins.
Re: GEM and AUTO programs.
The VDI is initialised before any of the AUTO programs are executed on
boot up, but the AES is not initialised until afterwards (just before
the accessories are loaded and initialised).
The only odd thing about using the VDI during boot up is that a
physical workstation should be used instead of a virtual workstation
which would cause a crash. This is the opposite of what happens when
the AES is loaded!
The following are fragments of code from Stoop, a Falcon boot manager,
that I've written, but they should work on a ST. It was written in
Lattice C.
// Main code
if(detect_aes()) aes=TRUE;
if(aes) {
// Normal start up if not running from the AUTO folder
// (i.e. the AES is present)
appl_init();
handle=graf_handle(&junk, &junk, &junk, &junk);
v_opnvwk(work_in,&handle,work_out);
}
else
// Physical workstation opened if running from AUTO
v_opnwk(work_in,&handle,work_out);
// These commands enable the mouse
vsin_mode(handle,1,2);
vq_mouse(handle,&mb_state,&mx,&my);
vsm_locator(handle,mx,my,&junk,&junk,&junk);
do {
interface(&mb_state,&mx,&my,&key,&code,&mod,UP);
// Your code goes here
}
// Closedown
v_clsvwk(handle);
if(aes) appl_exit();
The following are functions used by the above code.
/* Returns the state of the mouse (buttons and position) and keyboard
(ascii code, scan code and modifier key status). It loops until a key
or mouse button is pressed. */
void interface(short *mb_state,short *x,short *y,unsigned char *key,
unsigned char *scan,long *mod,char release)
{
*key=-1;
*mod=0;
do {
vq_mouse(handle, mb_state, x, y);
if(iskbhit()) v_get_key(key,scan,mod);
} while(!(*mb_state & 3) && *key==-1);
// Wait until mouse buttons are up or not, as required
waitmouse(release);
}
void get_key(unsigned char *key,unsigned char *scan,long *mod)
{
long x;
Supexec(conset); // Allow Bconin to read shift key status
// this would normally be in the initialisation code
x=Bconin(2);
*key=x & 0xff;
*scan=(x>>16) & 0xff;
*mod=Kbshift(-1);
}
long conset(void)
{
*(char *)0x484 |= 0x08;
return 0;
}
/* Exits when the mouse buttons are up if release=UP and are down if
release=DOWN
*/
void waitmouse(char release)
{
short x,y, state;
if(release==UP) {
do vq_mouse(handle,&state,&x,&y);
while(state!=0);
}
else {
do vq_mouse(handle,&state,&x,&y);
while(state==0);
}
}
Asm code for detecting the presence of the AES (given as source code
with NVDI 2.5)
CSECT TEXT,0
XDEF _detect_aes
_detect_aes move.w #$C9,d0
trap #2
tst.w d0
seq.b d0
ext.w d0
rts
END
This works fine with TOS 4 and should be OK with other earlier version
as it is all legal code. Problems occur with AES replacements like
Magic and VDI replacements like NVDI, so the program should appear in
front of them in the AUTO folder.
I have later versions of this code (particularly interface) but I
managed to kill my Falcon and I can't get at the code until it is
repaired.
----------------------------------------------------------------------
To: Mrten Lindstrm
From: Jonathan Leckie
1) Atari World subscription prices - This information is taken from
the February issue of Atari world but I don't think the prices will be
out-of-date you can always write and ask. Atari World have an
arrangement with "Sven Bornemark Musik" to supply subscriptions to
readers in Sweden, Norway, Denmark and Finland. Since you live in
Sweden I will quote the prices for Swedish Kronor :-
3 Issues without disc 140 Kr
3 Issues with disc 190 Kr
13 Issues without disc 560 Kr
13 Issues with disc 760 Kr
You should pay the correct amount by Post Giro to :- 23 59 59-4
The address of Sven Bornemark Musik is :-
Sven Bornemark Musik,
Lergosv 79,
238 40 OXIE {I don't know if it should be 0XIE - but you will know the
postcode conventions}
Tel: 040 54 54 54
I think it would be sensible to phone him and verify all this
information. Atari World also claims that you get an "additional
Swedish supplement free with each issue".
2) I have sent a DRAFT spec for HTML 3 to Peter but it is quite big
(approx. 420 Kb) so if it is put on the disc it will be compressed.
To: Derek Warren
You said your directory program was written mainly to learn C and
that you wanted feedback so here is some (screeeeeaaach - funny eh).
I am not anything of an expert in C coding but I liked your function
definitions at the top (bell, cur_posn, etc) but I notice that you
used 'Goto`s' shame, shame, shame. I myself have used goto`s in the
past (forgive me) but in the current climate of re-usable
modular structured programs using Gotos is a definite no-no.
If the programming police were to catch you it would be 3 years hard
COBOL in the AIX mines. May I suggest you use (in the case of C)
functions instead. So this code :-
rez_no = Getrez();
if (k==0 && rez_no==0)
{
not_low();
goto end;
}
would be replaced by :-
rez_no = Getrez();
if (k==0 && rez_no==0)
{
not_low();
end();
} else {
/* do code that can be done if in high or med res. */
} /* end of main code */
where end is :-
void end() /* commands to be done at end */
{
enbl_cur;
mouse_on();
keybd_repeat(15,-1); /* '15' puts speed of first keypress response
approx. back to normal */
cls;
gem_off();
exit(0);
}
You have used functions elsewhere in the program so just extend their
use to replace the Gotos. Your program will obviously still work with
gotos but it is better style to use functions and it makes the program
easier to read, debug and modify (apparently). The inclusion of the
Goto command in C was really a concession to the early users that used
rubbish BASICs without functions or procedures. Try and get a C book
that helps with the concepts behind IF ELSE and using functions. If
I am completely mis-judging you, sorry, but that was what occurred to
me when I was looking through it. The actual code looks O.K. though.
To: All
In case anyone is interested UDO ver. 4 should be available from
FloppyShop, Goodman, LAPD, Merlin and Power PD as we read. For those
that don't care or can't remember I was looking for it because it
converts ASCII, LaTeX, RTF, HTML formats (+ others). I haven't got it
yet but it looks funky and is available for Atari, DOS and Linux.
Registration costs 15 pounds.
----------------------------------------------------------------------
To: *.*
From: Martin Milner
The recent notes about STOS/TOS incompatibility and STOS versions have
finally spurred me to write with some recently acquired info that
should be useful to anyone programming in STOS.
STOS/TOS independence
---------------------
I have for several years now achieved TOS independence for the
joystick by using the joystick commands from the missing link
extensions, which seem to work on all versions of TOS, (including TOS
4.nn), but the mouse has until recently always been a problem without
using STOSFIX. However, recently I have come into possession of a
generic STOS fixer, which can 'pre-fix' a compiled program for up to
10 TOS versions, and it works brilliantly.
The original fixing code was produced by Les Greenhalgh, and Anthony
Jacques has now put a nice GEM interface on it (written in C), and
sent me a copy. (Thanks Anthony). As it's freeware, I've sent a copy
to Ictari to put on the disk. The program uses a set of up to 10
DEFnnnn.DAT files produced by STOSFIX3 to achieve the fixing, and no,
don't ask me how it's done, I've no idea! I've included the set of
DEFnnnn.DAT files with the program, they should enable you to make
your programs able to run on most current versions of TOS with no
further treatment required. If you add more default files, the program
will use the first 10 it finds. It can also be used to fix
BASIC206.PRG, as I had to do before using STOS on the Falcon.
STOS compiler versions
----------------------
In Ictari 32, someone was asking about whether compiler version 2.5
was the latest. Well, I've been using version 2.6 for some time, which
I believe was issued when the STE was released, but I've recently
found out that there is a version 2.7 (from Anthony Hoskin), which I
believe was issued with STOS 3D. I've sent a copy of that to Ictari as
well. I've just found out that I needed this version to overcome a
problem with using one of the commands from the latest version of
Anthony's Falcon extension, so it would probably be a good idea for
others to use it too. Note:- You'll need to have the compiler
extension already. As it is (was?) a commercial product, I haven't
included the extension files, only the compiler program and accessory.
Using the STOS Sprite Editor on the Falcon.
------------------------------------------
Finally, using the STOS sprite editor on the Falcon is virtually
impossible due to many of the graphics commands, (eg:- box, bar,
circle, etc) not working. I've now produced a patch file for
SPRITE.ACB, (SPRPATCH.ASC), which can be used to update the editor so
it will work on the Falcon. You'll need the latest version of Anthony
Hoskins Grafix II extension (3.6 upwards), which has the replacement
graphics commands in it. To patch the editor just do the following in
the program editor:-
load "SPRITE.ACB"
load "SPRPATCH.ASC"
save "SPRITE.ACB"
Then reload STOS or do an accload to reload the editor accessory.
Hope the above info/programs/files will be of use to some of you.
Enjoy.
*/ See the STOS folder for the patch programs and next month for the
Generic fix program. ICTARI /*
----------------------------------------------------------------------
To: Tony Harris
From: David Preston
Blitters - A minor correction.
While STe's certainly do have that particular bit of silicon wizardry
on board, the blitter's first appearance in an ST was in the Mega ST
(TOS 1.09). This was followed by the first one-box blitter-equipped
ST, STFM's fitted with TOS 1.4 (aka 1.04). Since then (I think)
they've all had one as standard.
To: Jason Railton
SeaPest problems
Erm, just a plain vanilla TOS 1.62 STe with 1mb on board, I'm afraid.
I didn't post a message last time cos I didn't want to labour the
point, but like Stephen Bruce (ICTARI 32), your 3D demo didn't
acknowledge the mouse either...
To: Mrten Lindstrm
UNICODE
I see that NVDI 4 advertises UNICODE support.
To: Peter Hibbs
One way of compressing your sprite data might be to use PackIce. Most
instances of Ice 2.4 I've come across on coverdisks and PD library
disks have included decompression routines in assembler. I even
compiled one using Devpac 2 from a coverdisk (assembly language might
as well be some obscure dialect of Klingon to me) and got it working
within STOS on one occasion but had a clearout and haven't been able
to duplicate the feat since...
If you do crack the compression question _really_ effectively you
might even be able to store the 'reflections' along with the sprites.
There was a report on the development of a basketball sim for one of
the consoles on telly recently, where the players looked as if they
had reflections in the polished, varnished court floor. The result was
very effective, looking almost as if the scene was being raytraced or
whatever on the fly. But of course the programmers had included the
'reflections' as part of the sprites, applying a softening mask to the
reflection bit, so it didn't require anywhere near as much processing
as it appeared. Looked good, though...
I'm not sure whether you mean like a reflection in a floor or what,
but the principle is pretty much the same.
To: ICTARI
Once you get to #100 you could use the extender for numbering purposes
- eg. ICTARI.100! (That'll fix those clever dicks who use "Install
application"!) ;-)
To: David Seaman
Sorry, but I can't see the problem with Stock Controller. The version
you submitted does seem to be the one without the disk commands to
which you earlier referred as problematical, but with regard to the
sorting problem, all I can achieve is a listing in stock number order.
Is this not what is supposed to happen? I know I'm a bit dim, but
you've really got me baffled with this!
To: *.*
Shuffling demo - ICTARI 32
I think I forgot to explain what you'd actually _use_ that sort of
routine for. Apart from the obvious card games, the same principle
works for shuffling questions in a quiz game, random tile dissolves in
a slide show etc etc.
*/ Looking through my hard disk I find that I do have the PackIce
source code, I will have to study them further. PDH /*
----------------------------------------------------------------------
To: Jim Taylor
From: Peter Hibbs
You say you want to generate an image in memory using all the normal
VDI commands and then print out the whole image to a printer (Ictari
27 and 32). I think I can provide half the answer, perhaps someone
else can do the rest. I have used the technique described below very
successfully on a program I am writing.
The idea is to make the VDI system output its graphics data to a
memory buffer rather than the screen which can then be dumped to a
printer in the normal way. First allocate a memory buffer which is
large enough for your image and store the start address of the buffer
(i.e. #buff_addr). As you probably know, the GEM system maintains two
'screen' addresses in RAM, the 'physical' screen address and the
'logical' screen address. The 'physical' screen address is the actual
address that the hardware uses when displaying the screen image which
can be anywhere in memory but is usually the last 32K of RAM. The
'logical' screen address is the RAM address that the VDI uses when
outputting its images and is usually the same as the 'physical'
address so that when a VDI function is used, the image appears on the
screen. However, it is possible to change the 'logical' address to
another location in RAM so that the graphics output will be stored
there instead of in the screen RAM.
The sequence below shows the technique using Assembler Macros (which
should be easily convertible to another language) :-
First we need to allocate a block of RAM to store the VDI output. This
can be done with 'malloc' or just define a buffer in RAM, e.g.-
buff_addr ds.b 32000 32K buffer
Next we need to find the current screen address with -
logbase fetch screen addr
move.l d0,scrn_addr save in (scrn_addr)
This address is saved so that the proper screen address can be
restored later (if we don't do this we won't be able to see anything
on screen).
Next we change the 'logical' screen address to the address of the
output buffer -
setscreen #-1,#-1,#buff_addr change addr
This command is the BIOS (TRAP 14/5) call which allows the screen
resolution and screen addresses to be changed. As we don't want to
change the resolution or 'physical' screen address, a negative value
is placed in those positions.
Now call the required VDI calls to generate the image, note that as
nothing will appear on screen during this operation, it would probably
be wise to display suitable 'please wait' message before the function
is called.
vsf_interior #2 set attribute
vsf_style #9 set attribute
circle #100,#200,#300 draw circle
etc
etc
When the image has been drawn, the screen display can be restored with
the same BIOS call but with the original screen address used as the
'logical' screen address -
setscreen #-1,#-1,scrn_addr restore addr
Any further output to the screen will appear on the screen and the
contents of the RAM buffer can now be sent to the printer.
The one big flaw in the above is that the buffer is still the same
size as the screen which is not much good for larger images.
Unfortunately I have not found a way to make the 'logical' screen
larger during program execution. I have found the two RAM addresses
which store the x and y screen sizes (at the A_line data address -12
and -4 respectively) but even though I have changed these before
calling the above code, the VDI still does not recognize the new
values. Maybe a new virtual workstation needs to be opened after the
values have been changed for the VDI to recognize them, I did try this
but it didn't work properly and I don't know enough about the VDI to
know if this should work. It must be possible somehow, I think,
because the screen expanders (such as AutoSwitch Overscan) do it
although they run in an Auto folder and affect the whole system.
If anyone can throw any more light on the subject, we would be
interested to hear about it.
----------------------------------------------------------------------
To: Peter Hibbs
From: Mrten Lindstrm
Warm thanks for the issue of Atari World, I will now try at least a
three-month subscription for it.
To: Ictari
From: Mrten Lindstrm
Apologies for using "strange" and uncommon English words. This wasn't
intended (I DO want my English to be as easily readable as possible)
and merely something that might happen when writing by dictionary.
Please continue to point out any other "unusual" features of my
English that you might spot; I promise to not find you finicky or
fastidious (or even finical).
To: *.*
From: Mrten Lindstrm
Unicode
-------
Just when I had posted my previous message, I discovered that 2B
apparently, according to "News" in ST Application, already have
included Unicode support in their new NVDI 4.
It remains to be discovered exactly HOW. With the VDI call VST_CHARMAP
(OP code 236 and taking a single intin) you could, already with the
first SpeedoGDOS version, select between Atari 8-bit characters
(=mode 1) and Speedo 16-bit character INDEXES (=mode 0). A fair guess
would perhaps be that a new mode (=2 ?) has been added for Unicode.
(I haven't yet upgraded my own copy of NVDI (3.02). But I guess I will
have to now?)
By the way, I hope I didn't cause any panic with my talk about
Unicode. Of course, the old 8-bit characters will be with us still,
for any foreseeable future. And this applies to other computers too
(Windows NT is the system that I think presently has gone the furthest
in way of Unicode support, but Windows 95, although using some Unicode
for instance in its extended file names, still mainly uses 8-bit
characters).
There are alternatives for overcoming the dissimilarities between
different 8-bit sets - e.g. RTF. For instance, in order to transfer a
file containing the text string "Mrten" (where "" is non-ASCII) from
Atari (or from PC DOS) to Windows I could simply expand it thus:
{\rtf\pc Mrten}, which Windows programs should interpret correctly
(see more in the texts on RTF that I have sent in).
For the time being, Unicode will, I think, primarily be of interest to
writers of word processors and the like. But even if not used
directly, Unicode is convenient just for reference purposes, I think
(e.g. for conversion tables) - allowing the specification of almost
any commonly used character or symbol, from anywhere in the world,
through a simple 16-bit number.
To: Tony Harris
From: Mrten Lindstrm
The blitter chip was first included in the MEGA STs as standard. All
Megas, all STEs and all Falcons should have one; other Atari computers
(including TTs) normally not.
But a program should, of course, not rely on a computer model or TOS
version to determine the presence of a blitter chip, but use
BLITMODE(-1) (XBIOS 64 with a word parameter = -1). Use bitwise AND on
the result with 1 to see if a blitter is "on" (configured by user to
be exploited by system) or with 2 to determine presence of a blitter
regardless of system configuration. Result: 0=NO.
(XBIOS 64 works with all TOS versions - even the "pre-blitter" TOS
1.00 which will always return 0=NO when ANDed as above)
To: Peter Hibbs
From: Mrten Lindstrm
Image compression with low decompression times
----------------------------------------------
Yes, some sort of run length encoding must indeed be the best choice.
But I would recommend to encode words "vertically" (in 16-pixel wide
columns). This technique is used in TINY images, and in Deluxe Paint
IFF ILBM compression type 2, and although requiring slightly more
programming effort, usually gives much better compression than
encoding words or bytes "horizontally" a scan line at a time.
The reason for this is of course the way each byte or word in itself,
on the Atari, represents a horizontal row of pixels; thus all the
pixels of a word are adjacent to pixels of a vertically adjacent word,
while only a single pixel touches a horizontally adjacent word (and
the chances of a compressible match decreases accordingly). The
difference disappears if working with e.g. the 16-bit Falcon hardware
screen, where each word represents only a single pixel.
In any case should each plane be done separately of course.
As for the speed of the decompression, for any kind of run length
encoding it should be possible to make it fast enough even for
animations, I think.
By the way, the weak point of the Tiny /Deluxe Paint vertical
compression scheme is with patterns. If your sprites contain much in
the way of patterns, you might want to reserve some code ranges for
repeating patterns of 2 (or more?) words.
References: Ictari 4: Picture formats by David Baggett and
Ictari 16: IFF ILBM (vertical word compression) by myself
Mirroring (and other manipulations) of images
---------------------------------------------
A lookup table is really the best solution as far as I can see. You
say you find lookup tables impractical and I agree that a 65536-word
table would be, but a 256-byte table isn't so horrible do you think?
Since there isn't a built in Motorola instruction for flipping a word,
the only alternative to lookup tables, that I can think of, is indeed
the shifting of one bit at a time via the X bit, like you suggest.
However, if you replace ROXL with ADDX
( example: LSR.W #1,D0 ; 1 æs on an ST
ADDX.W D1,D1 ; « æs - " - )
then each bit will take only 1.5 microseconds on a standard ST, as
compared to 2 microseconds if shift operations are used both ways.
Still, with the help of a byte lookup table you should be able
increase the speed, even further, by, at the very least, a factor two
- and maybe three or four.
Lookup tables are also what I would recommend to anyone who wants to
quickly shrink or enlarge an image (by a factor 2).
To: Jim Taylor
From: Mrten Lindstrm
GDOS
----
I do understand your hesitancy to rely on GDOS; it would be so much
nicer to be able to offer the user an inclusive package, not requiring
him to involve himself in, or even buy, GDOS.
But I am afraid there is no way past GDOS that I can see. Other than
writing your own replacement VDI driver from scratch, capable of
translating your VDI calls into drawing on a raster bitmap.
Without GDOS, the system is left with nothing but the built-in VDI
screen driver, which won't give you the memory bitmap image that you
want. (Any call of v_opnvwk will always give you the same dimensions
as the PHYSICAL screen workstation (of the AES), and in any case you
cannot, in a clean way, directly control or access a memory bitmap for
it - though you can copy between it and a raster image of your own.)
With GDOS, and the VDI driver MEMORY.SYS, you can open a workstation
(on device #61) that specifically does what you want; it allocates a
memory bitmap, the shape of which you can determine on the call of
V_OPNWK and the address of which you will receive on the return of
V_OPNWK (See chapter 5 of my GEM Guide).
---------------
If only Atari had included GDOS and more VDI drivers in ROM in the
first place, or at least distributed them with every sold computer,
you wouldn't have been in this dilemma.
There was some discussion on writing our own freeware GDOS replacement
(including drivers), that any Ictari member or anyone else would be
able to freely distribute with his programs (and among others Simon
Rigby had looked into the programming of drawing routines I think),
but I think we ended up at finding it not worth it (?).
To: Simon Rigby and anybody interested
From: Mrten Lindstrm
OUTLINE FONT FILE FORMATS
-------------------------
A long, long time ago you asked if anyone had information on the
Speedo font file format. I still haven't got that (has anybody else?),
but I HAVE now got some pretty detailed information on TRUETYPE files.
Unfortunately it is not in ASCII disk file format (and furthermore it
is copyrighted by Apple and Microsoft), but if you are interested I
think I could make the effort and write an article about TrueType.
To: *.*
HOW AN OUTLINE FONT ENGINE WORKS
--------------------------------
Although neither the end user nor the application programmer, making
his SpeedoGDOS function calls, needs to know how an outline font
engine goes about is business internally, I think there might be a
general interest in this subject, so here is an overview (there is
also some info in the text "Joy of GDOS" from Germany):
The main task of an outline font engine is of course to generate
bitmap images from the outline data (from then on, there is little
difference between an outline engine and a bitmap font engine).
The basis of any outline font data is arrays of coordinate pairs,
describing the contours that form characters (or "glyphs"). In Speedo
fonts these coordinate pairs refer to points for drawing "BZIER
curves" (= "CUBIC B-splines"); TrueType fonts, on the other hand,
merely use "QUADRATIC B-splines".
The difference between cubic and quadratic B-splines is, simply put,
that cubic splines use TWO "control points" (= off-curve "magnets")
between each "anchor point" (= on-curve point); quadratic splines use
only ONE control point between each anchor point.
/ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ\
If the above explanation isn't enough, at the risk of making it appear
more complicated than it really is, here are the full B-spline
equations.
Note to Protext users: Characters ý and þ (253 and 254) below are, in
the standard Atari set, superscript 2 and 3 ("squared" and "cubed").
Replace with Protext commands r !253 !t2!t c and r !254 !t3!t c
Linear (simple line): x(t) = (1-t)x0 + t*x1 (This is a straight line
y(t) = (1-t)y0 + t*y1 from (x0,y0) to (x1,y1))
Quadratic B-spline: x(t) = (1-t)ýx0 + 2t(1-t)x1 + týx2
y(t) = (1-t)ýy0 + 2t(1-t)y1 + týy2
Cubic (Bzier curve): x(t) = (1-t)þx0 + 3t(1-t)ýx1 + 3tý(1-t)x2 + tþx3
y(t) = (1-t)þy0 + 3t(1-t)ýy1 + 3tý(1-t)y2 + tþy3
where t goes from 0 to 1, (x0,y0) is the first anchor point and
(x1,y1) etc. are the following control and anchor points.
(The actual algorithm for calculating points on a quadratic or cubic
curve would use the basic linear formula (between each anchor and
control point), repeated in 2 or 3 steps for each t. The curve points
calculated in one step would be used as end points in the next, until
only two end points remain in the final step that produces the actual
curve point for the t.)
\____________________________________________________________________/
The coordinates for anchor and control points are given in some font-
internal unit, called ORUs (Outline Resolution Units) in Bitstream
terminology and FUnits (Font Units) in TrueType.
In the simplest case, the curves are used to generate bitmaps in only
two steps:
1) Scale them - i.e. multiply each anchor/control point
coordinate by some scaling factor - to match the pixel grid of
the current text size and device resolution. (If rotation
and/or skewing is applied, each coordinate must actually be
calculated as the sum of original x and y each multiplied by
some signed factor.)
2) Draw them on the bitmap (i.e. calculate the exact curves using
the B-spline equations above and then determine what pixels
are inside and should be drawn). This step is called "scan-
conversion".
The simplest outline font files may indeed be nothing more than a
collection of poly-beziers with a header on it; Calamus fonts may,
from what I have heard, be this simple (?).
---------------
If the text size is big enough, and the resolution high enough, there
is no need for anything more, but in small text sizes /low resolutions
you will start noticing that some character parts (stems or bows) are
visibly thinner than others, or deformed, or in bad cases even
entirely missing, just because of unfortunate interaction with the
pixel grid (if for instance a very thin part of a character happens to
pass IN BETWEEN pixel centres, it will "disappear" when the bitmap is
drawn). These bad effects become visible already at a character height
of about 60 pixels and get worse the smaller the characters get.
(Though exact figures will vary widely between different characters -
e.g. the "@" character is in much more trouble than "-" or "|".)
The remedy is called "hinting" or "grid-fitting" and is applied as a
step in between scaling and scan-conversion:
1) Scale outline curves.
2) Grid-fit them.
3) Draw them. (= scan-conversion).
Grid-fitting means distorting the outline, moving points and curves,
to fit better onto the pixel grid. Stems and bows can for instance be
made relatively thicker in small text sizes, and horizontal and
vertical stems moved to be aligned with pixel rows and columns,
ensuring uniform thickness when converted into bitmap image.
In TrueType, the hinting/grid-fitting is achieved through complete
GRID-FITTING PROGRAMS, built from INSTRUCTIONS much like the processor
instructions of Motorola or Intel. The difference is of course that no
hardware processor (as far as I know) has been built to carry them
out; this is left for a soft-ware interpreter which must be part of
any font engine dealing with TrueType fonts (thus one must be found in
SpeedoGDOS and NVDI).
At the heart are, of course, instructions for moving the individual
points or whole curve segments of the outline data, but there are also
instructions for arithmetical and logical operations, for moving data
about, and for (conditional) jumps and sub-routine calls.
Professional TrueType font designers will use special assemblers or
even high level compilers to create the hinting routines and programs.
By the way: It seems that hinting is normally shut off when text is
rotated in non-right angles. The reason is, from what I understand,
that hinting programs simply aren't flexible enough to successfully
deal with such cases.
BITMAP FONTS AND OUTLINE FONTS
------------------------------
There exists a strange myth, perhaps even among programmers, that
outline fonts generally are better-looking than bitmap fonts. Anyone
who has really LOOKED at outline text, must have realized it is
precisely the other way around. And if looking doesn't help, then just
think about it; any font engine - whether outline or bitmap - will, of
course, in the end work with BITMAPS, copied to the screen or whatever
- the difference is, an outline engine is capable of generating NEW,
reasonably good-looking, bitmap images for any new size or resolution.
But the single set of character images in a bitmap font was designed
by a HUMAN artist (well, in the best case at least) and in the size
and resolution IT WAS INTENDED FOR, no outline font can beat it.
The best an outline font designer can hope for, is to make machine-
generated bitmaps as close to human-designed ones as possible, and
this, indeed, is most of what outline font technology is about.
In fact, Microsoft has apparently just recently come up with the
ultimate solution (guess what): The EMBEDDING OF BITMAPS in TrueType
fonts. Yes, really! The circle has closed it seems.
Of course this feature will normally be used only for some especially
tricky characters and in small sizes/low resolutions, but Microsoft
does ALLOW even TrueType fonts with ONLY bitmaps and no outline data!
To: *.*
From: Mrten Lindstrm
POINTLESS POINTS
----------------
I little while ago, when I was writing my Gem Guide, I thought I
understood the meaning of "font size" and typographical "pica points".
A point is 1/72 of an inch (÷ 353 micrometres) and when text is set to
for instance 12 points, it would - so I thought - have a "character
cell height" of 12 points (= 1/6 inch ÷ 4.23 mm), i.e. be suitable to
print in lines this far apart (at a minimum). If you merely know the
resolution of the device on which you are printing (use 90x90 DPI for
screen; see WORK_OUT array for other devices), you should be able to
instantly figure out what point size to request in order to match a
given text line height in pixels.
Practically all GEM BITMAP fonts are indeed designed this way, so when
I found NVDI to return character cell heights much larger than this
for Speedo fonts, I at first thought it a bug in NVDI.
But no. It appears that existing GEM bitmap fonts are just a happy
exception, and that text point size more generally refers to nothing
as tangible at all as a "cell height" or "recommended line-spacing".
Instead, the point size merely refers to the "em" of the font.
¯¯¯¯ THE EM ? ¯¯¯¯
'Em??? What the *%#@ is the "em"?' you may rightfully ask. Well, it
seems that the em originally WAS the height of the lead slugs on which
characters were cast. The widths could vary, but traditionally the
capital letter "M" was cast on a square; hence the concept of the "em
square" or simply the "em" of a font. You might see a potential
analogy between physical lead slugs and the cells of a computer's
character bitmaps, both describing bounding boxes for the characters,
but it seems that this analogy no longer holds very well. You will
find that ascenders and descenders of many outline characters go way
above and below any em defined for them.
Neither is there, of course, any requirement for the width of the
letter "M" to equal the em; there may not even BE a letter "M" in a
font (remember symbol fonts and various non-Latin alphabets), but the
font will still always have an em. Similarly, although many fonts
contain so called "em-dash" and "em-space" characters, the widths of
these need not be equal, neither to each other nor to the letter "M"
nor the em of the font. The "em-dash" and "em-space" are simply "wide"
dash and space characters and the em itself totally devoid of any
exact meaning (except to define the internal coordinate system of the
font).
¯¯¯¯ FICKLE LINE-SPACING ¯¯¯¯
To some of you - with experience of the new Atari programs (like
Papyrus etc.) that make use of outline fonts - it may already be a
well-known phenomenon that a change of type-face, EVEN AT CONSTANT
POINT SIZE, causes the number of lines per page to automatically also
change (it may vary WILDLY depending on the whims of the font
designers). Personally, I only recently discovered this with MS Word
on a PC. The reason is, of course, that - although there may exist
some option to use the set point size (= the em) as the line-spacing
value (sometimes called "exact" or "solid" line-spacing) - the result
normally isn't usable, due to the seemingly routine habit of font
designers to under-dimension em relative to characters. Thus, the poor
application is forced to try and figure out some other, more
reasonable, line-spacing value based on maximum ascenders and
descenders (it seems that a TrueType font can contain THREE different
sets of ascender, descender and line-gap values - one for Macintosh,
one for Windows and apparently one intended to unify all formats).
Atari programmers may actually have a slight advantage in that GDOS is
supposed to always deliver a characters CELL height, that should be
immediately usable as a line-spacing value; thus it left for
SpeedoGDOS or NVDI to sort out the mess in outline fonts.
¯¯¯¯ WHY ? ¯¯¯¯
So why, oh why, couldn't the em of each and every font have been set
to be that line-spacing value that applications (or GDOS) now so
painfully have to deduce from other sources (that also would have
ensured constant line-spacing between different type faces). Or
alternatively - and perhaps even better - why wasn't simply the old
and obviously obsolete concepts of em and typographical point dropped
completely on modernizing and computerizing typography (the pica point
WAS apparently redefined from 1/72.08246 inches in metal typography to
exactly 1/72 inches in digital typography).
I would have preferred font sizes given in millimetres and referring,
ALWAYS, to the useful line-spacing of the font. (E.g. 4 mm text would
correspond to an EXACT LINE-SPACING of 11.34 points or AROUND 10
points FONT SIZE for most current fonts; 5 mm text would give a line-
spacing of 14.17 points which might correspond to ca. 12 points text
size.) I realize that metres and millimetres may perhaps not be as
appreciated by Anglo-Saxons as by the rest of us who have grown up
with them, but who can love POINTS?
To: *.*
From: Mrten Lindstrm
PC CONTEMPTIBLES
----------------
As you might have guessed from all my recent talk about PC things, I
have now got myself such a device. No, please, I AM honestly sorry
about this; I have for a long time been planning to buy a more
powerful Atari computer than my old 1 Mb ST (without an "E"), but
didn't have the money until recently. But then I wanted the ability to
run some PC stuff too, and didn't find a PC emulator a very
competitive alternative any more, and, well, sorry!
Needless to say, my trusty old ST is still taking the seat of honour
next to my PC on my desk (you wouldn't SELL a friend would you?). And
a very considerable part of the time I spend in front of my PC is
taken up by Gemulator sessions (in spite of Gemulator (4.05) not yet
working too well with Windows 95).
I still think it would be nice to have a Falcon too, though I guess
such dreams will, with my present reduced assets, have to stay dreams
for the foreseeable future.
So, what do I think of the PC? Well, compared to my old ST it is a
step up, in many ways (just the wonder of being able to use a super-
VGA colour monitor, ah), though I guess a Falcon owner wouldn't be
that impressed.
Windows 95 offers, all in all, a well-working fully multi-tasking
environment, which I never had on my 1Mb ST. But, on the other hand,
it is only about how I imagine MultiTOS, Geneva or MagiC would work on
an Atari (with enough RAM). Windows 95 may be the major breakthrough
that Microsoft has made so much noise about, but only when compared to
previous Windows versions (which for instance didn't allow icons on
the desktop as I understand it). The general movement, I assume, is
for modern systems to look more and more like each other, regardless
of computer and despite Apple's frantic efforts to claim copyright on
the concept of user-friendliness itself (called "the Apple look and
feel" in Apple terminology). There are some nice touches, windows
being resizable in all directions, and task switches are very
conveniently accomplished e.g. through the keyboard short-cut ALT-TAB
(I hope the makers of Geneva, MagiC etc. will take after these ideas).
There are minor flaws too, such as the dialog box shown before
deleting a folder being very uninstructive compared to the one shown
by any TOS version (even v1.0), but this was to be expected I guess.
The PC itself is of course a less inclusive and integrated piece of
hardware than an Atari computer, which shows itself in various ways.
For instance, the BIOS power saving feature is unable to detect MOUSE
activity, which means I must remember to at least press the shift or
control key once in a while to avoid that the computer is suddenly
shut down "in my face" (I found this very frustrating before getting
used to it). On the other hand, it is, of course, precisely this - the
open architecture (allowing multiple vendors to share in the
development) - that is behind the PC success; with a foundation more
primitive than any other currently used personal computer it seems
nevertheless to be on its way to slowly crush all competition.
The memory of my PC is 8 Mb internally, plus Windows comes with built-
in virtual memory handling; my hard disk is "850 Mb" (actually 850
million bytes = 811 Mb, falsely advertised as 850 Mb by all retailers
these days, though still 27 times the size of my Atari Megafile). But
as much as this would have been on my ST, it somehow doesn't seem that
much at all on the PC; it is as if everything took up ten times the
space on the PC.
The speed is breathtaking compared to the ST, or at least should be
when hardware specifications are studied. I would be lying if denying
to have actually experienced this speed (e.g. when ZIP compressing
files or with various graphics operations or, for that matter, with
the necessarily very processor-intensive task of Gemulator), but I
often find myself waiting for the PC and without really knowing why.
The hard disk - in itself also very fast - seems to be almost
constantly reading/writing something and I haven't a clue as to what.
This leads me to the overall sense of being at loss on my PC. On my ST
I have a fair idea of the purpose of just about each and every file on
my hard disk, and that of every disk access too. Not so on the PC.
There may be many explanations of course including:
1) I really AM a rookie on the PC
2) Since the PC isn't the all-in-one machine that an Atari
computer is (and the hardware and OS furthermore built in
layers over a more primordial core), things simply ARE a bit
more complicated.
I however strongly suspect a further reason: the tradition of over-
protectiveness and patronizing attitude on the PC and of Microsoft.
Anything as complicated as files and folders is supposed to be padded
and hidden away from the mere user. INSTALLATION PROGRAMS, objects of
intense and unrestrained hatred from my part on any computer, are
immensely popular on the PC. There are happy exceptions, such as
Gemulator, that come with no installation program and instead allow
the user full control over the copying of files and folders where he
really wants them. But the ruling philosophy seems to be that the user
shouldn't bother his little head with what an installation program
does to his precious hard disk, and if (or rather WHEN) the
installation program fails, there is no point in offering a manual
alternative, since the user is a complete moron anyway.
PC installation programs have left me with files missing (including
the Windows 95 installation itself) or worse.
To be fair to Microsoft, they have now taken some steps in the right
direction; for one thing apparently requiring any program that wants
to be called fully Windows-95 compatible, to be also fully un-
installable, ridding the hard disk from all the garbage it may have
littered it with (though I've tried a few "uninstall programs" that
didn't work too well). And they've also, very nicely, implemented a
number of features, that otherwise would be hidden in various system
files and the like, as concrete files and folders. For example: There
is a folder for the desktop, and when dragging a file icon onto the
desktop, a special .LNK file (a kind of pointer to the source file) is
created in this folder (better even than on the Atari, where all info
on the Desktop is hidden in an .INF file). There are other folders,
e.g. for a start menu (any sub-folders automatically become sub-menus)
where commonly used programs can be represented in the same way.
----------------------------------------------------------------------
To: Ictari
From: Thomas Nilsen
I have written a small example on how the object_change routine can be
used from GFA. It is not a guideline on how to do RSC-programming, but
merely an example on how to "de-select" selected buttons in RSC-forms.
*/ See GFA folder. ICTARI /*
To: All (Mrten Lindstrm)
I need some help with a small problem regarding window-clipping. I've
written a routine just to figure out how to do non-modal dialog-boxes.
But I'm having a problem getting the clipping routine correct when
my window gets a redraw/moved message when it is behind another
window. It redraws the window fine in most cases, but when part of my
window is seen on both side of the window topping my window it does
not redraw correctly. Sometimes both the menubar and the dialog-part
is drawn over the topped window and sometimes just the dialog-box
part. As far as I understand, this is due to the limit of the
object_draw's clipping - as it only clips in one rectangular block -
and doesn't handle the redraw correctly when there is more than one
block to clip. Or am I totally wrong here?
------------------------------ End of file ---------------------------
