Copy Link
Add to Bookmark
Report
Ictari Issue 36
ICTARI USER GROUP ISSUE 36 July 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 36
==================
ASSEMBLY ST Assembly Language Workshop. Chapter 1.
C Monochrome fade functions.
GFA Date and time setting procedures.
STOS Mouse and Joystick test routines.
MISC NVDI information.
SCSI FAQ.
File Viewer program demo.
Current membership list.
In next months issue of ICTARI (this may change) :-
ASSEMBLY ST Assembly Language Workshop. Chapter 2.
C Richard Harvey. C Tutorial Part 1.
Garden Database program.
GFA Various font routines.
STOS Alert box routine for STOS.
MISC Icon images.
----------------------------------------------------------------------
EDITORIAL
=========
POSTAL CHARGES
--------------
The postal charges have increased to 20p for a second class stamp.
Please send the correct value stamps when returning a disk. The cash
rates will stay the same.
KELSTAR DISKZINE
----------------
I had a letter from Bob Kell telling me about a disk magazine for
Atari users. It doesn't cover programming as such but has various
Atari related articles, etc. If anyone is interested in getting a copy
you can contact Bob at :-
22 March Crescent
Cellardyke
Fife
Scotland KY10 3AE
ARTICLES
--------
We still need more programming articles and some more correspondence
would be of interest also. If you haven't written in before (and there
are quite a few who haven't) perhaps it is about time you contributed
in some small way to the magazine.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: *.*
From: John Levon
Re: VDI Enhancer
v_opnbm would be very useful, but I'm not really happy with forcing a
user to install another auto program just to run my program using
v_opnbm. Is there any (pref. C) code around to install a similar
function without having to place anything in the auto folder ? Then
the program could check the EdDI cookie, and if wasn't present, use
its own routines ...
Has anyone tried to get NKCC 2.93 working with Lattice C (V5.6) ?
dr2lc (converting from DRI to Lattice object format) seems to work but
on compilation Lattice complains that some (why only some ?) symbols
were undefined e.g. nkc_multi isn't defined but others are.
PS. In case anyone else hasn't mentioned it, the A.C. (and Lattice
docs) incorrectly describe the array returned by vqt_[f_]extent. The
bounding box is actually :
1----------2
| |
4----------3
which is a lot more logical.
----------------------------------------------------------------------
To: ICTARI
From: Peter Strath
Re: File Viewer
WARNING: The layout of a saved EFI list has been changed to allow for
future extensions. EFI lists saved with FVb1 will NOT work
with any later versions.
I would like to thank all those who wrote in with comments and/or
suggestions on the first beta release of my program, File Viewer.
I have included the 2nd beta version of my program on disk which
includes some of those suggestions.
Bug fixes are mentioned in CHANGES.TXT and bugs still present in
FVMAN.DOC in the FVIEWER directory.
Below are replies to the comments made which I have answered one
point at a time, so the text won't mean much unless read in
conjunction with the original comments.
To: Peter Hibbs
From: Peter Strath
Re: BETA TEST PROGRAMS
I'm glad you found the program useful, it will become more and more
useful as my understanding of programming and design increases.
Your request for file sorting has been implemented and file list
window resizing added to my to do list. More picture formats have been
added and I have managed to get them to all be viewed in the 3
different ST resolutions accept 16 colour images in ST medium.
You can hide from view 'Re-read directory' and 'Previous directory'
using the 'File Information\Options' dialog, opened by right clicking
on any entry. 'Previous directory' is hidden by default.
Regarding file sizes; As yet I haven't looked into the disk
operations required to calculate actual disk space used by files,
although to display this prominently on the information line may
confuse novice users and would be more useful displayed in the
File Information dialog for folders and drives.
I will be looking into converting between different file formats when
I've learnt enough about the various file formats.
To: Jason J Railton
From: Peter Strath
Re: File Viewer
The program is being developed to handle as many types of file/data
formats as I can write for it, including; static images, plain text,
formatted text, databases, etc...
The first beta version only handled IMG and plain text. The second
beta version adds support for NEO, PI[1-3] and PC[1-3]. I am testing
a 1st Word Plus viewer and I'm in the initial stages of testing a
simple database viewer interface, nasty bugs aside both should be in
the third beta version.
If you have any other file formats you would really want File Viewer
to handle then please write in.
To: Stephen Bruce
From: Peter Strath
Re: File viewer Beta test
Thank you for your encouraging comments on my program. I intend the
completed project to be uncrippled shareware with a reasonable fee for
continual usage, although beta testing may take another few months to
complete.
Resizable, multiple file lists and longer EFI-long-filenames have
been added to my to do list.
In a future version there will be an option to determine the scope
of an EFI, local or global.
A global scope would mean any file with the specified name would
obtain the EFI data wherever it was located. The EFI would be saved
in one centralized list on disk called GLOBAL.EFI.
An EFI with local scope will have its data saved in the directory the
specified file was in, in a file called LOCAL.EFI.
Local EFIs with the same short name as a global EFI would take
precedence.
I agree with you on keeping the Re-read directory and removing the
Previous directory, the new hide from view option ('File
Information\Options' dialog) used in conjunction with the menu
option 'Show\Hidden files' enables you to hide/unhide any file.
Be warned though that it will hide from view any file with the same
name in any directory (global scope). This only affects File Viewer
and not any other programs.
The drive list can be quickly accessed by the menu option
'Tree\Drive list'.
I cannot say if internal file editing will be added because of the
time it would take and the large memory requirements required.
A simpler solution would be to use the current crop of applications as
file editors and use File Viewer as a previewer which can load a file
editor with a specified file if needed.
----------------------------------------------------------------------
To: All (C users)
From: Mrten Lindstrm
C++
===
Net trekers: I just saw (in Windows Developer's Journal - July 96)
that the draft ANSI C++ standard can be found on the Web address:
http://www.cygnus.com/misc/wp/draft
I don't know how big it is (maybe it's HUGE) but if anyone checks it
out and finds that it could fit on an Ictari disk (or two?)
(compressed), then I think many would be interested in it (I would).
Users of Lattice C: Is Lattice C a C or a C++ ? I have seen some
Ictari members refer to it as C++, but have failed to see any
notification from Hisoft or elsewhere that Lattice C was made into
C++, and I would have expected them to make at least some noise about
it.
I HAVE understood that Lattice C apparently recognizes C++ style one-
line comments (preceded by // rather than enclosed in /* and */). But
can it cope with other C++ features too? E.g. C++ operators: "new",
"delete" etc. or even full-fledged C++ CLASSES.
GNU C++ (FREEWARE but requiring 4 Mb and hard disk) is otherwise the
only C++ for Atari computers that I know of. From what I have heard,
GNU C/C++ contains some irregularities (non-standard extensions) but
on the other hand it is available on all platforms, and by cross-
referencing the ANSI C++ standard mentioned above it would be possible
to avoid using anything that isn't standard. Does anyone have any
experience of GNU C/C++ ?
To: Jim Taylor and other C programmers
From: Mrten Lindstrm
LOW-LEVEL VDI CALLS (Ref: The VDI Enhancer - Ictari 34)
-------------------
Oh dear, I really only intended my GFA listing to be a help for some
of "the poor devils who don't use C". There were some C-related
descriptions bundled with the new VDI functions (in the file
NEW_FUNC.TXT, Ictari 34), but I am not exactly an experienced C
programmer and I didn't study these very much to find out how helpful
they might be.
First, here is your translated C versions (from Ictari 35) of my GFA
Basic functions v_opnbm and v_clsbm (Ictari 34), with some fresh
corrections by me. Then follows some explanations. (If, as you say,
you have absolutely no experience of GFA Basic, I think you have made
a good job of translating my GFA code to C. Perhaps other C users can
benefit from it?)
int v_opnbm(short xmax,short ymax,short wpix,short hpix,MFDB *mem)
{
short i, junk;
_VDIintin[0] = 2+Getrez(); /* with Atari GEM */
for(i=1;i<=10;i++)
{
_VDIintin[i] = 1;
}
_VDIintin[11] = xmax; /* You had left 0 for these indexes */
_VDIintin[12] = ymax;
_VDIintin[13] = wpix;
_VDIintin[14] = hpix;
for(i=15;i<=19;i++)
{
_VDIintin[i] = 0;
}
_VDIcontrl[7] = (short)((int)mem>>16); /* bits 31-16 */
_VDIcontrl[8] = (short)mem; /* bits 15-0 */
_VDIcontrl[0] = 100; /* OP code for v_opnbm or v_opnvwk */
_VDIcontrl[5] = 1; /* Sub-op code for v_opnbm */
_VDIcontrl[1] = 0; /* No ptsin elements */
_VDIcontrl[3] = 20; /* 20 intin elements */
_VDIcontrl[6] = graf_handle(&junk,&junk,&junk,&junk);
vdi(); /* Make the actual VDI call! */
return _VDIcontrl[6];
}
int v_clsbm(short bm_handle)
{
_VDIcontrl[0] = 101; /* OP code for v_clsbm or v_clsvwk */
_VDIcontrl[5] = 1; /* Sub-op code for v_clsbm */
_VDIcontrl[1] = 0; /* No ptsin elements */
_VDIcontrl[3] = 0; /* No intin elements */
_VDIcontrl[6] = bm_handle;
vdi();
return 1;
}
// (I hope this will work!)
Apart from the small error with some array indexes, the major problem
was with the low-level VDI call itself (in GFA Basic 3: "VDISYS
100,20,0,1"), where you made a call of v_opnvwk. But that will only
undo your previous work of filling in the VDI arrays, since the
v_opnvwk binding of you C package will have its own ideas of how the
VDI arrays should be filled in.
vdi() - with no parameters - is instead the function call to use. The
simple vdi() function (or similar) will hopefully be defined somewhere
in your C libraries. If not, it can be defined based on the following
small assembly routine:
_vdi: move.l #_VDIpb,D1
moveq #115,D0
trap #2
rts
where _VDIpb is the address to the VDI parameter block (containing
pointers to the VDI arrays, in the order contrl, intin, ptsin, intout,
ptsout). I don't have Lattice C myself, so you will have to study its
documentation for the details regarding how to include assembly
language routines.
I also have added assignments for _VDIcontrl elements 0,1,3 and 5.
(These were built-in to the GFA VDISYS command.)
Furthermore, I was a little suspicious about the use of appl_init and
appl_exit within your VDI function definitions. I think you will
normally call appl_init only once, at the start of your program
(before you make any other GEM calls) and appl_exit once at the end of
your program.
In relation to the VDI, appl_init (registering your program as an AES
application) only serves the one purpose of making available the AES
call graf_handle(&junk,&junk,&junk,&junk), which returns the physical
screen VDI workstation handle in use by the AES. You need the physical
screen handle, as input to contrl[6], before you can call v_opnvwk (or
v_opnbm) to get a virtual one.
By the way: I think you asked what the parameter "junk" stands for. It
will return the dimensions of the system character cell (normally 8x16
or 8x8 depending on screen resolution) and the minimum size of an AES
boxchar object. If you were interested in these you could rewrite the
call as graf_handle(&wchar,&hchar,&wboxchar,&hboxchar).
Finally: I think it doesn't do any harm, with Atari GEM, to ALWAYS use
work_in[0] = 2+Getrez(); (or _VDIintin[0] = 2+Getrez();). Regardless
of whether or not GDOS is present. Though for PC GEM, work_in[0]=1
should instead probably be used.
To: Peter Hibbs and everybody else
From: Mrten Lindstrm
"DLLs" for the Atari
--------------------
(= External function libraries, callable during run-time)
This is a very interesting topic you raise, and I think we have
already been touching on it during discussions on ways to implement
universal printer drivers and VDI extensions.
There already exists, as you say, something similar on the Atari - in
the form of memory-resident (AUTO-folder) programs that hook into trap
vectors or make available addresses (via the cookie jar) to where
programs can jump. Examples are GDOS, NVDI or the VDI Enhancer program
published in Ictari 34, all of which make available a number of
functions that aren't in TOS ROM. I HAD already been considering
turning my PICPAC library into a memory-resident library module
similar to these.
But your proposal was to make it possible to load libraries only on
demand (and unload them afterwards) and also perhaps to provide some
standardized interface for the opening and closing of libraries. And
the following is the best solution that I can think of:
+ A library manager program, run from the AUTO folder, and that
reserves a separate pool of memory into which library modules
can be loaded. This way it will work with e.g. GEM Desk
accessories. (Just loading a library into any block got with
GEMDOS MALLOC wouldn't be safe, since such memory blocks are
freed when the main application, that was running at the time
of allocation, terminates).
The size of the pool should be easily configurable by the user
(e.g. by changing a numerical suffix of the manager file name
- similar to how Atari's FOLDRxxx works).
+ This manager installs a cookie whose value is a pointer to a
function dispatcher (or possibly to a structure in its turn
containing the pointer to the dispatcher). All calls to
library functions are made via this dispatcher. Special
"OpenLib" and "CloseLib" calls must be made by an application
before and after using any of the functions in a library.
The way I conceive "OpenLib", it would take as a parameter a
pointer to a (file) name string for the library to open, and
return a (long) value that should be used with any further
calls of this library. The function number within the library
should be added to the value and the result used as first
parameter of each call. (Thus the library manager can
determine both library and function from the leading parameter
of each call it gets.)
If the last byte of the library-identifying base number is
always zero, there would be room for up to 256 functions in
each library.
+ When the free memory of the pool isn't enough to load a new
library, any currently unused library modules (closed by every
caller) can be "unloaded" and their memory returned to the
pool.
(If library modules, according to my above idea, are
identified by a base function number, rather than called by
direct address, it would perhaps even be possible to RELOCATE
(unload and reload) library modules in order to fill memory
gaps, i.e. "defragmentize" the library memory pool.)
+ All function calls are made according to the standard C
calling convention. (On the low level meaning that the caller
is both pushing parameters on stack - last parameter first -
and, afterwards, tidying it. The call itself is a JSR
instruction to the address given with the library manager
cookie.)
This should make it maximally easy to make the calls from most
languages, but DOES, as far as I can see, have the
disadvantage that libraries cannot benefit from any of the
memory protection that MiNT, or compatible system, running on
a 68030 machine could otherwise provide. (I think they must be
placed in "global" memory under MiNT - freely accessible by
all - while if instead a TRAP was used, the libraries could be
placed in "super" memory - accessible by all but only in
supervisor mode.)
Another advantage is however that there is no risk of clashes
with other systems as there could be with traps.
Also: to avoid any possible problems under pre-emptive multi-
tasking, the library manager could perhaps set a flag on each
function entry and clear it on exit. If the flag is already
set when someone makes a call, I guess the library manager
could just execute a loop, waiting for the flag to be cleared?
+ A library module would be an ordinary TOS program file (easily
creatable with any assembler for instance), though containing
a non-standard "program". No calls of MSHRINK or PTERM should
be made. Instead there could perhaps be a small routine that
merely returns (in D0) the pointer to a function pointer table
and exits with an RTS instruction. I HOPE it still is possible
to create modules using C (and not just assembly), though this
would depend on whether the ordinary initialization procedure
- inserted by the compiler before the "main()" function - can
be changed. CAN C PROGRAMMERS ANSWER THIS?
I have done a little bit of drafting on the above ideas, but nothing
finalized. Any further views?
By the way: I would prefer the default name extension of library
modules to be something else than .DLL. So that, on a mixed system
such as a PC with Gemulator, it would be as easy to keep different
kinds of library modules apart as it is to distinguish ones PRGs from
ones EXEs. My unimaginative proposal is .LBR (.LIB is already heavily
used by many programming packages) - and perhaps FUNCLIBS for a
default folder name. Does anyone have better ideas?
*/ Since proposing this standard last month I have had further
thoughts on the subject. I think the main problem, as you rightly
point out, would be memory fragmentation, i.e. a program that is
opened by the user loads a library file into memory. The user may then
open another program which uses the same library file so the program
then does not need to load the file again. If the user now closes the
first program the library file must remain in memory for use by the
second program, the memory pool is now divided up into smaller chunks.
What happens if the user now closes the second program, there needs to
be some way of closing down the library program and releasing the
memory.
Your idea of a library manager program perhaps could handle all this
but I am not really in favour of another AUTO program being used. I
already have four or five AUTO folder programs that I have to run on
boot up and I think most users would prefer not to use these unless
absolutely necessary. It increases the risk of different programs
being incompatible, the user has to install the program in the AUTO
folder and sometimes decide in which order they have to be run, they
slow down the boot sequence on floppy disk only systems and they use
up more memory. I believe that the programmer should make it as easy
as possible for the user to use his program with a minimum of fuss.
For these reasons I would like to propose an alternative method.
Forget about AUTO folders and Cookie Jars, when a program runs it
allocates a memory block of the same size as the library program and
then loads the library program into it, the program also sets all the
absolute addresses using the program's relocation table as normal. Any
library functions are then called via the start address by pushing a
function parameter (together with any others required) onto the stack
and jumping to the start address. Return values would be returned in
register d0 as usual. This method has the slight disadvantage that if
two (or more) programs should need to use the same library program at
the same time, there will be no saving in memory since each program
will allocate memory space for it but I think the likelihood of this
happening very often is quite small and in any case, the library
programs would probably not take up too much memory space. The
advantages would be that when a program is closed, its associated
library program will also be closed and the memory automatically
freed. It would be simpler for the programmer since there would be no
Cookie Jars to install, check or relocate and the use of library
program variables would be easier to use since there will not be two
calls to the same program which may corrupt any variables used by
another application.
I think also that any library programs should not use any AES/VDI
functions (unless absolutely necessary) since the application program
which wants to use the library functions may not be using GEM. If any
GEM calls are used the documentation provided with the library files
should state that GEM must be initialised before calling any library
function as well as any other parameters required by the library
routines.
I would be quite happy with using the .LBR extension and FUNCLIBS for
the library folder. I would also suggest that on a hard disk, the
FUNCLIBS folder should always be in the root directory of the C drive
and on a floppy disk system, it should be in the root directory of the
disk from which the application program was run. This would allow the
application program to find the library programs easily. When the
programmer distributes his program he would also supply any library
files that are required with the instructions to the end user to place
these files in the FUNCLIBS folder (if he has one) or create the
folder if he hasn't.
I would like to hear from other members on this subject to see if it
is worth continuing with this project. PDH /*
----------------------------------------------------------------------
To: Mrten Lindstrm
From: Stephen Bruce
First, I should apologise for my bad grammar re the
instructions/assembler directives confusion. As previously stated, I
don't have anyone else to talk to about these things so it can get
confusing at times. Thanks for putting me straight, the extra info
helped clear things in my head.
Anyway, the main point of this is to ask another question. Last month
you stated that User mode was preferable for most operations when GEM
or multi tasking are required. Assuming the programs were not used in
these circumstances (e.g. games, demos, etc do not require these
usually), would it be feasible to write the program using
user/supervisor mode switches when required (running mainly in user
mode) until debugging is complete & then remove all switches except an
initial call to Supervisor mode? The resulting source code could then
be assembled & run in Supervisor mode without the slowdown caused
during switching. Is this a real possibility or does the removal of
these instructions cause problems in itself? Is it worth bothering
with at all for what might be a negligible speed increase? And how do
I know when I really need Supervisor mode anyway?
To: Jason J Railton
From: Stephen Bruce
You spooked me a bit coming up with the same thoughts as myself re PCs
& PlayStations. Let's hope there are more of us out there.
I tried the new polydemo & it's cool but the control method's a bit
clumsy (though it did work this time). Any chance of making one of the
mouse buttons a 'walk forward' button as I kept running off the edge
of my mouse pad. Also, is there an exit to be found in the maze?
Personally I just got lost. All we need now is something to shoot &
it's look out SubStation. Keep up the good work, I'm rather enjoying
following this 'work in progress' and I wouldn't mind knowing where
you got your 3D maths info from. Has it been sourced from one book?
*/ The demo was excellent, perhaps a joystick control would be more
practicable for this type of program. Any chance of a fairly basic
article on the methods used to generate the maze graphics. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: L.Maule-Cole.
I have the following books which I will send to anybody who would like
them for the cost of the postage.
Introduction to MIDI Programming by Dorfman Young.
GEM Programmers Reference by Gunther Szczepanowski.
Compute!'s ST Programmers Guide by Compute! Publications.
I also have a copy of HiSoft C Interpreter and a copy of HiSoft Basic
to give to anybody who would like them, again for the cost of the
postage. If I get no reply in the next copy of ICTARI I shall trash
them.
----------------------------------------------------------------------
To: Martin Milner
From: David Preston
What a relief! I haven't had the cross-machine problems you mention
(only one machine!), but your comments reminded me of a problem I'd
almost forgotten about. An earlier program had had problems with a
'palette' command and I'd got round it by putting a 'wait vbl'
directly after. It had never ocurred to me that *other* stuff might be
interrupt-driven (apart from the obvious sprites, mouse, colour
cycling, music etc etc). I must have a go at the offending prog, with
your suggestions borne in mind. Thanks!
To: Jason Railton
Your polygon demo works a treat (1Mb STe, TOS 1.62), and *very*
impressive it is, too.
To: *.*
Re: Atari/Ictari
What a refreshing change! How good it is to read such rational and up-
beat comments as those offered in Ictari 35 by Jason Railton, Lou
Maule-Cole and Stephen Bruce, on the continued validity of TOS
computers for home use.
I can't really add to their comments, save to offer this scenario for
your consideration - suppose a salesman knocked on your door and, with
a sickly smile, started this conversation -
Salesman - "Good morning, Sir. I have a proposition for you. For only
about 1,200, I'll take away your ST and give you a nice new computer
with smaller pixels and more screen colours."
You - "Will it run my existing software?"
Salesman - "No, but you can replace all your software for only about
300 quid an application, and some of it works almost as well as
Protext, Calamus, Papyrus and your other stuff."
You - "Is it any quicker than my ST?"
Salesman - "Well, the Pentium processor rips along at a hell of a
pace, but with umpteen layers of OS slowing it down you'll hardly
notice a difference. And now we've fixed the Pentium so it can add up
properly, we think we're onto a winner!"
You - "What about it becoming obsolete - I've had the ST for quite a
while?
Salesman - "Oh yes, sir! We include a guarantee of almost total
obsolesence in a very short time. While your ST has been plodding
along, doing its job without a problem, we've gone from the entry-
level PC being a 640k 8086 with a 20mb winchester, through 1mb 286,
386SX, 2mb 386DX, 4mb 486SX, 8mb 486DX, as far as the current 16mb,
100hz Pentium with a 1gig hard drive. And I shouldn't think that'll
see the year out!"
You have two possible responses - will you
a. Say "Oh, yes, that's for me. Please help yourself to my bank
account!", or
b. Set the dog/cat/hamster/ravenous bugblatter beast of Traal on him?
Bill Gates is wealthy enough. He's not getting any of my dosh.
And furthermore (sorry to labour the point, but I can't resist) - have
you noticed how many very new and up-to-date PC-contemptible machines
are _already_ on the second-hand market? After the initial selling
glitz has worn off, your average Mr/Mrs/Ms PC-buyer hasn't the first
inkling what they're buying or how to get their money's worth out of
it, so they turn off the superhighway at the first junction and put
the PC in the Classifieds.
The Gates/Big Blue combination (singly and/or in tandem) aren't
infallible. Remember MSX (MicroSoft eXtended basic) home computers?
What an earth-shattering success they were! IBM have taken twenty
years to come up with a decent machine and some would argue not yet
managed it. (The PS/1 & PS/2 were going to be the be-all and end-all
for personal use!?!)
There have been other crazes related to technology that were going to
sweep the world. The comparison between CB radio and the Internet
springs immediately to mind. That was going to allow the world to
communicate in a free and semi-unregulated way. In Britain at least CB
is now confined to very sad individuals (present company excepted in
case any of you guys are breakers) (Oops, I even know some of the
lingo!) and a few truckers. There's a very strong chance that the 'Net
will become the sole preserve of anoraks and wallies before very long
(not that it isn't already). Well, that's enough bitter and twisted
rhetoric from me for now on that subject.
*/ Can we take it then, that you are not in favour of PCs ? ICTARI /*
----------------------------------------------------------------------
To: Jason Railton
From: Peter Hibbs
Having tried your Rasters program which changes the colour palette on
every raster line without any interference from the mouse movement, I
must say I was very impressed. This is because I am trying to do a
similar thing in a machine code program I am writing without too much
success so far.
The part of the program which I am having problems with is the timing
of the raster displays. Basically I am changing to a different palette
when the screen display reaches raster line 32 and then changing it
back when it reaches raster line 170. I am using an MFP timer to count
the number of raster lines (using the Hsync pulse) and generating an
interrupt which then swaps the palette colours. The problem is that
when the mouse is moved a lot, the timer matures on lines 33-35 which
messes up my display. I think the problem is that the timer is reset
during the Vertical blanking pulse and the timer start can be delayed
if the mouse is moved because the mouse interrupts have a higher
priority. I cannot see any way of resetting the timer at a point in
time which is always constant, i.e. not affected by the mouse. One
possible solution would be to disable the mouse interrupts altogether
and somehow read the mouse co-ordinates and button status in the
Vertical blanking period and feed them to the mouse routines. I would
still need output from the keyboard however (but not the joystick).
Is there an easy way of reading the mouse co-ordinates from the
keyboard processor with the interrupts off and without affecting the
keyboard. Any suggestions would be welcome.
------------------------------ End of file ---------------------------
