Newbie Still Doesn't Understand Code

the first pass is reading from a list of spells known by a character.  it starts at 7E/1A6E for Character 0, and also exists outside of battle.

the second pass is reading from a character's in-battle menu.  the addresses of the 4 party members' menus are read from C2/2616, and saved in $302C,index.

so the answer is that FFh means different things in the two structures.  as a general rule, FFh will mean null in a menu.  in the first structure (which has the learn %), it means the spell is already fully learned.  the special value is used in place of 100 because it's quicker/smaller to check the Zero Flag than do "cmp #$64" everywhere.  also, there's another special value of 80h, which is used by end battle code to represent "just learned".

after the first quoted code, the game does some more processing using a couple intermediate/temporary RAM structures, and eventually saves the spell ID and other information to the menu at C2/5651.

i will give C2/55A1 a comment matching C2/6055.

It seems that I did not understand the code as well as I thought. Not only did I misunderstand the details, I didn't understand what the operator actually did.

assassin, I am especially grateful for your thorough input. Thank you for the disassembly in the first place, and for all the additional explanations you provided.

Edit: I wanted to clarify something I wrote earlier in this thread, because I did not write it clearly. Through selective blanking out of the code in C2, I was able to make all of the spells available and usable during battle, whether known or not.

Code:

C2/55A3: EA EA
C2/55A5: EA EA

Code:

C2/56EC: EA EA
C2/56EE: EA EA

Code:

C2/570C: EA EA
C2/570E: EA
C2/570F: EA EA
C2/5711: EA
C2/5712: EA EA
C2/5714: EA EA

By removing all the checks for whether a spell is known or not and NOP-ing the code that blanks out unknown spells, all spells are usable in battle.

It is also possible to "learn" magic because whether a spell is known or not is separate from whether it appears in the menu. That information is stored separately.

It isn't worth bumping the thread to add this, but I thought I should make it clear.

With the benefit of hindsight, I can answer myself.

All right, I was playing around with NOP-ing pieces of the code with various degrees of success*, and I became curious about something.

Despite the fact that the "default" view is the normal pool of available spells, both the code and my tests seem to indicate that the Spell + Cost view when pressing Y mode is actually the primary mode (and thus any changes must be made there first), while the view the player sees by default is actually the secondary view. Is this actually the case, or am I making a distinction where there is none?

You're making a distinction where there is none, because you don't understand how the code works and why the change you made did have an effect.

The spell availability in "Y mode" is based on whether that specific spell is known or not. However, this is likely the secondary mode, as it occurs after the branch away from the main code. Basically, the game treats the menu normally unless Y is pressed. Given how simplified the menu is and that its appearance is determined through used of the existing subroutines, you can gather this is the secondary mode if you plan to distinguish them like that.

There is duplicate code to determine whether to blank out a spell as you have noticed, but this is because the conditions for "Y mode" derive from the percentage of spells known and uses that as a barometer for blanking out a slot. That is the code you affected. As was mentioned, yes, it could be done more efficiently, but that's an irrelevant detail. "Y mode" doesn't contain any display option for partially known spells and just either makes the spell available or not.

The key fact is that you haven't grasped is that while "Y mode" is on/off in terms of spell display, the regular menu is made of subroutines which determine how a spell is displayed (on/off/partial). Basically, you are going to have to hop around the various subroutines to actually figure out the order they are applied. Even with documentation, this isn't straightforward. That spell generation (or more accurately, spell elimination) procedure is what you are going to have to hijack as well.  Once you figure out how to do that, modifying "Y mode" will be simpler in comparison.

*My short-term goal was to allow spells to be available even if they aren't in the actor's spell list. I had limited success on that front. I NOPed C3/4FE0-C3/4FE3 andC3/4FE7-C3/4FEA and all the spells became usable when I pressed Y.  When I NOP-ed C3/4FD5, though, removing the branch granted access to the spells...but removed the ability to see the spells without the MP cost next to them.

You essentially rendered the menu acting like Y is pressed all the time by removing the branch. However, you did not change the behavior of magic list population outside of that limited scenario. You need to figure out the place or places that this occurs, then work with that simplified menu later.

Although you did make some baby steps, you are going to have to look at the code more broadly than serially, line by line. You have to figure out the process, not just the general guidelines and overall rules, of how the list builds itself.