| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 62 online users.
» 1 Member(s) | 60 Guest(s)
Google
|
| Latest Threads |
Make it to 10,000
Forum: General Discussion
Last Post: Fifty
5 hours ago
» Replies: 2,629
» Views: 1,852,953
|
Bullet Bill Speed Modifie...
Forum: Offline; Item
Last Post: Brawlbox
05-16-2022, 01:55 PM
» Replies: 6
» Views: 4,815
|
Broadway SPR Rules + Note...
Forum: Resources and References
Last Post: Vega
05-15-2022, 02:37 PM
» Replies: 0
» Views: 80
|
Utilizing the Condition R...
Forum: Power PC Assembly
Last Post: Vega
05-15-2022, 01:07 PM
» Replies: 0
» Views: 66
|
Cache Basics
Forum: Power PC Assembly
Last Post: Vega
05-15-2022, 12:59 PM
» Replies: 0
» Views: 52
|
Draggable items code
Forum: Code Support / Help / Requests
Last Post: Vega
05-14-2022, 12:37 PM
» Replies: 1
» Views: 144
|
Gecko Region Code Porter
Forum: Resources and References
Last Post: TheNinjaKingOW
05-13-2022, 11:50 AM
» Replies: 1
» Views: 88
|
setting layout message id...
Forum: Code Support / Help / Requests
Last Post: jawa
05-11-2022, 05:01 AM
» Replies: 2
» Views: 121
|
Coding Questions and othe...
Forum: Code Support / Help / Requests
Last Post: Hackwiz
05-08-2022, 11:45 PM
» Replies: 109
» Views: 23,484
|
EVA Usage List
Forum: Resources and References
Last Post: Seeky
05-04-2022, 04:38 PM
» Replies: 1
» Views: 121
|
|
|
| Broadway SPR Rules + Notes + Mini Guides + Misc Random Stuff |
|
Posted by: Vega - 05-15-2022, 02:37 PM - Forum: Resources and References
- No Replies
|
 |
Broadway SPR Rules + Notes + Mini Guides + Misc Random Stuff
I have made this document when I needed a quick reference card to messing around with Broadways' special purpose registers. Might as well share it for anyone who needs it.
Sync and isync are synchronizing instructions. They play a huge role when modifying the Hardware Registers and certain other Special Purpose Registers.
Times when sync or isync are required~
1. sync is required BEFORE & AFTER any writes to the L2CR
2. isync is required BEFORE & AFTER modifying the ICE bit of HID0
3. isync is required BEFORE modifying ILOCK bit of HID0
4. sync is required BEFORE & AFTER modifying DCE bit of HID0**
5. sync is required BEFORE modifying DLOCK bit of HID0
6. isync is required AFTER any mtsr instruction when the segment registers effects an Instruction EA
7. isync is required AFTER any mtsrin instruction when the segment register(s) effects the Instruction EA
8. isync is required BEFORE & AFTER any mtsr instruction when the segment registers effect a Data EA
9. iysnc is required BEFORE & AFTER any mtsrin instruction when the segment registers effect a Data EA
10. sync is required BEFORE any modification to SDR1
11. isync is required AFTER any modification of SDR1
12. sync is required BEFORE modifying the POW bit of the MSR
13. isync is required AFTER modifying ANY of the following MSR bits....
POW, PR, ME, FP, SE, BE, IR, DR, RI, FE0, FE1
14. sync is required AFTER modifying the L2FM bit of HID4
15. sync is required AFTER reading the DMAQL bit(s) of HID2; you cannot write to these bits btw
16. sync is required AFTER writing the F bit high in the DMAL Register
17. isync is required AFTER writing to the IABR
18. sync is required AFTER writing to the DABR
19. isync is required AFTER modifying an IBAT Register***
20. isync is required BEFORE & AFTER modifying a DBAT Register****
21. isync is required BEFORE a tlbie instruction if the TBL effects Data
22. isync is required AFTER a tlbie instruction where the TLB effects Instructions
23. sync is required AFTER a tblie instruction if the TBL effects Data
24. tlbsync is required AFTER a TLB invalidation
***You can have multiple IBAT Registers be modified consecutively, with a single isync at the end.
****You can have multiple DBAT Registers be modified consecutively, with a single isync at the beginning & end
References for above isync/sync rules~
1. Broadway User Manual page 319.
2. Broadway User Manual page 137 for the 'BEFORE'. Broadway User Manual page 319 for the 'AFTER'
3. Broadway User Manual pages 60 & 137.
4. Broadway User Manual page 136 for the 'BEFORE'. Regarding the 'AFTER' there is no reference. Not mentioned in the Broadway manual but its a high probability since you are changing how Data Cache is executed.
5. Broadway User Manual pages 60 & 136.
6. PowerPC Microprocessor Family: The Programming Environments, table 2-23 (page 2-43)
7. PowerPC Microprocessor Family: The Programming Environments, table 2-23 (page 2-43)
8. PowerPC Microprocessor Family: The Programming Environments, table 2-22 (page 2-41)
9. PowerPC Microprocessor Family: The Programming Environments, table 2-22 (page 2-41)
10. PowerPC Microprocessor Family: The Programming Environments, table 2-22 (page 2-42)
11. PowerPC Microprocessor Family: The Programming Environments, table 2-22 (page 2-42)
12. Broadway User Manual page 330
13. POW Bit - Broadway User Manual page 330
13. PR Bit - Broadway User Manual page 89
13. All other bits: PowerPC Microprocessor Family: The Programming Environments, tables 2-22 & 2-23 (pages 2-41 & 2-43)
14. Broadway User Manual Page 66
15. Broadway User Manual Page 66
16. Broadway User Manual Page 324
17. Broadway User Manual Page 177
18. No reference. High probability. Since an isync is required for the IABR, it would make sense for a sync to be required for the DABR.
19. PowerPC Microprocessor Family: The Programming Environments, table 2-23 (page 2-43)
20. PowerPC Microprocessor Family: The Programming Environments, table 2-22 (page 2-42)
21. PowerPC Microprocessor Family: The Programming Environments, table 2-22 (page 2-42)
22. PowerPC Microprocessor Family: The Programming Environments, table 2-23 (pages 2-43 & 2-44)
23. PowerPC Microprocessor Family: The Programming Environments, table 2-23 (pages 2-43 & 2-44)
24. Broadway User Manual Page 180
NOTE: From everything I have read so far on the Broadway Manual & other PPC manuals, there is never a circumstance that ever requires a back-to-back sync nor a circumstance that ever requires a back-to-back isync.
HID4 rules:
You cannot modify any HID4 L2CR related bits while L2CR is on!
Bit 0 of HID4 must always be written as high (1), it will always read as 1 (reference: Broadway User Manual page 65).
Once bits 3 & 4 are set, its value cannot be lowered (refernce: Broadway User Manual page 66)
Bit 3 & 4 settings:
00 = bus max depth of 2
01 = depth of 3
10 = depth of 4
11 = reserved/unused
Thus if the setting is 10, it cannot be changed at all.
The L2FM field (bits 1 & 2) follow this same rule, can also not be lowered once set (reference: Broadway User Manual page 66)
L2CR Mini Guides:
NOTE: Interrupts should always be masked (disabled) during any L2CR operations.
Following guides are referenced using Section 9.1.3 (Page 318), and Section 9.1.4 (Page 319) of the Broadway User Manual,
Guide for L2 Cache Global Invalidation:
*Interrupts must be masked (disabled) throughout this entire process
*DPM bit of HID0 must be low throughout this entire process
1. Disable the L2CR by setting the L2E bit low
2. Initiate the Global Invalidation by setting the L2I bit high #Steps 1 and 2 MUST be done separately!
3. Run a Loop that constantly checks the L2IP bit. Once that bit is low, the Invalidation has been completed.
Guide to Initialize L2CR:
*Interrupts must be masked (disabled) througout this entire process
*DPM bit of HID0 must be low throughout this entire process
1. Globally Invalidate the L2 Cache (see above guide)
2. Disable L1 instruction cache of HID0
3. Turn on the L2CR by setting the L2E bit high
4. Restore L1 instruction cache of HID0
Guide to Configure L2CR:
*Interrupts must be masked (disabled) throughout this entire process
*DPM bit of HID0 must be low throughout this entire process
1. Turn on the L2CR (see above guide)
2. Disable L1 instructino cache of HID0
3. Set L2CR L2DO bit high #example bit, can be a diff config bit of your choice
4. Restore L1 instruction cache of HID0
Guide to Turn off L2CR:
*Interrupt must be masked (disabled) throughout this entire process
*DPM bit of HID0 must be low throughout this entire process
1. Simply set the L2E bit low
Guide to go into Reduced Power Mode (doze, nap, sleep)
*Interrupts must be ON! for the entire guide
1. Set Desired Power Mode bit high on HID0.
2. Flip POW bit high in the MSR (don't forget your sync before and isync after!)
3. Broadway will enter new power mode in a few clock cycles
Reference: Chapter 10.2 of the Broadway User Manual (pages 327 thru 330)
Reduced Power Mode options:
Doze: Time Base & Decrementer still work
Nap: Time Base & Decrementer still work
Sleep: Time Base & Decrementer do NOT work
You can get out of Doze and Nap mode by setting the Decrementer to the desired value before going into said power mode. Once Decrementer goes below 0, the Decrementer exception will run. Be sure to write some custom code in the Decrementer Exception to get you back to full power mode and back to normal operations.
Miscellaneous fun fact~
While in supervisor mode (MSR: PR bit low) any mtspr instruction involving HID1 or PVR will execute as a nop (reference Broadway User Manual page 90).
|
|
|
| Utilizing the Condition Register |
|
Posted by: Vega - 05-15-2022, 01:07 PM - Forum: Power PC Assembly
- No Replies
|
|
Utilizing the Condition Register
For Advanced ASM Coders
Chapter 1: Intro
Requirements:- Understand the basics of using compare and branch instructions
- Understand binary/bits + Logical Operations
Are your codes ending up with "countless" branches and branch labels? Your codes are in need of some spring cleaning. Sometimes codes that have an excessive amount branches end up "unreadable", making it difficult for others to understand your code or help you debug any errors.
Chapter 2: Condition Register Fundamentals
When you execute any plane jane comparison instruction such as....
...you are actually telling Broadway to run a check and then place the result of said check in Condition Register Field 0.
What is Condition Register Field 0? First thing's first. The register you see in Dolphin that is named "CR" is the Condition Register. It contains the results of previously executed Compare Instructions. Conditional Branch Instructions (i.e. beq) read the data of the Condition Register to determine whether or not a branch route/jump is taken.
The Condition Register contains 7 fields. Field 0 (cr0) thru Field 7 (cr7).
STUVWXYZ
S = cr0
T = cr1
U = cr2
etc etc..
Each field (crF) takes up one DIGIT (half-byte) in the CR. Thus, each crF contains 4 bits of data. You can specify which crF to place the result of the compare instruction in. By default, if no crF is specified in your compare instruction, then cr0 will be used.
is short for...
If you wish to use cr7 instead of cr0, you would write the instruction like this...
An important thing that you must keep in mind is that if you make a comparison that is NOT using cr0, you must also specify the crF in the subsequent branch instruction.
Like this...
Code: cmpwi cr7, r0, 100
beq- cr7, store_data #Notice the specification of cr7 in the instruction
In conclusion, any crF that isn't cr0 must be specified in both compare and branch instructions.
Chapter 3: Condition Register Field Bits and Examining Branch Instructions
Now that you know there are 7 crF's and how to use each one in your comparison + branch instructions, let's cover the crF bits and what each bit represents.
Each crF has 4 bits of data that uses the following structure.- bit 0 = Less-Than flag (LT)
- bit 1 = Greater-Than flag (GT)
- bit 2 = Equal flag (EQ)
- bit 3 = Summary Overflow flag (SO)
CR Bit Table
LT GT EQ SO crfX
0 1 2 3 crf0
4 5 6 7 crf1
8 9 10 11 crf2
12 13 14 15 crf3
16 17 18 19 crf4
20 21 22 23 crf5
24 25 26 27 crf6
28 29 30 31 crf7
Whenever a bit in the crF is high, the condition was true FROM THE MOST RECENT comparison instruction. Whenever a bit was low, the condition was false FROM THE MOST RECENT comparison.
Multiple bits can be flagged high and/or low from a comparison instruction. Now that you understand the crF bits, let's go over what branch instructions actually do.
Code: bge (branch if greater than or equal) = checks bits 1 and 2, if either bit is high, branch is taken
bgt (branch if greater than) = checks bit 1, if bit is high, branch is taken
ble (branch if less than or equal) = checks bits 0 and 2, if either bit is high, branch is taken
blt (branch if less than) = checks bit 0, if it is high, branch is taken
bne (branch if not equal) = checks bit 2, if bit is low, branch is taken
bng (branch if not greater than) = equivalent to ble
bnl (branch if not less than) = equivalent to bge
bns (branch if not summary overflow) = checks bit 3, if bit is low, branch is taken
bso (branch if summary overflow) = checks bit 3, if bit is high, branch is taken
The branch instruction checks the bits of the crF that is specified in the instruction.
Example: 'bge- cr7' checks GT and EQ bits of cr7
Chapter 4: Condition Register specific instructions
Before going into the CR specific instructions, we need to go over its 'format'. The 'format' of a typical CR instruction is this..
crXXX B, B, B #XXX = and, or, andc, orc, nor, xor, eqv
Under this format, you need to specify the exact bit of the entire Condtion Register. The problem with this is that it now becomes a memory game and you have to refer to the earlier CR bit table provided in Chapter 3. Instead of doing that non-sense, you can use this handy formula...
B = 4*crX+ZZ
X = field number (0 thru 7)
ZZ = lt, gt, eq, or so
With this formula, all you need to remember to which Field you want to use and what bit type. So now the easier-to-remember 'format' is this..
crXXX 4*crX+ZZ, 4*crX+ZZ, 4*crX+ZZ
---
CR Based Instructions:
- Condition Register Logical OR~
cror crfD, crfA, crfB #crfA bit is logically OR'd with crfB bit. Result is written to crfD bit.
- Condition Register Logical AND~
crand crfD, crfA, crfD #crfA bit is logically AND'd with crfB bit. Result is written to crfD bit.
- Condition Register Logical NOR~
crnor crfD, crfA, crfD #crfA bit is logically NOR'd with crfB bit. Result is written to crfD bit.
- Condition Register Logical XOR~
crxor crfD, crfA, crfD #crfA bit is logically XOR'd with crfB bit. Result is written to crfD bit.
- Condition Register Logical EQV (XNOR)~
creqv crfD, crfA, crfD #crfA bit is logically XNOR'd with crfB bit. Result is written to crfD bit. Technically, the instruction does a XOR of crfA with crfD, then this temp result is complemented, then writes that result to crfD.
- Condition Register Logical AND with Complement~
crandc crfD, crfA, crfD #crfA bit is logically AND'd with the complemented crfB bit. Result is written to crfD bit.
- Condition Register Logical OR with Complement~
crorc crfD, crfA, crfD #crfA bit is logically OR'd with the complemented crfB bit. Result is written to crfD bit.
Simplified Mnemonics:
- Setting a bit high (set cr0 EQ high)~
crset 4*cr0+eq #creqv 4*cr0+eq, 4*cr0+eq, 4*cr0+eq; crF bit is XNOR'd with itself and resutl written to same bit spot
- Setting a bit low (set cr0 EQ low)~
crclr 4*cr0+eq #crxor 4*cr0+eq, 4*cr0+eq, 4*cr0+eq; crF bit is XOR'd with itself and result written to same bit spot
- Copy-Pasting (Moving) a bit (copy cr0 EQ bit to cr7 EQ bit's spot)
crmove 4*cr7+eq, 4*cr0+eq #cror 4*cr7+eq, 4*cr0+eq, 4*cr0+eq; crF bit is Or'd with itself and result writen to crfD
- Flip a bit (flip cr0 EQ bit and place result in cr7 EQ bit's spot))
crnot 4*cr7+eq, 4*cr0+eq #crnor 4*cr0+eq, 4*cr0+eq, 4*cr0+eq; crF bit is NOR'd with itself and result written to crfD
Also, the following instructions may be handy for you...
- mfcr rD #Contents of the CR is copied to rD
- mtcr rD #Contents of rD is copied to the CR
- mcrf crD, crA #Condition Field A is copied to Condition Field D
Chapter 5: Cleaning up some Code
Let's go over some basic examples of some "CR trickery" to help clean up code. Some examples below won't shorten the source at all (will be same compiled length), but the amount of branches (plus label names) are reduced. This is accomplished by using multiple crF's and using Condition Register specific instructions.
Scenario 1:
If r4 = 1 and r10 = r31, then go to 'store_data'. Otherwise, go to 'dont_store'.
Typical Source
Code: cmpwi r4, 1
bne- dont_store
cmpw r10, r31
beq- store_data
New Source
Code: cmpwi r4, 1
cmpw cr7, r10, r31
crand 4*cr0+eq, 4*cr0+eq, 4*cr7+eq
beq- store_data
Scenario 2:
If r4 = 1 or r10 = r31, then go to 'store_data'. Otherwise, go to 'dont_store'.
Typical Source
Code: cmpwi r4, 1
beq- store_data
cmpwi r10, r31
bne- dont_store
New Source
Code: cmpwi r4, 1
cmpw cr7, r10, r31
cror 4*cr0+eq, 4*cr0+eq, 4*cr7+eq
beq- store_data
Scenario 3:
If r4 = 1 and r10 =/= r31, then go to 'store_data'. Otherwise, end_code
Typical Source
Code: cmpwi r4, 1
bne- end_code
cmpw r10, r31
bne- store_data
New Source
Code: cmpwi r4, 1
cmpw cr7, r10, r31
crandc 4*cr0+eq, 4*cr0+eq, 4*cr7+eq
beq- store_data
Scenario 4:
If r4 = 1 or r10 =/= r31, then go to 'store_data'.
Typical Source
Code: cmpwi r4, 1
beq- store_data
cmpw r10, r31
bne- store_data
New Source
Code: cmpwi r4, 1
cmpw cr7, r10, r31
crorc 4*cr0+eq, 4*cr0+eq, 4*cr7+eq
beq- store_data
Scenario 5:
If r4 = 1 then r10 must =/= r31, or if r4 =/=1 then r10 must = r31. If all requirments met go to 'store_data'. If not, go to end_code.
Typical Source
Code: cmpwi r4, 1
bne- make_sure_next_true
#r4 = 1, r10 must =/= r31
cmpw r10, r31
bne- store_data
b end_code
make_sure_next_true:
cmpw r10, r31
beq- store_data
New Source
Code: cmpwi r4, 1
cmpw cr7, r10, r31
crxor 4*cr0+eq, 4*cr0+eq, 4*cr7+eq
beq- store_data
Scenario 6:
If r4 = 1, then r10 must = r31. However r4 can =/= 1 as long as r10 =/= r31. If all requirements are met go to 'store_data'. If not, go to end_code.
Typical source
Code: cmpwi r4, 1
bne- make_sure_next_false
#r4 = 1, r10 must = r31
cmpw r10, r31
bne- store_data
b end_code
#r4 =/= 1, r10 must =/= r31
make_sure_next_false:
cmpw r10, r31
bne- store_data
New source
Code: cmpwi r4, 1
cmpw cr7, r10, r31
creqv 4*cr0+eq, 4*cr0+eq, 4*cr7+eq
beq- store_data
Chapter 6: Conclusion
And that's pretty much it. Happy coding!
|
|
|
|
| Cache Basics |
|
Posted by: Vega - 05-15-2022, 12:59 PM - Forum: Power PC Assembly
- No Replies
|
|
Cache Basics
This PPC tutorial will teach some broad basics of the Cache that can cover any issue regarding simple Gecko ASM Codes.
Chapter 1: Understanding some Basics about Memory
There's two types of memory, Virtual & Physical. When Broadway executes in Virtual Memory, this is called Virtual Mode. When Broadway executes in Physical Memory, this is called Real Mode.
Virtual Memory is split into two categories:
- Virtual Cached Memory
- Virtual Uncached Memory
Virtual Cached Memory is your typical 'normal' memory that you are familiar with (i.e. 0x80000000 thru 0x817FFFFF & 0x90000000 thru 0x93FFFFFF).
Virtual Cached Memory is a representation of Physical Memory but it includes any cached content. Cached content may be 'old' or may be 'too new'. Therefore, what you see in Virtual Cached Memory may not be what is actually present in Physical Memory. Virtual Uncached Memory is a simple representation of Physical Memory.
Virtual Mode is slower than Real Mode because Broadway (thru what is called BAT Registers and other mechanisms which you cannot see), has to 'translate' the Virtual Address to its Physical Address equivalent. Therefore, all Wii games will utilize most features of Broadway's Cache system to help speed up performance.
Virtual Memory has to be split into Cached & Uncached to reduce the load on Broadway's Cache System as it can only handle a set maximum of data.
Wii games won't run entirely in Real Mode even though Real Mode offers the fastest performance for the following reason...
Security
In Real Mode, all of memory has the same properties, and those properties cannot be adjusted from the Broadway default settings. With Virtual Mode, you can set different regions of memory to have a variety of different properties, and adjust said properties whenever you want.
Here's a list of Physical, Virtual Cached, and Virtual Uncached memory ranges for most Wii games.
- 0x00000000 thru 0x017FFFFF Physical Mem1
- 0x10000000 thru 0x13FFFFFF Physical Mem2
- 0x80000000 thru 0x817FFFFF Virtual Cached Mem1 (known as mem80 and mem81)
- 0x90000000 thru 0x93FFFFFF Virtual Cached Mem2 (known as mem9)
- 0xC0000000 thru 0xC17FFFFF Virtual Uncached Mem1
- 0xD0000000 thru 0xD3FFFFFF Virtual Uncached Mem2
The list doesn't include everything, just the important stuff that's relevant to Gecko ASM Codes.
Chapter 2: Structure of Cache Organization
Cache is split into two categories:
- Data Cache
- Instruction Cache
Instruction Cache is for anything that contains executable instructions, simple enough. Data Cache is for any data that are part of any load/store mechanism. Executable instructions can also be included in the Data Cache. For example, if you write (i.e. store) a new instruction to memory, it will be part of both the Instruction and Data cache.
Here's the layout of a Data Cache page (each row is known as a 'way'). An alternative name to 'row' is block.
Way0 | StateBits | 32-byte Aligned Physical Address +0x0 thru +0x1C
Way1 | StateBits | 32-byte Aligned Physical Address +0x0 thru +0x1C
Way2 | StateBits | 32-byte Aligned Physical Address +0x0 thru +0x1C
.. ..
Way6 | StateBits | 32-byte Aligned Physical Address +0x0 thru +0x1C
Way7 | StateBits | 32-byte Aligned Physical Address +0x0 thru +0x1C
The Instruction cache implements the same layout, but it uses a single "Valid" Bit in place of the State Bits.
8 ways (aka blocks) make up one 'Set'. There are a total of 128 Sets for both the Instruction and Data Cache.
For example~
If you had made a modification to the cache of address 0x80001504, cache for the words of addresses 0x80001500 thru 0x8000151C will all be effected simultaneously.
Chapter 3: State and Valid Bits
Each physical address in a data cache page has a state bit with it.
State bits--
- M = Modified
- E = Exclusive
- I = Invalid
Modified = Present in Virtual Cached Memory but not yet present on Physical Memory; will be written to physical memory sooner or later.
Exclusive = What's in Virtual Cached Memory is what's in Physical Memory
Invalid = Old data that is now invalid, you can freely erase/modify this block w/o effecting anything
Each physical address in the instruction cache has a valid bit associated with it
Valid = next time this address is used by an instruction, the value here is what will be used
Invalid = old data that is now invalid, will not be used, can be tossed whenever
Chapter 4: List of Cache Instructions
Broadway comes with the following cache instructions~
dcbf rD, rA = Data Cache Block Flush
dcbi rD, rA = Data Cache Block Invalidate
dcbst rD, rA = Data Cache Block Store
dcbt rD, rA = Data Cache Block Touch
dcbtst rD, rA = Data Cache Touch & Store
dcbz rD, A = Data Cache Block Zero
dcbz_l rD, rA = Data Cache Block Zero then Lock
icbi rD, rA = Instruction Cache Block Invalidate
All instructions treat their values as Signed.
rD + rA = The address (aka Effective Address aka EA)
Note that in all instructions, if rD = r0, it will be treated as literal zero.
- dcbf will check the address's state bit. If the address has an M bit, the data there is now written to physical memory and an I bit replaces the M bit. If the address has an E bit, the bit is simply changed to I.
- dcbst will check the address's state bit. If the address has an E bit, nothing is done, the bit remains as E. If the address has the M bit, data there is now written to physical memory, and the M bit is now changed to an E bit. Pro-Tip: If you are familiar with BAT Registers and the region of memory is in a BAT that is marked at 'Write-Through (W bit high), you will never need the dcbst instruction for that region of memory.
- dcbi simply sets the State Bit to I, regardless of what is was before.
- dcbt and dcbtst are basically available to possibly very slightly boost preforamnce as it can provide Broadway with some hints on how to handle a cache block. For Wii Gecko Coding, these instructions serve no purpose for you.
- dcbz will null out the contents at the location designated by the EA and the state bit is now set to M. If the EA is not in a cache block, it will be placed in a cache block, and tagged with M.
- dcbz_l does the same as above, but will then lock the cache where it can't be modified, You would need to unlock the data cache via HID0 afterwards.
- icbi is the only instruction you have available to modify the instruction cache. This will simply set the I bit on the block.
In regards to Gecko ASM Codes, you only need to concern yourself with dcbf, dcbst, dcbi, & icbi.
Chapter 5: Overwriting Executable Instructions
For Gecko ASM Codes, the only instance where we really need to worry about cache is if your code involves writing/re-writing new instructions that will be executed later on.
When overwriting instructions, you need to ensure they get updated in the cache system quickly. Or else there's a chance the instructions you see are not what is exactly being executed by Broadway.
Here's a snippet of code for updating cache for writing in new executable instructions
Code: #Pretend the r5 contains the address where the new instruction is at
dcbst 0, r5 #Force a write-thru on address's cache page
sync #Wait for update in memory to complete
icbi 0, r5 #Invalidate the old instruction that was there previously
isync #Prevent possibility of old instruction being fetched before the icbi is completed
You do NOT need to 32-byte align the address (i.e. 0x8000151C -> 0x80001500) aka make the address diviisble by 32 (0x20) when using the above example source. Broadway will handle that for you.
Use the above template if you are writing over a single instruction or multiple instances of writing over single instructions are not stringed together (back to back in memory)
For writing over a string of instructions, use the following template..
Code: #rX = Loop Amount (will be explained later)
#rY = Address
#Assume CTR is safe for use
li rX, X
mtctr rX
clrrwi rY, rY, 5 #Align address to 32-byte, this is needed for this source/template
cache_loop:
dcbst 0, rY
sync
icbi 0, rY
isync
addi rY, rY, 0x20 #rY cannot be r0 due to literal zero rule
bdnz+ cache_loop
Regarding what loop amount to set, let's say you are overwriting a string of 12 instructions. Since each cache page takes up 8 instructions (words), do 12 divided by 8. You now have 1.5. Round that up and you end up with 2. 2 Would be your loop amount.
Chapter 6: Sync & Isync; Conclusion
Without getting into all the technical jargon... sync 'updates' the Data cache, and isync 'updates' the Instruction cache. That's all you really need to know when it comes to Gecko ASM Codes.
Happy Coding!
|
|
|
|
| Draggable items code |
|
Posted by: dirtyfrikandel - 05-12-2022, 11:43 PM - Forum: Code Support / Help / Requests
- Replies (1)
|
 |
Hey.
I need some help with creating a code that lets you drag any item, just like the draggable blueshell mod (https://mariokartwii.com/showthread.php?...=draggable)
For example to drag a star i've tried the following:
1) Item Behaviour Modifier, https://mariokartwii.com/showthread.php?tid=386) but it also activates the power before dragging it.
048A61B8 00000002
2) I changed this code to the following (taken the PAL code for star from Item Behaviour Modifier):
068A61B8 00000008
00000002 00000000.
This does not activate the power up when pressing the item button (nice!), and the item actually drags behind the vehicle. However, when pressing the button again, it drops the item on the ground (like a banana)
I want to drag things like POW, Shocks, Bloopers, Megas in order to simulate a mario kart 8 Deluxe where you have 2 item slots.
Is this even possible as these items have a standard behaviour value of 00 instead of 01, like the blueshell/red shell/green shell (https://wiki.tockdom.com/wiki/Filesystem...r_Modifier)
Kind regards,
Dirtyfrikandel
|
|
|
|
| Hello I am 267 |
|
Posted by: 267 - 05-03-2022, 08:45 AM - Forum: Introductions
- Replies (1)
|
 |
Hi I'm Zi/StereoCat/Rosuku/Roskzy/Rosk/Sazry/Sazry666 I go by a few names
I'm bored and I feel like coming back to the mkwii community again but I'm not as active at all.
YT: ASL
Wiki: 267
|
|
|
|
| [Code Request] Get Points After Time is Up |
|
Posted by: Zeem - 04-14-2022, 05:03 PM - Forum: Code Support / Help / Requests
- Replies (6)
|
 |
After playing some battles online, I realized that players don't receive points until a few seconds after they hit their opponent. This is problematic because during the last 2-3 seconds of the battle, nobody can earn any points. I was thinking of a way this could possibly be fixed, it happens way too often when I'm battling online.
My idea is: a code that allows players to earn/lose points for 2 more seconds after time runs out.
If anyone can make this code, I would really appreciate it.
|
|
|
|
|
