2022-01-16 10:47 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004780Frontier[All Projects] Generalpublic2020-08-14 08:41
Assigned ToJOTDProject InfoFrontier (GameTEK/Konami)
Summary0004780: Many people have noticed that the slave turns off the Instruction Cache. This
DescriptionGameVersion: 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?
TagsNo tags attached.
ChipMem2 MB
FastMem128 MB
WorkbenchOS 3.1.4
KickROM45 - Kick 3.1.4
Attached Files

has duplicate 0004777closedJOTD For some reason slave version 1.2 (01.11.08) done by JOTD will disable the CPU 


note ~0009034

JOTD (developer)


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?

note ~0009035

JOTD (developer)

I'm pretty sure that whdload doesn't expect a 68080 and isn't aware of its cache settings.

note ~0009036

JOTD (developer)

this is a 68080 specific issue

note ~0009038

MuadDib (reporter)

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!

note ~0009039

MuadDib (reporter)

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

note ~0009040

MuadDib (reporter)

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

note ~0009041

JOTD (developer)

Last edited: 2020-08-13 15:06

View 2 revisions

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?

note ~0009042

MuadDib (reporter)

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

note ~0009044

JOTD (developer)

glad it worked, learned a new thing on whdload

-Issue History
Date Modified Username Field Change
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
+Issue History