Interesting... To both Codebreadpudding and RedstoneWithoutLimits, I'm pleasantly surprised somebody else has thought of building this I've built two different clocks of this style before, the first being in 2011. I've hardly been around the forums tho, so I missed both of these threads. (Gave up after the lack of response to my second clock)
Also this makes... At the very least 4 people independently finding this idea... Tho I have no idea if anybody built any between 2012 and 2015. At the very least Roboticaust built one after seeing mine, and somebody had built a variable timer (but not a clock) well before my first one. First clock I know of of this kind was the one Murtdragon showed in my older thread.
Which brings me to another point: there are a couple different styles for building clocks of this kind:
-Selecting clocks. Roboticaust's version had 4 different 1-wide clocks, and a decoder to pick the appropriate one. Fairly compact for low speeds, but limited options available.
-Enabling or disabling timer circuits. Both of my clocks, and Murtdragon's clock used this. It enables quite a range of frequencies, because you can have multiple timers enabled or disabled in parallel, and get lots of combinations out of only a few timers. All three clocks I know of that did this had timers with power-of-two times: 1-tick 2-tick 4-tick etc. etc. So you could enter a precise number of ticks whenever you wanted. I used a different style from Murtdragon: In my clocks, there is a base 2-tick clock with branches off of it. If you want to change speeds, you have to turn the clock off, and then turn the timers on or off. Otherwise, you might split a signal in half and have things go wonky. In Murtdragon's design, the clock checks its input every cycle when the signal gets to the base section of the clock, and only toggles the timers here. It can easily change speeds while its running, but that circuitry meant it had a minimum period of several ticks.
-Have a counter go between two spots. I don't think I've seen this one built, but theoretically it allows extremely high clock periods (say, entire dispensers full of items, possibly with a period multiplier). The downside, is that the granularity that periods can be set to is limited by how long it takes to move one count (an item, or a number between two registers, etc) two ways. I would guess this would cover the very high end of the spectrum of long period clocks, but be of limited precision.
Looking at both of the above clocks, I'm not quite sure what kinds I'm looking at... Is RedstoneWithoutLimits' clock multiple different clocks, with a selector between them? It looks a bit like that, seeing as the video only has the first or the third running; The three options may be mutually exclusive. Is that correct?
And CodeBreadPudding's clock... has a signal of a specific strength going to a comparator for input. Does that clock store a signal strength, as starting point for pulser fader clocks? Or is the signal strength controlling locked repeaters to enable / disable timers? I'm not quite sure what to make of using a signal strength for input.
(I suppose I can build both of these in the game myself to see.)
Well, there's several ways in general to switch a clock between different speeds, although probably all of them need more space than that one. So, the best way (or any possible way) to go about this kinda depends on how much room is available around there for it. One of the more understandable ways to do a varying speed clock is what zetlandsveryown said: Swap between two. Especially if you only need two options to toggle on a button. I think Roboticaust's old channel has a video demoing this from way back when. Also, I can point out one really general technique, as demo'd by my build (now on the second page of this forum): For lack of better terminology, enable and disable a delay slot along the wire. Basically, you could have a piston moving a block back and forth, connecting one 'path' along the wire when retracted and connecting the other when extended. You could use that to swap between 5 ticks worth of repeaters and 20 ticks, have all the repeaters on one side and 0 repeaters on the other side (so the delay purely adds time) or what have you. For a more complicated requirement, you could connect 1, 2, 4 etc. tick side tracks that can each turn on and off independently, so you can get any number accurate to 1 tick just by changing the settings. But for something like this, you could just have a... 6 tick delay on one part of the track, and then go through or skip the other part of the track (for the remainder of the time) with the toggle. I prefer to put the toggle on the input to a track, so you don't have the side track constantly activating when it isn't in use, tho with it on the input you may need to watch that the side track doesn't loop on its own and skip the first part.
If you want one side to be as short as the 6 ticks shown here, then for just about any side clock it might consume less space to use an entirely separate clock for the other speed. Tho most of the size required for a two clock system would be the TFF and toggle anyways, so it might save space to enable and disable a side track like that.
Not sure if this helps, since I don't really know how much space you have to work with.
I've built a clock (oscillator) that can run at nearly any frequency you want. You could use this for any kind of machine that needs to operate at different speeds in different circumstances. Say, a music player that can change tempo, or a lighting system. Or, since each part has a known / measurable speed, you could use this to get very specific timings that would be difficult to do with repeaters, and would take too long to test with a custom-built circuit. It can be set to any speed from 2 ticks, up through 8193 ticks, with a resolution of 1 tick. (Usage note: What ever speed the device is set to, as a binary number, it will run 2 ticks slower than that.)
Front view:
How it works: This is, at its core, a repeater clock. There's a vertical track running the full width of the device, with two repeaters. This gives it the minimum 2-tick speed: These two repeaters with nothing but wire between them. Along the entire track are delay circuits/timers. By default, these are disconnected from the main loop. When enabled, the track in front of them is blocked, and the signal passes through the timer instead, adding the corresponding number of ticks delay to that 2-clock on the main track. It has a separate circuit (and switch) for each power of two, giving it an input as a binary number of ticks. Since the device can operate as a 2-clock (1 on, 1 off), we have to start it with a 1-tick pulse. This gets stretched out to 2-4 tick long on-pulses by most of the timers.
The shorter timers are repeater tracks. These are all the timers on the bottom half of the main track. The top of the track has the longer timers, ranging from 64 to 4096 ticks. These are all variations on the same circuit. They use a 16-clock to drive a dropper-dropper counter through N items, twice. So these timers count down 32 ticks for every item in the droppers, plus a 32 tick start-stop time so we can easily do multiples of 64 ticks. Each of them is 3 wide, and 4 tileable. Inputs are two tileable, and connected in pairs to two timers, one above the other.
Comparing this one to its predecesor, this one has 13 bits of range, to the old clock's 8 bits. In construction, this one uses a vertical track, so timers fit 2 blocks apart. The old one had timers far more spaced out, on a horizontal track. That said, the old one had a restart circuit, which could automatically shutdown the clock or change its speed with a single button press. To shut down this one... Have fun waiting 7 minutes or so with the off switch enabled. You can shut it down in a few seconds, if none of the longer timers are running.
So, that I can see this is meant to select the item volume placed in a minecart? That may actually be the most productive use of such a clock. I've thought a few times a variable speed clock could be useful for a music system that ran at various tempos...
How is the delay for adding items controlled? Do input signals add an item to some template chest, and then the output chest is timed by the template chest? All of the previous variable delay timers / variable speed clocks I've seen used repeaters as delay circuits.
...While I'm mentioning previous clocks, here's a shameless plug of my own variable speed clock. Also my first big creation http://www.minecraftforum.net/topic/821567-variable-frequency-clock-generator/
(Other clocks of this type were made by Murtdragon (posted in that thread, decided on the appropriate clock delay every cycle), Roboticaust (posted on Youtube, toggled between 4 normal clocks. Referenced my clock in his video ), bansheecraft's variable no pulse generator (http://www.minecraftforum.net/topic/1098792-variable-no-pulses-generator-expandable/)... And there was at least one clock posted on the forums a while before mine, although I don't remember the author or have a link to the thread)
Well. Not completely, I don't know of a good way to learn assembly for the RG3 specifically. I've yet to write for it myself. That said, from the looks of it the statement structure it uses is moderately similar to the RG2, so I'll see if I can explain it from that myself.
...At the most basic level, every instruction does two things (where assembly on a normal RISC machine only specifies one) A logical operation on data, and a branch.
-Logical operations are similar to operators in higher level languages. You specify one or two values, an operation to do on them and take back some result. Operations are done by an ALU (arithmetic logic unit, as all computers have). You use the ALU by loading in values from two 'registers', selecting an ALU operation, and then saving the result back to a 'register'. Registers, now that I've mentioned them, are your general purpose memory. They are also the only memory you can save data to, unless a memory unit was added to the computer using DPI. The RG3 has 16 of them. Treat them as poorly named variables. You can load in two registers to the ALU, and perform your operation on them in the same command. This is where I may be a little inaccurate, as I've only used the RG2. There, we would load in one register to ALU input 1, then an other to ALU input 2, and do our operation. Then on the third cycle read from ALU output back to one of our registers. The RG3 does both reads to the ALU in one cycle, as well as the operation. Then the next cycle you still specify that you'll read from the ALU and write back to one of your registers.
-The branching system is, AFIAK, specific to the RedGame series of computers. Namely, every instruction specifies a condition, and two destination instructions (goto). Conditions basically specify a different selection based data, or what you're currently doing. Think of them as the if-then-else clause in higher level languages. (Indeed, all high level languages from C to Ruby to Lua to Haskell implement if's, and function calls as complicated gotos) The RG3 has conditions for the levers in the user interface, for ALU output being 0, for the two inputs being equal, one that always pics the first destination etc. etc. Your two destinations, in the cheat sheet of Dude's manual, are labeled '0' and '1', if you want to read the entire list of ways you can select a branch.
The branch destinations themselves work sorta like goto [line number] in FORTRAN and some Basics. Every instruction is numbered either from 0 to ~60 or 1 to ~60 (They're 1-based, or counted from 1 on the RG2). Selecting goto 10 will execute line 10. Unlike those two languages (and normal computers) execution does not automatically continue to the next line. If you want instruction n to be followed by instruction n+1, you have to put n+1 as one of your destinations. If you want that instruction to always continue to the next one, you could put that destination as destination 0, then use the 'false' condition to always select that. (On the RG2, unconditional branching involved entering the same address as both destination 0 and 1. That way, it didn't matter if the ALU said 0 or 5. You can still do that on the RG3.) (As an aside, since every line can specifies what follows it, you could write nearly the entire program backwards. Have it start at line 60, then do 59, 58 etc. etc. Of course, the machine starts up reading line 1, but that's the only exception to put you at that end of the program ROM).
As you mentioned, there aren't many example programs. I wrote this multiplication program for the RG2, which should look mildly similar to RG3 code. Also, I'm not sure this actually works properly. (although note, the different sections of the instructions may be differently ordered):
@ROM1 contains "1"
@Rom2 contains "0"
@Take Input:
Switch1:ram1:UserInput:NoAction:Unlit:GPU:line1:line2
Nowhere:ram2:UserInput:NoAction:Lit:GPU:line3:line3
Nowhere:ram3:ROM1:NoAction:Unlit:GPU:line4:line4
Nowhere:ram4:ROM2:NoAction:Unlit:GPU:line5:line5
@if (ram3 - ram2 > 0) or ram3 > ram 2, break loop (loop condition)
Nowhere:ALUinA:ram3:NoAction:Unlit:GPU:line6:line6
ALUFalse:ALUinB:ram2:Subtract:NoInvert:ALU:line7:line13
@else if (ram2 AND ram3 != 0) add ram1 to ram 4
ALUFalse:ram1:ram1:AND:NoInvert:ALU:line11:line8
Nowhere:ALUinB:ram4:NoAction:Unlit:GPU:line9:line9
Nowhere:ALUinA:ram1:Add:NoInvert:ALU:line10:line10
Nowhere:ram4:ALUAnswer:NoAction:Unlit:GPU:line11:line11
@then (always) shift ram1 and ram 3 to the more significant side.
Nowhere:ALUinA:ram1:Shift:NoInvert:ALU:line12:line12
Nowhere:ALUinA:ram3:Shift:NoInvert:ALU:line5:line5
@End of loop; Output ram4.
Nowhere:NumScreen:ram4:DisplayNum:Unlit:GPU:Shutdown:Shutdown
If you're actually interested in programming for this, you may have to do it manually.
Dudearent wrote part of an advanced assembler / compiler for this, but he never released it. I was trying to write a compiler for this computer's predecessor, tho I never finished that. I'd planned on also porting it over to this, with an assembler, port of the same compiler and lightweight dev environment... And for that matter modify my output system so you could write programs directly to the world instead of placing torches by hand. None of that, however, happened. I have two (working) assemblers for the older computer, but I doubt that'll be of help to you. Fallensnow also wrote a (working) combined assembler / emulator, for the old computer. That'll be about as useful to you.
I suppose most of the anger on the RDF is just a result of your fame. Although of course fame isn't wrong.
I believe I said, in the discussion that went on in the RG 1 thread, you are still very talented with redstone. Moreso than most people. Much more than me (as if I were good at it). (And that's not even mentioning L-OS) That's not belittled by the existence of a few more talented people, and the RG 3 is still a good computer in spite of the existence of faster ones. It's sad to see all of this happen over petty anger.
I suppose, now that the RedGame is for all intents and purposes historical, now is as good a time as any to say that my compiler has at least been quite interesting for me. It was supposed to be a quick and simple project, and I hoped you'd see it running on your computer. Well, there's still the chance I'll be able to make something out of it. Maybe I could port it over to the DCPU (for 0x10c), now that I'm starting to get into that.
That's an impressive feat in itself! I don't think anyone else has actually extended this computer before. Could you post some pics of the construction mechanism? Can it build any impressive circuits? Arbitrary circuits?
...I have a partly written / partly working compiler for this computer, the one I was talking about earlier on this page. If you've actually gotten this to work tho, you've done a whole lot more with this computer than I have
I'll see if I can find a big enough magnet to pull Dude back into this thread
I don't really want to bring a programming question into this thread, but it's still somewhat related to MCEdit...
My program is supposed to generate .schematic files containing Redstone ROMs, as a way to export programs to Redstone computers. I'm using the JNBT library. (I've posted about my program here before... Yes, I still can't get it to work XD )
Basically every time I try to load one of my schematics into MCEdit, I get an error saying that the Entities tag is invalid. The Entity tag and the Tile_Entity tag should both be empty. Here's how I'm generating that tag (and the other tags):
static void Schematic (Schematic.Structure data, String destination)
{
ShortTag width = new ShortTag ("Width", data.width);
ShortTag length = new ShortTag ("Length", data.length);
ShortTag height = new ShortTag ("Height", data.height);
StringTag materials = new StringTag ("Materials", "Alpha");
ByteArrayTag blocks = new ByteArrayTag ("Blocks", data.ID);
ByteArrayTag block_data = new ByteArrayTag ("Data", data.block_data);
HashMap<String,Tag> ent = new HashMap<String,Tag>();
CompoundTag entity_set = new CompoundTag ("Entities", ent);
List<Tag> set = new ArrayList<Tag>();
set.add(entity_set);
//Simnik's Redstone Simulator defines empty entity lists as {10, 0, 0, 0, 0}
ListTag entities = new ListTag ("Entities", CompoundTag.class, set);
ListTag tile_entities = new ListTag ("TileEntities", CompoundTag.class, set); //Should expand to include signs.
//Create a HashMap describing the schematic.
HashMap<String,Tag> compound = new HashMap<String,Tag>();
compound.put("Width", width);
compound.put("Length", length);
compound.put("Height", height);
compound.put("Materials", materials);
compound.put("Blocks", blocks);
compound.put("Data", block_data);
compound.put("Entities", entities);
compound.put("TileEntities", tile_entities);
CompoundTag structure = new CompoundTag ("Schematic", compound);
Is that the wrong way to store zero entities in the tag? Is it an invalid NBT tag all together? Is this JNBT specific?
...The other issues I'm having with schematics is that many of them (two of the three sample schematics it currently generates) show up as nothing but air in MCEdit, while I define several non-air blocks to the schematic. One of them does have the correct blocks appear, but in mangled positions. Those are either bugs in my code... Or I'm just not getting something about the format I'm supposed to be using. MCEdit itself is probably fine here, seeing how many other programs can export to it.
I just had a look back through the Redgame 2 thread. Spotted dude's original assembly syntax, and Zeemvel's post. He asked that compiler writers keep compilers for the platform modular and portable, so they could be run on linux... That point went straight over my head for the first few months. But... my compiler is shaping up to be a standalone Jar file that converts BoxCode text into assembly text. No GUI involved, no literal dependencies other than Java 6. Although you need an assembler. And you need Java 6 anyway to run Minecraft. So I think the BoxCode compiler is sufficiently portable to anything, just as long as my eventual GUI for the thing is in a separate package, and the compiler doesn't depend on it.
On the assembler for this computer, what if I hid the ALU registers and presented operations as [RAM] = [RAM] [operator] [RAM] ? Like... $2 = $5 + $3 to sum Ram 5 and 3, and save the result to 2?
-On that train of thought, How about a statement like that with no further information follows unconditionally to the next line?
-For statements that do some sort of branching, could we follow the above expression with something like |condition ?
:label
$2 = $5 + $3 |> label
To do that operation, then branch to "label" if $5 > $3 ?
-I only presented a conditional branch to one label there... But this computer can branch to two different destinations. I'll just say the above statement branches to the label only if that condition succeeds, and goes to the next line otherwise. But how should we list two labels?
-I suppose you could do user defined functions with a special syntax like {0000000000} for a user-defined operator that does regular-old addition. Similarly to that, you could define entire command lines like that, by writing the entire thing in {}'s.
-nop "No operation" could be a keyword for a command that does nothing, if you need a delay at some point.
This is hopefully a simple question; How do I import an existing MC install as an instance? Or otherwise, how do I get MCNostalgia to work with an instance? Last time I tried to use MCNostalgia (or what ever it's called) it only saw my regular Minecraft install in AppData. I couldn't use it to make a new instance of an old version of Minecraft.
It'd be awesome if I could import a regular install as an instance, then I could install mods normally without getting tripped up in MultiMC's mod installer system.
BTW, I've actually been using MultiMC since this thread was 8 pages long.
PS. The mod I had issues with installing was SPC. It doesn't use Modloader... I think I've tried it twice (in two fresh instances) one with the mod's jar in the mod folder, the other time modifying MC's own jar according to SPC's instructions (completely avoiding the mods folder). Both instances crashed on startup. I need an instance of an older MC version so I can run ComputerCraft and RedPower... Neither one works with MC 1.3 currently. Although I do have a MC 1.1 instance I've cloned a few times.
0
Interesting... To both Codebreadpudding and RedstoneWithoutLimits, I'm pleasantly surprised somebody else has thought of building this
I've built two different clocks of this style before, the first being in 2011. I've hardly been around the forums tho, so I missed both of these threads. (Gave up after the lack of response to my second clock)
2016: New Variable Frequency Clock
2011: Old Variable Frequency Clock
Also this makes... At the very least 4 people independently finding this idea... Tho I have no idea if anybody built any between 2012 and 2015. At the very least Roboticaust built one after seeing mine, and somebody had built a variable timer (but not a clock) well before my first one. First clock I know of of this kind was the one Murtdragon showed in my older thread.
Which brings me to another point: there are a couple different styles for building clocks of this kind:
-Selecting clocks. Roboticaust's version had 4 different 1-wide clocks, and a decoder to pick the appropriate one. Fairly compact for low speeds, but limited options available.
-Enabling or disabling timer circuits. Both of my clocks, and Murtdragon's clock used this. It enables quite a range of frequencies, because you can have multiple timers enabled or disabled in parallel, and get lots of combinations out of only a few timers. All three clocks I know of that did this had timers with power-of-two times: 1-tick 2-tick 4-tick etc. etc. So you could enter a precise number of ticks whenever you wanted. I used a different style from Murtdragon: In my clocks, there is a base 2-tick clock with branches off of it. If you want to change speeds, you have to turn the clock off, and then turn the timers on or off. Otherwise, you might split a signal in half and have things go wonky. In Murtdragon's design, the clock checks its input every cycle when the signal gets to the base section of the clock, and only toggles the timers here. It can easily change speeds while its running, but that circuitry meant it had a minimum period of several ticks.
-Have a counter go between two spots. I don't think I've seen this one built, but theoretically it allows extremely high clock periods (say, entire dispensers full of items, possibly with a period multiplier). The downside, is that the granularity that periods can be set to is limited by how long it takes to move one count (an item, or a number between two registers, etc) two ways. I would guess this would cover the very high end of the spectrum of long period clocks, but be of limited precision.
Looking at both of the above clocks, I'm not quite sure what kinds I'm looking at... Is RedstoneWithoutLimits' clock multiple different clocks, with a selector between them? It looks a bit like that, seeing as the video only has the first or the third running; The three options may be mutually exclusive. Is that correct?
And CodeBreadPudding's clock... has a signal of a specific strength going to a comparator for input. Does that clock store a signal strength, as starting point for pulser fader clocks? Or is the signal strength controlling locked repeaters to enable / disable timers? I'm not quite sure what to make of using a signal strength for input.
(I suppose I can build both of these in the game myself to see.)
0
Well, there's several ways in general to switch a clock between different speeds, although probably all of them need more space than that one. So, the best way (or any possible way) to go about this kinda depends on how much room is available around there for it. One of the more understandable ways to do a varying speed clock is what zetlandsveryown said: Swap between two. Especially if you only need two options to toggle on a button. I think Roboticaust's old channel has a video demoing this from way back when. Also, I can point out one really general technique, as demo'd by my build (now on the second page of this forum): For lack of better terminology, enable and disable a delay slot along the wire. Basically, you could have a piston moving a block back and forth, connecting one 'path' along the wire when retracted and connecting the other when extended. You could use that to swap between 5 ticks worth of repeaters and 20 ticks, have all the repeaters on one side and 0 repeaters on the other side (so the delay purely adds time) or what have you. For a more complicated requirement, you could connect 1, 2, 4 etc. tick side tracks that can each turn on and off independently, so you can get any number accurate to 1 tick just by changing the settings. But for something like this, you could just have a... 6 tick delay on one part of the track, and then go through or skip the other part of the track (for the remainder of the time) with the toggle. I prefer to put the toggle on the input to a track, so you don't have the side track constantly activating when it isn't in use, tho with it on the input you may need to watch that the side track doesn't loop on its own and skip the first part.
If you want one side to be as short as the 6 ticks shown here, then for just about any side clock it might consume less space to use an entirely separate clock for the other speed. Tho most of the size required for a two clock system would be the TFF and toggle anyways, so it might save space to enable and disable a side track like that.
Not sure if this helps, since I don't really know how much space you have to work with.
0
That's odd, it's (still) up for me. I've set the first picture to show inline, not sure how to embed an image gallery tho.
The gallery includes various sections of the clock, and my other attempt at explaining how everything works.
0
I've built a clock (oscillator) that can run at nearly any frequency you want. You could use this for any kind of machine that needs to operate at different speeds in different circumstances. Say, a music player that can change tempo, or a lighting system. Or, since each part has a known / measurable speed, you could use this to get very specific timings that would be difficult to do with repeaters, and would take too long to test with a custom-built circuit. It can be set to any speed from 2 ticks, up through 8193 ticks, with a resolution of 1 tick. (Usage note: What ever speed the device is set to, as a binary number, it will run 2 ticks slower than that.)
Front view:
How it works: This is, at its core, a repeater clock. There's a vertical track running the full width of the device, with two repeaters. This gives it the minimum 2-tick speed: These two repeaters with nothing but wire between them. Along the entire track are delay circuits/timers. By default, these are disconnected from the main loop. When enabled, the track in front of them is blocked, and the signal passes through the timer instead, adding the corresponding number of ticks delay to that 2-clock on the main track. It has a separate circuit (and switch) for each power of two, giving it an input as a binary number of ticks. Since the device can operate as a 2-clock (1 on, 1 off), we have to start it with a 1-tick pulse. This gets stretched out to 2-4 tick long on-pulses by most of the timers.
The shorter timers are repeater tracks. These are all the timers on the bottom half of the main track. The top of the track has the longer timers, ranging from 64 to 4096 ticks. These are all variations on the same circuit. They use a 16-clock to drive a dropper-dropper counter through N items, twice. So these timers count down 32 ticks for every item in the droppers, plus a 32 tick start-stop time so we can easily do multiples of 64 ticks. Each of them is 3 wide, and 4 tileable. Inputs are two tileable, and connected in pairs to two timers, one above the other.
Image gallery of the project overall:
http://imgur.com/a/gyNcW
This is version two of a (way) older project of mine, way back in 2011(!)
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/334948-variable-frequency-clock-generator
Comparing this one to its predecesor, this one has 13 bits of range, to the old clock's 8 bits. In construction, this one uses a vertical track, so timers fit 2 blocks apart. The old one had timers far more spaced out, on a horizontal track. That said, the old one had a restart circuit, which could automatically shutdown the clock or change its speed with a single button press. To shut down this one... Have fun waiting 7 minutes or so with the off switch enabled. You can shut it down in a few seconds, if none of the longer timers are running.
Schematics:
Overall Clock: https://up1.ca/#hYxK4RX0KrfVUvHLu_Rhjw
Timer, stacked two high: https://up1.ca/#_RksT9w-ikld2uBTfxbX5Q
The single end piece timer: https://up1.ca/#1UcnKPk2oXGtT5cII1cm-Q
Test rig: https://up1.ca/#vWbPCH-U6TfzT0-xJ3_FIw
0
I'm not sure how you'd be getting 32 blocks per bit stored... That octal piston tape held 144 bits, it wasn't that big.
0
So, that I can see this is meant to select the item volume placed in a minecart? That may actually be the most productive use of such a clock. I've thought a few times a variable speed clock could be useful for a music system that ran at various tempos...
How is the delay for adding items controlled? Do input signals add an item to some template chest, and then the output chest is timed by the template chest? All of the previous variable delay timers / variable speed clocks I've seen used repeaters as delay circuits.
...While I'm mentioning previous clocks, here's a shameless plug of my own variable speed clock. Also my first big creation
http://www.minecraftforum.net/topic/821567-variable-frequency-clock-generator/
(Other clocks of this type were made by Murtdragon (posted in that thread, decided on the appropriate clock delay every cycle), Roboticaust (posted on Youtube, toggled between 4 normal clocks. Referenced my clock in his video
0
...At the most basic level, every instruction does two things (where assembly on a normal RISC machine only specifies one) A logical operation on data, and a branch.
-Logical operations are similar to operators in higher level languages. You specify one or two values, an operation to do on them and take back some result. Operations are done by an ALU (arithmetic logic unit, as all computers have). You use the ALU by loading in values from two 'registers', selecting an ALU operation, and then saving the result back to a 'register'. Registers, now that I've mentioned them, are your general purpose memory. They are also the only memory you can save data to, unless a memory unit was added to the computer using DPI. The RG3 has 16 of them. Treat them as poorly named variables. You can load in two registers to the ALU, and perform your operation on them in the same command. This is where I may be a little inaccurate, as I've only used the RG2. There, we would load in one register to ALU input 1, then an other to ALU input 2, and do our operation. Then on the third cycle read from ALU output back to one of our registers. The RG3 does both reads to the ALU in one cycle, as well as the operation. Then the next cycle you still specify that you'll read from the ALU and write back to one of your registers.
-The branching system is, AFIAK, specific to the RedGame series of computers. Namely, every instruction specifies a condition, and two destination instructions (goto). Conditions basically specify a different selection based data, or what you're currently doing. Think of them as the if-then-else clause in higher level languages. (Indeed, all high level languages from C to Ruby to Lua to Haskell implement if's, and function calls as complicated gotos) The RG3 has conditions for the levers in the user interface, for ALU output being 0, for the two inputs being equal, one that always pics the first destination etc. etc. Your two destinations, in the cheat sheet of Dude's manual, are labeled '0' and '1', if you want to read the entire list of ways you can select a branch.
The branch destinations themselves work sorta like goto [line number] in FORTRAN and some Basics. Every instruction is numbered either from 0 to ~60 or 1 to ~60 (They're 1-based, or counted from 1 on the RG2). Selecting goto 10 will execute line 10. Unlike those two languages (and normal computers) execution does not automatically continue to the next line. If you want instruction n to be followed by instruction n+1, you have to put n+1 as one of your destinations. If you want that instruction to always continue to the next one, you could put that destination as destination 0, then use the 'false' condition to always select that. (On the RG2, unconditional branching involved entering the same address as both destination 0 and 1. That way, it didn't matter if the ALU said 0 or 5. You can still do that on the RG3.) (As an aside, since every line can specifies what follows it, you could write nearly the entire program backwards. Have it start at line 60, then do 59, 58 etc. etc. Of course, the machine starts up reading line 1, but that's the only exception to put you at that end of the program ROM).
As you mentioned, there aren't many example programs. I wrote this multiplication program for the RG2, which should look mildly similar to RG3 code. Also, I'm not sure this actually works properly. (although note, the different sections of the instructions may be differently ordered):
@ROM1 contains "1"
@Rom2 contains "0"
@Take Input:
Switch1:ram1:UserInput:NoAction:Unlit:GPU:line1:line2
Nowhere:ram2:UserInput:NoAction:Lit:GPU:line3:line3
Nowhere:ram3:ROM1:NoAction:Unlit:GPU:line4:line4
Nowhere:ram4:ROM2:NoAction:Unlit:GPU:line5:line5
@if (ram3 - ram2 > 0) or ram3 > ram 2, break loop (loop condition)
Nowhere:ALUinA:ram3:NoAction:Unlit:GPU:line6:line6
ALUFalse:ALUinB:ram2:Subtract:NoInvert:ALU:line7:line13
@else if (ram2 AND ram3 != 0) add ram1 to ram 4
ALUFalse:ram1:ram1:AND:NoInvert:ALU:line11:line8
Nowhere:ALUinB:ram4:NoAction:Unlit:GPU:line9:line9
Nowhere:ALUinA:ram1:Add:NoInvert:ALU:line10:line10
Nowhere:ram4:ALUAnswer:NoAction:Unlit:GPU:line11:line11
@then (always) shift ram1 and ram 3 to the more significant side.
Nowhere:ALUinA:ram1:Shift:NoInvert:ALU:line12:line12
Nowhere:ALUinA:ram3:Shift:NoInvert:ALU:line5:line5
@End of loop; Output ram4.
Nowhere:NumScreen:ram4:DisplayNum:Unlit:GPU:Shutdown:Shutdown
With the following assembly definitions:
@Format Condition:Save:Load:Command:InvertOrIndicate:ALUGPU:IfFalse:IfTrue
@Conditions:
#define RandomBranch 1000
#define RNGEnabled 0100
#define Switch1 0010
#define Switch2 0011
#define Switch3 0000
#define Switch4 0001
#define ALUFalse 0101
#define Nowhere 0111
@ALU:
#define Add 1001
#define Subtract 1010
#define AND 1110
#define OR 1100
#define XOR 1011
#define Implies 1101
#define Shift 1111
@ALU invert Output
#define Invert 1
#define NoInvert 0
@ALU or GPU:
#define ALU 0
#define GPU 1
@GPU:
#define DrawFullRect 0111
#define DrawCorners 0100
#define DrawRows 0101
#define DrawCollumns 0110
#define ClearScreen 1000
#define DisplayNum 1100
#define NoAction 0000
@General Indicator:
#define Lit 1
#define Unlit 0
@Write to Registers:
#define ScreenX1 110110
#define ScreenX2 101110
#define ScreenY1 001110
#define ScreenY2 011110
#define NumScreen 111110
#define ALUinA 100110
#define ALUinB 010110
@Read from Registers:
#define ALUAnswer 100110
#define UserInput 110110
#define Random 010110
#define ROM1 001110
#define ROM2 101110
#define ROM3 011110
#define ROM4 111110
@Program Line:
#define Shutdown 000000
0
Dudearent wrote part of an advanced assembler / compiler for this, but he never released it. I was trying to write a compiler for this computer's predecessor, tho I never finished that. I'd planned on also porting it over to this, with an assembler, port of the same compiler and lightweight dev environment... And for that matter modify my output system so you could write programs directly to the world instead of placing torches by hand. None of that, however, happened. I have two (working) assemblers for the older computer, but I doubt that'll be of help to you. Fallensnow also wrote a (working) combined assembler / emulator, for the old computer. That'll be about as useful to you.
For what it's worth, here are the repositories for the projects of Fallen & I:
https://github.com/F...n0w/RedCompiler
https://github.com/Solarspot/BoxCode
0
I suppose most of the anger on the RDF is just a result of your fame. Although of course fame isn't wrong.
I believe I said, in the discussion that went on in the RG 1 thread, you are still very talented with redstone. Moreso than most people. Much more than me (as if I were good at it). (And that's not even mentioning L-OS) That's not belittled by the existence of a few more talented people, and the RG 3 is still a good computer in spite of the existence of faster ones. It's sad to see all of this happen over petty anger.
I suppose, now that the RedGame is for all intents and purposes historical, now is as good a time as any to say that my compiler has at least been quite interesting for me. It was supposed to be a quick and simple project, and I hoped you'd see it running on your computer. Well, there's still the chance I'll be able to make something out of it. Maybe I could port it over to the DCPU (for 0x10c), now that I'm starting to get into that.
0
That's an impressive feat in itself! I don't think anyone else has actually extended this computer before. Could you post some pics of the construction mechanism? Can it build any impressive circuits? Arbitrary circuits?
...I have a partly written / partly working compiler for this computer, the one I was talking about earlier on this page. If you've actually gotten this to work tho, you've done a whole lot more with this computer than I have
I'll see if I can find a big enough magnet to pull Dude back into this thread
1
after three months0
My program is supposed to generate .schematic files containing Redstone ROMs, as a way to export programs to Redstone computers. I'm using the JNBT library. (I've posted about my program here before... Yes, I still can't get it to work XD )
Basically every time I try to load one of my schematics into MCEdit, I get an error saying that the Entities tag is invalid. The Entity tag and the Tile_Entity tag should both be empty. Here's how I'm generating that tag (and the other tags):
static void Schematic (Schematic.Structure data, String destination) { ShortTag width = new ShortTag ("Width", data.width); ShortTag length = new ShortTag ("Length", data.length); ShortTag height = new ShortTag ("Height", data.height); StringTag materials = new StringTag ("Materials", "Alpha"); ByteArrayTag blocks = new ByteArrayTag ("Blocks", data.ID); ByteArrayTag block_data = new ByteArrayTag ("Data", data.block_data); HashMap<String,Tag> ent = new HashMap<String,Tag>(); CompoundTag entity_set = new CompoundTag ("Entities", ent); List<Tag> set = new ArrayList<Tag>(); set.add(entity_set); //Simnik's Redstone Simulator defines empty entity lists as {10, 0, 0, 0, 0} ListTag entities = new ListTag ("Entities", CompoundTag.class, set); ListTag tile_entities = new ListTag ("TileEntities", CompoundTag.class, set); //Should expand to include signs. //Create a HashMap describing the schematic. HashMap<String,Tag> compound = new HashMap<String,Tag>(); compound.put("Width", width); compound.put("Length", length); compound.put("Height", height); compound.put("Materials", materials); compound.put("Blocks", blocks); compound.put("Data", block_data); compound.put("Entities", entities); compound.put("TileEntities", tile_entities); CompoundTag structure = new CompoundTag ("Schematic", compound);Is that the wrong way to store zero entities in the tag? Is it an invalid NBT tag all together? Is this JNBT specific?
...The other issues I'm having with schematics is that many of them (two of the three sample schematics it currently generates) show up as nothing but air in MCEdit, while I define several non-air blocks to the schematic. One of them does have the correct blocks appear, but in mangled positions. Those are either bugs in my code... Or I'm just not getting something about the format I'm supposed to be using. MCEdit itself is probably fine here, seeing how many other programs can export to it.
0
On the assembler for this computer, what if I hid the ALU registers and presented operations as [RAM] = [RAM] [operator] [RAM] ? Like... $2 = $5 + $3 to sum Ram 5 and 3, and save the result to 2?
-On that train of thought, How about a statement like that with no further information follows unconditionally to the next line?
-For statements that do some sort of branching, could we follow the above expression with something like |condition ?
To do that operation, then branch to "label" if $5 > $3 ?
-I only presented a conditional branch to one label there... But this computer can branch to two different destinations. I'll just say the above statement branches to the label only if that condition succeeds, and goes to the next line otherwise. But how should we list two labels?
-I suppose you could do user defined functions with a special syntax like {0000000000} for a user-defined operator that does regular-old addition. Similarly to that, you could define entire command lines like that, by writing the entire thing in {}'s.
-nop "No operation" could be a keyword for a command that does nothing, if you need a delay at some point.
0
0
It'd be awesome if I could import a regular install as an instance, then I could install mods normally without getting tripped up in MultiMC's mod installer system.
BTW, I've actually been using MultiMC since this thread was 8 pages long.
PS. The mod I had issues with installing was SPC. It doesn't use Modloader... I think I've tried it twice (in two fresh instances) one with the mod's jar in the mod folder, the other time modifying MC's own jar according to SPC's instructions (completely avoiding the mods folder). Both instances crashed on startup. I need an instance of an older MC version so I can run ComputerCraft and RedPower... Neither one works with MC 1.3 currently. Although I do have a MC 1.1 instance I've cloned a few times.