impressed with what youve done so far, thought this kinda project would only be successful on the pc version, you get this done it will be testament to how good the 360 really is...
great job !!
I am pretty proud of the fact it will be one of the most powerful redstone computers ever built. If I had to guess, there have been maybe 200 - 300 computers built in Minecraft. I'm fairly confident in saying this would be in the top 10%. Although, at that point, the top echelon of machines start to become ridiculous.
And I'm only judging by features, ALU power, and ease of use. Basically, it will be one of the "fanciest" computers out there. Everything is designed with the average user in mind. With a short tutorial, lasting maybe 30 minutes, literally anyone will be able to write a functional program. It may be an extremely basic program, but they will be able to write one, as opposed to someone having to know the CPU in and out to program it efficiently.
Building a machine that's as easy to use as a modern computer is physically impossible through redstone. At this point, a BIOS, or even dedicated OS is impossible, (as far as I know) and would be very inefficient.
In terms of versatility, my system would not rank as highly. Eventually, I want to build a Turing complete machine, but that's not going to happen with this project. As for the instruction set, that's not going to be as optimized as I would like for it to be. That's the only part that's not going to be very user-friendly. But at this point, it's necessary for the ALU functions to work correctly.
I don't think it will, but it's definitely going to cause some massive framerate drops. I'm hoping the flatland will take a lot of the strain off of the console's hardware. Either way, I'm sure it will lag some people out of the game, even the old CPU could do that. And it could only handle 1.3% of the work that the new processor can accomplish.
it's definitely going to cause some massive framerate drops. I'm hoping the flatland will take a lot of the strain off of the console's hardware. Either way, I'm sure it will lag some people out of the game, even the old CPU could do that. And it could only handle 1.3% of the work that the new processor can accomplish.
I'm having visions of the de-neurolizer scene from Men in Black II (or more appropriately, EVERY east coast black-out joke ever pulled in a movie).
I've been following your progress with interest, and just want to say its an awesome project your developing. very impressed with the progress so far.
I have a little experiance with ASM programming and theres a couple of useful functions that seem to be missing, im not sure if your planning to implement them via software, or you just havn't included them in the posts so far.
BSF
BCF I know you can workaround these two by using several OR/AND opperations but would require several CPU cycles
NOP, CLRF, CLRW I know you havn't build your general purpose registers /special registers yet so the file and accumulator stuff doesnt apply, and essentialy these are just a movlw 0x00 command.
INCF/W and DECF/W again you can work around by using MOVLW 0x01; ADDWF f,1; but with 2 cpu cycles instead of one.
most of these i've posted will only save you 1 cpu cycle per opperation although the BSF, BCF would save several more.
however more importantly I hope you've remembered to set your C,DC, and Z bits as without the Z bit you cant use
BTFSC f,d or BTFSS f,d which are usually used in loops/delays and to test equality. I know you've mentioned that your ALU can evaluate (x > y, x =y and x < y). I have no idea how you designed that section but usually in my experiance the Z bit is used at ASM level to evaluate equality.
also you'll need to have at least the C bit set so you can keep track and deal with bit overflows. ie RLF d'128,0 will put 0 in the accumulator when the actual result is 256. so to let the ALU know theres been an overflow you would need to check the C bit.
at any rate, the work you've done so far is just awesome, and the only reason im posting this is because I have a little experiance in ASM and I would hate for you to have to go back and redesign things at the end just because you missed a little detail.
if you already know all this then just ignore me
First and foremost, I would like to thank you for the criticism. It's something I don't have the pleasure of seeing too often. I'm very amateur when it comes to programming, so feel free to correct me at any time. I mostly build these things to increase my own knowledge in computer science and find ways to make redstone behave like real-life circuitry. As a result, I don't tend to focus on programming as much as I should, and my instruction sets tend to be a bit... awkward.
My CPU (like most redstone CPUs) uses an RISC-based instruction set, with some differences. Commands are extremely low-level, meaning no specific instruction does more than one operation at a time. Writing to and reading from memory is done with separate commands from the rest of the machine. Even the ALU has a few functions outside of its own instruction decoder. (Or it will rather, the decoder for it hasn't been built yet.) That way, I can perform a logical or algebraic function, and shift the result in the same operation. Or I could (x + NOT y = NOT z) to perform subtraction in the same cycle, without adding an extra function for SUB. The general purpose registers will contain 16 locations of 16-bit RAM registers, each cell will have dual-read technology. Thanks to dual-read cells, I will have two reading buses, and I can write two operands to the ALU's input registers in a single clock cycle, instead of two.
What I'm saying is the design of this CPU is very specialized and a lot of typical functions become useless or redundant because of it. Like I said, I'm not a programmer, so please correct me on the usefulness of these commands when I inevitably get out of line.
BCF/BSF:
Adding something like this would be useful at times, but it would require expanding the instruction set by another 6 bits. Not to mention, the registers would be a nightmare to construct. First, a word would have to be addressed, then a bit within that word would be selected, to be cleared or set as a 1. Something like this just isn't practical or efficient in redstone engineering. My general purpose registers will be able to do one of two things, clear a location, or write to a location from the writing bus, which can contain data from either UI ROM or the ALU's output.
NOP:
From what I understand, this is any operation that doesn't effect any registers. Mostly used as a time waster or a placeholder. Like I said, my program memory reads extremely low-level operations. So, there are many ways I could write a NOP code, I would just need to not write to any registers.
CLRF/CLRW:
I already have plans for an instruction that basically does this. It will block all inputs to the RAM cells from the writing bus, then write to the location I wish to clear. It will actually be a combination of two instructions, but it can still be done in a single clock cycle.
INCF/DECF:
In a redstone CPU, I'm pretty sure this is impossible to accomplish in a single clock cycle. And if it is possible, it requires some fancy RAM with built-in adders. I can do this in two lines of code though. In fact, my usual demo program is a simple counter that increments by one every two clock cycles. In the new CPU, I'll be able to theoretically increment by 1 multiple times in a single cycle by using a special-purpose "shortcut" register. I suppose this could be considered a hack, but I thought it would be kind of a fun idea to attempt.
I'm assuming by C, DC, and Z you're referring to flag registers. I will have a Zero flag, I have previously used this before for conditional branching when a program required user input to continue. If there are more uses for this, I would love to hear them. Like I said, I'm a beginner when it comes to programming, so I would love to learn some more tricks of the trade. Anyway, a Carry flag isn't happening for the same reason BCF/BSF functions aren't happening. A flag for C would be wayyyyyy more trouble than it's worth. It's probably possible, but it's definitely beyond my understanding of redstone at the moment. I will have an Overflow flag as well, which will simply show up in the UI as an error. I could also have this terminate the program, but it's not really necessary for all the extra work involved. I will probably just have it log the error through an SR latch and display the line of program memory in which the error occurred. Then the user can go observe the area of opcode and determine what caused the issue. By the way, what is a DC bit?
BTFSC/BTFSS:
Once again, operations that effect individual bits are just a bit too complex for redstone. Including bit testing operations like this would make branching a nightmare. Although, the way my comparative functions work is similar to how it would work in assembly (or any) language. My ALU compares inputs internally, through a comparator. A > B (or x > y, whatever the kids are calling it these days) detection is done through a modified XOR gate, which simply means removing the OR gate at the end, making it an XOR with two outputs. Not sure what it would actually be called, but it works very well. From this point on, I will call the inputs of this XOR A and B, the outputs will be X and Y, just to keep things simple. When A=1, B=0, then X=1, Y=0. When X=1, NOT gates are used to force all Y outputs of less significant bits to output 0, so you don't end up with mixed results and possible errors. A < B detection works in the same way, but in reverse. When A=1, B=1, then X=0, Y=0, thanks to the AND gate in the XOR gate. This means both flags, (for A > B aswell as A < B detection) are returning false, 0's. If A isn't greater than B, and B isn't greater than A, that only leaves one more option, A = B. That means adding the detection for this is as simple as an inverted input AND gate. (CON-AND?) Now, when outputs for both A > B and A < B are 0, then A = B will be a 1.
As for overflow detection, I mentioned I had a flag for that, which I called O. From what I understand, C is more of a scratch space for when a value exceeds the size of the ALU and registers. Of course, I may be completely wrong, please correct me if I am. By the way, this ALU handles 16-bit words, so that 9th bit isn't a problem. Overflow issues will only arise once a program exceeds a representation of 65,535.
Once again, I thank you for the criticism and look forward to you correcting the mistakes I inevitably made in this post. Your suggestions are all great, it's just that computer science becomes a lot more complicated in redstone. It's a power source that's not as flexible as electricity, and you have to find work-arounds to make things operate properly. Because of this, redstone components tend to be a lot more complex than their real-life counterparts. The CPUs I and other redstone engineers build are very basic when compared to that itty bitty chip in your computer. Modern CPUs are simply not possible as redstone performs today, at least I don't think so. If it is, it hasn't been done yet, and it would be extremely slow and probably the size of 15 football fields, arranged 15 x 3.
I defiantly have far more knowledge from a programming point of view than electronics, so I'm essentially looking at this from the opposite angle you are, I know how CPU's work from a programming point of view and what instructions I would need available to me. However from an electronics standpoint i'm pretty much clueless, and then factor in the redstone logic and im well out of my depth.
Yeah, it's definitely interesting trying to think about it from your perspective. We're essentially the yin and yang of computer science. I've learned tidbits of assembly language, and I understand what the commands do. I just don't think like a programmer, I don't know how to use them effectively.
Plus I'm always always learning from the hardware side of things, and usually reinterpreting through redstone. I've barely scratched the surface of programming with a modern CPU. I've written more programs on a redstone CPU, where I don't have the convenience of any high-level language. Everything is done in stripped down machine code, pure 1's and 0's.
Most instruction sets in redstone CPU's are completely custom and you will probably never see another one exactly like it. Some like to copy HACK or MIPS architecture, but the majority are completely original. I'm going for a user friendly build this time around, with a GPU, printer, ethernet, (will be implemented into a full LAN) and some other fancy stuffs. Because of this, I had to make some sacrifices in the optimization of my architecture and instruction set.
BCF/BSF: I actually thought that would be quite simple to have, shows how much I know about electronics from your explanation defiantly sounds easier to just implement it at software: ie BSF file,7; would be exactly the same as MOVF file,w; IORLW 0x80; MOVWF file
all I know is that in standard cpu's I can use BSF to do the job in less cps cycles, like INCF and DECF I was surprised at their absence because I don't really understand the electronics or redstone side of things enough.
While it would be possible, it would be a huge pain and add a lot of weight. Definitely easier through software, though it will take an extra cycle. To set a specific bit in a register, first you would need to read it, and an input from the UI alongside it. UI uses ROM lines, which are manipulated through levers, the bit to set would be a 1, the rest 0's. This new value would be saved to one ALU input register, while clearing the other. Then, the data could be OR'd, XOR'ed, or even added, doesn't matter as long as the function's truth table says x=1 y=0 z=1, the output must reflect a single input when the opposite is 0. Then you can write the ALU output to the original register.
It sounds like a long process when explained in the terms of what actually happens, but it would only take 2 clock cycles. I just wanted to provide details to explain the differences and the limitations my CPU will have.
To clear a specific bit, it would be a much similar process. In fact, the only difference is the user input, designating the bit to clear must be in one ALU input register, and the original data in the other. That and you must XOR the data, no alternative functions will give you the result you're looking for. You could also AND with all bits set high except the one you want to clear, but why flip more levers than you need to.
If your going to have a 0 flag anyway it may be worth looking at BTFSC/BTFSS i'll show you a little delay loop using them and NOP. (examples are easier to explain with ^^)
main Prog
blah blah
call delay
blah blah
delay MOVLW 0xFF; // 1 cpu cycle
MOVWF temp; // 1 cpu cycle
MOVLW 1; // 1 cpu cycle
loop NOP; // 1 cpu cycle
SUBFW temp,1; // subtract W from temp and store result in temp - 1 cpu cycle
BTFSS status,Z; // look at the Z bit, skip next line if set - if Z is set then 2 cpu cycles, else 1 CPU cycle
Goto loop; // this is skipped if Z is set - 2 CPU cycles if i remember correctly
RET // can only get here of line above was skipped - 2 CPU cycles
also as you can see the NOP i've added will increase the run time of the delay loop by 255 cpu cycles.
I never even thought about it like that. The only time I've used the Z flag was to sort of "halt" the program if set. I had two sets of GOTO command lines for a 4-bit program counter, attached to 16 bits of program memory. When the ALU output was all 0's, Z bit would return true, enable one set of GOTO commands, while disabling the other. For this set of lines, at a point where user input was required, I would have the line of PROM tell the program counter to go to itself, so it would remain at the same line.
(In redstone, program counters with branching abilities are easier to build using only a binary to unary decoder. The downfall is it's annoying as hell to program. It means every single code needs a GOTO command, even if it's just to continue to the next line. Though a more sophisticated counter can be made with a shift register and attached decoder, to get the best of both worlds. This uses GOTO commands alongside a jump bit.)
The same line also had the condition for if Z returned false, in the second set of GOTO commands. When the user's input reached the ALU's output, the flag would clear and the program would progress as normal with the next clock cycle.
Although your comparison method is very clever, surely if your having a Z status bit anyway it would be easier to just look at the Z bit and skip an instruction (or not as the case may be), or have I completely misunderstood?
I think I just confused myself right now. The way I understand it, the Z flag's state depends only on the ALU's output. My comparator compares the ALU inputs and outputs it's own set of flags for them. (>, <, =) You're talking about essentially comparing data from say, two different registers and doing something with them based on how they compare to each other, correct? I just don't see how the Z bit could possibly help with that if it's based on the output of every bit in the ALU.
Honestly, I'm not even sure what to use these comparative flags for. I designed a comparator awhile back as a small project, then when I started on XENON I thought it would be cool to squeeze it in there. xD Since I did it, I have had an idea to use it in a program for a guessing game. Since 16 bits presents a lot of possibilities, I thought it would be kind of awesome to use the greater than and less than bits as a display to assist the player.
I've built a less fancy roulette-style game before, but it was external and only controlled by the computer. This would be my first attempt at making a software-only game. Which is pretty exciting, and would make a huge statement about how powerful this is for a redstone computer.
A lot of people have made suggestions of games like Pong or Snake, but that's just not going to happen. With a lot of work it would be possible, (and lots of extra hardware, somewhat defeating the purpose) but my god that would be the slowest game you've ever seen in your life. I'm talking about 1 frame/10 seconds, maybe even worse.
Hopefully what I've said makes sense, I'm just trying to provide a little insight from a programming point of view, my electronics knowledge is very basic.
When you say you might not fully understand the usefulness of a command, by the same token I don't understand the difficulty of implementing them.
Also just cant wait to see it in action once its complete.
Oh, it makes sense... sometimes. I'm just the opposite, I understand the basics of what a command actually does. (You kind of have to know at least that much to build a machine like this.) I just don't really know how to use them together to effectively produce software that's remotely useful. If only there was some way we could splice our brains together. xD
I do appreciate your input though. It's very interesting to compare the abilities of the modern CPU to my own architecture. It helps to see the flaws in it and how that has effected my instruction set. I already have the CPU itself and general RAM planned out to specifics, so I won't try applying any fandangled space-age technology to this build. But I'm definitely taking these ideas to heart. You've inspired me to try and really take my next CPU to a higher level, no matter how slow it may become as a result.
I'd like to take a good look at this if possible. Also. I could record if you would want to when the finish product is done.
Certainly! You can record it if you want, your channel probably won't be the only one to have a video of it though. And it won't be done for quite awhile, at least a month from now.
Ah, well that will be easy, just make sure you use 10-bit tapes. You'll also need to find out how fast of a clock you'll need for the initial section. A Minecraft day takes 20 minutes if I remember correctly, so that should help. And keep in mind MCXBLA has issues with redstone timing. Things tend to be off by a tick every once in awhile, so the clock won't be completely accurate.
I learned how to make combo locks and retractable workbenches. All from tutorials though. The tutorials for actual creations help me more than the redstone tutorials themselves do. I'm making progress in my understanding of redstone! =PPP
I'm not sure when instruction sets modern processors have, but i've never come accross > or < flags, so i've always implemented them at software. Does your comparator run after every instruction and if so does it make your CPU any slower especially on instructions where its not needed? As its a really handy function to have (saves me time with programming) but is it CPU friendly?
In a way no, but overall, yes. My ALU processes everything possible outcome through parallel logic. When values enter the ALU, it does everything all at once, so whatever operation you need is already there. It's just a matter of enabling the correct output to sort of "release" that information. Whenever two values come into the ALU they're automatically compared, the flags will simply be ignored unless I choose to use them.
It will be much faster than applying the same thing through software, but it does have one major flow. From the MSB, if only A is set, it takes a total of 36 ticks to negate all lesser B outputs. So, if you have a 1 in B of the LSB, and write a 1 to the MSB's input A, both the A > B, and the A < B flags will be set for about 32 ticks. Normally, this would cause major issues and slow my clock down tremendously, but I have a work around. The program counter will have a togglable clock. It will be able to adjust its own speed, based on a set of instructions in the program memory. So the CPU will be pretty fast, except when an instruction depends on an IF statement regarding A > B.
I'll show you a little demo of how I would approach <,>,= comparisons in ASM as a programmer.
is A > B, A < B, A = B
MOVF B,0 // move B to accumulator
SUBWF A,0 // Subrtact accumulator from A and store in Accumulator
BTFSC status,Z // look at the Zero status bit and Skip next line if its clear
goto result_A_IS_=_B
BTFSC status, C //look at the Carry status bit and Skip next line if its clear
goto result_A_IS_>_B
goto result_A_IS_<_B
Im assuming here that your ALU does subtraction by 2's compliment. If you work out an example by hand you'll see that the Carry bit is set when A > B during the addition in the last stage. Usually the carry bit causes more problems than it solves, if its been set and you do any shifting left or right it'll move into your address space. Always having to remember to clear it
Oh yeah, it's much faster to implement through hardware, as numbers can be compared in a single cycle. It seems modern CPU's don't usually come with a built-in comparator, as you said, frankly I'm surprised they don't. It's actually fairly common to see them built into redstone ALU's.
As a side note, I believe what you call the accumulator would, in essence, be the same thing I've been calling input registers. I think I'll start calling them accumulator registers, as that does make more sense. They save information which is then delivered to the ALU's input accumulator, then branched to all of the internal functions of the ALU.
Also I saw you saying you had worked on a redstone HDD, so building and saving librarys should be possible too? you know for frequently used functions implemented at software level. You'll find when programming you'll frequently need the same set of commands, although linking librarys is another topic in itself
I did, I did, but... it's not an HDD in the way you would think of one. =/ It's a ROM HDD, so you can't actually write data to it without manually breaking and replacing blocks. To load a set of commands into an existing program with this method would be very complicated. Once again, I think that's an idea I'll save for a later build.
The design has some bugs, particularly in how indexing and seeking function. That particular mechanism will be redesigned, but a ROM model is all I really need. It will be used to save whole programs that will be used frequently. When read from, they will completely overwrite anything stored in program memory. Writable HDDs have been built in the past though, so they're definitely possible. Some people even use them as program memory, which is something that definitely doesn't happen in a modern CPU. I personally don't like to do this because they're slow and branching is a nightmare. In real life, and HDD is more compact compared to an SSD, but much much slower. The exact same is true in the world of redstone.
Yes, the comparisson flags will be really useful, if you get a little more into programming you'll see without comparisons your severerly limited with what your program can do automatically. However saying that, the way you've build you comparator is in no way worse to my experiance using C,DC and Z flags, just different. (if it requires less CPU time then its better )
Also running a fully software emulated game on your computer would be the ultimate test. In respect to proving its a fully functional computer in its own right. Plus bonus points for awesomeness (playing you guessing game through like 3 virtual machienes/emulators)
all running on limited xbox harware:p
Yeah, I like the thought of emulating software, on hardware that's being emulated by software, (Minecraft) which is running on hardware. (Xbox 360) That exact idea is what got me into redstone engineering and Redstone Theory. When you think about it, it's just truly mind-boggling how powerful this small set of items can be. And to most players, it's just a small portion of the game!
I think I'm going to start getting more into programming now. It would definitely help me understand what would be useful in future redstone endeavors. Do you know of any good ASM books or videos, even YouTube tutorials?
I learned how to make combo locks and retractable workbenches. All from tutorials though. The tutorials for actual creations help me more than the redstone tutorials themselves do. I'm making progress in my understanding of redstone! =PPP
Nice! What kind of locks?
Also, building tutorials are a horrible way to learn redstone. I got to where I am today by avoiding these kind of tutorials as much as possible. I'm going to quote some advice I gave a player yesterday. I think it's relevant, and hopefully you will find it useful.
Block by block tutorials are the absolute worst way to learn the how's and why's of redstone. Start with the two videos below, then build the things you've done before, from scratch, without a tutorial, and making up your own designs. Start with something simple, like logic gates, use only the truth tables for them. Make several designs for each gate, learn how redstone can be manipulated in several ways to achieve the same effect.
Once you have a good grasp on this, slowly work your way up to the intermediate stuff. Use logic diagrams to understand how mechanisms work, start with the easy things like latches, binary to unary decoders, half adders, etc. Build an initial model with the logic spread out, so you can see and understand how it works. Then rebuild the design, practice making it faster and more compact. Then you can proceed to things slightly more complex, like full adders and flip flops, and repeat the process. Even if these things aren't practical to what you want to build, practicing with them will greatly increase your knowledge with redstone, far more than most tutorials ever will.
Also, building tutorials are a horrible way to learn redstone. I got to where I am today by avoiding these kind of tutorials as much as possible. I'm going to quote some advice I gave a player yesterday. I think it's relevant, and hopefully you will find it useful.
The locks are 9 digit and 4 digit button locks with decoders and RSNOR Latch arrays. I somewhat understand each individual part, but not to the fullest. I've planned out my next few days or weeks, however long it will take to complete this.
-Watch those 2 videos you just listed until both are understanded, taking breaks and experimenting if need be
-Come back to my xbox and experiment with different logic gates
-Develop an understanding for most (if not all) of the logic gates and learn the different ways of building and using them, both together and separately
-Begin redesigning some popular redstone mechanisms WITHOUT tutorials
Once I start understanding everything better, I think my first real project will be a command center for anything in my world that will be powered by redstone. I plan on making a large village / community world with my friends on survival, and I've always imagined having a command center and redstone wiring going all across the world on large poles. Almost like the real world, but instead of telephone poles I'd call them repeater poles. =P
Well you my friend are some sort of Demi God at minecraft, Building a computer on a computer. It's Mineception at it's finest. Best of luck with your project and I will continue on making Wooden Bridges and Buildings =D. Also I'm about to start a project that consists of building the Daft Punk helmets, How would one get the glass part of the helmet to flash in certain areas like LED lights? If that is possible at all.
The locks are 9 digit and 4 digit button locks with decoders and RSNOR Latch arrays. I somewhat understand each individual part, but not to the fullest. I've planned out my next few days or weeks, however long it will take to complete this.
-Watch those 2 videos you just listed until both are understanded, taking breaks and experimenting if need be
-Come back to my xbox and experiment with different logic gates
-Develop an understanding for most (if not all) of the logic gates and learn the different ways of building and using them, both together and separately
-Begin redesigning some popular redstone mechanisms WITHOUT tutorials
Once I start understanding everything better, I think my first real project will be a command center for anything in my world that will be powered by redstone. I plan on making a large village / community world with my friends on survival, and I've always imagined having a command center and redstone wiring going all across the world on large poles. Almost like the real world, but instead of telephone poles I'd call them repeater poles. =P
Wish me luck on my Redstone Crusade!
Sounds good! I wish more people actually wanted to learn about redstone. By the way, one of the guys who was supposed to be helping me out hasn't been on for over a week. I don't really feel like waiting for him, so I think Crininson and I are going to get started soon. You don't have to help with the building if you don't want to, but you can still join in while I'm teaching Crin everything.
Well you my friend are some sort of Demi God at minecraft, Building a computer on a computer. It's Mineception at it's finest. Best of luck with your project and I will continue on making Wooden Bridges and Buildings =D. Also I'm about to start a project that consists of building the Daft Punk helmets, How would one get the glass part of the helmet to flash in certain areas like LED lights? If that is possible at all.
Well, you could do it with block swappers or torches. It would look much nicer with redstone lamps though, so you could always wait for them.
P.S. Thanks to everyone for helping this thread become a hot topic!
Sounds good! I wish more people actually wanted to learn about redstone. By the way, one of the guys who was supposed to be helping me out hasn't been on for over a week. I don't really feel like waiting for him, so I think Crininson and I are going to get started soon. You don't have to help with the building if you don't want to, but you can still join in while I'm teaching Crin everything.
Can't wait. And yeah, the other day, I was there while you were showing off your old computer, I was just stuck in Dishonored "mode" haha.
Can't wait. And yeah, the other day, I was there while you were showing off your old computer, I was just stuck in Dishonored "mode" haha.
Any idea when we can actually get started?
Yeah, random kids often want to see it. One of the downfalls of having someone else record for you, everyone can see your gamertag. I don't mind though, it's fun to show off sometimes.
I'm actually about to get on in a few minutes. If you're on, and up to it, we can get started tonight. Probably not on the actual construction, but you'll at least be up to speed.
Yeah, random kids often want to see it. One of the downfalls of having someone else record for you, everyone can see your gamertag. I don't mind though, it's fun to show off sometimes.
I'm actually about to get on in a few minutes. If you're on, and up to it, we can get started tonight. Probably not on the actual construction, but you'll at least be up to speed.
I'm online right now, but I'm not sure about getting started right now. Perhaps later tonight or tomorrow.
Updated the OP with the official finalized specs. It now has 16 "true" functions, as the comparator will actually be used to output specialized flag registers, more relevant to program memory than processing operations. (They'll mostly be used for branching, in fancy programs.) This also helps everything fit into my completely redesigned instruction-set, which I should be able to post a photo of in a day or two. (Still a W.I.P. at this point.) Not to mention, having a 4-bit decoder with only 12 outputs felt like such a waste. Not sure what I would actually do with these implication functions, but I'm sure a 1337 programmer out there somewhere would find them useful.
ALU (16 functions)
AND
NAND
OR
NOR
XOR
XNOR
IMPLIES (a AND !b)
CON-IMPLIES (!a AND b)
NIMPLIES (a NAND !b)
CON-NIMPLIES (!a NAND b)
NOT
ADD
SUB (a - b)
SUB (b - a)
L. Shift
R. Shift
Official legitness!!!
Also, I feel it is necessary to share the artwork that has been recently made around the project XENON construction site.
Updated the OP with the official finalized specs. It now has 16 "true" functions, as the comparator will actually be used to output specialized flag registers, more relevant to program memory than processing operations. (They'll mostly be used for branching, in fancy programs.) This also helps everything fit into my completely redesigned instruction-set, which I should be able to post a photo of in a day or two. (Still a W.I.P. at this point.) Not to mention, having a 4-bit decoder with only 12 outputs felt like such a waste. Not sure what I would actually do with these implication functions, but I'm sure a 1337 programmer out there somewhere would find them useful.
ALU (16 functions)
AND
NAND
OR
NOR
XOR
XNOR
IMPLIES (a AND !b)
CON-IMPLIES (!a AND b)
NIMPLIES (a NAND !b)
CON-NIMPLIES (!a NAND b)
NOT
ADD
SUB (a - b)
SUB (b - a)
L. Shift
R. Shift
Official legitness!!!
Also, I feel it is necessary to share the artwork that has been recently made around the project XENON construction site.
Oh man, I can't believe you actually posted those. Haha.
I am pretty proud of the fact it will be one of the most powerful redstone computers ever built. If I had to guess, there have been maybe 200 - 300 computers built in Minecraft. I'm fairly confident in saying this would be in the top 10%. Although, at that point, the top echelon of machines start to become ridiculous.
And I'm only judging by features, ALU power, and ease of use. Basically, it will be one of the "fanciest" computers out there. Everything is designed with the average user in mind. With a short tutorial, lasting maybe 30 minutes, literally anyone will be able to write a functional program. It may be an extremely basic program, but they will be able to write one, as opposed to someone having to know the CPU in and out to program it efficiently.
Building a machine that's as easy to use as a modern computer is physically impossible through redstone. At this point, a BIOS, or even dedicated OS is impossible, (as far as I know) and would be very inefficient.
In terms of versatility, my system would not rank as highly. Eventually, I want to build a Turing complete machine, but that's not going to happen with this project. As for the instruction set, that's not going to be as optimized as I would like for it to be. That's the only part that's not going to be very user-friendly. But at this point, it's necessary for the ALU functions to work correctly.
I don't think it will, but it's definitely going to cause some massive framerate drops. I'm hoping the flatland will take a lot of the strain off of the console's hardware. Either way, I'm sure it will lag some people out of the game, even the old CPU could do that. And it could only handle 1.3% of the work that the new processor can accomplish.
I'm having visions of the de-neurolizer scene from Men in Black II (or more appropriately, EVERY east coast black-out joke ever pulled in a movie).
That depends. How are you going to design the clock, and what form of memory will you be using?
First and foremost, I would like to thank you for the criticism. It's something I don't have the pleasure of seeing too often. I'm very amateur when it comes to programming, so feel free to correct me at any time. I mostly build these things to increase my own knowledge in computer science and find ways to make redstone behave like real-life circuitry. As a result, I don't tend to focus on programming as much as I should, and my instruction sets tend to be a bit... awkward.
My CPU (like most redstone CPUs) uses an RISC-based instruction set, with some differences. Commands are extremely low-level, meaning no specific instruction does more than one operation at a time. Writing to and reading from memory is done with separate commands from the rest of the machine. Even the ALU has a few functions outside of its own instruction decoder. (Or it will rather, the decoder for it hasn't been built yet.) That way, I can perform a logical or algebraic function, and shift the result in the same operation. Or I could (x + NOT y = NOT z) to perform subtraction in the same cycle, without adding an extra function for SUB. The general purpose registers will contain 16 locations of 16-bit RAM registers, each cell will have dual-read technology. Thanks to dual-read cells, I will have two reading buses, and I can write two operands to the ALU's input registers in a single clock cycle, instead of two.
What I'm saying is the design of this CPU is very specialized and a lot of typical functions become useless or redundant because of it. Like I said, I'm not a programmer, so please correct me on the usefulness of these commands when I inevitably get out of line.
BCF/BSF:
Adding something like this would be useful at times, but it would require expanding the instruction set by another 6 bits. Not to mention, the registers would be a nightmare to construct. First, a word would have to be addressed, then a bit within that word would be selected, to be cleared or set as a 1. Something like this just isn't practical or efficient in redstone engineering. My general purpose registers will be able to do one of two things, clear a location, or write to a location from the writing bus, which can contain data from either UI ROM or the ALU's output.
NOP:
From what I understand, this is any operation that doesn't effect any registers. Mostly used as a time waster or a placeholder. Like I said, my program memory reads extremely low-level operations. So, there are many ways I could write a NOP code, I would just need to not write to any registers.
CLRF/CLRW:
I already have plans for an instruction that basically does this. It will block all inputs to the RAM cells from the writing bus, then write to the location I wish to clear. It will actually be a combination of two instructions, but it can still be done in a single clock cycle.
INCF/DECF:
In a redstone CPU, I'm pretty sure this is impossible to accomplish in a single clock cycle. And if it is possible, it requires some fancy RAM with built-in adders. I can do this in two lines of code though. In fact, my usual demo program is a simple counter that increments by one every two clock cycles. In the new CPU, I'll be able to theoretically increment by 1 multiple times in a single cycle by using a special-purpose "shortcut" register. I suppose this could be considered a hack, but I thought it would be kind of a fun idea to attempt.
I'm assuming by C, DC, and Z you're referring to flag registers. I will have a Zero flag, I have previously used this before for conditional branching when a program required user input to continue. If there are more uses for this, I would love to hear them. Like I said, I'm a beginner when it comes to programming, so I would love to learn some more tricks of the trade. Anyway, a Carry flag isn't happening for the same reason BCF/BSF functions aren't happening. A flag for C would be wayyyyyy more trouble than it's worth. It's probably possible, but it's definitely beyond my understanding of redstone at the moment. I will have an Overflow flag as well, which will simply show up in the UI as an error. I could also have this terminate the program, but it's not really necessary for all the extra work involved. I will probably just have it log the error through an SR latch and display the line of program memory in which the error occurred. Then the user can go observe the area of opcode and determine what caused the issue. By the way, what is a DC bit?
BTFSC/BTFSS:
Once again, operations that effect individual bits are just a bit too complex for redstone. Including bit testing operations like this would make branching a nightmare. Although, the way my comparative functions work is similar to how it would work in assembly (or any) language. My ALU compares inputs internally, through a comparator. A > B (or x > y, whatever the kids are calling it these days) detection is done through a modified XOR gate, which simply means removing the OR gate at the end, making it an XOR with two outputs. Not sure what it would actually be called, but it works very well. From this point on, I will call the inputs of this XOR A and B, the outputs will be X and Y, just to keep things simple. When A=1, B=0, then X=1, Y=0. When X=1, NOT gates are used to force all Y outputs of less significant bits to output 0, so you don't end up with mixed results and possible errors. A < B detection works in the same way, but in reverse. When A=1, B=1, then X=0, Y=0, thanks to the AND gate in the XOR gate. This means both flags, (for A > B aswell as A < B detection) are returning false, 0's. If A isn't greater than B, and B isn't greater than A, that only leaves one more option, A = B. That means adding the detection for this is as simple as an inverted input AND gate. (CON-AND?) Now, when outputs for both A > B and A < B are 0, then A = B will be a 1.
As for overflow detection, I mentioned I had a flag for that, which I called O. From what I understand, C is more of a scratch space for when a value exceeds the size of the ALU and registers. Of course, I may be completely wrong, please correct me if I am. By the way, this ALU handles 16-bit words, so that 9th bit isn't a problem. Overflow issues will only arise once a program exceeds a representation of 65,535.
Once again, I thank you for the criticism and look forward to you correcting the mistakes I inevitably made in this post. Your suggestions are all great, it's just that computer science becomes a lot more complicated in redstone. It's a power source that's not as flexible as electricity, and you have to find work-arounds to make things operate properly. Because of this, redstone components tend to be a lot more complex than their real-life counterparts. The CPUs I and other redstone engineers build are very basic when compared to that itty bitty chip in your computer. Modern CPUs are simply not possible as redstone performs today, at least I don't think so. If it is, it hasn't been done yet, and it would be extremely slow and probably the size of 15 football fields, arranged 15 x 3.
Yeah, it's definitely interesting trying to think about it from your perspective. We're essentially the yin and yang of computer science. I've learned tidbits of assembly language, and I understand what the commands do. I just don't think like a programmer, I don't know how to use them effectively.
Plus I'm always always learning from the hardware side of things, and usually reinterpreting through redstone. I've barely scratched the surface of programming with a modern CPU. I've written more programs on a redstone CPU, where I don't have the convenience of any high-level language. Everything is done in stripped down machine code, pure 1's and 0's.
Most instruction sets in redstone CPU's are completely custom and you will probably never see another one exactly like it. Some like to copy HACK or MIPS architecture, but the majority are completely original. I'm going for a user friendly build this time around, with a GPU, printer, ethernet, (will be implemented into a full LAN) and some other fancy stuffs. Because of this, I had to make some sacrifices in the optimization of my architecture and instruction set.
While it would be possible, it would be a huge pain and add a lot of weight. Definitely easier through software, though it will take an extra cycle. To set a specific bit in a register, first you would need to read it, and an input from the UI alongside it. UI uses ROM lines, which are manipulated through levers, the bit to set would be a 1, the rest 0's. This new value would be saved to one ALU input register, while clearing the other. Then, the data could be OR'd, XOR'ed, or even added, doesn't matter as long as the function's truth table says x=1 y=0 z=1, the output must reflect a single input when the opposite is 0. Then you can write the ALU output to the original register.
It sounds like a long process when explained in the terms of what actually happens, but it would only take 2 clock cycles. I just wanted to provide details to explain the differences and the limitations my CPU will have.
To clear a specific bit, it would be a much similar process. In fact, the only difference is the user input, designating the bit to clear must be in one ALU input register, and the original data in the other. That and you must XOR the data, no alternative functions will give you the result you're looking for. You could also AND with all bits set high except the one you want to clear, but why flip more levers than you need to.
I never even thought about it like that. The only time I've used the Z flag was to sort of "halt" the program if set. I had two sets of GOTO command lines for a 4-bit program counter, attached to 16 bits of program memory. When the ALU output was all 0's, Z bit would return true, enable one set of GOTO commands, while disabling the other. For this set of lines, at a point where user input was required, I would have the line of PROM tell the program counter to go to itself, so it would remain at the same line.
(In redstone, program counters with branching abilities are easier to build using only a binary to unary decoder. The downfall is it's annoying as hell to program. It means every single code needs a GOTO command, even if it's just to continue to the next line. Though a more sophisticated counter can be made with a shift register and attached decoder, to get the best of both worlds. This uses GOTO commands alongside a jump bit.)
The same line also had the condition for if Z returned false, in the second set of GOTO commands. When the user's input reached the ALU's output, the flag would clear and the program would progress as normal with the next clock cycle.
I think I just confused myself right now. The way I understand it, the Z flag's state depends only on the ALU's output. My comparator compares the ALU inputs and outputs it's own set of flags for them. (>, <, =) You're talking about essentially comparing data from say, two different registers and doing something with them based on how they compare to each other, correct? I just don't see how the Z bit could possibly help with that if it's based on the output of every bit in the ALU.
Honestly, I'm not even sure what to use these comparative flags for. I designed a comparator awhile back as a small project, then when I started on XENON I thought it would be cool to squeeze it in there. xD Since I did it, I have had an idea to use it in a program for a guessing game. Since 16 bits presents a lot of possibilities, I thought it would be kind of awesome to use the greater than and less than bits as a display to assist the player.
I've built a less fancy roulette-style game before, but it was external and only controlled by the computer. This would be my first attempt at making a software-only game. Which is pretty exciting, and would make a huge statement about how powerful this is for a redstone computer.
A lot of people have made suggestions of games like Pong or Snake, but that's just not going to happen. With a lot of work it would be possible, (and lots of extra hardware, somewhat defeating the purpose) but my god that would be the slowest game you've ever seen in your life. I'm talking about 1 frame/10 seconds, maybe even worse.
Oh, it makes sense... sometimes. I'm just the opposite, I understand the basics of what a command actually does. (You kind of have to know at least that much to build a machine like this.) I just don't really know how to use them together to effectively produce software that's remotely useful. If only there was some way we could splice our brains together. xD
I do appreciate your input though. It's very interesting to compare the abilities of the modern CPU to my own architecture. It helps to see the flaws in it and how that has effected my instruction set. I already have the CPU itself and general RAM planned out to specifics, so I won't try applying any fandangled space-age technology to this build. But I'm definitely taking these ideas to heart. You've inspired me to try and really take my next CPU to a higher level, no matter how slow it may become as a result.
Certainly! You can record it if you want, your channel probably won't be the only one to have a video of it though. And it won't be done for quite awhile, at least a month from now.
Ah, well that will be easy, just make sure you use 10-bit tapes. You'll also need to find out how fast of a clock you'll need for the initial section. A Minecraft day takes 20 minutes if I remember correctly, so that should help. And keep in mind MCXBLA has issues with redstone timing. Things tend to be off by a tick every once in awhile, so the clock won't be completely accurate.
I learned how to make combo locks and retractable workbenches. All from tutorials though. The tutorials for actual creations help me more than the redstone tutorials themselves do. I'm making progress in my understanding of redstone! =PPP
~SmileyyyFaceee
In a way no, but overall, yes. My ALU processes everything possible outcome through parallel logic. When values enter the ALU, it does everything all at once, so whatever operation you need is already there. It's just a matter of enabling the correct output to sort of "release" that information. Whenever two values come into the ALU they're automatically compared, the flags will simply be ignored unless I choose to use them.
It will be much faster than applying the same thing through software, but it does have one major flow. From the MSB, if only A is set, it takes a total of 36 ticks to negate all lesser B outputs. So, if you have a 1 in B of the LSB, and write a 1 to the MSB's input A, both the A > B, and the A < B flags will be set for about 32 ticks. Normally, this would cause major issues and slow my clock down tremendously, but I have a work around. The program counter will have a togglable clock. It will be able to adjust its own speed, based on a set of instructions in the program memory. So the CPU will be pretty fast, except when an instruction depends on an IF statement regarding A > B.
Oh yeah, it's much faster to implement through hardware, as numbers can be compared in a single cycle. It seems modern CPU's don't usually come with a built-in comparator, as you said, frankly I'm surprised they don't. It's actually fairly common to see them built into redstone ALU's.
As a side note, I believe what you call the accumulator would, in essence, be the same thing I've been calling input registers. I think I'll start calling them accumulator registers, as that does make more sense. They save information which is then delivered to the ALU's input accumulator, then branched to all of the internal functions of the ALU.
I did, I did, but... it's not an HDD in the way you would think of one. =/ It's a ROM HDD, so you can't actually write data to it without manually breaking and replacing blocks. To load a set of commands into an existing program with this method would be very complicated. Once again, I think that's an idea I'll save for a later build.
Here's the original thread for the HDD, in case you're interested in how it works.
The design has some bugs, particularly in how indexing and seeking function. That particular mechanism will be redesigned, but a ROM model is all I really need. It will be used to save whole programs that will be used frequently. When read from, they will completely overwrite anything stored in program memory. Writable HDDs have been built in the past though, so they're definitely possible. Some people even use them as program memory, which is something that definitely doesn't happen in a modern CPU. I personally don't like to do this because they're slow and branching is a nightmare. In real life, and HDD is more compact compared to an SSD, but much much slower. The exact same is true in the world of redstone.
Yeah, I like the thought of emulating software, on hardware that's being emulated by software, (Minecraft) which is running on hardware. (Xbox 360) That exact idea is what got me into redstone engineering and Redstone Theory. When you think about it, it's just truly mind-boggling how powerful this small set of items can be. And to most players, it's just a small portion of the game!
I think I'm going to start getting more into programming now. It would definitely help me understand what would be useful in future redstone endeavors. Do you know of any good ASM books or videos, even YouTube tutorials?
Nice! What kind of locks?
Also, building tutorials are a horrible way to learn redstone. I got to where I am today by avoiding these kind of tutorials as much as possible. I'm going to quote some advice I gave a player yesterday. I think it's relevant, and hopefully you will find it useful.
The locks are 9 digit and 4 digit button locks with decoders and RSNOR Latch arrays. I somewhat understand each individual part, but not to the fullest. I've planned out my next few days or weeks, however long it will take to complete this.
-Watch those 2 videos you just listed until both are understanded, taking breaks and experimenting if need be
-Come back to my xbox and experiment with different logic gates
-Develop an understanding for most (if not all) of the logic gates and learn the different ways of building and using them, both together and separately
-Begin redesigning some popular redstone mechanisms WITHOUT tutorials
Once I start understanding everything better, I think my first real project will be a command center for anything in my world that will be powered by redstone. I plan on making a large village / community world with my friends on survival, and I've always imagined having a command center and redstone wiring going all across the world on large poles. Almost like the real world, but instead of telephone poles I'd call them repeater poles. =P
Wish me luck on my Redstone Crusade!
~SmileyyyFaceee
Sounds good! I wish more people actually wanted to learn about redstone. By the way, one of the guys who was supposed to be helping me out hasn't been on for over a week. I don't really feel like waiting for him, so I think Crininson and I are going to get started soon. You don't have to help with the building if you don't want to, but you can still join in while I'm teaching Crin everything.
Well, you could do it with block swappers or torches. It would look much nicer with redstone lamps though, so you could always wait for them.
P.S. Thanks to everyone for helping this thread become a hot topic!
Can't wait. And yeah, the other day, I was there while you were showing off your old computer, I was just stuck in Dishonored "mode" haha.
Any idea when we can actually get started?
Yeah, random kids often want to see it. One of the downfalls of having someone else record for you, everyone can see your gamertag. I don't mind though, it's fun to show off sometimes.
I'm actually about to get on in a few minutes. If you're on, and up to it, we can get started tonight. Probably not on the actual construction, but you'll at least be up to speed.
ALU (16 functions)
Also, I feel it is necessary to share the artwork that has been recently made around the project XENON construction site.
Oh man, I can't believe you actually posted those. Haha.
I felt it would benefit the community.
Oh, and here is the data sheet for the redesigned instruction-set. Probably not official, I imagine I'll be changing things at some point.