As I previously mentioned, I skipped Lesson 8.  It is generally reckless to solder something to a PCB without having first tried it out on a breadboard, but since most of the lessons already confirmed to me that the SX, the 7-segment LED driver, the resistor ladders, etc all work as advertised, I felt I didn’t want to keep doing it just to get more breadboard practice.

I’m not new to soldering.  I’ve got a half-completed 2m amateur radio transceiver in my closet (note to self: finish the thing already).  So, in light of that, this wasn’t a challenging lesson.  For that, I’m grateful.  As I’ve said before, when you’re learning to fly, it’s less important to know the mechanics of taking off as it is to know how to get out of a stall and spin.  Knowing a few things about how to solder, remove solder, test things, etc, was very handy.  For the most part, I didn’t get too many problems.  One of the “seats” in a DIP socket came out and the wires for the 9V battery broke repeatedly.  Other than that, it was smooth sailing.

So, below are some pictures of my completed XGS Pico Edition and it running a demo on my LCD TV.  Two things that are important to note– the LCD TV warning, while not as serious, should be followed.  When the Racer City game logic kicks in, my TV gets fussy and starts adding color noise; a standard CRT does not.  Second, the XGS PE uses the SX28 and the XGS ME (the PE’s “predecessor”) uses the SX52, which has more memory and more registers.  Most of the downloadable demos on the XGameStation site, therefore, require portage to work.

Some resisors for the 7-segment missing...TO RADIO SHACK!

My first run of the XGS PE

All in all, I’m pleased to have everything on a PCB.  I feel like I’ve learned a lot at this point, and now I’ll get to enjoy a few labs on programming this platform.  I’ll probably start tonight.

In the meantime, the parts of my brain dedicated to learning about hardware design can start scoping out a future project.

Regardless of what I mention in the previous post, it turns out my problems had nothing to do with the LCD screen I bought.  For reasons that are not entirely clear, the version of the SX-Key IDE which I have seems to not like the SX-Key that came in my kit.  It will program the SX just fine, but it doesn’t seem to generate a proper clock signal for it on the first try.  After trying the NTSC demo programs on a CRT TV, I became frustrated and decided to poke around with the manual clock control feature of the SX-Key IDE.  Well, merely engaging this feature seemed to cause the SX-Key to reset the SX and issue the correct clock signal.  I was then able to confirm correctness on my little LCD TV at home.

It’s still not a good idea to use an LCD screen apparently.  Some of them are just fussy, while older CRT screens will forgive you a bit more.

Anyway, the demos are pretty cool.  One is a monochrome test pattern, one is a color test pattern, and one is a scrolling star field that immediately made me go “Oooh!  I am building a game console!”  This is also the first time I’ve confirmed the correctness of a resistor ladder on a breadboard, which makes me feel good for my breadboarding skills.

This lesson definitely makes it worth it.  It also is a great reminder of using the XGameStation forums as part of the kit.  While I would really like to see Nurve add more material to the kit regarding ways to debug a circuit which is going wrong, they do a good job of tracking the forums and being patient with rookie questions and mistakes.

I’d encourage anyone having trouble with this lesson to follow the discussion thread I’d started over there.  It might give you some interesting ideas on how to debug an R2R ladder or how to poke about with the somewhat temperamental SX-Key.

Lesson 8 involves putting the entire XGameStation Pico on a breadboard.  I’m going to skip this and proceed to soldering it to the PCB.  I don’t feel I need the extra breadboard practice, and while it is a risk to solder down a circuit that hasn’t been tried out on a breadboard, I’m willing to take that risk.

I guess you could consider this a pre-review of lesson 7.  I can be pretty verbose, so I’ll give you the summary first.  Do not use this kit or the XGS Pico with anything but a CRT TV. Now, for the story…

The story begins with me realizing that lesson 7 covers generating NTSC signals with software.  To say that I’ve been salivating over giving these lab exercises a whirl is putting it mildly.  Anyone who knows me knows that I live for the moment when I make a device come to life, and for me, blinking some lights just doesn’t cut it.  So, this is the big one, Elizabeth!

I try to live a fairly compact life.  I own a single television set, which serves double-duty as both the family TV and the monitor for my PC.  I bought this TV with money from my Google internship back in 2005, and even today I don’t have that kind of “walkin’ around money”, so I’d be daft beyond daft to plug my homebrew circuit into my only TV and computer monitor.  Even if it’s designed safely, why risk it?  So, I popped down to Target to get the tiniest TV I could find.  This was a nice little 7″ LCD television.  I was pretty excited.  Not only will this serve as a good test screen, but maybe I can put it in an innocuous place in the apartment and find a good use for it.  $180 later, I strapped the thing to my bike and took it home.

Today, I woke up gleefully and after some much-needed late morning sloth, I wired up the NTSC signal generation circuit as described in the Game Console Design Kit materials.  At first, I got nothing, then figured out that I hadn’t set up the TV right (which I tested with my Playstation 2) and also discovered I’d had the “brightness” potentiometer dialed so high that there wasn’t much signal to detect.  After fixing those two things, I ended up with something like what you see in this video.  It would seem the red and blue “fuzz” is just general noise, which you’d expect from a breadboard circuit like this one.  The kicker, however, is the big white bars in the middle.

I played around with it all afternoon, desperately trying to figure out what I did wrong.  It turns out that nothing is wrong with my circuit.  What I did wrong is buy an LCD TV to test this out on.  It would seem that LCD TVs do not have good tolerances when it comes to compliance to the NTSC signal standard, and I’m running headlong into a problem caused by a fussy TV and software which cuts corners in its NTSC signal generation.  You can read all about it, including a diagnosis of the issue and a handy trick for debugging a resistor ladder, at this thread on the XGameStation forums.

Originally, I felt the hacker in me rise to the challenge of cleaning up the NTSC monochrome demo.  Then it dawned on me– EVERY XGameStation program generates an NTSC signal in software, meaning that every last one of them is likely broken, too.  While there’s also the upside in that I’d be getting the fun of rolling my own everything, I feel that this would rob me of time to devote to additional topics and immediately divorce me from an existing corpus of knowledge and experience.  I’m trying to broaden my horizons, and while I might enjoy the fun academic challenge of fixing the NTSC mono demo, I’d be taking the long way around the lake to continue that way forever.

So, the long and the short?  Don’t use an LCD TV with your kit. Go get an old CRT TV and use it.  You’ll thank yourself.   Some LCD TVs are ok, so if you have one that works, bully for you.  However, some are very uptight about NTSC compliance and being even a couple of clocks off is enough to ruin it.

This set of labs represents the “front nine” of the XGameStation Game Console Starter Kit.  I’ve looked ahead a bit, though, and it’s also fair to say that this is the penultimate lesson on hardware.  Lessons 8 and 9 are about prototyping the entire console on a breadboard and assembling the PCB.  Lessons 10-12 are on programming for the console.  While I do look forward to learning more about coding from the Parallax SX28, as I have wanted to do more embedded systems programming in my spare time, I can’t help but feel that much is missing.  There’s a 30-pin expansion header, and no lab that will cover it.  I also find it sad that, despite how the lesson slides allude to cartridge-based systems, boot code to load and copy cartridges, etc, that the XGS Pico seems to not have the necessary hardware for it.  That is, the XGS Pico appears to require reprogramming to change games.  What’s more, the kit ships with a copy of “The Black Art of Video Game Console Design” which was written for and about the XGS Micro, which seems to include a lot of very interesting hardware (like a keyboard), making me feel like I’m not getting the full experience.

Anyway…none of this makes the kit bad.  It does, however.  Having missed opportunities to teach more doesn’t mean it’s failing to teach.

Lesson 6 is basically all about audio.  The three labs deal with making sound first through the old school methods of an oscillator and frequency divider and then with software synthesis techniques– pulse width modulation and pulse code modulation.  I actually put off this lesson for a little while because I wanted to buy a second breadboard to put the basic synthesizer on.  After placing my SX, I wanted to keep it there, and the first lab requires removing it.  A minor frustration, sure, but not insurmountable.  If nothing else, it’s good practice for wiring up the SX in a jiffy.

A basic 4-tone synthesizer.

In working on this lab project, I encountered a familiar problem with this kit– the labs are clear and straightforward but lack information that would be invaluable when troubleshooting.  In this case, when I first pressed a button, the speaker would “POP” but not make any apparent sound.  As I don’t own an oscilloscope and signals in the kilohertz range are too fast to see on a multimeter, I fumbled with some extra capacitors and made the 555 timer IC output a much slower (~1Hz) signal, then replaced the speaker with some LEDs and confirmed each button was providing a correct division of the source signal.  Once I knew that the circuit worked, I suspected the speaker, and I found that the tin on the wires (to prevent fraying) looked a little suspect and didn’t seem to fit in the breadboard well.  So, I clipped the ends off and used some alligator clips to attach the speaker to some new leads.  Pressing a button then gave different faint, almost inaudible buzzes.  I still suspect the circuit needs an amplifier in there somewhere, but I’m not trained enough to know.

Pulse width modulation circuit

The next lab features the Parallax SX28 again.  In this case, you’re working with Pulse Width Modulation (PWM) audio.  I may state this somewhat incorrectly, but essentially, the microcontroller can send square wave pulses of different widths, and as they go through a specially designed RC circuit before reaching the speaker, you gen non-square-wave sounds coming out.  It’s neat, though a touch limited, of course.  I found that this lab went off without a hitch, and I actually had a great deal of fun playing around with the sample code to generate sounds.

Pulse code modulation circuit

Finally, we come to the PCM audio lab.  PCM audio is the kit’s first treatment of an D/A converter.  That is, it’s a means of taking a number of digital outputs and converting them into a single analog value.  This is, of course, pretty critical in generating stuff like audio and video.  The lab itself has an ingenious presentation, offering you the chance to record some audio on your personal computer and play it back in 4-bit PCM on your nascent game console hobby kit.  To do this, you first record some audio using a special tool on your PC, then run it through a program provided by the kit’s creator.  This generates assembly code that can be programmed onto your SX.  I didn’t get the results I expected…the output audio was completely different from the input.  I suspect this may be my own fault, however, as I used a different version of the sound recording tool or perhaps just saved my file at the wrong sampling rate or something similar.  The lab does come with a ready-made program that contains recorded sound, but I didn’t think to try that until I was at work the next day.  My hat is at least off the the authors on including that program, though, as that’s a level of troubleshooting support that the rest of the projects should be at.

Hey!  It’s microcontroller “Hello World!”  How fun is that?  The labs for lesson 5 introduce the student (that’d be me in this case) to the fundamentals of working with a microcontroller.  That is, hooking it up to power and ground, building its programming circuit, and using its programmer tools to load a binary onto it.  There are three labs in this one; all are essentially flavors of the same fundamental lab.  The easiest one delivers you some blinkenlights (pictured below).  Another demonstrates use of the microcontroller as a seven-segment display driver.  The final one is a sort of crude one-dimension pixel game played with some LEDs and a pushbutton.

It’s great to finally feel like I’m getting to the meat of the project, that is, using a microcontroller to do things.  All in all, these lessons are fun and definitely produce an air of excitement.  There’s nothing quite as much fun as plugging in the programmer key and watching it all work.  I also can now definitely understand the author’s choice in microcontroller (the Parallax SX).  It’s very easy to program and its debugging is easy to control.  It’s a good beginner’s chip.

Of course, inevitably, I have to mention what seem like the road blocks to learning.  Both of these are minor complaints and should be taken as such.  The first is that I don’t think enough attention is paid to what could possibly go wrong.  Specifically, this is the first lab in the entire kit that both has a large number of “moving parts” and which also carries the warning about how easy it is to break some of them (like the SX Key).  This lesson could greatly benefit from some material on how to debug common problems safely.  In my case, I had a problem with my programmer circuit.  The result was that the SX Key Editor could sense the SX Key and would attempt to program the microcontroller, but would then die complaining “Could not create VPP”.  I knew the problem was with my programmer circuit, but the error didn’t give me much to go on and there wasn’t much help to be found through web searches, since most of the material I found was about having oscillators on the same line as the programmer pins for the microcontroller.  I eventually decided to dissect the programmer circuit, and finally found that I’d accidentally run a wire to the wrong pin.  Lesson learned, of course, but it would have been a huge help to even see the lab materials contain information about common errors you can encounter and what you should check.  It’s nice to feel like you’re not completely out in the weeds on your own.

My other complaint is that the author provides sample code sufficient for the student to finish the lab without digging into SX assembly at all.  In fact, it brushes it aside as unnecessary to have because there’s plenty of information out on the Web.  I understand the author’s perspectives and priorities here, but there’s plenty of information on basic circuit theory on the web, too, and that got 4 dedicated lessons, each with several labs in them.

I’m going out on a limb here, but I used to teach so I feel qualified being out here.  Teaching programming by dissection is a pedagogical failure.  It’s roughly the equivalent to learning Japanese by listening to the same handful of J-pop albums over and over again.  You learn the songs, sure, but you don’t know Japanese.  Seeing how a functioning program works isn’t the same as learning how to build one on your own, and it generates little more than a shallow parroting of known idioms.  Is sample code essential to a learn-at-home kit?  Absolutely.  What’s also essential, though, are extra labs without code that push the student through writing code on his/her own.

That said, the lesson achieves its effect, which is to get your feet wet with the microcontroller and drills into you the most important rule of working with a new microcontroller — do not do anything before you first get power, a programmer, and a blinking LED to work.  That’s “Hello world!” and it’s essential to do it every time.  If you don’t, you’re just asking for trouble.  I can deal with this.  It’s pretty common for me to write a “Hello world!” for every driver, service, and application, proving first that I at least have the boilerplate structure right.  It’s good to see someone teaching this responsibly.

Blinking LEDs from Lesson 5, Lab 1

Oh!  You’ll notice an extra LED in this photo, off to the left.  That’s not part of the lab at all.  Basically, the barrel connector I was sent is mildly defective and sometimes the wall wart doesn’t make enough contact, causing issues.  I got tired of constantly testing to see if I had a power supply problem, so I put an extra LED on to let me know that the power’s on.  I also added a simple switch so I could turn the power on and off without unplugging the wall wart.  It’d be nice to see these added to the labs in general.  It’s convenient and easier on your parts.

As mentioned previously, I am working my way through the labs of the XGameStation Game Console Starter Kit 2.0.  This represents my first experience working with electronics, prototyping on a breadboard, etc.  I get the feeling that I’m fairly well placed in the target demographic Nurve had in mind with this kit, which is, of course, why I want to track my progress and provide some review of the kit.

First off, there’s opening up the kit and unpacking the parts.  The kit is well-packaged and has a detailed manifest of all of the parts contained.  I immediately went out and bought a crafting box to keep all of the components, the tools, etc.  The manifests contain some pictures and diagrams, so I figured I’d keep them on hand anyway.

The book which comes with the kit is clearly written by an expert in the field and, as such books go, the pedagogy is above average.  It is, however, a book published by SAMS, and it carries with it all of the usual problems associated with this publishing company.  A large number of the figures are misprints, often being duplicates of the previous or next figure.  Other diagrams are backwards.  Copy editing also seems to be lacking, as I’m not sure a book on microcontroller systems needs a segue on how Captain Kirk is “the original space pimp.”  These errors are frustrating but don’t substantively detract from the book which is itself a fast and informative read and prepares one well for the projects to come.

I really endorse not only finishing reading before doing the presentation slides and labs, but I suggest reading well ahead of the presentation slides.  Especially early in the book, the chapters build on each other, and having the broader first exposure makes it easier to follow along with the slides and lab lessons.

The presentations appear to have some minor problem with them.  They’re done with PowerPoint and the audio seems to cut out early on most slides.  My solution was to load all the audio MP3s on a playlist and play the playlist, advancing the slides when I hear proper pauses.

So, now for the labs.  I’ve done most of the labs for lessons 1-4 at this point.  Essentially, these are activities that cover introductory RC circuits, using SPICE, the basics of working with DIP ICs, combinational logic, flip-flops, and state machines.  Some of these labs are done on a breadboard.  Others are done using software provided in the kit.

The first thing I must comment on is this — Nurve needs to do a better job checking the parts they include in the kit.  The first time that this bit me was in a lab for Lesson 1, where I was asked to use a specific current-limiting resistor in series with a LED, only to find I had no resistors with that specific amount of resistance.  Sure, I had some that were close, but I’m a roockie with electronics and I wasn’t sure if I could use one of those.  After scraping around the parts lists, triple-checking several times, consulting websites on resistor color codes, and fretting, I finally found a tiny note that some parts had been replaced with comparable parts that would work fine even if specific resistances/capacitances/whatever weren’t reflected.  This might be comfortable to someone who knows what they’re doing.  I didn’t, and as a good engineer, I don’t just cavalierly reinterpret instructions without knowing what’s going on.

Additionally, One of the more important parts of Lesson 3 involves developing a timer using the famous 555 timer IC.  This IC can change the frequency of its output based on the resistors and capacitors you tie to some of its pins.  Critical in finishing the labs in Lesson 3 and others is wiring up the timer IC to a 10uF capacitor to provide a 1.2Hz signal.  The problem is…the kit does not contain an extra 10uF capacitor.  It does contain a 10uF capacitor, but this component is already dedicated to supporting the voltage regulator.  When I contacted Nurve about this oversight, they did not respond.

So, now for some pictures.

The most visible fun in Lesson 1 is hooking up the voltage regulator and then confirming it works by hooking a LED to its output:

Hooking up a LED to the voltage regulator.

Later on, you get to the more fun stuff.  Other labs don’t make for particularly good photography, so I’ll skip ahead.  Lesson 3 includes playing with logic gates.  You can see here as I tap on the inputs for an OR gate.  The gate stops output to the LED when one or both of the inputs is depressed:

An OR gate output through a LED.

It’s at the end of Lesson 3 where I discovered the lacking of the parts.  The goal was to build a 4-bit binary counter.  To do this, you tie the output of the 555 timer IC into a binary counter so that it counts on every beat of the timer’s output.  First off, the breadboard becomes horribly cluttered under this project.  Secondly, I had to go buy a new capacitor before I could build the timer.  So, to at least develop skills, I hooked up the counter circuit and then manually set a state on it.  You can see it registered through the LEDs:

A 4-bit counter with a hand-set state

When I finally did drag my butt to Radio Shack to get the necessary components, I had limited work space and felt I’d learned enough about working with the counter that I didn’t want to have to get bogged down.  So, I instead just designed a circuit for the timer and showed that it’d blink a LED…this is the electrical equivalent of “Hello World!”  I also want to point out here that the barrel connector for the AC adapter is quite flaky.  Until I can replace this part, too, the best I can do is struggle to seat the connector and plug and then put in a simple switch to turn on and off the supply voltage.  I strongly encourage that Nurve consider making this the standard power supply circuit in the future, as the barrel connector is weak and subject to wear, it’s a good lesson, and once the voltage regulator is seated on the breadboard, it’s foolish to remove it.  So, why not make this more robust and user friendly with a simple switch?

Making a LED blink with a 555 timer IC

Future labs beyond this point increasingly dive into the SX microcontroller and speak more to critical aspects of design and implementation of the XGameStation Pico.  I’m grateful for these early labs because they’ve helped me build confidence that will serve me well on the more interesting labs.  I feel, however that Nurve needs to do more to explain the variance in its parts, to ship less brittle components, and to make sure everything the student needs is already in the box.  A once-over of their book with an editor would help, too.  No part of this will stop the determined student of digital design, but these tripwires can really stymie the cautious or those without more prior training.

I’ll be back with more tales on this project in another week or two.