avp@garfield.UUCP (Anthony Paul) (02/23/88)
Ok, here are the much sought after (by me anyway) addresses for the mouse on the Mega. Simply, the old addresses pluss 96 (decimal) , or $60. That is, now on the Mega, you use, $2740, or 10048 (decimal) I know the 10048 is right, but just converted the hex in my head I hope it's right. I found a few other addresses were plus 90 (decimal). Some are plus 70 (deciaml). If anyone is looking for a specific one, maybe I can help. Drop me a line. BTW, I have a non-Mega version of Arkanoid, and would like to get it to run on my Mega, but I figure there must be more to it than just the mouse addr changes, because it locks up solid before the game reallt gets anywhere. If it was just the mouse addrs, wouldn't it just not play? or something? I'll mess with it and post any positive results. thanks for your time, Anthony Paul avp@garfield.UUCP avp@garfield.mun.cdn
apratt@atari.UUCP (Allan Pratt) (02/25/88)
in article <4516@garfield.UUCP>, avp@garfield.UUCP (Anthony Paul) says: > > Ok, here are the much sought after (by me anyway) addresses for the > mouse on the Mega. PLEASE DON'T USE THESE ADDRESSES! The offsets from the line-A variable base (negative offsets for the mouse info) are CONSTANT, but the ABSOLUTE addresses are not! It is impossible to estimate the damage done to version-independent programming by Apple and Atari when they published the "magic peeks and pokes" of their systems. Remember when an OS call on an Apple ][ consisted of a branch into ROM? The effects linger on... ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
good@atari.UUCP (Roy Good) (02/26/88)
Allan made a very important point in a recent posting, and that is that programmers for the ST, or any machine, MUST abide by the published rules when designing and writing software if they expect their code to run unaltered on future revisions. One of the greatest problems any company has is maintaining compatibility. It's bad enough when a published, supported, interface forces a systems programmer (eg Allan Pratt) to make compromises in an enhancement or bug fix - that is the price paid for an open system. However, it is much MUCH worse when a good, desirable, improvement to systems software (TOS in the case of Atari) has to be removed or seriously reduced in impact just because some widely used software disobeys the rules and hits the OS directly. I realise I have only been at Atari for about 6 weeks (it seems longer [:-)]) but this applies to ANY computer supplier. There is the constant worry that a major enhancement that would really improve the value of the product for well-behaved applications will cause others to fail. And, of course, the congratulations for the enhancements will be totally obliterated by the flames and flak from those whose pet programs no longer work. Every feature of the forthcoming TOS, fix or enhancement, has to go through vigorous discussion of how it will affect existing users. This in itself adds to the development and test process considerably. When a manufacturer releases software or firmware which is bundled with every system, he/she must stand by it. When an independent makes such a release, he/she can decide whether to provide total compatibility or to state certain restrictions on the product's use. So PLEASE, keep to the rules and understand the impact not so doing has on the development process. And we thank you for your support. ----------------------------------------------------------------------------- Roy J. Good Product Development, Atari Corporation Views expressed are my own. Atari may agree or disagree; they have the right. -----------------------------------------------------------------------------
sreeb@pnet01.cts.com (Ed Beers) (02/28/88)
Speaking of following the standards to insure future compatibility, why did
Atari use the $axxx and $fxxx instruction traps. These are reserved in the
mc68000 and the $fxxx instruction opcodes are used by the mc68020 and mc68030.
This probably explains why the megas come with a 68000 rather than a 68020.
UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!sreeb
ARPA: crash!pnet01!sreeb@nosc.mil
INET: sreeb@pnet01.cts.comlandon@Apple.COM (Landon Dyer) (03/01/88)
In article <2597@crash.cts.com>, sreeb@pnet01.cts.com (Ed Beers) writes: > Speaking of following the standards to insure future compatibility, why did > Atari use the $axxx and $fxxx instruction traps. These are reserved in the > mc68000 and the $fxxx instruction opcodes are used by the mc68020 and mc68030. Line-A was used because, well, Apple used it, and it was there. Line-F was used as an optimization (two-byte JSRs so the AES would fit into ROM), and is in no way related to the way the ST is "defined" to the outside world. Questions about what IS defined on the ST should probably be directed to the guy in the hotseat, Mr. Good. Since the final technical documentation is over TWO YEARS LATE (!) I'd expect it to be a priority item now. There is no substitute for good documentation -- and the ST just doesn't have any yet. > This probably explains why the megas come with a 68000 rather than a 68020. Nope. The ST is pretty stuck in the mud with respect to the 68000, but for different reasons. Moving to a 68020 will be painful for EVERYONE. -Landon -- I speak for me.
c60b-at@buddy.Berkeley.EDU (John Kawakami -0^0-) (03/01/88)
In article <993@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > >It is impossible to estimate the damage done to version-independent >programming by Apple and Atari when they published the "magic peeks and >pokes" of their systems. Remember when an OS call on an Apple ][ >consisted of a branch into ROM? The effects linger on... > I would call it the lesser of two evils rather than damage. Without these hardwired os calls, lots of memory would have been wasted on implementing a portable os that really had nowhere to go. Without these memory maps there may never have been a home computer (read home vid-game machine) revolution. And yes, the effects linger on much to the chagrin of many CIS departments across the globe :-) John Kawakami / c60b-at@buddy.berkeley.edu model american / cc-28@cory.berkeley.edu numbered account / ----* -O^O-
c60b-at@buddy.Berkeley.EDU (John Kawakami -0^0-) (03/01/88)
I want to add to Roy Good's call for using only documented system calls. I think we need more adherence to the "rules". But we also need clearer rules and bug free functions (or at least docu- mented bugs). Of all the 'new' machines, the ST has the worst and most difficult to find manuals. Compare the photocopied ST devpack docs to the AppleIIGS docs (the hardcover texts at Waldenbooks). Perhaps if we could get better documentation, we would adhere more closely to the official calls. (by we, I mean programmers in general. I'm stuck with Pascal so I'm not doing many system jumps;-) John Kawakami / c60b-at@buddy.berkeley.edu model american / cc-28@cory.berkeley.edu numbered account / ----* -O^O-
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/02/88)
In article <1115@pasteur.Berkeley.Edu>, c60b-at@buddy.Berkeley.EDU (John Kawakami -0^0-) writes: > calls. I think we need more adherence to the "rules". But we > also need clearer rules and bug free functions (or at least docu- > mented bugs). Of all the 'new' machines, the ST has the worst and > most difficult to find manuals. Ok...the question of the day... If we have such a hard time getting bugs fixed like the 40 folder problem now, what will happen when Atari releases the 68030 Unix(/Idris ?) machine AND THE Abaq system? :-)
drs@bnl.ARPA (David R. Stampf) (03/03/88)
In article <1720@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >In article <1115@pasteur.Berkeley.Edu>, c60b-at@buddy.Berkeley.EDU (John Kawakami -0^0-) writes: >> calls. I think we need more adherence to the "rules". But we >> also need clearer rules and bug free functions (or at least docu- >> mented bugs). Of all the 'new' machines, the ST has the worst and >> most difficult to find manuals. >Ok...the question of the day... >If we have such a hard time getting bugs fixed like the 40 folder >problem now, what will happen when Atari releases the 68030 Unix(/Idris ?) >machine AND THE Abaq system? :-) Must be a newcommer - You are not going to see 68030 machines nor (I bet) an Abaq out of atari any time soon. (Soon in a Geologic sense). See the past history of PC clones, hardware upgrades, (Face it folks - the Mega is a 1040 in a new box - period), documentation and the like. Anything with a 68030 or a Transputer will put them in the same price range as the big boys and Atari will be crushed - they just have no concept of support and quality. They should have stuck to the game market - that seems to be the direction that the ST is heading in anyway. Have you seen one of their Blessed Retailers lately - all games and very little else of substance. Even the cheerleading magazines are looking a little grey around the gills lately. < dave
hakanson@mist.cs.orst.edu (Marion Hakanson) (03/04/88)
In article <7499@apple.Apple.Com> landon@Apple.COM (Landon Dyer) writes: >. . . >Nope. The ST is pretty stuck in the mud with respect to the 68000, but for >different reasons. Moving to a 68020 will be painful for EVERYONE. Just how painful is it? I've been operating under this assumption for quite awhile -- people on the net have been saying that GEM/TOS would not work because of different sizes of exception frames, etc. A fellow here who didn't know any better put a 68020 in his 1040ST, and when I asked him about it, he said it works just fine. Runs all his TOS/GEM programs just fine. He said it even bombs normally. Apparently he had to use some PAL's to do the trick, but since I'm not a hardware hacker, I couldn't say exactly what was involved. Certainly it's not for the faint of heart. This guy did his own 4M upgrade, too. The speed isn't greater except for certain operations, he said (presumably the loop mode, instruction cache, and longword operations would be better). I assume that this is why Atari, et al, think the added expense is not worth the while (I'll agree), but what's the REAL story here? -- Marion Hakanson Domain: hakanson@cs.orst.edu CSNET : hakanson%cs.orst.edu@relay.cs.net UUCP : {hp-pcd,tektronix}!orstcs!hakanson
good@atari.UUCP (Roy Good) (03/04/88)
In article <1720@ssc-vax.UUCP>, benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > In article <1115@pasteur.Berkeley.Edu>, c60b-at@buddy.Berkeley.EDU (John Kawakami -0^0-) writes: > Ok...the question of the day... > If we have such a hard time getting bugs fixed like the 40 folder > problem now, what will happen when Atari releases the 68030 Unix(/Idris ?) > machine AND THE Abaq system? :-) Ok...the answer of the day... (and tomorrow, and tomorrow,...) We are in the process of revising product test, release and support rules for all products, and the good news is that future products such as the 68030 don't have a history. The 68030 is mandated to comply with SVVS and X/OPEN requirements, and implicitly with POSIX. A seasoned professional with many years experience has been hired as UNIX Program Manager, working within my area, i.e. Development Engineering. We are making other adjustments and hirings to strengthen controls and support, as evidenced by my recent posting of new job opportunities here at Atari on this very net (misc.jobs.offered). I have almost 20 years in this business, entirely spent in system software (and hardware) development and/or worldwide systems-level product support. I am EXTREMELY sensitive to product quality and to post-release support. Right now it's a question of finding people who are "pro-active" in those areas to add to our existing capabilities. So if you know of anyone who might be interested in such positions, get them to look at the job posting. ----------------------------------------------------------------------------- Roy J. Good Product Development, Atari Corporation Views expressed are my own. Atari may agree or disagree; they have the right. -----------------------------------------------------------------------------
poole@forty2.UUCP (Simon Poole) (03/08/88)
In article <7499@apple.Apple.Com> landon@Apple.COM (Landon Dyer) writes: >In article <2597@crash.cts.com>, sreeb@pnet01.cts.com (Ed Beers) writes: ...... >> Atari use the $axxx and $fxxx instruction traps. These are reserved in the > >Line-A was used because, well, Apple used it, and it was there. Line-F was >used as an optimization (two-byte JSRs so the AES would fit into ROM), and >is in no way related to the way the ST is "defined" to the outside world. .......... >> This probably explains why the megas come with a 68000 rather than a 68020. >Nope. The ST is pretty stuck in the mud with respect to the 68000, but for >different reasons. Moving to a 68020 will be painful for EVERYONE. Matter of fact, the german computer magazin c't has published a series of patches for the ROM's that allow you to run most (they claim 99%) programs with their 68020 board. They use some of the unused Line-A "instructions" as replacement for the Line-F trap. The main problem is that you really don't get so much more speed (they claim about 50%) for the money (if you can use the 68881 you're naturally lucky). -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------