Monday, August 20, 2012

Petit Computer Journal#3


Petit Computer Journal #3

How to use Buttons and Directional Pad

Let's do something real quick. Let's make a counter that will increase when a button is pushed. Looking at the various commands, it is obvious that it is either BUTTON() or BTRIG(). Let's use BTRIG(). Reading the Help entry shows that the value returned by BTRIG() is usually 0. Non-zero if there's a button pushed. Perfect. We come up with this very quickly:

CLS
@COUNTER
B=BTRIG()
IF B==0 GOTO @COUNTER
A=A+1:A=A%1000:'0-999 CYCLE
?A;"      "
GOTO COUNTER

We run the program, and press a button. We see that the counter increments, all right. And it cycles to 999 like it should. However, the program registers so many button presses. That is not what we want. We want 1 increment per button push. So, we need to fix it. At this point, most people would do the sensible thing and type into Google: "Petit Computer how to use button". 

Haha, joking aside, we do need to understand how to read buttons properly. What do we do when the platform does not have built-in debugger? Well, we make our own!


What to do when things go wrong

I know I'm bucking the convention, here, but writing self-debugging program isn't that much trouble. The most important thing is that you want to understand what's going on. The simplest, easiest method to do it is read the manual. When the manual fails, however, we need to do better. That means we need to try things out and see what happens. It's called, "Learning without a teacher" or "Research". If you passed high school, then you know how to do it.

First make a hypothesis: One button press=one event. (desired behavior)

Then gather data: One button press=many events (observed)

Therefore, the conclusion is: what we want, and what we have are two different things. Error!

There are many kinds of errors in computer programming, but let's just simplify things a bit for now.

Computers are stupid, remember? If you mistype a command, the computer cannot handle it. If you forget a variable, the computer cannot handle it. If you transposed commands or letters or anything, the computer cannot handle it. The computer will complain: "Syntax Error!" That means, you have typed something incorrectly as to confuse the computer.

Another kind of error occurs when you ask the computer to do the impossible. Dividing by zero is one. GOTO a unlabelled section is another. These kind of errors are called "Run-time Error", because they occur at the running of the program.

Sometimes the program runs fine, but doing something else than what we want. We want to roll 5 dice, but only 1 is rolled. That means that what we say and what we want to say are two different things. We need to figure out a different way to say what we want. This is called "Semantic Error".

If, however, your screen is cracked, plastic is chipped, and stylus bent, then we have what is called PEBKAC Error: Problem Exists Between Keyboard And Chair. You probably should stay off computer programming for a while.

A binary review

If you're wondering why the values for the buttons are 1,2,4,8 etc, the answer is that the buttons do not have separate variables. The figure is all one number! There are different bits to the number, and that is what we're seeing. We can take a look at various bits by doing this code:

V=9
FOR I=0 TO 7
P=POW(2,I)
IF (P AND V) THEN ?"1"; ELSE ?"0";
NEXT
PRINT

In this case, we're doing a "Binary AND" (instead of "Logical AND") using bit 0-7. You can, of course, increase the bits to 31. I'm trying to keep it simple. Try putting in different values into V variable.


Source code for button readings

If we want to see what the buttons do, then it is very simple to do this:

CLS
@MAINLOOP
A=BUTTON(0)
B=BUTTON(1)
C=BUTTON(2)
D=BUTTON(3)
E=BTRIG()
LOCATE 0,0
?"BUTTON(0) ";:V=A:GOSUB @BIN
?"BUTTON(1) ";:V=B:GOSUB @BIN
?"BUTTON(2) ";:V=C:GOSUB @BIN
?"BUTTON(3) ";:V=D:GOSUB @BIN
?"BTRIG()   ";:V=E:GOSUB @BIN

'PLACEHOLDER

GOTO @MAINLOOP

@BIN
FOR I=0 TO 7
P=POW(2,I)
IF (P AND V) THEN ?"1"; ELSE ?"0";
NEXT
PRINT
RETURN

You can see the flickers for Button 1-3. That means the change happens in an instant. In this case, the change happens only in one frame, or 1/60 of a second. That's fast! I also see that the flickers on B is identical with the flicker on E. From that, I deduce that BTRIG() is equivalent to BUTTON(1). Is there any delay or waiting either with BTRIG() or BUTTON()? None that I can see.

If you want to make sure, replace the "'PLACEHOLDER" with these lines:

IF A!=E THEN LOCATE 0,7 :V=A:GOSUB @BIN:V=E:GOSUB @BIN
IF B!=E THEN LOCATE 0,10:V=B:GOSUB @BIN:V=E:GOSUB @BIN
IF C!=E THEN LOCATE 0,13:V=C:GOSUB @BIN:V=E:GOSUB @BIN
IF D!=E THEN LOCATE 0,16:V=D:GOSUB @BIN:V=E:GOSUB @BIN

The suspicion that BTRIG()==BUTTON(1) is confirmed! Now that's what I call successful research!



The fixed source code

Now that we know what is happening, we can do different things to fix it. 

First, we can specify that the increase is between Button Push and Button Release, like so:

CLS
@COUNTER
B=BUTTON(2)
IF B==0 GOTO @COUNTER
A=A+1:A=A%1000:'0-999 CYCLE
@C2
B=BUTTON(3)
IF B==0 GOTO @C2
?A;"      "
GOTO COUNTER

And that works nicely. However, let's see if we can improve things a bit. The manual mention VSYNC 1, as a way to get the input right. So, let's use that

CLS
@COUNTER
B=BUTTON(2):VSYNC 1
IF B==0 GOTO @COUNTER
A=A+1:A=A%1000:'0-999 CYCLE
?A;"      "
GOTO COUNTER

That also works, and notice that it is cleaner. What happens if VSYNC is set to something other than 1? Try it! You'll see that you will be missing some button presses. The exception to that is if you use BUTTON(0), and only at the sync.

CLS
@COUNTER
B=BUTTON(0):VSYNC 15:IF B==0 GOTO @COUNTER
A=A+1:A=A%1000:'0-999 CYCLE
?A;"      "
GOTO COUNTER

And that's what we want. Problem solved!

The rest of Console Entry Commands

Try out this command: BREPEAT 4,60,4
That will cause the A button to be repeated if you press it longer than 1 second. Pretty neat, eh?

Also, what is the difference between INKEY$, INPUT, and LINPUT?
INKEY$ behaves just like BUTTON(), in that it doesn't stop and wait for keypress.
LINPUT, LINE-INPUT, takes the whole line, including commas.
INPUT takes the line, and assign different values separated by commas.

And that's all there is to it!

No comments: