|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004780||Frontier||[All Projects] General||public||2020-08-01 09:08||2020-08-14 08:41|
|Assigned To||JOTD||Project Info||Frontier (GameTEK/Konami)|
|Summary||0004780: Many people have noticed that the slave turns off the Instruction Cache. This|
|Description||GameVersion: english,pal,2 disks|
SlaveVersion: 1.0 from 20.05.2000
Many people have noticed that the slave turns off the Instruction Cache. This is not needed. In fact it makes the game run slower than expected. It has an especially serious effect on Vampire boards, because turning off the Instruction Cache triggers "turtle mode", which slows the computer to 68020 speed.
Is it possible to fix the slave, please?
|Tags||No tags attached.|
|KickROM||45 - Kick 3.1.4|
can you prove that instruction cache is off?
for instance, by running HRTMon in the background and interrupting the game? or with an emulator?
I just checked and instruction & data caches are on.
I've rebuilt both CD32 & floppy version against new versions of kickemu, can you test that?
|I'm pretty sure that whdload doesn't expect a 68080 and isn't aware of its cache settings.|
|this is a 68080 specific issue|
Sorry about the late response!
I was able to reproduce this using WinUAE and AmigaOS 3.9, both with the original slave and the new slave you attached.
- On a 68030, the CACR register changes from 00002111 to 00002000 when the slave starts. Meaning: The instruction and data caches get *turned off* by WHDLoad. I can see the problem here.
- On a 68040, the CACR register changes from 00008000 to 80008000 when the slave starts. Meaning: The instruction cache remains on, and the data cache gets turned on by WHDLoad. No problem here.
So, this problem is not specific to the 68080. I feel that, if you fix the problem for the 68030, then it will be fixed for the 68080 automatically as well. If you are planning to do this in the duplicate bug (bug #0004777), then it's fine, you can close this current bug. :)
Still, we have not explained what WHDLoad is *exactly* doing on the 68080.
As far as I know, the 68080 introduces itself to the OS as a 68040. And it behaves just like a 68040. If WHDLoad is detecting it as a 68040, then why isn't it working perfectly, like on a normal 68040??
I have a theory, but I don't know if it makes sense:
WHDLoad detects the 68080 as an "unknown CPU". Then it falls back to the default code path for the 68030. So it calls the OS function to disable the ICache and the DCache. (I don't know if such an OS function exists; I am just assuming things.) The OS function knows that it is a 68040 CPU, and so it "correctly" disables the caches on the 68080.
Is this theory plausible? If you fix the bug for the 68030, and if this automatically fixes the problem on the 68080, then maybe this theory is correct. :)
Thanks and best wishes!
Here is the OS function I was "imagining":
And I don't know if the requirement of a 1.3 ROM for this slave could have this strange effect..?
I've found out that the 68080 enables *both* the 68030 bit and the 68040 bit in SysBase->AttnFlags. So if WHDLoad is checking the 68030 bit *before* checking the 68040 bit, it will detect the 68080 as a 68030. This is fine; the 68080 supports all instructions of the 68030. But then, according to my theory, WHDLoad enters the (buggy) code path where it calls CacheControl() to *turn off* the caches. CacheControl() thinks that this is a 68040 CPU, and so it "correctly" disables the caches on the 68080.
So, if you solve this "accidental cache disabling" problem for the 68030, it should automatically be solved for the 68080. :)
Last edited: 2020-08-13 15:06
68040 is also seen as at least a 68030. It's incremental. No bug.
I have updated the attached .zip with latest fixed slaves. Can you test?
Thank you, it works perfectly!! We all are very, very appreciative of your work!! Best wishes!!
(I just opened the bug to say that it worked; you can close it again. :))
|glad it worked, learned a new thing on whdload|
|2020-08-01 09:08||administrator||New Issue|
|2020-08-01 09:08||administrator||Status||new => assigned|
|2020-08-01 09:08||administrator||Assigned To||=> JOTD|
|2020-08-10 22:57||JOTD||Relationship added||has duplicate 0004777|
|2020-08-10 23:05||JOTD||File Added: Frontier13_beta.zip|
|2020-08-10 23:05||JOTD||Note Added: 0009034|
|2020-08-11 09:18||JOTD||Note Added: 0009035|
|2020-08-11 22:30||JOTD||Note Added: 0009036|
|2020-08-13 06:58||MuadDib||Note Added: 0009038|
|2020-08-13 07:20||MuadDib||Note Added: 0009039|
|2020-08-13 11:58||MuadDib||Note Added: 0009040|
|2020-08-13 15:05||JOTD||File Deleted: Frontier13_beta.zip|
|2020-08-13 15:05||JOTD||File Added: Frontier13_beta.zip|
|2020-08-13 15:06||JOTD||Note Added: 0009041|
|2020-08-13 15:06||JOTD||Note Edited: 0009041||View Revisions|
|2020-08-13 15:41||JOTD||Status||assigned => closed|
|2020-08-13 15:41||JOTD||Resolution||open => fixed|
|2020-08-13 19:35||MuadDib||Status||closed => feedback|
|2020-08-13 19:35||MuadDib||Resolution||fixed => reopened|
|2020-08-13 19:35||MuadDib||Note Added: 0009042|
|2020-08-14 08:41||JOTD||Status||feedback => closed|
|2020-08-14 08:41||JOTD||Note Added: 0009044|