WHD Load: Games Keep CRASHING!!!

[barney]

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

[TheGoose]

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.

[Lockon_15]

@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.

[TheGoose]

@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).

[Lockon_15]

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).