Question about MAX11503 chip...

I'm not exactly sure where the s-video port's GNDs are supposed to go. Here's the schematic I've got so far involving the s-video port and the MAX11503 chip.

Other than that, I've got the layout done. The chip is intimidatingly small :)

JTAG connector works!

I just barely hooked up my AVR Dragon to the Dexter PCB using my freshly soldered JTAG connector and it seems to be working perfectly! This means I will be able to bring just the Dragon and the Dexter PCB to CAX and save luggage space while still getting great value out of having real machines there to plug into.

Soldered on JTAG connector to rev 1b PCB

In order to prepare for CAX, I decided I really needed debug capabilities, so I soldered on a JTAG connector to the rev 1b PCB. It's not pretty but it should work. (I ran out of time to test it but I did test the connections with a multimeter)

Schematic for MAX11503 chip

I started working on the schematic for the MAX11503 chip. This thing is so tiny it is less likely that we will be able to solder it on by hand but I have decided to put it on the rev 2 PCB anyway because I think it would be ideal for the finished product (where we have a machine put it on for us).

Found and fixed bug in AVR code

So thanks to Teo and Warren's super don testing, I was able to find and fix a bug in my code. The bug was because I had a stray "int" in the code which is compiled as a signed 16-bit number for AVR but is a signed 32-bit number for every other platform I support. The signed 16-bit number turned out to not have enough precision which was causing problems with the VBI once the frame number got over approximately 16,384 (because the field number would exceed 32,767 and wrap around).

Unfortunately, this is not a defect that my unit tests (when run on x86) would have caught because it only existed on the AVR. So I have changed all data types in that code to be explicit so they will be the same size on every platform. That seems like the best compromise I can do right now.

Here is Teo's latest video showing off the improved code:

Teo got super don working

It gets confused once it gets to the dragon stage, but seems to work quite well up until then. (still need some tweaks so it doesn't show the wrong fields)

Trying to help Teo troubleshoot his Dexter PCB

Teo put together a Dexter PCB probably about a month ago but has not had much time to test. Last night he got far enough in his testing to notice that nothing seemed to be coming from the Dexter serial port. And he was using a USB-to-serial adapter for his windows PC. I admitted that I had never tested it with a USB-to-serial adapter but that I had one and would test.

So this morning I tested it. At nothing was working at all, but after I rebooted then things started to work. The screenshot shows what the Dexter output currently will look like when just dumped straight to a terminal program such as the one I am using, Tera Term.

So my conclusion is that Dexter will work with a USB-to-serial adapter just fine.

I made an s-video part

I made an s-video part in Eagle. This means that the only part which is not made/accounted for is the video squelch part (which currently we have not settled on a solution). I could either mock up the too-small MAX chip we found and see how the PCB layout is looking or wait... :)

I should have a layout to post on here soon.

Changed MAX222's to surface mount

I changed the two MAX222 IC's on the rev 2 layout from through-hole to surface mount. This may free up a little bit of space but it remains to be seen whether it will be enough. I'll probably start playing with layouts tomorrow.

Almost done with rev 2

I added the PR-8210A interface to the rev 2 design yesterday.

Now we have met almost all of the goals for rev 2.

A big problem we are running into is space on the PCB. The problem is we have so many components now that we are very low on PCB space and it's looking fairly likely that we won't have enough room. In order to increase the amount of space we want to use, we will have to pay $500 for the basic commercial version of Eagle. Anyone want to contribute toward that? :)

LED driver finished, added part for NAND gate

I have finished the LED driver part in Eagle and have added it to the schematic.
I also made a part for the SN74LS38 IC which essentially nothing more than a couple of NAND gates. I will hook it up the schematic soon and then the PR-8210A interface should be ready to go.

Getting closer to rev 2 being finished...

Placed PR-8210 interface on schematics, LED driver partially finished

I updated the schematics for the forthcoming rev2 PCB with a PR8210 interface (designed by Warren). I also made a surface-mount part for a 16-bit LED driver but I haven't hooked it up yet on the schematic.

Rev 2 is getting closer to being sent off for production. We barely have enough pins on the ATMega324P to handle everything we want to do. Now the biggest obstacle is space on the PCB itself.

Looking for 16-bit LED driver

Warren had a good idea to tie the DTR and DSR lines of the RS-232 port together and just assume that that is good enough. I think that is a reasonable risk to take so I'm going with it.

We've spent the rest of the morning trying to figure out how to have 10+ LEDs on the rev2 board, driven by a minimal amount of pins on the AVR. We didn't arrive at a final solution before I had to leave to get ready for work.

More progress on rev 2 schematic

This morning I added two push buttons for changing the current laserdisc player and going into diagnostics mode.

I also added an output 5V jack to go along with the input 5V jack I already have. I removed the reverse polarity diode protector with the idea that we will just bundle the correct power supply with the final dexter product.

I also added a power LED.

Got side-tracked fixing parallel port code in Daphne

I got a little side-tracked working on some DAPHNE parallel port code. I think that I'm finished with that so now I can resume Dexter work.

The curse of the memorex...

I just looked for some DVD-R's that I burned way back in 2003. To my horror, they are Memorex discs! I just successfully read one of three. How much do you want to bet one of the remaining two won't work anymore?

Figured out why Dexter wasn't working...

I figured out why Dexter wasn't working for me when I tried to demo it for Bard.

The AVR microcontrollers have these internal configuration settings called "fuse bits" that indicate, among other things, what the clock source will be. The AVR can support different clock sources, including its internal oscillator, an external crystal, and an external clock (not sure what the difference between the last two are). I had my AVR setup to use the STK600's external clock. And when I tried to use the STK600 to show off Dexter, it wasn't working properly (Dragon's Lair would boot but the beeps were coming in slow and I wasn't getting anything on the serial port). This may have had something to do with how I was trying to power it but I haven't looked into it.

But what I tried to do was move the AVR chip over to the Dexter PCB because "I know this works and is wired correctly." But I forgot to change the fuse bits to use an external crystal so when I powered the AVR up, I had no clock and so the vsync LED was not blinking. I completely forgot about this at the time.

I should've verified that everything was working the night before and just made it work with the STK600 since that environment allows me to debug with the AVR dragon. In the rev 2 of the dexter board, I will add JTAG pins so I can plug the dragon directly into the dexter board.

Are they evil?

You be the judge. This type of conduct is something I'd expect from the Microsoft of the 90's.

Bard was here...

I tried to give Bard and his daughter a demo of Dexter but it didn't work! I even spent some time troubleshooting it and was frustrated in my efforts. So I've got some hardware troubleshooting to do.

Rough mock-up of PCB layout rev 2

I just threw all the components on the board to see how much room I had left. It's looking pretty good.

Worked on rev 02 schematics/layout

Last night I spent some time working on the rev 2 schematics and layout. Unfortunately, somehow I got my board layout and schematic out of sync and Eagle is too inept to sort it out for me. Attempts to manually sort it out seemed to just make things worse *sigh*. So it looks like I will lose a little bit of work as I have to go back to an earlier copy. This will give me an excuse to get the Eagle files checked into subversion.

23 hours later, SDL is finally decoupled

It took me 23 hours worth of development work (which is a LOT for a hobby task) but I'm finally done decoupling SDL. The resulting product is much improved and much more modular. Future ports to other platforms (GP2X, Android, etc) are now much more doable.

Now that I've finished that task, and gotten almost all of the unit tests passing on Beagleboard (yes, you heard that correctly), I've realized that my current priorities should be working on the rev 2 PCB design (since it takes time to get it back from the manufacturer) and preparing for my CAX presentation (since that is the only thing that has a due date right now). After that, my next priority will be debugging the AVR code that Warren has been testing.

Looks the same, but the code is brand new

My generic DrawString function is finished! It looks and behaves exactly the same as it did before except now it's not using SDL at all.

Help me find a good URL for this project

Since I will be showing this project off at CAX, I need a URL to direct people to for them to learn more.

My goal is something easily pronounceable and memorable (so something like VLDP-HW is out). www.dexter.com is already taken hehe

I will consider any and all suggestions :)

Finished font code

This morning I have finished the font code and just have a few more things to touch up before the generic "draw string" function is working again. Then seektest should be fully operational and I should be able to whip up a drop-down console to replace the SDL console which I can no longer use.

Warren's latest super don tests

Looks like there is a bug in the AVR code and it's not a buffer overrun. Here's Warren's latest tests:

Working on getting the generic font working again

Yesterday and today I've worked on fixing the generic "draw string" function in the dexter code. This function is used quite a bit but especially in seektest which is useful for testing. The old version relied heavily on SDL so I am writing the new version basically from scratch. It's a bit more work doing it this way but at least I can do unit tests.

All unit tests pass!

I've made some great progress on my SDL decouplage so much so that all of my existing unit tests pass. Unfortunately, some of the legacy functionality that I broke never had unit tests (because I wrote the stuff before I knew what unit tests were).
This becomes the most difficult part of the process because I don't particular want to fix the legacy stuff right now but I will probably have to fix it eventually so now is probably the best time while it's all fresh on my mind. *sigh*

Why I've started using goto's...

So every since I can remember, people have said the using goto's is a Bad Design decision and I've always agreed. There is no situation where one _must_ use a goto. And here is my evolution from using goto's as a beginner, to shunning them to eventually starting to use them again.

1982-1983 our family gets our first computer, an Apple ][+ . I am 6 or 7 years old and learn how to write a simple game in AppleSOFT BASIC. I use GOTO's all over the place.

1989-1990 I have begun to learn 6502/65816 assembly language for the Apple ][gs. Since it's assembly language using absolute branches and jumps (ie GOTOs) is typical and acceptable.

1991 I go on a vacation to Switzerland for 1 month. For some reason, while I was there, I read my first book on the C language. At this point I start shunning GOTO's.

1993 I start taking a few classes at the University of Utah. The instructor sternly tells us to never use goto statements.

1997 I take a class on computer programming that emphasizes good coding practices. One of them is to only include one return statement per function. I embrace this concept and realize that I can do pretty much anything I want by declaring a variable containing the result code at the beginning of all functions, then get through the function using nested if/else/while/for conditional sections.

1999 Development on DAPHNE begins.

2003 I finally graduate with a BS in computer science

2007 I am beginning to get really weary of nested if/else/while/for conditional sections. It's ok for small stuff but a maintenance nightmare when the nesting gets complex. I realize that using exceptions (try/catch) to abort functions early is the way I can stop the nesting madness. Instead of saying "if (something succeeds) { }" I say "if (something fails) throw exception". This seems to solve my problem... or does it?

2009 A co-worker casually mentions that using GOTO's can be useful

2010 Some of the embedded platforms I want to work on do not support (Android) do not support try/catch exceptions in C++. Try/catch generally is expensive and only useful on desktops where CPU power and memory is plentiful. At least for now.

2011 I start using goto statements as a primitive form of try/catch. Instead of throwing an exception on error, I just goto the end of the function. This allows me to still only have one return statement per function while also avoiding nasty if/else nesting.

So there you have it. I'm not proud of using goto's.. in fact, if someone can find a solution that meets my goals without goto's, I'd love to hear it.

Exciting developments

First of all, I spent another 2 hours trying to get the daphne/dexter code base back up and running after breaking a lot of stuff ripping out SDL. I'm going through all my unit tests one by one and fixing them. Sure glad I wrote them.

Warren has been working on the rev2 PCB design, trying to solve the problem of using the same interface on the dexter PCB to support the LD-V1000, PR-7820, and PR-8210A. The problem is that the PR-8210A uses a few data lines for vsync and composite sync which can be provided by the LM1881 but we don't want to try to pipe them through the AVR because it would probably be too sluggish. So he came up with an idea to use four NAND gates that either output GND or nothing (open collector) to enable/disable having the LM1881 lines go directly to the female interface shared by the three players I mentioned. It's pretty clever.

Also, a fellow named Neil contacted me recently and has taken an interest in this project, particularly for the Firefox support. He brings a lot of engineering experience and has already provided some helpful suggestions on how to improve the PCB design. We're looking forward to working with him more in the future.

We're still trying to solve the problem of preventing hardware damage if some numbskull plugs an RS232 cable into the Philips VP931 port. They are _not_ compatible and the voltages on the RS232 cable have he potential for damage.