# Save DVD recorder data

Recently I extracted video data from a broken JVC DR-MH300 DVD recorder.

The device’s power circuitry has broken down, but there was still interest in the contents of its hard drive. Since I couldn’t find any confirmation on the Internet that data recovery was possible, I thought this post would make a good encouragement for others facing the same problem. To attempt this, you need to be moderately comfortable with opening up electrical appliances, and you should also be reasonable Linux savvy for the recovery itself.

This is what I did:

1. Unplug the device (obviously).
2. Open the device, by taking out the screws on the side and back.
3. Unscrew the hard drive, and take out the connector. In the image below, it is already dismounted/disconnected (and hence not aligned with the rest of the device :)).
4. The DVD recorder’s hard drive has an PATA connection, so you either have to find a PATA harddrive dock, or an old computer to plug it in. I went for the second option.
5. I created a live usb disk with a version of Ubuntu, booted it up, and tried to mount the hard drive. This didn’t really work, since it uses a filesystem that I could not identify.
6. Instead, I made a copy of the disk on a separate drive using the dd command. Unfortunately I lost the exact command line, but it must have been something similar to this:

7. You can now get rid of the dock / old PC, and work from the image file, which is much more convenient. Looking at the first few kilobytes on the image, it turns out that the DVD recorder is running some version of the VxWorks OS, since the first bytes contain strings related to it. This also showed that the data is at least readable from a PC platform, so recovery is possible.

8. Download PhotoRec, and scan the disk image. I left it running overnight, since it takes a while to process the entire drive. This recovered the relevant MPG files on the disk. Note that you will also recover (parts of) the MPGs that have been deleted, which leads to some interesting playback issues on those files. However, the majority of the recovered MPGs worked properly.

# Keep Talking and Nobody Explodes meets hue

Keep Talking and Nobody Explodes (Ktane) is a great game about defusing bombs, communication and accuracy in a stressful environment. I recently received a set of hue lamps from my friends, with the subtle hint that some kind of integration with Ktane was expected next time we play it. Challenge accepted?

It turns out that the hue lights have an easy to use interface; they (or more precisely, the bridge) accept http get and post requests which you can use to receive status info or update settings, respectively. Applying “rule 43”, I decided to google for ktane hue, and found this reddit post, describing the efforts of another Ktane player to control hue lights based on the game. The effect he created looks quite nice, but unfortunately, the source code is not available, so I attempted to spin my own version. My current prototype is available on github.

The log file in <your_ktane_folder>/logs/ktane.log contains quite a lot of debug data, which can be used to derive the current game state. Here’s a few useful snippets:

The first line indicates the start of the countdown timer, the others are self explanatory I think.

I selected the Python phue library to control my lights. It seemed like a nice enough API, and is written in Python 3, which just happened to be the Python version I installed on my windows Ktane machine:

My log-file parser is not very majestic: it reads the entire log file approximately every 0.1 seconds, and parses the thing based on some string /regex matching. If the timestamp of a log message is sufficiently new (less than 0.3 seconds old), then it is interpreted by the class that keeps track of the game state. This works, assuming the game and the python script use the same clock, which they typically do if they run on the same machine. I had to correct for the local timezone I am in (the game writes UTC stamps), but besides that, it worked as expected. The relatively high sample rate (10 ticks / second) makes the delay between quick events, like the bomb exploding and the associated light effect, unnoticeable.

I later found there are github projects dedicated to parsing Ktane logs, so I could have used one of those. However, for this project, the quick and dirty method is sufficient.

Using the log, I keep track of these events:

• Being in the menu / bomb selection screen results in neutral lighting
• When the bomb defusal part of the game starts, the lights alternate between two shades of orange
• On a strike, the pulse rate increases
• When the bomb explodes, the lights go bright red, yellow, and then red with a very low brightness.

Here’s a little demo video showing these phases:

There is room for improvement: I want to use the OneMinuteLeft entry to change the pulse colors to shades of red, and improve robustness of the state tracker, such that it can pick up on a game that is already running. Also, backing up the settings of the lights and restoring them when the script exits might be useful. A small (persistent) settings file that keeps track of the lamps to control and the bridge’s ip could reduce the hardcoding, and make it easier to use. Overall, code quality could be better (I’ve “only” invested about 2.5 hours of development time so far). I’ll update the git repo as I make changes.

# A little conjecture

One of my propositions in my thesis is:

February 2015 was the last month in which the world’s combined SDRAM production could have been used to cache all the traffic flowing into the Amsterdam Internet Exchange.

The underlying idea is that, if all DRAM vendors would team up (and were really committed to the idea), they could produce DRAM chips to store “The internet” at about the same rate as it is flowing into the AMS-IX. February is special, in the sense that the bandwidth of the DRAM producers is extremely close to the AMS-IX bandwidth (they are only 0.15 % apart).

DRAMeXchange reports 2402 million 2 GiB units were produced, for a total capacity of 5.16 exabits. The DRAM production bandwidth can be calculated from that number:

$$\frac{2402 \cdot 10^6 \cdot 2\cdot 2^{30} / 8~\text{bytes}}{2.419 \cdot 10^6\text{seconds in February}} = 267~GB/s$$

So far, it still holds up, as you can see here:

AMS-IX traffic has grown explosively over the past years, and can apparently scale up easily. It hence seems extremely likely to me that DRAM production, which is bound more physical factors, will not be able to overtake it anymore.

Source data:
ams-ix.net DRAMeXchange

# The thesis is real!

Four years and a few months of hard work condensed into 213 pages, and this is what it looks like:
128 copies (a nice round number) of my thesis A Reconfigurable Mixed-Time-Criticality Memory Controller’ are ready to be distributed to everyone who is interested.

# pypatterngen - The python-based SDRAM patterns generator

My Ph.D. thesis is about real-time memory controllers, and more specifically, pattern-based memory controllers. Such controllers need to be programmed with memory patterns, which are sequences of SDRAM commands that are executed by the controller when it needs to read from or write to the memory. You can read about how these patterns are used in this article on ieeexplore. The SDRAM controller in the CompSOC platform executes these memory patterns, enabling us to give (real-time) guarantees on worst-case bandwidth and worst-case response time.

Patterns are statically computed at design time, and since this is quite a tedious process to do manually, we automated it with a publicly available tool, which you can find on the gitlab page of our group. This post describes the pypatterngen tool that creates SDRAM command schedules for DDR2/3/4 and LPDDR1/2/3 that satisfy the SDRAM timing constraints.

# Mini example-based VHDL tutorial

This post tries to introduce the basic vhdl syntax by means of examples. Written about a year ago, its original purpose was to serve as a guide for students that started developing hardware for the CompSOC platform, but I think this info is generally useful for the world. I left most of the CompSOC specific bits in the tutorial for the sake of completion (the occasional CompSOC: label marks them). There is also a section on DTL, which may be interesting for academic readers who wonder how the sentence DTL, which is similar to AXI‘, which I wrote in my thesis and some papers, actually holds up.

I wrote the guide with Xilinx tools in mind (version 14.7). It gradually introduces new language constructs. Although far from complete, you should be able to find most frequently used snippets in here.