VBI injection: it works!!

I've got my VBI injection code working well enough to be able generate complete laserdisc data.  In the above example, I successfully have generated the following data:

Track 0 Field 0 WhiteFlag:1 L16:f86767 L17:f81313 L18:f83210
Track 0 Field 1 WhiteFlag:0 L16:f86760 L17:800001 L18:800002

To break that down, on line 11 I have a solid white line (white flag), and on line 16, 17, and 18, I have data that begins with 0xF8.  And so on.  This is what I was attempting to generate so to have it succeed is very gratifying.

You may notice that there is a little wobble with the white lines in that they are not consistently drawn in the same place.  This _may_ be due to the way the AVR handles external interrupts by default.  I haven't looked into this too closely yet.  I suspect it may not matter at all since the official laserdisc spec does allow for some small variation about when the line is drawn.

Wow! VBI injection is working! Holy cow!

I am super excited about this!  This is my first attempt at injecting a 24-bit picture number into the VBI of a video signal.  Yes, it's on line 11 instead of 17/18 and yes, it's not as bright as it should be, but dangit it is working!!  I had to hand-craft AVR assembly language and count each cycle meticulously to make sure I did not drift and I am pleased to say that each bit cell is "exactly" 2 microseconds long (as accurate as the clock is) which is what the official laserdisc spec says it should be.

This was really the big hurdle that I've been procrastinating for so long and now that it's finished I can do the easier stuff.

For those curious, the voltage to create this data is currently about 0.95V where the NTSC standard says that 1 V should be about max brightness.  But often this standard is somewhat ignored.  I designed the board so that I can crank up the voltage as high as about 1.5V.  The RGB values from the current voltage are 182 and they should be closer to 255 (fully white).  According to my math, I am going to need the voltage to be about 1.3V to get it fully white.  I am sure glad I made the voltage adjustable on this board! :)

More progress on VBI injector v2

So, I couldn't figure out why I was getting the magic smoke on my last board.  Turns out that I had an extra board just in case and I had even ordered a duplicate set of parts (just in case).  So I decided to solder this extra board instead and just use the Arduino.  This was a lot easier and made me wonder why I didn't attempt this in the first place.  I guess I just wanted to try my hand at surface mount soldering!

After plugging it into the dexter board, I was able to verify that the hardware was working perfectly!  My surface mount soldering skills are climbing :)  Now, I "just" need to write the software.

Replaced 12-pin receptacle on Dexter, but had MAGIC SMOKE upon power up

So tonight I decided to replace my 12-pin receptable which had a few pins broken off (piece of junk!!).  I also decided to straighten the wires while I was at it.

Ah, now the wires are straighter.  Feels better.

Plugs in nicely to the VBI injector board :)

It also seems to work!  But, I  happened to notice some magic smoke (and a electrical burning smell) emanating from the board.  I happened to see that it was originating from this area.  Those pads include the GND and VCC pins of the AVR.  I checked (and double checked) that there were no shorts there but I did recently glob on an overload of flux and didn't do a very good job of cleaning it off.  I thought this stuff wasn't supposed to be conductive!  I guess I'll try thoroughly cleaning it with rubbing alcohol (if I can find some) and try again.  It would be really nice if I don't fry my AVR as that will set me back a week rebuilding this board with my spare.

Dexter work started again!

As I said a while ago, I was temporarily suspending Dexter work in order to finish the Cobra Command for Collins project.  Now that that project is finished, it's time to resume Dexter work!

Back during California Extreme 2013, I was hastily trying to get my VBI injector board working but was unsuccessful.  I recently spent some more time troubleshooting it and found that I had failed to connect a crucial pin to the AVR microcontroller *Face palm*.  So I've just completed a very hacky soldering job to attempt to rectify this problem.  I won't be able to test it until a few days from now because I am waiting on a part to ship from Digikey.

Cobra Command For Collins : The Interview

Getting some of Leslie's thoughts.

Cobra Command For Collins : The exciting conclusion

A few talented and determined individuals labored for 6 months to create a replica arcade game for Leslie M. Collins, who is disadvantaged in life.  After knowing Leslie for 10+ years, and knowing that his dream was to own a Cobra Command arcade game, and concluding that he had done everything possible within his own means to make this dream come true, we stepped in and made up the difference.
We raised money, built (from scratch) the cabinet, painted it, got replica art work, wired in the electronics, and wrote the emulation software to play two classic laserdisc games: Cobra Command and Cliff Hanger.

Upon placing the video game at the Pinball Hall of Fame in Las Vegas, we lured Leslie to the location on pretense of just hanging out with one friend to enjoy an afternoon of pinball games.  We allowed Leslie to randomly discover this game on his own.

This video shows this moment (captured from 3 angles) and his reaction.

Upon discovering the game, he was very excited.  We let him soak it in for a few seconds before revealing ourselves from our hiding place.




Technical notes: This game runs on Daphne ported to the Raspberry Pi by myself (heavily optimized).  Cliff Hanger runs a 100% speed, Cobra Commands runs at near 100% (you can't really notice any problems).

Here are some other random video clips for those who want more of the experience.

Should emulators be commercial (part 2)

I just read a fascinating article (see http://technologizer.com/2012/01/23/why-history-needs-software-piracy/ ) about why software piracy tends to unwittingly preserve digital history much more than copyright holders do.

The part that jumps out at me is that DRM (aka copy protection) seems to actively interfere with preserving software because it is designed to prevent the software from stolen (which has the side effect of the software becoming un-preservable down the road).

In my previous blog post, I mused about making parts of Daphne closed-source and partially commercial in the future because I feel like I need to be able to justify the time I spend on less interesting improvements to Daphne (ie a polished Raspberry Pi port).  It almost feels like I am somewhat forced to add some kind of DRM scheme as part of this experiment.  This puts me in a big quandary.

The crappy part about DRM is what the above article states to eloquently:
"That is why DRM feels fundamentally wrong from a humanistic standpoint: it conspires, in conjunction with time, to deprive humanity of its rightfully earned cultural artifacts."

The irony is not lost on me.  What business does an emulator have being closed-source (with DRM) when the whole mission of the emulator is to presumably preserve memories from becoming lost forever?  Could the hypocrisy be any more blatant?

I don't have all the answers right now.  But I've thought of one possible solution to this problem.

The solution is to do what John Carmack (of id Software) tends to do with his games.  He sells them commercially, lets them make their money, then he open sources them after they've lost commercial viability.  In this way, he is both getting paid for his work AND he is preserving his work for posterity.  In other words, the idea is to have a temporary DRM system that expires after a relatively short period of time.  I like this idea and I think it could work for what I am trying to do.

In case you are wondering what I think I am trying to do (and this seems to change regularly as I try to figure it out myself):

1. I want my work to be preserved forever which means I am highly motivated to have all source code completely open.
2. I want to be able to justify the time I spend on my less-interesting work which means I probably need to start getting paid for it, which probably means some temporary DRM system.  Hopefully the knowledge that it would only be temporary will help people tolerate it a lot better.

This seems like a good idea now, I may think it's nuts when I come back tomorrow and re-read this.

And the good news is that I won't be acting on this any time soon (maybe years) because I am still working on DEXTER.  So this plan still can do through many revisions.  If anyone has any good ideas, I'm pretty open at this point.