Are constant mem writes a concern?

[daijoda]

I've wondered about this for a while - Would increased use of constant "write" codes fasten the aging of the Wii's NAND? Or are the effects of a dozen more constant writes completely negligible?

For example, comparing #1 with #2:

#1.

if value = button activator A
   load [po] into gr1
   do some calculation on gr1
   store gr1 to po
if value = button activator B
   load [po] into gr1
   do other calculation on gr1
   store gr1 to po
terminator

#2.

load [po] into gr1   ############ write
if value = button activator A
   do some calculation on gr1
if value = button activator B
   do other calculation on gr1
end if
store gr1 to po   ############ write

The first has more lines, but its writes are conditional, unlike those two constant writes in the second one.

[dcx2]

No.  The NAND in the Wii is a different form of storage from the MEM1 and MEM2 RAM chips.  The NAND is encrypted and it stores all of the IOS versions, the System Menu, channels, stuff like that.  You need special homebrew to read and write to it.

Gecko code types write to MEM1 and MEM2 RAM chips.  These are not NAND, therefore there is no wear-and-tear.

There is no harm in using constant writes.

[daijoda]

That's true, when you dump the NAND, you get system menu files, game saves, etc., but not MEM1/MEM2. So, the RAM is designed to be able to withstand this kind of writes? And they won't "bog down" the system? Lol, I don't know why, but every time I see these writes that could've existed inside the IF codes outside, I tend to think of them as "additional" "unnecessary" writes. Good to know they're not writing to the NAND.

[dcx2]

These kinds of writes are exactly what RAM was designed for.  There is no need to "withstand" writes.  RAM is just some capacitors and transistors, it does not wear.

It is possible to "bog down" the system with too many *codes*, though.  The code handler runs every frame; if your codes take a long time to finish then the game will slow down.  Sorta like using MemView with auto update.

[daijoda]

Hm, does having more *codes* mean having more lines, or more "things" that need to be done? To use my previous example, assuming the conditions are not met, is #1 considered to have more codes than #2?

[dcx2]

Each code line is 8 bytes (two 4-byte words separated by a space)

All the code lines together are a binary blob in a gct file.  Loaders copy them into memory before starting the game.  When the debugger is running, 1931-style loaders will have about 200 code lines total.

Even if code lines are not executed (i.e. activator condition is not met), they still take up space.  If they are executed multiple times per frame (e.g. you used a Set Repeat or something), they still only take up one line each.

#1 would be 9 lines, #2 would be 7 lines (8 when you include the terminator)

For #1, in the common case there is no button held, so three lines would be executed; the two ifs and the terminator.  For #2, in the common case there is a load, two if's, end-if, store, and probably a terminator.  Though #2 takes up less space it will typically require more time to execute.  However, Broadway is pretty fast, and the code handler is pretty small, so it's actually quite difficult to slow the game down meaningfully.

[wiiztec]

It is possible to "bog down" the system with too many *codes*, though.  The code handler runs every frame; if your codes take a long time to finish then the game will slow down.  Sorta like using MemView with auto update.

How much codes would that take? the brawl codeset I use is over 4000 lines and their is no noticeable slowdown

[dcx2]

If you use a Set Repeat code with a huge repeat count, it can slow the game down.

Also, F6 codes will slow the game down while they're searching.  This is why they only search once.  However, if you make a resettable F6, it could slow the game down unless you use an A8 code to make it only search every few seconds.