more SDL decoupling this morning

I fleshed out some generic bitmap blitting routines (independent of SDL) and have been continuing to wade through unit tests. I'm currently reimplementing the dragon's lair bitmap scoreboard (the one that is displayed in noldp mode) using my generic video routines instead of the SDL routines I was relying on before. This feels really good to be abstracting this stuff out.

Back in business

Looks like my RAM had gone bad so swapping it out fixed my problems.

I've made good progress on the SDL decoupling task. Now everything builds and I am just fixing the unit tests so that they pass again. I also made a list of things that I broke along the way that I should go back and fix :)

Fixed?

In the process of troubleshooting, I noticed that I didn't have an internal speaker plugged into the motherboard which meant that if the BIOS was giving me error beeps, I wasn't hearing them. I also noticed that my case doesn't seem to have an internal speaker. So I cannibalized an old empty ATX case I had sitting around and removed its little speaker. I plugged it in and powered on. I was greeted with a long continuous beep.

I did some googling and decided that the long continuous beep may indicate a RAM problem. So I swapped out the RAM (which I had not tried yet I am ashamed to admit) and the machine POST'd! Woohoo!

I now have to plug in all the stuff I unplugged and see if I am really back in business or not.

Update on dead computer

I priced out a new cpu, motherboard and ram and I _really_ don't want to buy that right now when I need to be saving money for Dexter investments. So I did some more troubleshooting on my current hardware.

I swapped out the following parts:
- video card
- power supply (which was a pain!)

I removed all cards except for the video card. I removed most of the RAM.

So I've narrowed the problem down to the motherboard, CPU, or the memory and I am really pointing the finger squarely at the motherboard.

So the cheapest option right now seems to be to get a "new" motherboard that supports my older components (DDR2 memory and core2 duo CPU). I could get the same motherboard I currently have or I could try for something newer that is targeted toward legacy stuff which might have more bugs worked out of it.

My current motherboard is an ASUS P5NE SLI (and I have never used the SLI feature). It mostly works well and I definitely use the firewire port on it but other than that any motherboard that supports the memory configuration and CPU would do. Oh, my CPU is a core 2 duo E6760. And my memory is PC2-6400 DDR2 800MHz. Suggestions?

Decoupled sound code from SDL

I did some work to decouple the dexter sound code from SDL and am mostly finished.
Now I need to go through the code and remove all other references to SDL which may take a little while. I had to do all this work on my laptop as my desktop is still down (and probably will be for a week).

Computer still down

I've tried some suggestions from others on how to save my computer and it's still exhibiting the same symptoms.

So now I'm looking at what new hardware would cost.

Disaster

Last night, a high-powered electrical device was plugged into our power outlet outside of our house. This device apparently drew too much power and tripped a breaker but only then did I realize that my computer stuff was on the same circuit.

Now my computer won't boot. I have to suspect a motherboard/BIOS problem at this point. But it has drastically slowed down my progress on the Dexter project because it could be a week before I can get back up and running. I can use my laptop instead so progress can still be made but it will definitely be at a decreased speed.

Sad day.

Made great progress on SDL decoupling

Today I spent another 2.25 hours in the morning working on decoupling SDL from the dexter code. I've got the video and input completely decoupled and the only thing remaining is to decouple the sound. This is exciting.

Once I finish decoupling then I can try to get Dexter displaying GLES2 graphics on the beaglebroad again.

Worked on rev02 of the PCB

Today I was going to keep working on SDL decoupling but one of my hard drives apparently is totally corrupt (chkdsk is still working on repairing it). I am blaming the linux NTFS driver for now and intend to stop using it (I'll use it in read-only mode from now on). Fortunately, I think I have all data saved.

So instead I worked on the upcoming rev 02 PCB. We have lots of things we want to add to it but for starters I made room for two (!!) DB25 ports. Check it out.

Progress with LD-V1000 AVR code and Super Don

I found a problem with my LD-V1000 AVR code; I was putting the AVR into input mode (with 0xFF pull-up resistors enabled) right before disabling the status strobe.

This caused problems with Super Don because it uses LS374 IC's (positive-edge triggered flip flops) to store the LD-V1000's status and this value is stored when the status strobe ends. So by putting the AVR into input mode and enabling the pull-up resistors before ending the status strobe, the AVR was causing the LS374 to store a random value close to 0xFF; usually it would be 0xF6, but it was always somewhere between 0xF0-0xFF.

So I just changed the AVR code so that it ended the status strobe before going into input mode and this seems to have fixed the issue Warren was seeing with Super Don. He says that it is now locking up later so that's the next thing to troubleshoot. But good progress being made!

Warren sent me the diagnostic logs from his super don hardware

Warren sent me the diagnostic logs from his super don hardware. It was running a ROM that I slightly modified to help see what the super don hardware thought it was receiving from the dexter PCB.

After seeks, super don will wait for a status code back from the LD-V1000 that has the high bit set (meaning the value will be >= 128). If the value is not 0xD0 (seek succeeded) it will consider it an error.

Well, the Dexter PCB tries to send back 0xD0 codes, but the super don hardware sees random codes instead, usually 0xF6 but sometimes values like 0xF0, 0xF7, 0xFF, 0xFE. I don't really know what to make of it.

Decoupling SDL day #3

Not much news to report except that I spent another 2.5 hours this morning decoupling SDL...

Added IPlatform and IVideoSurface classes

Last night I added generic IPlatform and IVideoSurface classes. The IPlatform class will handle video, audio, and input and the IVideoSurface will behave similar to an SDL_Surface except it will not require SDL.

I haven't checked in anything yet because the code does not compile :o

Seeing the changes makes me happy because it needed to happen. But it is frustrating having to stop work in the middle of big changes because then when you come back to resume you've forgotten everything.

Started work on decoupling SDL

I started (and restarted) the work of decoupling SDL from the dexter codebase. Part of me really does not want to do this because I fear that once I start, the code will be broken until I finish and I don't like leaving code in a broken state (I wouldn't be able to do it in just one sitting). The other part of me says to just grit my teeth and do it.

This is about the most discouraging part of the project to work on. But I am pretty confident that when I finish I will be very glad I did it.

Well I think I know what's causing the GLES2 crashing...

After writing some more test programs, I've determined that the beagleboard's GLES2 and SDL don't play nicely together. The good news is now I know.

The bad news is that the dexter code base is tightly coupled to SDL. I've wanted to decouple this before but it has always been too much work to justify my efforts. Well, I think I will finally have to break down to do it. The resulting decouplage (is that a word?) will be an improvement but who knows how long it will take me to do. I will probably write a generic set of structs/classes that have the same structure as the SDL_Surface struct so I can just do a find/replace and keep most of the code the same.

Super don hardware tested, not working properly

Warren tested his super don boardset with the dexter PCB and the dexter PCB seems to be receiving commands from the sdq boardset just fine. However, the sdq boardset does not seem to be receiving the status from the dexter PCB properly. I was able to come to this conclusion by comparing the dexter PCB logs with daphne logs, assuming that daphne's ld-v1000 I/O is correct (which it probably is since the game works). I modified the logs slightly so they would match up in Beyond Compare and then created this screenshot.

In the daphne logs, the sdq ROM program seeks to a frame and then issues the play command, having seen that the seek was successful. However, on the real hardware, the program seeks to the frame, then does a new seek to a position 2 frames later. This suggests that it thinks that the first seek was not successful.

Made more GLES2 progress

I spent quite of time (pretty much most of Saturday) integrating my GLES2 work into the dexter media server. I got stuck for quite a while on simple coding errors which are hard to find because GLES2/OpenGL is usually quite difficult to debug. If your screen is blank when it should be showing something, all you can do is start experimenting until you hopefully find the problem.

So I finally got everything working on regular desktop OpenGLv2 (which is mostly compatible with GLES2). I then had to spend quite a bit of time getting my unit tests building (again) under linux as I had only been maintaining them under windows.

After all that, I finally tested it on the Beagleboard and it gives me a blank screen _and_ locks up when I try to show my first image. *grumble* Oh well, at least I am closer than I was.

Dexter PCB successfully hooked up to Space Ace hardware

Warren successfully hooked the dexter PCB up to his Space Ace hardware.

It seems to be working great except for the fact that when the AVR sends log information, the video stops. I have seen this same problem on my Dragon's Lair hardware. One solution is to turn off the logging but it would be nice to have both at the same time so I will probably invest some time fixing that.

Here's Warren's cool video:

Media server bottlenecks

Yesterday, Warren tried running the media server on a 3 GHz Pentium 4 and it was almost too slow. That means that I've got some major optimizations to do. But I will probably finish up my GLES2 work first for Beagleboard since I am kinda in the middle of that.

The good news is that Warren was able to do enough tweaks to get his video playing at full speed so I am hoping to see some new videos from him soon :)

Here is a dump from a profiler program called "oprofile" from my AMD64 showing which functions are eating up the majority of the CPU. It shows that almost all of the CPU power is being consumed by the libjpeg reference decoder (which is notoriously slow hehe).


CPU: AMD64 processors, speed 1802.24 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000
CPU_CLK_UNHALT...|
samples| %|
------------------
776601 40.2711 dexter.bin
CPU_CLK_UNHALT...|
samples| %|
------------------
775435 99.8499 dexter.bin
1166 0.1501 [vdso] (tgid:24944 range:0xe2b000-0xe2c000)
337096 17.4803 libGLcore.so.195.36.24
332950 17.2653 zero
190925 9.9005 libc-2.11.1.so
155456 8.0613 no-vmlinux
27350 1.4182 libSDL-1.2.so.0.11.3
13420 0.6959 libpulsecommon-0.9.21.so
11233 0.5825 nvidia_drv.so
10433 0.5410 libpulsecore-0.9.21.so
9787 0.5075 libpixman-1.so.0.16.4
6558 0.3401 libpulse.so.0.12.2
5868 0.3043 oprofiled

----------------------------------------------------------------------------

CPU: AMD64 processors, speed 1802.24 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name symbol name
318575 41.0341 dexter.bin jpeg_idct_ifast
168258 21.6725 dexter.bin decode_mcu
143847 18.5282 dexter.bin h2v2_fancy_upsample
102495 13.2019 dexter.bin null_convert
16637 2.1429 dexter.bin decompress_onepass
2833 0.3649 dexter.bin jpeg_make_d_derived_tbl
1458 0.1878 dexter.bin sep_upsample
1166 0.1502 [vdso] (tgid:24944 range:0xe2b000-0xe2c000) [vdso] (tgid:24944 range:0xe2b000-0xe2c000)
1148 0.1479 dexter.bin process_data_context_main
1033 0.1331 dexter.bin read_markers
707 0.0911 dexter.bin jinit_master_decompress
...


Yesterday's video

As promised, here is the video I filmed yesterday morning showing my dragon's lair working.

You may notice that the video freezes before seeks. I haven't looked into this thoroughly, but I suspect the problem is that I have verbose logging enabled which means the serial port is being clogged with logging data when the dragon's lair machine sends a seek command to the dexter PCB. I expect that turning off verbose logging will solve this problem.

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

Got GLES2 working in ubuntu!

Thanks to some help from the Ubuntu ARM maintainers, I was able to resolve my GLES2 crashing issues and get it working. The issue was that the kernel and the GLES2 kernel module were out of sync.

Using the SDK I got from the PowerVR web site (I forgot their "real" name), I modified my sample GLES2 program so that it was written correctly. I tried to compile it on the Beagleboard but ran out of time so this will be my next task.

Did a full install of Ubuntu 10.10 for beagleboard

I installed Ubuntu "Natty" on the beagleboard this morning. Trying to run anything to do with GL gives a segfault. Interesting. Now I am going to try to go back to the demo image I got with my xM and see if that still works. If it doesn't then I guess I may be in trouble. *fingers crossed*

GLES not working on beagleboard currently

So I discovered this morning that when I upgraded to a newer version of the GLES libraries on my beagleboard linux install that all of the GLES demos stopped working. I spent most/all of my time this morning trying to troubleshoot. No luck yet.

The good news is I found an SDK that seems to be designed to run on beagleboard and it has a ton of coding examples so this should get me well on my way once I can get GL working again.

Made progress on GLES2 for Beagleboard

I wrote a tiny OpenGL test program that uses a simple vertex and fragment shader. I verified that it works on Windows (heh) and got this compiled/linked on the beagleboard but attempting to run it gave an SDL error saying that the GLX context could not be created. I actually have no idea whether SDL can be used for OpenGL on the beagleboard. I'm currently looking for simple OpenGL examples for beagleboard but they are surprisingly hard to find. In fact, I am having an unsually difficult time finding example code _anywhere_ for how to do GLES2 which is shocking since as far as I know, it is the standard on both iphone and android.

OpenGL Shading Language and Matrices

So it turns out that OpenGLES2 does not support the legacy fixed function mode of OpenGL v1.x which includes functions like glMatrixMode and glOrtho. I rely heavily on these functions in Daphne's OpenGL code but it looks like now I have to learn the 3D math behind these functions and implement that stuff in shaders instead. I've always wanted to do this anyway, so this will be a nice excuse.

I spent this morning reading my OpenGL books trying to figure out the matrix stuff, and also refreshing myself on how matrix multiplication works. I also played around with ATI's RenderMonkey program.

AVR debugger ordered, LD-V1001 is still not working

I thought I'd try my LD-V1001 again since it's warmer. Still no dice. It stays in parked mode when I issue it the play command.

I also ordered the AVR Dragon today (and a routing card for the STK600 that matches the ATMega324P). The Dragon is a low cost debugger. I've decided that I really need it to work out the software bugs in my AVR code because using the simulator can be brutal when a lot of setup is required. Based on past history, I'd say the Dragon will be on my door step in exactly 7 days.

MAME's LD-V1000 isn't so great after all..

So after my LD-V1001 apparently stopped working, I decided to use MAME's emulated LD-V1000 to discover some specific LD-V1000 behaviors during error conditions. For example, if I seek to a frame that can't be found and then issue a play command once it has returned an error, from where does the LD-V1000 start playing (if at all)?

Unfortunately, it seems that the MAME emulation for the LD-V1000 is not that great. For one thing, during disc spin-up it alternates between status codes 0x64 and 0x58 and I verified on my real LD-V1001 (when it used to actually work) then during spin-up it would display solid 0x64's.

I also tried to simulate a search error by telling it to search to frame 79999 (which didn't exist) yet somehow the search succeeded in MAME. I can't really say what would happen on a real LD-V1000 but I am assuming that the search would fail with an error.

I suppose I don't necessarily need to know about all the error conditions, since Dexter (in theory) should never get errors when working properly. But it would make me sleep a little better at night.