New 8-bit Processor
-
I think I found a bug. When I try to write from C to RAM, instead of replacing the old value with the new value (that of C), it just puts it over the top. In other words, if RAM slot 2 = 00000001, C = 00000010, and I try to send C to RAM, it sets RAM slot 2 to 00000011 (i.e. old slot 2 OR C).
Demonstration of bug: https://powdertoy.co.uk/Browse/View.html?ID=1276180
I'm working on a multiplication program and this is stopping it from working. :(
Edited 2 times by Okte. Last: 3rd Aug 2013 -
Ah ok I shall fix this soon (i already knew about this, just completely forgot about fixing it). I will make sure the values are cleared before being entered. When I have finished changing it, I shall edit this post.
Also looking at another bug involving addition.
EDIT: I have added 3 new instructions. Because of the nature of ARAY RAM, it's hard to clear it before writing to it on the same instruction. So I have made 3 seperate instructions for clearing using ROM/A/B as address.
01111
10000
10001
view first post for details.
EDIT 2: Fixed problem where if you read a RAM address that had no value, it would set the addresses value to 11111111.
I am now looking into a supposed problem with the addition not sending to C very rarely (even though I myself have never seen this), and also adding a feature to use A/B/C as the address for outputting RAM.
Edited 3 times by Synergy. Last: 3rd Aug 2013 -
Brilliant! Now my multiplication program works (I think) :) https://powdertoy.co.uk/Browse/View.html?ID=1276167
-
Awesome. I didn't update the save (for EDIT2) until like 5 minutes after I edited the post. So make sure you are using the very most recent one now.
Hopefully it works. If something goes wrong, I imagine it will be because of the aforementioned problem with A/B going to C. But as I said, I have never seen that problem myself.
I shall try the program now :D
edit: Tried 13*3, worked perfectly. Trying some other combinations.
Edited once by Synergy. Last: 3rd Aug 2013 -
Whoops, just realised that I forgot to clear slot 5 after I update it. (The program failed on 15 x 5.)
Just updated the save; hopefully I've fixed the problem.
-
woo i hope so. I was watching 9*9 with dread as it was failing. I'll try now.
EDIT: mfw 9*9 outputs 81
1JVQwti0zlgWatch video on youtubeEdited once by Synergy. Last: 3rd Aug 2013 -
I have a question: why do I have to put 255 in the first "section" to send a value from RAM to somewhere else? Is there any logical reason for it?
Also, are IF GREATER and IF LESS instructions possible? They would make making an integer division program a lot easier :)
-
No logical reason. I am just a failure of a wire magician.
The way the RAM reads is by sparking all of the input wires. If you pause the processor while it's reading, you should see this (and you will see why they all need to be sparked). I could get around this by using some delay and Wifi, which I should probably do later on.
greater/less should be possible. I am just in the middle of thinking of a way to quickly do them (also adding IF NOT EQUAL soon since its just a modification to the output for the wires that perform IF EQUALS).
In other news. I added input functionality. You can easily input any number from 1-255 in decimal and it will be converted to binary and stored in RAM (specified by you). The way the input works is like this. Say you want the number 147? Press 50 then 50 then 40 then 7. Or any logical combination (90 then 10 then 40 then 7) (even 1 then 1 then 1 ectect you get the idea). After the full number is entered, press confirm.
I will update the front of the thread with the new information for the input function.
-
The RAM is working fine and the right variables are being added together in my multiplication program, but I just don't understand why for certain numbers, e.g. B1010 * B1010, the processor first adds A, 0 to B, 10100, stores the results from C to A (10100), adds it to 0, but before the last result (1010000 (80)) is stored, the CPU mysteriously clears both the A, B and C registers. Hence as I have stated in earlier comments, only the last result is displayed leading to erroneous results. My thoughts are that sometimes during the A/B to C process, the contents of the register are cleared but are somehow lost and not stored back into the registers or the data transfer fails to be completed. Perhaps it's only timing.
Anyways, as for Okte, I was just wondering what algorithm you used for your multiplication. I wanted to use 'for loops' in program but thought that it would take too many instructions to successfully increment and check the value of the incrementing variable. I'm currently working on my own 8-bit computer in real life (I find it easier to work with actualy integrated circuits) and I am hoping to create an efficient program that can handle a limitless number of bits (any data sign) but not take up too many instructions in memory. Else I simply need to look more into this computer's instruction set an develop a more efficient loop.
Also, I have suggestions for creation more efficient for loop structures by simply incorporating a dedicated incrementer register that increments if it's contents are not equal with specified value of the instruction. An example could be [00001000][0][address following the concluding loop JUMP][0110][00000] where the current contents of the Incrementer Register are zero and at the end of the for statement there is a JUMP command the jumps to the address of the For statement. This could help to decrease the size of some programs I guess.
As for multiplication, perhaps the shift left command simply inputs the contents of the A register to the ALU twice in order to be added to itself. Then another register could be used to store the overflow of the ALU so that it can be called and stored into the most significant byte of the 16-bit number. Else, a 16 bit shift register could complete get rid of this manual cascading process.
