The WHDLoad '040 compatibility problems list

[macce2]

With NoCache option, some games with problems do work. However, in some cases disabling caches slows things down seriously. SWOS, for example. With Lotus 3 NoCache won't help. That' s the case with relatively f3w games, however.

[zipper]

Rather use OS CPU command, CPU nodatacache nocopyback leaves instruction cache on. Can't remember how Lotus3 works - at least I played it with an 060. Probably just instruction cache on like with Lotus 2.

[daxb]

Hmm... with my 040/40 I get the same error as you with Lotus 3. When using NoCache all works fine. If that doesn`t help for you then make a bugreport, please.

[Irek´72]

I've just tested Lotus 3 on my Blizzard 040/25 and the game worked fine without additional options on my setup.
BTW: the game SWOS works only with CACHE option without problems on 040/25 machines.

[macce2]

I eventually got Lotus 3 to work. I booted directly to DOS with ECS chipset (?!) disabling Caches in early startup menu. Then I started Lotus 3 WHDload with NoCache option. I didn't use Preload option.
I only tested single player game, however. I'm afraid the two player game to have issues..?! :-o

[Hewitson]

Would it be fair to say that any slave requiring NOCACHE or other tooltypes was poorly written? Surely there's a way to disable the caches in the slave?

[zipper]

Can't say - but then different processors should have different slaves. And nocache is overkill as many games do use instrucrion cache but barf at data cache (030 and up) and 040/ 060 specific caches. Then some games expect VBR=0. too.

[daxb]

It might be the case but generally no. The slave author isn`t always able to test on different systems. It may work fine on his system(s) without NoCache. Sometimes it is better to give the user the choice to disable cache. Details about this should be answered by slave writer.

[majestyx]

Originally Posted by Irek´72

I can confirm it. After the start the game crashes with an error on my set up as well. Then I tried to start the game with a NOMMU option and it worked without any problems. There are some games which only work with this option without problems on 040 CPU.
Here are some of them listed : The WHDLoad 68040 Users Group

Awesome! Came here trying to get this to work on my A4000D/040 and kept getting a fatal Out of Range error (something to that effect). The NOMMU option solved it. Weird thing is I was actually able to run it from the diskette, although it moved way too fast. Glad someone figured out how to get this to run.

[Irek´72]

@majestyx: I'm glad I could help. Well, I always use the NOMMU option in case of weird game crashes. Sometimes, it helps and sometimes it does not.

Btw: There is a little update in the WHDLoad 68040 Users Group....

[Irek´72]

Originally Posted by Graham Humphrey

I also started a user group dedicated to such things (Irek's idea, not mine); if you own an '040 please join so we can see how many people these problems affect.

Exactly 10 years ago we created our WHDLoad 68040 users group.
I think that we have managed to solve some problems together. Of course, without great support from the entire WHDLoad team that would have been impossible. I wanted to say thank you.

[daxb]

My impression was/is that there isn't such a big problem or incompatibility with 68040 like some people say in forums. At least no bugs in 68040 that cause software failures.

[Jacques]

Is there maybe a way/workaround to use NoCache or Cache (disables data cache only) globally? I find it real problem these parameters are not allowed in WHDLoad prefs. Especially I like to use TinyLauncher and have 060, so it would be really good to set it once and for all, since I haven't managed TinyLauncher to use ToolTypes at all (just guru), not to mention setting NoCache tooltype for too many games launched from icon seems not the way.

[jotd]

if you have to disable caches, then the slave should be updated. Open a bug report on http://mantis.whdload.de, and enjoy the cache on the rest of your collection.

[DJ Mike]

I'm interested in the problems with Wiz 'n' Liz. I'm currently updating a few things about this patch. Unfortunately I don't have an 040 to see the problems with this. I did originally fix the blits missing waits when I released a patch in 2006, but this seems not to be the extent of the game's issues.

It seems to have a wild combination of things going on to pull off the speed it runs at.
- Some blits run without waiting for them to complete (these I patched in 2006)
- Most blits run and do check for finish, using "btst #6,dmaconr" - but these also enable bltnasty/bltpri flag in dmacon before they start (and disable when finished)

I noticed when running in WinUAE that, in 2 player mode, the whole playfield seems to glitch from time to time. However, that seems to be fixed by enabling Cycle Exact mode, so I don't know if it's relevant.

I tried patching out bltnasty flag, but that causes slowdown to appear when the screen is busy, so it seems necessary.

I have some code to replace the limited "btst #6,dmaconr" with Bert's better BLITWAIT macro that we could try, but I'd need testers to see if this works or not. I'm also not convinced if it will do anything given the previously mentioned bltnasty flag being employed for these (which means the CPU has to wait for the channel to be free anyway...)

Unfortunately I have limited familiarity with blitting and other graphics DMA concerns, but I'm always eager to learn more about it. :-)

[jotd]

btst #6,$dff096 isn't going to work because dff096 is write-only... you mean dmaconr

[DJ Mike]

Originally Posted by jotd

btst #6,$dff096 isn't going to work because dff096 is write-only... you mean dmaconr

Pardon my typo (early morning post) - I do mean dmaconr. I have edited original post.

[jotd]

let's remember that whdload has nothing to do with 68040 issues.

Some games themselves aren't 020 compliant, let alone 040 compliant. So when adapting a game, he A4K must be taken into account

Last example: Music in monkey island going too fast, and on A4000 (not seen in winuae)

Fixed by 1) moving Level 6 ack in the end of the routine and 2) doubling it (the infamous "a4k" bug that requires in some situations to write twice in intreq.

Not sure of which part fixed it but it worked.

[DJ Mike]

Originally Posted by jotd

let's remember that whdload has nothing to do with 68040 issues.

I wasn't suggesting otherwise. But I do at least try to address issues if I can when I make patches, which I know you and other devs do as well.

However, 68040 seems to cause a particularly unique set of issues that can be difficult to overcome - even compared to 68060. Particularly difficult for me as I don't have an 040 accelerator to test on - and emulation isn't a substitute.

Do you have any insights on what tends to cause issues between 68040 and graphics DMA? I'm aware the caches cause problems but is that because of caching running instructions too fast, or perhaps because of faulty assumptions about the state of readable DMA registers?