Musing Journal #3

3 Priorities

I think that's me. For some reason, I always fixated to number 3. Or maybe number 4. In this case, I'm thinking about what I'm doing with my time, and there are 3 answers:

1. PTC: There will be GameJam this weekend, and I really, really want to go there. Basically, I'll spent the weekend doing one whole game using PTC. It should be fun. There is a lot of projects that has been held up due to my setbacks. I need to step up my productivity.

2. My home. It's kind of a mess right now. I just discovered that the previous owner cleaned the oven by using the "self-cleaning oven" setting. Which is to say, burn all grease to a crisp. Unfortunately, that's all he did. So, I'll be scraping all the fat that is currently sticking to it. Sigh. Where's Mr. Clean? I also need to work on my paperworks, speaking of which...

3. My books. I have 4 books nearly done. 2 needs editing, 2 needs a little more materials before editing. I also have some more materials for more books. So, I need to step up to that also.

It's kind of bad when bad health is causing havoc with the schedule. Then I have the tendency to make up for time lost, then I get sick due to overwork, and repeat. I'll have to figure something out to break the cycle.

So, I should ride my bicycle more often. That gets my heart rate up, and hopefully raised my stamina so I can get more work done.

Book Review #3

Algorithms in C++

Robert Sedgewick

This is a very old copy of the book. Robert (Bob) Sedgewick has been writing this book in various languages over the years. Some of them are rather thick! The one copy I have is an old, out-of-print hardcover edition, Algorithms in C++.

How old is the book? The book came out when C++ has just come into being. The majority of computer programmer were still using plain old C. The programs in the book are written in C. Only the data structure is written in C++ format. The year was 1992.

I like to think of it as the layman's guide to Donald Knuth's The Art of Computer Programming books. Every time I read Donald's book, my mind went blank. The farthest I can read was 5 pages. That was on bubble sort algorithm, a subject in which I know intimately. Obviously, the professor has his head in academia world, because the rest of us do not read or write like that! Thankfully, Robert Sedgewick distilled the essence of it, and put forth the content the rest of us can decipher.

I have read a few more algorithm books, but I think this one stands a mention. The rest pales in comparison. If you have this book, and supplement it with special purpose procedure/math formulas book, then you should be prepared for most eventualities.

You do need to know C, but I assume those of you who knows C, Objective C, C++, C#, and other C variants will have no trouble understanding it.

Unlike, say, a special-purpose, non-existent, artificial assembly language. Really. I think it's easier to teach the readers the whole C language, than reading a single program written in assembly language.

Raspberry Pi Journal #3

Printer Trouble

I was printing my other blogspot for archival purposes, when I realized that I was double printing the month of June. I quickly cancel the print process, except it already got sent to the server, and I couldn't open up the web page quick enough for me to cancel the print. So, I did what I know would work: Turn off the printer.

Sure enough, when the printer administration web page came up, it said unable to send job to the printer. So far, so good. Obviously, I cancelled all print jobs so far.

The trouble was, I couldn't send any new print job to the printer! After trying various attempt over 10 minutes, I gave up and rebooted the computer and printer. This should have worked. Except, it didn't!

More going around to check the printer. It's not until I stumbled upon "Resume Printer" option in the Maintenance menu that I am able to print again. Apparently, there is a status recording somewhere that cause the printer to be invalid until "resumed", whatever that means.

I think this is bad behaviour.I should be able to reset the printer by turning it off. Smart devices are way too smart these days. It's no longer just a simple turn off, turn on for resetting their values. What if something got screwed up inside? You'll have to take it to the service department. What a hassle!

Libre Office trouble

I was doing multiple windows on Libre Calc, when I found out that the new window I spawned was affecting the old window as well. Of course, this happens after I'm done all editing with the new window. There goes my work out the window! To be honest, this is the first time I've seen it happen. I wonder what the purpose is to link multiple windows to a file?

In the end, I simply toss out all changes. Reload the old file, and save under different name. Close all windows, and load all files. Problem solved, but more time wasted. Growing pains, I suppose.

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!