Track selectors are just an array of modified SR latches. If you look at it, piece by piece, they're actually insanely simplistic in function. This is beginner-intermediate stuff. I'd say leaning towards intermediate, but still nowhere near the master level machines that process data based on scientific algorithms I don't even understand.
See, I know absolutely nothing about Redstone engineering. Nothing at all.
How about a wall that moves with pistons triggered by a pressure plate on the track. It would kind of be like a Fremont St in Las Vegas kind of thing. You ride a cart along and the wall moves in waves amd shapes and other things like that.
How about a wall that moves with pistons triggered by a pressure plate on the track. It would kind of be like a Fremont St in Las Vegas kind of thing. You ride a cart along and the wall moves in waves amd shapes and other things like that.
That would probably lag so bad either A. The client would crash or B. The framerate drop would be horrendous and you would be riding through unloaded chunks, not even being able to see this wall.
How about a wall that moves with pistons triggered by a pressure plate on the track. It would kind of be like a Fremont St in Las Vegas kind of thing. You ride a cart along and the wall moves in waves amd shapes and other things like that.
do you need the build/mine permission on to hit a button ?
if so then it could easily be adapted to use pressure pads instead of buttons
Switches, buttons, doors, repeater timings are all of the items, that I've personally tested, that can't be done without the build/mine permission. As I told Nose_Job I'm taking a break from the station, however, I have redone the cart storage system to a "pez dispenser" style system. I'll take and post pictures later today.
I had some concerns over my old system and this solves most, if not all, of them. The spiral is just something semi-random that I thought I'd do.
Looks nice! Much more compact than the old loopy-start-n'-stop-a-ma-jig.
So are you going to be doing anything more to the station, other than aesthetics and fixing the latch array? Or will you be starting on the mechanisms and such? What are you going to call this anyway, a museum or gallery or something?
Looks nice! Much more compact than the old loopy-start-n'-stop-a-ma-jig.
So are you going to be doing anything more to the station, other than aesthetics and fixing the latch array? Or will you be starting on the mechanisms and such? What are you going to call this anyway, a museum or gallery or something?
Thanks, now that I look back at what I did, I agree that it was not only ugly looking, but also highly inefficient. With the new system I no longer have to worry about a cart not getting where it needs to be and clogging up the entire system.
Beyond the aesthetics and fixing the latches, I can't currently think of anything else to add to the station. That may come to me as I'm building the mechanisms.
As for the name, I think "gallery" or "showcase" would be more fitting names than "museum". However, knowing me, I'll probably call it something different each week.
Since I'll be using this map as part "show-off" and part teaching aid, I've decided to start off the groupings with basic logic gates(NOT, AND, etc.) and examples of each in as small as possible a build while still showing what it can be used for. Then after that group, there will be various hidden/"fancy" doors. After that it will be an even more complex build and so on. The eighth and final grouping will most likely be a redstone memory array with two, maybe three, examples of how it could be used.
Thanks, now that I look back at what I did, I agree that it was not only ugly looking, but also highly inefficient. With the new system I no longer have to worry about a cart not getting where it needs to be and clogging up the entire system.
Beyond the aesthetics and fixing the latches, I can't currently think of anything else to add to the station. That may come to me as I'm building the mechanisms.
As for the name, I think "gallery" or "showcase" would be more fitting names than "museum". However, knowing me, I'll probably call it something different each week.
Since I'll be using this map as part "show-off" and part teaching aid, I've decided to start off the groupings with basic logic gates(NOT, AND, etc.) and examples of each in as small as possible a build while still showing what it can be used for. Then after that group, there will be various hidden/"fancy" doors. After that it will be an even more complex build and so on. The eighth and final grouping will most likely be a redstone memory array with two, maybe three, examples of how it could be used.
I just had this brilliant idea all typed up. Then, Firefox derped on me...
Now I'm agitated, so I'm just going to go watch TV and pass out. But I'll be back with that idea tomorrow.
Haha, alright, no problem. I actually switched to chrome rather recently, myself. Got tired of all the Firefox derps, especially with Flash.
The stable releases usually don't give me much of a hassle. I most likely picked up a virus from a porn site somewhere along the line. I'll just clean-install Linux Mint 13 again in a few days. Or maybe switch to a different distro, as long as it's Linux-based. Anyway, time to re-form my idea.
You could have sections, that would be divided into sub-sections. For example, you could have an area dedicated to logic. It would start with a plot for standard logic gates, AND, NAND, OR, NOR, XOR, XNOR, NOT. You could also have a little spot behind that for obscure logic gates, IMPLIES, NIMPLIES, CON-IMPLIES, CON-NIMPLIES, TRUTH, FALSE, IDENTITY, PROJECTION, NEGATION. There are probably more I'm forgetting. They're rarely useful, except in Redstone Theory, but still interesting to look at and study.
Next section could be simple mechanisms using the basic gates.
Half Adder - 1 XOR gate, 1 AND gate
Full Adder - 2 XOR gates, 2 AND gates, 1 OR gate
Comparator - 1 XOR gate, 1 AND gate, + 1 OR gate/additional bit
Combination Lock - 1 AND gate/2 inputs
SR Latch - 2 NAND gates
RS NAND Latch - 2 NAND gates
RS NOR Latch - 2 NOR gates (In this case, they're pretty much just NOT gates.)
JK Latch - 2 NOR gates, 2 NOT gates
Gated SR Latch - 2 NOR gates, 2 AND gates
Gated D Latch - 2 NOR gates, 2 AND gates, 1 NOT gate
I'm not even going to get into obscure latches or the thousands of other things you can create using logic gates. They're really not necessary for basic understanding of logic. Also, keep in mind that all of these mechanisms can be made with different gates from what I listed. If it functions exactly as the mechanism should, that's what it is, this is just how I understand them. If you want, I could also make some diagrams for each of these. I've been getting back into playing with Logisim lately, so it wouldn't be a problem.
After this, you could build some slightly more complex components that use these mechanisms.
Sequential Memory Array - 1 RS NOR Latch/input (This is what would be used in a combo lock. [In theory, most SR latches could be used for this.])
Unary Memory Array - 1 RS NOR Latch/bit (This is what your track selector will be once it's fixed.)
Binary -> Unary Decoder - (Contains 1 NOT gate for every unary value equivalent to a single binary digit. 1, 2, 4, 8, 16, 32, 64, etc. All values receiving multiple binary inputs use AND gates.)
Binary -> BCD Decoder:
This deserves its own paragraph, cause it's about to get a little bit complicated up in here. (Don't worry, it's nothing too scary.) The easiest way to convert binary values to binary-coded decimal is by using the Double Dabble Algorithm. For an n-bit value, you need a 4-bit scratch space for each decimal digit the binary word can represent. This means, for an 8-bit word, which can represent 256 values, would need three 4-bit scratch spaces, totaling 12 bits. The algorithm is performed by left-shifting the value n times for your n-bit binary word, (in this case, 8) and adding 3 to any BCD column equal to or greater than 5. Once you have reached n shifts, the algorithm is completer and you should have your value.
Here's an example, we'll be using 10111001, which is 185 in decimal.
That took way longer to type than I thought it would. x_x Anyway, there are a ton of designs for a binary to BCD decoder. The most common models use a humongous array of full adders. This is a bit slow, but still faster than using special purpose registers and sending the data through an ALU repeatedly. Not to mention, compared to a binary to unary decoder, this will make up speed tremendously in the long run, the more bits are added. This makes it ideal for 7-segment displays, cutting down tremendously on delay as well as size.
This is only about half of my overall idea, but I'm thinking that this is a pretty big post already by how long it takes me to scroll through it. Sometime later I will post the rest of the layout I'm envisioning. Next would be getting into the somewhat advanced circuitry. Not all that advanced though, just up to the point of a really basic computer. I was thinking it would be pretty awesome if all this stuff led up to a simple 1-bit example computer.
You could have sections, that would be divided into sub-sections. For example, you could have an area dedicated to logic. It would start with a plot for standard logic gates, AND, NAND, OR, NOR, XOR, XNOR, NOT. You could also have a little spot behind that for obscure logic gates, IMPLIES, NIMPLIES, CON-IMPLIES, CON-NIMPLIES, TRUTH, FALSE, IDENTITY, PROJECTION, NEGATION. There are probably more I'm forgetting. They're rarely useful, except in Redstone Theory, but still interesting to look at and study.
I had planned on including AND, NAND, OR, NOR, XOR, XNOR and NOT gates.
I had taken a look at the more obscure logic gates and decided to not include them. Simply because they are rarely useful, as you said yourself, in common builds that people like to make.
And as far as I understand it, a TRUE/TRUTH gate is simply a redstone torch.
Next section could be simple mechanisms using the basic gates.
Half Adder - 1 XOR gate, 1 AND gate
Full Adder - 2 XOR gates, 2 AND gates, 1 OR gate
Comparator - 1 XOR gate, 1 AND gate, + 1 OR gate/additional bit
Combination Lock - 1 AND gate/2 inputs
SR Latch - 2 NAND gates
RS NAND Latch - 2 NAND gates
RS NOR Latch - 2 NOR gates (In this case, they're pretty much just NOT gates.)
JK Latch - 2 NOR gates, 2 NOT gates
Gated SR Latch - 2 NOR gates, 2 AND gates
Gated D Latch - 2 NOR gates, 2 AND gates, 1 NOT gate
-snip-
Sequential Memory Array - 1 RS NOR Latch/input (This is what would be used in a combo lock. [In theory, most SR latches could be used for this.])
Unary Memory Array - 1 RS NOR Latch/bit (This is what your track selector will be once it's fixed.)
Most, if not all, of everything listed above here could be added. I don't see any problems there.
Binary -> Unary Decoder - (Contains 1 NOT gate for every unary value equivalent to a single binary digit. 1, 2, 4, 8, 16, 32, 64, etc. All values receiving multiple binary inputs use AND gates.)
This is where I get a little "iffy". I'm unfamiliar with Decoders and couldn't properly teach someone what is going on, what is doing what and how it's set up to do what it's doing. Personally, I still believe the most advanced thing I've done to date was the redstone memory array I have for my countdown timer.
Binary -> BCD Decoder:
This deserves its own paragraph, cause it's about to get a little bit complicated up in here. (Don't worry, it's nothing too scary.) The easiest way to convert binary values to binary-coded decimal is by using the Double Dabble Algorithm. For an n-bit value, you need a 4-bit scratch space for each decimal digit the binary word can represent. This means, for an 8-bit word, which can represent 256 values, would need three 4-bit scratch spaces, totaling 12 bits. The algorithm is performed by left-shifting the value n times for your n-bit binary word, (in this case, 8) and adding 3 to any BCD column equal to or greater than 5. Once you have reached n shifts, the algorithm is completer and you should have your value.
Here's an example, we'll be using 10111001, which is 185 in decimal.
That took way longer to type than I thought it would. x_x Anyway, there are a ton of designs for a binary to BCD decoder. The most common models use a humongous array of full adders. This is a bit slow, but still faster than using special purpose registers and sending the data through an ALU repeatedly. Not to mention, compared to a binary to unary decoder, this will make up speed tremendously in the long run, the more bits are added. This makes it ideal for 7-segment displays, cutting down tremendously on delay as well as size.
This, as of the moment this reply is posted, is out of the question. Haha. Like explained above, this is something I'm going to have to mess around with and understand before I show it off and/or try to teach about it.
This is only about half of my overall idea, but I'm thinking that this is a pretty big post already by how long it takes me to scroll through it. Sometime later I will post the rest of the layout I'm envisioning. Next would be getting into the somewhat advanced circuitry. Not all that advanced though, just up to the point of a really basic computer. I was thinking it would be pretty awesome if all this stuff led up to a simple 1-bit example computer.
I am however, looking forward to the other suggestions you have.
As for the 1-bit example computer, that will be(if this map is a success) on another map if anything, and only after we've completed "Project Xenon".
I had planned on including AND, NAND, OR, NOR, XOR, XNOR and NOT gates.
I had taken a look at the more obscure logic gates and decided to not include them. Simply because they are rarely useful, as you said yourself, in common builds that people like to make.
And as far as I understand it, a TRUE/TRUTH gate is simply a redstone torch.
Yeah, the really shady unheard-of gates are almost never useful. Most of them are only used in Redstone Theory, which is a completely different genre of redstone that has little to do with logic itself. It's more about diving deep into the underlying mechanics of redstone as a conductor. It's unlike any power source, so if one wishes to study it, you have to think in completely abstract terms, disconnect it from electronics or reinterpretations of it.
I've actually seen implication gates, converse non-implication gates, and the rest of that specific family used a few times. Not commonly though, it's usually only found in a couple addition algorithms. The rest of those obscure gates, I can almost guarantee you won't see anywhere, unless they were created by accident.
This is where I get a little "iffy". I'm unfamiliar with Decoders and couldn't properly teach someone what is going on, what is doing what and how it's set up to do what it's doing. Personally, I still believe the most advanced thing I've done to date was the redstone memory array I have for my countdown timer.
This is one of those things that sounds a lot more complex than it really is. Once you see one in person, it will seem much more simple. To make a binary to unary decoder, the only knowledge you need is how to count in binary. The easiest design contains binary inputs inputs leading to blocks, with a perpendicular lines above them, which are your unary outputs. From this point, you just place torches and count in binary. A 1 is a single inversion, and a 0 is double inverted, you just represent that with the lines of blocks in front of the inputs.
(0001, 0010, 0011, 0100, 0101, 0110, 0111, 1000, etc. [for a 4-bit decoder])
This, as of the moment this reply is posted, is out of the question. Haha. Like explained above, this is something I'm going to have to mess around with and understand before I show it off and/or try to teach about it.
Not even going to lie, this is a bit more complicated. Understanding a machine that can perform an algorithm like this comes from more of an intermediate-level of knowledge concerning computer science. By the time we're done with XENON, you'll be laughing at stuff like this.
I am however, looking forward to the other suggestions you have.
As for the 1-bit example computer, that will be(if this map is a success) on another map if anything, and only after we've completed "Project Xenon".
It actually wouldn't be that big, if that's what you're getting at. I pretty much have a whole example computer on my old map, from when I was making the logic tutorial threads. It's scattered out in pieces, but altogether, it would most likely only take up a 50 x 50 area. It would barely put a dent on the map. It wouldn't have to be a very complex computer, just an ALU with standard logic functions, maybe an adder. 4-bit program memory with a tiny 2-bit program counter, throw in a 1-bit RAM, 1-bit input register and you're done. You won't have to worry about synchronization, since it doesn't even have to be functional. You just need something you can point at and say "This is this, that is that, and here's how it goes together."
It would make more sense for the complex things to have their own section. It would be unnecessary to add them to the mini-CPU, if someone asks you will be able to just tell them where a more advanced component would fit in.
you should look at a tutorial. not to copy it, but to see how they do the redstone and take ideas because it looks like you're over-complicating the wiring. also, a pez despenser for the minecarts would save you a ton of space and clean up the whole project.
you should look at a tutorial. not to copy it, but to see how they do the redstone and take ideas because it looks like you're over-complicating the wiring. also, a pez despenser for the minecarts would save you a ton of space and clean up the whole project.
good luck
Read more than the OP before posting, please.
The wiring isn't over-complicated other than the fact the latches aren't ideal. Other than that, they actually need a slight modification added to the array. And a PEZ dispenser type system was added. Again, read through the whole thread.
you should look at a tutorial. not to copy it, but to see how they do the redstone and take ideas because it looks like you're over-complicating the wiring. also, a pez despenser for the minecarts would save you a ton of space and clean up the whole project.
good luck
The whole idea behind this build/series of builds, is to test my own person knowledge of redstone and how it works. If you could point out where I'm "over-complicating" the wiring, that would be greatly appreciated.
This is one of those things that sounds a lot more complex than it really is. Once you see one in person, it will seem much more simple. To make a binary to unary decoder, the only knowledge you need is how to count in binary. The easiest design contains binary inputs inputs leading to blocks, with a perpendicular lines above them, which are your unary outputs. From this point, you just place torches and count in binary. A 1 is a single inversion, and a 0 is double inverted, you just represent that with the lines of blocks in front of the inputs.
(0001, 0010, 0011, 0100, 0101, 0110, 0111, 1000, etc. [for a 4-bit decoder])
Even if it isn't quite as complicated as I think, I'd still feel more comfortable teaching people something AFTER I've messed around with making it personally.
Not even going to lie, this is a bit more complicated. Understanding a machine that can perform an algorithm like this comes from more of an intermediate-level of knowledge concerning computer science. By the time we're done with XENON, you'll be laughing at stuff like this.
I would certainly hope so.
It actually wouldn't be that big, if that's what you're getting at. I pretty much have a whole example computer on my old map, from when I was making the logic tutorial threads. It's scattered out in pieces, but altogether, it would most likely only take up a 50 x 50 area. It would barely put a dent on the map. It wouldn't have to be a very complex computer, just an ALU with standard logic functions, maybe an adder. 4-bit program memory with a tiny 2-bit program counter, throw in a 1-bit RAM, 1-bit input register and you're done. You won't have to worry about synchronization, since it doesn't even have to be functional. You just need something you can point at and say "This is this, that is that, and here's how it goes together."
It would make more sense for the complex things to have their own section. It would be unnecessary to add them to the mini-CPU, if someone asks you will be able to just tell them where a more advanced component would fit in.
Well, when put that way, I suppose it couldn't hurt to at least show it off. Haha.
See, I know absolutely nothing about Redstone engineering. Nothing at all.
That would probably lag so bad either A. The client would crash or B. The framerate drop would be horrendous and you would be riding through unloaded chunks, not even being able to see this wall.
It was a cool idea though.
I'll look into that, no promises, though.
I'm so crazy I did this in survival! No, I'm kidding, this is definitely done in creative.
I had some concerns over my old system and this solves most, if not all, of them. The spiral is just something semi-random that I thought I'd do.
Looks nice! Much more compact than the old loopy-start-n'-stop-a-ma-jig.
So are you going to be doing anything more to the station, other than aesthetics and fixing the latch array? Or will you be starting on the mechanisms and such? What are you going to call this anyway, a museum or gallery or something?
Thanks, now that I look back at what I did, I agree that it was not only ugly looking, but also highly inefficient. With the new system I no longer have to worry about a cart not getting where it needs to be and clogging up the entire system.
Beyond the aesthetics and fixing the latches, I can't currently think of anything else to add to the station. That may come to me as I'm building the mechanisms.
As for the name, I think "gallery" or "showcase" would be more fitting names than "museum". However, knowing me, I'll probably call it something different each week.
Since I'll be using this map as part "show-off" and part teaching aid, I've decided to start off the groupings with basic logic gates(NOT, AND, etc.) and examples of each in as small as possible a build while still showing what it can be used for. Then after that group, there will be various hidden/"fancy" doors. After that it will be an even more complex build and so on. The eighth and final grouping will most likely be a redstone memory array with two, maybe three, examples of how it could be used.
I just had this brilliant idea all typed up. Then, Firefox derped on me...
Now I'm agitated, so I'm just going to go watch TV and pass out. But I'll be back with that idea tomorrow.
The stable releases usually don't give me much of a hassle. I most likely picked up a virus from a porn site somewhere along the line. I'll just clean-install Linux Mint 13 again in a few days. Or maybe switch to a different distro, as long as it's Linux-based. Anyway, time to re-form my idea.
You could have sections, that would be divided into sub-sections. For example, you could have an area dedicated to logic. It would start with a plot for standard logic gates, AND, NAND, OR, NOR, XOR, XNOR, NOT. You could also have a little spot behind that for obscure logic gates, IMPLIES, NIMPLIES, CON-IMPLIES, CON-NIMPLIES, TRUTH, FALSE, IDENTITY, PROJECTION, NEGATION. There are probably more I'm forgetting. They're rarely useful, except in Redstone Theory, but still interesting to look at and study.
Next section could be simple mechanisms using the basic gates.
Half Adder - 1 XOR gate, 1 AND gate
Full Adder - 2 XOR gates, 2 AND gates, 1 OR gate
Comparator - 1 XOR gate, 1 AND gate, + 1 OR gate/additional bit
Combination Lock - 1 AND gate/2 inputs
SR Latch - 2 NAND gates
RS NAND Latch - 2 NAND gates
RS NOR Latch - 2 NOR gates (In this case, they're pretty much just NOT gates.)
JK Latch - 2 NOR gates, 2 NOT gates
Gated SR Latch - 2 NOR gates, 2 AND gates
Gated D Latch - 2 NOR gates, 2 AND gates, 1 NOT gate
I'm not even going to get into obscure latches or the thousands of other things you can create using logic gates. They're really not necessary for basic understanding of logic. Also, keep in mind that all of these mechanisms can be made with different gates from what I listed. If it functions exactly as the mechanism should, that's what it is, this is just how I understand them. If you want, I could also make some diagrams for each of these. I've been getting back into playing with Logisim lately, so it wouldn't be a problem.
After this, you could build some slightly more complex components that use these mechanisms.
Sequential Memory Array - 1 RS NOR Latch/input (This is what would be used in a combo lock. [In theory, most SR latches could be used for this.])
Unary Memory Array - 1 RS NOR Latch/bit (This is what your track selector will be once it's fixed.)
Binary -> Unary Decoder - (Contains 1 NOT gate for every unary value equivalent to a single binary digit. 1, 2, 4, 8, 16, 32, 64, etc. All values receiving multiple binary inputs use AND gates.)
Binary -> BCD Decoder:
This deserves its own paragraph, cause it's about to get a little bit complicated up in here. (Don't worry, it's nothing too scary.) The easiest way to convert binary values to binary-coded decimal is by using the Double Dabble Algorithm. For an n-bit value, you need a 4-bit scratch space for each decimal digit the binary word can represent. This means, for an 8-bit word, which can represent 256 values, would need three 4-bit scratch spaces, totaling 12 bits. The algorithm is performed by left-shifting the value n times for your n-bit binary word, (in this case, 8) and adding 3 to any BCD column equal to or greater than 5. Once you have reached n shifts, the algorithm is completer and you should have your value.
Here's an example, we'll be using 10111001, which is 185 in decimal.
[0000 0000 0000] [1011 1001]
Shift #1
[0000 0000 0001] [0111 0010]
Shift #2
[0000 0000 0010] [1110 0100]
Shift #3
[0000 0000 0101] [1100 1000]
1's place is 5, so +3
[0000 0000 1000] [1100 1000]
Shift #4
[0000 0001 0001] [1001 0000]
Shift #5
[0000 0010 0011] [0010 0000]
Shift #6
[0000 0100 0110] [0100 0000]
1's place is 6, so +3
[0000 0100 1001] [0100 0000]
Shift #7
[0000 1001 0010] [1000 0000]
10's place is 9, so +3
[0000 1100 0010] [1000 0000]
Shift #8
[0001 1000 0101] [0000 0000]
And now you're done!
[0001 = one] [1000 = eight] [0101 = five] = 185
That took way longer to type than I thought it would. x_x Anyway, there are a ton of designs for a binary to BCD decoder. The most common models use a humongous array of full adders. This is a bit slow, but still faster than using special purpose registers and sending the data through an ALU repeatedly. Not to mention, compared to a binary to unary decoder, this will make up speed tremendously in the long run, the more bits are added. This makes it ideal for 7-segment displays, cutting down tremendously on delay as well as size.
This is only about half of my overall idea, but I'm thinking that this is a pretty big post already by how long it takes me to scroll through it. Sometime later I will post the rest of the layout I'm envisioning. Next would be getting into the somewhat advanced circuitry. Not all that advanced though, just up to the point of a really basic computer. I was thinking it would be pretty awesome if all this stuff led up to a simple 1-bit example computer.
I had planned on including AND, NAND, OR, NOR, XOR, XNOR and NOT gates.
I had taken a look at the more obscure logic gates and decided to not include them. Simply because they are rarely useful, as you said yourself, in common builds that people like to make.
And as far as I understand it, a TRUE/TRUTH gate is simply a redstone torch.
Most, if not all, of everything listed above here could be added. I don't see any problems there.
This is where I get a little "iffy". I'm unfamiliar with Decoders and couldn't properly teach someone what is going on, what is doing what and how it's set up to do what it's doing. Personally, I still believe the most advanced thing I've done to date was the redstone memory array I have for my countdown timer.
This, as of the moment this reply is posted, is out of the question. Haha. Like explained above, this is something I'm going to have to mess around with and understand before I show it off and/or try to teach about it.
I am however, looking forward to the other suggestions you have.
As for the 1-bit example computer, that will be(if this map is a success) on another map if anything, and only after we've completed "Project Xenon".
Yeah, the really shady unheard-of gates are almost never useful. Most of them are only used in Redstone Theory, which is a completely different genre of redstone that has little to do with logic itself. It's more about diving deep into the underlying mechanics of redstone as a conductor. It's unlike any power source, so if one wishes to study it, you have to think in completely abstract terms, disconnect it from electronics or reinterpretations of it.
I've actually seen implication gates, converse non-implication gates, and the rest of that specific family used a few times. Not commonly though, it's usually only found in a couple addition algorithms. The rest of those obscure gates, I can almost guarantee you won't see anywhere, unless they were created by accident.
This is one of those things that sounds a lot more complex than it really is. Once you see one in person, it will seem much more simple. To make a binary to unary decoder, the only knowledge you need is how to count in binary. The easiest design contains binary inputs inputs leading to blocks, with a perpendicular lines above them, which are your unary outputs. From this point, you just place torches and count in binary. A 1 is a single inversion, and a 0 is double inverted, you just represent that with the lines of blocks in front of the inputs.
(0001, 0010, 0011, 0100, 0101, 0110, 0111, 1000, etc. [for a 4-bit decoder])
Not even going to lie, this is a bit more complicated. Understanding a machine that can perform an algorithm like this comes from more of an intermediate-level of knowledge concerning computer science. By the time we're done with XENON, you'll be laughing at stuff like this.
It actually wouldn't be that big, if that's what you're getting at. I pretty much have a whole example computer on my old map, from when I was making the logic tutorial threads. It's scattered out in pieces, but altogether, it would most likely only take up a 50 x 50 area. It would barely put a dent on the map. It wouldn't have to be a very complex computer, just an ALU with standard logic functions, maybe an adder. 4-bit program memory with a tiny 2-bit program counter, throw in a 1-bit RAM, 1-bit input register and you're done. You won't have to worry about synchronization, since it doesn't even have to be functional. You just need something you can point at and say "This is this, that is that, and here's how it goes together."
It would make more sense for the complex things to have their own section. It would be unnecessary to add them to the mini-CPU, if someone asks you will be able to just tell them where a more advanced component would fit in.
good luck
Read more than the OP before posting, please.
The wiring isn't over-complicated other than the fact the latches aren't ideal. Other than that, they actually need a slight modification added to the array. And a PEZ dispenser type system was added. Again, read through the whole thread.
The whole idea behind this build/series of builds, is to test my own person knowledge of redstone and how it works. If you could point out where I'm "over-complicating" the wiring, that would be greatly appreciated.
Also, I have already switched over to a "Pez Dispenser" style storage system, picture here: http://www.minecraftforum.net/topic/1537148-minecart-station/page__st__20#entry18817902
Even if it isn't quite as complicated as I think, I'd still feel more comfortable teaching people something AFTER I've messed around with making it personally.
I would certainly hope so.
Well, when put that way, I suppose it couldn't hurt to at least show it off. Haha.
Picture:
Questions, comments?