Yeah, saw his awesome ALU. I think he's getting close to finishing his CPU. Check out this guy's ALU, it's 32 bit and uses a look-ahead design to speed it up!
Usually I just browse the forums instead of posting.
but with this post i couldn't resist.
what kind of inputs/outputs are available?
I browsed the original post and they weren't listed.
perhaps a numpad and a few seven segs would be good for now.
Nothing at the moment, apart from an out register, which hooks up to a line of redstone torches to show its value. I've got plans for a screen and keyboard, I'll think about more after those are done. :smile.gif:
After thinking about how to optomise this code for size, I came up with the following solution
First I realised that you could instead of counting from 10 down to 0, count from 246 to up to 0, that saves one branch. When I thought about both values incrementing I thought would it be possible to store them both in the same register? Then it dawned on me, yes it could. So the following is my modified program
count to ten and store it in memory 00
m00 data 00 # <-- this is my way of saying manually put these values in the memory
start m01
loop
LOADm m00,A
ADDi i01,A
STOREm A,m00 # increment m00
NOT A
ANDi i10,A
BRANCHZERO exit
BRANCHALWAYS loop
7 instructions
14 bytes
+1 for variables
15bytes
Wups, missed this when reading before. That looks good, nice use of branching, could be good for a video. :smile.gif:
I could throw together an assembler if you like. Be written in C# and be quick and dirty. How are branches done, just indirect jumps? Do you use the ALU to add to the PC register or is it set by a counter? I assume it can only access an 8 bit memory space because the it doesn't look like jumps take 3 bytes.
Got a schematic for a 16 byte block rom if you like. I built hallways for you to go in and hit switches to toggle bits on and off:) Only problem is there are no torches in any of the hallways.
i interpreted the code into op codes and binary operands for you so you don't have to do that menial task.
I have all the memory values in hex to lessen confusion.
the code is a timer, it counts up from 0 to 59, resets, then increments the "hours" value from 0 to 127
"mins" is stored in 0x1F and "hours" in 0x1E
there is no delay or anything, so the speed of the timer is purely based on your CPU speed and the code.
if you see any failures please note and i'll edit the post to fix
I could throw together an assembler if you like. Be written in C# and be quick and dirty. How are branches done, just indirect jumps? Do you use the ALU to add to the PC register or is it set by a counter? I assume it can only access an 8 bit memory space because the it doesn't look like jumps take 3 bytes.
Got a schematic for a 16 byte block rom if you like. I built hallways for you to go in and hit switches to toggle bits on and off:) Only problem is there are no torches in any of the hallways.
that could be nice, even just an semi-assembler that included some commands like MOVB
letting people right in any higher level language is going to make bloated code XD
could you imagine trying to fit any assembled C code into this 16bytes of memory?
an interpreter is a must though...
since he has to flip levers to enter code
EDIT:
is writing to memory just as fast as writing to the register for your CPU?
Actually, the program does contain errors, I forgot that branching adds to the program counter instead of replacing the contents. :S Thanks, I'll fix it now....
I could throw together an assembler if you like. Be written in C# and be quick and dirty. How are branches done, just indirect jumps? Do you use the ALU to add to the PC register or is it set by a counter? I assume it can only access an 8 bit memory space because the it doesn't look like jumps take 3 bytes.
Got a schematic for a 16 byte block rom if you like. I built hallways for you to go in and hit switches to toggle bits on and off:) Only problem is there are no torches in any of the hallways.
That'd be awesome! But I'm still not done with it yet, so I don't know if future changes could affect the code. Yeah, branching just increases the PC by the given amount. The PC increments using its own adder. There's a block diagram at http://lazcraft.tumblr.com/post/1489658879/block-diagram-of-the-cpu-ive-put-coloured-wires. Yep, 8 bit memory space. I'll have a look at that schematic, might be good to add ROM.
Actually, the program does contain errors, I forgot that branching adds to the program counter instead of replacing the contents. :S Thanks, I'll fix it now....
which also brings up..
how does it handle overflow & negative numbers?
;assuming 16bytes of shared memory
;assuming results read off memory address 0x0E and 0x0F continuously
00: 15 %0000 0000 ;load A with 0
01: 04 %0000 1111 ;store A to 0x0F
02: 10 %0000 0001 ;add 1 to A
03: 04 %0000 1101 ;store A to 0x0D
04: 09 %0011 1100 ;sub 60 from A
05: 05 %0000 1000 ;branch if 0 (0x0D == 60) to 0x08
06: 07 %0000 1101 ;load A with 0x0D
07: 04 %0000 1111 ;store A to 0x0F
07: 13 %0000 0010 ;branch always to 0x02
08: 07 %0000 1110 ;load A with 0x0E
09: 10 %0000 0001 ;add 1 to A
0A: 04 %0000 1110 ;store A to 0x0E
0B: 13 %0000 0000 ;branch always to 0x00
0C: unused
0D: ram
0E: output
0F: output
i interpreted the code into op codes and binary operands for you so you don't have to do that menial task.
I have all the memory values in hex to lessen confusion.
the code is a timer, it counts up from 0 to 59, resets, then increments the "hours" value from 0 to 255
"mins" is stored in 0x0F and "hours" in 0x0E
there is no delay or anything, so the speed of the timer is purely based on your CPU speed and the code.
if you see any failures please note and i'll edit the post to fix
Sorry, that won't work yet, because it doesn't have enough memory. :tongue.gif: Each instruction takes 2 bytes, 1 for the op code and 1 for the address/value. Awesome program though, more inspiration to aim for more memory!
Quote from otakudjr »
is writing to memory just as fast as writing to the register for your CPU?
Which register? The output register that I mentioned? If so, yes. It takes the same amount of time to do each of the different operations.
Quote from otakudjr »
which also brings up..
how does it handle overflow & negative numbers?
At the moment, I haven't even thought about overflow, carry bits don't go anywhere. All the numbers are signed, so adding and subtracting with negative numbers should work fine.
Sorry, that won't work yet, because it doesn't have enough memory. :tongue.gif: Each instruction takes 2 bytes, 1 for the op code and 1 for the address/value. Awesome program though, more inspiration to aim for more memory!
btw, I intend to go up to 32 bytes of memory, it shouldn't take too long for me to double the 16 bytes.
Sorry, that won't work yet, because it doesn't have enough memory. :tongue.gif: Each instruction takes 2 bytes, 1 for the op code and 1 for the address/value. Awesome program though, more inspiration to aim for more memory!
At the moment, I haven't even thought about overflow, carry bits don't go anywhere. All the numbers are signed, so adding and subtracting with negative numbers should work fine.
HURR DURR, i forgot all the basics while coding this.
i'll fix the branches (again) and maybe you can use it when you get 32 bytes of memory
Yeah, saw his awesome ALU. I think he's getting close to finishing his CPU. Check out this guy's ALU, it's 32 bit and uses a look-ahead design to speed it up!
Nothing at the moment, apart from an out register, which hooks up to a line of redstone torches to show its value. I've got plans for a screen and keyboard, I'll think about more after those are done. :smile.gif:
or does it write each bit at a time?
This thread is now [Diamond]
8 bit parallel bus, for both memory and for the output.
Wups, missed this when reading before. That looks good, nice use of branching, could be good for a video. :smile.gif:
Got a schematic for a 16 byte block rom if you like. I built hallways for you to go in and hit switches to toggle bits on and off:) Only problem is there are no torches in any of the hallways.
Might have to right click and save as
My new version of Redstone Simulator
Main Code Site: http://code.google.com/p/red-stone-simulator/
he should add TNT to resemble the stuff overheating cuz it cant run it and then try this!!!
hahahaha
;assuming results read off memory address 0x0E and 0x0F continuously
00: 15 %0000 0000 ;load A with 0
02: 04 %0001 1111 ;store A to 0x1F
04: 10 %0000 0001 ;add 1 to A
06: 04 %0001 1101 ;store A to 0x1D
08: 09 %0011 1100 ;sub 60 from A
0A: 05 %0000 0101 ;branch if 0 (0x1D == 60) to 0x10 (+5)
0C: 07 %0001 1101 ;load A with 0x1D
0E: 13 %1111 0011 ;branch always to 0x02 (-13)
10: 07 %0001 1110 ;load A with 0x1E
12: 10 %0000 0001 ;add 1 to A
14: 04 %0001 1110 ;store A to 0x1E
16: 13 %1110 1001 ;branch always to 0x00 (-23)
18: unused /unused
1A: unused /unused
1C: unused /ram
1E: "hours" / "mins"
all binary below for easy programming
i interpreted the code into op codes and binary operands for you so you don't have to do that menial task.
I have all the memory values in hex to lessen confusion.
the code is a timer, it counts up from 0 to 59, resets, then increments the "hours" value from 0 to 127
"mins" is stored in 0x1F and "hours" in 0x1E
there is no delay or anything, so the speed of the timer is purely based on your CPU speed and the code.
if you see any failures please note and i'll edit the post to fix
edit: http://gicodewarrior.github.com/mc-cpu-emulator/demo/?code=0F%2000%0A04%201F%0A0A%2001%0A04%201D%0A09%203C%0A05%2005%0A07%201D%0A0D%20F3%0A07%201E%0A0A%2001%0A04%201E%0A0D%20E9%0A00%2000%20%20%3Bempty%20spaces%0A00%2000%20%20%3Bto%20show%20changes%20in%20ram%0A00%2000%20%20%3Bunused%2Ftemp%20%20%0A00%2000%20%20%3B%22hours%22%2F%22mins%22
edit: fixed branches to be real branches not magic jumps & line numbering
This thread is now [Diamond]
that could be nice, even just an semi-assembler that included some commands like MOVB
letting people right in any higher level language is going to make bloated code XD
could you imagine trying to fit any assembled C code into this 16bytes of memory?
an interpreter is a must though...
since he has to flip levers to enter code
EDIT:
is writing to memory just as fast as writing to the register for your CPU?
This thread is now [Diamond]
Actually, the program does contain errors, I forgot that branching adds to the program counter instead of replacing the contents. :S Thanks, I'll fix it now....
Have another Notch!
That'd be awesome! But I'm still not done with it yet, so I don't know if future changes could affect the code. Yeah, branching just increases the PC by the given amount. The PC increments using its own adder. There's a block diagram at http://lazcraft.tumblr.com/post/1489658879/block-diagram-of-the-cpu-ive-put-coloured-wires. Yep, 8 bit memory space. I'll have a look at that schematic, might be good to add ROM.
which also brings up..
how does it handle overflow & negative numbers?
This thread is now [Diamond]
Sorry, that won't work yet, because it doesn't have enough memory. :tongue.gif: Each instruction takes 2 bytes, 1 for the op code and 1 for the address/value. Awesome program though, more inspiration to aim for more memory!
Which register? The output register that I mentioned? If so, yes. It takes the same amount of time to do each of the different operations.
At the moment, I haven't even thought about overflow, carry bits don't go anywhere. All the numbers are signed, so adding and subtracting with negative numbers should work fine.
btw, I intend to go up to 32 bytes of memory, it shouldn't take too long for me to double the 16 bytes.
Yeah, good idea. I should put tnt under the whole thing, and when I add a keyboard, have it set off the tnt if crysis is typed. :biggrin.gif:
Haha, that would make me feel like this guy:
:tongue.gif:
HURR DURR, i forgot all the basics while coding this.
i'll fix the branches (again) and maybe you can use it when you get 32 bytes of memory
now what to make with ~7 lines of code...
This thread is now [Diamond]