Latest News Article

[Hans Lemurson]

Beardedcow, on 06 February 2012 - 06:23 PM, said:

Sounds very nice, but reading some of your previous posts, about your 8-color display. That is going to be very big, you build this on a server I am guessing??

The 8-color display is not for this machine.  This one is a general-purpose computer.  I am building this on the Redstone Development Foundation server, and so have a 256x256 plot of flat ground all to myself!

Jammin123, on 06 February 2012 - 07:32 PM, said:

Looks awesome so far!!!
Keeping up the good work as always

- Jammin123

Thanks!

Glenn, on 06 February 2012 - 09:02 PM, said:

What specs are you planning?

Clock speed?
Amount of RAM?
User input?
Amount of ROM?

By the way, it's good to see a computer with a comparator. What does it do with the results?

I have been developing a computer myself with an unusual architecture, by the way. I wonder if I will ever finish it. Man, I haven't even touched the RSGC2 for half a year.

Clock Speed: I'm aiming for a clock-speed of 500 milliHertz (20 ticks), but based on some preliminary tests with a program counter, I may need to reduce this to closer to 400 milliHertz (25 ticks).
RAM: It has 15 Bytes of RAM hooked up as the CPU registers.  The 16th address-slot (technically the 0th) is empty, for easy access to the number 0.
User Input: I will be doing "Memory Mapped I/O" so I'll just replace some of the RAM in my register slots with wires connected to a manual input.  Reading from "Address 1111" will mean that it's reading the user input.  I might also set up an interface for modifying the program memory, so it can be programmed from one location instead of flying about.
ROM: ROM (read-only memory) is simply a kind of memory device, not a discrete computer component.  For initial tests, I might use ROM for my Program Memory, but later I intend to store the Program in write-able storage.  I'll start off with just 16 instructions worth of program memory, but would like to get up to 64.  The difficulty is that larger memory sizes have longer access-times and hence will slow the machine down.

Sabinno, on 07 February 2012 - 01:05 AM, said:

Hans Lemurson!
Dear Notch, I haven't seen you around here since... Months ago.
Welcome back to the RF =P

OT:
Can't wait to see more progress on this, looks great so far!
And an 8-color display, you say? I'm very excited to see this

Question, how fast do you think this computer will be able to execute simple functions?

Yeah I haven't been a frequent contributor to these forums for some time, but I felt I should start showing more awesome stuff to you guys.  This project will NOT be using an 8-color display though.

YuriKahn, on 07 February 2012 - 04:09 AM, said:

I've been using that display myself [sethbling's], it's quite versatile (though quite large in the world, and a bit laggy).
As for your computer, what interests me most is the dual-read memory. How do you do that without a lot of torch towers (I did this in my last cpu project, but it was quite slow :/).

What's funny is that it DOES use torch-stacks, but it doesn't add any delays that really matter.  Unless you're accessing memory frequently, it doesn't matter how long the "percolation time" is within a cell.  Output1 receives changes 2 ticks after data is written, and Output2 receives it 4 ticks after.  All this will happen during the "instruction-fetch" phase of the CPU cycle when the registers are sitting idle, and so is of no consequence.

There are more compact versions of Dual-Read RAM, but the one I'm using has the versatility of being able to support ANY NUMBER of outputs, so long as you're willing to accept +2 ticks of delay for each one.  

I'll have a thread about my Dual-Read RAM up at some point, but for now I'm fighting with my video editing software to export a decent copy of my ALU-Demonstration Video.

[Stee_vo]

Yay, i wish i had the skillz to make a computer
But i'll get there, i am working on redstoen every day now

[captainarcain]

Hans Lemurson, on 07 February 2012 - 07:34 PM, said:

ROM: ROM (read-only memory) is simply a kind of memory device, not a discrete computer component.  For initial tests, I might use ROM for my Program Memory, but later I intend to store the Program in write-able storage.  I'll start off with just 16 instructions worth of program memory, but would like to get up to 64.  The difficulty is that larger memory sizes have longer access-times and hence will slow the machine down.

Actually, I've been working to find a solution to this very problem.  I've found that by banking the memory using 8 byte banks and then giving them a shared bus, I've been able to reduce the "Long" delay reaching that 16th or 32nd byte.  The trade-off, of course, is a longer initial delay.  Personally, I prefer this method since it's more consistent timing-wise and offers less delay in the long run.

My new RAM design offers a read speed of 6 ticks at the 16th byte minus 7 ticks (also @16th byte) for the hardware for the address decoder.  I'm sure I could knock down the decoder to 6 ticks with some refinement, but not much more.

[Hans Lemurson]

captainarcain, on 07 February 2012 - 09:16 PM, said:

Actually, I've been working to find a solution to this very problem.  I've found that by banking the memory using 8 byte banks and then giving them a shared bus, I've been able to reduce the "Long" delay reaching that 16th or 32nd byte.  The trade-off, of course, is a longer initial delay.  Personally, I prefer this method since it's more consistent timing-wise and offers less delay in the long run.

My new RAM design offers a read speed of 6 ticks at the 16th byte minus 7 ticks (also @16th byte) for the hardware for the address decoder.  I'm sure I could knock down the decoder to 6 ticks with some refinement, but not much more.

From my experience it sounds like you've made some RAM with a 2x3 footprint.  Smaller footprints help reduce the magnitude of the problem, but don't eliminate it.  3-Long RAM has a delay of +2 per 5 registers, whereas the 4-Long RAM I'm using has its +2 delay every 4 registers.  

I'm using 4-Long RAM (4x4 footprint) because that's the shortest RAM available with Dual-Read capability.  I've been exploring methods of using Instant-Repeaters to speed up memory access times.  Memory-access times are the biggest factor in slowing down a Redstone Computer.  ALU's can be made to work in 5 ticks, but data reading and instruction-fetching overwhelm that seeming speed with their delay costs.

I've actually designed some 2x2 footprint RAM which I'll also have a thread about at some point.  Technically speaking, it's 2x2.2, since it needs a repeater (and some extra spacing) every 7 registers, but it's about as compact as you can get (if you don't mind using piston update glitches).

Update: I've added a summary of "branching" to the first post and computer specifications.

[captainarcain]

Hans Lemurson, on 07 February 2012 - 10:46 PM, said:

From my experience it sounds like you've made some RAM with a 2x3 footprint.  Smaller footprints help reduce the magnitude of the problem, but don't eliminate it.  3-Long RAM has a delay of +2 per 5 registers, whereas the 4-Long RAM I'm using has +2 every 4.  

I'm using 4-Long RAM (4x4 footprint) because that's the shortest RAM available with Dual-Read capability.  I've been exploring methods of using Instant-Repeaters to speed up memory access times.  Memory-access times are the biggest factor in slowing down a Redstone Computer.  ALU's can be made to work in 5 ticks, but data reading and instruction-fetching overwhelm that seeming speed with their delay costs.

I've actually designed some 2x2 footprint RAM which I'll also have a thread about at some point.  Technically speaking, it's 2x2.2, since it needs a repeater (and some extra spacing) every 7 registers, but it's about as compact as you can get (if you don't mind using piston update glitches).

Update: I've added a summary of "branching" to the first post.

Actually, I'm using 4x2 footprint.  Oddly enough, it *does* happen to have the piston update glitch, but it's configured in a way that if the glitch does get fixed, it *should* still operate unmodified.  I hadn't intended to use the glitch when I built it but it just worked out that way.

The input/output bus contains nothing but repeaters every 15 to carry the signal, so a 16 byte bank only has a 3 tick travel time once the READ is initiated.  Again, this breaks down to the delay in the addressing/READ/WRITE/CLEAR logic.  I'm not really sure HOW I can make that logic any faster than it already is, but I'm sure someone far more brilliant than I will come up with something insanely simple to do it 3 times faster.  In the meantime, I'll keep hammering at new designs.

I am REALLY interested to see your 2x2 footprint, that's just crazy.

[Hans Lemurson]

Everybody can celebrate now, for I have completed a video demonstration for this ALU!!!



This video will also be added to the Original Post.

[Sabinno]

Great video! Very informative, can't wait to see more progress

[Kamil]

How could the effect of "Disable XNOR and force carry to back-propogate" possibly be difficult to understand?

[Hans Lemurson]

Sabinno, on 08 February 2012 - 04:36 AM, said:

Great video! Very informative, can't wait to see more progress

Thanks.  The next video will be from the past though.  Does that still count?

Kamil, on 08 February 2012 - 04:52 AM, said:

How could the effect of "Disable XNOR and force carry to back-propogate" possibly be difficult to understand?

No idea.  It does exactly what it says!  Totally intuitive to anybody who's invented this particular design of ALU.  It was either that or use Right-shifting for Logic, but I added the shifter fairly late in the design, and so Back-Propagation it is!

[Sabinno]

Oh course it does =P

OT:
Will we be seeing any progress on the 0-5 % completed portions of the computer soon?

Human readable output (lolwut?)
Haha, pretty funny. Human readable. Redstone. Hahaha.

And more off-topic...
It's 1:30 here, very tired, goodnight RF!

[Hans Lemurson]

Program Counter and Program Memory are next on the list to be added.  Once the Program Counter is in place, then I can finish the Branching circuitry.

Program memory will pose an interesting challenge, trying to figure out how to get all 16 bits on instruction data to all get to the right places without ending up backwards or adding too much delay.  It's just a wiring-organization challenge though.

Off Topic: I just figured out a way to improve my speech clarity and eloquence.  I'm recording using a headset, but it turns out that when I have the earphones plugged in and I talk on the mike, this makes me stutter.  It's a known effect that having delayed sound feedback of your voice can cause stuttering, and there's just enough delay caused by mike->computer->earphones that it causes a noticeable increase in my stuttering (I normally barely stutter at all, only on videos).

[captainarcain]

okay, you've got me stumped.... I can *NOT* for the life of me figure out how you're doing 2x2 RAM.  I've gotten it down to 2X3, but 2x2?  You mock me, Sir!

[Hans Lemurson]

captainarcain, on 11 February 2012 - 05:31 AM, said:

okay, you've got me stumped.... I can *NOT* for the life of me figure out how you're doing 2x2 RAM.  I've gotten it down to 2X3, but 2x2?  You mock me, Sir!

I'll have a video about the 2x2 RAM up this week, but before that I'll get the video up about the jumping/looping counter I built as a proof of concept for Program Memory.  It's without voice so I'm annotating it.

[Tjakka5]

Oh yeah, i saw this thing on the RDF server.

It end of stream'ed me....

[myskillsisfromhell]

WOW looks awesome!
But you said that's it's gonna be able to run simple games?
Just wanted to know if you are going to use a "real" GPU or like the 8/11 color display?

[bumblebeeminer111]

whoa...How long did it take

[Hans Lemurson]

Tjakka5, on 14 February 2012 - 01:10 PM, said:

Oh yeah, i saw this thing on the RDF server.

It end of stream'ed me....

Heh, yeah, that's one of the dangers of the large and complex redstone creations in multiplayer.

myskillsisfromhell, on 14 February 2012 - 06:43 PM, said:

WOW looks awesome!
But you said that's it's gonna be able to run simple games?
Just wanted to know if you are going to use a "real" GPU or like the 8/11 color display?

This machine will not be hooked up to a GPU, but just a screen whose rows get updated with new information when relevant.  I probably won't do the map-screen for a while.

bumblebeeminer111, on 14 February 2012 - 07:53 PM, said:

whoa...How long did it take

I've been working on it since November 2011, but my work has been very sporadic.  My progress is often in fits and starts, I'll do nothing on it for weeks, and ponder how to integrate the next part, and then in a few hours suddenly add on major components.  There's also a lot of down-time where I'm planning HOW to build the next part when I add a few wires and realize that I'm about to run into another structure.  Getting everything to fit together nicely without excess space and delay is a challenge.  Being a perfectionist slows down my progress, but does enhance the quality of the final product.  

I'm working on trying to find a good balance between making a machine that I am proud of versus actually getting shit done.

[brett122798]

Sabinno, on 07 February 2012 - 02:24 AM, said:

Here's Sethbling's 11-color display, he never made an 8-color one however.

Try making a color display without the map(a screen)... difficult, but possible. Would be laggy though...

[ChronusZ]

brett122798, on 18 February 2012 - 04:27 AM, said:

Try making a color display without the map(a screen)... difficult, but possible. Would be laggy though...

I think the bigger problem would be how large it would be. For a 4 colour display, it'd be 4 blocks of space between pixels, minimum. For an 8 colour display, it'd be (7?) blocks of space. So 96% of the display is empty space on a 4 colour display, and 98% is empty on an 8 colour display. Not very efficient.

[Hans Lemurson]

ChronusZ, on 18 February 2012 - 05:10 AM, said:

I think the bigger problem would be how large it would be. For a 4 colour display, it'd be 4 blocks of space between pixels, minimum. For an 8 colour display, it'd be (7?) blocks of space. So 96% of the display is empty space on a 4 colour display, and 98% is empty on an 8 colour display. Not very efficient.

Shortly after pistons came out, I figured out a way to make a 4-color display like that.  It's not as bad as your estimates, but the block-density is still depressingly low.  Also, it's angled:


I'm about to get around to annotating my programmable loop counter video, so stay tuned.