Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: TOS
Message-ID: <1563@atari.UUCP>
Date: 15 Jun 89 18:14:22 GMT
References: <8906090105.AA10969@ucbvax.Berkeley.EDU> <1550@atari.UUCP> <2637@brahma.cs.hw.ac.uk>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 22

In article <2637@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes:
> In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
> >NEVER NEVER NEVER use an absolute address like $FC0000 because if we
> >ever move the ROM start address (HINT HINT) your program won't work!  The
> >only absolute addresses in any TOS program should refer to published
> >system variables or hardware things like interrupt vectors. 
> 
> Your not thinking of moving the I/O addresses are you?

Sorry, you're right, the I/O space is definitely nailed down.  That is,
any machine with, say, a Mega-style real time clock will have that clock
chip address at the same place as on a Mega.  That goes for all I/O
devices: if the hardware acts like an ST, it'll address like an ST. 
Things which aren't in future machines will, of course, not be there,
and nothing funny will address at the same place.  Things which are
different will address at a different place.  Things which are both the
same and different (i.e. new features, but have a compatibility mode)
will address both ways. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt