0004780: Many people have noticed that the slave turns off the Instruction Cache. This

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Tags

No tags attached.

Machine

A1200

CPU

Apollo

CPUSpeed

ChipSet

AGA

GFXCard

Other

ChipMem

2 MB

FastMem

128 MB

Workbench

OS 3.1.4

KickROM

45 - Kick 3.1.4

KickSoft

None

WHDLoad

18.5

imported

yes

Attached Files

Frontier13_beta.zip (10,264 bytes) 2020-08-13 15:05

Relationships

has duplicate

0004777

closed

JOTD

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

Relationships

Notes
note ~0009034 JOTD (developer) 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?

note ~0009035 JOTD (developer) 2020-08-11 09:18	I'm pretty sure that whdload doesn't expect a 68080 and isn't aware of its cache settings.

note ~0009036 JOTD (developer) 2020-08-11 22:30	this is a 68080 specific issue

note ~0009038 MuadDib (reporter) 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!

note ~0009039 MuadDib (reporter) 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..?

note ~0009040 MuadDib (reporter) 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. :)

note ~0009041 JOTD (developer) 2020-08-13 15:06 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) 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. :))

note ~0009044 JOTD (developer) 2020-08-14 08:41	glad it worked, learned a new thing on whdload

Notes

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