Been working on MACH 3

Matteo Marioni, Warren, and myself have been jointly trying to test Dexter with MACH 3.  This is difficult at the moment because Teo is the one with the game but he does not have a VBI Injector board so we've tried to rig up a workaround for the time being.  After analysis of the MACH 3 hardware, we've concluded that the Manchester picture number can be encoded in a visible line of the video which means that the Raspberry Pi can render it without external help.  So we created a laserdisc image file and tested it out.

Early results were encouraging but not was encouraging as we'd hoped.  By adjusting the voltage threshold of the picture number comparing hardware, we were able to get the game to find the picture number some of the time (maybe 50% if my understanding is right) but still find garbage the other half of the time.  This is quite puzzling.  I really wish Teo had an injector board!

Another problem is the target data encoded in one of the audio channels on the disc.  Early tests showed that trying to parse the audio data from the Raspberry Pi were resulting in complete garbage.  I can think of a few things that could be wrong: a) the audio data may be offset from where it is supposed to be on the original laserdisc (a common problem with audio capturing hardware), b) the audio voltage level output by the Raspberry Pi may be too far off from the voltage level output by the original PR-8210.

Unfortunately I have neither a MACH 3 laserdisc nor a PR-8210 player so I am unable to test the voltage level coming from the audio jack on the back of that player when the disc is playing to see what the proper range should be.

At any rate, I am going to venture a guess that getting MACH 3 to work properly with Dexter may be one of the three most challenging tasks to overcome, the other two being Star Rider and Freedom Fighter (the latter possibly being the easiest of the three).

PR-8210

PR-8210 support for Dexter is "finished" but remains untested on Cliff Hanger and MACH 3 hardware (the two main targets).

Warren recently tested it on his Cobra Command conversion for Cliff Hanger boardset and discovered that the picture number from the video signal is apparently completely ignored.  The way that the game decides when a seek has finished is to watch for the PR-8210 to drop the video signal and then restore it.  In other words, it appears that all PR-8210's drop the video signal during seeks (and maybe all laserdisc players in general do this and we've just never noticed!).  If this is true, then it introduces a mystery as to what exactly needed to be different about the PR-8210 player for MACH 3.

Anyway, the gist of it is that Cobra Command (Cliff Hanger conversion) is now tested and working with Dexter.

Our next target is to test with MACH 3 because we know for sure that it definitely reads the picture number from the video stream.  We know this because MAME and Daphne both emulate MACH 3 and provide this behavior.  Cliff Hanger also reads the picture number from the video stream (verified by the same reason).

When will Dexter be ready?

Although there is no formal release date for the next run of Dexter boards, here is what I can tell you:

I am extremely motivated to finish this project and am working on it constantly.  I am trying to prioritize finishing laserdisc players that have the most games associated with them.  This is why I did LD-V1000 first, then Sony LDP-1450, and now PR-8210 (Neil W. contributed the firefox player code).  I also tend to prioritize doing what will make the finished product as easy for the customer to use as possible (I've learned by working on Daphne that releasing something very hard to use is just not worth it).  I did release the rev2 board which falls in the "hard to use" category but that was because I needed testers and also capital to make the boards in the first place so I could keep development going.

It's been about 2 years since I made the rev2 boards (December of 2011).  I think people have been very patient and therefore I really want to release a rev3 to "the world" soon, hopefully within the next 6 months (but no promises).

My plan for rev3 is that it will be somewhere between a completely finished product and a product still in development meaning that it will probably be something like this:
- two bare boards (Dexter and Raspberry Pi) that will sit inside your cab (we'd like to come up with a fancy way to protect the boards and mount them but I don't want to delay production for people who want them Right Now and have waited so long)
- Officially supported modes will be LD-V1000, VP931 (firefox only), LDP-1450, and PR-8210.  The rest of the modes will be included on the LEDs on the board (like rev2) but will be clearly marked as "not working, may never work" on the silk screen so that there are no false expectations.
- During this time, I will keep working on releasing new modes such as PR-7820, Hitachi (astron belt), VP932 (PAL euro), PR-8210A (Star rider), VP-931 (for freedom fighter), Simutrek (cube quest).  I'll do my best to predict whether I can implement these modes before actually doing it.
- LDP-1000A and VP-380 will _not_ make it in.  These require a new architecture.
- Updating the firmware will be easy (much easier than rev2).  You won't need to program the microcontrollers as I've written a bootloader so that they can be automatically updated via the raspberry pi's serial port.
- We will also need to bottom out on how to provide the disc images to the customer.  I may write a "Dexter Loader" spin-off of DaphneLoader that will load the images and software/firmware updates to a USB thumb drive which can then be inserted into the pi.
- Price of the boards will be determined by how many people pre-order.  My minimum goal will be making 50.  I will be hand soldering prototypes ahead of time to make sure the bulk production run is correct.

As you can see, there is still a lot of work to do, but we are closing in.

OpenBench Logic Sniffer upgrade HOWTO

I got one of these about 6 months ago but only recently started messing with it.  I wanted to make sure my firmware was up to date so I started reading up on how to update it and quickly hit a brick wall of confusing, outdated and obsolete information.

Updating the FPGA bitstream (to v3.07) seemed okay but trying to update the PIC code was not working at all for me.

Here is the best guide I've found: http://samelimmat.blogspot.de/2013/05/open-bench-logic-sniffer-with-os-x.html

I did this on linux.  The problem is when you go into update mode, the /dev/insert-your-usb-device-here goes away after a few seconds so passing it in on the command line is problematic.  I discovered that if I got the command line ready, and then went into update mode (by holding down UPDATE button and pressing RESET) that the /dev/insert-your-device-here would stay resident for a brief period and I could quickly run the command line.  It worked!

See http://www.mikrocontroller.net/topic/264866#2759493 for how I got /dev/OpenLogicSniffer

The exact command line I used:
sudo /home/matt/ols-fwloader/bin/ols_fwloader -f BOOT -n -P /dev/OpenLogicSniffer -V -W -w OLSv1.firmware.v3.0.hex

PR-8210 Dexter support almost done

PR-8210 Dexter support is almost done!  This is a fantastic milestone because it will (theoretically) unlock the following games: Cliff Hanger, Goal to Go, Bruce Jenner (hehehehe), MACH 3, Us Vs Them, Cobra Command (Cliff Hanger conversion), and Cobra Command (MACH 3 conversion).  Now that's a lot of games! :)

What's done:
---------------
- PR-8210 interpreter written and unit-tested
- test program written on another AVR to simulate sending PR-8210 serial data over the wire (so that I don't need an arcade boardset to test)
- dexter code written to interpret incoming pulses on the wire and correctly convert them into PR-8210 commands
- dexter code to inject VBI data into video stream (woohoo!)

What remains to be done:
----------------------------
- hooking up PR-8210 interpreter to Dexter
- implementing step forward/backward generic LDP command to Dexter (seems that MACH 3 and Cobra Command both use these as a substitute for pausing the disc)

Made progress on PR-8210 code

Last night, I've wrote a lot of the Dexter code for PR-8210 support.  It should be able to now correctly interpret incoming pulses on the wire and convert those into messages.  I still need to take the interpreter inside Daphne and modify it so it can be used with Dexter but that shouldn't be too hard.  Unfortunately, I don't have any arcade hardware which used the PR-8210 so I have nothing to test it with.  I plan on rigging up my STK600 to add as a controller.  I will need to find a jack that plugs into the PR-8210 port on the Dexter board and modify it so it can be plugged into the PR-8210.  I've gotta have a cable lying around here somewhere that will fit.  Interpreting the PR-8210 is actually pretty trivial compared to something like the VP-931 but not having an authentic way to test it is a pain.  Fortunately, Warren can test it on his Cobra Command Cliff Hanger conversion board set and at least verify that it works for one PR-8210 game.

VBI injection now working dynamically

After some more coding and debugging, I've got VBI injection working pretty reliably (and I am _very_ pleased about this!)

Here is what the VBI data looks like on the original Cliff Hanger laserdisc.  (I captured this from my disc)

Here is what the VBI data looks like on Dexter (using VBI injection).  Note that Dexter only is displaying the data that is described in the official laserdisc standard because this is what is needed to inject the frame number into the video stream.  Dexter does not try to re-generate the other non-standard schlop stored on the original laserdisc.

Bootloader tested and working!

I've finished writing my custom AVR bootloader.  I had to resort to some trickery in order to keep it fitting within 2k but I succeeded.

Here is what it does:

When Dexter board is powered on, bootloader checks a location in the EEPROM to see if last update succeeded.  If it did, it immediately boots the Dexter code.  So the bootloader is essentially invisible in this scenario.

If the last update did not succeed (or the bootloader has been installed on a fresh microcontroller), the bootloader sends a message on the serial port requesting for the listener on the other end to upload the firmware to it.  It will continue to do this indefinitely until it gets the complete firmware program uploaded to it.  At this point, it marks in the EEPROM that the firmware programming succeeded and boots the firmware.

This _should_ cover most disaster situations, including the power going out in the middle of a firmware update.

The only situation it doesn't cover is if the firmware itself is defective.  The firmware will need to correctly be able to initiate a self-update of itself and if this part of it is buggy, the bootloader has no way of knowing this and will happily continue to boot the firmware.  So I also made it so if you hold down the DIAGNOSE button while powering on, the bootloader will initiate the reprogramming sequence no matter what.  This is my disaster-recovery option.  And if someone does it by accident, it should just reprogram with no harm done.

I think I've covered all the bases.

Bootloader written, but not tested

Since my last update, I've realized that I really need to write a "bootloader" for the AVR so I've been working on that over the last week.

What is a bootloader?  It's a small program that is installed at the top of the AVR's program memory and boots up first.

Why do we need one?  It's so that I can push out firmware updates through the AVR's serial port instead of requiring an ISP/JTAG programmer (such as the AVR Dragon).  This is a must-have feature for the finished Dexter product and I felt like the time was right for me to stop procrastinating on it and just write it now.

Instead of using a pre-existing bootloader, such as the Arduino's, I just wrote mine from scratch with the goal of making it as small as possible.  Total program size right now is just under 2k which is not horrible.  On Dexter's main microcontroller, this will mean that 2k of the total 64k will be used by the bootloader.

The bootloader make it so that the Raspberry Pi can reprogram Dexter.  This means I can release updates from time to time and no one will need to do anything technical to get them onto the Dexter board.