Today's Dexter Progress

I've made a bunch more progress on Dexter since my last blog post.

Here is a summary of things that I've improved:

1. When switching disc player modes on the Dexter board, the firmware tries to clean up itself better.  This is just an internal change that will hopefully make Dexter more stable.
2. Improved my VP-931 tester and made it flag more problems in the serial port log.
3. Improved VP-931 mode and made it more robust and safer.
4. Improved DIAGNOSE mode.  Now when DIAGNOSE is pressed, the current picture number (using VBI style encoding) will be displayed as well as the build date.  This is to help the end user have some visibility into what's going on if all they see is a blank screen.
5. Intelligent reprogramming.  Now Dexter will automatically try to do a hardware reprogram of itself if one part of it can't talk to the other part.  So if your firmware gets corrupted, the program running on the Raspberry Pi will automatically reprogram the firmware for you after 30 seconds of inactivity.  Neat, eh?
6. The USB stick no longer has to be in the Pi for Dexter to operate.  The USB stick will continue to used only for updates.  Dexter can now operate solely from the SD card. (woohoo!)

Here are some screenshots of how the VP-931 interface should look if it is working properly.

This first picture is zoomed out.  The solid blue bar at the bottom is the composite sync signal which is changing once every line.  Notice that the Read (RDEN') and Write (WREN') are staggered so that they don't stomp on each other?

Here's a medium zoom showing the beginning of a new field (notice the FIELD transition) and where Dexter is sending the status bytes (DAV' and RDEN') relative to this field.  This is a little after where it happens on a real VP-931 but it really doesn't matter and it can be tweaked easily.

Here is a zoom in of the six status bytes being sent by Dexter.  Notice the handshaking?  DAV' goes low, then RDEN' goes low, then DAV' goes high, then RDEN' goes high.  That's the game and the player stay in sync when communicating.

Testing VP-931/Firefox with Dexter

Dexter has supported Firefox for literally years, but I've never been able to personally test it because I do not own any Firefox hardware.  On my TODO list has been to make a "firefox tester" so that I can test the VP-931 mode of Dexter without having a real Firefox boardset.  Over the last few days, I finally worked up the will to create this tester and I decided to make a video to show what I've been working on.




I will be less afraid to improve the VP-931 mode in Dexter now that I can test it.

Just learned something about Dragon's Lair that I never knew

Sorry for the absence in updates.  I hope to be posting more frequently in the near future :)

For LD-V1000 operation, I always thought that Dragon's Lair kept the LD-V1000 ENTER line (pin 17, not to be confused with the PR-7820 ENTER line) tied to ground (ie always active).  However, I am wrong about this.  Looking at the schematics, I just noticed that LD-V1000 Pin 17 is actually tied to the output of an LS374 (an 8-bit latch, called U16 on the schematic).  This latch is written to via memory location 0xE008 in the ROM program.  This means that the ROM program must actively set bit 7 of memory location 0xE008 to 0 in order for commands to be accepted by the LD-V1000.  Setting this bit to 1 would disable command receipt.  I actually have no recollection of whether the ROM ever sets this bit to anything other than 0, and , frankly, I can't see any reason to do this since the LD-V1000 (I am pretty sure) has internal pull-ups to force a 0xFF "NO ENTRY" command if no data is put onto the bus during the command strobe window.

Anyway, just something interesting that I never noticed before.  The LD-V1000 suggests tying pin 17 to the command strobe (pin 7), but I think tying it to ground would also work.

Dexter Manager (Windows version) now builds by itself (almost)

Since my last update, I've done something I should've done years ago: set up an automated build system, sometimes called a Continuous Delivery system.

I am using a tool called Go , which I became familiar with as a result of my day job.  What you see in the picture is a list of build tasks.  The former ones such as zlib, expat, jansson, and openssl, do not have any dependencies and will build standlone.  Mpolib (my cross-platform bridge library) depends on zlib, expat, jansson, and optionally openssl, so it will be built if any of the former source code repositories (which I am storing locally for simplicity) change.  WxWidgets is also somewhat independent and technically has no dependencies (it can build using zlib if available or can use an internal zlib if not available).  DexterManagerLib depends on mpolib and so will build if mpolib changes or if the DexterManagerLib's code changes.  Finally, DexterManagerTest (unit testing suite for DexterManagerLib) and DexterManager (the final application that will run on the desktop) depends on DexterManagerLib and both will rebuild if DexterManagerLib changes.

Some of the cool aspects of this is the mpolib and dextermanagerlib both have unit tests suites which will get automatically run after either of those two libraries gets built.

Even more cooler is that all of this is happening on linux, but it is cross-compiling windows binaries using mingw for linux.  And the unit tests?  They are running under wine (which is super geekish and cool).

As you can see, one of the stages for DexterManagerTest is red.  This is because I have written a new unit test which is currently failing.  This is known as Test Driven Development: write the unit test first, see that it fails, then write the code to make the test pass, and see that the test now passes.  And repeat until the product is finished.  This is my preferred way to write software, although it requires a lot of patience and faith because it feels slower to develop using method.  But overall, it is definitely faster, because debugging is a breeze and doesn't take much time.

DexterManager (the final desktop app) is also red at the moment.  That's because I haven't finished setting up this stage to build successfully.  It took sooo much work to get to this point, that I am showing off what I've accomplished without actually finishing.  It doesn't look like much, but yes, it is a lot of work.

I will also need to set another set of pipelines up for building Raspberry Pi binaries, and, if I am _really_ ambitious, for building AVR binaries too (although building those by hand isn't a big deal since they don't have any external dependencies).

Dexter Manager WIP 6 January 2015

This probably won't look like much, but it represents a ton of work.  Like DaphneLoader, the forthcoming DexterManager app can now self-update.  My last video showed a contrived example of what the UI would look this.  This example is no longer contrived but it is actually downloading a real update, applying the update, and restarting.

Dexter Manager WIP 29 Dec 2014

This is a desktop app I am writing to make it easy to manage Dexter.  A high priority for me is making the app be able to update itself so that I can keep everyone up to date with my latest improvements.  So I am working on this part first.  There is a lot of behind the scenes stuff that you can't really see in the video.  That is why I added a section showing how much source code I've written so far :)

Dexter bootstrap video

TLDR: Dexter booting up for the first time in a new environment

This is a video of Dexter bootstrapping itself from a new SD card image.  It reboots twice (after creating a partition dedicated to holding .ldimg files), then copies an .ldimg file from a USB drive to its SD card in order to achieve good performance.




What does this mean for you?

It means that Dexter is closer to being able to fully auto-configure itself so that a human being needs to do less in order to use Dexter.  This is a high priority for me (to make Dexter as easy as possible to use).