Copy Link
Add to Bookmark
Report
Ictari Issue 25
ICTARI USER GROUP ISSUE 25 August 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 25
==================
ASSEMBLY Changing the mouse shape with 'A Line' calls.
C Tim Oren GEM Tutorial. Part 14. User interfaces.
Various C functions for MegaMax and Prospero.
Speech synthesizer for C and GFA.
GFA Weller Tools utilities.
STOS Print examples using M Cubitts STOS extension.
MISC Mrten Lindstrm, GEM Guide. Part 1.
Motorola DSP documents list.
Using the DMA port.
Current membership list.
Index for issues 1-24.
In next months issue of ICTARI (this may change) :-
ASSEMBLY
C Tim Oren GEM Tutorial. Part 15. Coping with GEMDOS.
GFA
STOS STOS loader program, etc for Missing Link Extn.
MISC How GDOS works.
Mrten Lindstrm, GEM Guide. Part 2.
AMCGDOS program.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
We have two more new members this month, welcome to them.
GEM GUIDE
---------
This month we are starting a series of articles about GEM by Mrten
Lindstrm which explains GEM calls with special reference to a multi-
tasking environment. Anyone writing programs which will be used on one
of the new Operating Systems should find the series very useful. The
articles are not written for any particular language although the
examples are shown in Assembler and GFA Basic. If anyone has any
queries about the series I'm sure Mrten would be happy to answer
them.
POSTAL PROBLEMS
---------------
A couple of members have had problems with damage to packages that
have been sent to us which contain disks. We would strongly recommend
that members write their name and address on the disks when sending
them to us. This way they stand a good chance of getting them back if
they become detached from the envelope.
SPEECH SYNTHESIZER
------------------
The speech synthesizer program in the C folder also has a version for
GFA Basic, whether this is the same speech program as the Naval Battle
program in last months issue, I don't know. Again, if anyone can
provide some Assembler code to use the SPEECH program, we would be
interested to see it.
ARTICLES
--------
As usual we are still very short of articles to publish from members.
If you can provide some source code and/or programming article please
send it in.
----------------------------------------------------------------------
CORRESPONDENCE
--------------
To: *.*
From: John Logan
re Floating point number package
I presume that most people are familiar with decimal floating point
numbers such as 0.123E2 (where E means "10 to the power"). This number
translates to 0.123 x 10 to the power 2 or 0.123 x 100 or 12.3. The
first part (the 0.123) is called the mantissa and can be positive or
negative. A positive mantissa means the entire number is positive and
a negative mantissa means the entire number is negative. The second
part (the 2) is called the exponent and determines the number of
places the decimal place has to be shifted to get the final value of
the number. The exponent can also be positive or negative but this
affects the direction of shift and not the positivity or negativity of
the number as a whole. Examples:-
+0.123E+2 = +12.3
-0.123E+2 = -12.3
+0.123E-2 = +0.00123
-0.123E-2 = -0.00123.
Binary floating point numbers are similar but only contain 0's and
1's. The binary number 0.0110E10 translates to 0.0110 x 2 to the power
2 or 0.0110 x 4 or 1.100 or 1.5 in decimal. There are a number of
different formats used to represent the mantissa, exponent, mantissa
sign and exponent sign. There are also differences in size and layout.
I think the floating point number format discussed in the listing is:
EXPONENT. The text states that the exponent is in the "excess 128"
format. An excess 128 bit number should be an eight bit binary "2's
complement number with the sign bit inverted" and is used as follows:
11111111 = +127 ie the mantissa is multiplied by 2 to the power +127
10000000 = 0 ie the mantissa is multiplied by 2 to the power 0
00000001 = -127 ie the mantissa is multiplied by 2 to the power -127
00000000 might be expected to represent -128 but instead is reserved
to indicate a zero mantissa. I think this is not being used properly
in the programme. For instance the code:
result cmp.b #$80,d2 if result exponent is 0, then use underflow
beq ufexit to set Z and zeroise
is incorrect if the exponent is truly excess 128 as it is confusing a
zero exponent (exponent = 10000000) with a zero mantissa (exponent =
00000000). It is correct if the exponent is 2's complement.
MANTISSA. The mantissa is probably 2's complement in that it is
negated using the "neg" instruction. This is not the best mantissa
format as the sign takes one bit so leaving only 23 bits for the rest
of the mantissa. It is better to use the "sign and magnitude" format
with hiding of the 24th bit.
What does this mean? We start with the simple rule that the mantissa
is always justified (except when it is being operated on). That is to
say, at the end of an operation, the mantissa is always shifted one
way or the other (depending on the operation) until bit 24 is set. (Of
course the exponent needs to be incremented or decremented at the same
time). The binary point is assumed to be to the left of the most
significant bit. If bit 24 is always a "1" (except when the entire
mantissa is zero), then it does not need to be seen and can be hidden
by the sign bit which is written over the top of it. Since bit 24 of
the mantissa is hidden by the sign bit, it is not possible to tell
from the mantissa alone whether the mantissa 000000000000000000000000
represents +zero or +1/2 (raised to the exponent of course). This is
why an exponent of 00000000 is used to indicate a mantissa of zero. In
other words the floating point number 00000000000000000000000000000000
is equal to zero.
Some examples of hiding the most significant bit follow. For
simplicity an eight bit mantissa and four bit exponent (excess 8
format) are used. The binary point is assumed to be to the left of
mantissa bit 7. We will not be concerned with the sign until the
mantissa is justified and the signs are remembered somewhere else.
positive number
(.)00101000 1100 mantissa unjustified, exponent = 4
(.)01010000 1011 mantissa shifted left and exponent decremented
(.)10100000 1010 mantissa shifted left and exponent decremented
(.)00100000 1010 bit 7 overwritten by the sign bit (0)
negative number
(.)00101000 1100 mantissa unjustified, exponent = 4
(.)01010000 1011 mantissa shifted left and exponent decremented
(.)10100000 1010 mantissa shifted left and exponent decremented
(.)10100000 1010 bit 7 overwritten by the sign bit (1)
The argument given in the original programme for using the least
significant byte for the exponent seems sensible as it is easily
separated from the rest of the number. However, I think this layout is
not compatible with the IEEE standard as used in the Motorola hardware
floating point units. The IEEE standard for single precision floating
point numbers probably uses bit 31 for the mantissa sign, bits 23 to
30 for the exponent and bits 0 to 22 for the mantissa. It does not
matter particularly from the mathematics point of view but would be
important if you were writing a programme which would use a FPU if it
was present or software if it was not. You would want the number
format to be the same.
Outline floating point add and subtract routines
They are taken from "Hashizume B. Floating Point Arithmetic" (see
below). These routines assume:
- the floating point numbers have already been unpacked
- the exponents are 8 bit signed "excess 128" binary numbers
- the mantissae are 24 bit unsigned binary numbers
- each mantissae sign is stored in an extra bit which, during
these operations, has been copied elsewhere but which is written
over the mantissa most significant bit on packing the number into 32
bits
- both mantissae most significant bits have been over-written by "1"
- both exponents have been moved to separate registers
- both mantissae occupy the upper 24 bits of a 32 bit register with
the lower 8 bits initially clear
- the second mantissa is being added to or subtracted from the first
mantissa
Note:
- floating subtract leads directly into floating add
- exponent underflow occurs with an exponent of 00000000 )but remember
an exponent of zero is represented by 10000000)
- the sign of the result mantissa depends on the signs of the original
mantissae
fsub change sign of second mantissa;
fadd exponents equal?
yes
branch to signs;
no
determine which number is smaller;
shift the mantissa of the smaller number right by one;
mantissa equal to 0?
yes
return with other number as answer;
no
increment the exponent of the smaller number by one;
branch to fadd;
signs signs equal?
yes
signs positive?
yes
set result mantissa sign positive;
no
set result mantissa sign negative;
add mantissae;
was there a carry out?
yes
rotate mantissa right by one;
increment exponent by one;
was there an exponent overflow?
yes
branch to over;
no
branch to round;
no
branch to round;
no
first mantissa larger than second?
yes
set result mantissa sign same as first mantissa sign;
no
set result mantissa sign same as second mantissa sign;
subtract mantissae;
was there a carry out?
yes
negate mantissa;
mantissa = 0?
yes
branch to zero;
no
branch to norm;
no
mantissa = 0?
yes
branch to zero;
no
branch to norm;
norm most significant bit = 0?
yes
shift mantissa left by one;
decrement exponent by one;
exponent underflow?
yes
branch to zero;
no
branch to norm;
no
branch to round;
round mantissa bit 7 = 1?
yes
add $00000080 to mantissa;
was there a carry out?
yes
rotate mantissa right by one;
increment exponent by one;
exponent overflow?
yes
branch over;
no
return with result;
no
return with result;
no
return with result;
over set overflow flag;
return;
zero clear 32 bit register;
set zero flag;
return;
The result mantissa, mantissa sign bit and exponent will have to be
repacked into a 32 bit number.
Useful books
Hashizume B. "Floating Point Arithmetic". In: Programming Techniques
Volume 3. Numbers in Theory and Practice. Editor Blaise W Liffick.
Byte Books 1979.
Huggins E. "Microprocessors and Microcomputers - Their Use and
Programming" The Macmillan Press Ltd 1979.
----------------------------------------------------------------------
To: Peter Hibbs
From: Mark Baker
"The author does not give enough detailed information on how
the floating point numbers are represented in binary format and also
does not provide any routines to convert from normal ASCII format
to or from the floating point format which would also be
necessary in a practical program. If anyone can get these
routines working and perhaps write some ASCII-FP conversion
routines, we would be very grateful."
From the comments at the top:
; bits 31-8 = 24 bit mantissa
; bits 7-0 = 8 bit excess 128 exponent
All that's missing is the sign, looking through the source I think
that's just done by two's complementing (ie neg.l) the mantissa.
Basically all that's done here is to move.b the exponent into another
register, sign extend it, then use the mantissa almost as is, treating
it as a 32bit mantissa - the extra zeroes are ignored as they're just
like putting 1.0000 instead of 1.0
I'm not going to volunteer to write the conversion routines as I'm not
too good at assembler, and copyright prevents me stealing the ones we
use at work.
To: Steve Gale
"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."
It doesn't flush the buffer when the key is released for obvious
reasons - the program may not have responded to the ones you've
already pressed, so people who press a key twice to go down two lines
for example may find they only go down once. If the program does
respond quickly enough then obviously there isn't a problem.
What might be nice would be for it to behave as normal on individual
keystrokes but to change it's behaviour as soon as the typematic came
in, replacing it instead with a single key down and key up message.
Windows on the PC works like this, but there's no way it could be done
on the ST (by the OS it could, but not in an application using the
existing OS) I'm afraid.
To: Terry King
"Does anyone know much about the Falcon hardware ? In particular
I would like to know how to use the sound, I believe that the STE
DMA sound commands are not supported on the Falcon which means STE
games run in silence, is this true ?"
Although the Falcon's sound hardware is more capable it is compatible
with that of the STE. Most STE programs work well. What Backwards
fixes is the sound chip used by ST programs, not the STE's DMA sound.
If you want information on using the extra capabilities of the
Falcon's sound system, look in The Atari Compendium or Hisoft's book.
I can give you a little example program if you want (a d2d recorder
written in C).
"I tried out a game I am writing on a Falcon and although
the game played, the display seemed to give quadruple vision
with messed up colours. "
That sounds like you're running in the wrong screen mode, if you run a
program intended for ST low res in a 640x400 or 640x480 mode (and the
program uses direct screen writes) you get this effect. Do you still
get it if you switch to ST low first ?
"using hardware scrolling and writing to the video address
registers. Should I put the Falcon in some specific mode for it to
work ?"
The Falcon has some extra video registers but I think the ones that
also exist in the STE are at the same address.
"Also, what's the best way to check whether the machine the
program is running on is a Falcon ? Would it be something like the
cookie jar variable _MCH containing the value 30 ? "
If it's literally the Falcon you want to test for, then yes. More
likely you will want to test for a particular feature, such as the
better graphics, better sound, DSP, TOS 4, AES 3.4 etc. The first
three of these are in the cookie jar (_VDO for video, the other two in
different bits of _SND), for the TOS version use Sversion(), for the
AES version (which I guess you won't want for a game) use AESglobal[0]
To: Dick Teuber
"Can anyone help me on how to use machine code in Lattice C. I want
to include a small block of machine code within the source code of
a C program and not link in with an Object file. I also need to
pass parameters from C to the CPU registers and stack. The
Lattice C manuals seem to be very unhelpful on how to do any of this."
The reason they're unhelpful is because you can't do it, it doesn't
have an inline assembler. If you want to use assembly language
routines you have to link them in (it isn't that difficult).
How parameters are passed is documented in the manuals, they are on
the stack by default or if __stdargs is used, or put in the first few
registers (check the manual for exactly which) if you compile with
register params or use __regargs. You can also declare the routine
__asm to allow you to specify any registers you like for parameters.
There is an example in the manuals somewhere of how to support both
register or stack arguments, remembering that one prefixes labels with
@, one with _. It's something like :-
_myfunc: move.l +(a7),d0 ;__stdargs entry point
move.l +(a7),a0
@myfunc: ;some code ;__regargs entry point, first int
;argument in d0, first pointer in a0
rts
depending on how many parameters and what types.
To: *.*
From: Mark Baker
Printer drivers
---------------
I really can't see any point in doing this to be honest. GDOS has its
faults, yes, but it's well supported, and these days is easy to
install. More to the point it supports vector fonts with a quality as
good as anything you'll find on any other platform (I believe it is
supposed to be rather better than Truetype).
Also, your system will /never/ be as easy to program as GDOS, whatever
you do to it. In my programs I use exactly the same code for printing
as for displaying on the screen, which your system will never allow.
Mrten suggested that we wrote our own GDOS, since there wasn't a
freeware one available. In fact there is the German AMCGDOS which is
freeware. I did have a couple of problems with this but I know other
people have used it successfully.
In my opinion the main problem with GDOS is that it is difficult to
write drivers. Atari used to give registered developers documentation
on doing so, and source to the fx80 driver so only the minimum
necessary had to be changed, making writing a new one not too
difficult. Much better as a project for ICTARI would be a freeware
driver skeleton in my opinion.
If anyone does this, some nice true colour printer drivers (current
colour ones only allow primary colours) would be nice, and I would
like to try writing a fax driver.
I like Mrten's suggestion that we write a driver that allows the user
to configure it through a text file, so allowing use with many
printers - obviously it is limited to an extent. This is, in effect,
what NVDI 3 does - it comes with drivers called PAGEPRN.SYS and
PINPRN.SYS which the user configures by typing codes into a dialogue
box.
Whilst GDOS has never pretended to offer more than the bare minimum of
support for text mode printing, there is little need for more than
that, as most applications where any more than that is necessary would
be better served by using graphics fonts anyway. However I can see
some point in UPD if it is limited to text, using a system similar to
Idealist's but as a standard supported by many applications.
Whilst I accept your comment about GDOS only being suitable for GEM
programs, most non-GEM programs are games, and indeed I can't imagine
anyone daring to publish a serious application that didn't use GEM
these days.
If, however, you go ahead with the project as originally planned,
can't we have longer, lower case names for the functions, such as
upd_output_bitmap() instead of UPD_SGM()? It makes code much easier to
understand...
----------------------------------------------------------------------
To: ICTARI
From: Jim Taylor
I think your idea of a universal printer driver is excellent. I would
love one for use with my draughting program MULTICAD. So far I have
managed to figure out how to print my drawings to a 9 & 24 pin Epson
and an HP Deskjet 520 inkjet printers. As for helping with the
specification of the UPD I think it is more likely that I will need
help to implement such a program. I'm afraid I only have a vague idea
of how printer drivers work but would be most interested in any in-
depth information/tutorials on them, eg. how are they structured and
how are they implemented by the program etc.
----------------------------------------------------------------------
To: *.*
From: Mrten Lindstrm
GIF is dead! Long live PNG!
---------------------------
In Dr. Dobb's Journal, July 95 (an American non-Atari Magazine that I
by unfortunate coincidence happened to look into) there is an article
about GIF and a new picture file format PNG to replace it.
As you may have heard, the copyright holders of GIF, a greedy company
Unisys, recently decided to squeeze money out of this format, by
demanding royalties from all developers of 'GIF based software'.
Actually it seems to be the GIF implementation of LZW compression that
is copyrighted, which makes me suspect (though I haven't seen any
mention about that) that most TIFF images may be subject to the same
problem, considering that TIFF LZW is almost identical to GIF LZW.
Even if you may be clear of charges for writing a freeware GIF-using
program, any CD (or magazine cover disk?) producer who wants to
include your program on his disk WILL have to pay.
I assume that merely making a program capable of READING GIF isn't
chargeable (?), as long as you don't supply any GIFs with it, but I
certainly never intend to create a program - or PICPAC routine -
capable of WRITING GIF after this. I personally find all demands for
money from developers for merely using a data file format a revolting
idea, and copyrights in this area to be purely destructive,
discouraging standardization.
With GIF where people, tricked into believing it was free to use, have
helped in making the file format popular and then are thanked by
suddenly being charged with royalties for this, many people have
reacted very strongly. And among these is the author of the Dr. Dobb's
article - Lee Daniel Crocker - who was apparently involved with
defining both GIF89a and JFIF and now has taken part in defining a new
picture file format PNG (Portable Network Graphic format) intended to
replace GIF.
Unfortunately there is no full format description in the magazine,
merely some addresses where this could be found (Internet:
http://sunsite.unc.edu.boutell/ and Compuserve: GO GRAPHICS, if this
makes any sense to net-trekers among you.)
Some general qualities are however presented:
1) Most importantly, PNG is guaranteed to always remain free to
use. (Which seems to prove that royalty money isn't needed to
encourage the development of useful file formats.)
2) A PNG file is started by the 8 bytes: 137,80,78,71,13,10,26,10
and after this is built up from sequential chunks (similar to
IFF images). (The pointers within a TIFF file, forcing a TIFF
reader to jump back and forth, was the reason that TIFF was
'discarded' as successor to GIF in conveying images by
electronic mail).
3) The compression used is the Deflation of ZIP (plus
'prediction' methods for true colour images). Non-lossy! (The
need for lossless compression of images that might be
repeatedly edited or cut, plus the fact that JPEG isn't good
with palette colour images, ruled out JFIF, = JPEG File
Interchange Format, as successor to GIF.)
4) PNG, unlike GIF, is capable of dealing with true colour images
as well as palette colour images.
5) Each PNG file always stores only one image (with no GIF
'logical screen' concept) though there might be a transparency
mask (possibly graduated) for this image.
6) Words and longwords are always stored most significant byte(s)
first (as by our Motorola processors), which is contrary to
how they are stored in GIF and by Intel processors.
The general chunk format is:
1 long: length of chunk (data only, excluding the 12
extrabytes)
4 bytes: ID of chunk
? bytes: data
1 long : checksum
There is, unfortunately, no requirement mentioned in the article for
each chunk to start at an even address (as in the IFF standard).
The ID is apparently to consist of four ASCII LETTERS, the cases of
which are used to encode general properties of the chunk. The default
is for all letters to be uppercase, but if letter
#1 is lowercase => chunk is ancillary (non-critical)
#2 is lowercase => chunk is application-specific (not in PNG spec).
#4 is lowercase => chunk is safe to copy into edited file even if not
recognized by editor program (i.e. not dependent on other data).
(Lowercase of letter #3 is presently undefined)
The first chunk is always IHDR, the last one always IEND and in
between there must always be one or more IDAT chunks (with the image
data) plus possibly further chunks. A palette image must have a PLTE
chunk before IDAT. A 'gAMA' chunk might appear (before PLTE and IDAT)
specifying a 'gamma curve' which could be used to adjust colour
intensity values to the specific hardware used. (Compare the
ColorResponseCurves tag in the TIFF specification; the PNG gamma is a
less accurate but simpler way to achieve the same thing).
Unfortunately the formats of specific chunks are not described in the
article, with the exception of an ancillary 'tEXt' chunk, simply
intended for short comments such as author's name, a title for the
image etc.
Considering some recent discussions here in Ictari it may be
of interest that the character set used in tEXt should be ISO
8859-1, which I think is the set used by Amigas etc. Windows
uses the same character set although with extensions (defining
characters for numbers undefined in the ISO set).
If more than one line is used in a single tEXt chunk (which
isn't recommended) a single LF (ascii 10) should be used for
newline (like in Unix etc). (Atari TOS and MS-DOS use CR-LF,
and Macintosh uses a single CR.)
There are also some C listings in the magazine from which some further
info could perhaps be deduced (the PLTE data seems, for instance, to
be a palette in the familiar old format of GIF and IFF ILBM) but
without the full PNG specification won't do us much good.
All in all, PNG seems to be a very nice and well thought out picture
format, which I would be very interested to include in the PICPAC
library if I can get hold of the full PNG specification.
But for most Atari purposes I still think that IMG or IFF ILBM should
be the first choice, using the ST (and Amiga) native bitplane-
separated format and requiring much less time (and space) to unpack.
(Although ZIP deflation is more effective than LZW, I suspect it to be
slower too - judging from the time it takes to inflate a ZIP file with
the excellent ST ZIP program.)
*/ We are sure that ICTARI members would be interested in any further
developments on this subject, if anyone has more details, please let
us know. ICTARI */
To: Peter Hibbs
Printer Drivers
---------------
I feel I have to clarify some of my points :-
UPD.PRG, as I envisaged it, would be an AUTO-folder program just like
GDOS.PRG, hence the PRG ending. As little as GDOS it would be intended
to run separately from the Desktop. If you don't go for the GDOS
option this wouldn't be as meaningful (the UPD file could then - as is
your plan - be loaded by each program when needed, instead of being
loaded by the system at bootup), but my idea was to expand UPD into
'GDOS UPD', and for this to work, the UPD routines would have to be
already loaded and initialised when VDI output is first sent to the
printer.
Also the end user would, with this system, certainly NOT have to
program his own GDOS drivers. The whole point of the universal GDOS
driver would be that a single GDOS driver program (UPD.SYS) could be
used for any printer, since instead of sending actual output to the
printer it would call the previously installed UPD routines to print
bitmaps and characters.
Multiple printers on the same system IS a problem, but not unsolvable
(The user must be given the option to install multiple copies of
UPD.SYS as well as multiple printer text file specifications, and each
UPD.SYS copy must be able to somehow connect to its own printer
specification).
A more serious problem may be to make the UPD system compatible with
SpeedoGDOS. Maybe I DID take too lightly on this. The thing is that I
don't have SpeedoGDOS (or even FONTGDOS) and have no idea of how
SpeedoGDOS program interfaces with its drivers. But it seemed to me
that if I had been given the task of adding the capabilities of
outline fonts and Bezier curves to the old GDOS, then I would have
built these capabilities into the GDOS program itself and let the
drivers remain essentially unchanged (if nothing else to save memory
space - there is only one GDOS program but potentially many drivers).
I.e. the GDOS program would convert any bezier curves and outline
fonts into bitmaps before somehow sending these to the driver.
My loose (and maybe too bold) idea was thus for us to write a
universal GDOS driver that perhaps could be used both with old GDOS
and with SpeedoGDOS (provided that someone has info on the interface
between SpeedoGDOS and its drivers), and for us to possibly also
supply a freeware replacement for the old GDOS.
If on the other hand the GDOS UPD project would mean rewriting
SpeedoGDOS, then I can only agree this to be beyond all reason.
I finally want to say, again, that whether or not you decide to adapt
UPD to GDOS I think it a great and highly useful initiative.
*/ In view of the correspondence over the past two months on the
viability of a free Universal Printer Driver system as opposed to
GDOS, it looks as though GDOS seems to be winning the argument. I must
confess that in the past I have been against using GDOS in my programs
for various reasons. I once had a very nasty experience when trying to
install GDOS on my hard disk when I nearly lost everything on it (OK,
OK, it was almost certainly my fault but you tend to remember these
things). Also the original GDOS was very limited with bit map fonts,
some bugs, etc and somewhat messy to set up. However, with the arrival
of SpeedoGDOS, this has all changed and I think it may be to my (our)
advantage to look at it for future programs. Having re-read the
SpeedoGDOS review in ST Applications it does, as Mark Baker says, have
facilities which my UPD system could never emulate (not that I ever
intended UPD to supersede GDOS of course) and especially the access to
high quality vector fonts would be very useful.
Several of my original arguments against GDOS still stand though, that
is that it is not free and that it cannot be used with STOS but, on
the other hand, I suppose if one is writing a 'serious' PD program
which requires high quality printing with vector fonts, colour, etc,
it is not unreasonable to assume that the end user will have
SpeedoGDOS already installed on his system. At least the user will
only need it once so that it can be used with a number of different
programs. The same argument would also apply to STOS, that is STOS was
mainly designed as a games writing language and not for writing
'serious' applications programs.
The problem I have (and I'm sure a lot of other members also) is that
having never used GDOS in any of my programs I am not sure how to use
SpeedoGDOS in a practical application. When one buys SpeedoGDOS, do
you get any programming information, for example Mark Baker says that
he can output vector drawings to screen and use the same code for
printer output but how do you ensure that the size of the drawing on
the print-out is the required size with the screen and printer
resolutions being different (and even different printers resolutions
being different). How do you print bit map images with SpeedoGDOS.
Does the NDC system have to be used. What extra VDI commands are
available under SpeedoGDOS. How do you print in colour and what colour
facilities are available, i.e. primary colours only or dither patterns
to give multiple colours (I have just purchased a Canon BJC600 colour
printer and I would like to write some code to print in colour). Since
Mark is a strong advocate of GDOS/SpeedoGDOS, perhaps he would like to
write a COMPREHENSIVE article on how to use SpeedoGDOS in an
application program (preferably in 'GEM pseudo-code' rather than any
specific language).
Having said all that I still think that the UPD system has some merit,
perhaps (as Mark suggests) as a mainly text output system with some
limited graphics capabilities. I will probably continue to develop it
on those lines and publish it later so that anyone can use it if they
want to in an application which does not need the sophistication of
SpeedoGDOS. Any further comments would be welcome.
Although I think that any future applications programs should use
SpeedoGDOS rather than GDOS where applicable, I would still like to
see more information on the old GDOS system since this could be of use
in writing software for new applications. For example, how do GDOS
printer drivers work, how does GDOS itself work, what is the format
for bit map GDOS fonts, etc. Mrten Lindstrm has provided some useful
information on GDOS drivers which we will publish in the next issue
along with the AMCGDOS freeware program that Mark Baker mentioned. If
anyone has any other information on GDOS or SpeedoGDOS please send it
in.
As I mentioned above, having now got a colour printer I am interested
in writing some software for colour printing. The printer has control
codes to output the colours black, magenta, cyan, blue, yellow, red
and green using the escape code ESC, $72, n where n is the colour
number 0-6. Presumably to make the output image appear in any other
colour, say orange, one would use two (or more) colours in a dot
pattern which simulate the required colour, i.e. dithering. I believe
there are standard dithering systems but unfortunately the printer
programming manual does not give any information on this technique.
Does anyone have any information on colour dithering techniques. Also,
does anyone have information on how the Hewlett Packard colour
printers process colour information since they seem to use a different
system to Canon. PDH /*
----------------------------------------------------------------------
To: ICTARI
From: Abdul Rahman, Singapore
I would really like to write games and applications programs for the
STE and Falcon since I have bought both machines. But here in
Singapore support for the ATARI machine is dead. I bought both from
Singapore suppliers and both have since changed over to PC compatible
machines and I am left stranded with no support, hardware and software
is zero here. I believe in Singapore there are quite a number of users
and that's the reason I want to learn programming and start writing
good software for the Atari machine. I can write programs but only on
a PC compatible machine.
I'm wondering if there is a program that can transfer the program the
I wrote on the PC to the Atari maybe with a little modification in the
original language that I wrote it with. For your info the language
that I use is CLARION PROFESSIONAL DEVELOPER on the PC and is written
using the C language. I have heard the C language is also common on
the AMIGA machine which is why I am interested in it.
I have PURE C and LASER C but the manuals have been lost. I have
enclosed a disk with one of the modules of the application software
that I wrote using Clarion Professional on the PC. I can load it into
DevPac and also on PURE C and LASER C and still see the whole routine
as I wrote it on the PC but I cannot compile and link the code on the
1040 STE or Falcon 030.
Please advise on the best possible way I could get around it. If I
could write a program in my office and bring it home to transfer the
code so that it can run on the Atari machine that would be really
wonderful. If no such program or ways exist, please advise on a
possible solution to the problem. I'm keen to write for the Atari
machine and maybe show one or two here what the Atari can do. Atari
has been labelled as a GAME MACHINE here, people have the wrong
concept about it.
*/ We think it is very unlikely that you will find a programming
language which will operate properly on a PC and Atari (and Amiga ?).
The nearest you might get is to use C and keep to the ANSI standard
commands but even then there would be all sorts of problems,
especially if you wanted to use GEM (or Windows on the PC) and any
hardware specific code. If anyone knows of any programming language
which will work on both platforms or has any further comments, please
let us know. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Martyn Wells
Hi there everyone. I have just got an STE and was wondering if anyone
knows if you can do hardware scrolling of the screen from GFA BASIC
3.5. Also does anybody have any info on the file format for EZ-ART
professional picture files, i.e .EZA files and does anyone have any
info on how to use the Videomaster digitizer from GFA BASIC. I know
how to display the films, etc, but I want to be able to grab from
within a program that I'm writing, i.e full screen grabs.
----------------------------------------------------------------------
To: ICTARI
From: Terry King
Devpac 3 possible improvements:
1. After compiling, the messages window should be put to the back
(after being displayed for around one second) and then the last
selected window should be brought to the front.
2. After compiling I generally always save the code before running,
however if you forget to go back to the correct window then the
output to the messages window ends up wiping over your file ! This
would be solved by having 1.
3. You may have a number of sub-routines that you regularly go to,
but putting their position in the bookmark doesn't tell you anything
about the position of the marker. A bookmark should contain the
first line of the text for identification purposes.
4. An advanced feature that I would love to see in GENST would be a
sub-routine fold feature as seen in GFA Basic where any number of
lines can be compressed to a single line just by pressing HELP on
the title. ie, something like ..
SUB multiply_by_8
move d0,d1
and.l #$ffff,d1
lsl.l #3,d1
ENDSUB
after folding would become,
> multiply_by_8
For a huge program (like the one I'm currently working on) this would
be a great feature for tracking down a particular piece of code
without having to wade through thousands of lines.
5. Another advanced feature to save precious memory is for GENST to
allocate just enough memory for the window instead of a fixed size
which must be specified in the preferences. It would be better if
the size specified were treated as extra memory per window and not
an absolute value.
6. A bug which has crept into version 3 is that GENST doesn't restore
the resolution after cancelling MONST which can result in an almighty
mess that only a reset can fix.
As HiSoft has stated that it will continue to support the ST maybe we
should get a conference going here that we can then send to them :-)
*/ We especially like the 'sub-routine fold' idea and it would be
relatively easy to implement. ICTARI /*
------------------------------ End of file ---------------------------
