 |
Author |
Topic: more bit visualization (Read 2407 times) |
|
rgovostes
|
more bit visualization
« on: Oct 19th, 2004, 12:16am » |
|
Earlier, I posted code which displayed the output of a function in binary - it wasn't very exciting. Today, I have written a program which rapidly scrolls through a file, "input.dat", located in the sketch's data folder, and displays it as a 1-bit 512x384 image.
It gives me quite a headache, eh. But here it is:
Code:byte b[];
float offset = 0.0;
void setup() {
size(512, 392);
b = loadBytes("input.dat");
}
void loop() {
render();
offset ++;
}
void render() {
int i, x;
byte p[] = new byte[24576];
System.arraycopy(b, (int)offset, p, 0, 24576);
/*for(i = 0; i < 196608; i ++) {
x = p[i / 8] & 0xff;
pixels[i] = (~x >> (7 - (i % 8)) & 1) * 0xffffffff;
}*/
for(i = 0; i < 196608; i ++)
pixels[i] = (~(p[i / 8] & 0xff) >> (7 - (i % 8)) & 1) * 0xffffff;
fill(0xffcccccc); stroke(0xffcccccc);
rect(0, 384, 511, 7);
fill(0xffffffff); stroke(0xff000000);
rect((offset / b.length) * 508, 384, 7, 7);
} |
|
I'm fairly proud of the (commented) for() loop which "renders" the image, since it works extremely quickly (around 50 milliseconds on my machine) - I reduced this to one line because of the performance boost (20 milliseconds). I get about 10 FPS, which seems to be the maximum (same on my 400 MHz machine as my 2 GHz one).
By the way, there is probably an exception when it reaches the end of the file, since System.arraycopy() doesn't like it when you're asking it to copy more than exists. I'll fix that eventually, but it takes so long to reach the end it probably isn't necessary 
And, uh, it doesn't increment by 1 bit, but 8. I didn't realize this would happen earlier, which was kind of foolish... it could be updated if need be. Also, instead of incrementing by 1, I guess you could by 24576, and slow it down a bit.
Hmm hmm hmm.
|
| « Last Edit: Oct 19th, 2004, 12:34am by rgovostes » |
|
|
|
|
jrc313
 
|
Re: more bit visualization
« Reply #1 on: Oct 19th, 2004, 12:44am » |
|
I like that. It's a bit like listening to C64 tapes 
Not that I ever did that you realise ..... ahem.
|
|
|
|
|
rgovostes
|
Re: more bit visualization
« Reply #2 on: Oct 19th, 2004, 1:18am » |
|
I've been using it trying to locate 4 hidden images in the Mac SE ROM ... I think I've located them, but they're very distorted - I'll have to try to extract them as best as possible ...
For more effects, you can display the data as RGB:
Code:byte p[] = new byte[196608];
System.arraycopy(b, (int)offset, p, 0, 196608);
for(i = 0; i < 196608; i += 3) {
pixels[i] = color(p[i] & 0xff, p[i + 1] & 0xff, p[i + 2] & 0xff);
} |
|
Or, shades of gray:
Code: byte p[] = new byte[196608];
System.arraycopy(b, (int)offset, p, 0, 196608);
for(i = 0; i < 196608; i ++) {
pixels[i] = color(p[i] & 0xff, p[i] & 0xff, p[i] & 0xff);
} |
|
And, a high-contrast version (really easy to see where data changes):
Code: byte p[] = new byte[196608];
System.arraycopy(b, (int)offset, p, 0, 196608);
for(i = 0; i < 196608; i ++) {
pixels[i] = p[i] & 0xffffffff;
} |
|
Simple stuff, really.
|
| « Last Edit: Oct 19th, 2004, 1:41am by rgovostes » |
|
|
|
|
fry
|
Re: more bit visualization
« Reply #3 on: Oct 19th, 2004, 7:51pm » |
|
yeah, unpacking bits is good geeky fun.. a couple examples i've done in the past, the former with p5 and the latter just as a hack on top of an open source nes emulator:
http://acg.media.mit.edu/people/fry/mariosoup/
http://acg.media.mit.edu/people/fry/deconstructulator/
as for unpacking the SE image.. i'm guessing that the image is probably 512 pixels wide and 342 pixels tall (not 384), as was the SE's screen. one thing that i've always wanted to try would be a slider that let you set the initial offset, so that you could see the image re-orienting itself until you got a clear picture.
|
| « Last Edit: Oct 19th, 2004, 7:53pm by fry » |
|
|
|
|
gll
|
FileScratching
« Reply #4 on: Oct 19th, 2004, 8:56pm » |
|
Wow! I could reMix my favorites files!
Code://float offset = 10000.0;
offset -= (mouseX-width/2)*0.01f; |
|
|
guillaume LaBelle
|
|
|
rgovostes
|
Re: more bit visualization
« Reply #5 on: Oct 19th, 2004, 9:26pm » |
|
on Oct 19th, 2004, 7:51pm, fry wrote:| as for unpacking the SE image.. i'm guessing that the image is probably 512 pixels wide and 342 pixels tall (not 384), as was the SE's screen. one thing that i've always wanted to try would be a slider that let you set the initial offset, so that you could see the image re-orienting itself until you got a clear picture. |
|
Ah, quite a good catch I was under the impression it was 4:3 like a TV... The below corrected version will also work for dimensions of any size, with the pseudoscrollbar at the bottom.
The pictures still don't show up 
Code:int k, l;
byte b[];
float offset = 0.0;
void setup() {
size(512, 342 + 8);
b = loadBytes("input.dat");
k = width * (height - 8) / 8;
l = width * (height - 8);
}
void loop() {
render();
//offset += 24576;
}
void render() {
int i, x;
byte p[] = new byte[k];
System.arraycopy(b, (int)offset, p, 0, k);
//for(i = 0; i < l; i ++) {
// x = p[i / 8] & 0xff;
// pixels[i] = (~x >> (7 - (i % 8)) & 1) * 0xffffffff;
//}
for(i = 0; i < l; i ++)
pixels[i] = (~(p[i / 8] & 0xff) >> (7 - (i % 8)) & 1) * 0xffffff;
fill(0xffcccccc); stroke(0xffcccccc);
rect(0, height - 8, width - 1, 7);
fill(0xffffffff); stroke(0xff000000);
rect((offset / b.length) * (width - 4), (height - 8), 7, 7);
}
void keyPressed() {
if(key == LEFT) {
offset = constrain(offset - 12288, 0, b.length - 1);
} else if (key == RIGHT) {
offset = constrain(offset + 12288, 0, b.length - 1);
} else if (key == UP) {
offset = constrain(offset - 1, 0, b.length - 1);
} else if (key == DOWN) {
offset = constrain(offset + 1, 0, b.length - 1);
}
}
void mouseReleased() {
println("Index: " + ((mouseY * width) + mouseX + (int)offset));
} |
|
|
|
|
|
|
fry
|
Re: more bit visualization
« Reply #6 on: Oct 20th, 2004, 2:10am » |
|
well, i tried with a mac plus image which supposedly has a picture too, and here's my hack, which lets you move the mouse up and down to see the whole contents of the rom (but not the offset thing i had mentioned..)
however i don't see anything, and i'm starting to wonder if it's actually stored with rle compression or something simple like that. the way to show them was always "G XXXXXXXX" where the Xs were a hex addr for the memory location (rom was mapped into ram somewheres) and i believe G meant jump, so at that point in memory, it should have a tiny program to show the image.
and my files have finished downloading so i can't noodle any more.. there could be bugs in this code so maybe that's broken too.
Code:BImage image;
void setup() {
size(512, 342);
b = loadBytes("MacPlus.rom");
int bits = b.length * 8;
//println(bits + " bits");
image = new BImage(512, 1 + bits / 512);
int index = 0;
for (int i = 0; i < b.length; i++) {
for (int j = 7; j >= 0; --j) {
image.pixels[index++] =
((b[i] & (1 << j)) != 0) ? 0xff000000 : 0xffffffff;
}
}
}
void loop() {
float howmany = image.height - 342;
float howmuch = mouseY / float(height);
image(image, 0, -howmany*howmuch);
} |
|
|
|
|
|
|
rgovostes
|
Re: more bit visualization
« Reply #7 on: Oct 20th, 2004, 3:32am » |
|
Hm, I've not heard of pictures in the Mac Plus - though it has a "Stolen Mac" icon in it which would let an Apple employee check if a machine was using a stolen ROM. In fact, I just dropped in a Mac Plus ROM and I see nothing special - just noise. You're right about the G thing, though.
That's some sleek code I was wondering how long until someone posted something shorter...
I've tried disassembling the ROM, and it's unclear where to start assembly. ROM was loaded into RAM at 0x00400000, so for instance on the SE, the "show picture" function would be 0x1D89A bytes into the file. The instruction at this address is "jsr" (Jump to SubRoutine) to 0x1D8B4 - however, telling my SE to execute this address is fruitless. 0x1D8D6 displays one image, albeit distorted. Anyway, all of the code in that are a makes sense - it appears to call _GetResource, _UnpackBits, _Delay, and then repeat. Obvious what it's doing, but not really I'll have to research what GetResource and UnpackBits do.
http://freaky.staticusers.net/textfiles/SecretROMStuff.txt has more information.
For fun, I'll look for that "Stolen Mac" icon while I'm board ... hopefully that's the size I think it is I did find a ? and an X while viewing at 32x32, I bet these are the icons it overlays on a floppy icon when it can't find a bootable system folder. The cursor is in there, too. When it's so small, your brain kind of makes up images to fit, so it's hard to tell what's static and what's not - I swear I've seen Mario 50 times :\
|
| « Last Edit: Oct 20th, 2004, 4:08am by rgovostes » |
|
|
|
|
rgovostes
|
Re: more bit visualization
« Reply #8 on: Oct 21st, 2004, 11:43pm » |
|
If anyone's following this, here's the documentation for UnpackBits. It doesn't give many clues about how exactly it is packing them - if I find this out, I can alter my program to show the output...
It seems to do Run-Length Encoding, which is fairly simple. I have to figure out what separator character PackBits assumes, though.
|
| « Last Edit: Oct 22nd, 2004, 7:11pm by rgovostes » |
|
|
|
|
|
