Made some more progress on LDP-1450 text overlay

I tried the trick of expanding the source texture to twice its normal twice and enabling filtering.  This looks really good but there are still a few artifacts when the grey background is enabled.

Here are some screenshots for comparison:

Finally generating LDP-1450 characters in GLES2

I finally broke down and wrote some GLES2 code (including a new vertex shader) to render LDP-1450 text overlay.  While this may sound like a trivial task, it was actually quite difficult coming up with an approach that would run fast on the Raspberry Pi.  Trying to just render to a frame buffer directly would've been far too slow so I needed to come up with a tile system.  I am still making speed improvements, but I am pretty confident that I am going in the right direction.

Here is how the original LDP-1450 text looks:

 Here is how my generated text looks using no filtering (ie nearest neighbor):

Here is how my generated text looks using filtering:

This isn't an exact comparison because the LDP-1450 text I captured is in "grey border" mode which I have not yet tackled, so you will kinda have to imagine that the grey border is not there.

Anyway, my conclusion is that the filtered mode is too smooth and the nearest neighbor mode is too rough.  I think maybe if I increase the size of the source texture by a factor of 2 (or maybe more if necessary) that I should be able to use filtering and still see some pixel edges like on the original LDP-1450.  Stay tuned...

Worked on LDP-1450 text overlay some more

This morning I worked on the OpenGLESv2 side of things, writing code to make LDP-1450 text overlay run fast on the Raspberry Pi.  I am basically caching every character that can be displayed as a texture and then when I render it, each rendered character will be a rectangle with a portion of the texture applied.  It should be pretty fast.  If it's not... *ominous music*

Unfortunately, anything to do with GLES2 is quite difficult to get working right.  So this could take me a while.  I've been dreading it but I finally forced myself to do it so the train is moving.

Dexter status spreadsheet

For those wanting a larger overview of where Dexter is at, I made a spreadsheet showing what is finished and what is left to do.

You can find it here.

Added more commands to LDP-1450 code

This morning I added interpreters for most of the LDP-1450 text overlay commands, including unit tests.  The only one I haven't done yet is the command to actually change the contents of the text buffer.

Dexter update: Sony LDP-1000A probably won't make the cut

As you may have noticed, I have been exploring various video capturing technologies lately.  Part of the reason is to see if we can have more control over the video output signal than what the Raspberry Pi gives us.  Why?  Because of two reasons:
1) the Raspberry Pi does not let us control the VBI data that contains the frame numbers
2) the Raspberry Pi does not let us control when vsync occurs

Reason #1 is important because some players (PR-8210 and PR-8210A) are essentially output-only players and do not give the game any feedback as to whether they are functioning correctly.  In order to know whether the player is working, the game hardware needs to read the frame number from the VBI data.  So the fact that the Raspberry Pi does not let us control this VBI data was problematic.  However, I believe that we have discovered a way (and we will pursue it) to inject VBI data into the video signal in real-time (which is very cool).  So things are looking good for the PR-8210 games (Cliff Hanger, Goal to Go, MACH 3, and Us Vs Them off the top of my head).  Things are looking fairly good for Star Rider (PR-8210A) but it is still way too early to say with confidence that Dexter will definitely work with Star Rider.  But I am feeling good about the other four games at this point.

As for Reason #2, it turns out that the Data East games which use the Sony LDP-1000A (Bega's Battle, Cobra Command, Road Blaster) tell the laserdisc player when vertical sync occurs (unless I am very much mistaken) which is backward from how every other game works (the laserdisc player tells the game when vsync occurs).  I really am mystified how the laserdisc player can let an external source dictate when vsync occurs.  But regardless, this is something that I am quite sure the Raspberry Pi _cannot_ do (allow an external source to dictate vsync).  So the solution is for us to control the video signal more directly (ie through a DAC).  But at this point, I feel that going down this road would extend the release date of Dexter by a year at least, probably two to be realistic.  And I don't want to do that.  So I am hereby saying that as of now, Sony LDP-1000A support in Dexter v1.0 is out due to the constraints of the current design (ie using the Raspberry Pi).  I do eventually want to support this player, but I also want to ship a product!

That's the bad news.  The good news is that Sony LDP-1450 support is very much in and should be very good.  And the command protocol is almost the same between the 1450 and the 1000A.  So Dexter may still be able to be used with a Data East game but the game would require some hardware modifications (beyond my knowledge).

New SD card benchmarks

Well, before I go to a bunch more work only to find out that I can't succeed, I decided to try to do a sustained write to the SD card that would last about 10 seconds.  Therefore, I choose to write 300,000 512-byte blocks (about 146.5 MiB).


With a 12-bit 15 MHz Analog->Digital Converter, we will need to read in 180 million bits per second, or 21.46 MiB/second.  With two cards splitting the load, each of them would need to be able to write at 10.73 MiB/second.

From start to finish, it took 13.467 seconds, or 10.88 MiB/s which is too close to the minimum to be reliable.  Future runs were slower.  For example one was as bad as 14.59 seconds (10.04 MiB/s).  Another test yielded 14.06 seconds (10.42 MiB/s).

Without using the SD card's pre-erase feature (which I can only use for the first 4 gigs on the SD card for some strange reason), I am getting 15.06 seconds (9.72 MiB/s).

EDIT : with an optimization and no pre-erase I am now getting 14.2 seconds (10.3 MiB/s).

EDIT #2 : I just tried doubling the data written.  Now I am getting 9.83 MiB/s.

NOTE : It looks like the reason for these speeds is because I am using this kind of SD card.  I've found that bigger (physically) and smaller (capacity) cards can write faster.

Conclusion: Ok, so two SD cards are almost fast enough but not quite.  Incredible.  I was so close!  I'm so close now that I will probably just buy another SD card.  But dang.. 3 SD cards!  This project is broadening into gargantuan proportions.