So I had found the C# DLL’s that seemed to generate VM byte code. At this point I had grown weary of digging around in LabVIEW and attacked the problem from another angle.
I took a look at the EV3 Brick. I connected it to my computer and started the LabVIEW Brick Memory Browser. With that browser I found out that I can fetch files from the Brick, so I tried to fetch a program. It worked, and I was able to download a program file that executes on the Brick.
The program in question was a simple Play->Start Medium Motor->End, and it had resulted in a file weighing in at 334 bytes of VM byte code, with the file extension .rbf. Without knowing anything about the file format I opened up the file in my favorite hex viewer and quickly found that the first 4 bytes was always the int 0x4C45474F, which spells out ‘LEGO’, and the next 4 bytes, when read as a little endian 32 bit integer, always contained the size of the file. After that started the confusion.
I created a bunch of permutations of the same program, downloaded the compiled VM byte code to my computer, compared the different permutations and found a bunch of similarities and also a lot of differences. I tried different blocks (medium motor, large motor) and I tried the same block with different parameters (loop X times, wait X seconds, different values of X). Changing values of X yielded the value of X as the only diff in the binary files, as expected, but changing between medium and large motor yielded a massive change in the byte code, which I hadn’t quite expected.
So now I had a massive (relatively speaking) binary of VM byte code, and I had the C# class that would generate this byte code. All I had to do now was to use the LabVIEW C# class to generate VM byte code from Unity and see if would boot on the Brick!