Thursday, December 29, 2011

parts should arrive today


The parts from digikey should arrive at 4pcb.com today and they are due to finish the bare PCBs tomorrow which means that should start assembly on Monday at the latest. This means that assembly should be finished no later than Monday the 16th of January since I ordered a 10 day turnaround on the assembly. I guess this gives me time to work on the software side of things. It would be cool if I could get some pics of the boards now just so we all can get excited.

Tuesday, December 27, 2011

Some parts ordered and sent off to be assembled

The rev 2 PCB's themselves will be done within a few days. I've also ordered assembly services from the company who made the PCBs for some of the surface mount IC's. This means that they will place 9 of the ICs that would be very difficult (or impossible) to hand solder. The rest of the components will be hand solder-able.

At this point, it looks like each prototype board with those 9 parts already placed will cost between $80-$90 and that is before buying the remaining parts. As for the remaining parts, I will publish a Bill of Materials and people can order what they want from the list (not all parts will be required so people will be able to save some money if they are only interested in a subset of the board's functionality).

Thursday, December 22, 2011

Rev 2 PCB's _ordered_ !


I have ordered 10 revision 2 PCBs. They should be done in a few weeks.

Six of them are spoken for already. If you are interested in one of the remaining four, and are willing to accept the risk of the board not working properly (or at all) in exchange for the chance to try out one of these boards early, let me know.

Wednesday, December 21, 2011

Gerber files generated


Getting close to ordering a batch of these things. Anyone else want one? :)

Tuesday, December 20, 2011

Experimenting with ground plane


Now that everything is routed, I'm trying to add a few ground planes. Here's what I've got so far.

Monday, December 19, 2011

WIP 19 Dec 2011, everything routed!


Everything is now routed except the GND lines which will be handled by a plane. Getting close!

Thursday, December 15, 2011

Canon AVCHD 24p Pulldown Removal

So our old Canon HV10 HDV camcorder was aging and the firewire port on it doesn't seem to work anymore, so it was time to get a new camera. We got a Canon VIXIA HF M41 which is pretty awesome because it has 32gb of internal flash memory (no more HDV tape dumps via firewire port!).

So I noticed while playing with the new camcorder that it can record in "film" mode (24 frames per second). This seemed like a neat option to have if I ever wanted to make my own music videos or laserdisc-styled games so I started trying it out only to discover that Canon saves all videos at 60i for some silly reason. It can be converted back to 24p but only with some effort. Groan.

So I decided to undertake the challenge and eventually found this page. It got me most of the way there, but I was still stuck at a few parts.

Here is what I did to finally get unstuck and get wookin' (and thanks to Warren for spending time helping me with this also!) :

I had to also install the this package in addition to ffdshow (I may not have enabled something properly on ffdshow, I dunno):

For ffdshow, I did not need to enable deinterlacing (in fact I suspect this should be avoided), nor did I need to choose ffmpeg-mt (although this may speed things up and doesn't seem to hurt anything).

My AVS template needed to be modified and looks like this:

### Batch Intermediate Inverse Telecine Template
###
### Requires: TIVTC.dll

Directshowsource("__vid__",pixel_type="yuy2")
tfm()
tdecimate()
AssumeFPS(24000,1001,sync_audio=true)
###Lanczos4Resize(1920,1080)


Also, my Batch Intermediate Creator prefs look like this:

Wednesday, December 14, 2011

WIP 14 Dec 2011


Started wiring up DB25 port (tricky!) and slimmed down the 5V tracks from 0.04 inch thick to 0.03 inch thick to make a little more room.

Thursday, December 8, 2011

Another WIP for today


Did some more work. Got most of the LEDs routed and got the LD-V1000 port mostly routed also. Will try to fill in the big gap between the DB25 port and everything else as I see how much room I will have.

today's WIP


Here is today's WIP screenshot.

I've moved things around temporarily while I work on the routing. It is like solving a complicated puzzle.

Thursday, December 1, 2011

Another revision today


A few minor tweaks. Warren pointed out that the diagnose and mode buttons do not need pull-up resistors because the AVR can provide internal pull-ups. I also tried to align things a bit better.

Dexter WIP 1 Dec 2011


My latest WIP. I've moved the right side of the board in a little bit and moved the PR-8210 jack from the top to the right side. I've also used up the remaining free LEDs which is interesting because we originally thought we couldn't possibly use all of them. :)

Wednesday, November 23, 2011

Latest PCB WIP


Here's the latest WIP for the Dexter rev 2 PCB.
Notice that I am using all but 4 of the LEDs from the LED driver which validates having it in the first place :)
I also started adding silk screen. Would this thing make sense for "Ed" to use?

Monday, November 21, 2011

Latest Dexter layout


Here's a layout I just whipped up. WORK IN PROGRESS, so don't get too excited about its flaws. :)

Friday, November 18, 2011

Verified all parts

I've verified all of the custom Eagle parts that I've made and I also started on a partial layout today. It's good to be working on this stuff again.

Wednesday, November 16, 2011

More decoupling on media server

Today I did some more work on decoupling the media server. I changed the video object code so that an arbitrary number of observers can register to receive screenshots for every frame. This is a change from the old behavior where only the main loop could receive screenshots.

Monday, November 14, 2011

Backup utility finished, data backed up!

I finished writing my backup utility and I finished making a full backup of all my valuable data (6 DVD-R's worth) so now I'm ready to resume Dexter work. Woohoo!

Wednesday, October 12, 2011

Did more decoupling work on the media server

Yesterday, I did some more decoupling work on the Dexter media server. Basically, I added multiple uses of the http://www.blogger.com/img/blank.gifObserver Design Pattern which means that the timer class and the video renderer class are more decoupled from each other. Also the input class is more decoupled. When timing events and input events occur, they are broadcast to generic "observers" of which there can be an arbitrary amount. Before, they were broadcast to specific class instances which caused undesirable coupling.

I have a new son!

My latest cool project is raising my new son who was born one week ago.

Here are some pictures: hope this works

Wednesday, September 14, 2011

Time to get upgraded version of Eagle

I've gone back and forth about this for a while but I think I've finally settled on the idea that purchasing an Eagle license is the next step. Unfortunately, this will cost $500. It will take me a while to store up that kind of cash. If anyone wants to donate to help speed the process along, let's talk; I must add a caveat that Dexter remains a "spare time only" project and may never be completed, so there _is_ an element of risk involved.

Thursday, September 8, 2011

Mocks for C#

For those who are interested in getting better at unit testing in C#, here is a quick write-up I've made giving some quick recommendations (with example code).

Check it out my quick reference for Rhino mocks.

Wednesday, August 24, 2011

Almost done

I'm almost done with my utility to prepare files to be backed up. It does exactly what I want. I wonder if anyone else would find it useful :)

Saturday, August 20, 2011

Grrrr backing stuff up

Another thing is getting in my way of doing what I _really_ want to do (Dexter): the need to transfer files off my hard drive onto DVD (or other hard drive?). I know DVD is an unpopular choice for doing backups today but it remains a decent strategy for me especially when I am backing up files which other people already have but would still be somewhat painful to recover due to their sheer size.

I've looked for software for Windows that will take an arbitrary directory on my hard drive and optimize the file structure so that it makes the most out of each DVD's space but I've been having a really hard time trying to google for that. There's too much software out there designed to backup DVD movies that gets in my way.

Friday, August 19, 2011

"high priority stuff" revealed

The high priority stuff I was working on was going through the process of finding another job. I have formally given notice to my current employer as if two days ago so now it's okay to publicly announce it. I haven't started at my new job yet so there is still some work to be done but I thought I'd let anyone who checks this blog know what I've been doing instead of Dexter work lately. :o

Monday, August 8, 2011

Dexter update

Just an update on the state of Dexter: I have had some higher priority stuff come in lately that I have chosen to work on instead so I have not done any more work on the rev 2 PCB. But I will get back to it once the high priority stuff subsides. And once the high priority stuff subsides, I may reveal what the high priority stuff is (it's secret!)

Friday, August 5, 2011

Microzine #7 rescued!

Chip found Microzine #7 at his mom's house and mailed it to me. He had two copies of it which was a good thing because I had to use both copies in order to get a good read.
Enjoy it here.

Wednesday, August 3, 2011

In theory.. it should all fit


I just crammed everything that I want for rev2 onto the board space just to see if it would fit and it looks like it just might! That is pretty encouraging :)

Zeroing in on decision...

Soon I am going to play around with PCB layouts. There is a chance that all of the stuff will fit on the current PCB size now that we have eliminated one of the DB25 ports (which took up a ton of space). I hope to post some pics soon of my sample layouts.

Tuesday, August 2, 2011

Considering ATMega2560

Well now I'm considering the massive 2560 microcontroller instead because it has a ton of pins on it, is super tiny, and is super awesome. The drawbacks? It would definitely require a machine to play on a PCB because it is just too small for a human to do. The is one reason I am still considering the 324P as well. There is no "ideal" solution here; compromises must be made no matter what.

Saturday, July 30, 2011

Still working on pin issue

Looks like we have agreed on how to solve the extra AVR pin issue which means the schematic for rev2 is pretty much finalized and now the task is to place the components on the PCB.

Thursday, July 28, 2011

Added output RCA jacks to dexter schematic

So as to make some progress, I tackled one of the things on my TODO list which can be solved independently of the current AVR dilemma: adding RCA audio output jacks to the schematic. I finished this up so now the two main obstacles to a rev2 PCB are settling on how to get the functionality that we could have if we had an extra pin, and also doing the actual PCB layout.

Considering ATMega325P but running into trouble

We are short 1 pin on the ATMega324P so we've been considering the 325P instead which has a lot more pins on it. Unfortunately, this morning I just discovered that the 325P seems to be light on features that the 324P had such as multiple USARTs and multiple external interrupts. So now I'm stuck. Maybe we can consider the surface mount version of the 324P which probably has a few more pins on it.

Wednesday, July 27, 2011

Back from vacation

I'm back from my vacation and am ready to resume work on Dexter.

I wanted to get my presentations from CAX online before I did anything else because I knew if I didn't do it soon, I would never get around to doing it. Now that that's out of the way, I can resume the fun stuff.

Thursday, July 21, 2011

Going out of town

I am going out of town for the weekend. I will have limited access to the internet. I will try to do some work on rev2 on my laptop while I am gone (that's what vacations are for, right? working on cool projects!)

Wednesday, July 20, 2011

CAX Presentation part 3 of 3

Here is the final part of the CAX video. It is mostly questions & answers.

Tuesday, July 19, 2011

Part 3 coming soon...

I will have part 3 with subtitles posted next.

Possibly some time today... :)

After I get the CAX presentations posted then I can get back to the rev 2 PCB design.

Monday, July 18, 2011

Part 2 of 3 from CAX Presentation

Here is part 2 of 3 from our CAX presentation. Be sure to enable subtitles (CC) you can follow what we are saying as the audio is sometimes hard to understand.

Saturday, July 16, 2011

Been busy with my yard


We are finishing our backyard and I've been very busy getting ready for that. Hence, not much in the way of blog updates. We ordered 16 pallets of sod (6400 square feet!) and it looks like we're going to have at least 3 full pallets leftover. So I need to water them regularly so we can sell them off.

We advertised them on the local classifieds and within 10 minutes had our first caller, so we won't have any trouble selling them. But there's a lot of high maintenance going on right now that is taking me away from working on my cool projects.

Tuesday, July 12, 2011

Part 1 of 3 from CAX Presentation

Here is the first 16 minutes of the CAX presentation about Dexter.


Be sure to enable subtitles by pressing the 'CC' button! Otherwise you may have a hard time understanding what we are saying.

Monday, July 11, 2011

Had a great time at CAX

I got back from CAX tonight. I had a great time!

I just dumped my CAX presentation from tape and probably will need to add subtitles to it before posting it to youtube so it could take a little while but I know some people who weren't at CAX want to see it so I will get working on it.

Friday, July 8, 2011

Just got dexter working on Badlands!


We plugged Dexter into BJZ's Badlands cabinet at CAX and it worked great! Steve Hertz even beat the game while we watched. It was really exciting because we have never tested it on Badlands before and didn't know whether it would work. It had a few minor issues but nothing that can't be overcome in software.

At CAX, got some interesting hurdles to overcome

Well, we're testing the dexter hardware here at cax to prepare to show it off only to discover that the dragon's lair image file I brought seems to be missing audio. So now we are coming up with creative ways to rectify that situation.

Sunday, July 3, 2011

Dexter PCB ready for CAX demo

My Dragon's Lair arcade monitor suddenly decided to start working again. So here's the current state of Dexter. As you can see, it has a few minor issues but otherwise works great!

Saturday, July 2, 2011


My Monoprice VGA->NTSC RCA converter came today. It is extremely well designed and I am quite impressed. So far it seems to perform to my level of expectations also which is great.

For fun, I hooked up Rockford's projector that he shipped me. I plan on using this projector at CAX if necessary so this is a good test.

I took a picture from my wife's phone so the quality isn't that great but you can still get the idea.

Consolidated two DB25 ports down to just one

This morning I consolidated the two DB25 connectors I had on the rev 2 design down to just one by adding a relay. This should free up space on the PCB and also make it easier for our primary persona to figure out where to plug his cable into when he is looking at the PCB (now there will only be one place his cable will fit into whereas before there was two).

The next challenge is figuring out how to control the relay since we are out of AVR pins.

Friday, July 1, 2011

Design Personas identified

I also wanted to mention that I am zeroing in on design personas, which are imaginary people that represent the users for the dexter product.

To summarize, there are four of them right now and here they are:

The Nostalgic : Person who wants to relive childhood
The Restorer: Person who likes restoring old stuff
The Tinkerer: Person who likes to modify stuff
The Preservationist: Person who likes to preserve childhood

We will be targeting Dexter primarily toward the first one. The others may get their own interfaces if appropriate.

MAX11503 chip finished

I've finished adding the s-video port and the MAX11503 chip to the schematics.

The only thing left before doing the layout is merging the two DB25 ports down to one and adding a relay. Then I'll see the bad news about how much space we _don't_ have on the PCB.

Thursday, June 30, 2011

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.

Wednesday, June 29, 2011

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)

Tuesday, June 28, 2011

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:

Monday, June 27, 2011

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.

Saturday, June 25, 2011

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.

Friday, June 24, 2011

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.

Thursday, June 23, 2011

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? :)

Tuesday, June 21, 2011

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...

Sunday, June 19, 2011

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.

Thursday, June 16, 2011

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.

Wednesday, June 15, 2011

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.

Tuesday, June 14, 2011

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.

Monday, June 13, 2011

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.

Sunday, June 12, 2011

Are they evil?

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

Saturday, June 11, 2011

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.

Friday, June 10, 2011

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.

Thursday, June 9, 2011

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.

Tuesday, June 7, 2011

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.

Monday, June 6, 2011

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.

Saturday, June 4, 2011

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.

Friday, June 3, 2011

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*

Wednesday, June 1, 2011

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.

Tuesday, May 31, 2011

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.

Monday, May 30, 2011

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 :)

Saturday, May 28, 2011

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).

Friday, May 27, 2011

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.

Thursday, May 26, 2011

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.

Wednesday, May 25, 2011

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.

Tuesday, May 24, 2011

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.

Monday, May 23, 2011

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!

Saturday, May 21, 2011

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.

Friday, May 20, 2011

Decoupling SDL day #3

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

Thursday, May 19, 2011

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.

Wednesday, May 18, 2011

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.

Monday, May 16, 2011

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:

Saturday, May 14, 2011

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
...

Friday, May 13, 2011

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.

Thursday, May 12, 2011

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.

Wednesday, May 11, 2011

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.

Tuesday, May 10, 2011

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.

Monday, May 9, 2011

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

Saturday, May 7, 2011

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.

Friday, May 6, 2011

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*

Thursday, May 5, 2011

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.

Wednesday, May 4, 2011

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.

Tuesday, May 3, 2011

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.

Monday, May 2, 2011

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.

Saturday, April 30, 2011

How hard would it be to create schematics for rare laserdisc hardware?

This morning I've been trying to fix bugs in my LD-V1000 interpreter so I decided to build the latest MAME and use Visual Studio's debugger to observe some key LD-V1000 behaviors that I am curious about. (MAME emulates the LD-V1000 whereas DAPHNE just simulates it, so MAME may be a good point of reference)

In process of doing this, I started looking at MAME's Esh's Aurunmilla driver which is based (entirely?) off of DAPHNE's since no schematics are available and getting access to real PCBs is difficult.

Well, it got me to thinking... next time we have access to an Esh's PCB (hehe), why can't we create our own schematics for it? At the very least, figure out what these unknown Z80 ports are hooked up to inside the DAPHNE (and by extension MAME) drivers.

Thursday, April 28, 2011

All hardware on the PCB tested and working

After reflowing some solder connections, I successfully tested the PCB (with all hardware installed) on my Dragon's Lair. The Dragon's Lair booted up properly and ran through the attract mode. Which means all the onboard hardware is working!

  • 5V Power Working
  • 14.7456MHz crystal working
  • ISP pins working
  • AVR working
  • LM1881 working
  • BNC port working
  • LED working
  • LD-V1000 working
  • MAX3232 IC working
  • DB9 port working
That means that I can turn my attention to getting a second revision of the PCB drafted, getting the media server up and running on the BeagleBoard, and working on the web server. I can tell you right now that the first two choices are much more fun than the third. :)

Mods applied, seems to work


I applied Warren's recommended modifications tonight. I plugged in the PCB to my serial port and turned it on and got the expected serial data (at the 115200 bit rate) so it _seems_ to work. So I am going to say that the LD-V1000 connector remains the final thing for me to test on this thing.

Final remaining PCB modification





My PCB has two known defects. I've already fixed one of them with a black ground wire. The other one is a little more complicated to fix. Hopefully these images illustrate the task that lies before me.

Warren's advice:

* cut trace from existing C3 to MAX pin 2
* solder wire from cut side of C3 to ground (MAX pin 15)
* (strip and tin the end of the wire, then cut it very short. It'll easily hook onto the component lead with just a little heat)
* (wire goes on bottom side of board)
* solder new cap (C12, I guess) directly to pins 2 and 16 on bottom side of MAX socket
* remove the chip during this process (not critical, but safer and keeps it from drawing away heat)
* as for C4, use pin 16 and the near lead of the 680k resistor (which is also ground)

PCB can be powered by STK600 through ISP pins :)


Just noticed that I can power the AVR, LM1881, and LED using the STK600 and the ISP pins. That is pretty handy. Putting the ISP pins on this PCB was a really smart move on my part, and I did it as kind of a "Well this isn't necessary but it might be nice to have" type addition.

Vsync LED is blinking!

This video says it all.

* 5V Power Working
* 14.7456MHz crystal working
* ISP pins working
* AVR working
* LM1881 working
* BNC port working
* LED working



Yet to be tested:
* LD-V1000 port
* MAX3232 IC
* DB9 port

ISP pins on the PCB work!



After some tense moments of failure, I actually decided to read the instructions for how to use the STK600 to program external devices via the ISP pins. Turns out I had to remove a jumper (phew, glad I didn't damage anything). Once I did that, AVR Studio was able to see the AVR on my PCB! I haven't yet worked up the guts to switch the clock source from the internal oscillator to my external crystal since I fear that if the crystal isn't working that I may "brick" the AVR temporarily until I can get a routing card for the STK600 to reset it. Deep breaths...

Wednesday, April 27, 2011

Finished soldering


I put the finished product on my flatbed scanner just to see what it would look like. As you can see, it looks weird! :)

But the soldering is finished... well except for the modification I nedd to do to fix the MAX3232 chip. I think I may need my wife's help for that one.

Got S-Video working on the beagle broad

I spent probably an hour trying to figure out how to enable s-video on the beagle board. The information out there is conflicting and often out of date.

I finally got a picture showing but it was black and white and rapidly scrolling. I think I was in PAL mode.

After some more tweaking I finally got the picture I was expecting. I fired up the media player for beagleboard on a random .M2V file and it looked fantastic at full screen (and was only using 30-40% of the cpu). That is a good starst but the big test will be trying to get my LDImage files playing at full speed.

I'll probably do some more soldering next since Warren wants me to program his AVR for him :)

Tuesday, April 26, 2011

Did some soldering this morning; almost done! :)




I did some soldering this morning. It actually went faster than I thought it would which is great. The part that took the longest was finding the components and placing them on the board.

I got enough of the parts soldered on to test the power supply. And... it wooks!





The digikey shipment came last night! Here's some pictures of the contents, including the ultra small Beaglebroad!

Monday, April 25, 2011

Disc enumeration reflected on web server


The layout of these radio buttons is questionable, but the concept is sound; I want to let the user put more than one disc image on a USB stick and choose which one should be active. When I pondered whether I should go to the trouble to do this, I thought "Well almost all users are going to only have one image per stick so why should I make it selectable?" Then I thought "Well, there will probably be an exception I didn't think about." So here it is.

Microzine #40 rescued!

I've been sitting on Microzine #40 for almost a month trying to figure out how to save it. The problem is it has failing sectors so typical copy programs like Copy ][+ or archival programs like Shrinkit will see an I/O error and either skip the bad sector or else abort entirely.

But I've had a belief that repeated reads of the bad sectors would eventually result in success.

So I finally wrote my own little sector copy program.

Or at least I intended to. I started writing a DOS 3.3 sector copy program only to realize that all of my development tools were in ProDOS so instead I decided to write a block copier. A block is merely 2 sectors which means I would need to get two good sector reads at a time instead of just one which is twice as "hard" on a disk full of errors, but still very doable.

I am pleased to report that by using my own copy program I was able to "brute force" copy Microzine #40 and save it. (at least, the disk checksums passed so I think I most likely got good reads)

For fun, here is the little ProDOS program that I wrote to accomplish this feat.



* matt copier

mli EQU $BF00
cout EQU $FDED
CLS EQU $FC58
prbyte EQU $FDDA
ptr equ $6

ORG $2000

start
jsr outstr
asc "Insert 5.25 disks to copy and press a key to start",8d,00
wait LDA $c000
bpl wait
sta $c010
loop
lda block_idx
sta readblock
sta writeblock
cmp #$18
bcc :1
lda block_idx+1
sta readblock+1
sta writeblock+1
cmp #$01
bcs :done
:1
jsr outstr
asc 8d,"Block: ",00
lda block_idx+1
jsr prbyte
lda block_idx
jsr prbyte

; read block
:read
jsr mli
db $80
da read_parms
bcs :error ; if no error, do the write

:write
jsr mli
db $81
da write_parms
bcc :next

:error
pha
jsr outstr
asc " Err code: ",00
pla
jsr prbyte
bra loop

:next
; increment block index
lda block_idx
inc
sta block_idx
cmp #$00 ; did we overflow?
bne loop ; if we didn't overflow
lda block_idx+1
inc
sta block_idx+1
bra loop
:done
jsr mli
db $65
da quitparms

block_idx ds 2

quitparms db 4
ds 6

read_parms
db 3 ; 3 parameters
db %01100000 ; drive 0, slot 6
da buf ; read buffer
readblock ds 2 ; block to read

write_parms
db 3
db %11100000 ; drive 1, slot 6
da buf ; write buffer
writeblock ds 2 ; block to write

outstr pla
sta ptr
pla
sta ptr+1
ldy #1
:1 lda (ptr),y
beq :4
jsr cout
iny
bra :1
:4 clc
tya
adc ptr
sta ptr
lda #0
adc ptr+1
pha
lda ptr
pha
rts

buf

typ #$ff
sav copy.system

Saturday, April 23, 2011

More work on disc image enumeration

I did more work on this today. I have all of the code fully covered by unit tests.

Friday, April 22, 2011

Digikey skipped!

E-mail from digikey:


Thank you for your order! Digi-Key has processed and shipped ...


Once these components arrive then I can start soldering them onto the PCB. I wonder how long it will take.

Recorded song, uploaded it to youtube

Last night I had some free time so I recorded a song. And since I stayed up late doing it, I slept in this morning and missed my usual early morning VLDP development work. Ohwell.

Check it out and please give a thumbs up on youtube for me if you like it. Thanks!

Wednesday, April 20, 2011

Prototype PCB has arrived!!!




The prototype PCB has come back from BatchPCB and it looks great! As you can see, it's pretty small. It fits in the palm of your hand.

Digikey estimates that they will ship out all the parts for this thing tomorrow, so when those arrive I can start soldering.

It is super cool to see my design manifest in a physical PCB. Really awesome. I'm sure the novelty will wear off but for now I am stoked!