Being a complete fanny, I managed to drop my phone and break the display assembly again.
I was in the pub the next day with a friend recounting my tale of woe, and as he was showing off his shiny new phone to me, it suddenly occurred to me that we used to have the same phone. I ended up buying his old phone off him for parts, and repaired my phone there and then.
Annoyingly, in doing so I managed to snap my SD card!
I bought a new 64GB SD card on ebay and when it arrived I decided to do a check of its integrity:
$ dd if=/dev/urandom bs=1M count=64000|pv|sudo tee /dev/mmcblk0|sha1sum -
Already things were seeming suspicious: It claimed to be a class 10 card (10MB/s) but it initially wrote (at least for the first few GB when I was paying attention) at about 2-2.5MB/s.
When I came back later, it was ~45GB in and had sped up to about 15MB/s.
I had planned to read it back and check that the data were the same:
$ sudo pv /dev/mmcblk0 | sha1sum -
But it read at about 10MB/s (rather than the advertised 50MB/s) so I lost interest and tried a different approach, writing to random locations and reading back. 54MiB in was fine, but 54722MiB in returned garbage.
I threw together a quick script to check random 1MiB blocks throughout the disk:
#!/bin/bash dd if=/dev/urandom bs=1M count=1 of=somerandom for i in $(seq 1 1000) do thisblock=$(shuf -i 0-63999 -n 1) sudo dd if=somerandom of=/dev/mmcblk0 bs=1M seek=$thisblock sudo sync sudo dd if=/dev/mmcblk0 skip=$thisblock bs=1M count=1 | diff - somerandom if [ $? == 1 ] then echo "bad" echo $thisblock >> badblocks else echo "good" echo $thisblock >> goodblocks fi done
(I don’t know if the sync is necessary – I wasn’t sure if maybe there’d be some transparent caching in play whereby the OS would assume what it’s just written is still there.)
This gave me two lists, one of the known good blocks and one of the known bad blocks. About 3/4 of the blocks were bad, so it was looking like this 64GB was a 16GB in disguise:
$ wc -l goodblocks badblocks 240 goodblocks 760 badblocks 1000 total
I threw together a piece of octave too, to make a visualisation:
goodblocks=dlmread("goodblocks");
badblocks=dlmread("badblocks");
image=zeros(320,200);
for i=goodblocks'
x=floor(i/200)+1;
y=(mod(i,200))+1;
image(x,y)=1;
end
for i=badblocks'
x=floor(i/200)+1;
y=(mod(i,200))+1;
image(x,y)=2;
end
colourmap=[0 0 0; 0 1 0; 1 0 0];
imshow(image+1,colourmap);
imwrite(image+1,colourmap,"image.png")
The result:
Each pixel represents a 1MiB block of the SD card, top left being the start, working right then down, with the bottom right being 64GB (more accurately 64kMiB, or 64000MiB). Black pixels are unknown (the script took a random sample of 1000 blocks out of 64k), green are good (read back the same) and red are bad. This looks pretty conclusively like it’s a 16GB card in disguise.
The bad section seems to be the same 512 byte pattern repeated over and over for a bit, then the repeated pattern changes sometimes for no discernible reason. I haven’t invested much energy into figuring out why yet.
and 
. These are both encrypted with the same key, say 
for example. This means we have two ciphertexts 
and 
is the same. As air travels through one of the bottles, it will indeed have to speed up as it enters the mouth, because of conservation of mass and therefore volume (subsonic air flow is essentially incompressible). By Bernoulli, this causes pressure to decrease and therefore, according to the ideal gas law, the temperature to change slightly.
bits. That means that there are around 
possibilities to brute force. At a million guesses per second, it would take in the order of a billion years to check every possibility.
, which is simply the entropy of the gaussian distribution and has an 
matrix is diagonal), this becomes:
on the other hand is a nastier affair – it’s the entropy of the noisy signal, or that of a sum of gaussians, 
. This has no closed form so instead the approach I took was to sample 
over a grid, and then sum across it for 
:
is calculated and the average is taken. Since the process is ergodic, this tends to the expectation, 
. To do this we need to calculate the real and imaginary parts of 
, then add these to the real and imaginary parts of c.
, which as I showed previously is 
. We copy 
into CX, since we’ll need it again later and we don’t want to clobber it. Then we multiply this by SI (
) and store the result in CX. The value in this register should now be 
(note what I said about fixed-point multiplication earlier). Ignoring the conditional jump for now, we would then want to divide by 128 to get 
. Except what we want is actually 
being greater than 32768/128 in magnitude (the signed 16-bit max, after scaling). That is, 
. As noted previously, this is given by 
. Earlier versions of my code calculated exactly this – multiplying each part by itself, then subtracting one from the other. Then I realised I was missing a trick here – I could factorise 
, thus gaining an ADD (+2 bytes), but losing an IMUL (-3 bytes). A saving of 1 byte – score!
with the add bx,bp, we no longer need 
, ie 
. Over the range of |Re(c)|<2 - exactly the space we're working in - this completely contains the r=2 circle. In fact, at the far left and right edges of the canvas, they just touch. An illustration is shown to the right: including the [latex]abs(z^2)<2[/latex] criterion in grey and the rectangular criterion we're using here in blue. The rectangle moves around relative to the axes depending on the point being calculated.
This block: 14 bytes, So far: 41 bytes
[code];calculate z'=z^2+c
add si,di
add cx,dx
mov bp,cx
;do another iteration
inc ah
jno iterate[/code]
Here are the final steps to calculate [latex]z_{n+1}[/latex]. We then increment the iteration counter, AH, and unless it overflows (passes 255), we go round again. Whee! 255 iterations is thoroughly excessive, but it allows us to just check overflow, rather than doing a CMP with an immediate value, which would cost 3 bytes.
This block: 10 bytes, So far: 51 bytes
[code];iterations are over
inc al ; if we've gotten all this way, set the colour to white
overflow:[/code]
If we get here just by the natural progression of the program, that will be because we went through 255 iterations without overflowing. Therefore the pixel is in the set, so we set it to white - a value of 1. Since I know its value before is zero, I can use an INC (2 bytes) instead of a MOV immediate (3 bytes).
If we get here via one of the jump on overflows, we skip out of this instruction and the pixel remains black.
This block: 2 bytes, So far: 53 bytes
[code];now write a pixel
mov ah,0ch ; write pixel interrupt
xor bh,bh
mov cx,di
add cx,320
add dx,175
int 10h
sub dx,175[/code]
Here we use another INT 10h interrupt to write the pixel to the screen. We set AH=0Ch for the "write a pixel" command, set BH=0 for page zero (using XOR- no size advantage over MOV immediate here, but faster), and stick the coordinates in CX and DX (in fact, I chose to use DX to store the y coordinate anyway, to save a MOV instruction here). Since our coordinate system was centred around zero, we add 320 and 175 to the x and y coordinates respectively, to centre the image on the screen. After the interrupt, we have to take the 175 back off DX, since it serves as our loop counter so we can't clobber it.
All of these ADD and SUB immediates are VERY expensive instructions - each one takes 4 bytes. I haven't thought of a way to optimise this though.
This block: 20 bytes, So far: 73 bytes
[code];loop around, do the next pixel
inc di
cmp di,255
jne xloop
;or if we've gotten to here, draw the next row
inc dx
cmp dx,127
jne yloop[/code]
And some loop logic. We go onto the next pixel in the line (inc DI), and loop around unless the pixel value's 255 (end of the line). This CMP literal is expensive (4 bytes) but not easily avoided - since it's a signed type (and we're only using the lower 9 bits anyway), we can't just test for overflow. Outside of this, we have the same structure to loop through lines.
This block: 13 bytes, So far: 86 bytes
[code]cli
hlt
db $-$$ ;tell us the length of the code
times 510 - ($ - $$) db 0
dw 0xAA55[/code]
And finally a little bit of boilerplate: clear BIOS interrupts and halt. The db $-$$ line is a little hack to make it easier to see the size of the program - it just inserts a byte of value (this memory location-memory location of program start). Then I just look at the code in xxd and the last byte before the long run of zeros is the size of the program.
It needs to be padded up to 512 bytes (the size of a boot sector), with the magic word AA55h at the end to indicate that it's bootable.
And so that's a final 2 bytes of executable code (I'm not counting the padding, of course), bringing us up to 88 bytes!
The complete code is here: 
