• 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    @shrugg: Quite nice! I'm going to need RAM later on too, but right now I just need ROM (read-only memory) for the program code itself. (I find it more attractive to write out a program in hardware, where you can physically see the code you're putting down). Disadvantage is that you can't just program in a MOV to shift the program over if you need to add an instruction.

    Quote from snipehsheep »
    Quote from shrogg »
    Just place a button beside the door on either side of the wall.


    Wow? That simple. I tried doing that with levers and only one lever would open it.

    Levers work, but it'll be of the form: if either or both levers are "on", the door is open, else if both levers are "off", the door is closed.

    To use the levers so that flipping one from either side changes the door's state, you'd have to use a 2-input XOR gate, the inputs each being one of the levers.

    Otherwise, maybe one of the levers wasn't powering a block directly adjacent to a door?
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    Hey guys,

    Are there any general techniques or principles to consider in creating space-efficient horizontal device designs? (Not tackling vertical designs or 1-wides yet...) Minimizing the logic is fine for me — I'm comfortable with K-map minimization and NOR implementation of combinational circuits, which suffices for most of my needs. I'm learning various tricks to minimize the number of NOR gates (torches). But when it comes to physically minimizing the space Redstone devices take, try as I might it always seems very suboptimal (a lot of extra space due to parallel wires, crossovers, etc., compared to the super-dense designs some of you guys come up with), aside from the easiest things.


    Also, has anyone designed extensible ROM with 8-bit addresses? (At least extensible in terms of data size, if not address width). I'm trying to work on that right now as part of a (somewhat Harvard-architecture) simple computer I'm designing in Minecraft.

    The design we've seen in my digital systems design class uses an nx2ⁿ decoder to decode the addresses, and each output bit is OR'd with the addresses where that bit is 1. I'm going to try describing what I'm thinking in redstone right now, but I haven't done anything except thinking about it so no screenshots sadly. Hopefully this is clear enough to generate a little discussion.

    I can easily imagine doing that with a line for each inverted decoder output going into 8 blocks — a torch is put on top of it if, at that address, the corresponding bit is 1, and no torch if the bit is 0. I'd have a straight line blocks with redstone on top, perpendicular to the decoder output lines, going over one set of torch.

    The design seems pretty clunky though — 3 blocks per address in one direction, 2 blocks per bit in the other direction, and five blocks high (including the ground block) — the height makes it easy to just walk in and reprogram the thing, though. It should be possible to stack layers of this and then just OR each output bit into a single output bit for the system — again, though, five high.

    I'm not quite sure how to go about designing the decoder for such a system, though. Again, I'm not very good at space efficiency. It would be a series of NAND gates (with inverters on the inputs as necessary), which can be implemented in fairly small amounts of space, although it still seems like it'd be large and messy for decoding 8 bits...

    Best-case response time for this system would be 3 ticks, assuming no signal repeating is necessary (1 tick inverter, 1 tick NAND gate, 1 tick torch in the data array).

    Any comments or other ideas on designing a hardware-reprogrammable ROM?
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on So, I am the only one who hates Redstone?
    I absolutely adore redstone, because of the fact that its main "active" component, the redstone torch, acts like a NOR gate.

    Know what that is?

    It's a universal gate. It means that you can build any logic gate or digital circuit (combinational or sequential) using the NOR gate. (Same goes for NAND).

    You can make any digital circuit you want — from as simple as a combination lock, to a recreation of a real-world circuit like a full-blown computer. Any circuit at all, as long as it's pure digital.

    The only limits are your imagination, computer's processing power and space/simultaneous loaded chunks.

    *cough* Okay, I'm done idolizing now.

    Anyway, the only problem with redstone right now is that its applications are limited to the roleplay sense of the game — i.e. anything that you can profit from in a survival game. Most circuits tend to be more of a creative endeavour than anything that is useful. I attribute this mostly to the fact that we have very little input/output devices for our redstone — pressure plates, buttons, levers, minecart rails, and noteblocks. Soon, pistons, which will open things up a LOT.

    Still, there are a few interesting applications that are useful in Survival (SSP or SMP). Parallel combination locks are quite simple and can act as a layer of defence in SMP. In a mob grinder, you can funnel items to a collection area and use a wooden pressure plate to detect items — you could even design a timer to warn you, via sound blocks and/or flashing torches, when items are about to disappear since you last picked them up. (Youtube:EthosLab implements this — not an ideal one, but effective enough). Obviously, there's automatic subway stations that are designed around redstone control — those are even easier to make now that we don't have to set up power boosters!

    I'd say the most interesting application of redstone right now is railroad/subway control systems. Designing it around a busy server, so that it can automatically regulate each station's cart supply and dispensing, prevent collisions at stations, deal with runaway minecarts, etc.

    Anyway, I've gone on too long here, so I'll just stop. <.<

    @Ichimoto: Can't you use an inverter + a repeater (delay = 1) for one door, and a repeater (delay = 2) for the other? Assuming you don't catch any S/W rule glitches, that should apply 2 ticks of delay to each door, shouldn't it?
    Posted in: Survival Mode
  • 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    @preeriakoer: Could the ones you used be sensitive to the N/S quirk? Have you tried rotating them around ±90°?

    @WarlockD: Ooh, finally the project can keep moving and improving. =3 You're awesome, WarlockD.

    (Now hopefully the original author won't reappear someday and demand the source/your distribution be taken down — which would be entirely in his rights to do, unless he released the original under a license that permitted redistribution of source/reverse engineering.)
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    Okay, this is weird.

    I tried building Cadde's T flip-flop once, and it works fine. I leave one space above it, build another floor layer of dirt, and build the same flip-flop on top of that, same orientation. It doesn't work. I just checked and rechecked the circuit four times, and checked that none of the "floor" blocks were being powered inadvertently.

    The torch right above the input just flickers off a moment instead of going on and off. I hear the circuit burning out, too, every few minutes. The torch in the bottom-right corner stays off permanently, and the top-right corner flickers on (or off? forgot...) instead of oscillating steadily.

    I know that's not much to go on, but anyone perhaps have any idea what happened there? I'm probably just going to tear it down and rebuild from scratch next time I do this... Or just use the wiki one, which is a bit less difficult to figure out for debugging purposes.
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    JoshuaGump, do you know why the sim fails with that flipflop?

    Also, I was trying to get it to work and made a schematic file for Cadde's compact T flip-flop. It might be useful for arranging a more complex circuit's topology, even if it's useless in simulation for now. Trunksbomb, feel free to add it or rehost it. http://www.box.net/shared/u92r4u1cz0

    I needed some multi-input AND gates earlier and designed some semi-compact 3- to 7-input AND gates (5xnx2 for an n-input AND gate, about the same scale as the wiki's). Pretty basic stuff. Think they're worth including?

    Image: http://www.box.net/shared/4p4c3h5je1 [Edit]
    Schematic: http://www.box.net/shared/41g7op5omd
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    Quote from trunksbomb »
    Laogeodritt

    Except that I don't visit the fora very often anymore and I forget about this topic once I stop getting email notifications for whatever reason. XD (e.g. checking it while not logged in).

    Ahh, random number generation. I was thinking about how one could do that in redstone the other day, actually...
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    EDIT: Made a mistake with the carry bit formula. Fixed.

    I'd suggest technique :cool.gif: for converting two's complement by hand and technique a) for doing it via a circuit (using XNOR gates to flip bits, and you can add one via the LSB carry which is unused). [Not sure how you're doing it, just that two above posters mentioned adding +2^n, n being bit width of your integers, but that's a more work-intensive method in both cases.]

    I took a look at the circuit and figured out what I think is your most significant problem:

    You're working with the subtraction of UNSIGNED integers (no sign, i.e. positive or zero), and yet you're expecting an output that makes sense when you'd expect a negative result. It looks like you're expecting to get the magnitude of the result. This makes no sense.

    But if I subtract 10 from 01 it gives 011 (1-2 should give value of 001 instead of 011).
    1 - 2 = -1, negative result, so you would expect signed integer 11. If you look at the two least significant bits (rightmost bits), then the result as a signed integer is correct, just not sign-extended to the third bit. (You need to take the first two bits).

    If you interpret your inputs as SIGNED, then you're really doing 1 - (-2) = 1 + 2 = 3. Your three-bit result is therefore correct — however, if you use a two-bit result, it's -1, because 3 can't fit in a signed integer.

    If I subtract 11 from 01 it gives 010 (1-3=-2 fine enough for me since the value is correct).

    "Fine enough for me" — something you should NEVER say in the face of a possible bug. What happens if the same bug gives you a completely erroneous output for some other input?

    Again, you're assuming your inputs are unsigned and that you'll get a proper signed output. This is true if you consider the two-bit result 10 (ignoring the third, leftmost bit), and that you assume it's signed. If your inputs are signed, you're doing 01 - 11 = 01 + 01 = 010, and your three-bit output. Again, +2 can't fit in a two-bit unsigned input, so it overflows to -2 (10).

    You probably should not be messing around with 2n-to-(n+1) adder circuits or messing around around with mixing signed and unsigned, unless you're 100% sure of how the circuit will act given all the possible inputs you might feed it. It might also be useful to build some overflow detection circuit, so that you know when the result is outside the bounds of your n-bit result.

    For signed addition, we check the "overflow" bit, symbol V. This is generated as follows: define C_n as the carry on the most significant bit's full-adder. Define C_(n-1) as the carry on the full-adder right before that. Then V = C_n XOR C_(n-1) (edited! I made a mistake).

    For unsigned addition, we check the "carry" bit, symbol C, which is simply C_n from above.

    The overflow verification for subtraction of signed integers should be the same if you're first converting two's complement and adding. Other techniques I'm not sure how to check are left as an exercise to the reader.

    In summary,
    - Make sure that you're clear on whether you're adding signed or unsigned numbers, and don't expect a result that isn't possible.
    - Don't mix signed and unsigned inputs/results unless you're 100% sure of a) what the range of inputs you're giving the circuit is; :cool.gif: whether the circuit acts predictably and correctly, and how it does so, for all such inputs.
    - Make sure you understand when overflows occur and to detect it properly.
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    That's what I thought he might've misunderstood, too.

    To add to ick's statement, here's some more background on two's complement.

    Modern computers and digital circuits often use two's complement for signed integers. To transform between two's complement representations (i.e. from positive to negative and back again):

    a) Say you have the number 0110 ( = 6 dec). Invert all its bits: 1001. Then add 1: 1010 = -6 dec.
    :cool.gif: Starting from the right, find the first 1: 0110. Invert each of the bits to the right of that: 1010.

    You can apply these techniques to negative numbers, too, to get the positive number back.

    Technique :cool.gif: is faster. Inverting all the bits (without adding 1) is also called one's complement.


    You might be wondering why we use two's complement. Wouldn't it be easier to just read sign-magnitude form? Like, have the most significant bit (leftmost bit) indicate whether the number is positive (=0) or negative (=1), and then the number itself.

    Although that makes more sense from a human's perspective, in terms of computations it's not all that effective compared to two's complement. The nice thing about two's complement is that you can add them together as if they were unsigned (i.e. strictly positive numbers) and you still get the correct result.

    Say, you want to do 5 - 2, or in binary, 0101 + 1110 = (1)0011 = 3. (The carried 1 is lost, since the binary integer is 4 bits only. That's how you deal with signed integer arithmetic.)

    If we treat the numbers as unsigned 5-bit integers (to not lose the carry), 00101 + 01110 = 10011, same binary result; in decimal, since these are unsigned, you get 5 + 14 = 19.

    Hence, you can design one adder-only circuit for addition AND subtraction, and feed it positive and negative numbers directly. It's also very easy to create a switch using a "sub?" input (i.e. 1 = subtract the numbers), one XOR gate per bit, and a full adder for the LSB to make a circuit that can also subtract (i.e. flips the sign of the second operand to the addition).

    With more human-readable methods like sign-magnitude, you don't have that convenience of designing the same adder circuit for any combination of positive and negative integers. If you naïvely added them, you would add the magnitude and multiply the signs. The circuitry would be more complex and less efficient.
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Switching computers
    Need to know two things:

    1) Which operating system are you running?
    2) Where exactly did you copy the files? (Give the full path to the folder containing the saves folder your hard drive) What else is in that folder?

    Also, could you check that the files copied correctly? (i.e. check inside your copied saves folder to see if the world files that are supposed to be there are indeed there.)
    Posted in: Survival Mode
  • 0

    posted a message on does the "Minecraft Virus" show with McAfee
    Which file is being detected? What is it being detected as? (The A/V should also give you the name of the "virus" in the alert, along with the filename.)

    Proxy-OSS seems to be an adware application, which is entirely unrelated to Minecraft. I would suspect that you're getting a false positive, or it's something else on your computer that's being detected, not a Minecraft file. (Again, which file exactly is being detected?)

    Try uploading the problem file to http://www.virustotal.com and see how many of the antivirus scanners pick it up, and what they detect it as. You can post a link to the results page here if you want a second opinion.
    Posted in: Survival Mode
  • 0

    posted a message on Minecraft for the Wii?
    Re: the one analogue stick, don't forget the motion sensing! You could look around with the Wiimote motion sensing, and move around using the analogue stick. (And this is why I'd like to try a few FPSes on the Wii.)

    Quote from nickkourpias1998 »
    Not possible MC is coded in Java which is not the language that any console runs on.

    Even if it were written in C++, it wouldn't be portable to the Wii. Most "portable" applications use at least some OS-specific code which is selected at compile-time depending on platform - either in the app itself, or in the libraries and APIs it uses. The Wii is a closed platform; most libraries wouldn't be written/built for it like they might be for Windows, Mac, Linux/UNIX, etc. AFAIK, the Wii OS doesn't use a common graphical API like OpenGL. Hence, it wouldn't be possible to directly compile most software for the Wii.

    However, have you ever heard of "porting" any software from one platform to another? That includes video games - Tales of Symphonia from the Gamecube to the PS2 (Japan only), or Cave Story from the PC to the Wii (WiiWare) and DS (DSiWare), for example. They didn't simply take the source code and compile it for the new platform — they would've needed to rewrite some (or most!) of it to work on the target platform. Mostly just the code that interfaces with the OS/hardware, like the game engine part. A port of Minecraft is equally possible, but it would require an extensive rewrite of the code specifically for the target platform.

    Also, Java is a virtual platform; the bytecode compiled Java produces is not machine code runnable on any specific processor or operating system, but bytecode meant to be run by a Java virtual machine — i.e. Java code runs on a virtual processor, which in turn is run on a real processor/operating system. So if someone wrote a Java virtual machine for the Wii, it could run Java. (Obviously, unless the VM was licensed by Nintendo, it'd have to run as a homebrew, which last I checked required a few workarounds...)

    So it's not currently possible to run Java on the Wii, but that doesn't mean it's not possible to run it in the same way that it would on a computer (via a Java VM), if someone wrote the software needed. (Obviously limited by whatever computing resources the Wii has along with computational overhead from the VM.)

    Also, saying that a system "runs" on a language is misleading in wording IMO - the only thing a system/processor does run directly is machine code. Everything in any language is either compiled into machine code, or run through an interpreter/VM which itself is compiled to native machine code. Honestly, you could run anything on the Wii or any other platform, as long as you had an appropriate compiler (or an interpreter compiled for the platform, for interpreted languages), and you wrote the program to use the appropriate APIs and native libraries. (And you could run homebrew on the Wii, for that specific case!)

    Sorry, I went on a bit longer than I intended. I hope that was informative, though. =P Not really making a judgement on whether MC on Wii would subjectively be a good idea - but as far as controls and porting goes, it's certainly viable. I have no idea about the Wii's specs — or what Minecraft specifically would require in terms of resources.

    ---

    Quote from spudcosmic »
    Do you have a brain?!?! CONSOLES CAN NOT SUPPORT MINECRAFT, THEY DO NOT HAVE ENOGHF RAM. LEAVE THE FORUMS NOW! the mods need to make thease post deleated the istant they are made.
    'Cause personal attacks, yelling and suggesting that mods "make thease post deleated" [sic] is totally a way to convince people that you know what you're talking about. Pfft, forget facts, justifications, or even educated guesses. <_<

    See TCoZ's post? Sie actually tried interpreting the available data to back up hir claim, rather than yelling and screaming when (sie thought) someone disagreed.
    Posted in: Survival Mode
  • 0

    posted a message on The Absolute Beginner's Guide to Everything Redstone
    Quote from trunksbomb »
    I saw the same video, Lao. That was really impressive!
    Can you happen to find a link? I should've saved that... XD

    For the noise issue, you could just chain extenders to and from the counter and bury it deep and/or put it far away. Of course, this introduces a longer delay, depending on how far away it is. So there's a tradeoff- noisy, but fast; or quiet, but slow. You pick!
    Well, I guess it depends on the application. Time-sensitive circuits would have trouble dealing with that, if the source and/or output were at the surface. Circuits that didn't care about the counter delay would be fine.

    It's possible to make a 2x2xn vertical wire, though, since a wire on one level connects to an adjacent wire on the layer above, as long as there's no block above the first wire. Just make the wire coil around itself, potentially up to 15 blocks upward. It's no worse than having wires carrying signals around horizontally with more complex systems, I think. Any idea how far down it needs to be to not be heard?

    Also, do you think this guide (and the Compendium) would be more helpful in the Beta - Survival forum?
    Hmm, I would keep it here. It seems more appropriate.
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on The Absolute Beginner's Guide to Everything Redstone
    Quote from slackathor »
    Maybe we can get our heads together and combine the two. All I've seen redstone and water used together for are secret sand doors (and cannons, kind of - they have redstone and water in them). We have got to be able to do something better than just that.

    I've seen a really simple counter design using a boat and water. The basic idea was to have a loop of water flowing around, and using a number of doors equal to the value n that you want to count to. A clock pulse of about 1s would open all the doors, allow the boat to travel through one door, hence advancing the counter. In one of the inter-door spaces, there would be a wooden pressure plate for the boat to activate, which is the output - it is HIGH for every n clock pulses, and LOW otherwise.

    It's more compact and requires a lot less resources than making a ripple counter or synchronous counter using T or JK flipflops. I think a 5-counter takes about the surface area of a T flipflop, maybe 4-5 blocks high. Compare that to a 3-bit ripple counter AND the reset circuit...

    (Only thing is that the doors are really noisy!)

    I'm not sure of the specifics (as described, I don't think it works out if built naïvely), and I can't recall exactly where I saw it.

    I think it used wooden pressure plates to "hollow out" the centre (prevent water from flowing in), rather than raised blocks. I'm not sure if it has importance to, say, the boat's freedom of movement... half-blocks would work out there I guess.


    One limitation, right now, with using water/redstone systems is that there's no easy (and reversible) way to control flow of water via redstone; you can rely on particular behaviours and updating blocks via redstone to modify flow, but it's usually permanent until you reset the whole thing. A (non-mod) floodgate-type block would be rather useful.
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Redstone Logic Gates and FAQs Compendium
    Observationally, with two's complement addition, an overflow has occurred if the sign bit flips when both operands have the same sign. i.e., if you're adding two negative numbers and end up with a positive (two's complement) integer, or adding two positive numbers and end up with a negative integer.

    I'm not 100% sure it covers all overflow cases, or if there's a better condition to detect overflow. I've never really looked into that very much, since I usually work with higher-level programming languages. I think what I gave works, though.
    Posted in: Redstone Discussion and Mechanisms
  • To post a comment, please .