How to detect variable going below zero, without using PBPL ?

Hello again :)

is there any way to avoid getting 65xxx numbers instead of negative numbers, when X-Y and Y is > X ?
I know, that PBPL can do it, but I don't want to use 18 series.

So maybe there is a way, instead of 0-65535, to have range of -32768 +32767 ?
or any other trick, that if resulting variable is going below zero, it to become equal to zero?

what have you tried ?
in what way does it not provide a correct result?

signed divides, multiplies and shifts need proper handling of the sign bit
otherwise as long as the vars match in type signed integer math works as expected

It depends on what you're doing with the number(s).
If your displaying them using LCDOUT/SEROUT/HSEROUT/ARRAYWRITE you can use the SDEC modifier to display the value 65535 as -1.

If you're doing further math with the numbers you need check the highest bit, if it's set the value is negative and you can use the ABS operator to retrieve the actual value, do whatever needs done (like a division) and then restore the sign.

Code:

---

X VAR WORD
Sign VAR BIT

X = -5000
HSEROUT["Raw: ", DEC X, "    Signed: ", SDEC X, 13]

Sign = X.15    ' Preserve sign
X = ABS(X) / 5  ' Divide absolute value
X.15 = Sign  ' Restore sign

HSEROUT[SDEC X, 13]

---

If all you want to do is cap the value at 0 then

Code:

---

IF X.15 THEN X = 0

---

I'm helping some fellow students to build an extinction meter.
There's ADC reading, and based on liquid passed in the system, light transmission, compared to reference, might increase or decrease.
So idea is, that they flow thru the "reference" liquid, ADC is read and that value is used as offset, which is deducted form further ADC readings, to get the info, what's going on.

Code:

---

ADCIN Baseline
ADCIN Reference
IF Reference < Baseline THEN
  'Sign = negative
  'Use subtraction in calculation
  'Denote a reduction
ELSE
  'Sign = positive
  'Use addition in calculation
  'Denote an increase
ENDIF

---

Another possibility is use 128 = 0. If ADC Value < 128, treat as negative... I've created my own positive/negative methods that don't follow the standardized Signed Variable format. The math was easier my way for what I was doing. Just some thoughts that might spur ideas.

It's not ADC value reference that causes problems.
Here's the explanation.

Say ADC changes from 100 to 200 and "middle" point is being 150.
So to have zero at my system variable output (which I later display both on screen and write to EEPROM), I'm deducting 150 from the input ADC value, to get zero. In case when ADC reading increases, than all is good, final variable value changes from 0 to 50, that's good. But if ADC value gets below 150, then things get bad.

Code:

---

Zero VAR BYTE
Variable VAR BYTE
OtherVar VAR BYTE

ADCIN, Zero
ADCIN, Variable
IF Variable < Zero THEN
  Zero = [some newly calculated value]
ENDIF
OtherVar = Variable - Zero

---

Make up your own rules!

Quote:

---

But if ADC value gets below 150, then things get bad.

---

what does get bad mean ?

show your code

Variable value should go to negative, but since we have no negative, it goes into 65xxx range :)

Quote:

---

Variable value should go to negative, but since we have no negative, it goes into 65xxx range

---

only if you interpret it incorrectly and ignore the sign bit



show your code

So by checking the last bit, I can know, whenever variable went into negative world, right?

That is what post #3 says. Henrik explained it well.

Ioannis

Whether signed or unsigned, 0 = 0.
With an Unsigned BYTE (let's start simple), the range is 0 to 255. From 255, add 1 and you get 0 again, as the BYTE rolls over.
With a Signed BYTE, the range is -128 to +127. Think in terms of binary: 127d = %0111 1111. Make sense so far?

Working with a Signed BYTE, if you calculate: "0 - 1 =", you get %1111 1111 which equals -1.
With an Unsigned BYTE, if you calculate: "0 - 1 =" you still get %1111 1111, but it equals 255.

Think about this for Signed Variables:
0d = %0000 0000
1d = %0000 0001
-1d = %1111 1111
-2d = %1111 1110

Sometimes just looking at the representations enables the light bulb to turn on.

Now if we're working at the 16-bit WORD level:
0d = %0000 0000 0000 0000
1d = %0000 0000 0000 0001
-1d = %1111 1111 1111 1111
-2d = %1111 1111 1111 1110

See the trend?? I hope this helps you figure some things out.

its called two's compliment , no magic involved

https://en.wikipedia.org/wiki/Two%27s_complement

I came into another issue.
I have font array in EEPROM, and need to set offset for reading it. Depending on charset, this offset can be negative and positive.

So I have to do it in a way like this:

if langvar[x]=0 then
Y=(topline[x])*8+OFS

if langvar[x]=1 then
Y=(topline[x])*8-OFS

Can these two joined into single operation somehow?

Code:

---

if langvar[x]=0 then
    Y=(topline[x])*8+OFS
else
    Y=(topline[x])*8-OFS
endif

---

Ioannis

No, I meant changing the value of OFS in the way, that addition will cause actual subtraction, due to overflow.

As long as both variables are of the same size adding a two's compliment value to another is the same as subtracting the absolute value of one from the absolute value of the other.

In these examples all variables are bytes.

X = 0
OFS = 1
Y = X + OFS Y will have the value of 1.
***********************************************
X = 0
OFS = -1 OFS will have the value 255
Y = X + OFS Y will contain the value 255 (which is -1)
***********************************************
X = 10
OFS = -5 OFS will have the value 251
Y = X + OFS Y will have the value value 5
***********************************************
X = -10 X will have the value 246
OFS = - 15 OFS wil have the value 241
Y = X + OFS Y will have the value 231 which is the same as -25
***********************************************

in simple terms adding the two's compliment of a var to a number is equivalent to subtracting the var from a number
providing they are all the same integer var type