Seeking causes crash on AVR (bug in my code)

So yesterday when I started a game of Dragon's Lair, the AVR would crash. I wasn't sure what was causing it but today I simulated the same command sequence using the PC's parallel port (to eliminate the Dragon's Lair as being the problem) and it crashed again. Here's the log:


Starting Main Game Loop
Play
LDP : Received pause while disc was not playing, ignoring
listener: Controller is using our current settings (yay!)
listener: VLDP-HW: <- fd
listener: VLDP-HW: Play
listener: VLDP-HW: -> 64
listener: VLDP-HW: LDP Status: Spinning up
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- 2f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- 8f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- 2f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: AM HERE!
listener: VLDP-HW: Settings applied
listener: Controller said hello
listener: VLDP-HW: LDV1000 start
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> fc
listener: VLDP-HW: LDP Status: Stopped
listener: Controller is using our current settings (yay!)


Do you know what this means? It means that this.. DANG THING.. doesn't work at all!

Actually what it means is that I get to step through in the simulator and see why it's crashing. The "AM HERE!" string is the first thing the AVR sends when it boots. I've seen crashes caused by null pointer dereferencing so that is one possibility. I sure hope I can figure out a way to make the simulator run most of this code by itself because entering in the entire command sequence by hand in the debugger would take a long time.

Measured voltage levels on my dragon's lair

So Warren suggested that I measure the voltage levels on my Dragon's Lair hardware to troubleshoot my monitor's problems that were evident in the video from yesterday. I just did. It's a little hard to tell for sure, but I believe that there is some A/C interference going on. I measured the voltage between the power supply's metal piece and the monitor's metal frame which should be 0, and it definitely did not seem to be steady at 0. It seemed to be fluctuating a bit between 0 and 0.02V but since it shows an average I couldn't tell for sure. I did measure the voltage going to the NTSC decoder card and it is a solid 18.6V (supposed to be 16V). I don't know what to think about that.

Video now playing at full speed!

After getting the I/O between the AVR and the Dragon's Lair working properly yesterday, I turned my attention to getting video playing on the PC. I was seeing my CPU usage pegged at 100% and no video which was disconcerting since I knew this PC was fast enough to play the video while running real-time linux (which is slower than normal linux).

I found two things. The first one was that my code that automatically drops fields if the PC is behind was not working, so it was getting more and more behind. The other thing was that somehow I had switched to using the slowest type of JPEG IDCT algorithm. Once I switched it back to my hand-crafted SSE2 algorithm (which ended up not being much faster than the reference integer version unfortunately) things improved dramatically and the PC was then able to play video at full speed using about 75% CPU which is acceptable (considering it doesn't need the CPU for any other purpose).

So I made a video of the attract mode playing with the video being rendered on the VGA monitor. I did attempt to route through the arcade monitor on the Dragon's Lair but my usual electrical problems made this underwhelming. I've included it in the video anyway.

Sound isn't working but I haven't spent any time looking into why. It's probably something simple.

It works!!!

I finally have successfully worked out the problems with communicating with the Dragon's Lair hardware. It now seems to be working perfectly (phew!!).

I did two things:
1) the AVR datasheet has specific instructions on how to switch between input and output modes that I was not exactly following so I fixed that
2) I enabled the AVR's internal pull-up resistors when in input mode which meant when dragon's lair stayed in input mode during the command strobe, I would receive a FF command.

My log file for your curiosity/enjoyment:


listener: VLDP-HW: LDP Status: Stopped
listener: Controller is not using our current settings, so we are pushing down new ones.
listener: VLDP-HW: Settings applied
listener: Controller is using our current settings (yay!)
listener: VLDP-HW: LDP Status: Stopped
listener: VLDP-HW: LDP Status: Stopped
listener: VLDP-HW: LDP Status: Stopped
listener: VLDP-HW: LDP Status: Stopped
listener: VLDP-HW: <- cd
listener: VLDP-HW: -> 7c
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> fc
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 7c
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> fc
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 7c
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> fc
listener: VLDP-HW: <- f
listener: VLDP-HW: -> 7c
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> fc
listener: VLDP-HW: <- 5f
listener: VLDP-HW: -> 7c
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> fc
listener: VLDP-HW: <- 1f
listener: VLDP-HW: -> 7c
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> fc
listener: VLDP-HW: <- f7
listener: VLDP-HW: Search to frame 197
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: LDP Status: Searching
listener: VLDP-HW: -> d0
listener: VLDP-HW: LDP Status: Paused
listener: VLDP-HW: LDP Status: Paused
listener: VLDP-HW: LDP Status: Paused
listener: VLDP-HW: <- cd
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 4f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 6f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- f7
listener: VLDP-HW: Search to frame 306
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: LDP Status: Paused
listener: VLDP-HW: LDP Status: Paused
listener: VLDP-HW: LDP Status: Paused
listener: VLDP-HW: <- cd
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 4f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 8f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- 4f
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- f7
listener: VLDP-HW: Search to frame 323
listener: VLDP-HW: -> 50
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> d0
listener: VLDP-HW: <- fd
listener: VLDP-HW: Play
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: LDP Status: Playing
listener: VLDP-HW: <- cd
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- 3f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- 5f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- 1f
listener: VLDP-HW: -> 64
listener: VLDP-HW: <- ff
listener: VLDP-HW: -> e4
listener: VLDP-HW: <- f7
listener: VLDP-HW: Search to frame 197


Researching real LD-V1000 behavior

So yesterday I observed that Dragon's Lair was ignoring some command strobes (actually a lot of them) and just staying in input mode during this time. The result was that after a successful seek, the AVR would read back codes like 0xD0. I guess the real LD-V1000 had some pull-up (and/or pull-down) resistors for handling this scenario which I probably ought to implement.

UPDATE: Looks like my LD-V1001 won't play discs anymore, or even respond to play. That means all it is good for is comparing strobe timings :) I guess this gives new motivation for me completing my project! Hehe.

I/O with Dragon's Lair working!

It looks like I am receiving the proper commands from the Dragon's Lair board!
Unfortunately, my own AVR code seems to be pretty buggy because it is not responding properly to those codes. This is a little surprising because I am using the exact same code on the AVR to interpret and handle the laserdisc state as I am in windows/linux for DAPHNE. I did this on purpose to ensure that the AVR code would be good. Well, apparently it's not so good. But the problem is probably only in one or two places. For all I know, it's a buffer overrun or some nonsense like that.

Basically, what I am seeing right now is Dragon's Lair is sending the proper search/play codes and the AVR is responding with endless "busy searching" codes. Bad AVR! :)

At least the problem is back in my software which is my specialty, so it shouldn't be too hard to fix.

Mystery Solved!

The reason Dragon's Lair was not booting was because I did not have pin 17 (the Enter signal) connected. It was just a dangling wire coming from the dragon's lair hardware. The LD-V1000 manual made it sound like this pin wasn't used anymore so I didn't think that it mattered if it was connected, but I had eliminated almost every other possibility as being a potential problem so hooking up the Enter signal was one of the last things I hadn't tried. The reason I hadn't hooked it up earlier was because I had made the wire too short so it was inconvenient *embarrassed grin*.

If someone with dragon's lair schematics and time on their hands wants to figure out why this line needs to be connected, I would be interested in hearing about it. :)