jbwaters@bsu-cs.UUCP (J. Brian Waters) (01/07/88)
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?
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?
--
Brian Waters <backbone>!---\
ihpn4!{iuvax|pur-ee}!bsu-cs!jbwaters
uunet!---/daveh@cbmvax.UUCP (Dave Haynie) (01/08/88)
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, <ea>; 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 <backbone>!---\ > 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!"
rusty@vertigo.UUCP (M.W.HADDOCK) (01/09/88)
In article <3106@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <1786@bsu-cs.UUCP>, jbwaters@bsu-cs.UUCP (J. Brian Waters) says: >> Keywords: 2000,1000,programing,guru >** Anyone got anything else to add? ** Yes, use the system's timing routines if you MIGHT need delays. My '020 runs much faster than your '000. When double buffering make sure that the screens get displayed! Don't know what happens but the "Space Invaders" game that was posted runs on my '020 but after a while things get real messed up and they stop moving! After a little bit they start appearing again but the old ones don't go away. It works OK when I take the '020 off the side. Anyone know what's going on??? -Rusty- -- Rusty Haddock {{uunet!likewise!}cbosgd,rutgers!moss}!vertigo!rusty AT&T-IS Consumer Products Laboratories - Human Factors Laboratory Holmdel, New Joyzey 07733 (201) 834-1023 -- Being schizophrenic is better than living alone. --
bryce@hoser.berkeley.edu (Bryce Nesbitt) (01/09/88)
In article <3106@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > >** Anyone got anything else to add? ** Yes: It is possible to write a game that will work BETTER if a 68020 system is in use. Many games just become unplayable. Methods differ, but here are two starting points: 1> Use the system timer for your object moves. Under a 68020 the effective frame rate/smoothness goes up. 2> Time your frame rate, and make that the "standard". During execution check the frame count... if you are over or the same, flip right away. If you are under, Wait() until the proper frame. The first makes a better game on the faster CPU. The second gives the same game, with more spare CPU for other tasks. ------- In reality, people won't do this until faster systems are more common. >Sigh<. At least the A500/A2000 just about seals the "Fast memory" problem. Think how long that would have hung on if the A500/A2000 had 1 meg of chip/ 0K of fast as the standard configuration. >Dave Haynie |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci") (") U "Your theory is crazy... but not crazy enought to be true." -Niels Bohr
drs-ano@duvan.nada.kth.se (Arne Nordmark) (01/09/88)
In article <3106@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > > - If you're playing with exception stack frames, make sure you > check the CPU type and make your code work with all CPUs. > >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!" Oops! I added a "trap trap" to my standard startup code mostly to get rid of the famous division-by-zero guru (#00000005). Ehem...what if I try my programs on a 680X0-Amy. (My code never gurus but...:-) Perhaps a quick tutorial on 680X0 exception stack frames? Please? - Gunnar Nordmark - elin.lne.kth.se!NORDMARK@enea.UUCP ( That's right, I'm posting this from my brother Arne's account again. He'll kill me, but don't worry, I'm used to it. )
daveh@cbmvax.UUCP (Dave Haynie) (01/13/88)
in article <22471@ucbvax.BERKELEY.EDU>, bryce@hoser.berkeley.edu (Bryce Nesbitt) says: > In article <3106@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>** Anyone got anything else to add? ** > Yes: It is possible to write a game that will work BETTER if a 68020 > system is in use. Many games just become unplayable. Methods differ, > but here are two starting points: > 1> Use the system timer for your object moves. Under a 68020 the > effective frame rate/smoothness goes up. ... > In reality, people won't do this until faster systems are more common. Don't bet on it. And I was surprised, too. But Marble Madness, from Electronic "We develop on PC-ATs" Arts, of all things, runs BETTER on a 68020 system, in exactly the way you mention above. It's apparently synced to the video frame rate, not the CPU speed, and the main effect of running it on a FAST 68020 based system is that the mouse control gets much smoother and easier to handle. So your score goes up. I recally maybe one feature, I think it was the countdown timer before, but not during, each race, that's too fast on the '020, but otherwise, this is apparently a very well done game. Which proves than anyone writing games which work worse on a 68020 than a 68000 based system is out to lunch. > |\ /| . Ack! (NAK, SOH, EOT) > {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci") > (") > U "Your theory is crazy... but not crazy enought to be true." -Niels Bohr -- 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!"
peter@sugar.UUCP (Peter da Silva) (01/16/88)
In article ... bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: > 2> Time your frame rate, and make that the "standard". During execution > check the frame count... if you are over or the same, flip right away. If > you are under, Wait() until the proper frame. This is what "Tracers", our new video-game, does. On a 68020 you would expect to keep total smoothness right up to the highest level of difficulty. On the 68000 it does slow down just a tad at the higher levels. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.