Path: utzoo!utgpu!water!watmath!clyde!rutgers!psuvax1!vu-vlsi!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: 2000 incompatiblities Message-ID: <3106@cbmvax.UUCP> Date: 7 Jan 88 22:27:53 GMT References: <1786@bsu-cs.UUCP> Organization: Commodore Technology, West Chester, PA Lines: 61 in article <1786@bsu-cs.UUCP>, jbwaters@bsu-cs.UUCP (J. Brian Waters) says: > Keywords: 2000,1000,programing,guru > I just recieved my amiga 2000 yesterday and tried to run a terminal program > on it that I had written. It runs just fine on my 1000, but give a guru > #A on the 2000. It does this regardless of using the nofastmem program. > What other problems are there of incompatiblity from the 1000 to the 2000 > besides those solved by nofastmem? Well, even if you run NoFastMem, you're still getting system stuff put up in FAST RAM. This won't normally cause the problems that things like improper memory allocations for graphics can cause, but its still a potential problem with some old software. Specifically, anything that thinks it knows where in memory it's running, or does other wierd things based on addresses. We found an early version of the Amiga3D program had some signed 24 bit math in it that caused the program to barf on any system with memory above $7fffff. The mysterious thing in this case was that the program didn't contain this code on it's own, we had versions that didn't exhibit the problem. It turns out that the problem was based on either the startup or library code that's associated with the C compiler used to build the program. My suggestion would be, once you're sure that YOU aren't doing anything strange with addresses that might cause such problems, would be to re-compile your program, making sure you're using up-to-date startup and library code. > The program uses the serial device and the console device and does not go > directly to the keyboard or serial port. Does anyone have a list of > things to watch for in programming to make sure it runs on all the amigas? - Watch your allocation of graphics and trackdisk buffers to make sure they sit in CHIP RAM. - Don't assume you're running on anything other than a full 32 bit machine (no monkey business with address bits 24..31). - Don't use signed math on addresses. - Don't ever make an assumption about any routine being at any particular location. - Watch your word alignment, especially you 68020 users. - Never MOVE SR, ; use GetCC() in the exec.library instead. - If you're playing with exception stack frames, make sure you check the CPU type and make your code work with all CPUs. ** Anyone got anything else to add? ** > > -- > Brian Waters !---\ > ihpn4!{iuvax|pur-ee}!bsu-cs!jbwaters > uunet!---/ -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"