Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!motcsd!mcdcup!mcdchg!att!oucsace!bwhite
From: bwhite@oucsace.cs.OHIOU.EDU (Bill White)
Newsgroups: comp.sys.atari.st
Subject: Re: Call for opinions
Summary: No problem with me ...
Message-ID: <1183@oucsace.cs.OHIOU.EDU>
Date: 5 Mar 90 04:11:59 GMT
References: <2059@atari.UUCP>
Organization: Ohio University CS Dept., Athens
Lines: 33

In article <2059@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes:
> Without going into the gory details, I want to know what you
> programmers out there think of adding the following constraint to
> programming on the ST line of machines:
> 
>     "You must leave Timer C in the MFP as it was originally programmed."
> 
> This does not mean you have to leave its interrupt enabled, or its
> interrupt vector pointing at the 200Hz handler: it just means you can't
> reprogram that timer's control or data registers.
> 
(stuff deleted)
> ============================================
> Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
> reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt

	I'm currently working on a math analysis / display program (read:
infinitely complex fractal program with delusions of grandeur) and might
end up using timer C for internal purposes.  However, the only reason I
can see for this causing a problem (ie peripheral access) is precisely
what I'll be avoiding.

	As I see it, most of the programs that would break (you suggested
games, demos, and such) are unlikely to rely too heavily on Bconout and/or
disk access.  Besides, application writers have three other timers to use
as they see fit.  A 200hz timer isn't likely to be of much use in a game
anyhow, would it?  Wouldn't that be a bit slow?
	Of course I could be wrong.  But I can't see any problems with the
change; to me, any program which changes timer C already risks messing up
GEMDOS, so it a little extra chaos won't matter that much.

					Bill White
					bwhite@oucsace.cs.ohiou.edu