Tuesday, February 13, 2018

Game Review: TIS-100

TIS is a new game by Zachtronics. tl:dr; Geek? Buy it.

Earlier, I had written about the lack of diversity in games. The world doesn't need another action adventure first person shooter. What it needs is creative games, games that make you evaluate, to think new thoughts. I loved a game that made you burn stuff, and a gem by Zachtronics called Space Chem. I have been interested in Zachtronics' catalog since SpaceChem. For background, SpaceChem was about splitting and combining atoms to make new molecules.

TIS-100 is about parallel programming. But that's as vacuous as saying Chess is about moving wooden pieces on a board. TIS is about writing good code, about making magic with very little, about learning how best to utilize a small instruction set.

It is about reliving 80s computing: complete with a ratty manual, an uncertainty about what to make. Walk away with an appreciation that you can do a lot. Learn the system, and you can bend it to your will.

You write assembly language programs for a computer that has multiple stream processors, where multi-processor communication is a one-cycle primitive, and you choose how to achieve the objective.

You don't need to know assembly, you don't need to know programming. You don't need knowledge of Chemistry for SpaceChem, you don't need to know programming for TIS-100.

But at the end of it, you appreciate programming and you learn how much fun programming can be.

TIS is an absolutely amazing game. A game that I will be recommending to many friends, and their young kids.

Here's a video showing the different processors (little square boxes). The highlights are on executing lines, and the left side shows inputs and expected outputs.

Video courtesy: me.

Friday, January 26, 2018

Matrix Voice: Hardware review

Many years ago, my Math professor and I chanced upon a 3D cube maze puzzle where a metal ball had to be extracted from the transparent maze.  We tried our best to solve it, but neither of us could.  So we did the next best thing: we proved that it was unsolvable...

I bought a Matrix Voice on IndieGogo last year. The tagline was, "Open-Source Voice Platform for all". It shipped eight months late, and does very little. Read on for cautionary tale on crowdfunded ideas where the promises surpass expectations. And promises that surpass a shipped product.

Matrix Voice looked enticing: a device that captured from multiple microphones and allowed you to process it on a Raspberry PI. Seven microphones, some expansion capability with GPIO, and a development platform built upon Raspberry Pi, Linux, and standard tools. Sounds promising, so I signed up, and put $115 for a Matrix Voice board, a Raspberry PI, and May 2017 availability.

March to May is a long time, I forgot all about it. I was waiting for it to ship, I would read the quickstart guide, and much like other single board computers, I would tinker with it and make a useful gadget.

Around July last year, as I was ordering other equipment, I vaguely remembered having funded a project on Indiegogo.  So I dug up the receipt, and went over to the project page to be greeted by irate users all expecting some shipping details.  May 2017 had come and gone, and delivery dates were moving to August, which had also past.

Projects get delayed. Software can still ship with a reduced feature-set and be improved upon, hardware projects can't. In addition, building hardware is difficult and messy. At this stage, I half-expected the project to be an elaborate scam. Looking through their pitch at IndieGogo, I was surprised I fell for it. The team list didn't include any people's names, and instead had lofty titles for the team, "Senior Advisor", "Country Manager Brazil", "Innovation Manager", and "Director of Operations". Everyone gets fooled, right?

So imagine my surprise when the board finally shipped! I got a notification that a package was headed my way, and I was eager to play with a real device. The quickstart guide, while slim, mentioned the URL https://voice.matrix.one/boards and https://matrix-io.github.io/matrix-documentation.

The first link redirects to this one (https://www.matrix.one/products/voice#compatibility) instead, and is surprisingly mum on code you can use. It points to a Documentation page which talks about MATRIX Core, Matrix OS, and Matrix HAL. No reference to Matrix Voice, or how it relates to these other words. Worse, they all talk about a product called Matrix Creator, which is a different board, with a different controller, different mic array and LED setup, and completely different sensors.  The most detailed information I could find was this Matrix Voice architecture page which has gray boxes connected trivially to an FPGA.

Voice Diagram

None of the Matrix Creator projects worked on Matrix Voice. The matrix-creator-hal demo programs on this question, for instance, gave SPI errors on the Matrix Voice. Neither the microphone nor the LEDs work on the Voice. My lofty ambitions had sunk so low that I was thrilled when the code compiled.

The only project I could find that uses the Matrix Voice is this Alexa demo project. It requires two packages: matrixio-malos (a binary file run as a service) and libmatrixio-creator-hal-dev (header files that don't refer to the binary or the service).  It refers to a github project: https://github.com/matrix-io/alexa-avs-sample-app.git. The Debian packages are interesting in how little they contain.

$ dpkg-deb -R matrixio-malos_raspbian-stretch-0.2.2_armhf.deb matrixio
$ find matrixio


$ dpkg-deb -R libmatrixio-creator-hal-dev_raspbian-jessie-0.1.4-main_armhf.deb creaor-hal-dev
$ find creaor-hal-dev


The payload is bolded.  Everything else is metadata or superfluous. The instructions ask you to reboot the machine after install malos: even though it is a single binary run as a service. You could just run /usr/bin/malos as root. Looking at the source, malos writes to FIFOs in /tmp/matrix_micarray_channel_* and those are expected to be set up as audio streams in Linux.  But you'd need to know a lot about Linux and audio to get past this information. Finally, this package might work with a Matrix Creator but does not work for Matrix Voice. Since all the samples for matrixio-creator-hal fail on the Matrix Voice, the malos binary gets SPI errors. Both malos and the demo program call matrix_hal::MicrophoneArray.Read(). Both get failures.

It's no surprise many backers are having trouble getting the Alexa demo working on Matrix Voice.  One backer even said that they were just guessing what code was used in the demo video.

Finally, the Alexa Sample Github repository has a lot of setup: it installs Node, VLC, Maven, WiringPi, OpenSSL.  But the only code that ever reads a microphone is the Java sample from AVS: samples/javaclient/src/main/java/com/amazon/alexa/avs/MicrophoneLineFactory.java which reads the default mixer and the default microphone. The microphone on the Raspberry PI. This will only work if you have set up Alsa to read from the pipe in /tmp, and if you have a Matrix Creator. If you have a Matrix Voice, you'll read from the default microphone on your Raspberry Pi. Nothing calls the MicrophoneArray code from libmatrix_creator_hal.a. (which isn't even in the installation instructions). I suspect you could go through the entire Alexa Sample Github code without needing the static library. Or the header files.

The github link and the Debian packages hide the fact that none of these packages are hooked together. And as mentioned earlier, creator-hal-dev is for the Matrix Creator, not the Matrix Voice. The demo programs from creator-hal-dev all fail on the Matrix Voice. Someone copy-pasted instructions from the Alexa Matrix Creator project instructions to the Alexa Matrix Voice project and didn't notice that the instructions are wrong.

If anyone wants a Matrix Voice, rummage through my electronic trash next week. It looks like a circular board, covered in shattered promises.

There are many wonderful crowd-sourced projects and ideas. Be cautious, be realistic. Above all, be patient. Game-changing ideas and products stick around for years.

Update (29 Jan): Matrix_Alfred posted a reply on the Matrix Community forum and disabled my account from posting feedback. They are eager to hear from their backers, apparently. This is my feedback for them which I had to create another account for.  See it online before they silence that account too.

Saturday, December 23, 2017

Laser cutting: Creating a phone stand

For the holiday season, I wanted to make my co-workers something useful.

Everyone has a cell-phone at work, and we are mobile developers.  To reduce desk clutter, I thought a phone stand might be perfect.  I had recently learned how to use a laser cutter, and looked around for a good project to grab from usual websites like thingiverse.  Despite looking online, I didn't find anything that suited my needs.

The goals:
  1. A simple material, hopefully sedate and elegant.
  2. Fewer pieces was better.  I wanted to make more than 30 holders, and simplicity would allow me to make many of them.
  3. Ability to fit a wide variety of phones.
  4. Tablets would be a plus, but not required.
I had cut some wood in an Epilog cutter before, so I decided to continue using 0.125 inch plywood.

Step 1: Prototype

This was my first experience designing a physical object.  Being a true engineer, I grabbed a pencil, a pen-knife and some cardboard from discarded packaging.  I started with a simple design with two pieces: one for the face plate, and one for the bottom.  The bottom would poke through the face plate and hopefully lock in.

I worked with various widths and lengths, to see what would hold a phone comfortably.  The first cut was made from a cardboard case, and was too short, and the base wouldn't lock tight because I made the base too curved and the cardboard was too weak.

Calculating the weight of a usual phone (adding 30% for future growth), the inclination, and the rough springiness from wood, my son and I worked out the lengths of the various segments.

With some iterations, I arrived at two perfect rectangles: the face plate was taller, the base had long prongs that would stick out.  On one cardboard prototype, we were able to hold a real phone without flopping.  This is the first prototype holding up a phone.

That night, I drew one face plate and one base on Inkscape, learning about Inkscape as I went. To personalize them, I added a co-worker's name to be etched (marked in red) while lines in black were to be cut.

Finally, 12 x 24 inches plywood at 1/8 inch thickness was bought.

Step 2: Test on Paperboard

To confirm the measurements, the first draft was loaded up on the laser cutter with some quarter inch paper board.  I added inch markings along the side to diagnose any deviations in the cut.  This is the desk area as I was waiting for the cut to finish.

To my utter shock, the first cut on cardboard was absolutely perfect. It measured exactly to spec, the two pieces locked together, and it held up my phone.

Step 3: Test on Wood

With the success of the paperboard run, I decided to calibrate the laser cutter for engraving and make a single test run on wood to see how well it held up.

I loaded up my wood, and sent the same .svg file, this time calculating laser intensity for wood instead.  The power on the first run was too weak, so I just repeated the run without moving the wood. It led to a working model, this time in wood!  The face plate is to the left and the bottom plate is to the right. Notice the inch markings along the left edge, still visible.

This is what it looks like with a phone on it.

Making a single phone holder is easy, and takes forty minutes to print the face plate, then readjust origin, print the base plate, and ensure the cut is good.  Making many copies without mistakes would be time consuming.  I did not want to manually adjust the origin, and find where the start from.  I would have to automate it to make all the holders in time for Christmas.

Step 4: Production!

Over the next few days, I used the wooden prototype, and learned:
  1. The prongs were too short, which led to the phone sliding off. This was bad.  The prongs needed to be longer.  To allow for a phone charger cable, gaps were cut at the bottom of the face plate and the bottom plate.
  2. To minimize wastage and manual effort, I had to fit 30 face plates and 30 bottom plates on as few sheets of plywood as possible. Eventually, I ended up fitting the face plates together on one run, while bottom plates would go in another svg file.
  3. After completing #2, I realized the laser cutter might not cut perfectly near the edges of the wood, and all wood warps over time. In addition, I might not set the origin perfectly, and the board might be smaller if it was at the edge. So all sizes were reduced by a small amount to leave a thin border of wood as a precaution for these issues.
  4. A friend came over and suggested that usernames worked better than first names for our office.  All first names were changed to usernames.  This was a great idea since there are people with the same name.
  5. Since I had increased the prong size in #1 and reduced the overall board in #3, we'd have to create another PVT to confirm before a final production run.
  6. The inch markers were left in the final run, adding a minimalist elegance to the design.
  7. I had just enough wood to make all holders, but no spare planks if I messed up.
  8. Kids fell ill, leading to production delays.

With all these lessons, three new Scalable Vector Graphics (.svg) files were created: two containing 15 faceplates each in a 3 x 5 grid. Since these had names for engraving, they had to be different files. The font sizes were reduced for longer usernames to make them fit on a line.   The inch markers and names are in red for engraving (less time at 100% intensity).  The black lines are for cutting through (more time at 100% intensity).

The bottom plates were not personalized so a single sheet with 21 bottom plates (3 x 7 grid) was made.  Ordering spare wood would have been wise, but I aimed for perfection instead.

Finally, I went over to the laser cutter with wood, .svg files, paperboard, pen-knife and tools.  After confirming that the new measurements with longer prongs and overall reduced size still held up a phone, I loaded up a full sheet of 12 x 24 inches plywood at 1/8 inch thickness.

Engraving all the names and inch markings took the most time: 40 minutes for each face plate sheet.  Here's the engraving, in progress.  The sound is the ventilator at full-throttle.  The laser cutter itself is relatively quiet.  You can see how painfully slow the progress is.  There are three other names that you don't see, which is why the arm is swinging far out of these two usernames

Cutting took 10 minutes, and just to ensure a precise cut, I ran the job again with just the cutting again.  Even so, some sheets were warped around the sides and some plates were loosely attached and had to be scored with a pen-knife to separate.

Here's a video of the cutting in progress.  You can see the inch markings along the left wall as the cut lines up perfectly against them.

The bottom plates were faster, having no engraving.  Here's the start of the bottom plate run.  You can see the narrow border left, which was to allow for some error while setting the origin of the run.

My co-workers got a personalized phone holder each, and I still had wood left over.  There was one hilarious mistake where a username were incorrectly spelled, and another where a natural knot in plywood marred the username.  These face plates were cut again, individually.

With that, production was complete.  The delight was not just in having a personalized gift for everyone, but the satisfaction of a job well done.

Images: courtesy me.

Saturday, February 18, 2017

Learning Blender

I have been learning Blender the last few weeks. Here is the video I made today.  There are four glass spheres moving with a wooden cube in the back.  It took about two hours to render on my Linux computer.  Each frame takes about two seconds to render, and there are 1800 frames.  The video has 24 frames a second.

Blender is a 3D modeling software that is freely available on Mac, Windows, and Linux.

Monday, December 12, 2016

KernelOops on Nvidia 367 with dual monitor setup

My home Linux display setup is complicated.  The Linux desktop has two monitors, and one of the monitors is connected to the desktop via a KVM switch.  The KVM is also connected to a non-Linux desktop.  I use a Nvidia GTX950 card on the Linux machine, which needs proprietary Nvidia drivers to run. In the last few weeks, I started getting Kerneloops when suspending the Linux machine.  The problem seemed to be the nvidia modules of the kernel.  I didn't have kernel oops earlier, so I started to track down the cause.

I finally found the issue was nvidia not being able to modeset correctly.  My previous Xorg config forced a specific screen layout.  The new Nvidia binary driver undid this, and that is roughly when the suspend problems started happening.

I have two screens: DFP-0, and DFP-4.  You can see your own list of screens by looking at the file /var/log/Xorg.0.log.  The relevant lines that show you which screens are connected is here:

[  6615.937] (--) NVIDIA(0): Ancor Communications Inc ASUS VS247 (DFP-0): connected
[  6615.937] (--) NVIDIA(0): Ancor Communications Inc ASUS VS247 (DFP-0): Internal TMDS
[  6615.937] (--) NVIDIA(0): Ancor Communications Inc ASUS VS247 (DFP-0): 330.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-1: disconnected
[  6615.937] (--) NVIDIA(0): DFP-1: Internal TMDS
[  6615.937] (--) NVIDIA(0): DFP-1: 330.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-2: disconnected
[  6615.937] (--) NVIDIA(0): DFP-2: Internal DisplayPort
[  6615.937] (--) NVIDIA(0): DFP-2: 960.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-3: disconnected
[  6615.937] (--) NVIDIA(0): DFP-3: Internal TMDS
[  6615.937] (--) NVIDIA(0): DFP-3: 330.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): Acer K272HUL (DFP-4): connected
[  6615.937] (--) NVIDIA(0): Acer K272HUL (DFP-4): Internal DisplayPort
[  6615.937] (--) NVIDIA(0): Acer K272HUL (DFP-4): 960.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-5: disconnected
[  6615.937] (--) NVIDIA(0): DFP-5: Internal TMDS
[  6615.937] (--) NVIDIA(0): DFP-5: 330.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-6: disconnected
[  6615.937] (--) NVIDIA(0): DFP-6: Internal DisplayPort
[  6615.937] (--) NVIDIA(0): DFP-6: 960.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.938] (--) NVIDIA(0): DFP-7: disconnected
[  6615.938] (--) NVIDIA(0): DFP-7: Internal TMDS
[  6615.938] (--) NVIDIA(0): DFP-7: 330.0 MHz maximum pixel clock
[  6615.938] (--) NVIDIA(0): 

In the above example, you can see that DFP-0 and DFP-4 are connected to the graphics device while the others are disconnected.

In my case, the graphics card was trying to determine which screens were still connected.  This is the incorrect behavior when I switch to the non-Linux computer through my KVM switch.  My Linux desktop resizes and all windows move to the screen that is still connected to the desktop.

To force X to force both screens to stay connected, you can use the magic 'ConnectedMonitor' option.  This goes in the Screen section.  It is confusing since the screens that you refer to in the Connected Monitor line are DFP entries that you get from Xorg, while the metamode lines refer to screens in the same terminology as the output from xrandr.  DVI-I-1 is the first DVI device, while DP-2 is the second DisplayPort device.   I suspect DFP means Digital Flat Panel, to distinguish it from Cathode Ray Tube (CRT) and Liquid Crystal Display (LCD).

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "metamodes" "DVI-I-1: nvidia-auto-select +2560+0 {rotation=left}, DP-2: nvidia-auto-select +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    Option         "ConnectedMonitor"   "DFP-0,DFP-4"
    SubSection     "Display"
        Depth       24

Using the example above you can force DFP-0 and DFP-4 as connected devices. Once you add the line in red, you need to restart X, and then the Nvidia driver will not reallocate the desktop when a screen is disconnected from the display (when the KVM switches).  As a happy side-effect, the Kerneloops while suspending are gone as well.

Monday, September 26, 2016

Space Chem: A brilliant game about Chemistry and Parallel computing

If you like programming, you might want to play SpaceChem, a delightful game.

The world doesn't need another platformer, another action RPG, or another First Person Shooter.  These genres have been explored beyond the point of creativity.  I played a game recently that blew my mind: it was a puzzle game that allowed you to write code to create molecules.  If you are left scratching your head, it is because the game truly is a mind-bender.

Spacechem bills itself as a puzzle game about chemical synthesis, but it is really about programming.  You build reactors using blocks which follow simple programming rules.  You can control two devices called Waldos (one Red, one Blue) that run the commands, and allow you to combine or uncombine molecules into elements.  Elements follow their true chemical properties: Oxygen can make two bonds, Hydrogen can only make a single bond.

The game board is limited, and the input and output areas are clearly delineated.  This constrains your programs, as objects cannot overlap on the game board.  And only one instruction can be placed for a single waldo: you cannot have two red instructions in a square.

Since there are two Waldos, sometimes you need to synchronize them to accomplish a task.  This forces you to reckon with parallel programming concepts.  Accomplishing the task is sufficient to advance to the next level, though you are given a graph of time and complexity (reactors used, and symbols used).  These correspond to time spent and space complexity of parallel programs.  To accomplish the goal quickly or with a small complexity, you quickly learn to keep your waldos busy as much as possible, and synchronize little.  This corresponds to high CPU utilization and reduced global barriers in parallel computing.

All put together, this is one of the most innovative games I have played.  There is a story-line which, while innovative,  pales compared to the beauty and elegance of the game.  The combination of Chemistry and Computing and puzzle solving is truly unmatched.

SpaceChem stands out as a wonderful example of gaming both as a creative art form, and a splendid way to motivate and teach programming.

Here is a program I made which creates Titanium Dioxide and Zinc Oxide from Oxygen, Zinc and Titanium.