25 May 2021, 23:46 | #1 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 773
|
CacheControl and VBR from bootblock
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? |
26 May 2021, 00:05 | #2 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,498
|
|
26 May 2021, 00:22 | #3 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,438
|
Quote:
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. |
|
26 May 2021, 00:24 | #4 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 773
|
oh bloody hell, how did I miss that.
|
26 May 2021, 00:26 | #5 | |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 773
|
Quote:
|
|
26 May 2021, 12:21 | #6 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
I thought data cache was disabled until SetPatch was run, but maybe that's only valid for 68040/68060?
|
26 May 2021, 14:23 | #7 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,552
|
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. |
26 May 2021, 16:09 | #8 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,498
|
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.. Code:
; 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 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 |
26 May 2021, 16:23 | #9 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
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 |
26 May 2021, 17:07 | #10 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,330
|
Quote:
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. |
|
26 May 2021, 17:09 | #11 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,330
|
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. |
26 May 2021, 17:57 | #12 | ||
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,498
|
Quote:
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. Quote:
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. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Bootblock | jarre | Coders. General | 5 | 19 April 2022 22:31 |
SetPatch / CacheControl() | dissident | Coders. System | 17 | 04 March 2018 17:01 |
quit key on 68000 (non-vbr) systems | Yulquen74 | project.WHDLoad | 5 | 04 March 2016 18:01 |
Error in game VBR detected... | franeti | project.WHDLoad | 1 | 22 April 2015 23:43 |
|
|