EZ-Flash USA Forum

It's been a while, so I figured I might as well create another simply skin. This includes a modified font, text colors, and the usual mix of fun backgrounds (the text mode and file manager backgrounds are a bit bland, though). The text does look a bit sketchy at times, which I'm not entirely happy about, but I think it's good enough to readily decipher. I hope you enjoy.

Edit: A small update to fix up the font. I think I'm happy with it now.

GBA Skin:


GBA Boktai Skin (includes patched firmware)

Well, I wasn't entirely happy with the old Boktai Skin, so here's a new version with a few tweaks. I hope Boktai fans will enjoy it.



GBA Boktai Skin v2 (includes patched firmware)

Edit: Just a small fix to the text. If you downloaded this already, please redownload.

Nice theme and fonts man.. How'd you manage to view EZ4 on your PC? I can't find a better way to screen my skins than using the skinner..

Kuwanger hacked the EZ4 loader not to crash when you ran it in VBA. I forgot to bookmark the thread where the explanation on how to do it was though and a search is not helping.

Yeah, all you do is let it run and it'll get stuck in an infinite loop at 0x8001758 (08001758 e7fe b $08001758 -- that means "branch to $08001758). So, just change $8001758 to a NOP (0xc460 -- "eh 8001758 c460" if from a terminal; you might have to byte swap it to 46 c0 if you're altering 8001758 from the memory viewer). So, not much of a hack really...and why it says "ND" instead of "SD".

PS - NOP is a "no op"; ie, it's supposed to do nothing or nearly nothing. Strictly speaking, 0xc460 is the opcode for "mov r8,r8" (move r8 into r8) and really any "mov rn,rn" (for n being 0 to 14; I don't know if n=15 might malfunction since r15 is the instruction pointer) should be functionally a NOP, though I don't know if technically the GBA can skip the time actually used to execute the mov instruction in this case. You'd have to ask gbatek's author about that.

Thanks. I will remember to bookmark/note it this time.

I would not sell yourself quite so short either- debugging hardware specific code for an embedded platform is a fairly scary concept for some.

As for the NOP using the program counter I would avoid it (although I will have to confirm it as I am not sure and now curious). I recall trying to get a value for the PC at a given point tends to require some maths as the PC will have already advanced by the time you have read it in hardware and that has the makings of an infinite loop.