apratt@atari.UUCP (Allan Pratt) (03/01/90)
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.
If you violate this constraint, or if you think it's unreasonable,
please let me know. The point is that I need a way to count small
increments of real time, and I want to get rid of all the places where
instruction execution time is used to achieve a delay.
If accepted, violating this constrait results in Bconout to printer or
IKBD not working, and the floppy disk code not working reliably.
I'm trying to make this as transparent as possible: only really screwy
programs (games, demos, etc.) care about this stuff. Timer C is the
system heartbeat, and you shouldn't mess with it unless you really feel
you need to, and then you should accept the consequences.
(It is already the case that revectoring or changing Timer C causes
GEMDOS to lose track of the time, and AES events not to happen, among
other things. Also, incidentally, if you inhibit the system vblank
handler, floppy operations will never time out, and the floppy's access
light will never go out even on successful operations; the motor will
shut off, though.)
I don't want to make this decision in a vacuum. What do you all think?
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!aprattneil@cs.hw.ac.uk (Neil Forsyth) (03/02/90)
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." >... >I don't want to make this decision in a vacuum. What do you all think? Well the Timer C interrupt seems to be quite an important issue when trying to achieve stable colour screen interrupts. Degas Elite subverts Timer C completely during screen interrupts and Neochrome lowers the IPL level. My own technique follows the Neochrome example and I believe is less traumatic to the system but would welcome Atari's own thoughts on it. None of our handlers change the timers characteristics though so I guess I'm voting with Allan on this. >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt +-----------------------------------------------------------------------------+ ! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own ! ! and are to be regarded as pure nonsense in a court of law! ! ! "I think all right thinking people in this country are sick and tired of ! ! being told that ordinary decent people are fed up in this country with ! ! being sick and tired. I'm certainly not and I'm sick and tired of being ! ! told that I am!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK ! +-----------------------------------------------------------------------------+
david.megginson@canremote.uucp (DAVID MEGGINSON) (03/03/90)
"You must leave Timer C in the MFP as it was originally programmed" Sounds good to me. The TOS is already such a mess trying to be compatible with a whole market of hacked, sloppy programs that we all know the idea of a multi-tasking GEM is almost hopeless. I'd support much more drastic rules and changes for the ST. That way, developers can start easing their programs towards compatibility now, so that if the great multi-tasking TOS 2.0 ever appears, every program will not suddenly die. -- David Megginson BITNET: meggin@vm.epas.utoronto.ca --- ~ Via ProDoor 3.2aR
bwhite@oucsace.cs.OHIOU.EDU (Bill White) (03/05/90)
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
ONM07@DMSWWU1A.BITNET (Julian Reschke) (03/13/90)
In article <2059@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." It sounds if this would allow TOS to run more properly on different CPUs and clock freq. GO FOR IT! ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 eMail: ONM07@DMSWWU1A.BITNET, "Julian Reschke" @ MAUS MS (++49 251 80386) ____________________ correct me if I'm wrong _____________________________