I'm completely new to minecraft forum, so I have no idea if you can reply to comments. Anyway, the RAM won't actually take up too much space. It will be 3 dimensional, arranged in 8 by 2 by 8 cells (which are each 16 bits and treated like two cells. 2 pieces of data are fetched at once for speed), which is about 88 by 68 by 80 blocks high (I think; it's sort of late right now so don't trust that if it seems wrong.)
I'm not sure how much mass storage it will have, because it depends on how much space there will be left in the chunk render distance.
It actually won't use a clock. It'll use a slightly different method for each instruction to tell when to increment the pc and start the next cycle.
The large amount of RAM actually isn't enough for its purposes. I have an algorithm on the planet minecraft article which is about 85 instructions long. It just converts decimal input to binary, which is actually a lot more difficult than it may sound.
Decoding it will be a pain, but there are some patterns which can be MCedited in very quickly, and its 3-dness means it won't take much decoding for the number of cells. Because each cell holds two bytes of data, there are only 128 cells to decode.
I'm completely new to minecraft forum, so I have no idea if you can reply to comments. Anyway, the RAM won't actually take up too much space. It will be 3 dimensional, arranged in 8 by 2 by 8 cells (which are each 16 bits and treated like two cells. 2 pieces of data are fetched at once for speed), which is about 88 by 68 by 80 blocks high (I think; it's sort of late right now so don't trust that if it seems wrong.)
I'm not sure how much mass storage it will have, because it depends on how much space there will be left in the chunk render distance.
It actually won't use a clock. It'll use a slightly different method for each instruction to tell when to increment the pc and start the next cycle.
The large amount of RAM actually isn't enough for its purposes. I have an algorithm on the planet minecraft article which is about 85 instructions long. It just converts decimal input to binary, which is actually a lot more difficult than it may sound.
Decoding it will be a pain, but there are some patterns which can be MCedited in very quickly, and its 3-dness means it won't take much decoding for the number of cells. Because each cell holds two bytes of data, there are only 128 cells to decode.
Course you can reply to other comments =P
Just click the quote button. Like I did here.
Anyway, I get how you're actually using the RAM, but I believe there is a more efficient way of converting decimal to binary than your method. As for the decoding, I can see how hard it is xD
And I assume that you're make this computer run asynchronously?
Course you can reply to other comments =P
Just click the quote button. Like I did here.
Anyway, I get how you're actually using the RAM, but I believe there is a more efficient way of converting decimal to binary than your method. As for the decoding, I can see how hard it is xD
And I assume that you're make this computer run asynchronously?
Thanks.
The method for converting from decimal to binary holds values for three digits (the highest number is 255 on the RedAppe). Each time a new digit is entered, the higher digits are multiplied by 10, and all the digits are added together. I created a shorter algorithm, but it meant you had to type the digit backwards.
I'm not sure what you mean by asynchronously. Each instruction takes a different amount of time, if that's what you mean.
Thanks.
The method for converting from binary to decimal holds values for three digits (the highest number is 255 on the RedAppe). Each time a new digit is entered, the higher digits are multiplied by 10, and all the digits are added together. I created a shorter algorithm, but it meant you had to type the digit backwards.
I'm not sure what you mean by asynchronously. Each instruction takes a different amount of time, if that's what you mean.
Is this algorithm intended to show off the power of your machine, or are you trying to use it for some basic functionality? There are hardware implementations of Binary to BCD conversion which go quite quickly, although can be a bit large.
Anyways, your computer sounds fascinating. Any chance of screenshots? Or wait, do you already have a project for it on PlanetMinecraft? I must search.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
How very Apple of you to not post screens etc anywhere but one site.
Sounds like a sweet project though you may want to reconsider the 256 Bytes ram, 128 Bytes(64B shared use with screen controller) and 64B dedicated to the SC would probably work fine.
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Is this algorithm intended to show off the power of your machine, or are you trying to use it for some basic functionality? There are hardware implementations of Binary to BCD conversion which go quite quickly, although can be a bit large.
Anyways, your computer sounds fascinating. Any chance of screenshots? Or wait, do you already have a project for it on PlanetMinecraft? I must search.
Thanks for showing interest in this project. I'm a big fan.
I'm trying to use it for a basic functionality, although it's the only algorithm I've written so far. It actually converts from decimal to binary, which I swapped in a post by accident. I don't want to use a hardware binary encoder, because I'd rather use the space for more generalized functions, and because I'm sort of bored with binary decoders and encoders after spending about half a year deigning a binary decoder.
Thanks.
How very Apple of you to not post screens etc anywhere but one site.
Sounds like a sweet project though you may want to reconsider the 256 Bytes ram, 128 Bytes(64B shared use with screen controller) and 64B dedicated to the SC would probably work fine.
I'll eventually post images, once I figure out how to, and I'll figure out how to once I don't have exams soon. I'll upload a picture of the RAM grid (not finished yet) to planet minecraft, to give you an idea of how big it is. I think I'll be able to fit the whole computer within the chunk load distance, which is about 256 blocks, methinks.
I already have some other memory dedicated to the screen. It'll use 256 5-bit RAM cells.
Part of the reason for the huge amount of RAM is the way the inputs work. When you enter an input, it jumps to a RAM cell which contains a distributing sort of jump command, which jumps to an algorithm which does what the input is supposed to do. Because of that, 45 cells are used in the first place just for distributing inputs.
I know this computers going to be slow as heck (50 seconds just to type a digit in a number), but it's mainly for fun. I'll make a smaller, more practical version later on.
I was wondering if you were around here somewhere : )
Nice work on getting Hans attention, i am jelly ; P
Can't wait to see primary construction... I'd love to get a hold of your finished draw buffer. ( if you can get it working to spec of-coarse )
Nice work man,
Thanks! Good to see you here too.
Right now I'm working on RAM. I've been re-building it for about a month, because of changes in cell size or capacity, and this time I'm re-buiding it because of the dual-fetch thing. Basically, it stores two peices of information in one cell, but treats them like two seperate peices of information.
The draw buffer is probably going to semi-huge, but thanks. It'll be about 4-6 blocks high per pixel.
I'm also at work on highly realistic spec Redstone memory; and have come to a very similar conclusion.
Decoding many small cells is detrimental.. in many ways;
The design I'm working on now fetches 4-bytes at-a-time, then, a single shared apparatus uses the lower 2 bits of the address to chop-up the data into 4 unique accessible bytes.
You're welcome. Are you building the RAM for a new computer? If so, will it use RISC, or CISC, or neither?
I think we came to the exact same conclusions. My RAM works the same way, but only fetches two bytes at a time, and only uses the lowest bit of the address.
oh yes, I remember you! you contacted me for help on your design!
256 bytes? yea, that's a little much, especially for a first computer. a good idea is to leave the 8 bit address and even bus the address, but to actually only make the RAM up to 4-6 bits or so of it. that way, if you want more, you simply build more. you will realize very soon that making that much memory in minecraft will be a bit big.
oh yes, I remember you! you contacted me for help on your design!
256 bytes? yea, that's a little much, especially for a first computer. a good idea is to leave the 8 bit address and even bus the address, but to actually only make the RAM up to 4-6 bits or so of it. that way, if you want more, you simply build more. you will realize very soon that making that much memory in minecraft will be a bit big.
anyways, good luck!
I'll probably keep the 256 bytes, because I've already built most of it. I just have to repeat the busing. It is pretty big, but I think that's a good thing. Speed won't be an issue, because it fetches two pieces of data at once. I think it'll be easy enough to fit into the chunk load distance, because it's much higher than wide. I don't really think this is a first computer. It's the first computer I've built, but it's gone through many stages.
The amount of RAM is also necessary, because of the way inputs work. Each input leads to a jump commands which uses 1 cell. Because there are 45 inputs, only 211 cells are left. It also uses a reduced instruction set. Jump commands, fetching, and sending data to MARs take two instructions, so programs tend to be a bit lengthy.
Thanks for the advice! I'll keep yoour idea in mind for the smaller, more practical version I'm going to make. Maybe I'll let the user decide the amount of RAM.
Hi, this is a computer I designed, and still have to build. I’ve been working on it for about 3.5 months, averaging an hour a day. Here’s some info:
-8-Bit Computer
-3 level memory hierarchy
-Unknown amount of mass storage
-256 bytes of RAM
-32 bytes of cache
-45 Input Keyboard
-Commands which allow for highly efficient memory use
-32x32 pixel screen
-RISC with some traits from CISC (I learned what those mean from Wikipedia, which probably has a detailed definition of every computer word I’ll use.)
Once I figure out how to, I'll post a link to a planet minecraft article with detailed information.
........Wait, WHAT?! 256 Bytes! Holy crap, that's s sh!tload of memory for a Minecraft computer.
Either way, doesn't sound bad as long as it runs at a decent clock speed.
Even I can't think of uses for 256 slots.
Also, good luck on decoding 256 slots if you decide to go on with it.
I'm not sure how much mass storage it will have, because it depends on how much space there will be left in the chunk render distance.
It actually won't use a clock. It'll use a slightly different method for each instruction to tell when to increment the pc and start the next cycle.
The large amount of RAM actually isn't enough for its purposes. I have an algorithm on the planet minecraft article which is about 85 instructions long. It just converts decimal input to binary, which is actually a lot more difficult than it may sound.
Decoding it will be a pain, but there are some patterns which can be MCedited in very quickly, and its 3-dness means it won't take much decoding for the number of cells. Because each cell holds two bytes of data, there are only 128 cells to decode.
Course you can reply to other comments =P
Just click the quote button. Like I did here.
Anyway, I get how you're actually using the RAM, but I believe there is a more efficient way of converting decimal to binary than your method. As for the decoding, I can see how hard it is xD
And I assume that you're make this computer run asynchronously?
Thanks.
The method for converting from decimal to binary holds values for three digits (the highest number is 255 on the RedAppe). Each time a new digit is entered, the higher digits are multiplied by 10, and all the digits are added together. I created a shorter algorithm, but it meant you had to type the digit backwards.
I'm not sure what you mean by asynchronously. Each instruction takes a different amount of time, if that's what you mean.
Is this algorithm intended to show off the power of your machine, or are you trying to use it for some basic functionality? There are hardware implementations of Binary to BCD conversion which go quite quickly, although can be a bit large.
Anyways, your computer sounds fascinating. Any chance of screenshots? Or wait, do you already have a project for it on PlanetMinecraft? I must search.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Sounds like a sweet project though you may want to reconsider the 256 Bytes ram, 128 Bytes(64B shared use with screen controller) and 64B dedicated to the SC would probably work fine.
http://www.planetminecraft.com/project/redappe-computer/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Cool! This does look very well planned. I hope this does good for him!
- Squarest of the Dogs
Thanks for showing interest in this project. I'm a big fan.
I'm trying to use it for a basic functionality, although it's the only algorithm I've written so far. It actually converts from decimal to binary, which I swapped in a post by accident. I don't want to use a hardware binary encoder, because I'd rather use the space for more generalized functions, and because I'm sort of bored with binary decoders and encoders after spending about half a year deigning a binary decoder.
Thanks.
I'll eventually post images, once I figure out how to, and I'll figure out how to once I don't have exams soon. I'll upload a picture of the RAM grid (not finished yet) to planet minecraft, to give you an idea of how big it is. I think I'll be able to fit the whole computer within the chunk load distance, which is about 256 blocks, methinks.
I already have some other memory dedicated to the screen. It'll use 256 5-bit RAM cells.
Part of the reason for the huge amount of RAM is the way the inputs work. When you enter an input, it jumps to a RAM cell which contains a distributing sort of jump command, which jumps to an algorithm which does what the input is supposed to do. Because of that, 45 cells are used in the first place just for distributing inputs.
I know this computers going to be slow as heck (50 seconds just to type a digit in a number), but it's mainly for fun. I'll make a smaller, more practical version later on.
I was wondering if you were around here somewhere : )
Nice work on getting Hans attention, i am jelly ; P
Can't wait to see primary construction... I'd love to get a hold of your finished draw buffer. ( if you can get it working to spec of-coarse )
Nice work man,
Thanks! Good to see you here too.
Right now I'm working on RAM. I've been re-building it for about a month, because of changes in cell size or capacity, and this time I'm re-buiding it because of the dual-fetch thing. Basically, it stores two peices of information in one cell, but treats them like two seperate peices of information.
The draw buffer is probably going to semi-huge, but thanks. It'll be about 4-6 blocks high per pixel.
Decoding many small cells is detrimental.. in many ways;
The design I'm working on now fetches 4-bytes at-a-time, then, a single shared apparatus uses the lower 2 bits of the address to chop-up the data into 4 unique accessible bytes.
Thanks for the extra info BTW.
I think we came to the exact same conclusions. My RAM works the same way, but only fetches two bytes at a time, and only uses the lowest bit of the address.
256 bytes? yea, that's a little much, especially for a first computer. a good idea is to leave the 8 bit address and even bus the address, but to actually only make the RAM up to 4-6 bits or so of it. that way, if you want more, you simply build more. you will realize very soon that making that much memory in minecraft will be a bit big.
anyways, good luck!
I'll probably keep the 256 bytes, because I've already built most of it. I just have to repeat the busing. It is pretty big, but I think that's a good thing. Speed won't be an issue, because it fetches two pieces of data at once. I think it'll be easy enough to fit into the chunk load distance, because it's much higher than wide. I don't really think this is a first computer. It's the first computer I've built, but it's gone through many stages.
The amount of RAM is also necessary, because of the way inputs work. Each input leads to a jump commands which uses 1 cell. Because there are 45 inputs, only 211 cells are left. It also uses a reduced instruction set. Jump commands, fetching, and sending data to MARs take two instructions, so programs tend to be a bit lengthy.
Thanks for the advice! I'll keep yoour idea in mind for the smaller, more practical version I'm going to make. Maybe I'll let the user decide the amount of RAM.