Hacking gelu AKmenu3in1 10_e14

[Normmatt]

Because that code is worse than mine. It has too do more reading and has to look the addreses up in a lookup table, it shouldn't be in a loop anyway the loop is small enough to unbundle which gives a nice optimisation and mine takes up less space than your new code and thus produces faster code.really?
result of your code:

ÂÂÂÂldrÂÂÂÂr1, .L3
ÂÂÂÂldrÂÂÂÂr3, .L3+4
ÂÂÂÂstrÂÂÂÂr1, [r3]
ÂÂÂÂaddÂÂÂÂr3, r3, #108
ÂÂÂÂstrÂÂÂÂr1, [r3]
ÂÂÂÂaddÂÂÂÂr3, r3, #16
ÂÂÂÂstrÂÂÂÂr1, [r3]
ÂÂÂÂaddÂÂÂÂr3, r3, #16
ÂÂÂÂstrÂÂÂÂr1, [r3]
ÂÂÂÂldrÂÂÂÂr2, .L3+8
ÂÂÂÂaddÂÂÂÂr3, r3, #8
ÂÂÂÂstrÂÂÂÂr1, [r3]
ÂÂÂÂaddÂÂÂÂr3, r3, #8
ÂÂÂÂstrÂÂÂÂr2, [r3]
ÂÂÂÂaddÂÂÂÂr3, r3, #28
ÂÂÂÂstrÂÂÂÂr1, [r3]
ÂÂÂÂbxÂÂÂÂlr
.L4:
ÂÂÂÂ.alignÂÂÂÂ2
.L3:
ÂÂÂÂ.wordÂÂÂÂ-509607936
ÂÂÂÂ.wordÂÂÂÂ37270936
ÂÂÂÂ.wordÂÂÂÂ-476053504

mine:

ÂÂÂÂldrÂÂÂÂr3, .L7
ÂÂÂÂldrÂÂÂÂr1, .L7+4
ÂÂÂÂmovÂÂÂÂr2, r3
ÂÂÂÂaddÂÂÂÂr2, r2, #140
ÂÂÂÂstrÂÂÂÂr1, [r3]
ÂÂÂÂstrÂÂÂÂr1, [r3, #108]
ÂÂÂÂstrÂÂÂÂr1, [r3, #124]
ÂÂÂÂstrÂÂÂÂr1, [r2]
ÂÂÂÂaddÂÂÂÂr2, r2, #8
ÂÂÂÂstrÂÂÂÂr1, [r2]
ÂÂÂÂaddÂÂÂÂr3, r3, #184
ÂÂÂÂldrÂÂÂÂr2, .L7+8
ÂÂÂÂstrÂÂÂÂr1, [r3]
ÂÂÂÂsubÂÂÂÂr3, r3, #28
ÂÂÂÂstrÂÂÂÂr2, [r3]
ÂÂÂÂbxÂÂÂÂlr
.L8:
ÂÂÂÂ.alignÂÂÂÂ2
.L7:
ÂÂÂÂ.wordÂÂÂÂ37270936
ÂÂÂÂ.wordÂÂÂÂ-509607936
ÂÂÂÂ.wordÂÂÂÂ-476053504

QUOTEBy the way whats the main problem with adding NAND support? that ECC crap?

i dont' know. you can try implement, why not?

Hmm I never bothered to go and disassemble the results.

My question about the NAND was if you had any particular reason too do it for the SD and not the NAND (NAND would be best as you wouldn't have any speed issues??)?

 

[z.g]

My question about the NAND was if you had any particular reason too do it for the SD and not the NAND (NAND would be best as you wouldn't have any speed issues??)?

developing sd direct write is easy and safe than nand direct write. there is no operations that put sd card to inconsistence state. but in nand case it possible.

 

[Normmatt]

My question about the NAND was if you had any particular reason too do it for the SD and not the NAND (NAND would be best as you wouldn't have any speed issues??)?

developing sd direct write is easy and safe than nand direct write. there is no operations that put sd card to inconsistence state. but in nand case it possible.

Sounds like a good reason too stay away from that and let the official team (If they ever seem to do anything) add support for it.

By the way gelu, Does your firmware have problems showing the text in the rom info and help window when under any language other than english? This is the main reason we moved back to devkitarm r21 and I couldn't find any way around it as it was a problem with newlib which should hopefully be fixed in devkitarm r24.

 

[z.g]

By the way gelu, Does your firmware have problems showing the text in the rom info and help window when under any language other than english?as i can see, no any problem: one, two, three.
QUOTEThis is the main reason we moved back to devkitarm r21 and I couldn't find any way around it as it was a problem with newlib which should hopefully be fixed in devkitarm r24.

and what is the problem?

 

[Normmatt]

The Help window doesnt show up in chinese or anything apart from english in AKAIO and it started occuring when i moved from devkitarm r21 to r22(and above). It would only show the first button icon and one chinese character then nothing else. I tracked it down to a problem with vnsprintf which since devkitarm r22 now supports unicode (which appears to break compatibility with AKAIO for some reason??).