Nuts & Volts - January 2006

O

T

PL

I

S

G

E

H

T

A

T

O

G

N

M

N

I

T

B

T

A

T

S

U

I

P

C

P

S

A

T

A

P

M

P

R

L

O

I

J

E

C C

T

S

,

A

H

T I

I

N

T

S

O

&

T

N

I

P

S S

■ BY JON WILLIAMS

PLAYSTATION ROBOT CONTROLLER

The other day my boss, Ken, pointed out that I have written over six years’ worth of columns for Nuts & Volts. Wow. Aren’t you guys tired of me yet? (Okay, don’t answer that question!) For all the columns I’ve written, clearly one of the top three in reader interest was called “PlayStation Control Redux” (September 2003) where we delved more deeply into the PlayStation controller protocol work started by Aaron Dahlen. Well, between then and now, Parallax released the SX/B compiler for the SX micro and the speed issues we dealt with when using a BASIC Stamp are no longer issues. That, and Ken is building a cool new treaded robot that might need a full-featured control device — let’s hack a PlayStation controller for him and let him drive that dude around, shall we?

During a recent conversation with a Parallax EFX customer, I was asked how difficult it is to learn SX assembly language — my friend is interested in building custom accessory devices for his props and holiday displays using the SX28. He was actually quite surprised to learn that, to date, all of the EFX accessory products (RC- 4, DC- 16, AP- 8) that use the SX are actually programmed in SX/B — I know because I’m part of the team that designed those products and wrote a few of the programs myself.

■ FIGURE 1. PSX timing

Why did I use SX/B? Well, I’m part of the SX/B development team so I’m really comfortable with it and — here’s the kicker — I still haven’t taken the time to commit to learning enough assembly programming to write full-blown applications. What it actually comes down to is a lack of patience on my part, and with SX/B I really don’t need to be; I can write very PBASIC-like code that gets compiled. I get the benefits of high-level programming with the execution speed of assembly language.

That said, SX/B is not a compiler in the terms that we typically think about, that is, SX/B doesn’t optimize and automatically remove redundant code. Why not? The reason is that Parallax created SX/B so that those interested in assembly could learn from it — that’s very tough to do when one looks at the assembly output of an optimized compiler. With SX/B, you can see the assembly output from your high-level code (which gets included in the comments) and see how the various instructions work “under the hood.”

So does that mean SX/B is inefficient? No, I don’t

think so; it is what it is: an inline (some call “macro”) compiler. The code we write gets compiled inline as it appears in the source file. If, for example, we have two consecutive PAUSE instructions, the code to execute PAUSE will be expanded twice — and this does use more code space. This is not a problem if we understand and design around it, and that’s really what I’m going to focus on in this month’s column.

If you look at enough of my SX/B programs, you’ll notice that they are all similarly structured and, in fact, I reuse a lot of the same subroutines. The reason is this: By keeping my code consistent, I can follow my own programs and get back into them more quickly after a break and — here’s the real important part for SX/B — by putting “big” (lots of assembly code required) instructions into a subroutine, those instructions only get expanded once and I’m able to conserve code space. The additional benefit to putting these commands into subroutines is that we can add our own (even optional) features to the routines. We’ll see how just a bit later.