Caution: Intense geekery inside

January 23, 2012 1:55 PM

Pipe Logic "Suppose the null-byte is an electron. Then, /dev/zero provides an infinite supply of electrons and /dev/null has an infinite appetite for them..." Modeling transistors and logic gates using Unix pipes.
posted by bitmage (22 comments total)

So....this is not the latest release from Vivid Entertainment capitalizing on geek culture....
posted by Fizz at 2:02 PM on January 23

Official XXX O'Reilly Parody!
posted by hincandenza at 2:07 PM on January 23

If you know this it's because it's an Unix system.
posted by Foci for Analysis at 2:28 PM on January 23 [1 favorite]

This is pretty great:

if(!S_ISFIFO(statbuf.st_mode)) errx(1, "%s: ceci n'est pas une pipe", filename);

posted by finite at 2:29 PM on January 23 [8 favorites]

I started to complain that it would make more sense to use GnuCAP or learn a real assembly language or even MIXAL, but having read this article a second time, I have to tip my hat to the author. Simulating a computer in sh is actually pretty cool.
posted by ob1quixote at 2:36 PM on January 23 [2 favorites]

This is fun.
posted by empath at 3:08 PM on January 23

This is really good.
posted by Blazecock Pileon at 3:19 PM on January 23

This totally tickled TWO of my (G)eek spots.
I'll be in my bunk.
posted by Floydd at 3:36 PM on January 23

Some of you might know him better as lft - the guy who created this out of a single microcontroller and a few discrete components.
posted by ymgve at 3:53 PM on January 23 [4 favorites]

if they build it ... someone will try to install linux on it
posted by fistynuts at 3:54 PM on January 23

if they build it ... someone will try to install linux on it

Yo dawg...
posted by Avelwood at 4:00 PM on January 23

I'm sorry, but I'm a little lost. "Pipe Logic" models the behavior of electronic microchip logic so you could teach your computer to model its own brain using shell commands?
posted by xtian at 4:28 PM on January 23 [1 favorite]

It's basically like unix redstone, if you've ever played minecraft at all.
posted by empath at 4:42 PM on January 23 [1 favorite]

If you liked ymgve's link to lft's earlier demo, you will love Turbulence, a demo that pretty much knocked the socks off the community of Parallax Propeller afficionadoes. Also you might notice the addition of "...and Chip Gracey" to the list of fellow demoer shout-outs; Chip Gracey of Parallax, Inc. pretty much single-handedly designed the P8X32A by hand, and it's an awesome departure (as lft says "a peculiar chip") from ordinary thinking about CPU design. lft obviously got it better than most of the rest of us did.
posted by localroger at 4:57 PM on January 23

Some of you might know him better as lft - the guy who created this out of a single microcontroller and a few discrete components.

Whoa. Just. Whoa.

That.. i... wow.
posted by odinsdream at 5:09 PM on January 23 [1 favorite]

Best comment: Now you just need to build a complete computer out of this which will run INTERCAL.
posted by phliar at 6:57 PM on January 23 [1 favorite]

Yeah ram-less video is pretty amazing: rather then generating an image in video memory, which then gets converted to analog by dedicated hardware, you're using software directly control the electricity levels on the pins of the VGA cable.
posted by delmoi at 9:53 PM on January 23

Isn't that how stuff like the c64 worked anyway? Plus that microcontroller was 20 mhz? That's 20 times faster than the C64 CPU.

I wouldn't even know where to start with doing something like that, but it's not exactly miraculous these days :)
posted by empath at 10:09 PM on January 23

The c64 had a dedicated graphics chip with sprites, like a Nintendo. I don't know if it had a framebuffer, it probably had a text-buffer for plaintext mode.
posted by delmoi at 11:22 PM on January 23

This is clever, using the OS scheduler to schedule a simulator...
posted by spiderskull at 12:43 AM on January 24

The c64 has a full framebuffer with a variety of graphics modes, and the VIC does all of the graphics logic. If you want to, you don't need to do anything other than drawing directly to the framebuffer.

You might be thinking of the Atari 2600, which didn't have a framebuffer and required you to constantly draw the screen in real time.
posted by ymgve at 3:50 AM on January 24

You might be thinking of the Atari 2600, which didn't have a framebuffer and required you to constantly draw the screen in real time yt .

A lot of early game systems were like that, in a sense making them truly 'video games' as software and hardware were intimately tied to the video signal itself, rather then simply 'computer games' where the game just renders itself to a frame buffer.

But there's a slight difference. The Atari and NES had physical hardware to draw sprites and titles. You just load your sprites into the right part of memory, and tell the hardware where they should go. Then the hardware, as generates the video signal puts the sprite's scanline in the right location given the current location and time during the video signal.

So you can do things like have extra sprites by moving the sprites during the scan (i.e. once the first sprite is finished being drawn, you load a new sprite

But what these modern systems are doing is literally just using software, rather then special hardware to generate a video signal. Of course if your chip is fast enough you can just write a software framebuffer, I guess.
posted by delmoi at 8:40 PM on January 25