While whizzing through the code, I noticed a pattern in the IRAM section:  a byte location that is cleared or set to 0xff (though either of two ways), and tests of bit 0.  So I conclude that these are 'flags'.  There's a bunch of them, so I went through the various byte sized locations and did a cross reference to find how they were used.  If they fit into the pattern of 'clear, set to 0xff, branch test on set or clear' only, then I marked them as XXX flag??? so that would propagate through the listing.

A typical cross-reference example is for byte_6D:

Type Address           Text
---- -------           ----
w    sub_E068:loc_E07F clr     byte_6D         ; XXX flag?
r    sub_E489:loc_E4A0 brset   byte_6D 1 loc_E4C5; XXX flag?
r    sub_E6BD+5E       brclr   byte_6D 1 loc_E74C; XXX flag?
r    sub_E6BD+9C       brset   byte_6D 1 loc_E760; XXX flag?
w    sub_E842          clr     byte_6D         ; XXX flag?
r    sub_F013+5        bset    byte_6D $FF     ; XXX flag?
r    sub_F26C+4        brset   byte_6D 1 loc_F286; XXX flag?

It's interesting that these bools are typically set/cleared all bits on (bset 0xff) or off (clr), but are just tested at bit 0 (brset/brclr 1).  This may just be a matter of taste.  It's interesting also that with so many 'flag' bytes, that the authors didn't pack them into bits.  The instructions to do so are there, and that would have liberated some RAM.  Maybe there is a reason (it doesn't seem to be code size, though, since clr is 3 bytes, and bclr is also 3 bytes on this page 0 memory), or maybe just taste or there simply wasn't sufficient impetus.  At any rate, it makes my job a bit easier to have one flag per address reference.

On the other hand, there are some examples of the alternative implementation, e.g. at location byte_58:

Type Address           Text
---- -------           ----
r    sub_E489:loc_E4C1 bset    byte_58 1       ; XXX flag?  
r    sub_E6BD:loc_E717 brclr   byte_58 1 loc_E6ED; XXX flag?
r    sub_E84F+5F       brclr   byte_58 1 loc_E8C2; XXX flag?
r    sub_F013:loc_F024 bset    byte_58 $FF     ; XXX flag?  
r    sub_F26C:loc_F2BE bset    byte_58 $FF     ; XXX flag?  
r    sub_F26C+60       bset    byte_58 $FF     ; XXX flag?  
w    sub_F26C:loc_F2D1 clr     byte_58         ; XXX flag?  

Here we can see a mixture of the '0xff' style and also the 'bset 1' style.  Testing is still the 'brset/brclr 1' style, so it's the same concept of 'byte as bool'.  So this could suggest different programmers working on different parts of the code (or reusing old code for parts written by a different programmer, or maybe yourself when you had different sensibilities).  So there were many hands involved in the code base.

Other examples of the 'many hands' hypothesis are at byte_4a:

Type Address           Text
---- -------           ----
r    sub_E6BD+F2       bset    byte_4A 1       ; XXX flag?  
w    sub_EAA7+5        staa    byte_4A         ; XXX flag?  
r    sub_F26C          brclr   byte_4A 1 loc_F2BE; XXX flag?
w    sub_F26C:loc_F2BB clr     byte_4A         ; XXX flag?  
w    sub_F26C+5D       clr     byte_4A         ; XXX flag?  
r    sub_F2D6          brclr   byte_4A 1 loc_F2EE; XXX flag?
w    sub_F2D6:loc_F2EB clr     byte_4A         ; XXX flag?  

where an explicit staa is used to set the flag true.  Though this one is possibly explainable because the surrounding code already had an 0xff in the A reg, so this save a byte of program space as opposed to the bset method.  This might just be parsimony. 

There's some other cases such as byte_a1 which uses explicit load/store instead of the bset/clr, and also byte_a3 which toggles with eor (although that particular flag seems to be unused by anything).

Differences in style like these are interesting to me because they are artifacts of the team that created the product.