curiously, the MP cost under the Skills menu reads the correct variables, so it doesn't have either of the issues mblock129 described. (i say "curious" because the Bank C3 coders are avoiding their own menu variables here, but it makes sense that people who coded the menus would be more familiar with their variables' limitations.) however, it DOES have the problem i described with reading the Hours and Minutes as two separate bytes. unless there are some precautions taken for the NMI, you could get an erroneous cost (1 or 2 MP too low, depending on what you consider "current" time) if you happen to pop into Skills-->Lore right as Minutes roll over to 0. there's like a 1/8524 chance (7 / (3580000 / 60)) it'll bug, and that's assuming you know what frame to enter on (i don't) -- so VERY slim.
fortunately, their code to determine the cost is bigger than Bank C2's, so i can fix this theoretical flaw with at least 1 byte to spare.
EDIT: for that matter, the game reads hours/minutes and seconds separately (it has no choice; they're 3 bytes) when copying them into variables before saving them to SRAM. what's to stop the bug from happening there? or are menu actions "aligned" to take place at a certain part of a frame, so the game "knows" that NMIs will never conflict with them? if that's the case, then neither the Save screen nor the Skills submenu would have the problem..
EDIT2: ok, this feared issue probably will never happen. the main menu loop will wait on an NMI shortly before calling a menu action (such as loading the Lores submenu under Skills). in order for another NMI to happen in the middle of this, the action would have to take over 59000 CPU cycles (3580000 CPU speed / 60 frames in a second). a trace log of Lore submenu loading has only 8693 instructions, and assuming 3-4 cycles average per instruction, that'll be well short of the limit.
i haven't timed the act of saving your game (choosing "Yes" on "Erasing data. Okay?"), but my guess is it's shorter.
