grwalter@watmath.waterloo.edu (Fred Walter) (06/06/89)
With a recently purchases A2620, and the FASTROM option of SetCPU 1.4 I have problems running graphics intensive stuff. For instance - F18 consistently screws up. Apparently F18 double-buffers, and it looks like one of the buffers gets trashed. Without FASTROM set, F18 works fine. As well, I was running Hack (Lite) the graphics screwed-up as well when I had FASTROM set (but I couldn't get this to consistently occur). Is this a problem with SetCPU 1.4 FASTROM ? my A2620 ? my 2000 (Rev 4.3) ? Are there any diagnostic programs I can get my hands on to check the A2620 out ? (If/when I take this back to the dealer, I want to be able to tell him something definite). Oh ya, the dealer told me that this was one of the earlier A2620's made available (in Canada anyway) - did the earlier version of the A2620 have timing problems ?
daveh@cbmvax.UUCP (Dave Haynie) (06/08/89)
in article <26925@watmath.waterloo.edu>, grwalter@watmath.waterloo.edu (Fred Walter) says: > With a recently purchases A2620, and the FASTROM option of SetCPU 1.4 I > have problems running graphics intensive stuff. For instance - F18 > consistently screws up. Apparently F18 double-buffers, and it looks like one > of the buffers gets trashed. Without FASTROM set, F18 works fine. In general, anything that's likely to be sensitive to system timing could mess up on an A2620. For example, games. It's not all that difficult to wide up with game code that counts on certain things taking a certain time. Any game should work as well on a 2500 type machine if you reboot to the 68000, as you might well imagine. Some programs almost certainly have a problem with 68020s due to unsupported coding practices like the MOVE SR,<ea> instruction or self-modifying code. My advice is to have your system set up so that most of the normal, everyday stuff runs just fine. For me, that's with FASTROM installed (but if I find a program that doesn't work with FASTROM or the '030, I usually toss it). Follow these steps in the event of something being screwy; all but the last are reversible. 1. REMOVE FASTROM If a program seems to act goofy, especially something time dependent like a game, first thing you might try is removing the FAST ROM code. "SetCPU NOFASTROM" will free up that memory and turn off the MMU, leaving you running from real ROM. This will help with programs that have ROM-dependent software timing problems, or programs that cause GURU #2s (protection violations, though SetCPU V1.5 handles these for you in most cases). 2. TURN OFF THE CACHE Additional goofiness can be removed with the cache off; use "SetCPU NOCACHE" for this. Self-Modifying code (which seems to be a favorite of game authors, even though it's officially forbidden) will certainly work better with this, and it will make the system go slower, which may help if you still have a speed problem. 3. TURN OFF FAST MEMORY The NoFastMem program from 1.3 may allow things that still have speed or chip memory addressing problems to function. 4. BOOT UP ON THE 68000 If you set out to, you could write a program that works on the 68000 but not on the 68020, though it's not real easy. Some folks have, however, succeeded without trying. Perhaps every time you find this necessary, you could send a letter to the authors of the program that forced you into it. Maybe they'd upgrade it. Games work on faster systems better in the Amiga than many other systems because may of them are video synced, and the video system stays the same here. Still, many programs, especially of the "take over the machine" variety, never thought about running in a speed variable CPU environment -- they're still writing code with the same tricks they learned on 6502s, many of which are just plain wrong in the Amiga system. I believe it's completely possible for most any kind of program to be written to work as well on the fastest 68030 machine as the plain A500. No one said it happens automatically, though; it takes a bit of thought. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
ewilts%Janus.MRC.AdhocNet.CA@cornellc.cit.cornell.edu (Ed Wilts - CandianOxy) (06/09/89)
>In general, anything that's likely to be sensitive to system timing could mess >up on an A2620. For example, games. > > 2. TURN OFF THE CACHE > > Additional goofiness can be removed with the cache off; use > "SetCPU NOCACHE" for this. Self-Modifying code (which seems to be a > favorite of game authors, even though it's officially forbidden) will > certainly work better with this, and it will make the system go > slower, which may help if you still have a speed problem. Although game writers seem to be guilty more often than non-game writers, let's add a non-game product to your list of titles that won't run. SoundScape (from Mimetics) will NOT run on a 2620 without the cache disabled. Didn't somebody promise to post a list here a long time ago of titles that wouldn't run on 68020 boards? Perhaps it's time somebody accumulated a list for all to look at before getting bit. Possible work-arounds (such as nofastmem, nocache, etc) might be useful for people that add a 2620 (or similar) and find out that suddenly an important piece of software stops working. Then somebody can take this list, publish it in a magzine and with a lot of luck, some publishers might even fix their code. We'll all benefit in the end. >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" .../Ed (EWilts%Janus.MtRoyal.AB.CA@UncaNet.Bitnet) Ed Wilts Sr. Systems Analyst, Canadian Occidental Petroleum Ltd. Calgary, Alberta, Canada (403) 234-1007
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (06/10/89)
In article <17261@louie.udel.EDU> ewilts%Janus.MRC.AdhocNet.CA@cornellc.cit.cornell.edu (Ed Wilts - CandianOxy) writes: >Although game writers seem to be guilty more often than non-game writers, let's >add a non-game product to your list of titles that won't run. SoundScape (from >Mimetics) will NOT run on a 2620 without the cache disabled. I don't know about SoundScape itself, but I know for a fact that the copy-protection scheme makes *heavy* use of self modifying code, to try to protect the guts of the CP scheme from prying eyes. It's really ugly. The rest of SoundScape may be ok, in which case you could turn the cache back on after the it has started up. -Dan Riley (riley@tcgould.tn.cornell.edu, dsr@crnlns.bitnet) -Wilson Lab, Cornell U.
daveh@cbmvax.UUCP (Dave Haynie) (06/12/89)
in article <17261@louie.udel.EDU>, ewilts%Janus.MRC.AdhocNet.CA@cornellc.cit.cornell.edu (Ed Wilts - CandianOxy) says: > Didn't somebody promise to post a list here a long time ago of titles that > wouldn't run on 68020 boards? Perhaps it's time somebody accumulated a list > for all to look at before getting bit. Possible work-arounds (such as > nofastmem, nocache, etc) might be useful for people that add a 2620 (or > similar) and find out that suddenly an important piece of software stops > working. Then somebody can take this list, publish it in a magzine and with > a lot of luck, some publishers might even fix their code. We'll all benefit in > the end. That's an excellent idea. Now if only every software developer out there will send ME one copy of each piece of software they make, so that I can test it on '020 and even '030 systems, maybe we can get the ball boinging on this :-) But seriously, if companies today are actually publishing software that won't work with '020s or (say what!) expansion memory, I don't suppose they'd be the ones sending in the software for such an examination. What would be a good general suggestion, though, would be for reviewers of any piece of software to go over a system checklist: O Works on minimal system (68000, 512K, 1 floppy) O Works with fast memory O Works from hard disk O Works on 68020/68030 O Works with SetCPU CACHE FASTROM TRAP 0 on A2620/68030 You could probably get a few more added to the list. That last one probably stresses things as much as possible. Which might be considered a good thing to do if you have an eye toward 1.4 or A3000 compatibility. Though beware: "NewCLI" and "EndCLI" break with the SetCPU "TRAP 0" option (you can use the equivalent commands under Bill Hawes' WShell for that setup...). > Ed Wilts > Sr. Systems Analyst, Canadian Occidental Petroleum Ltd. > Calgary, Alberta, Canada (403) 234-1007 -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession