Copy Link
Add to Bookmark
Report
Ictari Issue 30
ICTARI USER GROUP ISSUE 30 January 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 30
==================
ASSEMBLY ReStart TSR program.
XBRA Protocol information.
C Disk catalogue program source code.
GFA Mrten Lindstrm: An introduction to GFA programming.
BASIC Lottery program.
STOS Seapest game source code.
Tiny picture format loader routine.
MISC Cookie Jar list.
Mark Baker, SpeedoGDOS example code.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Saucers game.
Line drawing routines.
C SCSI Interface Library for C programmers.
GFA GFA Interface dialog utility program.
STOS Polygon demo program.
MISC SCSI Frequently Asked Questions.
Pexec function Cook-Book.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
Another new member has joined the group this month, welcome to him.
ENVELOPES
---------
As most of you will have noticed, this month I have printed the names
and addresses directly onto the envelopes instead of using sticky
labels which did not work very well. I am using the K-Data database
program to store the info (after several days work) and my Laser
printer to print the envelopes. As I have had to enter all the
information into the data base again, perhaps everyone could just
check that the addresses and postcodes are correct (that is assuming
you have received this disk in the first place).
DISK CATALOGUE PROGRAM
----------------------
In this issue Lee Russell has provided his disk cataloguing program in
C with a lot of useful information on the program structure. The
document files were provided in Protext format and we have left them
in this format to retain the text attributes, layout, etc. If anyone
needs an ASCII version of the files, just send a disk. (Incidentally,
the program does work OK in High Rez).
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: Anyone
From: Owen Rogers
About 3 weeks I decided to go out and buy Gfa Basic 3 for myself. I
knew how to program in STOS so I just read through the manual and now
I am on to displaying and using dialog boxes. I tried making a program
and the buttons on the dialog worked fine but I could not type things
into the editable strings. I used the following bit of code :-
form1%=0
comline%=1 ! EDIT
icon1%=2 ! ICON
gar%=3 ! STRING
oper%=4 ! STRING
icon2%=5 ! ICON
ru_ttp%=6 ! STRING
okay%=7 ! BUTTON
cancel%=8 ! BUTTON
~RSRC_FREE()
~RSRC_LOAD("F:\GFABASIC\RUN.RSC")
~RSRC_GADDR(0,0,tree%)
~FORM_CENTER(tree%,x%,y%,w%,h%)
~OBJC_DRAW(tree%,0,1,x%,y%,w%,h%)
REPEAT
ex%=FORM_DO(tree%,0)
UNTIL ex%=okay% OR ex%=cancel
~RSRC_FREE()
Can anybody tell me what I'm doing wrong? I use the ORCS resource
construction set.
----------------------------------------------------------------------
To: ICTARI
From: John Oakes
Could you advise me on which book I can obtain for Assembly 680x0,
with reference on how to construct or design a program.
*/ I have two books on Assembly, "68000 ASSEMBLY LANGUAGE PROGRAMMING"
by Leventhal (ISBN 0-931988-62-4) and "68000, 68010, 68020 Primer" by
Kelly-Bootle and Fowler (ISBN 0-672-22405-4) which are quite good but
neither are Atari specific. In issue 8 we reviewed 18 Atari books
which may also be of interest. Do you want to know how to program in
Machine Code from scratch or are you familiar with machine code and
want to know how to use it in the Atari environment, we may be able to
provide some articles for future issues on this subject if there is
any interest. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Mrten Lindstrm
10 sectors per track on PC's
----------------------------
I have always thought (and still do) that formatting standard DD disks
with 10 - rather than 9 - sectors per track is quite OK to do (giving
you 800 rather than 720 K). The data will rest as safely on the 10th
sector as on the 9th (unlike using more than 80 tracks). As is
exploited by some ST programs, there is actually even space for 11
sectors per track but this IS to push things a bit far, requiring you
to reduce the inter-sector space below recommended minimums and
risking problems with drives whose rotation speed deviates from the
standard 300 RPM.
However, trying to read the Ictari 27 disk on a PC gave me a shock!
The root directory looked OK, but when trying to open sub-folders or
reading the ICTARI.TXT file, it all looked like garbage. And all the
PC programs that I consulted told me it WAS! - Some of them even
helpfully offering to "repair" the disk by deleting a few directory
entries. (This was on a Windows 95 system with all the latest
Microsoft programs). But, hands trembling, inserting the disk in my
trusty old ST showed my everything was still OK. (Phew)
THE SOLUTION:
÷÷÷÷÷÷÷÷÷÷÷÷÷
After clearing the first byte - $F9 - of the FAT (I did the same thing
in both FAT copies) the PC too was smart enough to see what my ST knew
all along: the disk was OK.
(The FAT - File Allocation Table - contains information on how each
DOS data unit (called "cluster") on the disk is used for files and
folders. There are, for safety, two identical FAT copies maintained).
EXPLANATION:
÷÷÷÷÷÷÷÷÷÷÷÷
The first byte of the FAT is, on PC's, a media descriptor byte which
is $F9 for a standard 9-sectors-per-track DD disk. The following two
bytes are filled with $FF but ignored. On ST's all three bytes are
ignored and normally cleared (zeroed) when formatting, so the reason
they were NOT cleared on the Ictari 27 disk must ironically be a
misguided attempt by the program, used to format this disk, to make
the disk "PC compatible".
When the PC finds a cleared media descriptor byte, but apparently only
then, will it go back to the boot sector information (which is what
the ST always use) to find out how the disk is REALLY formatted.
(It surprised me that the PC was too stupid to try the boot sector
information even when realizing that the disk looked like a mess, read
as 9-sectors-per-track).
The theoretical problem would be if some DOS version NEVER uses the
boot sector information, but I think most or all DOS versions should
be at least this smart. Anyone with other experiences?
(An even better solution would have been a PC media descriptor for 10-
sectors-per-track disks, but, while a number of outdated disk formats
- single-sided 8-sectors/track etc. - are catered for, there doesn't
seem be any descriptor for 10 sectors/track. Atari evidently realised
the idea of media descriptors to be obsolete already at the time of
the first ST, since they never made use of it).
HOW TO DO IT
÷÷÷÷÷÷÷÷÷÷÷÷
The easiest solution is to avoid formatters that don't clear the first
byte of the FAT's. (Programmers of formatters: Always clear the first
three bytes of each FAT, unless formatting with 2 sides, 9 sectors and
80 tracks when F9,FF,FF could be used, or with 18 sectors on HD disks
F0,FF,FF). The second easiest solution, if you have an existing disk
with this problem (e.g. Ictari 27), is to use a disk editor (like the
excellent Knife ST from Hisoft).
If you don't have a disk editor that can help you find and edit the
correct sectors, then you can create your own little correction
program with the help of the BIOS function RWABS (BIOS 4).
RWABS(0,bufaddr,1,0,0) - will read the boot sector (logical sector 0)
of drive A into the buffer starting at "bufaddr". Make it at least 512
bytes (a full kilobyte won't hurt either).
From this, you can find the start sector of the first and second FAT:
First FAT: Read Intel word (i.e. read word and swap its bytes) at
offset 14. (In practice this will always be =1, but use the just
mentioned formula to be sure).
Second FAT: Read Intel word at offset at 22 and add to start sector of
first FAT. (You could check that the number of FAT copies - in byte at
offset 16 - really IS 2, which it should in practice always be).
Then read, change and write the start sectors of both FATS:
RWABS(0,bufaddr,1,sectnum,0) - to read specified sector on drive A
into bufaddr. Clear first byte (or first THREE bytes) of FAT, then
call:
RWABS(1,bufaddr,1,sectnum,0) - to similarly write the buffer contents
back to the same sector.
To: Thomas Nilsen
From: Mrten Lindstrm
Thank you for the ZIP deflate info!
NON-MODAL DIALOGS (= that don't put other processes on hold):
------------------
Regarding your question on how to display and use an AES object tree
(dialog box) in a window:
- Draw it with OBJC_DRAW, just as you would an ordinary ("modal")
dialog box, only you need to do it in response to a window redraw
event (after creating and opening the window) and in a loop, walking
through the "visible rectangle list" of the window (adjusting the clip
rectangle of each OBJC_DRAW call) - the way ANY clean drawing in a
window has to be done, in order to avoid overwriting other windows
that might be partially covering the window. The visible rectangle
list is returned by WIND_GET with modes 11 and 12.
- To handle it you cannot use FORM_DO, since this waits only for
button and keyboard events related to the dialog box itself and not
for window (or other message) events. Instead you need to write your
own FORM_DO replacement, centred on an EVNT_MULTI that DOES look for
message events. Button and keyboard events can be dealt with through
calls of OBJC_FIND, FORM_BUTTON, FORM_KEYBD and OBJC_EDIT (which are
used as sub-routines by FORM_DO).
See chapter 4 of my GEM GUIDE for an example of a FORM_DO replacement.
(You need to expand the EVNT_MULTI call of this to look for message
events too). See chapter 3 for how to handle AES windows in general.
(In Ictari 27 and 28).
The technique for implementing panels, tool-bars and -boxes and menus
in windows would probably be similar.
(Note: none of this requires anything more than the basic AES of any
bog standard ST. The AES of Falcons adds further functions to deal
with e.g. tool-bars in a slightly simpler way, but at the price of
abandoning backwards compatibility with ST's).
*/ When I format a normal disk (80 tracks, 9 sectors) I use the normal
Atari TOS (V1.04) which I believe formats in IBM format. If I have to
format a disk with 10 sectors I usually use ACopy which probably
doesn't use IBM format. I have also got FastCopy which I think does
use IBM format so I will look into this and try and make the disks IBM
compatible, are far as possible. ICTARI /*
----------------------------------------------------------------------
From: Jonathan Leckie
To: All ICTARI readers
Hello all, this is my maiden message (posting?) hmmmghh. I do some
GFA, and C and even less assembler and I would class myself as a
beginner so now you know about my frailties and you have lowered your
expectations I can start grovelling.
Question 1: Can anyone submit a set of working, time-served double
linked list handling routines written in C? I have written a set but
they, for an annoying and hidden reason, refuse to work properly. My
modules have the following mini. spec. :-
#define KeyType int
typedef struct {
KeyType key;
/* program specific data */
} StdElement;
typedef struct {
void *Next;
void *Prev;
StdElement Data;
} Node;
typedef struct {
Node *Head;
Node *Tail;
short NoInList;
} DblList;
BOOL DLFull (DblList *DList);
BOOL DLEmpty (DblList *DList);
void DLCreate (DblList *DList);
BOOL DLAdd (DblList *DList, Node *Nod);
BOOL DLDelete (DblList *DList, int ListPos);
BOOL DLTerm (DblList *DList);
StdElement *DLRetrieve (DblList *DList, KeyType Key);
A set conforming to it would be useful, though "beggars can't be
choosers" as my great aunt Nellie used to say.
Question 2: I read a while ago in Atari World about a program called
"UDO" that converted TeX, HTML and RTF formats I haven't heard any
more of it, any ideas if it exists and where I can get it?
Question 3: Is there a HTML viewer that views HTML files properly. I
have HTML-Viewer 0.93 but it does not cope properly with some HTML
ver. 2 commands or simple text effects (</B>bold<B>, </I>Italics<I>).
I don't have even a partial 'Net connection so programs that only
work with one will be no use. Any further ideas?
You can send stuff to me by E-mail but it will take at least 3 days to
get more than a perfunctory reply because it is my friend's address.
E-mail: com40020@diana1.paisley.ac.uk
*/ If you track down the text file conversion program, I would be
interested in having a copy. I get all sorts of text files from the
Public Domain which need to be translated into ASCII.
Since the ST Applications magazine transferred to disk they have
provided HTML V0.96 on each disk, perhaps this version does not have
the problem of V0.93, I've had no problems with it myself. ICTARI /*
----------------------------------------------------------------------
To: Michael Harrop
From: John Watson
Thank you Michael for your generosity, received the GFA 2 Manual and
disks, a letter is on its way (if not already there !).
To: Mrten Lindstrm
I thank you for your informative reply in issue 29 regarding the
differences between versions 2 and 3.X of GFA Basic and your worthy
comments on the Pro's and con's of Programming Languages in general.
I started programming in Microsoft Basic on a 64K MSX and have ported
the same programs to ST Basic and on to GFA, gradually enhancing them,
and learning as much as I was able to, of each variation as I went
along. As I still have a lot to learn, I unfortunately do not feel
like attempting another language. I just can't seem to grasp the
syntax of C (all those Brackets !), though the structuring of programs
necessary in C is a very good aspect.
GFA is also very good on structuring i.e. not allowing jumps out of
Loops or Procedures with the dreaded GOTO......
I try to keep to a style of Structured Programming that I learned from
a book by Mr Peter Bishop published in 1984, his ideas termed Top Down
Stepwise Refinement entails writing in plain English the objectives of
the program. Then working up each part into more and more detail until
the Code itself is written.
To: *.*
Does anyone have or is compiling a GFA Function, Procedure library or
a common Naming convention for program Variables, Constants, Etc. I
believe that the GFA User group has produced one. There is also the
GFAXPERT.LIB by Han Kempen (which I have).
Over the years I have developed (or should I say plagiarised) my own
very small collection, which is available to anyone interested.
*/ We also would be interested to hear about any specialised libraries
for GFA (or any other language). ICTARI /*
----------------------------------------------------------------------
To: David Seaman
From: Jason Railton
Re: STOS Stock Controller listing
I tried running your Stock Controller and it wouldn't work. You use a
STOS extension I don't have about 46 times. When I list the program I
get the words "extension #M" (The MISTY extension, I presume?) in
place of certain commands. Unfortunately, all I have is the STE
extension - I don't have an STE, but I occasionally use the twin-
joystick reading functions.
Sorry I can't test the program for you. In future though, could STOS
users state what extensions they've used in the documentation. I try
to avoid them whenever possible, but that's because I like to write
machine code routines and load them into STOS to perform specific
functions.
To: Peter Hibbs & Everyone Else
Re: STOS stuff
Hopefully this disk should contain some STOS programs from me. I sent
them in last month, but because Mssr. Hibbs is so disarmingly well
organised, last month's disk was already prepared and chock-a-block
full and I've had to wait another month to see my name in phosphor.
Anyway, they were a bit rushed, so here's a bit more information in
addition to what you'll find in the .DOCs.
Sea Pest: Sorry. One of the symptoms of rushed code is dispiritingly
poor titles. Anyway, I read a letter from David Seaman in Ictari #28
asking for more STOS code, so I wrote this Minesweeper variant over
the next few evenings. It's a bit slow when run from BASIC, but is
quite playable when compiled. I don't know if you'll get the compiled
version as well as the source code, since it is a fairly large .PRG.
If you do, then you won't need STOS in order to run this. I've only
programmed in the basic game mechanics. Feel free to embellish it
with titles and scoring, and send it back in to ICTARI. The listing
is heavily commented to explain what it does.
Polydemo: This was only provided as a compiled program. It'll
probably appear in the STOS section, but have a look at it if you're
into machine code. It's only based in STOS because it's incomplete. I
want to eventually get the routines working in stand-alone code. Then
again, I might stay in STOS and just convert more and more into
machine code as I need to. I've since improved the routine to provide
more stipples for a much better graduated fill, and improved the
intersection and depth clipping functions. */ See next month for this
one. ICTARI /*
I intend to write a few articles on how the fill routines work, but
I'd like to know from Peter Hibbs what he can fit on the disk. These
articles would be irregular, since I don't always have a lot of time
to put things together. Anyway, the graphics routines are of interest
to the machine code programmer, as well as the STOS programmer.
Unfortunately, they are written as m/c subroutines for use in STOS,
not as runable .PRGs. I can provide the assembly source code, and a
STOS listing (containing the m/c in a memory bank) to demonstrate the
process, but would there be room for the compiled (stand-alone)
version of the STOS demonstration, for m/c programmers? These can run
to around 70 or 80K, as you can see from PolyDemo.
To: Machine Code programmers
Line-drawing routines
~~~~~~~~~~~~~~~~~~~~~
I would be grateful for any fast line-drawing source code you can
provide me with, or tips on how to write my own. I need to write some
very fast, customised line-drawing routines to improve my 3D graphics.
All my lines are clipped, and I have already written a routine to plot
lines in the vertical-->45' range. What I need is a fast 45' through
to horizontal line plotter.
Reading the mouse
~~~~~~~~~~~~~~~~~
Has anyone written a m/c program using both rasters and the mouse? Or
read the mouse in ABSOLUTE mode? I presume I need to use this mode so
that I can interrogate the mouse, rather than having it occur on
interrupts (which disturb the rasters). Incidentally, I don't want a
pointer on screen. It's for control in an arcade-type game. What
settings are appropriate for the mouse scaling factors in this mode?
What is the normal scale setting, or the one that best relates to the
standard mouse movements?
Running from STOS
~~~~~~~~~~~~~~~~~
Has anyone tried running a machine code program in STOS that disables
STOS interrupts/keyboard/mouse handling, installs its own, then later
restores them and returns to STOS? Or am I being too ambitious? I'd
just prefer to keep my games running from within STOS because it's
easier to write title/high score pages in it than in machine code. Or
can STOS programs be loaded/run/communicated with from a machine code
program?
I gather from the manual that STOS establishes its own traps, but does
not in any way affect the existing OS traps.
Writing STOS extensions
~~~~~~~~~~~~~~~~~~~~~~~
Anyone tried this? How do you do it? Or would anyone like to turn my
3D graphics routines into an extension for me?
*/ I agree entirely that contributors should provide as much
information as possible about any supplied source code, especially
extensions used, library files used, etc, etc. I know that this can
sometimes be very time consuming and boring but it does save the end
user a considerable amount of time and frustration when trying to use
the code. I would like to see a text file with the source code which
explains what the code is supposed to do and how to use it with some
simple examples, this would help me when compiling these disks (I
can't try all the code sent in) and it would help anyone who wants to
use the code.
I would be very interested to publish your graphics fill routines (and
any other stand-alone routines in any language for that matter). What
I would prefer (although I appreciate that it's not always possible)
is to have a stand alone runable program also supplied which
demonstrates the operation of the routine. This allows anyone
interested in the code to try the program first to see if it covers
the area of programming in which they are interested. The programmer
should make the program as small as possible (so that it does not
waste too much disk space) and, if possible, should also supply the
source code of the program itself so that potential users can see how
the relevant routines are integrated into a working program.
I will try and include some line drawing routines on next months disk.
These are not particularly fast but could be modified or improved,
obviously the fastest way to draw a line is to use GEM with NVDI
running but I guess that is not an option under STOS.
To read the mouse information direct I think you would have to access
the keyboard CPU. There are various books which cover this subject,
has anyone written any code to do this?
Writing STOS extensions is not easy, perhaps Martin Cubitt (who has
written some) can help! ICTARI /*
----------------------------------------------------------------------
To: David Seaman
From: David Preston
STOS Extensions Survey
I'm intrigued by your disapproval of the Squasher. I've used the
squasher quite a lot - mainly for screenbanks - without many problems.
It seems to work ok and achieves pretty good compression ratios.
Alright it takes an eternity to squash a file in the first place, but
once squashed it usually produces a very compact file which
uncompresses quickly and easily. It has run riot once or twice when
I've passed duff parameters to UNSQUASH, but other than that no real
problems. Is there some nastiness I've missed? The Stars extension
however crashes my compiler - is there anything I should know?
Stock Controller
I know I'm a bit dim, but I couldn't identify the problem to which you
referred in the readme file. Could you perhaps expand upon the
problem?
To: Mrten Lindstrm
Yes, thanks, I did realise you meant both slider and 'track' were
TOUCHEXIT objects. I was gobsmacked to say the least when I got the
slider to actually slide, it's small things like that (I find, at
least) that make programming the enormously rewarding hobby it is. But
I digress. I now find I'm stuck on something else - I'd like to redraw
part of a dialog - one object and all its children. As I understand
things, I do this by calling objc_draw, referencing the parent object,
but I need to know its x and y co-ords, and its width and height. I
think I can use objc_offset to establish its x and y position, but I
seem to recall reading somewhere that the width and height have to be
read direct from the object structure. Am I on the right track so far,
and can you offer any advice? Thinking about it as I write, this would
probably also be involved in the process of changing the size of the
slider to reflect the proportion of the items displayed, say, in a
file selector, to the total number of items in the directory,
probably...?
----------------------------------------------------------------------
To: *.*
From: Peter Hibbs
Does anyone know anything about Terminate-and-Stay-Resident (TSR)
programs. In the near future I want to write a program which can be
called from within any GEM type program (in the same way as ImageCopy
or Mortimer do) with a particular key combination. The program would
then need to be able to display a GEM dialog box, load/save to disk
and output data to the printer (parallel) port. As you can see, I have
included some TSR source code in the Assembly folder this month which
is quite helpful but this program is very simple, are there any
problems which might appear in a more complex program. I haven't tried
writing any code yet but if anyone has had any experience of writing a
TSR program, I would be very interested to hear about it.
------------------------------ End of file ---------------------------
