Copy Link
Add to Bookmark
Report
Ictari Issue 29
ICTARI USER GROUP ISSUE 29 December 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 29
==================
ASSEMBLY Jaguar Pad interface routine.
SpeedoGDOS functions MACRO reference guide.
C Lasso function code.
Incremental circle generator code.
Application skeleton code.
GFA GFA Patch program.
Slider puzzle game code.
USA map game code.
STOS Stock controller program.
ACC loader program.
STOS Extensions survey.
STOS fix program for the TT.
MISC Mrten Lindstrm, GEM Guide. Part 5.
ZLIB and Deflate compressed data format information.
Ralph Lovesy interview.
GEM Bitmap font file format.
MODEM programming and MODEM comparison guide.
Atari Compendium correction list.
XAcc GEM communication protocol specification.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY
C Disk catalogue program source code.
GFA Mrten Lindstrm: An introduction to GFA programming.
BASIC Lottery program.
STOS Seapest game source code.
Polygon demo program.
MISC Cookie Jar list.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
We have had four more members join this month with a couple of other
enquiries, welcome to them. Just a reminder to new members, we would
prefer text files sent in Protext format, if possible, if that is not
possible then plain ASCII is fine. Also, when sending a disk for next
months issue, please include a letter for the correspondence section.
Ask a question, answer a question or just say what you want to see in
ICTARI, and we still need more articles for next year.
SpeedoGDOS ARTICLE
------------------
Unfortunately Mark Baker has not had enough time to complete the
SpeedoGDOS article for this months issue so it will appear in the
January issue (hopefully).
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: John Watson
From: Michael Harrop
John, you say you have only the PD version of GFA BASIC, well I have
both V2 and V3. I don't use V2 now so if you would like the original
manual for V2 let me know, my address is in the MEMBERS.TXT file or if
you have INTERNET access you can E-MAIL me at:
100025.2357@compuserve.com
----------------------------------------------------------------------
To: ICTARI
From: Lee Russell
Subject : Dave Richards' Database Program
I was encouraged to see Dave Richards' database program on the latest
ICTARI disk. It proved to me that programmers of all levels are
members. I was starting to get the impression that only people with a
full knowledge of GEM, GDOS in all its disguises, C, Assembler and
advanced cryptography were in the group !
Dave's letter has prompted me to submit my code for a disk catalogue
program I wrote in '92. In many ways the code is not an example of
good GEM programming practice, but it works. Hopefully it may help
other budding C programmers to make a start with GEM.
*/ See next month for the source code. ICTARI /*
----------------------------------------------------------------------
To: Mrten Lindstrm
From: Thomas Nilsen
ZIP deflation/inflation.
------------------------
I have ftp'ed the ZIP-docs from ftp.uu.net/pub/archive/zip/doc as you
wanted in last issue. Hopefully there is space enough to include them
on ICTARI issue 29. The files are named DEFLT1-1.DOC & ZLIB3_1.DOC.
Enjoy em! */ Thanks for the info. See /MISC/DEFLATE/ folder. ICTARI/*
To: Ictari
Well, the ICTARI bulletin is now on-line! It did take a bit more than
a week to complete the task, but isn't that normal? Not all things
turn out the way they are planned... Anyway, lets hope some of
the Norwegian programmers will join Ictari as well.
I will hereafter make the ICTARI issues available on my BBS together
with one of the more interesting items from the issue, with a request
to become a member of ICTARI to get the complete issue every month.
What about taking it even further. As my BBS is connected into the
two major ATARI networks, NeST and ATARInet, I could post parts of
each issue in the programming conferences together with the
information on registration. There are a lot of users around in
the programming conferences.
Now for my programming-question last month. I guess I didn't quite
explain myself well enough. What I meant with using an RSC from
within a window was basically how to display an RSC-TREE (ie. a
FORM with boxes, texts, etc) within a window, so that it is
capable of multitasking (at least in theory). But I would, of
course, also be interested in displaying a menu inside a window,
though I believe this is achieved by setting a bit in the
windowtype, more or less. So if anyone has ever done this before, I
would very much like to know!
To: Ictari
DSP Modem.
----------
When ATARI first released the Falcon one of its selling points was
that it would be capable of emulating a highspeed modem using
software. Well, during the three years the Falcon has been on the
market, no such software has been developed, at least to my
knowledge. I have heard various rumours that HiSoft did a prototype
of a DSP Modem, but found it too expensive to complete it. I have
also heard other rumours about single souls trying to make this kind
of software, but it's all rumours. Anyway, now I'm a bit tired
of all these rumours and therefore I am thinking of developing the
software myself. But this is probably going to take more than one mans
time to finish off, so I am looking for other Falcon coders to assist
me on this project. I will also need information on the various
Modem standards. So if anyone wants to join, or have information
about this (or know how to get such information) I would very much
like to hear from you.
To: John E Nicholls.
Regarding your plea for help in the last issue, I would suggest you
try out STOS or GFA Basic v3. I myself started programming in STOS
and I learned a lot from it. STOS is best used for programming
games and the like, and if you are to develop a shell for text
adventures I guess STOS is more than adequate. But, if you are to
go for more serious programming GFA Basic v3 is the only usable
choice when it comes to Basic programming. C is also a good
programming language, but with no prior programming knowledge I
suggest you learn the basics of programming first. C can be
quite difficult for a newcomer to understand, and learn.
I believe ST Format is selling the complete GFA Basic v3 package, with
compiler and manual. GFA Basic is quite easy to get the hang of as
soon as one learns how it's structured, and I would definitely
recommend it as a first time programming language.
*/ Feel free to distribute some of the ICTARI articles around the
networks, the more publicity we can get the better. Good luck with the
DSP/Modem project, can anyone help. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Adrian Lovatt
Has anyone got a list of the VDI function numbers available to
SpeedoGDOS, I would like to write a subroutine library in HiSoft
BASIC2 but don't have the calling conventions.
*/ The book Modern Atari System Software from HiSoft lists all the
SpeedoGDOS functions (Chapter 8) in C, Assembler and BASIC format but
with very little information on how to use them. A list of the
Assembler calls is given in the ASSEMBLY\BEZMACRO folder this month
which may help (if anyone can provide more detailed information with
some practical examples on how to use the functions we would be very
interested). If you haven't got access to this book we could probably
send you a photocopy of the relevant pages (let us know). Also Mrten
Lindstrms GEMGUIDE article this month covers some of the SpeedoGDOS
calls. ICTARI /*
----------------------------------------------------------------------
From: Jason J Railton
To: Everyone
*** ME, FALCON AND MONOCHROME ***
Well, you may think I'm new to ICTARI, but I'm not. Some of you might
remember me as 'Falcon' from the first few issues - I sent in loads of
STOS stuff, although I don't know if my digital rotation demo ever got
distributed. No? Don't remember me? Oh well...
If anyone out there remembers me from the Monochrome bulletin board at
City University, or from Loughborough, get in touch. For those who
haven't heard of Monochrome, it's on telnet 138.40.17.1 - I think.
I'm not sure because I haven't had access for months now. I'd
appreciate it if someone could pass on some messages from me to people
I knew (if they're still on it).
Well, I've left University and got a job, so now I'm living in
Gosport, the other side of Portsmouth harbour to Portsmouth. Anyone
nearby?
I've sent in two programs to ICTARI; one STOS game (SeaPest) and a
graphics demo (Polydemo). I hope Peter can fit them on the disk...
Go on Pete, cram them in there...
Plenty of room...
Please put a document displayer on each disk, it would be useful.
Cheery-bye for now. Have fun.
*/ Sorry, there wasn't enough room, I do compile these disks a month
or two in advance. I'll include them on the next couple of issues. I
have considered a document displayer for the disk in the past but
decided against it because it would take up valuable room each month
and I think everyone will already have their own favourite editor, WP
program, etc which they would prefer to use anyway. ICTARI /*
----------------------------------------------------------------------
To: John E Nicholls
From: Pete Bailey
I can't really improve much upon Peter Hibbs' comments in the last
issue, but would like to add a thought or two of my own. It's tempting
to say that C isn't a suitable first language for a beginner, but I'm
not sure that it's necessarily true. It's one of those languages that
you can either cope with or you can't - I know at least two
professional programmers (workmates, in fact) who, though thoroughly
competent in various Basics, simple cannot get their heads around C.
In fact I suspect that previous experience in Basic may even make it
harder to learn C! What I'm trying to say here is don't be afraid to
give it a go - but don't expect it to be easy. I think it would be
reckless to blow 70+ quid on Lattice, though; more sensible, I think,
to try Sozobon first and see how you get on with it. It costs nothing,
and works well - the only bugbear is setting it up and getting to
grips with how to make it do something useful. If you want to pursue
this, then I'll be very happy to help on that front.
Of the other languages you mention, the next best choice would be GFA
Basic in my view. I'm not a regular Basic user myself, but I have
looked at most of them at least once and GFA was the flavour that
impressed me the most. Very capable, and very fast, even when running
interpreted code (I think there's a separate compiler available -
correct me if I'm wrong someone). In C's defence I would just add that
the language is powerful, flexible, expressive and the next fastest
thing to assembler; but you are perfectly correct in your comments
regarding portability. Although it is, in principle, perfectly
portable, the differences in header files and libraries between the
various versions makes porting software for real quite a nightmare. I
recently switched from Sozobon v1.something to the latest Sozobonx -
even between different versions of ostensibly the same compiler, the
changeover gave me headaches (literally) for a week. Oh, and as for
Hisoft C - it's wet, misguided, ill-conceived and I wouldn't touch it
with a barge-pole of any length whatsoever. Just my personal
prejudice, you understand!
To: Dave Richards
The answer to your prayers, Dave, is... Malloc. Where you've defined
struct database { ... } address[MAX], define struct database {...}
*address instead. This gives you a pointer to a structure, but doesn't
reserve any storage for it or carry any implications as to its size.
Now before you can use it, you need to reserve some storage and then
make your pointer point at it. There are C library functions to do
this, but my personal preference is to call Gemdos functions directly
(I'm not interested in portability). One way to do this might be
something like:-
unsigned long maxmemory;
maxmemory = Malloc(-1L); address = (char *)Malloc(maxmemory);
The first call to Malloc passes a longword of -1, which causes Gemdos
to return the size in bytes of the available free memory. The second
call then uses this value to hog the lot, and sets address to point at
the start of it. I'm not sure whether Gemdos ever returns an odd
address, but I usually like to check and add 1 if it is just to be
safe. Purists might also object that this kind of memory-hogging is a
bad idea (well it is, I can't deny it); in that case, just decide on
some sensible maximum size and Malloc that much rather than all of it.
Remember also that, if you pretty the program up with a Gem interface,
then Gem will need some breathing space. As far as accessing your
database in memory goes, you shouldn't need to change much (I'm sorry,
I don't have time right now to go through your code in detail).
Remember that, when you define an array in C (eg address[MAX]), you
don't *have* to treat it as an array all of the time. The array name
(address) is in fact evaluated as a pointer, and the brackets act as
an operator which add the bracketed value to the pointer to form the
address at which the array contents will be stored or retrieved.
Consequently, while the normal (sane) method of accessing an array
would be address[n], it is in fact perfectly legal to write n[address]
which evaluates to exactly the same thing. But don't go showing such
code to anyone else unless you enjoy being laughed at. (A less
laughable variation would be *(address+n); think about it - it's still
the same thing!) Anyway, the upshot of all this is that, even though
you've changed your original array into a pointer which isn't even
initialised until run-time, you can still reference your database with
expressions like address[n].name and so on - the pointer acts just as
though it were an array name, because essentially they're the same
thing. Irrespective of how much memory you grab, by the way, you can
calculate the maximum number of database entries (ie array elements)
by: maxmemory/sizeof(struct database). As regards the graphical
interface - go for it. If you have a resource editor, use that and
learn about the AES; if not, hand-roll your own graphical interface
using VDI calls. It's more tedious, but it's a good way of learning
about the VDI.
----------------------------------------------------------------------
To: *.*
From: Mrten Lindstrm
Inspired by the general GDOS interest in Ictari recently, I at long
last made the decision to part with the money for NVDI 3, and actually
received it before I got the FontGDOS that I ordered some weeks before
it. Experimenting with both NVDI 3(.02) and FontGDOS has taught me a
number of things about beziers and outline fonts that I wasn't
previously aware of, and I have tried to include them in chapter 5 of
my GEM Guide. (I only hope that our wonderful editor has managed to
get it on this disk, since I sent it in a bit late, I think).
One further thing I have learned is that, although in the beginning,
all GDOS implementations - including NVDI - could use the same
drivers, this seems to no longer be true, and each GDOS now must be
supplied with its own drivers.
To: *.*
Last month I said that a slider is a touchexit box within an ordinary
box - the slider bar. I hope that everybody, who read this, realized
that the bar too would normally be made a touchexit object, in order
to facilitate "paging" when the user clicks on the bar above/below the
slider. Since FORM_DO only returns the exit object number, and not the
mouse position, you would have to make a call of GRAF_MKSTATE in order
to establish whether the bar was clicked above or below the slider (or
else write your own FORM_DO).
To: *.*
Does anyone have Gemini, the shareware Desktop replacement, and is
willing to share the info on an "AV protocol" (for communication
between main program and accessories) that I have heard should be in
its documentation?
To: Pete Bailey
Hello and thank you for the praise. I have so far not done any real C
programming myself, since I've been too parsimonious to pay for a
commercial C and too cowardly to try a PD C. But I am considering to
join the Sozobon gang.
To: John E Nicholls
What programming language to choose
-----------------------------------
You seem already to have found your main choice to be between GFA
Basic 3 and a some C package (of which Pure C and Lattice C probably
are the top two, at least judging from their prices). And as long as
your object isn't pure "games programming" I think that you probably
have made the right selections thus far.
"Games programming" for this purpose means any machine-specific
programming where SMOOTH AND FAST SCREEN ACTION is the all-important
aim, including e.g. flight simulators, animator programs etc. But the
strategy/adventure type games that you (and I) are interested in, are
actually on the borderline to "serious" programs, I think, in the
sense that they wouldn't lose much from making COMPATIBILITY the main
objective instead. Though most commercial offerings have shunned the
compatibility of GEM, ostensibly in favour of smooth animation, I
cannot see what a game such as Civilization would have lost if made
100% GEM. (Certainly nothing in its humble animations).
STOS is a language squarely for games programming, i.e. if compatibi-
lity is of no concern. In addition, although equipped with an arsenal
of truly impressive functions and utilities for swiftly putting a game
together, at its heart and foundation resides a horridly ancient and
unfriendly Basic. Just looking at its LINE NUMBERS gives me the
creeps.
For "serious" (i.e. compatible) programming some modern high-level
language is easiest to use, and there ARE other alternatives than GFA
Basic and C, including the Hisoft Basic as well as Pascal (e.g. I
understand Pure Pascal to be a very powerful Pascal implementation)
and Modula 2. Without really knowing that much about them, I have how-
ever got the impression that they all fall somewhat between the stools
of GFA Basic and C. Neither being as instant to use as GFA Basic, nor
as completely dominating the serious programming world as C. (Of
course, the situation could be different for those somehow given easy
access to /experience with a certain language - e.g. at work).
Assembly programming, finally, can be used for ANYTHING. It is what
HAS to be used whenever optimal speed and/or compactness is needed,
since no compiler of any high-level language is nearly as intelligent
as an assembly programmer. (Converting from compiled code to assembly
can often increase speed several times). For top-of-the-range games
programming there are thus no alternatives. Assembly programming IS
slightly more difficult than high-level programming though (in spite
of the Motorola processor being more programmer-friendly than some,
and assembler macros giving a high-level "touch" to assembly). Above
all, it offers more opportunities for bugs than high-level
programming. And, for general purposes, assembly programming could be
a complement rather than an alternative; any good high-level language
should allow you to include assembled code in your program, to replace
those high-level routines that you have found to execute too slowly.
(ST users who need an assembler, try to get hold of the June 93 cover-
disk of Atari User, containing the complete Devpac 2. Users of Falcons
and TTs must pay for Devpac 3 which, apart from supporting all
Motorola processors, does also provide a better shell and editor but
otherwise doesn't add that much to Devpac 2).
---------------
Since I have some experience of GFA Basic 3 and also (without real
experience) know a little about C, I will try to summarize the pros
and cons of each.
GFA Basic 3:
+ Interpreted language (with compiler too). Meaning much less
time between error correction and seeing the effect of the
correction.
+ Intelligent editor, automatically changing letter case to
distinguish recognized GFA Basic key words from variable
names, correcting some syntax errors (and letting cursor point
to others) and - not least - adjusting indentation to reflect
loops, IF-blocks and function/procedure definitions, instantly
revealing missing ENDIF's etc. (On the down side, the editor
is non-GEM and single-document).
- It is a Basic, meaning a non-standard language.
- A few of the system functions are built in to GFA Basic
commands, complicating references to TOS documentation. (See
the start of my GEM Guide - in Ictari 25 - for an attempt to
relate GFA graphics commands to VDI functions).
- Variables do NOT have to be declared before use, meaning a
natural opportunity for error checking is missed. (Though the
editor can be made to watch for new variable names).
- Names cannot be defined for constants (only for variables).
GFA Basic programs are all-in-one, and there are no separate library
files, which for small programs is adding to the instantaneousness of
GFA Basic (I would imagine those without a hard disk in particular
appreciating this). There are no paths or environment variables to
worry about, just run the GFA Basic interpreter and start programming.
But for a larger project it could perhaps become a bit unwieldy not to
be able to split it into several files. (On the other hand programs of
monumental proportions - Papyrus was mentioned here in Ictari - have
been produced with GFA Basic).
C (and C++):
+ The completely dominating language in the serious programming
world (on all platforms) assuring a wealth of source code and
general support from fellow programmers. (Without really being
a C programmer myself, I still have found it necessary to pick
up some C knowledge just in order to read source listings -
translating to assembler or GFA Basic).
+ Pointers not only to data but to sub-routines (functions) -
effectively making it possible to pass a function as a
parameter to another function.
+ "Structures" (similar to arrays but with elements of MORE THAN
ONE TYPE, referenced by names instead of by indexes).
(In GFA Basic this has to be achieved with arrays, accessing "non-
standard elements" via pointer operations: {V:x(...)}).
- Not possible to run in interpreted mode before compiling. (I
understand the Hisoft C interpreter to be more of a tool for
learning than for serious programming).
- No true string variables (but strings can be implemented as
byte-arrays).
The syntax of C is very compact, partly thanks to heavy use of braces,
brackets, parentheses, asterisks and other characters and character
combinations where other programming languages use keywords and
functions with NAMES in English. And partly thanks to such legendary
combinations as x++ which if used in an expression will FIRST cause
x to be read and used in the expression and THEN ALSO increased by
one. Or to x+=2 which is equivalent to x=x+2, x-=y equivalent to x=x-
y etc. This compact syntax can be regarded as an advantage but also as
a disadvantage, making C more difficult to read, especially to a
beginner. (Mean people have called C a Write-Only Language).
C also has a way of allowing things otherwise only possible with
assembly. In fact I get the impression that the main idea of C was to
make it "as low-level as any high-level language could be".
Example: C allows access of arrays outside their declared range.
Of the above pluses and minuses some are more significant than others
of course. In short:
The strong-point of GFA Basic is its INSTANTANEOUSNESS. Instantly
start programming, instantly see many of your errors pointed out by
editor and instantly try interpreted program.
The strong-points of C are, I think, in order of importance: (1) its
popularity = support (including well-made programming packages I
presume). (2) A flexible programming environment, better suited than
GFA Basic for LARGE projects (though other languages have this too).
(3) Capability to do some low-level things, most importantly the
passing of (pointers to) functions as parameters to other functions.
(C++ adds further advantages of course, but the only Atari C++ package
that I have seen is the public domain GNU C++, requiring 4MB of memory
and a hard disk).
To: John Watson and any other users of GFA Basic 2
From: Mrten Lindstrm
GFA Basic v2 vs v3
------------------
I am afraid that all GFA Basic related references and material that I
have contributed are for version THREE. Apologies for that, and for
perhaps not have made this as clear as I should have done, but v3(.04)
was the version that I first purchased and the only version that I
have really used, and I wasn't until now aware of quite how big the
difference is.
I do have a v2 lying around too (got for free from somewhere) and on
reading your message I tried to load a few of my v3 listings into
this, but frankly was surprised by how little of it that was accepted.
(You may already have performed this experiment for yourself?)
Improvements have been made to the editor of course. Although still
looking much the same and still single-document and non-GEM, a GEM
menu with the GEM accessories can be reached. And among other things
there is now a "procedure folding" feature to give better overview.
And the execution speed is boosted.
But, again and most importantly, the language itself is very much
improved from v2 to v3 of GFA Basic. Here are the additions in roughly
the order of (my view of their) importance:
+ The INLINE command, allowing assembly routines (and various
data such as built-in GEM resources) to be incorporated in
program.
+ Multi-line FUNCTIONs can be defined.
Plus the parameters passed can - with a keyword VAR in the
procedure/function definition - be the variables themselves,
rather than their values, ALSO allowing ARRAYS to be passed
(not possible at all in v2, except through pointers).
I find these two features (in particular the latter one)
invaluable as they allow the definitions of new functions/-
procedures that can be called JUST AS NEATLY as the built-in
ones. (With v2 you'd have to use global variables and pointer
passing as a substitute, but it wouldn't be nearly as neat).
+ Integer size can be WORD (16-bit) and BYTE (8-bit), and not
only LONG (32-bit) as in v2. (In addition to saving some time
and memory, allows use of WORD ARRAYS for VDI raster MFDB's
and other OS structures, the way they are internally handled
by the OS).
+ Much improved means of handling pointers (effectively removing
the need for PEEK, POKE and the unary * operator, and again
allowing neater syntax).
+ All AES functions (except the newest ones) built in to
language, using the standard format (simplifying comparison
with sources in other languages). A few VDI commands are
similarly added. (All the GFA-specific commands based on VDI
and AES calls are still there of course).
Syntax for making low-level GEM calls (to implement the
functions not built in) also improved.
+ Lots of other new commands and functions (including a number
of integer-specific functions for faster execution and -
amazingly - built-in commands for shell sorting and quick
sorting arrays).
There are probably ways in v2 to work around many of its limitations.
For instance, there is no function in v2 to inquire the existence of
GDOS, but - after thinking for a while - I realized that one could be
implemented through the following procedure:-
PROCEDURE vq_gdos
LOCAL s$,a%
s$=MKL$(&H70FE4E42)+MKI$(&H4E75) !Hexadecimal codes for Motorola
a%=LPEEK(*s$)
LPOKE gdos%,C:a%()
RETURN
which would be called with
@vq_gdos
after which gdos% could be evaluated. (If gdos%=-2 then NO GDOS there,
if MKL$(gdos%)="_FNT" then FontGDOS, if MKL$(gdos%)="_FSM" then
SpeedoGDOS or similar and otherwise old GDOS there).
To possibly help you translate v3 code back into v2 here are a few
further explanations:
{addr%} corresponds to LPEEK(addr%) or LPOKE addr%,...
WORD{a%} (or INT{a%}) correspond to DPEEK(a%) or DPOKE a%,...
Thus the AES version number, which I said in chapter 1 of the GEM
guide could be accessed with INT{{GB+4}}, can also be accessed with
DPEEK(LPEEK(GB+4)).
V:a$ gives address of string, also accessible with Lpeek(*a$).
V:a%(0) gives address of first array element (0) <=> Lpeek(*a%())+4.
V:a%(0,0) - " - (0,0) <=> Lpeek(*a%())+8.
etc.
V:a% is identical to *a%.
~function(...) is another way of writing VOID function(...)
Access of the elements in the GEM arrays can in v3 be done with e.g.
ADDRIN(2)=a% corresponding to LPOKE ADDRIN+4,a%.
VDISYS x,y,z is same as DPOKE CONTRL+6,y
DPOKE CONTRL+2,z
VDISYS x
VDISYS x,y,z,w is same as DPOKE CONTRL+10,w
VDISYS x,y,z
But, all in all, if I had only got GFA Basic 2 and were serious about
it, although I am a parsimonious devil I would really consider an
upgrade to v3(.5).
*/ Another consideration when choosing a programming language is
platform portability. If you might want to transfer your masterpiece
to another computer system (say a PC) at a later date I think it would
be unwise to choose GFA Basic and definitely not machine code.
Presumably C would be OK providing the program was not too hardware
specific and HiSoft BASIC 2 (according to Jon Ellis in Atari World) is
directly compatible with Microsoft Quick Basic on the PC. It would be
interesting to know just how compatible these Basics are since there
are a number of good programming books available for Quick Basic, if
anyone has any info, please let us know. ICTARI /*
----------------------------------------------------------------------
To: Lars Andersson
From: David Preston
Re- STOS on a TT030.
A couple of points -
1. I think STOS V2.6 is the latest (and last) version, although if
anyone knows otherwise...
2. The answer to running STOS on the TT _may_ be BASICMJH.PRG, which
was included on the cover disk with ST Format #41. The accompanying
text file suggests that it could cure your problems. (The text file
makes no mention of it being copyright or anything so I have enclosed
both files as they appeared on the cover disk, in the folder
STOS_FIX). As I understand it, this will only get STOS running, any
completed compiled program files you produce will need to be fixed
themselves if you are to run them on the TT. There are utilities
available to do this for you, try any good PD library.
*/ See folder STOS\STOS_FIX. ICTARI /*
----------------------------------------------------------------------
++ And finally something to think about over the Christmas holiday ++
===============================================================
You Know You've Been on the Computer Too Long When...
* When you are counting objects, you go -
"0,1,2,3,4,5,6,7,8,9,A,B,C,D...".
* When asked about a bus schedule, you wonder if it is 16 or 32 bits.
* When your wife says "If you don't turn off that darn machine and
come to bed, then I am going to divorce you!", and you chastise her
for omitting the else clause.
* When you are reading a book and look for the space bar to get to
the next page.
* When you look for your car keys using: "grep keys/dev/pockets"
* When you get in the elevator and double-press the button for the
floor you want.
* When not only do you check your email more often than your paper
mail, but you remember your {network address} faster than your postal
one.
* When you go to balance your chequebook and discover that you're
doing the maths in octal.
* When you dream in 256 palettes of 256 colours.
* You're writing a homework assignment, and get to the end of the
line in the middle of a sentence, tack on a '\', and continue writing
on the next line.
* You try to sleep, and think ... "telnet xxx.dreams.heaven"
HTML version by Omri Weisman
------------------------------ End of file ---------------------------
