Improve WHDLoad when used with a 060?

[keropi]

I just noticed that some games (like AB3D II) stop working, because I changed my 030 accel with a p5 1260 ... Is there any way to improve compatibility? Some games like Sabre Team freeze the maschine....

and anothere one: how cool would be to implement SAVE STATES in WHDLoad? can it be done? like the software action replay, GAME WIZARD PRO that I used to have on my 386, u could amongst other nice things to SAVE the current prog, and restore it later.... a full mem/vga/sound state!

[Shoonay]

Those are the "future plans" for WHDLoad development...

http://www.whdload.de/docs/en/future.html

[adolescent]

Have you tried the various compatibility tooltypes? I've yet to find a WHDLoad game that wouldn't work on my A1260 or CSMK3.

Remember, this is what WHDLoad was made for...

[jotd]

I doubt generic save state will be supported one day since SNOOP slows down the games quite a lot (MMU trap on custom chip control page to get their values when written)

In JST I had implemented such a feature without the need of SNOOP stuff, but the slave (game-specific) had to perform some actions like restoring the copperlists... Apart from that it worked, but was not 100% reliable. It helped me (& Ralf) finishing some slaves, saved some time to reach some point.

Bert, any comments? Am I too much pessimistic?

JOTD

[keropi]

ah, nice ... "freeze" :D
what compatibility tootypes?

[Bloodwych]

Well these can be set in the prefs or tool types keropi but I'm not sure which help with the 060:

;
; global configuration file for WHDLoad
; searched as "S:whdload.prefs"
;
; CLI-Arguments and ToolTypes will overwrite these !
;

;ButtonWait ;wait for button pressed (slave must support this)
;ChipNoCache ;disable cachebility of Chip-Memory
;CoreDumpPath=T: ;path for coredump files
;DebugKey=$5b ;rawkey code to quit with coredump (debug)
;ExecuteStartup=rx offline.rexx ;command to execute on WHDLoad startup
;ExecuteCleanup=rx online.rexx ;command to execute on WHDLoad exit
;Expert ;selects expert mode
;FreezeKey=$5d ;rawkey code to enter HrtMon/TK
;MMU ;use MMU (for 68030)
;NoAutoVec ;ignore unwanted autovector interrupts
;NoFilter ;disable audio filter
;NoFlushMem ;do not flush memory
;NoWriteCache ;disable the disk write cache
;QuitKey=$5a ;rawkey code to quit
;ReadDelay=150 ;wait after reading from disk (1/50 seconds)
;RestartKey=$5c ;rawkey code to restart
;ShowRegs=SYS:Utilities/MuchMore W WL=80 WT=80 WW=582 WH=700 ;command for Show Regs
;SplashDelay=200 ;time to display splash window (1/50 seconds)
;WriteDelay=150 ;wait after saving something to disk (1/50 seconds)

[AMIGAZ]

Speaking about WHDLOAD settings etc...I have a problem with my WHDLOAD v16.3 and Blizzard 1260 setup:

On some games I get an error message from WHDLOAD telling me I have the MMU disabled and those games doesn't start.
I read that my 68060 CPU's MMU is still used with WHDLOAD, where can I change so WHDLOAD use it always?

/J-J

[adolescent]

what compatibility tootypes?

In general, the tooltypes like NOCACHE, NOAUTOVEC, NOVBRMOVE, NOMMU, PAL or NTSC can help with hardware compatibility. In practice, I've only had to use NOCACHE to disable CPU caches, and PAL to force a PAL mode on my NTSC system to get everything running (this depends on the install of course).

[jotd]

Speaking about WHDLOAD settings etc...I have a problem with my WHDLOAD v16.3 and Blizzard 1260 setup:

On some games I get an error message from WHDLOAD telling me I have the MMU disabled and those games doesn't start.
I read that my 68060 CPU's MMU is still used with WHDLOAD, where can I change so WHDLOAD use it always?

/J-J
Maybe that's because the icon tooltypes of some of your games have the NOMMU option active. Check the icons, or run WHDLoad from CLI

I think icon tooltypes override S:WHDLoad.prefs, so setting MMU in WHDload.prefs would have no effect IMHO (MMU is set by default).

JOTD

[adolescent]

Try running showconfig to see if the 060/MMU is detected. If not, then your 060 libraries are incorrectly installed.

[AMIGAZ]

Tried removing the nommu tooltypes on the two games that crash but it didn't work, the crashed before they started with an error message I have to write down and post.
I have the latest 68060 libs installed, I run cyberpatcher also at startup...it's in my WBstartup folder

[Wepl]

I doubt generic save state will be supported one day since SNOOP slows down the games quite a lot (MMU trap on custom chip control page to get their values when written)

In JST I had implemented such a feature without the need of SNOOP stuff, but the slave (game-specific) had to perform some actions like restoring the copperlists... Apart from that it worked, but was not 100% reliable. It helped me (& Ralf) finishing some slaves, saved some time to reach some point.

Bert, any comments? Am I too much pessimistic?

JOTD

I really like to implemet this, but due lack of free time it's unclear when.
Technical not a big problem, MMU required and several internal adaption for.
I think it would be useful also a lot during install development phase.

[jotd]

I really like to implemet this, but due lack of free time it's unclear when.
Technical not a big problem, MMU required and several internal adaption for.
I think it would be useful also a lot during install development phase.

Well, maybe the overhead would not be too high since SNOOP checks stuff, whereas this new mode would only store and pass the values. And read access would be free so only page faults on writes, you're right, it's feasible with a fast CPU. Please do it :bash