@Schmolendevice (View Post)

I am going to look into that problem tomorrow. As of right now. I am too intoxicated :).

I will look for the problem tomorrow. In the meantine, I solved a couple other problems. Does the program still give the same result?

Yeah at the moment I still haven't added automatic clearing. So you need to clear the RAM address beforehand, whenever you are going to write to it. Unless there is nothing in the RAM address.

My bad, changing now.

Hmm ok let me think.

The right portion of the RAM filled with INWR is the address decoder (originally designed by Crionis, it's basically the same as previous lookup grids used which involved PTCT and NTCT, but smaller. It takes in a binary value, and outputs a value from 1-100. This is how the address is chosen.

Just after the address decoder shoots out a horizontal line of BRAY, I send the value through the wires at the top. Those wires shoot out vertical lines of BRAY which intersect with the horizontal line of BRAY. When two lines of BRAY intersect, they create a single pixel of long lasting BRAY. So for example, if I gave the address decoder [0110010] (50), it would decode it and shoot a horizontal line of BRAY (address 50, which is half way down the RAM grid). Immediately afterwards, I give the RAM a value, which is sent to the top wires, fires vertical BRAY and intersects with the horizontal BRAY to create the long lasting BRAY. If the value I chose was say [00000111] (7) then three lines of BRAY would be fired downwards, and 3 long lasting pixels would appear.

These long lasting pixels still dissapear after about 15 seconds, so you need to constantly refresh them by firing BRAY at them. This is why at the end of every cycle, the RAM flashes, because they are being refreshed. This doesn't require intersecting lines of BRAY, just the vertical lines.

When reading, it's fairly similar. I select the address and BRAY is fired horizontally. Straight afterwards, I send [11111111] via the value wires. As said previously, normally when two lines of BRAY intersect, they create pixels of long lasting BRAY. Also, when the vertical lines intersect with the horizontal lines, they are stopped (the horizontal line acts like a wall and prevents the vertical lines from travelling further downwards). There is one way for the vertical line to pass through the horizontal line, and that's if there are long lasting BRAY particles along the horizontal line (which there are, from the previous write). Therefore, once the vertical lines hit the horizontal line, it will only let the correct values pass through to the output (at the bottom).

Unfortunately, every time I read a value, it create also corrupts the value. This is because once the vertical lines intersect, they create long lasting BRAY on all eight points, therefore changing the value in that address to 11111111. In order to restore the previous value, I first trigger the address BRAY again (while opening up the switch on the left) which hits the PSCN ARAY and deletes all of the values. While that is happening, the previously outputted value is looped back to the top of the ARAY and re-written into the empty address.

It's really hard to explain, but it's actually a pretty simple concept that many people use. Best way to understand it is to just watch it frame by frame, and make little experiments.

If you look at the INWR closely, it's binary. Binary in reverse. In address 1, it says [01111111][1000000].

Reverse that and it's actually [1111110][0000001]. INWR works in a similar way to long lasting BRAY. It allows normal BRAY to pass through when intersecting. It can also be used to prevent intersecting BRAY from creating long lasting BRAY or preventing each other from passing. It doesn't convert binary to decimal, just converts 0000001 to the first slot, 0000010 to the slot beneath it, 0000011 to the slot beneath that ect ect. Also, the output unit which outputs a decimal shape, just uses a massive lookup grid rather than using a binary to decimal algorithm like double dabble. I have something that implements double dabble, but it takes slightly too long for my liking.

Yeah the registers use the same concept of looping back to the input. It's actually kind of pointless that I included it. Could probably have made a far simpler design, but when I was making then I really wanted them to be 2px apart. So I came up with some weird method of turning the switch on, and passing a value through, using the same wire twice. If you look at the small box (in front of the RAM address inputs), that's what I probably should have used (or something similar). But the problem is that the lines are 3px apart.

As you can see though, I am in INST whore. I would use ARAY since it can be 1px apart, but it doesn't allow sparks to go in both directions.

Either way if you are creating a computer, the first advice I would give you is make sure you make the value bus easily accessible, and create switches (that you can turn on and off with WIFI) on the inputs/outputs of everything. Makes controlling the flow of data amazingly easy.

@Okte

What happened to your program?

It says:

USER INPUT -> RAM[1]

USER INPUT -> RAM[4]

C -> RAM[2]

C -> RAM[3]

ect

ect