Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Iv been looking online everywhere but cannot figure out what this could be. It looks similar to ASCII but only with 2 digits in most parts instead of of one. This was the only place i thought may know what it is or could be.
(i added the spacing my self not sure if it should be here or not )
54 56 32 55 52 32 55 52 32 55 48 32 51 97 32 50 102 32 50 102 32 54 57 32 54 100
32 54 55 32 55 53 32 55 50 32 50 101 32 54 51 32 54 102 32 54 100 32 50 102 32 52
54 32 53 57 32 51 57 32 52 52 32 52 100 32 52 102 32 51 53
They are ASCII, using decimal code points, where 54 is '6', 56 is '8' and so on. Decoding that gives you:
68 74 74 70 3a 2f 2f 69 6d 67 75 72 2e 63 6f 6d 2f 46 57 37 44 4d 4f 35
But that again looks like valid ASCII code points (in hex this time) so decoding them gives you:
http://imgur.com/FY9DMO5
which leads to this image:
Now, if you look really closely at the black bit under the white square, you'll see some dots reminiscent of braille. And, in fact, the letters spelled out seem to be:
bitdotdoslashwehunger
If you enter that into a browser as bit.do/wehunger, you end up with yet another image:
As to what that is, my detective skills have reached the limit of my ability to care. Since the first image was called Day J, and this last one is called Day K, I suspect it's a puzzle of some sort and you should probably continue on your own.
In any case, if it's a job interview puzzle process and it's for the same big trendy company I'm currently interviewing for, I don't want to make it too easy for you :-)
I'll probably carry on following the trail just because I like puzzles, but I won't be publishing the results. Good luck in your hunt.
Related
I’m trying to compute all permutations of 12 or 13 specific values (e.g., x = [73 78 84 82 79 68 85 67 84 73 79 78]), but I’m running into memory errors in Matlab (12 = 46.0 GB and 13 = 647.6 GB of memory).
Is there an easy way to select a random subset of, say, 4 million of these permutations?
For my assembler, I want to encode the operation mov eax, [addr]. In 64 bits this would only possible using a SIB byte, as the mod r/m combination 00 101 was changed to indicate rip-relative addressing. The problem I find is that, in 32 bits, encoding this instruction using a SIB byte doesn't work. For example I have:
8B 84 25 1C FE 43 00
(mov) (10 000 100) (00 100 101) (address)
but disassemblers don't seem to accept it, I get:
mov eax,DWORD PTR [ebp+eiz*1+0x43fe1c] (defuse.ca)
mov eax, ss:off_43FE1C[ebp] (ida)
and when the instruction is executed it generates an exception. I know that there is the shorter encoding in 32 bits, but don't understand what's wrong with the longer one.
I have those 3 Events in a Midi file:
00 FF 51 03 0E 15 C3 86 A6
20 FF 51 03 15 20 A5 83
5C FF 51 03 0E 15 C3
But what is, in this case, important is, that FF 51 stands for a Tempo Change and the 03 for the number of following Byte-Pairs describing the tempo. As it is "3 Byte Pairs" in Each Event Why are there 5 Byte Pairs describing the first Event, 4 describing the second, and 3 describing the third? (I hope the image helps)
How does the encoding program know, when a new Event starts? The File can be played without any Problems.
All three events have three data bytes.
The delta times between the events are encoded as variable-length quantities, so you have to continue to read bytes until the most significant bit is clear. The three times before each event are 00, 86 A6 20, and 83 5C, resulting in the decoded delta times of 0, 109344, and 476.
I am having a problem with the I2C driver for a Freescale p1022tw board. There is a command on U-Boot's console to read from an I2C device:
i2c md chip address[.0, .1, .2] [# of objects]
When I read 4 bytes from a device with id 0x60, at address 0x0, I get:
tw=>i2c md 60 0 4
0000: 45 45 45 45 EEEE
These values that it returned are wrong. I can get the right values if I read one byte at the time:
tw=>i2c md 60 0 1
0000: 45 E
tw=>i2c md 60 1 1
0001: 45 E
tw=>i2c md 60 2 1
0002: 46 F
tw=>i2c md 60 3 1
0003: 00 .
I should have gotten 45 45 46 00 or EEF0 in the first command. In multiple readings for this device, it is returning always just the first byte value. If I try to get 6 bytes starting at address 0x2, this is the output:
tw=>i2c md 60 2 6
0002: 46 46 46 46 46 46 FFFFFF
This problem does not happen on other devices on the bus. For instance, in the device with id 0x4F, the right values are printed:
tw=>i2c md 4F 0.2 6
0000: 18 00 f6 48 00 00 ...H..
The address in the previous command has a ".2" because the chip uses 2 bytes for addresses. The first device only uses 1, so there's no need to put a ".1" (I already tested that).
I went through the implementation of the Freescale driver for the I2C communication, but I didn't change anything on it and it works for other devices. My coworker also says that the very same code works on his board. Have anybody had a similar issue or has any theory about why this is happening?
Thanks in advance.
I met such a situation. I had driver, read and write functions, and it worked not for all i2c devices. I found that was caused the not working device had different operating format for a number of operation. Unfortunately this happens, there a kind of not standard protocols. When you open the doc for the problem device and compare it to working and/or to the driver implementation you most likely will see a difference.
In his famous blog post The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) Joel said :
The earliest idea for Unicode encoding, which led to the myth about
the two bytes, was, hey, let's just store those numbers in two bytes
each. So Hello becomes
00 48 00 65 00 6C 00 6C 00 6F
Right? Not so fast! Couldn't it also be:
48 00 65 00 6C 00 6C 00 6F 00 ?
The second representation is faster ? why ?
How does swapping the high and low bytes affect performance ?
The sentence "Not so fast!" isn't about computing performance but a way to say "hey, don't make assumptions so fast, here's another way to look at it".
The question is Mu.