O
T
PL
I
S
G
E
H
H
T
A
T
O
G
N
M
N
I
T
B
T
A
T
S
U
I
P
C
P
S
S
A
T
A
P
M
P
P
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.
PLAYSTATION
CONTROLLER PROTOCOL
It turns out that the PlayStation
18
January 2006