Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: barney on November 05, 2009, 06:36:19 AM
-
Am I the only person experiencing this phenomina? It seems like about 40 percent of all WHD games crash on me. The game completely disappears and I am back to the Amiga Workbench. Up on the top left corner of the screen I get a small windows saying, do you want to "Exit", "retry" or make a "Core Dump". I tried all three options and nothing beneficial came out of it.
My hardware requirements are sufficient also: 1mb chip ram, 20mb fast ram, 68030 GVP Accelerator, WB 3.1.
Am I the only one having crash problems? Thanks.
Banrney
-
Are you running a TCP or USB stack at the same time? These programs clash with WHDLoad and make games crash like that. I'm not sure what else causes it, but I've seen the same thing happen in a lot of games on Rebel's A1200/030. IT never used to happen though.
-
No, I am not running either of those. In fact, I attempted to run WHD Load games using a fresh install of Workbench but still several games crash. Here are a few that will not work:
1. Indiana Jones and Fast of Atlantis
2. Indiana JOnes and Last Crusade
3. Alien Syndrome
4. Ultima 6
....and the list goes on.
Barney
-
Lower the value of the Mask transfer to 0x1FE00 with HDTooolbox and install or copy the game again.
Now try again. I think that most games won't crash anymore.
I have the same problem with my Amiga 1200 and this solve the problem.
-
How do I lower the value of the mask transfer. I have never even heard of that before. Is it a pretty simple proces?
Barney
-
it is a simple proces. Go to System:tools and double click HDToolbox. Click on 'Partition Drive' button . Select 'Advanced options' and now you get more options. Click on 'Change' button. Select the Maxtransfer Textbox and change the value to 0x1fe00. click on 'OK' button to close the the window. Do the same with other partition. click on 'OK' button to close the the window when you chnage the Maxtransfer value of all partitions. Click on the 'Exit'-button to close HDtoolbox.
-
There is only one problem. I have a GVP Accelerator/SCSI card so I don't even use the HD toolbox. I configured my hard drive using the GVP Prep Disk. I loaded this prep disk, and I did find where it displays my current configuration. Mine is configured as follows: 0XFFFFFE. If I make this change, will it wipe my drive?
Barney
-
Well, I changed it to 0x1FE00 and it unfortunately still crashes. I typed out the exact message it gives me when it crashes:
Exception "NMI Autovector" ($7c) at $1BCC744 (ExpMem $66774) occurred. Do you want to "Quit", "Restart" or "Make Core Dump"
I'll keep troubleshooting and see what happens.
Barney
-
When you changed the MaxTransfer figure did you press Enter before clicking OK?
The changes aren't saved unless you press Enter before clicking OK.
Dave G
-
@barney
You must edit WHDLOAD.PREFS file (usually inside S:) to set off NMI Autovector.
Default setting is commented, so you just have to remove semicolon.
Usual stuff on GVP devices, I have same thing with my A530.
-
Codetapper wrote: NMI Autovector is when a non maskable interrupt occurs. Usually reset switches such as the button on the Action Replay cartridge cause these to occur, but it also happens with some TCP/IP stacks and other hardware (perhaps your CD drive is generating them?). If that error occurs all the time, simply download the development archive and copy the s:whdload.prefs file and set that NOAUTOVEC flag globally. Then all installs will automatically use it.
-
Lockon 15, I think you just gave me the answer. I altered the WHDPrefs like you said and I havn't had a crash yet. I am still only on my first game but I have been playing it non-stop for over 30 minutes and no crash. Before, it would crash at the beginning title screen. I will give updates if I have any problems.
NOTE: Also, since this change to the WHDLoad config fine most likely fixed the problem, should I return my masktransfer back to its original setting: 0XFEEEEE
Barney
Barney
-
Does this also solve the problem if a TCP stack is running the background ?
-
@barney
Yeah, I've come down off my high for WHDload, it is just unstable. My experience with Lemmings is an examplary one of many games; that it runs fine for a few levels, then blammooo! Whole machine freezes up.
Too frustrating too deal with...:destroy:
-
I am still hopeful. I am now playing Indiana Jones and the Fate of Atlantis and it appears to be working good. I did get another strange crash, but I went back into WHDLoad config file and made another change. There is a line that states it should be enabled for 68030 machines (some kind of memory manager). I just removed the semicolon at the beginning of the line and now things are really working good.
Barney
-
Hmm. I may check into these things... But why the hell they don't deal with this stuff in an installer? , if it just a matter of asking a few questions and commenting or un-commenting a few script lines.
-
@TheGoose
Installer has a script which deals with WHDLOAD slave, so it's feasable to put few simple questions and generate an appropriate tooltype . The problem is no one cared enough in the first place, it was SW in development with no firm feature set; on other hand that might prove worthless from today' perspective since in over a decade of WHDLOAD development/usage it became pretty clear which Amiga setup behaves best. That means 030 is preferred, while 040 has it's own agenda; with 4Mb or more FastRAM you can fire up even the most demanding game; stay away from Poseidon USB stack since it' messes around with system calls. If some serious retro gaming is intended, then reading some WHDLOAD docs is a wise move; you learn a lot about MMU, PRELOAD and extraRAM, CACHE and MMU...knowing this might help you editing every single slave info or global prefs file, just as it suites your Amiga hardware.
-
@Lockon
So, do you think a littler better installer could be made? To set up the program to be more machine specific (in regards to CPU, MMU, memory situation, chipset) ?
I need to look at what all gets set in the WHDLOAD.prefs file...
Could that help knock out some of these issues?
Seems to me much of theses things are set on the tooltype level (per salve).
-
It could be made but it would be still pretty custom biased - simply, there are tons of various HW options which can't be commanded by a 2-dimensional rule. There are a lot of exceptions which tends to became a rule. I can't see it happening.
New install script is less relevant as long as you have WHDLOAD.PREFS since it stores most common tooltypes/switches. As you said those are already present in individual game slave, but can also be edited to include some more.
AFAIK, people with WHDLOAD issues mainly report problems with a 040 compatibility which is a separate issue (decreasing issue in any aspect of WHDLOAD progress, for sure) and common, rookie footfalls of meeting minimum requirements (misspelling Kickstart RTB/KICK files, low RAM, poor's man 68000 etc). Issues like NMI or RESLOAD are less common since those cover HW banging or even issues with different WHDLOAD versions (so called KickEMU compilers etc.)
As you can see, issues exists, but they can be remedied.
Personally, I have around 100 WHDLOAD installs on my setup; maybe 5 of them had some problem which was sorted out after few forum searches, no big deal.
And all that comes with a HW which is known to be pretty dodgy with respect to operation (GVP A530 uses some not-so-great glue logic tricks for basic operations and that proved bad compared to other competitive designs. As a final outcome, I can't properly use SubWay USB on this config - board is a bad IRQ handler).