Watched a game of Dragon's Lair play through

This morning, after some debugging/troubleshooting, I was able to watch a full game of Dragon's Lair play all the way through. This is the furthest I've got with the current AVR code so it's pretty exciting.

I was going to post a video but I am having some technical difficulties. So look for the video within the next 24 hours.

AVR Dragon JTAG interface

Just in case I want to attempt hacking on a JTAG interface to my PCB, here is a screenshot from the AVR Dragon's documentation for reference. Looks like 6 or 7 lines need to be connected.

Mystery solved!

The mysterious cause for the AVR program behaving unpredictably is solved thanks to the AVR Dragon's hardware debugging capabilities. The reason is that I was using too much data memory and it was causing the stack buffer (which resides at the end of the data memory) to overrun into some of the ld-v1000 interpreter's global variables. This would cause unpredictable behavior (and a lot of errors).

I've worked to reduce my data memory usage and have freed up about 400 bytes for the stack which should be more than enough. I can't test it right now though because my NTSC source (my camcorder) ran out of battery power and I don't have the power cable handy. So tomorrow will be the big test.

AVR Dragon works!

The dragon is a lot smaller in person than it looks in the pictures. It can program AVR's using ISP or JTAG (like the STK600) but can also debug via JTAG. It also can debug using other methods.

I spent a great deal of time this morning making sure I was plugging it in the right way. I've heard rumors that since the Dragon is cheap, it also is easy to break, so I definitely didn't want to plug in any cables backward.

I hooked my ATMega324P up to my STK600 (using my new routing card!) and then just to be safe, I removed the target voltage jumper from the STK600. I then plugged in the JTAG interface from the STK600 to the Dragon and fired up AVR Studio. The Dragon gave an error message about the target device not being powered. At that point I decided it was safe to put the target voltage jumper back into the STK600 and give it some power.
Things started working at that point. I was able to put AVR Studio in JTAG mode, program the AVR, and then start hardware debugging. Exciting!

I was seeing the serial RX interrupt handler trigger over and over again which was odd so I looked at the pins on the STK600 again to see if they were correct. Since I had previously had it wired up for the ATMega2560, there was a chance I hadn't rewired it correctly. And sure enough, I had the vsync signals plugged into the AVR's RX/TX pins hehehe. So the vsync pulse was triggering the RX interrupt.

After I corrected the pin assignment, trouble started. AVR Studio would try to program the AVR and get corrupted results. So I decided to try using the STK600 to program the AVR instead. I got the same problem. Hmmmm.. well I was relieved that I hadn't broken the Dragon already hehehe. So I started thinking that maybe something I had plugged in was interfering with the JTAG pins. I pulled up one of my schematics for the dexter PCB and saw that most (all?) of the 324P's JTAG pins were on pin group C. So I just unplugged my header from pin group C and that fixed the problem for now. I was able to start programming again and debugging.

I am using pins C0 and C1 for the status and command strobes so I will need to look at the 324P's datasheet to see if I need to reassign these temporarily in order to make JTAG work. As JTAG is not needed for the final product this would only be a temporary change but it would be more convenient to keep the JTAG pins exclusively for debugging than to have to juggle them back and forth. That's one reason I chose the 324P is it has more pins to play with.

So once I sort out the JTAG pin assignments then I can power up the Dragon's Lair machine and set some breakpoints in the debugger to see what the ploblem is with my code.

AVR Dragon arrived, made progress on GLES2 test program

Today, as expected, the AVR dragon and ATMega324P STK600 routing card arrived.

However, since I'm in the middle of trying to get my GLES2 test program working properly on the Beagleboard, I am going to finish that task first, then switch over to AVR debugging.

I am pretty close; I've got the purple rectangle displayed on the beagleboard, but it is the wrong size. I've tested my view and projection matrices on linux/x86 and it works fine but I am kinda using an odd projection matrix that maybe requires a lot of floating point precision. I am going to redo my projection matrix to a very simple one and see if that fixes it. If that is the solution then I am done. I'll test tomororow morning.

UPDATE: I was wrong, it is working fine. The reason I was confused is because my linux/x86 setup was running at over 5000 FPS (Geforce 8800GT) and the beagleboard is running at about 120 FPS. Once I enabled sync-to-vblank on the linux/x86 box, I was seeing comparable results (it ran at 60 FPS). It's good that the beagleboard is running at 120 FPS but not so good that it's doing it drawing just two polygons hehehe. Maybe there is more here than meets the eye.

Warren got his prototype built!

Looks a lot better than my soldering job :)

Got the "hello world" GLES2 program build on Beagleboard

I got the "hello world" GLES2 program build on Beagleboard and working. All it does is displays a yellow triangle against a blue background, but it successfully demonstrates how to use the shaders and setup geometry for the Beagleboard's hardware.

I ported my test program over and it isn't quite working yet; it just displays a black window, but at least it is displaying a window! :)

Also I took my beagleboard over to my mom's house to show it off to my family and discovered that the beagleboard's HDMI port does not seem to work with HDTV's; in other words, it seems to only work with computer monitors that support DVI.

From now on all further attempts to show off the beagleboard will be done via the s-video port