WHDLoad MantisBT - Frontier
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004780Frontier[All Projects] Generalpublic2020-08-01 09:082020-08-14 08:41
ReporterMuadDib 
Assigned ToJOTD 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionreopened 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
MachineA1200
CPUApollo
CPUSpeed75
ChipSetAGA
GFXCardOther
ChipMem2 MB
FastMem128 MB
WorkbenchOS 3.1.4
KickROM45 - Kick 3.1.4
KickSoftNone
WHDLoad18.5
importedyes
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?
Thanks!
TagsNo tags attached.
Relationships
has duplicate 0004777closed JOTD For some reason slave version 1.2 (01.11.08) done by JOTD will disable the CPU 
Attached Fileszip Frontier13_beta.zip (10,264) 2020-08-13 15:05
http://mantis.whdload.de/file_download.php?file_id=1030&type=bug

Notes
(0009034)
JOTD   
2020-08-10 23:05   
hi

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?
(0009035)
JOTD   
2020-08-11 09:18   
I'm pretty sure that whdload doesn't expect a 68080 and isn't aware of its cache settings.
(0009036)
JOTD   
2020-08-11 22:30   
this is a 68080 specific issue
(0009038)
MuadDib   
2020-08-13 06:58   
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!
(0009039)
MuadDib   
2020-08-13 07:20   
Here is the OS function I was "imagining":
http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node033A.html

And I don't know if the requirement of a 1.3 ROM for this slave could have this strange effect..?
(0009040)
MuadDib   
2020-08-13 11:58   
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. :)
(0009041)
JOTD   
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?
(0009042)
MuadDib   
2020-08-13 19:35   
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. :))
(0009044)
JOTD   
2020-08-14 08:41   
glad it worked, learned a new thing on whdload

Issue History
Date ModifiedUsernameFieldChange
2020-08-01 09:08administratorNew Issue
2020-08-01 09:08administratorStatusnew => assigned
2020-08-01 09:08administratorAssigned To => JOTD
2020-08-10 22:57JOTDRelationship addedhas duplicate 0004777
2020-08-10 23:05JOTDFile Added: Frontier13_beta.zip
2020-08-10 23:05JOTDNote Added: 0009034
2020-08-11 09:18JOTDNote Added: 0009035
2020-08-11 22:30JOTDNote Added: 0009036
2020-08-13 06:58MuadDibNote Added: 0009038
2020-08-13 07:20MuadDibNote Added: 0009039
2020-08-13 11:58MuadDibNote Added: 0009040
2020-08-13 15:05JOTDFile Deleted: Frontier13_beta.zip
2020-08-13 15:05JOTDFile Added: Frontier13_beta.zip
2020-08-13 15:06JOTDNote Added: 0009041
2020-08-13 15:06JOTDNote Edited: 0009041bug_revision_view_page.php?bugnote_id=9041#r1255
2020-08-13 15:41JOTDStatusassigned => closed
2020-08-13 15:41JOTDResolutionopen => fixed
2020-08-13 19:35MuadDibStatusclosed => feedback
2020-08-13 19:35MuadDibResolutionfixed => reopened
2020-08-13 19:35MuadDibNote Added: 0009042
2020-08-14 08:41JOTDStatusfeedback => closed
2020-08-14 08:41JOTDNote Added: 0009044