Alright, so...this seems like it should be simpler than I'm making it. I'm probably going to botch the explanation here, but hopefully you guys will be able to decode what I mean.
I had a signed comparison so that I could evaluate for a negative number (checking the value of VAR to see if it is negative...this value has already been determined in a different part of code, this is just checking to see its value - so for instance, at this moment I might have "-27" as a signed value during the check...this isn't the moment where I'm mathing to GET "-27" so there is no simple matter of checking the carry). However, as it turned out I needed more than 128 possible positive values, so BPL/BMI that I was using for this turned out to not be a good evaluation method.
So I played around with BCC/BCS methods instead, but of course the problem is... the math is done in a different part of code to find out the value of VAR, so it's not just a matter of checking the carry in a resulting compare. At this point, if I want more than 128 "positive values", I'd have to evaluate it unsigned...but I can't really do that if I want more than 128 values in the positive.
The only way I could think to do this is kind of wonky - to continue using signed values, but *sacrifice* the upper most possible values. I could determine if it's -16 through -1, and if it is, treat it as negative. If it's either less than -16 as a signed number, or 0 and higher, i'd evaluate it as positive. That would essentially give me the ability to compare 0-240 as *positive* and be able to still have a negative value of down to -16...
It just seems...unnecessarily convoluted. Anyhow - that's my thought with how to approach it, but I figured I'd ask if there are any other thoughts on possible approaches to this?
I had a signed comparison so that I could evaluate for a negative number (checking the value of VAR to see if it is negative...this value has already been determined in a different part of code, this is just checking to see its value - so for instance, at this moment I might have "-27" as a signed value during the check...this isn't the moment where I'm mathing to GET "-27" so there is no simple matter of checking the carry). However, as it turned out I needed more than 128 possible positive values, so BPL/BMI that I was using for this turned out to not be a good evaluation method.
So I played around with BCC/BCS methods instead, but of course the problem is... the math is done in a different part of code to find out the value of VAR, so it's not just a matter of checking the carry in a resulting compare. At this point, if I want more than 128 "positive values", I'd have to evaluate it unsigned...but I can't really do that if I want more than 128 values in the positive.
The only way I could think to do this is kind of wonky - to continue using signed values, but *sacrifice* the upper most possible values. I could determine if it's -16 through -1, and if it is, treat it as negative. If it's either less than -16 as a signed number, or 0 and higher, i'd evaluate it as positive. That would essentially give me the ability to compare 0-240 as *positive* and be able to still have a negative value of down to -16...
It just seems...unnecessarily convoluted. Anyhow - that's my thought with how to approach it, but I figured I'd ask if there are any other thoughts on possible approaches to this?