Copy Link
Add to Bookmark
Report
Ictari Issue 40
ICTARI USER GROUP ISSUE 40 November 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 40
==================
ASSEMBLY ST Assembly Language Workshop. Chapter 5.
C Memory debug utility.
GFA Text manipulation/search routines.
GFA VDI functions.
STOS Line clipping techniques.
Lottery program.
FORTRAN FORTRAN on the Atari.
MISC Falcon register information.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY
C Bezier curve routine.
GFA Functions for using ARGV arguments in command lines.
File recognition routine.
Using the Iconified window Server in GFA.
STOS Slideshow program and tutorial.
FORTRAN BC-FORTRAN 77 development system.
FORTRAN-C compiler.
Compiler-Driver for BC-FORTRAN 77.
MISC A quick guide to creating an HTML document.
----------------------------------------------------------------------
EDITORIAL
=========
THE FUTURE OF ICTARI
--------------------
A few months ago I mentioned that I was planning to purchase a PC,
well I have now built my own system around a 133MHz Pentium with the
all the usual bits and pieces, 8 speed CD-ROM, 32Mb RAM, 17 inch
monitor, 1.6Gb HD, etc, etc. The problem, as I said before, is that I
do not have sufficient room to run both the PC and the Atari so I am
going to have to dispose of the Atari hardware, software, books and
magazines eventually. This means, of course, that I will be unable to
continue with the editing of Ictari after this year. Although the
membership has fallen over the last few months from about 60 members
down to about 30 at present, I believe the members that still remain
are quite happy to continue programming on the Atari and some members
are still providing useful contributions to the magazine. I would hope
that Ictari will continue into next year but this will depend on
someone being prepared to take over my role as editor after Christmas.
I have the next issue already prepared which I will send out as usual
in December but if no one has volunteered to take over by then, this
could be the last issue.
If you have found these magazines useful over the past three years and
you would like to continue receiving them, then please seriously
consider whether you could do the job of editor. It is not difficult
although ideally you do need a hard disk as well as a colour and
monochrome monitor. Naturally I will be happy to assist in any way I
can and I can probably provide the necessary software and hardware, if
required. You do not need to spend a LOT of time on editing the mag,
most of the time is spent just deciding what material to include on
the next disk, preparing this text file and then making 30 copies of
the master disk for despatch which takes about an hour. If anyone in
the UK is interested (and I sincerely hope there is) please ring me
any time so that we can discuss it further.
Naturally I am sorry that I have had to step down as editor as I have
enjoyed putting the Ictari magazines together over the last three
years but personal circumstances have meant that I need to have a PC
to fulfil other commitments which I cannot do on the Atari. However, I
do hope that this will not be the end of Ictari, but that is really up
to you. I look forward to hearing from someone SOON.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: Everyone
From: Jason J Railton
Re: Stuff...
I hope you liked the two-player TANKS game, from ICTARI #39. It
wasn't a demo. That was the game.
I'll try to get my BUZZSAW game finished soon too. It's difficult to
set the difficulty levels just right, and some of the special effects
I'd planned for bonuses are proving a little complicated. I just need
to spend some time on it. I haven't done a thing on my 3D maze for
ages though.
I'm not really bothered that ST Format has finished, as there wasn't
much in it worth reading over its last year. It is a shame, however,
that the PD, repair and hardware companies have lost their advertising
space. Good luck to the new magazine, anyway.
I won't be getting rid of my ST for a long time, I can assure you.
Anyway, I've sent in a tutorial on clipping lines to the screen edge.
You can use the techniques in any language that has a line drawing
command, and if you look on ICTARI #31 you'll find some machine code
line drawing routines written by Peter Hibbs to use them with.
Run either CLIPPING.PRG or CLIPPING.BAS (STOS) with CLIPPING.TXT in
the current directory, to read the tutorial. Step through it with the
SPACE key. You can also send CLIPPING.TXT to the printer, but then
you won't get the diagrams or demos.
I've already covered rotating lines, and I'll go on to describe 3D and
perspective for future articles. Finally, I'll talk about functions
such as SIN and COS in machine code. (For those who can't wait, you
use a table of values of INT(16384*sin(r)) in your sums.)
*/ The CLIPPING.PRG program is very good as it describes the clipping
techniques used together with animated graphics of the functions.
Unfortunately it bombs out in Monochrome but is excellent in colour.
It would be very useful if this idea could be used in other tutorial
type articles. ICTARI /*
----------------------------------------------------------------------
To: ICTARI
From: John Hayward
I am trying to write a program that can produce touch tone beeps
through the ST's monitor speaker (like a telephone) using STOS. I have
tried doing this using sound samples but they were not of sufficient
quality to dial correctly, What I need is some method of playing
sounds using the Yamaha sound chip with exact frequencies in Hertz.
The values required are as follows :-
Frequency ---------digits---------
697Hz 1 2 3 (A)
770Hz 4 5 6 (B)
852Hz 7 8 9 (C)
941Hz * 0 # (D)
1209Hz 1336Hz 1477Hz 1633Hz
For example, if button 8 is pressed, the 852Hz and 1336Hz tones are
sent out to the exchange to signify digit 8.
This shareware program is unusual, I am using it to create a crude
form of E-mailing system which does not require a Modem or a
subscription to an on-line service. If you have access to a television
with Teletext you can advertise things on a notice board on channel 3,
page 388/389 and there is a place where you can sell computers on
channel 4, page 435. To place ads you use an unorthodox method of
writing your message, you convert each individual letter into a two
digit code (A=11, Z=36, etc) and you then call a premium line phone
number and type in every single code which takes about 5 minutes and
I estimate would cost about 2-2.50 per advert. My program will
convert the text message into a series of tones and play them down the
line at relatively high speeds which results in cheaper bills with no
errors. As well as selling hardware on the ads you can also advertise
PD libraries, BBSes or whatever so you might find the program useful
to advertise ICTARI.
*/ I think it may be more difficult to implement than you imagine. I
don't program in STOS so I can't tell you how to do it using that
language but I have written a small machine code program to test out
the basic idea and it does not seem to work.
I suspect there could be several reasons that it fails to work
properly, the main one being the frequencies that the Programmable
Sound Generator (PSG) can generate. As you probably know the tones are
derived from a source oscillator of 125KHz which is then divided down
by the PSG counters to produce a range of tones. The problem is that
it is not possible to produce ANY tone, only an approximation of the
tone. For example, to calculate the division factor for a given tone
you would use the following formula :-
divide_factor = 125000/f
where f is the desired frequency. So a frequency of 1633Hz would give
a value of 76 which is the value that would be loaded into the PSG
registers for channel A (or B or C). To calculate the actual frequency
produced you would use the following formula :-
f = 125000/divide_factor
If you use the divide_factor value mentioned above to find the actual
frequency it calculates as 1644.73Hz which is quite a bit different
from the 1633Hz required. The other frequencies work out as follows :-
Required Divide Actual
Frequency Factor Frequency
697 179 698.32
770 162 771.60
852 146 856.16
941 132 946.96
1209 103 1213.59
1336 93 1344.08
1477 84 1488.09
1633 76 1644.73
It may be possible to fiddle about with the divide_factor to get
slightly nearer to the required frequency but I doubt whether it would
still be reliable enough for general use.
When I worked for British Telecom I designed some equipment to
generate tone calls and I seem to remember that the tone detectors in
the exchange equipment have a tight tolerance on the tone frequencies
to avoid cross channel interference. Also the tones must be reasonably
good sine waves with very little distortion to ensure reliable
detection. This may be another problem with your scheme, any
distortion introduced into the sounds will make it less reliable.
Another factor is phase difference between the two tones which also
has to be within certain limits.
It may be possible for other computer platforms (such as the PC) to
generate accurate tones but I don't think the Atari is capable of
doing this unless you can use the D-A converter in the STE using
sampled sounds. You said that this did not work but how exactly did
you do it. Presumably you sampled the tone output from a telephone and
played them back using the D-A converter chip in the STE.
Probably the best way to achieve your aim using the Atari would be to
use the tone generator chip which is used in telephones and is
available for a few pounds. The chip could be controlled from the
Atari parallel port to generate the required tone pairs but this will,
of course, require some hardware building on your part. If you would
like further details of the chip let me know. ICTARI /*
----------------------------------------------------------------------
To: ICTARI
From: Mark Foot
Can anyone suggest a method of having a library of SmartIcons as per
Windows, whereby a user can select those he/she wishes to have
available within a program. I am writing a 'programming language' in C
for a robotics project and I would like user selectable tools via
icons.
Has anyone managed to fit a second serial port to a 520ST? If so any
hints and tips on hardware and software aspects would be appreciated.
----------------------------------------------------------------------
To: ICTARI
From: Charles Ayres
In your last issue of ICTARI there was a request for information
regarding PAGE 6 magazine for the Atari 8 bit. I am happy to tell you
it is still going strong thanks to Les Ellingham and Sandy (his wife).
It is now called Page 6 New Atari User as Les took over the old ATARI
USER magazine when it went out of production. Unfortunately this
magazine is now printed in A5 format and is only available on
subscription from :-
PAGE 6
PO BOX 54
STAFFORD
ST16 1DR
Annual subscription rates are as follows :-
UK MAGAZINE ONLY (6 ISSUES) 15.00
UK MAGAZINE WITH DISK (6 ISSUES) 25.00
----------------------------------------------------------------------
To: Peter Hibbs
From: David Preston
Thanks for your additional comments re WordGrid. I have to admit I'm
no wiser (more puzzled if anything) about the problem with Mortimer's
print spooler. I use Hisoft's spooler (HSPOOLER.PRG) from the
"Introduction to Programming Utilities" pack, and there doesn't seem
to be a problem with that one. I don't have Mortimer though, so I
can't try that out. Is Mortimer usually co-operative? (I suppose it
must be or you'd use something else!)
To: *.*
What about everyone else - any other problems with WordGrid, with
print spoolers or w.h.y.? Or any similar problems with your own Hisoft
Basic progs?
To: STOS programmers
What a swiz! (Is swiz a real word?) Anyway, I was fiddling about
converting a GFA listing of a fractal (Mandelbrot set) generating prog
from an ancient coverdisk, into STOS. It worked ok but slowly (no
surprises there, then!) so I set about optimising it a bit. I'd used
nice structures (repeat...until etc.) originally, but found that nasty
goto's and stuff were significantly quicker. It's all very well trying
to write decent looking code, but if the language doesn't co-operate
you're spragged. (Now that _is_ a real word.)
One thing that did emerge however is that it's much quicker if you
have to use floats in your maths to use _all_ floats. Or at least
don't have a mixture of ints and floats in individual calculations.
Even for...next loops should count in floats if the counter is used
with floats in a calculation within the loop. I think the manual
suggests that mixing number types in calculations is inefficient, but
sometimes you need to discover the truth of these things for yourself!
To: Kevin Cooper
Re - Subject DLL's
I'm not sure what you mean by "the standard graphic format will be the
standard device independent format" - surely something like the PNG
format as described in Ictari recently would be an ideal choice? RTF
would seem right for WP, but spreadsheets are a more complex matter,
as different applications have different features/functions etc. It
depends if you want to just transfer data (where a DIF file might
suffice) or have a common (standard) data file format to save formulae
etc. And bear in mind that some software producers (eg. Lotus) have
been known to be less than chuffed about people using their
standards...
To: UK members
With this new Channel 5 in the offing, and the need to retune VCR's to
avoid a clash with the new channel, does anyone know if/how this will
affect those of us using our ST's on a telly?
*/ I find Mortimer very useful actually although it needs to be on a
hard disk to be practicable. It provides a reasonably good and very
fast text editor as well as a number of other handy facilities. I
would be happy to send you my copy with manual if you want to try it
out with your program, let me know if you want it. Alternatively you
could just mention the problem in the document file with your program
and let the end user disable the spooler. PDH /*
----------------------------------------------------------------------
To: Kevin Cooper and everybody else
From: Mrten Lindstrm
VRML
----
If you do implement a VRML browser, I think you will be really in the
forefront of things. I had personally never even heard of VRML until I
read your message. However, with the help of Alta Vista, I quickly
found the specification for VRML 1.0 (in HTML format) on the net - and
I have now sent it to Ictari. It sounds like a very nice idea but
probably a lot of work to implement.
To others who also didn't know what VRML is, and still don't:
VRML (Virtual Reality Modelling Language) is a language for describing
a "world" of 3D objects (and light sources etc.) of which some may be
possible for the user to manipulate (presently only in the form of
clickable links - to other VRML worlds or to HTML texts - but this is
intended to be developed in the future).
VRML has got absolutely nothing to do with HTML (HyperText Markup
Language) or SGML (Standard Generalized Markup Language - of which
HTML is an application), except that its name was originally inspired
from them. VRML doesn't compete with them. HTML and SGML deal with
TEXT documents, VRML with 3D worlds.
To: Ictari Editor, Article Writers and Readers
From: Mrten Lindstrm
__________________
HTML FOR ICTARI?
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
It seems to me that things are definitely moving towards more and more
HTML. And I am not just speaking of the Internet where new specifica-
tions etc. seem to be often provided ONLY in HTML format. Even else-
where, such as on software distribution disks - where README files
etc. used to be only in plain text ("ascii"), you will now often find
alternative HTML versions.
HTML (with a good browser) not only allows documents to LOOK better
but can sometimes even add to the information contents. Where, for
instance, programming syntax is described in printed books, ITALIC
style is often used to denote a VARIABLE; this can be very easily
translated into HTML markup but will be lost in plain text.
Being able to use different HEADING LEVELS (displayed in different
font sizes) can also be very helpful to make a presentation clearer.
And, of course, HTML allows PICTURES to augment the text. Back in the
distant past (Ictari 10) our Dear Editor did raise the question of
whether Ictari should change from plain text to something richer
allowing pictures (apparently without much positive response though I
am not to blame 'cause I hadn't yet joined), but, of course, HTML
wasn't an option back then (before the Atari HTML-Browser).
In addition to all this, HTML has some further advantages:
ù It is non-proprietary. Bound to neither a software company nor
a specific platform. (And, again, its support is only rising.)
ù Good HTML browsers come as _FREEWARE_ (both on Atari and PC).
ù It is viewable as plain text too (no control characters used).
Admittedly not quite as neat-looking as a dedicated plain text
file could be. But since both newlines and extra spaces will
be ignored by the HTML browser, they can be freely used to
adorn the layout of the text when viewed as uninterpreted
"ascii".
ù It is very SIMPLE TO WRITE HTML documents with no more
software than a plain text editor. REALLY, it IS!!!
I have written a brief "quick and dirty" guide to converting a
plain "ascii" text to HTML, and could perhaps write a more in-
depth article on HTML too, if there is interest for it.
Perhaps making that article in HTML format :-)
I have also sent in the specification documents for HTML 2.0
and 3.2, the latter actually being a bit more accessible, I
would say, though lacking some explanations and
recommendations of the HTML 2.0 docs. (See some further notes
below.)
ù HTML is per definition highly adaptable to any display (or
even to speaking machines) or user preferences. If you have
ever used CAB or HTML-Browser you can see how it, on the fly,
reformats the text to fit whatever window width you choose,
and this is how any browser should work. (Thus, you SHOULD be
able to browse even on an ST low-resolution screen - 320x200.)
You sometimes hear that you need an 800x600 display to go
browsing the Web. This is CRAPTALK!!! It may be true that some
lousy authors use unnecessary large pictures, as well as
various effects created with unsound or even outright illegal
HTML constructs, to cover up poor text contents. But good HTML
should be written to be enjoyable even on very small screens
(there ARE Macintosh Classic users out there who browse the
Web with apparently not more than 460 monochrome pixels width
available). And it should (as far as possible) provide
alternative meaningful text for those who - for whatever
reason - cannot see the graphics.
In fairness, the last of these advantages may also be seen as a disad-
vantage: HTML is NOT a page description language. It is used to mark
up the PURPOSE and MEANING of various parts of the text, and leave the
display for the browsing software and human to decide on. Thus HTML
lacks a legal and sound method for such a simple thing as indenting a
text section (though self-brewed solutions abound, one more horrible
than the other). And so you may perhaps prefer something like Post-
Script, Acrobat or maybe even RTF for a printed document with well-
defined layout, page breaks & numbering etc.
''~``
( o o )
,-----ooO---(_)---Ooo-----.
/ \
/ SO, WHAT DOES EVERYBODY \
( THINK ABOUT USING )
\ MORE HTML IN ICTARI ? /
\ /
`-------------------------'
Some follow-up questions:
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ù Does everybody have a copy of CAB or HTML-Browser?
(It IS freeware you know.)
ù Are you HAPPY with CAB /HTML-Browser?
I find CAB to compare amazingly well with the PC's MS Internet
Explorer (which I must admit is what I use for online
browsing) and Netscape, though there are a few weak spots:
- For one thing, CAB seems strangely unable to make proper use
of the ordinary ST low resolution (320x200 in 16 colours).
Outline font sizes don't match the system bitmap font size
well (though to some extent explainable by how GDOS/NVDI deals
with it) and, very oddly, CAB doesn't seem to make use of the
COLOUR!!! A REALLY GOOD browser should work equally well in
any resolution, taking advantage of what colours there are.
- CAB also doesn't seem to keep more than one document in
memory at a time. Caching pages in RAM could save considerable
time when jumping back and forth - e.g. between a table of
contents and the "contents" (sub-documents).
I am (possibly) considering writing an alternative HTML
browser with the following specifications:
+ Small(er than CAB) - possibly so small that it could
even fit on each and every Ictari disk (?).
+ Fast(er than CAB (?) )
+ Taking full advantage of ST low resolution as well as
any other resolution.
- Simple. Bare minimum of functionality (definitely no
support for online Web browsing) and perhaps initially
not supporting some more advanced HTML features such
as the tables of HTML 3.
Would there at all be any need for such a program?
To: All
From: Mrten Lindstrm
HTML versions (again)
-------------
Since last month I have found out some more on this topic and it seems
that the real reason that HTML 3.0. was abandoned was that
a) - Producers of HTML browsers were too lazy to implement it and
instead thought it more fun to implement their own non-
standard extensions.
b) - Illiterate people, knowing nothing about the HTML 3.0
specification but styling themselves "web designers" or
something similar, took on the habit of calling their sites
"HTML 3.0 enhanced" when in reality they had just jammed some
non-standard extension into their HTML, supported only by
their personal favourite browser.
From another (and kindlier) perspective, one could perhaps just say
that the HTML 3.0 specification was too big and ambitious.
HTML 3.2 is thus much smaller than 3.0 and is furthermore largely a
result of "reverse engineering" of existing extensions (though
adapting these for coherence among browsers and compliance with the
SGML foundation of HTML where this was violated). Most of HTML 3.2 is
therefore already now supported by the newest browsers - including the
Atari CAB - AND there is also validation software (for PCs at least)
and services available to certify HTML 3.2 compliance of documents.
Non-ascii characters in HTML
----------------------------
Last month I said that the British pound sterling symbol () could be
represented as £ in HTML. It seems however that this isn't
strictly in the HTML specification (neither 2.0 nor 3.2) though it is
RECOMMENDED in the HTML 2.0 document. In practice it seems that at
least the browsers I have tried DO understand £
Generally, a character can in HTML (and SGML) be expressed in one of
THREE ways:
ù directly as a character (byte) e.g.
ù as a "numeric reference" e.g. £
ù as an "entity reference" e.g. £
Since the CHARACTER "" IS in the HTML character set - at code
position 163 - the first two methods should always work. I.e. £
will unambiguously be interpreted as a pound symbol by ANY truly HTML-
compliant browser on any platform, and so will the character with
number 163 (that appears as "£" in the Atari character set, so Atari
browsers need to translate it before display).
The third method however formally requires that the "entity" be
defined in the so-called DTD for HTML (DTD = Document Type Definition
- an SGML term for what essentially constitutes the definition of the
HTML language, or at least a significant part of it). And "pound"
isn't (yet?).
The same thing applies for most other "extended" (non-ascii)
characters (including overline " ") EXCEPT the modified LETTERS, all
of which have entities defined for them ("Mårten" is in strict
conformance with HTML :-)).
Of course the most compact and perhaps simplest method is to use
direct characters - remembering to use the "ANSI" (aka ISO 8859-1 aka
Latin-1) character set.
The major reason not to do that is if one fears that 8-bit characters
might be corrupted during electronic transmission. This isn't a
problem if documents are distributed by disk of course, but it is also
not a problem if the document is placed on a typical WWW site using
the HTTP protocol, since this protocol preserves 8-bit characters.
Other protocols can cause problems though, and conversions by local
networks between different character sets might possibly also corrupt
8-bit characters.
To: Kevin Cooper
From Mrten Lindstrm
ATARI STANDARDS FOR DATA FORMATS
================================
The only data types for which there is any standard - AS DEFINED BY
BUILT-IN TOS SUPPORT - are, I'm afraid, pictures.
Apart from bitmap images, supported via VDI call vr_trnfm (and then
the other raster functions) as well as - on printers and memory
devices only - v_bit_image, TOS can, of course, handle VECTOR images
supplied as GEM metafiles (.GEM) files - i.e. a series of recorded VDI
commands, to be replayed on screen or printer.
There actually isn't any one function that simply can take a .GEM file
as input and play it. (Maybe such a function would be a useful project
for a DLL?) Instead each VDI command of the .GEM file has to be
interpreted and played individually.
For text, the only real standard is plain "ascii" text - without
formatting controls. There is no built-in TOS support neither for any
richer text format nor for a spreadsheet or database format.
When exchanging data via the clipboard or - with MultiTOS or
compatible - the drag-and-drop protocol, the exporting application
generally has to offer the same data in a variety of formats for the
importer to choose from. In the case of text, a plain text file should
definitely be one of the offered formats, but for richer text .1WP
(1st Word Plus), RTF (Rich Text Format) and nowadays perhaps most
important .HTM(L) would be among the most widely supported
alternatives.
When creating "DLL" import functions, on the other hand, each function
could of course be defined to convert only to one, especially useful,
format. (Again, possibly HTML for text (?)).
One useful project would, I think, be routines that try to translate
between .GEM metafiles and PostScript. I have personally not seen the
specifications for PostScript and I am too mean to buy a book. Maybe
someone would write an article on PostScript?
To: Pete Bailey
From: Mrten Lindstrm
I don't know the answer to your main question, as to what method would
be best to change the Atari drop-down menus into pull-down menus. I
have got something called ST Control (which I haven't used much) and
which came with a utility that I think did just that - and working
fine on my ST as I recall it. So I guess it SHOULD be possible somehow
(maybe I shall have a look at that program again).
Your desperation is an echo of mine when I was trying to coerce TOS
into changing the system font (the result of which was my PC_LINES
program, published in an earlier Ictari). This change too has a
tendency to be inexplicably reset. I guess this is almost inevitable
with any such type of "unforeseen" system configuration, unsupported
by solid high-level functions and requiring semi-clean means.
As to some of your secondary questions:
Q: Is XBRA worth losing sleep over?
A: XBRA probably won't provide any help in this. As long as all
programs adhere to it, it makes it possible to simply and
cleanly uninstall vectors as well as to detect all of the
previously installed programs. But when TOS (at least all the
older versions) install vectors it will probably disregard
XBRA completely.
Q: Does Katherine Peel mean that interrupts should be disabled
during installation only or for the full duration of the new
vector?
A: Definitely during the installation only. If you leave
interrupts disabled almost nothing will work - including the
keyboard and certainly the GEM mouse.
To: Peter Hibbs
STYLE OF ASSEMBLY LISTINGS
==========================
Oh dear, and I have always thought that my way of writing was the most
readable that could possibly ever be :-). It goes to show that taste
is a very personal thing. Or as we like to put it here in Sweden:
Smaken
r som baken
- delad.
( In English: Taste
is like the behind
- divided. )
(Sorry about this piece of poetry, but I couldn't resist it.)
I am quite certain that my habit of writing register names in upper
case did not originate in my own twisted mind, but I am less sure of
from where I got it. The disassembled BIOS listing in the Abacus book
"ST Internals" is written in the same style though.
Back when, trembling and insecure, I wrote my first lines of assembly
code I found some comfort in this way of marking register names as
something quite different from mere memory labels etc. This was back
when I was still confused that "a7" could also be written as "sp".
Since then the habit has stuck, and I even often (as a kind of therapy
while collecting my thoughts) convert imported pieces of code to this
style, more familiar to me. I suppose you are right of course that it
must slow down my typing, but I have never reflected much on that.
Maybe it only slows down the speed of my typing to that of my
thoughts. I feel a need to put some thought in just about every line
of assembly code to ensure it's OK.
It had honestly never occurred to me that anyone could find this style
DETRIMENTAL to readability. Though - when thinking about it - it is
only natural of course for everyone to prefer what one is most used
to. So from now on I will start making sure that my assembly
contributions conform with the predominant style of all lowercase.
*/ Mrten, I didn't mean to imply any criticism at all, as you say
ones style of writing code is usually a matter of taste, I was merely
interested in your reason for using caps. I also use capital letters
for some parts of my code, i.e. assembler directives (MACRO, ENDM, IF,
ENDIF, etc) and object names (FORM_LIST, etc) mainly so that they are
easy to find when scanning through a listing.
You mentioned the PostScript language, I have bought a book on this
language with the same idea in mind but I soon found that it is
unbelievably complicated and I didn't understand much of it at all. It
is basically a language built into the file, for example, a PostScript
font is not like a Calamus font which just defines a set of co-
ordinates and simple commands, a PostScript font seems to be a mini
source code that tells the PS interpreter how to process the font data
to draw the character image. Any code you would need to write would
have to be an interpreter (like a BASIC interpreter) with about as
many commands and functions, no mean feat. If you would REALLY like to
see the book I would be prepared to lend it to you provided you are
willing to pay the postage charges to and from Sweden and it is quite
a heavy book, over 700 pages. PDH /*
----------------------------------------------------------------------
To: All
From: Peter Hibbs
In Ictari issue 9 I published a set of TOS Macros (TOSMACRO.S) and it
has just come to my notice that there is an error in the f_datime
MACRO that reads the date/time stamp on a disk file. The code should
be amended so that it reads as follows :-
f_datime MACRO 1\mode,2\fhandle,3\buffer
move \1,-(sp)
move \2,-(sp)
move.l \3,-(sp)
gemdos #87,#10
ENDM
I should point out that this was not entirely my fault, the source of
my information was the Atari Internals book which incorrectly shows
the second and third arguments reversed in the example code, hence my
error. I then checked the Compute! book volume 3, The Atari TOS, which
shows the arguments correctly but then states that the first word of
the buffer holds the date and the second word holds the time when it
is, in fact, the other way round. Next I looked at the Concise
Programmers Guide by K Peel (Aug 86) which also shows the wrong buffer
allocation and in addition has the flag settings reversed as well,
i.e. it shows 0 for set and 1 for read which is the opposite of the
correct values. The Atari Compendium, however, shows everything
correctly although it does not give any help to machine code
programmers. I think the moral of this sorry tale is DON'T BELIEVE
ANYTHING YOU READ IN A BOOK UNTIL YOU HAVE CHECKED IT YOURSELF.
----------------------------------------------------------------------
To: ICTARI
From: Theo Ros
Is there anyone who can explain how picture dithering is performed.
*/ I think this question has been asked before and nobody knew then
but if anyone does, write in soon. ICTARI /*
----------------------------------------------------------------------
To: Everyone
From: Owen Rogers
I'm afraid I've finally decided to hang up my mouse and move to the PC.
I like my programs to be used, not sit around in a PD Library so I've
bought MS Visual Basic for my PC. This is just a thank you to everyone
at Ictari for helping me finally release my first GEM program
MUSICBASE and really everyone I've talked to and who have helped me
(Including LAPD, Floppyshop and those great people who sent me those
STOS manuals). I don't think I've met such friendly and helpful
people than in the Atari community. Thanks again to everyone I've
known and met and especially to LAPD who were the only people who took
a 13 year old boy (me!) from the Welsh valleys seriously about
programming! If there is anyone out there who has one of my
programs that needs registering, don't bother!
So now in the words of Sooty I'll say..
BYE, BYE EVERYBODY
BYE, BYE
------------------------------ End of file ---------------------------
