My Reasoning

Hello. I'm Dannon.
I chose this project, the CPU, because it has been in the back of my mind for 2 years. Given that now, i'm in a class that requires a good product, I decided that I take on this challenge, since I now know basic computer architecture and programming.
I chose this instead of the myriad of other things, such as just programming, because this still gave me a challenge, and believe me, it did.

The Overview

Since the CPU is generally complicated and was made somewhat messily, I will try to simplify it.
Firstly, we have memory, which contains the pre-loaded program, such as a benchmark. It has a capacity of 64Kb, or basically the ability to hold about 64000 pieces of data, or instructions. This is pre-made by the simulator, otherwise this project would of not worked.
Secondly, we have the ALU. The ALU, standing for Arithmetic Logic Unit, allows the CPU to do math. Every CPU, even the ones in the chromebooks have one. This allows for 3 inputs, which will be explained in the ALU section.
Next, we have the heart of the CPU, the instruction manager. This is irregular from actual CPU's, being not the most complex part but the second most complex part. This part takes in the data from the Databus, then processes it into the instructions, when told to.
Lastly, we have the registers. It has 9 registers, A, B, C, D, E, H, L, F, and a 16 bit one, that is the memory pointer, PC. This will be explained later in more detail, but this segment controls the general cache data for the ALU, and holds the flags, allowing it to find conditions (if I got it to work by then).

ALU

This part, as already said, does math and logic. Its generally simple, consisting of only the preset simulation math parts, 3 inputs for Data and Output control.
When input with the two Byte of data, it has all the outputs all ready, but it uses something called a "Multiplexer," which takes an input signal and allows one of the outputs to pass through, into the registers.
The most "understandable" parts of the ALU would be the Addition, Subtraction, and possible multiplication. The other things do inversion, and cancel bits, which you don't need to know about.

Instruction Manager

The instruction Manager is the second most complex part, as said. It takes the databus input and processes it into a 256 combinations (1/3 of them are empty of any process), since 8 bits makes 256 combinations.
As you can see in the picture, the ALU and main REG control are on the right, being the most contributing of 128 total instructions! The others consist of comparing 2 data values, loading data values, jumping to addresses, etc.
Not much else to explain here, its even more simple than the ALU but harder to understand when programming. <

Registers

Lastly, comes the biggest, messiest part. Since this segment was made in 1 day, it had to cooperate with non-standard inputs, making it a hassle to debug, making the conditional jumps impossible.
This part stores all the data in its 9 registers, 8 being general data for math and 1 for the memory. The outputs on the right show the memory address (bottom right), and ALU, port, and memory data output, for loading to memory (Also not working. Wow, this is really buggy.)
This was the hardest to make, since I had to debug for about a couple hours and couldn't find solutions to some of the instructions not working.

Examples

Here will be some exemplary code, of which is really the limit of this CPU.

Adding 41+52 - 00 28 29 2a 34 81 82 08 = 5D or 93
It works by loading the two values, 41 and 52, from Hexadecimal into the registers B and C, then adding them to A, and loading the product in the end.

Minus 1 from 0 (Spoilers, it does work in a weird way.) - 00 29 01 89 08 = ff or 255
It works weird, since 0 - 1 would normally equal -1. However, since computers use a limited Binary system, and my system can't handle negatives, it acts like a carry system from a imaginary 9th bit, which loads 1 in all bits.

Count Forever. - 00 d8 08 23 - Counts until simulation stops.
It works in a weird, logical way. Every register starts at 00, or 0, and we just increment reg A every single time the clock reaches that exact instruction. After that, it prints it to output, then next clock cycle it "jumps" to register pair O, which is equal to 0, or the start of the program. Still running, it does it again, and again, and so on.

This is really the most it can handle. JMPing doesn't work.

My plan

I plan for this project to continue, I am really happy with it and I will clean it up and will try to make everything work on it! However, I will downscale it from 8 bit to 4 bit, since it would be much easier to re-do and try and learn from it, instead of jumping into this.