CacheControl and VBR from bootblock

[h0ffman]

Been having cache and what I think are VBR problems on Metal Gear when running from floppy. I think the easiest way to deal with this, bearing in mind system is shortly killed and ram trashed after boot, is to disable all caches and ensure the VBR at $0.

Anyone got an example?

Also just wanna confirm something with WHDLoad settings. It seems that even with NoCache setting, I'm getting so oddities on the ACA500+ boards. Feels like a data cache issue but not owning one its pretty hard to determine.

Are there any other settings which I should consider here?

[ross]

http://eab.abime.net/showthread.php?t=96233

[roondar]

Originally Posted by h0ffman

It seems that even with NoCache setting, I'm getting so oddities on the ACA500+ boards. Feels like a data cache issue but not owning one its pretty hard to determine.

The ACA500/ACA500+ have a 68000 on them running at a high clock speed. They also have true Fast RAM, which isn't slowed down by DMA access. However, they do not have either instruction or data caches because that only came with the 68020+*

So the good news is that the ACA500 cards can't cause cache issues, the bad news is well - that means it's something else
Note that I am assuming here that the card is a base ACA500/ACA500+, not one where someone has plugged in an external accelerator card.

*) Technically the 68010 also has a kind of cache in it's 'loop mode', but that tends to not cause nearly as many issues as the 68020+ caches as it's only three words long and so is only used on a very specific type of code.

[h0ffman]

oh bloody hell, how did I miss that.

[h0ffman]

Originally Posted by roondar

The ACA500/ACA500+ have a 68000 on them running at a high clock speed. They also have true Fast RAM, which isn't slowed down by DMA access. However, they do not have either instruction or data caches because that only came with the 68020+*

So the good news is that the ACA500 cards can't cause cache issues, the bad news is well - that means it's something else
Note that I am assuming here that the card is a base ACA500/ACA500+, not one where someone has plugged in an external accelerator card.

*) Technically the 68010 also has a kind of cache in it's 'loop mode', but that tends to not cause nearly as many issues as the 68020+ caches as it's only three words long and so is only used on a very specific type of code.

Hmm.. well the sucks.

[hooverphonique]

I thought data cache was disabled until SetPatch was run, but maybe that's only valid for 68040/68060?

[phx]

I would say that's only valid for 68020/68030.

Usually caches and MMU should be disabled and VBR is zero when the boot block is entered, but I have seen some A1200 configurations where this is not the case. I guess there is BootROM code coming with the Blizzard060 or BPPC boards which already enables everything before booting? At least I have never seen that on my CSPPC systems. I would be curious to find out the details as well...

Those Blizzard boards were also infamous for loading a 68060.library or ppc.library very early in the boot process, but I'm not sure if there is a connection.

[ross]

This is my full disabler.

Me too, as phx, have had reports from users for caches, VBR and MMU already active/modified before the execution of the booblock.
Usually only the instruction cache is active.
But if you want to take control of the system later then you should use something more complete.

This code snipped is based on keirf's one that's based on mine (yes, recursively ).
I have already used it successfully and it is quite optimized, but always available for suggestions.

Warning: execute this code from 'non-remapped' memory area (chip-RAM is good); I've no idea on what happens if you execute it from memory that's on MMU tree..

; Disables caches, MMU and sets VBR to zero, full 68k family processors support

	lea _super_disable(pc),a5
	jsr	_LVOSupervisor(a6)
	...


__trap:
	and.w	d2,(sp)			; clear CCR.Z
	addq.l	#4,2(sp)		; skip faulting instruction
	rte

_super_disable:
	subq.l	#8,a5			; trap for unsupported instructions
	move.l	a5,($10).w

	moveq	#0,d0
	moveq	#0,d1
	moveq	#~4,d2

.010
	; VBR=0
	dc.l	$4e7b0801		; movec d0,VBR
	dc.l	$4e7a1002		; movec CACR,d1
	tst.l	d1			; Bit 31 set? (68040+ Data Cache Enabled)
	bpl.b	.020			; Skip CPUSHA if not (020/030 boards fail)
	dc.w	$f478			; CPUSHA DC	; 68040+ only

.020
	; Disable caches
	moveq	#$10,d1			; IBE only on 030
	tst.l	d0			; set CCR.Z
	dc.l	$4e7b1002		; movec d1,CACR
	bne.b	.done			; if CCR.Z bail on 000/010

	;tst.l	d0			; CCR.Z already set if I get here
	dc.l	$4e7a1004		; movec ITT0,d1	; 68040+ only
	beq.b	.060			; CCR.Z=1 if 040/060

	; Detect 020 vs 030: check IBE
	dc.l	$4e7a1002		; movec CACR,d1
	tst.l	d1			; d1=$10 if running on 68030
	beq.b	.done			; bail on 68020

.030
	; Disable 030 MMU
	clr.l	(a5)
	dc.l	$f0154000		; pmove.l (a5),TC
	dc.l	$f0150800		; pmove.l (a5),TT0
	dc.l	$f0150c00		; pmove.l (a5),TT1
	bra.b	.done

.060
	; Disable superscalar dispatch
	dc.l	$4e7b0808		; movec d0,PCR	; 68060 only

.040
	; Disable 040/060 MMU
	move.l	#$0000c040,d1
	dc.l	$4e7b1006		; movec d1,DTT0
	move.l	#$00ffc000,d1
	dc.l	$4e7b1004		; movec d1,ITT0
	dc.l	$4e7b1005		; movec d1,ITT1
	dc.l	$4e7b1007		; movec d1,DTT1
	dc.l	$4e7b0003		; movec d0,TC
	dc.l	$4e7b0806		; movec d0,URP
	dc.l	$4e7b0807		; movec d0,SRP

.done
	rte

Yes, all the MMU stuff is a bit overkill.
Usually those with active MMU know why and know how to start problematic programs.
So in 99% of cases you just disable caches and set VBR=0 (or use WHDLoad to do all the work).

But it is always useful to have exhaustive informations

[hooverphonique]

very exhaustive

instead of "subq.l #8,a5", I would write "subq.l #_super_disable-__trap,a5" just to avoid any surprises down the line

[Thomas Richter]

Originally Posted by phx

Usually caches and MMU should be disabled and VBR is zero when the boot block is entered, but I have seen some A1200 configurations where this is not the case. I guess there is BootROM code coming with the Blizzard060 or BPPC boards which already enables everything before booting?

All of them have some sort of "emergency emulation code" already active at boot time, including the even the Blizzard 2060, but not in the form of a 68060.library. That a 68060.library is in ROM only appeared with later PPC models. This "emergency code" is sufficient to address some issues with known boot devices, e.g. it includes emulation code for MOVEP, which is used by some ALF controllers.


I do not recall that they relocate the VBR, though.

[Thomas Richter]

Originally Posted by ross

Yes, all the MMU stuff is a bit overkill.

All of this is overkill... There is an exec function which can be used consistently through all CPU models to enable and disable caches. Please don't use CPU-specific code if exec can do it for you.


Disabling the MMU is generally not advisable, even more so as the kickstart you see without the MMU may be different from the kickstart with the MMU. There is a WithoutMMU() function in the mmu.library you may use to run a short program segment with the MMU disabled, though recall that you cannot savely call any Os function without the MMu running.

[ross]

Originally Posted by Thomas Richter

All of this is overkill... There is an exec function which can be used consistently through all CPU models to enable and disable caches. Please don't use CPU-specific code if exec can do it for you.

I don't want to restart the usual system/non-system dispute,
I know exactly how you think and your method is absolutely valid.

But there are those who are also interested in this type of speeches and in understanding what happens behind the scenes.

So in my opinion one useful thing you can do is very simple: write a piece of code, preferably in assembler, that does the SAME things as my piece of code, so whoever wants to use mine uses mine and whoever wants to use yours uses yours.
And we are all happy

I, for example, have no idea how to disable the 060 superscalar dispatch with system functions.

Disabling the MMU is generally not advisable, even more so as the kickstart you see without the MMU may be different from the kickstart with the MMU. There is a WithoutMMU() function in the mmu.library you may use to run a short program segment with the MMU disabled, though recall that you cannot savely call any Os function without the MMu running.

With my snippet you don't need to know if the kickstart is remapped, you don't need to know who's running the MMU, you don't even need a KS!
Ok, you destroy the system and you will never be able to use OS functions again, but everything was born for that: take control of the machine and abuse it at will

Sorry for this.