Let's make a computer

Discussion in 'Public Member Events' started by jkrmnj, May 27, 2016.

  1. I'm definitely interested. Can't promise that I can spend time to help build it (will try) but I'll definitely donate stuff to make this work.
    Yeah, but there are ways to overcome this. First, most important, know your limits. With that I refer to chunk limits for a single player. Make sure that you're building a device which can be loaded by a single player so within this limitation.

    I don't know the limits from mind (can look them up later) but I do know that it seems to be smaller than 2 SMP residences; I used to be able and trigger a beacon on my other smp2 residence (I have a master on/off switch) but these days the beacons in the outer corner no longer get triggered. For the simple reason that this part doesn't get loaded anymore when I'm on my main res.

    And that brings me to point 2: reset switch.

    Glitching (often happens with piston doors) usually happens when the redstone is (as I tend to call it) "out of state". One section affects the other, you place a (redstone) torch which triggers something, remove it and all of a sudden your device is in the wrong state because the triggering you did retained; it didn't reset. In plain English: sometimes sections get a charge while they shouldn't have one (or vice versa) and that can trigger other things. Sometimes you can't just "discharge" it because that sets other stuff into motion.

    But if you keep this in mind during the design you should be able to add reset switches. Or make it so that the device needs to power up and power down (which in itself could also be a reset switch).

    The problems you mention are definitely real, but I think you can overcome them by applying a good design.
    jkrmnj and 607 like this.
  2. It is true that it could cause a lot of lag butI think its a great idea im totally interested!!

    Count me in
  3. The usual problem I see is when the redstone signal simply stops propagating at a repeater after chunk-unload and -reload. The input of the repeater is on, the repeater is on, but the output stays off.

    This would need to somehow cycle all signal lines.
    I'm not sure if that's achievable. Even if, it would immensely add to the complexity.

    Nevertheless, I suggest trying to build and test the core components and then integrate them.
    Test and see what's possible.
  4. I've made a 4-byte (4 x 8 bit) memory cell, because I couldn't find something usable on YT within 1/2 hour.
    It's quite easy using "locked repeater" latches, a simple address demux that uses the fact, that a powered block will power a redstone dust below, but not vice versa, and "RD" and "WR" signals with the same technique.
    It has separate data read and data write ports, I think it is easier to keep it that way and not to make bidirectional data bus. I didn't optimize it, I think it is suitable to show the principles of how a memory cell works.

    Material per bit: 4 repeaters, 2 redstone torches, 11 redstone dust
    Additionally per row (per 8-bit word): 7 repeaters, cca 3 redstone torches, cca 28 redstone dust

    Single bit detail

    Row signals:
    "WR Row" unlocks the "latch" repeaters, "RD Row" unlocks the output comparators

    Address demux with the inverted CE signal matrix

    RD and WR signal detail - same principle as for CE and address demux
    ShelLuser, 607, ESSELEM and 2 others like this.
  5. What kind of memory do we actully want, I sure have got some designs (better than yours :p) but, there are several things you can do:

    1: this isn't real a memory, but you can use a button = lever as a memory, it can sometimes by very usefull [two inputs, one output IN memory, IN reset and OUT]
    2: you can also use a memory that goes on when the IN goes on, not selected by when the signal goes on [two INputs and one OUTput, exactly as above]
    3: a memory wich remembers if signals were ON or OF in one place in time, can not be affected after or before that [two INputs, one OUTput, IN signal IN remember now and OUT.

    (those memorys all are fast memories, you can read and reset them withing a few seconds, but they are slightly bigger as a slow memory (because they have a INput and OUTput for every bit)the slower designes usally have a gigantic memory, but you can't read or write it one one time)
  6. The question it depends on is "why build a redstone computer (programmable redstone device) on EMC" -
    what are the goals?
    607 likes this.
  7. If you think the specifications you gave earlier are possible, I think we should make that our goal even if it could be a little on the difficult side to make in Minecraft. I have one question about it though. What is the point of the 4bit offset when accessing the registers? I imagine we could also simplify the input and output to just binary with redstone lamps and switches unless there is room for a screen.
  8. The offset is only for accessing memory, for memory addresses.
    Example: LD A, (B + 4) means fetch contents from address B + 4 into A, B holds the base address.
    (x) means "contents of memory at address x."
    This allows to easily access structures that are up to 16 bytes long, while holding the base address in a register.
    It is design decision if the offset can only be positive or also negative.

    I think that the design I've described is too ambitious for SMP - I'm thinking how to reduce it, but still meet the goal of "programmable device" that could run a some meaningful program - e.g. calculate (integer) square root of a number.
    jkrmnj likes this.
  9. Thanks for explaining that. What happens if the 2 MSB have a carry? It seems like it just gets dropped.

    As for the project, we can almost certainly drop most of the IO and simplify it down to 1-2byte(s) of input, 1-2 byte(s) of output, and a button. The button could be used to continue after a halt command. If we went with 1 byte each, programs would likely be bigger but the amount of stuff that has to be built would be smaller. Also, 256 bytes of ram/rom is probably more than would ever be necessary for this.
    M4ster_M1ner likes this.
  10. Yes, the set Carry flag then signals overflow or underflow.
    Real CPUs have an additional Overflow flag that is needed for some operations, but that's outside of scope here.

    It is always users' (programmers') obligation to know the limits of used hardware / software and check the input values in order not to use a device outside of the defined range.

    That sounds like a good choice.
    16-bit input, which can be interpreted as two 8-bit parameters or as one 16-bit parameter, or possibly as more than 2 parameters, each consisting of a number of bits.
    16 levers with redstone lamps that can be accessed as two 8-bit input registers.

    16-bit output made from two 8-bit registers - connected to redstone lamps.

    Input and output is binary.
    Eventually, the output may be connected to a device to display the result in decimal form.

    That's the "start" or "enter" button which start the program.
    The CPU can have a "Halted" flag, connected to a redstone lamp that signals that the program has halted and that the result of the calculation is ready. Perhaps also an "Error" flag that can be used to signal an error - and an unusable result.

    Yes, 16 bytes of CPU-internal RAM allowing to temporarily store 8 16-bit numbers is probably enough.

    As for ROM, I'd suggest to have 8-bit PC (program counter) and to allow for 256-bytes long programs, as it is easy to start with e.g. 32 bytes and then add more ROM if needed.
    You can try to write a "square root" program and see how many instructions it needs.
    Perhaps it makes sense to add the "compare" and "compare with carry" instructions (CMP, CMPC), that are the same as SUB and SBC, but only set flags (Carry and Zero) without modifying the accumulator.

    I'm thinking if it would be good to have the ROM made of 8-byte chunks realized as rows of 8 Minecraft blocks that can be either full "1" or hollow "0" and are moved in circle by pistons.
    This way it would be easy to really see the program, it can be also colored for easier reading.

    A jump address would always have to be to a start of 8-byte chunk, and the chunk would always have to be fully read (rotated) before leaving it.
    jkrmnj likes this.
  11. If there would only be "insulated" redstone conductor, with special blocks for connections and crossings, it would be so much easier to build...

    To practice needed skills:

    Device that can add two 4-bit numbers.
    Input: 2 x 4 levers
    Output: 5 redstone lamps showing the sum.
    jkrmnj likes this.
  12. Title Change xD
    607 and jkrmnj like this.
  13. What kind of things would trigger the error flag?

    For the rom, are you talking about something like the gambling wheels that people make where the pistons push it in a square? How would data be stored on that?
  14. i have a question
    where are we buidling this?
  15. Me reading this thread

    ChickenDice and 607 like this.
  16. Probably a Utopia res. I have one that is completely empty that can be used.
  17. While looking at square root algorithms, I realized it would be really nice to have a bitshift operation. It looks like it will fit in the instruction set pretty easily and appears to be simple to build. How do people feel about including it?
    M4ster_M1ner likes this.
  18. The software itself to signal error ... perhaps also the CPU e.g. on invalid instruction.

    Yes, I've already started to build a prototype.
    The program (and data) is stored with blocks: Glass ("transparent") block is a "0" and full block is "1".
    I didn't finish the controller yet - not sure what kind of jumps to implement.

    After reading a byte, it shifts to the next one.
    A simple thing is to skip a byte or few bytes, or to skip to a mark.
    I'd probably go with an extra bit for jump marks, so the jump instruction "JP +n" would be "roll forward to the n-th mark", "JP -n" would be "roll backwards to the n-th mark".

    Shift is very easy to implement.
    I did mention it above (SHL, SHR - shift through carry).
    jkrmnj and 607 like this.
  19. This is all very beyond me, but I'd still like to be a part of it. What will the computer be able to do? Other than all the computer specs and stuff.
    jkrmnj likes this.
  20. I'll provide the res, 5005 on utopia perfect place for it because you said utopia is better and it's spawn front! Msg me on the forums if you want to use the res :)
    Jelle68 and jkrmnj like this.