Haku
Skeletron Prime
A while ago I posted a CPU I made which worked, I guess, but there were a few serious flaws with it.
Firstly, with 256 bytes of RAM the game would lag for a split second whenever anything passed through the data bus. It doesn't seem bad at first, but it capped the maximum clock speed at around 30-40Hz when it could have been 60+.
Secondly, there was an error in the ALU, I forgot to add a wire which inverted the inputs making subtraction impossible.
And last but not least, the instruction set was a nightmare. Each instruction was very small as if it was a super-RISC ISA, reading a value from memory into the data bus or something was as complicated as an instruction could be. Given that each instruction took 2 ticks to fetch and execute, it made the CPU very slow and inefficient, as well has hard to program.
But now the "HPU 2.0" is here!
With a reduced 64 bytes of RAM there is no stuttering at all when values are passed through the data bus. I can run Fibonacci at 60Hz while still maintaining 50-60fps as opposed to 3-10fps on the old one.
I've got a new ALU that uses a binary counter instead of a ripple carry adder. This new ALU can add, subtract, shift left and right as well as perform bitwise logic, although the bitwise logic unit is a bit messy.
The instruction set has been 'upgraded' from RISC to CISC making programs easier to write and increasing the CPU speed. As this CPU is still in a beta stage the stored instructions in the instruction ROM haven't been optimised yet. I thought of a way to shave off a tick or two from almost every instruction after I'd finished programming them all in, which took quite a long time to begin with so I'm not in a rush to redo them all anytime soon.
Instead of executing 1 micro-instruction per 2 ticks as in v1, v2 can execute 1 micro-instruction per tick due to a tiny bit of basic pipe-lining. The next instruction is fetched and the first micro-instruction is executed, then the subsequent micro-instructions are executed, and finally the program counter is incremented as the last micro-instruction is executed.
Rather than loading the old Fibonacci sequence as a demo program, I decided to spice it up and write a 16-bit version which is a bit slower but it now goes up to 40000 as opposed to 233.
Finally, I'll post a few gifs of the CPU in action along with the instruction set, a world file, some screenshots, and a diagram.
My framerate is shown in the bottom left, with frame skip off. The results are similar with frameskip on except it caps at 60.
My framerate isn't included in this one, but it was around 45-50fps. Definitely still playable, the gif might seem laggy but that's because it was recorded at 10fps. Moving away from the CPU boosted my framerate to 55-ish.
Here's v1 running the fibonacci sequence in 8-bit as opposed to 16-bit on the same 60Hz clock. 16-bit requires more than double the computational power of 8-bit:
Both CPUs run at about the same pace here, which means v2's code is roughly 2x faster, which can still be improved by several ticks once I fully optimise the built-in instructions.
Another key difference is the framerate - v1 would make the game unplayable but you could probably set the clock to around 40Hz and have no lag with v2. I haven't tried overclocking it yet but I reckon you could get up to 100Hz on v2 before it becomes as bad as v1 on 60Hz.
I made the binary output vertical and replaced the torches with actuators. I included it because it's a nice way of using the halt command (it branches to a specific address before stopping the clock, the switch here simply restarts the clock.)
As you can see, the CPU is considerably smaller than v1, I tried to make something that can reasonably fit in a world and also run in the background if given a slow clock. I could run fibonacci at 30Hz without experiencing any lag. Here is v1 for reference with v2 pasted inside:
As you can see, it's very sprawled out and messy. There are some painted RAM cells at the bottom because inputs / outputs are memory-mapped, so instead of having an output instruction you simply store the data in memory cell X or for inputs you'd read from memory cell Y. This system is used in v2 too for outputs.
A few general notes:
You can write a "1" to the ROM by breaking the top lamp (as shown by the pre-programmed code).
I use my own mod "WrenchMod" which contains a spark wrench to reset the CPU by triggering specific control wires. You could code your own reset subroutine though that clears the ALU, erases everything in the RAM, and branches back to 00.
I haven't fully tested this CPU yet so I'm saying it's in beta. There are 12 free instructions in the instruction set which can be filled, I was thinking of having a second ALU or just an adder that can increment values in memory addresses, check if they're 0 etc. making for loops more desirable and efficient. I want to add a couple of instructions for using a value in the RAM as an address too, like an array. This would allow you to write "for x in range 0 to 63: memory(x) = 0" to clear the RAM.
ROM address 7F (or 127) can be written to by an external component - if you created a queue and a custom subroutine to call for new instruction you could use it as a co-processor.
In the instruction set file, the JMP command jumps to "addr + 1", this is because the PC is updated with the new value and at the end of the instruction it is incremented. This means that when using the CAL() instruction you won't branch back to the same place and execute CAL() again, you'll move on to the instruction after it.
As you spawn in the world you will start falling - but don't worry! There's a teleporter at the bottom that will catch you and it'll take you to the decimal output display.
Have fun with it! (And let me know if you find any bugs)
Firstly, with 256 bytes of RAM the game would lag for a split second whenever anything passed through the data bus. It doesn't seem bad at first, but it capped the maximum clock speed at around 30-40Hz when it could have been 60+.
Secondly, there was an error in the ALU, I forgot to add a wire which inverted the inputs making subtraction impossible.
And last but not least, the instruction set was a nightmare. Each instruction was very small as if it was a super-RISC ISA, reading a value from memory into the data bus or something was as complicated as an instruction could be. Given that each instruction took 2 ticks to fetch and execute, it made the CPU very slow and inefficient, as well has hard to program.
But now the "HPU 2.0" is here!
With a reduced 64 bytes of RAM there is no stuttering at all when values are passed through the data bus. I can run Fibonacci at 60Hz while still maintaining 50-60fps as opposed to 3-10fps on the old one.
I've got a new ALU that uses a binary counter instead of a ripple carry adder. This new ALU can add, subtract, shift left and right as well as perform bitwise logic, although the bitwise logic unit is a bit messy.
The instruction set has been 'upgraded' from RISC to CISC making programs easier to write and increasing the CPU speed. As this CPU is still in a beta stage the stored instructions in the instruction ROM haven't been optimised yet. I thought of a way to shave off a tick or two from almost every instruction after I'd finished programming them all in, which took quite a long time to begin with so I'm not in a rush to redo them all anytime soon.
Instead of executing 1 micro-instruction per 2 ticks as in v1, v2 can execute 1 micro-instruction per tick due to a tiny bit of basic pipe-lining. The next instruction is fetched and the first micro-instruction is executed, then the subsequent micro-instructions are executed, and finally the program counter is incremented as the last micro-instruction is executed.
Rather than loading the old Fibonacci sequence as a demo program, I decided to spice it up and write a 16-bit version which is a bit slower but it now goes up to 40000 as opposed to 233.
Finally, I'll post a few gifs of the CPU in action along with the instruction set, a world file, some screenshots, and a diagram.
My framerate is shown in the bottom left, with frame skip off. The results are similar with frameskip on except it caps at 60.
My framerate isn't included in this one, but it was around 45-50fps. Definitely still playable, the gif might seem laggy but that's because it was recorded at 10fps. Moving away from the CPU boosted my framerate to 55-ish.
Here's v1 running the fibonacci sequence in 8-bit as opposed to 16-bit on the same 60Hz clock. 16-bit requires more than double the computational power of 8-bit:
Both CPUs run at about the same pace here, which means v2's code is roughly 2x faster, which can still be improved by several ticks once I fully optimise the built-in instructions.
Another key difference is the framerate - v1 would make the game unplayable but you could probably set the clock to around 40Hz and have no lag with v2. I haven't tried overclocking it yet but I reckon you could get up to 100Hz on v2 before it becomes as bad as v1 on 60Hz.
I made the binary output vertical and replaced the torches with actuators. I included it because it's a nice way of using the halt command (it branches to a specific address before stopping the clock, the switch here simply restarts the clock.)
As you can see, the CPU is considerably smaller than v1, I tried to make something that can reasonably fit in a world and also run in the background if given a slow clock. I could run fibonacci at 30Hz without experiencing any lag. Here is v1 for reference with v2 pasted inside:
As you can see, it's very sprawled out and messy. There are some painted RAM cells at the bottom because inputs / outputs are memory-mapped, so instead of having an output instruction you simply store the data in memory cell X or for inputs you'd read from memory cell Y. This system is used in v2 too for outputs.
A few general notes:
You can write a "1" to the ROM by breaking the top lamp (as shown by the pre-programmed code).
I use my own mod "WrenchMod" which contains a spark wrench to reset the CPU by triggering specific control wires. You could code your own reset subroutine though that clears the ALU, erases everything in the RAM, and branches back to 00.
I haven't fully tested this CPU yet so I'm saying it's in beta. There are 12 free instructions in the instruction set which can be filled, I was thinking of having a second ALU or just an adder that can increment values in memory addresses, check if they're 0 etc. making for loops more desirable and efficient. I want to add a couple of instructions for using a value in the RAM as an address too, like an array. This would allow you to write "for x in range 0 to 63: memory(x) = 0" to clear the RAM.
ROM address 7F (or 127) can be written to by an external component - if you created a queue and a custom subroutine to call for new instruction you could use it as a co-processor.
In the instruction set file, the JMP command jumps to "addr + 1", this is because the PC is updated with the new value and at the end of the instruction it is incremented. This means that when using the CAL() instruction you won't branch back to the same place and execute CAL() again, you'll move on to the instruction after it.
As you spawn in the world you will start falling - but don't worry! There's a teleporter at the bottom that will catch you and it'll take you to the decimal output display.
Have fun with it! (And let me know if you find any bugs)
