Searched Projects

This is an example implementation of the uCISC instruction set as defined at https://github.com/grokthis/ucisc. So far it implements the Copy and ALU instructions. Note that multiplication, division and floating point ALU operations are not currently supported. This processor is enough to execute real programs.

The EEPROM is programmed with the fibonacci calculation found in the uCISC examples.

My 4 Bit CPU, Not very standard so it might not actually be a CPU yet. **Made By Ben W.**

This is a CPU witch is capable of executing a lot of stuff in one clock cycle, and this CPU can shift left up to 7 times and shift right up to 7 times witch means that it is possible to  multiply and divide in one clock cycle if you program a table in the program memory. it has a 32 bit instruction width and a 8 bit address. it also has 

The ALU has the following operations:

• ADD
• SUBTRACT
• SHIFT_LEFT (up to 7 times per cycle 3 bit)
  
• SHIFT_RIGHT (up to 7 times per cycle 3 bit)
  
• XOR
• OR
• NOT

This Was made by miles

Working CPU with eight 8-bit registers and eleven commands. Instructions in the project, command list below.

Commands:

LDA r - loads value from register r into accumulator
STA r - stores accumulator value in register r
CLR r - clears register r
INC r - increments the value of register r and replaces into r
DEC r - decrements the value of register r and replaces into r
COM r - stores the complement of the value in register r in the accumulator
ADD r - adds value in register r to the accumulator
SUB r - subtracts accumulator value from value in register r, replaces into accumulator
AND r - stores value of (accumulator AND r) in accumulator
IOR r - stores value of (accumulator OR r) in accumulator [inclusive or]
XOR r - stores value of (accumulator XOR r) in accumulator [exclusive or]

*Eight 8-bit registers: r must be a value between 0 and 7 and refers to the address of the register, not its contents*

A computer made completely out of logic gates. Version 2. V1 can be found here: https://circuitverse.org/users/13948/projects/49969

Because of the limitations of the circuitverse.org simulator, and for easier use, some inbuilt components are used (like the 256-byte RAM module), but most of it is made up of OR, AND, NOT, XOR, NOR and NAND.

This project was originally made for my profile project. This is (or will be) version 2 of the 8-bit computer.

Yet Another Ben Eater Inspired Simple As Possible System

I'm following along with the excellent YouTube instructional series Building an 8-bit breadboard computer! by Ben Eater.

Note that he credits the book "Digital Computer Electronics" by Albert Paul Mauvino for many of the SAP (Simple As Possible) ideas.

I'm mostly keeping it the same as his computer except:

• I decided to have an 8-bit address space rather than 4-bits. 
• Indirect mode instructions require another register.
• Instructions only take as many clock cycles as they need as opposed to each instruction taking the same number of cycles and shorter instructions wasting the leftover cycles.
• I didn't implement the hex or digital multi-segment displays... man that looked tedious!
• I ended up having to do the microcode using combinational logic rather than EEPROM as the circuitverse EEPROM currently only supports 8 address lines and I needed at least 10
  
• I added 8 bit x 8 bit multiplication. This also involves a second accumulator register which is used with the primary accumulator to house the 16 bit result.

I finally did it.
I made my own 8-bit CPU! With a bit of inspiration from other CircuitVerse projects and from a book called, Digital Computer Electronics.
The premade program does this: 12 + 6 - 3 + 2 (which equals 17)

program the computer by typing in the opcodes in the ROM

Opcodes: (X = address)
0X = Load X's value to Accumulator
1X = Add X's value to Accumulator
2x = Subtract X's value from Accumulator
ee = Take Accumulator's value and put it in the Output
ff = Halt/stop everything

Versions (Date format: DD/MM)
9/11 v1.0 - Finally finished it!

Latest versions of the 256-Series, including the Femto-4:
https://circuitverse.org/users/4699/projects/256-series

A 16-bit computer/maybe console inspired thing, the Femto-4. This is a fork from the main branch to keep a semi-functional version around. This project was started around November 2020.

Currently runs:
Test code demonstrating basic functionality. First it uses most instructions to ensure they work, before showing the graphical capabilities of the computer.

Features:
Immediate, direct and indirect memory access
Jumps and conditional Jumps
16-bit address space
Switchable Memory Banks
An ALU capable of logical operators, addition, subtraction and shift left
Easy to add to buses
"Fast Execution" - Can run more than one instruction per clock cycle
15x15 pixel display

Will have:
An ALU capable of shift right and multiplying
Inputs, both "controllers" and keyboards
"Faster Execution" - Runs instructions on both edges of the clock pulse 
Random number register
Text outputs
Stack
Assembler (hopefully)
Save memory
Several pre-written carts to play with

General Architecture:
The Femto-4 has variable length instructions that are comprised of multiple 16-bit chunks. First the OP Code of the instruction is read, and then depending on the OP Code, additional pieces of data may be read for the operands. This allows execution to become incorrectly offset, which can lead to the execution of garbage if the PC is jumped to an incorrect address. This is usually fine, since the OP Code space is so empty that the data will likely be passed one at a time until the next valid instruction. Data is read through the standard data retrieval system (which is handy since its design is so universal and easy to add to) making this architecture a Von Neuman architecture as opposed to a Harvard architecture, like my previous, worse, computer. The MAR always specifies the address being read to or written from, whilst the MDR always holds the data being written. Data from the data out bus can be written to any special register during the instruction. OP Codes and operands are all 16-bits, which is a bit wasteful in terms of OP Code usage, however it was easier to implement this way, and so that is what I went with. 

Memory Mapping:
The 16-bit address space of the Femto-4 is memory mapped, with all data being stored somewhere in the address space, including many special registers like the program counter and the Memory Address Register. The last 48kx16b of memory (all addresses starting with 01, 10, or 11) are dedicated to the cart memory. This is where the interchangeable program would be stored, allowing programs to be easily changed by changing carts. (However, currently there is only one cart). The carts have 32 16kx16b EEPROM/RAM chips, which can be switched between during execution by writing to address 00cc (subject to change). This gives each cart 512kx16b of memory to play with. In theory, additional memory can be added in a cart by creating a similar system on the inside of the cart, which would allow it to swap between even more EEPROM/RAM chips. The initial 16kx16b are therefore mapped to everything else, including a fixed "work" RAM chip that cannot be switched out, the bootloader, the PPU data, general use registers and special use registers. 

"Fast Execution":
Execution at the fastest clock speed (one pulse every 50ms, or 20Hz) is terribly slow, and would make reasonable graphics effectively impossible. Due to this, the Femto-4 includes several execution modes that allow the computer to run much faster. There are two registers involved in this, address 00ca, the mode register, and address 00cb, the protection register. When the least significant bit of the mode register is low, the computer runs normally, executing 1 instruction per clock pulse. When it is set high however, the computer enters fast execution, where it executes multiple instructions per clock pulse. This is achieved by looping a rising edge monostable circuit into a falling edge monostable circuit, producing a loop that will pulse indefinitely until the looping line is written high too by some external factor. Stopping the loop is critical since leaving the loop running will stop CircuitVerse's execution, due to it going over the stack limit of the execution. "Fast execution" is always paused by a 0000 OP Code, which ensures that the computer will not attempt to "fast execute" memory that has not been written to. Setting the second bit of the mode register will enable protection. This will ensure that computer only executes as many instructions as the value in the protection register. This protects execution by ensuring that the loop will always pause before the cycle limit is reached. A value of 8 works consistently, though I have not toyed with values much higher. In future, additional execution options will likely be made available, the current planned ones being enabling falling edge execution as well as rising edge execution, to double the execution speed, updating graphics on both edges of the clock pulse, updating graphics every other clock pulse, updating graphics when the update graphics command is run, and disabling graphics. 

Graphics:
The Femto-4 is capable of driving a 15x15 15bit direct colour screen. It has space for 32 "sprites" which are rectangles with an assigned colour. Currently, every time the clock pulses low, the screen is refreshed. Should a falling edge "fast execution" mode be added and work, the falling edge should only be used to execute game code, since writing graphics data as the screen is being drawn may mess up the graphics. These 32 "sprites" have their data stored in the PPU RAM in the following format: The first 16 bits are the corners of the rectangle, with each coordinate being 4 bits. The coordinates are ordered x1 x2 y1 y2. The next 16 bits are the sprites colour, with the first 15 bits being used for 15 bit direct colour, and the last bit being used to enable or disable drawing the sprite. Since the screen is not wiped every time it is refreshed, the background must be sprite to ensure that the screen is fully wiped before the rest of the sprites are drawn on. The "sprites" are drawn in memory order, with the "sprite" with the largest address always being drawn last and therefore on top, of all other "sprites". This is achieved by using the exact same monostable clock system as "Fast Execution", which reads off all the sprite data and draws them to the screen in a single clock pulse. This can loop more times safely than the main CPU since it has less dependencies which dramatically increase the simulation's stack usage. The demonstration code uses two "sprites". The first "sprite" is the black background, and the second "sprite" is the red rectangle. The coordinate value of the red rectangle is incremented every frame, causing the animation. Had I had more storage I might have incremented the colour as well to show the colour capabilities of the Femto-4. Whilst driving a larger screen might be nice, given the limit in the number of instructions per second, it is unlikely that it could be well utilised, which is why I have chosen this screen size. A variation with larger screens may appear at some point, but this is a low priority for me. 

ALU:
The basic ALU (currently the only implemented bit of the ALU) was inspired by the ALU-74LS181. It was designed to flexibly change between various operations by changing an additional piece of data which is bundled in the OP Code. This allows a single ALU to handle all the required processes, such as the basic binary logic operations, shift right, adding and subtracting. This is unlike my previous computer which had different chips for each operation it could do. Additional capability chips, such as multiplication and shifting right will be added later. 

General Registers:
This computer probably has more general registers than it should. What makes the 256 general registers unique is that they can be easily piped into the A and B operators when performing ALU operations. This allows ALU instructions to only have one operand, with the lower 8-bits being the register address of value A, and with the higher 8-bits being the register address of value B. 

Timing:
This computer is timed using a several standard delay chips. The pulse length running in to the computer is about 10k units long. This then runs into the pulse generator which pulses 32 unique lines with a 20k delay between them which can then be used to time when control lines pulse. This is bundled together into a 32-bit timing bus, which then uses bit selectors to select how much delay that pulse will have. This is why there are 32 sub-circuits which are effectively just bit specific bit selectors - they allow me to "compactly" build timing circuitry. In addition to the main delay of 20k between the chosen bits, I can add "on-delays" to further delay the control line, allowing me to ensure that control lines like the enable read line can be on before the register reads from them. "On-delays" were first constructed to ensure that the data out line did not have contention issues - it ensured that the previous address outputting data was disabled before the next address outputting data onto the line was enabled. They add 1k of delay on the rising edge, and less than 10 delay on the falling edge. This way I do not need to worry about "on-delays" increasing the delay of one command into the next. The "Fast Execution" loop gives a pulse of 300k, with a delay between pulses of around 600k. This ensures that the previous instruction will finish before the next instruction starts. I do not entirely understand how the timing system works, since the in my mind it should be producing contention issues, however proofing it against that breaks the system entirely. 

Other Notes:
You may note that I use 32b EEPROM banks instead of 16b ones. This choice was made to reduce the number of EEPROM banks required. Each half of the EEPROM's 32b output is treated as one address. Whilst this added a slight bit of additional complexity in writing, it halved the number of EEPROM banks required. This project was started when I realised that EEPROM banks could be that large, since a major sticking point in a previous attempt was the number of EEPROM banks required. (That attempt is private and completely dysfunctional. It also suffers from contention errors caused by incomplete splitters.)

Latest versions of the 256-Series, including the Femto-4:
https://circuitverse.org/users/4699/projects/256-series

A 16-bit computer/maybe console inspired thing, the Femto-4. This is a fork from the main branch to keep a semi-functional version around. This project was started around November 2020.

Currently runs:
Test "Hello World" code demonstrating text input and output functionality of the computer. Once the computer has outputted "Hello World! Type something!" it will shift in any input from the keyboard into the text output.

Features:
Immediate, direct and indirect memory access
Jumps and conditional Jumps
16-bit address space
Switchable Memory Banks
An ALU capable of logical operators, addition, subtraction and shift left
Easy to add to buses
"Fast Execution" - Can run more than one instruction per clock cycle
15x15 pixel display

Updates:
Inputs, both "controllers" and keyboards
"Faster Execution" - Runs instructions on both edges of the clock pulse 
Random number register
Text outputs

Will have:
An ALU capable of shift right and multiplying
Stack
Assembler (hopefully)
Save memory
Several pre-written carts to play with
Maybe separate GPU to help with graphics handling

General Architecture:
The Femto-4 has variable length instructions that are comprised of multiple 16-bit chunks. First the OP Code of the instruction is read, and then depending on the OP Code, additional pieces of data may be read for the operands. This allows execution to become incorrectly offset, which can lead to the execution of garbage if the PC is jumped to an incorrect address. This is usually fine, since the OP Code space is so empty that the data will likely be passed one at a time until the next valid instruction. Data is read through the standard data retrieval system (which is handy since its design is so universal and easy to add to) making this architecture a Von Neuman architecture as opposed to a Harvard architecture, like my previous, worse, computer. The MAR always specifies the address being read to or written from, whilst the MDR always holds the data being written. Data from the data out bus can be written to any special register during the instruction. OP Codes and operands are all 16-bits, which is a bit wasteful in terms of OP Code usage, however it was easier to implement this way, and so that is what I went with. 

Memory Mapping:
The 16-bit address space of the Femto-4 is memory mapped, with all data being stored somewhere in the address space, including many special registers like the program counter and the Memory Address Register. The last 48kx16b of memory (all addresses starting with 01, 10, or 11) are dedicated to the cart memory. This is where the interchangeable program would be stored, allowing programs to be easily changed by changing carts. (However, currently there is only one cart). The carts have 32 16kx16b EEPROM/RAM chips, which can be switched between during execution by writing to address 00cc (subject to change). This gives each cart 512kx16b of memory to play with. In theory, additional memory can be added in a cart by creating a similar system on the inside of the cart, which would allow it to swap between even more EEPROM/RAM chips. The initial 16kx16b are therefore mapped to everything else, including a fixed "work" RAM chip that cannot be switched out, the bootloader, the PPU data, general use registers and special use registers. 

"Fast Execution":
Execution at the fastest clock speed (one pulse every 50ms, or 20Hz) is terribly slow, and would make reasonable graphics effectively impossible. Due to this, the Femto-4 includes several execution modes that allow the computer to run much faster. There are two registers involved in this, address 00ca, the mode register, and address 00cb, the protection register. When the least significant bit of the mode register is low, the computer runs normally, executing 1 instruction per clock pulse. When it is set high however, the computer enters fast execution on the rising edge, where it executes multiple instructions per clock pulse. This is achieved by looping a rising edge monostable circuit into a falling edge monostable circuit, producing a loop that will pulse indefinitely until the looping line is written high too by some external factor. Stopping the loop is critical since leaving the loop running will stop CircuitVerse's execution, due to it going over the stack limit of the execution. "Fast execution" is always paused by a 0000 OP Code, which ensures that the computer will not attempt to "fast execute" memory that has not been written to. Setting the 3 bit of the mode register high will enable protection. This will ensure that computer only executes as many instructions as the value in the protection register. This protects execution by ensuring that the loop will always pause before the cycle limit is reached. A value of hex 10 (16) is the highest value I have found to work. Setting the 2nd bit of the mode register high will enable the clock to run fast execution on the falling edge of the clock as well, doubling execution speed. This raises the max execution speed to 640 instructions per second. On the other end of the mode register are the graphics mode. The highest two bits give the graphics update mode, 00 for rising edge only (normal speed), 01 for duel edge (double speed), 10 for every other clock pulse (half speed), and 11 for when given the correct OP Code (controlled updates). The OP Code used for the graphics update is (01). The third most significant bit is the graphics disable bit. Setting it high stops updating the graphics.

Graphics:
The Femto-4 is capable of driving a 15x15 15bit direct colour screen. It has space for 32 "sprites" which are rectangles with an assigned colour. Currently, every time the clock pulses low, the screen is refreshed. Should a falling edge "fast execution" mode be added and work, the falling edge should only be used to execute game code, since writing graphics data as the screen is being drawn may mess up the graphics. These 32 "sprites" have their data stored in the PPU RAM in the following format: The first 16 bits are the corners of the rectangle, with each coordinate being 4 bits. The coordinates are ordered x1 x2 y1 y2. The next 16 bits are the sprites colour, with the first 15 bits being used for 15 bit direct colour, and the last bit being used to enable or disable drawing the sprite. Since the screen is not wiped every time it is refreshed, the background must be sprite to ensure that the screen is fully wiped before the rest of the sprites are drawn on. The "sprites" are drawn in memory order, with the "sprite" with the largest address always being drawn last and therefore on top, of all other "sprites". This is achieved by using the exact same monostable clock system as "Fast Execution", which reads off all the sprite data and draws them to the screen in a single clock pulse. This can loop more times safely than the main CPU since it has less dependencies which dramatically increase the simulation's stack usage. The demonstration code uses two "sprites". The first "sprite" is the black background, and the second "sprite" is the red rectangle. The coordinate value of the red rectangle is incremented every frame, causing the animation. Had I had more storage I might have incremented the colour as well to show the colour capabilities of the Femto-4. Whilst driving a larger screen might be nice, given the limit in the number of instructions per second, it is unlikely that it could be well utilised, which is why I have chosen this screen size. A variation with larger screens may appear at some point, but this is a low priority for me. 

ALU:
The basic ALU (currently the only implemented bit of the ALU) was inspired by the ALU-74LS181. It was designed to flexibly change between various operations by changing an additional piece of data which is bundled in the OP Code. This allows a single ALU to handle all the required processes, such as the basic binary logic operations, shift right, adding and subtracting. This is unlike my previous computer which had different chips for each operation it could do. Additional capability chips, such as multiplication and shifting right will be added later. 

General Registers:
This computer probably has more general registers than it should. What makes the 256 general registers unique is that they can be easily piped into the A and B operators when performing ALU operations. This allows ALU instructions to only have one operand, with the lower 8-bits being the register address of value A, and with the higher 8-bits being the register address of value B. 

Timing:
This computer is timed using a several standard delay chips. The pulse length running in to the computer is about 10k units long. This then runs into the pulse generator which pulses 32 unique lines with a 20k delay between them which can then be used to time when control lines pulse. This is bundled together into a 32-bit timing bus, which then uses bit selectors to select how much delay that pulse will have. This is why there are 32 sub-circuits which are effectively just bit specific bit selectors - they allow me to "compactly" build timing circuitry. In addition to the main delay of 20k between the chosen bits, I can add "on-delays" to further delay the control line, allowing me to ensure that control lines like the enable read line can be on before the register reads from them. "On-delays" were first constructed to ensure that the data out line did not have contention issues - it ensured that the previous address outputting data was disabled before the next address outputting data onto the line was enabled. They add 1k of delay on the rising edge, and less than 10 delay on the falling edge. This way I do not need to worry about "on-delays" increasing the delay of one command into the next. The "Fast Execution" loop gives a pulse of 300k, with a delay between pulses of around 600k. This ensures that the previous instruction will finish before the next instruction starts. I do not entirely understand how the timing system works, since the in my mind it should be producing contention issues, however proofing it against that breaks the system entirely. 

Other Notes:
You may note that I use 32b EEPROM banks instead of 16b ones. This choice was made to reduce the number of EEPROM banks required. Each half of the EEPROM's 32b output is treated as one address. Whilst this added a slight bit of additional complexity in writing, it halved the number of EEPROM banks required. This project was started when I realised that EEPROM banks could be that large, since a major sticking point in a previous attempt was the number of EEPROM banks required. (That attempt is private and completely dysfunctional. It also suffers from contention errors caused by incomplete splitters.) The memory wrappers allow external chips to interact with the main dat control system, in this case used for RNG, controllers, the keyboard, and driving the text output. 

Latest versions of the 256-Series, including the Femto-4:
https://circuitverse.org/users/4699/projects/256-series

A 16-bit computer/maybe console inspired thing, the Femto-4. This is a fork from the main branch to keep a semi-functional version around. This project was started around November 2020.

Currently runs:
Outputs the twelve days of Christmas into the text output. 

Features:
Immediate, direct and indirect memory access
Jumps and conditional Jumps
16-bit address space
Switchable Memory Banks
An ALU capable of logical operators, addition, subtraction and shift left
Easy to add to buses
"Fast Execution" - Can run more than one instruction per clock cycle
15x15 pixel display

Updates:
Inputs, both "controllers" and keyboards
"Faster Execution" - Runs instructions on both edges of the clock pulse 
Random number register
Text outputs

Will have:
An ALU capable of shift right and multiplying
Stack
Assembler (hopefully)
Save memory
Several pre-written carts to play with
Maybe separate GPU to help with graphics handling

General Architecture:
The Femto-4 has variable length instructions that are comprised of multiple 16-bit chunks. First the OP Code of the instruction is read, and then depending on the OP Code, additional pieces of data may be read for the operands. This allows execution to become incorrectly offset, which can lead to the execution of garbage if the PC is jumped to an incorrect address. This is usually fine, since the OP Code space is so empty that the data will likely be passed one at a time until the next valid instruction. Data is read through the standard data retrieval system (which is handy since its design is so universal and easy to add to) making this architecture a Von Neuman architecture as opposed to a Harvard architecture, like my previous, worse, computer. The MAR always specifies the address being read to or written from, whilst the MDR always holds the data being written. Data from the data out bus can be written to any special register during the instruction. OP Codes and operands are all 16-bits, which is a bit wasteful in terms of OP Code usage, however it was easier to implement this way, and so that is what I went with. 

Memory Mapping:
The 16-bit address space of the Femto-4 is memory mapped, with all data being stored somewhere in the address space, including many special registers like the program counter and the Memory Address Register. The last 48kx16b of memory (all addresses starting with 01, 10, or 11) are dedicated to the cart memory. This is where the interchangeable program would be stored, allowing programs to be easily changed by changing carts. (However, currently there is only one cart). The carts have 32 16kx16b EEPROM/RAM chips, which can be switched between during execution by writing to address 00cc (subject to change). This gives each cart 512kx16b of memory to play with. In theory, additional memory can be added in a cart by creating a similar system on the inside of the cart, which would allow it to swap between even more EEPROM/RAM chips. The initial 16kx16b are therefore mapped to everything else, including a fixed "work" RAM chip that cannot be switched out, the bootloader, the PPU data, general use registers and special use registers. 

"Fast Execution":
Execution at the fastest clock speed (one pulse every 50ms, or 20Hz) is terribly slow, and would make reasonable graphics effectively impossible. Due to this, the Femto-4 includes several execution modes that allow the computer to run much faster. There are two registers involved in this, address 00ca, the mode register, and address 00cb, the protection register. When the least significant bit of the mode register is low, the computer runs normally, executing 1 instruction per clock pulse. When it is set high however, the computer enters fast execution on the rising edge, where it executes multiple instructions per clock pulse. This is achieved by looping a rising edge monostable circuit into a falling edge monostable circuit, producing a loop that will pulse indefinitely until the looping line is written high too by some external factor. Stopping the loop is critical since leaving the loop running will stop CircuitVerse's execution, due to it going over the stack limit of the execution. "Fast execution" is always paused by a 0000 OP Code, which ensures that the computer will not attempt to "fast execute" memory that has not been written to. Setting the 3 bit of the mode register high will enable protection. This will ensure that computer only executes as many instructions as the value in the protection register. This protects execution by ensuring that the loop will always pause before the cycle limit is reached. A value of hex 10 (16) is the highest value I have found to work. Setting the 2nd bit of the mode register high will enable the clock to run fast execution on the falling edge of the clock as well, doubling execution speed. This raises the max execution speed to 640 instructions per second. On the other end of the mode register are the graphics mode. The highest two bits give the graphics update mode, 00 for rising edge only (normal speed), 01 for duel edge (double speed), 10 for every other clock pulse (half speed), and 11 for when given the correct OP Code (controlled updates). The OP Code used for the graphics update is (01). The third most significant bit is the graphics disable bit. Setting it high stops updating the graphics.

Graphics:
The Femto-4 is capable of driving a 15x15 15bit direct colour screen. It has space for 32 "sprites" which are rectangles with an assigned colour. Currently, every time the clock pulses low, the screen is refreshed. Should a falling edge "fast execution" mode be added and work, the falling edge should only be used to execute game code, since writing graphics data as the screen is being drawn may mess up the graphics. These 32 "sprites" have their data stored in the PPU RAM in the following format: The first 16 bits are the corners of the rectangle, with each coordinate being 4 bits. The coordinates are ordered x1 x2 y1 y2. The next 16 bits are the sprites colour, with the first 15 bits being used for 15 bit direct colour, and the last bit being used to enable or disable drawing the sprite. Since the screen is not wiped every time it is refreshed, the background must be sprite to ensure that the screen is fully wiped before the rest of the sprites are drawn on. The "sprites" are drawn in memory order, with the "sprite" with the largest address always being drawn last and therefore on top, of all other "sprites". This is achieved by using the exact same monostable clock system as "Fast Execution", which reads off all the sprite data and draws them to the screen in a single clock pulse. This can loop more times safely than the main CPU since it has less dependencies which dramatically increase the simulation's stack usage. The demonstration code uses two "sprites". The first "sprite" is the black background, and the second "sprite" is the red rectangle. The coordinate value of the red rectangle is incremented every frame, causing the animation. Had I had more storage I might have incremented the colour as well to show the colour capabilities of the Femto-4. Whilst driving a larger screen might be nice, given the limit in the number of instructions per second, it is unlikely that it could be well utilised, which is why I have chosen this screen size. A variation with larger screens may appear at some point, but this is a low priority for me. 

ALU:
The basic ALU (currently the only implemented bit of the ALU) was inspired by the ALU-74LS181. It was designed to flexibly change between various operations by changing an additional piece of data which is bundled in the OP Code. This allows a single ALU to handle all the required processes, such as the basic binary logic operations, shift right, adding and subtracting. This is unlike my previous computer which had different chips for each operation it could do. Additional capability chips, such as multiplication and shifting right will be added later. 

General Registers:
This computer probably has more general registers than it should. What makes the 256 general registers unique is that they can be easily piped into the A and B operators when performing ALU operations. This allows ALU instructions to only have one operand, with the lower 8-bits being the register address of value A, and with the higher 8-bits being the register address of value B. 

Timing:
This computer is timed using a several standard delay chips. The pulse length running in to the computer is about 10k units long. This then runs into the pulse generator which pulses 32 unique lines with a 20k delay between them which can then be used to time when control lines pulse. This is bundled together into a 32-bit timing bus, which then uses bit selectors to select how much delay that pulse will have. This is why there are 32 sub-circuits which are effectively just bit specific bit selectors - they allow me to "compactly" build timing circuitry. In addition to the main delay of 20k between the chosen bits, I can add "on-delays" to further delay the control line, allowing me to ensure that control lines like the enable read line can be on before the register reads from them. "On-delays" were first constructed to ensure that the data out line did not have contention issues - it ensured that the previous address outputting data was disabled before the next address outputting data onto the line was enabled. They add 1k of delay on the rising edge, and less than 10 delay on the falling edge. This way I do not need to worry about "on-delays" increasing the delay of one command into the next. The "Fast Execution" loop gives a pulse of 300k, with a delay between pulses of around 600k. This ensures that the previous instruction will finish before the next instruction starts. I do not entirely understand how the timing system works, since the in my mind it should be producing contention issues, however proofing it against that breaks the system entirely. 

Other Notes:
You may note that I use 32b EEPROM banks instead of 16b ones. This choice was made to reduce the number of EEPROM banks required. Each half of the EEPROM's 32b output is treated as one address. Whilst this added a slight bit of additional complexity in writing, it halved the number of EEPROM banks required. This project was started when I realised that EEPROM banks could be that large, since a major sticking point in a previous attempt was the number of EEPROM banks required. (That attempt is private and completely dysfunctional. It also suffers from contention errors caused by incomplete splitters.) The memory wrappers allow external chips to interact with the main dat control system, in this case used for RNG, controllers, the keyboard, and driving the text output. 

Reference to ComputerOrganisationAndDesign 4:4.

This CPU is capable of executing the following instructions.

• lw
  
• sw
• bne
• add
• sub
• and
• or
• slt
• j

Latest versions of the 256-Series, including the Femto-4:
https://circuitverse.org/users/4699/projects/256-series

A 16-bit computer/maybe console inspired thing, the Femto-4. This is a fork from the main branch to keep a semi-functional version around. This project was started around November 2020.

Currently runs:
Cart A: Flappy Bird
Cart B: Some Pixel Art
Cart C: Screensaver

Assembler:
https://repl.it/@Sanderokianstfe/Femto-4-Assembler#DeveloperGuide.txt

Features:
Immediate, direct and indirect memory access
Jumps and conditional Jumps
16-bit address space
Switchable Memory Banks, allowing for a standard Cart to hold up to 512kx16b of data
An ALU capable of logical operators, addition, subtraction and shift left
Easy to add to buses
"Fast Execution" - Can run more than one instruction per clock cycle
16x16 pixel display
Inputs, both "controllers" and keyboards
"Faster Execution" - Runs instructions on both edges of the clock pulse 
Random number generator
Text outputs
An ALU capable of shift right, multiplying, dividing, and other specialised functions
Stack
Assembler (written in an external program)
Save memory
Two pre-written carts to play with
Fixed code controlled graphics updates
Made Bootloader clear TTY, Keyboard, and Controller Pushed
Fixed Register ALU instructions
Updated Cart A and Cart B to make use of the Register ALU instructions

Updates:
Another pre-written cart to play with
Updated the sprite-art cart to respond to the start button on both controllers. 

Will have:
More pre-written carts
Bug fixes

Do fork the project and write your own code for it! If you want more information on how to do so read the Developer Guide in the assembler. 

Note:
The Flappy Bird high score is mine. If you want to save your own scores permanently you will have to fork it. 

General Architecture:
The Femto-4 has variable length instructions that are comprised of multiple 16-bit chunks. First the OP Code of the instruction is read, and then depending on the OP Code, additional pieces of data may be read for the operands. This allows execution to become incorrectly offset, which can lead to the execution of garbage if the PC is jumped to an incorrect address. This is usually fine, since the OP Code space is so empty that the data will likely be passed one at a time until the next valid instruction. Data is read through the standard data retrieval system (which is handy since its design is so universal and easy to add to) making this architecture a Von Neuman architecture as opposed to a Harvard architecture, like my previous, worse, computer. The MAR always specifies the address being read to or written from, whilst the MDR always holds the data being written. Data from the data out bus can be written to any special register during the instruction. OP Codes and operands are all 16-bits, which is a bit wasteful in terms of OP Code usage, however it was easier to implement this way, and so that is what I went with (and there are a lot of ALU processes). 

Memory Mapping:
The 16-bit address space of the Femto-4 is memory mapped, with all data being stored somewhere in the address space. The last 48kx16b of memory (all addresses starting with 01, 10, or 11) are dedicated to the cart memory. This is where the interchangeable program would be stored, allowing programs to be easily changed by changing carts. (However, currently there are currently only two carts). The carts have 32 16kx16b EEPROM/RAM chips, which can be switched between during execution by writing to address 00cc. This gives each cart 512kx16b of memory to play with. In theory, additional memory can be added in a cart by creating a similar system on the inside of the cart, which would allow it to swap between even more EEPROM/RAM chips. The initial 16kx16b are therefore mapped to everything else, including a fixed "work" RAM chip that cannot be switched out, the bootloader, the PPU data, general use registers, the, stack, inputs, outputs, and special use registers. 

"Fast Execution":
Execution at the fastest clock speed (one pulse every 50ms, or 20Hz) is terribly slow, and would make reasonable graphics effectively impossible. Due to this, the Femto-4 includes several execution modes that allow the computer to run much faster. There are two registers involved in this, address 00ca, the mode register, and address 00cb, the protection register. When the two least significant bits of the mode register are low, the computer runs normally, executing 1 instruction per clock pulse. When it is set high however, the computer enters fast execution on the rising edge, where it executes multiple instructions per clock pulse. This is achieved by looping a rising edge monostable circuit into a falling edge monostable circuit, producing a loop that will pulse indefinitely until the looping line is written high to by some external factor. Stopping the loop is critical since leaving the loop running will stop CircuitVerse's execution, due to it going over the stack limit of the execution. "Fast execution" is always paused by a 0x0000 OP Code, which ensures that the computer will not attempt to "fast execute" memory that has not been written to. It is also paused by the OP Code 0x0001. Setting the 3 bit of the mode register high will enable protection. This will ensure that computer only executes as many instructions as the value in the protection register. This protects execution by ensuring that the loop will always pause before the cycle limit is reached. Since some operations are far more complex than other operations, the maximum number of instructions per clock pulse is variable, and testing should always be conducted to ensure that the limit is not reached. Due to this, for games that need regular graphics updates, it is recommended that protection is not used, and instead the pauses are fully code controlled. Setting the 2nd bit of the mode register high will enable the clock to run fast execution on the falling edge of the clock as well, doubling execution speed. On the other end of the mode register are the graphics mode. The highest two bits give the graphics update mode, 00 for falling edge only (normal speed), 01 for dual edge (double speed), 10 for every other clock pulse (half speed), and 11 for code controlled, where the 0x0001 OP Code is required to update the graphics. The third most significant bit is the graphics disable bit. Setting it high stops updating the graphics. The mode and protection values are only updated on the rising edge of the clock pulse, and therefore there should always be pauses before and after any execution mode or protection change. 

Graphics:
The Femto-4 is capable of driving a 16x16 15bit direct colour screen. It has space for 32 "sprites" which are rectangles with an assigned colour. Currently, every time the clock pulses low, the screen is refreshed. When using dual-edge "Faster Execution", the falling edge should only be used to execute game code, since writing graphics data as the screen is being drawn may mess up the graphics. These 32 "sprites" have their data stored in the PPU RAM in the following format: The first 16 bits are the corners of the rectangle, with each coordinate being 4 bits. The coordinates are ordered x1 x2 y1 y2. The next 16 bits are the sprites colour, with the first 15 bits being used for 15 bit direct colour, and the last bit being used to enable or disable drawing the sprite. Since the screen is not wiped every time it is refreshed, the background must be sprite to ensure that the screen is fully wiped before the rest of the sprites are drawn on. Control of this allows carts to draw a single frame over multiple updates, allowing the 32-sprite limit to be bypassed. The "sprites" are drawn in memory order, with the "sprite" with the largest address always being drawn last and therefore on top, of all other "sprites". This is achieved by using the exact same monostable clock system as "Fast Execution", which reads off all the sprite data and draws them to the screen in a single clock pulse. This can loop more times safely than the main CPU since it has less dependencies which dramatically increase the simulation's stack usage. 

ALU:
The basic ALU was inspired by the ALU-74LS181. It was designed to flexibly change between various operations by changing an additional piece of data which is bundled in the OP Code. This allows a single ALU to handle all the required processes, such as the basic binary logic operations, shift left, adding, and subtracting. This is unlike my previous computer which had different chips for each operation it could do. The Femto-4 also can multiply, divide, shift right, shift left/right by a specified number of bits, and perform operations designed to work with the Femto-4's graphics data. 

Conditional Jumps:
The Femto-4 can perform immediate and direct jumps depending on the flags, a specified bit of the accumulator, and the clock. The flag jumps allow for comparisons to be made. There are three flags, the carry, the most significant bit in the accumulator, and if the accumulator value is 0, the equals flag. By performing A-B, we can compare A and B by looking at the flags. If the equals flag is true, then A=B, since A-B = 0. If the most significant bit is 0, then the number is positive or 0 (by two's complement) and therefore A>=B. The comparison is not entirely correct for numbers in two's complement (a large positive number and a large negative number when subtracted can yield a positive number), but for small values it works well. Whilst we cannot directly check A<=B using A-B in this design, we can simply flip the subtraction to B-A to do so. 
The accumulator bit testing is mainly used to check for controller inputs. Since each button in the controller is mapped to one bit, bit testing that bit effectively allows us to check if a button has been pressed. In theory a similar test could be performed using an AND instruction, and checking if the result is equal to 0 or not.
The jump on clock is there to ensure that we can jump execution on the right clock pulse, which ensures that graphics can be updated on the edge of execution. 

Timing:
This computer is timed using several standard delay chips. The pulse length running in to the computer is about 10k units long. Therefore, different parts an instruction are separated by 20k unit delays. Further control of timings inside these periods is achieved through 1k "On Delays", which have a 1k delay turning on, but a 0k delay turning off, ensuring that pulses do not bleed into the next pulse. For more information see here: https://circuitverse.org/users/4699/projects/circuitverse-delay-introduction. 

Other Notes:
The memory wrappers allow external chips to interact with the main data control system, in this case used for RNG, controllers, the keyboard, and driving the text output. 

For more information, please read the developer guide found in the Femto-4's Assembler, or just post a comment and ask me. 

This is a secret to everybody, unless you found it. 

Latest versions of the 256-Series, including the Femto-4:
https://circuitverse.org/users/4699/projects/256-series

A 16-bit computer/maybe console inspired thing, the Femto-4. This is a fork from the main branch to keep a semi-functional version around. This project was started around November 2020.

Currently runs:
Cart A: Flappy Bird
Cart B: Some Pixel Art

Assembler:
https://repl.it/@Sanderokianstfe/Femto-4-Assembler#DeveloperGuide.txt

Features:
Immediate, direct and indirect memory access
Jumps and conditional Jumps
16-bit address space
Switchable Memory Banks, allowing for a standard Cart to hold up to 512kx16b of data
An ALU capable of logical operators, addition, subtraction and shift left
Easy to add to buses
"Fast Execution" - Can run more than one instruction per clock cycle
16x16 pixel display
Inputs, both "controllers" and keyboards
"Faster Execution" - Runs instructions on both edges of the clock pulse 
Random number generator
Text outputs
An ALU capable of shift right, multiplying, dividing, and other specialised functions
Stack
Assembler (written in an external program)
Save memory
One pre-written cart to play with

Updates:
Another pre-written cart
Fixed code controlled graphics updates
Made Bootloader clear TTY, Keyboard, and Controller Pushed
Fixed Register ALU instructions
Updated Cart A and Cart B to make use of the Register ALU instructions

Will have:
More pre-written carts
Bug fixes

Do fork the project and write your own code for it! If you want more information on how to do so read the Developer Guide in the assembler. 

Note:
The Flappy Bird high score is mine. If you want to save your own scores permanently you will have to fork it. 

General Architecture:
The Femto-4 has variable length instructions that are comprised of multiple 16-bit chunks. First the OP Code of the instruction is read, and then depending on the OP Code, additional pieces of data may be read for the operands. This allows execution to become incorrectly offset, which can lead to the execution of garbage if the PC is jumped to an incorrect address. This is usually fine, since the OP Code space is so empty that the data will likely be passed one at a time until the next valid instruction. Data is read through the standard data retrieval system (which is handy since its design is so universal and easy to add to) making this architecture a Von Neuman architecture as opposed to a Harvard architecture, like my previous, worse, computer. The MAR always specifies the address being read to or written from, whilst the MDR always holds the data being written. Data from the data out bus can be written to any special register during the instruction. OP Codes and operands are all 16-bits, which is a bit wasteful in terms of OP Code usage, however it was easier to implement this way, and so that is what I went with (and there are a lot of ALU processes). 

Memory Mapping:
The 16-bit address space of the Femto-4 is memory mapped, with all data being stored somewhere in the address space. The last 48kx16b of memory (all addresses starting with 01, 10, or 11) are dedicated to the cart memory. This is where the interchangeable program would be stored, allowing programs to be easily changed by changing carts. (However, currently there are currently only two carts). The carts have 32 16kx16b EEPROM/RAM chips, which can be switched between during execution by writing to address 00cc. This gives each cart 512kx16b of memory to play with. In theory, additional memory can be added in a cart by creating a similar system on the inside of the cart, which would allow it to swap between even more EEPROM/RAM chips. The initial 16kx16b are therefore mapped to everything else, including a fixed "work" RAM chip that cannot be switched out, the bootloader, the PPU data, general use registers, the, stack, inputs, outputs, and special use registers. 

"Fast Execution":
Execution at the fastest clock speed (one pulse every 50ms, or 20Hz) is terribly slow, and would make reasonable graphics effectively impossible. Due to this, the Femto-4 includes several execution modes that allow the computer to run much faster. There are two registers involved in this, address 00ca, the mode register, and address 00cb, the protection register. When the two least significant bits of the mode register are low, the computer runs normally, executing 1 instruction per clock pulse. When it is set high however, the computer enters fast execution on the rising edge, where it executes multiple instructions per clock pulse. This is achieved by looping a rising edge monostable circuit into a falling edge monostable circuit, producing a loop that will pulse indefinitely until the looping line is written high to by some external factor. Stopping the loop is critical since leaving the loop running will stop CircuitVerse's execution, due to it going over the stack limit of the execution. "Fast execution" is always paused by a 0x0000 OP Code, which ensures that the computer will not attempt to "fast execute" memory that has not been written to. It is also paused by the OP Code 0x0001. Setting the 3 bit of the mode register high will enable protection. This will ensure that computer only executes as many instructions as the value in the protection register. This protects execution by ensuring that the loop will always pause before the cycle limit is reached. Since some operations are far more complex than other operations, the maximum number of instructions per clock pulse is variable, and testing should always be conducted to ensure that the limit is not reached. Due to this, for games that need regular graphics updates, it is recommended that protection is not used, and instead the pauses are fully code controlled. Setting the 2nd bit of the mode register high will enable the clock to run fast execution on the falling edge of the clock as well, doubling execution speed. On the other end of the mode register are the graphics mode. The highest two bits give the graphics update mode, 00 for falling edge only (normal speed), 01 for dual edge (double speed), 10 for every other clock pulse (half speed), and 11 for code controlled, where the 0x0001 OP Code is required to update the graphics. The third most significant bit is the graphics disable bit. Setting it high stops updating the graphics. The mode and protection values are only updated on the rising edge of the clock pulse, and therefore there should always be pauses before and after any execution mode or protection change. 

Graphics:
The Femto-4 is capable of driving a 16x16 15bit direct colour screen. It has space for 32 "sprites" which are rectangles with an assigned colour. Currently, every time the clock pulses low, the screen is refreshed. When using dual-edge "Faster Execution", the falling edge should only be used to execute game code, since writing graphics data as the screen is being drawn may mess up the graphics. These 32 "sprites" have their data stored in the PPU RAM in the following format: The first 16 bits are the corners of the rectangle, with each coordinate being 4 bits. The coordinates are ordered x1 x2 y1 y2. The next 16 bits are the sprites colour, with the first 15 bits being used for 15 bit direct colour, and the last bit being used to enable or disable drawing the sprite. Since the screen is not wiped every time it is refreshed, the background must be sprite to ensure that the screen is fully wiped before the rest of the sprites are drawn on. Control of this allows carts to draw a single frame over multiple updates, allowing the 32-sprite limit to be bypassed. The "sprites" are drawn in memory order, with the "sprite" with the largest address always being drawn last and therefore on top, of all other "sprites". This is achieved by using the exact same monostable clock system as "Fast Execution", which reads off all the sprite data and draws them to the screen in a single clock pulse. This can loop more times safely than the main CPU since it has less dependencies which dramatically increase the simulation's stack usage. 

ALU:
The basic ALU was inspired by the ALU-74LS181. It was designed to flexibly change between various operations by changing an additional piece of data which is bundled in the OP Code. This allows a single ALU to handle all the required processes, such as the basic binary logic operations, shift left, adding, and subtracting. This is unlike my previous computer which had different chips for each operation it could do. The Femto-4 also can multiply, divide, shift right, shift left/right by a specified number of bits, and perform operations designed to work with the Femto-4's graphics data. 

Conditional Jumps:
The Femto-4 can perform immediate and direct jumps depending on the flags, a specified bit of the accumulator, and the clock. The flag jumps allow for comparisons to be made. There are three flags, the carry, the most significant bit in the accumulator, and if the accumulator value is 0, the equals flag. By performing A-B, we can compare A and B by looking at the flags. If the equals flag is true, then A=B, since A-B = 0. If the most significant bit is 0, then the number is positive or 0 (by two's complement) and therefore A>=B. The comparison is not entirely correct for numbers in two's complement (a large positive number and a large negative number when subtracted can yield a positive number), but for small values it works well. Whilst we cannot directly check A<=B using A-B in this design, we can simply flip the subtraction to B-A to do so. 
The accumulator bit testing is mainly used to check for controller inputs. Since each button in the controller is mapped to one bit, bit testing that bit effectively allows us to check if a button has been pressed. In theory a similar test could be performed using an AND instruction, and checking if the result is equal to 0 or not.
The jump on clock is there to ensure that we can jump execution on the right clock pulse, which ensures that graphics can be updated on the edge of execution. 

Timing:
This computer is timed using several standard delay chips. The pulse length running in to the computer is about 10k units long. Therefore, different parts an instruction are separated by 20k unit delays. Further control of timings inside these periods is achieved through 1k "On Delays", which have a 1k delay turning on, but a 0k delay turning off, ensuring that pulses do not bleed into the next pulse. For more information see here: https://circuitverse.org/users/4699/projects/circuitverse-delay-introduction. 

Other Notes:
The memory wrappers allow external chips to interact with the main data control system, in this case used for RNG, controllers, the keyboard, and driving the text output. 

For more information, please read the developer guide found in the Femto-4's Assembler, or just post a comment and ask me. 

This is a secret to everybody, unless you found it. 

A 16-bit computer/maybe console inspired thing, the Femto-4. This will be the main branch and backups will be forks from it. This project was started around November 2020.

Currently runs: 

• Cart A: Flappy Bird 
• Cart B: Some Pixel Art 
• Cart C: Screensaver 
• Cart D: Snake 
• Cart E: Phemton Demonstrations 
• Cart F: Competitive Snake 
• Cart G: Tic Tac Toe 
• Cart H: Connect 4 
• Cart I: NIM
• Cart J: Bad Apple
• Bundle Cart: All carts in one 
• Cart 2A: 32x32 Snake
• Cart 2B: 32x32 Competitive Snake
• Cart 2C: 32x32 Pixel Art
• Cart 2D: 32x32 Bad Apple
• Bundle Cart 2: All 32x32 carts in one 

Assembler: 

• https://github.com/Comerstar/PhemtonCompiler/blob/main/Assembler/DeveloperGuide.txt

Compiler: 

• https://github.com/Comerstar/PhemtonCompiler/blob/main/PhemtonLiteCompiler/PhemtonDeveloperGuide.txt

The 256-Series: 

• https://circuitverse.org/users/4699/projects/256-series

Full screen Notes:

For some reason, the Femto-4v2.6 only is having issues around caching previous subcircuits. Should you need to use something to unbind key entries from the full screen button, toggle the clock. Previous versions are completely unaffected. 

Cart Notes: 

Cart A: 

• The first cart written for the Femto-4. 

Cart B: 

• The sprites in the cart are: 
• A: Femto-4 Logo. 
• B: Madeline from Celeste. 
• C: Madeline from Celeste (again). 
• D: Part of you aka Badeline from Celeste. 
• E: A strawberry from Celeste.
• F: Standing Mario from Super Mario Bros. 
• G: Jumping Mario from Super Mario Bros. 
• H: Standing Mario from Super Mario Bros 3. 
• I: Running Mario from Super Mario Bros 3. 
• J: Sanderokian (my own character). 

Cart C: 

• Enter anything into the keyboard to randomise the colours. 
• Enter r into the keyboard to reset the colours. 

Cart D: 

• WASD Pad is recommended. 
• Game settings (enter the letter before starting the game to use the setting): 
• e: toggle whether crashing into the edges results in a game over. 
• The two modes (with/without edge collisions) have two separate high scores. 
• w: change the snake's colour scheme to white. 
• r: change the snake's colour scheme to red. 
• y: change the snake's colour scheme to yellow. 
• o: change the snake's colour scheme to orange. 
• p: change the snake's colour scheme to purple. 
• a: change the snake's colour scheme to aqua. 
• g: change the snake's colour scheme to green. 
• b: change the snake's colour scheme to blue. 
• m: change the snake's colour scheme to magenta. 
• 1: change the snake's colour scheme to pink. 
• 2: change the snake's colour scheme to light blue. 
• 3: change the snake's colour scheme to the challenge colour scheme with an invisible body. 
• 0: randomise the snake's colour scheme. 

Cart E: 

• The test codes in the cart are: 
• 1: Hello World. 
• 2: Single Operator Calculator. 
• 3: Exponentiation Calculator. 
• 4: Fibonacci Calculator. 
• 5: Keyboard to TTY Test. 
• 6: Keyboard to TTY LDI LID Test. 
• 7: Keyboard to TTY LII Test. 
• 8: Keyboard to TTY LIA Test. 

Cart F: 

• WASD Pad is essentially required. 
• Game settings (enter the letter before starting the game to use the setting): 
• e: toggle whether crashing into the edges results in a game over. 
• w: toggle whether the number of wins each player has is tracked. 
• s: toggle whether the total score each player has scored is tracked. 
• d: display the total wins and total scored. 
• r: reset the tracked statistics. 

Cart G: 

• The small light in the corner indicates which player's turn it is. 
• When it is dimmed, it means that the computer is processing that player's turn. 
• Game settings (enter the letter before starting the game to use the setting): 
• w: toggle whether the number of wins each player has is tracked. 
• s: toggle automatic start player swapping. d: display the wins each player has. 
• r: reset the wins each player has. 

Cart H: 

• The bar at the top indicates which player's turn it is. 
• When it is dimmed, it means that the computer is processing that player's turn. 
• Game settings (enter the letter before starting the game to use the setting): 
• w: toggle whether the number of wins each player has is tracked. 
• s: toggle automatic start player swapping. 
• d: display the wins each player has. 
• r: reset the wins each player has.

Cart I:

• Game settings (enter the letter before starting the game to use the setting):
• w: toggle whether the number of wins each player has is tracked. 
• s: toggle automatic start player swapping. 
• d: display the wins each player has. 
• r: reset the wins each player has. 
• i: display the game instructions. 
• c: toggle the whether player 2 is played by the computer. 

Cart J:

• Plays Bad Apple
• There are no further controls

Cart 2A:

• The options are the same as Cart D. 

Cart 2B:

• The options are the same as Cart F. 

Cart 2C:

• The sprites in the cart are: 
• A: Femto-4 Logo. 
• B: Sanderokian (my own character). 
• C: Alstran (my own character). 

Cart 2D:

• Plays Bad Apple on the larger screen
• There are no further controls

Features: 

• Immediate, direct, & indirect memory access. 
• Jumps & conditional jumps. 
• 16-bit address space. 
• Switchable memory banks, allowing for a standard cart to hold up to 1MB of data. 
• An ALU capable of logical operators, addition, subtraction, shift left, shift right, multiplying, dividing, & other specialised functions. 
• Fast execution - can run more than one instruction per clock cycle. 
• 16x16 pixel display with 32 sprites and 15-bit direct colour. 
• 32x32 pixel display with 32 sprites which can have up to 18-bit direct colour. 
• Two controllers, a keyboard mapping for the controllers, & a keyboard for text inputs. 
• RNG, TTY, stack, & save memory. 
• Von Neumann Architecture. 
• Assembler & compiler (written in Python). 
• Twelve pre-written carts to play with. 

Updates: 

v1.0: 

• Finished the project and added Cart A. 

v1.1: 

• Added Cart B, some Pixel Art. 
• Fixed GRF, & AXR instructions. 
• Made Bootloader clear TTY, Keyboard, & Controller Pushed. 
• Updated Cart A & Cart B to make use of AXR instructions. 

v1.2: 

• Added Cart C, a Screensaver. 
• Updated Cart B to respond to the start button on both controllers. 

v1.3: 

• Added Cart D, Snake. 
• Moved to new project to fix issues around searching for projects branched from private projects. 
• Removed unnecessary EEPROM banks and write lines from all carts. 
• Made Reset clear WRAM and the General Registers. 

v1.4: 

• Fixed Keyboard. 
• Added a Bundle Cart that allows you to view all the carts without changing carts (you must reset the console to view another cart). 
• Fixed bug in the standard bank design which wrote data to incorrect addresses. 
• Fixed contention issue in Mult. 
• Added Annotations to the In Debug. 

v1.5: 

• Added Snake Player. 
• Added Reset & Power labels to the relevant buttons. 

v2.0: 

• Further optimisation to reduce lag/increase execution speed. 
• Added more memory access options. 

v2.1: 

• Further optimisation of the CU. 
• Added a keyboard to controller mapping. 

v2.2: 

• Continued optimisation and overhaul of the CU. 
• Removed old CU & compare circuits. 
• Added additional stack access instructions. 
• Updated the debug versions with the changes, as well as fixing bugs in the debug versions. 
• Designed a Logo for the Femto-4. 
• Rewrote Cart C to allow the sprites to be viewed in any order, and added the logo to it. 

v2.3: 

• Introducing Phemton Lite, the first version of the Femto-4's high level languages. 
• Added a link to Phemton Lite's compiler. 
• Added Cart E to demonstrate code written in Phemton Lite. 
• Combined SpecialD & ROMD1, and removed SpecialD & ROMDB. 
• Updated Snake code & Bundle code to match the new addresses. 
• Added Cart F, a competitive version of Snake. 
• Added an additional sprite into Cart B. 
• Fixed issues with LII, LXA & LXP instructions. 

v2.4: 

• Fixed alignment of the upper carts. 
• Added Cart G & Cart H, Tic Tac Toe & Connect 4 written in Phemton Lite. 
• Added progress lights to Cart G & Cart H. 
• Reworked bundle cart to make the code shorter and more efficient for large numbers of carts. 
• Made Cart G & Cart H faster. 
• Reshuffled Cart E test codes and added 2 Cart E test codes, exponentiation & Fibonacci calculation. 
• Added game options to Cart D, Cart F, Cart G, & Cart H. 
• Updated Cart C to allow the colours to be randomised. 
• Added optional colour schemes for Cart D. 
• Fixed Snake Player. 
• Remade the multiply and divide circuits to take advantage of the inbuilt adders. 
• Removed old MultM and DivM circuits. 

v2.5: 

• Further optimisation of the CU. 
• Optimisation of the fast execution clocks for the computer, the graphics, & the WASD Pad. 
• Fixed debug versions' issues with Phemton conditionals and added optimisations to the debug versions. 
• Added 32x32 screen PPU. 
• Added Cart 2A, Cart 2B, & Cart 2C, 32x32 versions of Snake, Competitive Snake, & Pixel Art. 
• Added Cart I, NIM written in Phemton Lite. 

v2.6

• Added the ability to directly write sprites to the PPU during execution.
• Significantly optimised the CU by removing unnecessary subcircuits.
• Introduced significant quantities of lazy evaluation to further improve performance.
• Added Cart J, and Cart 2D, which both play Bad Apple.
• The Femto-4 can now be added to the set of things that plays Bad Apple.

Future Updates: 

• More pre-written carts. 
• Bug fixes. 
• Adding an optimiser to the compiler. 
• Phemton Full. 
• Phemton Plus. 

Do fork the project and write your own code for it! If you want more information on how to do so read the Developer Guide in the assembler. 

Note: The Flappy Bird high score and the Snake high score are mine. If you want to save your own scores permanently you will have to fork the project. 

The Femto-4

General Architecture: The Femto-4 is a 16-bit, Von Neumann architecture computer with variable length instructions that are comprised of multiple 16-bit words. It has many features associated with CISCs, such as variable length instructions, and multicycle indirect loads, however operates like a RISC, with each instruction taking exactly 1 clock cycle. This was done to give the Femto-4 power whilst keeping its construction simple. First the OP code of the instruction is read, and then depending on the OP code, additional pieces of data may be read for the operands. This allows execution to become incorrectly offset, which can lead to the execution of garbage if the PC is jumped to an incorrect address. This is usually fine, since the OP code space is so empty that the data will likely be passed one at a time until the next valid instruction. Instructions are read from main memory, making this architecture a Von Neumann architecture as opposed to a Harvard architecture. The MAR always specifies the address being read to or written from, whilst the MDR always holds the data being written. Data from the data out bus can be written to most special registers during the instruction. OP codes and operands are all 16-bits. The large OP code size was chosen due to the high number of ALU instructions. There are approximately 500 interpretable OP codes that the computer can handle. 

Memory Mapping: The 16-bit address space of the Femto-4 is memory mapped, with all data being stored somewhere in the address space. The last 48kx16b of memory (all addresses starting with 0b01, 0b10, or 0b11) are dedicated to the cart memory. This is where the interchangeable program would be stored, allowing programs to be easily changed by changing carts. The carts have 32 16kx16b EEPROM/RAM chips, which can be switched between during execution by writing to address 0x00cc. This gives each cart 512kx16b of memory to play with. In theory, additional memory can be added in a cart by creating a similar system on the inside of the cart, which would allow it to swap between even more EEPROM/RAM chips. The initial 16kx16b are therefore mapped to everything else, including a fixed WRAM chip that cannot be switched out, the bootloader, the PPU data, general registers, the stack, inputs, outputs, and a few special registers, such as the protect, mode, and flag registers. 

Fast Execution: Execution at the fastest clock speed (one pulse every 100ms, or 10Hz, which is defined as the clock changing state every 50ms, or at a rate of 20Hz) is terribly slow, and would make reasonable graphics effectively impossible. Due to this, the Femto-4 includes several execution modes that allow the computer to run much faster. There are two registers involved in this, address 0x00ca, the mode register, and address 0x00cb, the protect register. When the two least significant bits of the mode register are low, the computer runs normally, executing 1 instruction per clock pulse. When bit 0 is set high, the computer enters fast execution on the rising edge, where it executes multiple instructions per clock pulse. This is achieved by looping an inverter into itself, producing a loop that will pulse indefinitely until the looping line is stopped by some external factor. Stopping the loop is critical since leaving the loop running will stop CircuitVerse's execution, due to it going over the stack limit of the execution. Fast execution is always paused by a 0x0000 and 0x0001 OP Code. Bit 2 enables falling edge fast execution, which can be done with rising edge fast execution producing dual edge fast execution. Setting the third bit of the mode register high will enable protection. This will ensure that computer only executes as many instructions as the value in the protect register. This protects execution by ensuring that the loop will always pause before the cycle limit is reached. Since some operations are far more complex than other operations, the maximum number of instructions per clock pulse is variable, and testing should always be conducted to ensure that the limit is not reached. Due to this, for games that need regular graphics updates, it is recommended that protection is not used, and instead the pauses are fully code controlled. On the other end of the mode register are the graphics mode. The highest two bits give the graphics update mode, 0b00 for falling edge only (normal speed), 0b01 for dual edge (double speed), 0b10 for every other clock pulse (half speed), and 0b11 for code controlled, where the 0x0001OP Code is required to update the graphics. The third most significant bit is the graphics disable bit. Setting it high stops updating the graphics, reducing lag by prevent the graphics fast execution loop from running. The mode and protection values are only updated on the rising edge of the clock pulse, and therefore there should always be pauses before and after any execution mode or protection change. By default, the Femto-4 executes with a protection value of 16, to allow the carts to run smoothly, however, depending on the instructions being used, that number can be raised to 64. 

Graphics (16x16): The Femto-4 is capable of driving a 16x16 15-bit direct colour screen. It has space for 32 sprites which are rectangles with an assigned colour. All the sprites are drawn to the screen whenever a graphics update occurs, depending on the graphics mode. When using dual-edge fast execution, the falling edge should only be used to execute game code, since writing graphics data as the screen is being drawn may mess up the graphics. These 32 sprites have their data stored in the PPU RAM in the following format: The first 16 bits are the corners of the rectangle, with each coordinate being 4 bits. The coordinates are ordered x coordinate 1 (4), x coordinate 2 (4), y coordinate 1 (4), y coordinate 2 (4). The second coordinates are offset up by 1, to allow the full screen to be drawn to, such that the dimensions of the rectangle are (x2 - x1) + 1 and (y2 - y1) + 1. The next 16 bits are the sprites colour, with the first 15 bits being used for 15-bit direct colour, and the last bit being used to enable or disable drawing the sprite. The last bit is important to ensure that blank sprites are not drawn to the screen. Since the screen is not wiped every time it is refreshed, the background must be a sprite to ensure that the screen is fully wiped before the rest of the sprites are drawn on. Control of this allows carts to draw a single frame over multiple updates, allowing the 32-sprite limit to be bypassed (see how Snake works). The sprites are drawn in memory order, with the sprite with the largest address always being drawn last and therefore on top, of all other sprites. This is achieved by using the exact same system as fast execution, which reads off all the sprite data and draws them to the screen in a single clock pulse. This can loop more times safely than the main CPU since it has less dependencies which dramatically decreases the simulation's stack usage. 

Graphics (32x32): The Femto-4 can also drive a 32x32 screen, with sprites able to be drawn through 3 different modes. The 32x32 screen PPU treats the addresses as one combined 32-bit value, with the value with the smaller address going first. The first 3 bits of the 32 bits define the mode. Only the values 1, 2, 3, correspond to actual sprites, whilst the rest are not drawn to the screen. Mode 1 splits the remaining 29-bit space as the following: unused (1), x coordinate (5), y coordinate (5), red (6), green (6), blue (6). Mode 2 splits the 29-bit space in the following way: x coordinate 1 (5), x coordinate 2 (5), y coordinate 1 (5), y coordinate 2 (5), red (3), green (3), blue (3). Mode 3 splits the 29-bit space in the following way: unused (3), x coordinate (5), y coordinate (5), red (5), green (5), blue (5), alpha/transparency (1). As with the 16x16 screen, Mode 2's second coordinates are offset by 1 resulting in rectangles having the dimensions of (x1 - x2) + 1 and (y1 - y2) + 1. Mode 3 is designed to allow the colours used in the 16x16 screen to be the same, making converting code between the two versions easier. The update mechanism is the same as 16x16 screen. 

ALU: The basic ALU was inspired by the ALU-74LS181. It was designed to flexibly change between various operations by changing an additional piece of data which is bundled in the OP code. This allows a single ALU to handle all the required processes, such as the basic binary logic operations, shift left, adding, and subtracting, reducing the number of circuits required, as well as the logic required to decide which instruction to use. The Femto-4 also can multiply, divide, shift right, shift left/right by a specified number of bits, and perform operations designed to work with the computer's graphics data. 

Conditional Jumps: The Femto-4 can perform immediate and direct jumps depending on the flags, a specified bit of the accumulator, and the clock. The flag jumps allow for comparisons to be made. There are three flags, the carry, the most significant bit in the accumulator, and if the accumulator value is 0, the equals flag. By performing A-B, we can compare A and B by looking at the flags. If the equals flag is true, then A=B, since A-B = 0. If the most significant bit is 0, then the number is positive or 0 (by two's complement) and therefore A>=B. The comparison is not entirely correct for numbers in two's complement (a large positive number and a large negative number when subtracted can yield a positive number), but for small values it works well. Whilst we cannot directly check A<=B using A-B in this design, we can simply flip the subtraction to B-A to do so. The accumulator bit testing is mainly used to check for controller inputs. Since each button in the controller is mapped to one bit, bit testing that bit effectively allows us to check if a button has been pressed. A similar test could be performed using an AND instruction, and checking if the result is equal to 0 or not. Bit testing is most useful for testing an input from both controllers, since it can cut out an additional instruction. The jump on clock is there to ensure that we can jump execution on the right clock pulse, which ensures that graphics can be updated on the edge of execution. 

Timing: The computer is timed using several standard delay chips. The pulse length running in to the computer is about 10k units long. Therefore, different parts an instruction are separated by 20k unit delays. Further control of timings inside these periods is achieved through 1k "On Delays", which have a 1k delay turning on, but a 0k delay turning off, ensuring that pulses do not bleed into the next pulse. These pulses can tell registers to write and what source to write from, enable the read and write lines, update the ALU, and update the stack Each instruction is separate by 600k of delay in fast execution. For more information on how delay works see here: https://circuitverse.org/users/4699/projects/circuitverse-delay-introduction. 

Keyboard Mapping: The Femto-4's keyboard controller mapping was created using a specialised chip. This chip used the fast execution loop to take 15 inputs from a keyboard and map the inputs to button presses on the controllers. Since the buttons are updated several times in a clock pulse, the keyboard controller cannot handle held buttons. The keyboard mapping is designed to work with both controllers, allowing two player games to be feasible on the computer. 

Assembly: The Femto-4 has an assembler that converts assembly written in a .txt into hex values in a .txt that can be copied and loaded into the EEPROM banks for storage. The assembler can handle symbol assignment, as well as assigning addresses in the code symbols to make handling jumps easier. For full details on the Femto-4's assembly language view the assembly developer guide. 

Phemton: Phemton is the Femto-4's high level language, with a compiler to compile it's code into Femto-4 assembly. Phemton handles variable memory assignment, basic array assignment, if, elif, else statments, while loops, for loops, and functions. Phemton Lite is the only compiler complete, and lacks an optimiser. Phemton Lite has the concept of local scope only when compiling. All uniquely identified variables are given a global address. This reduces the runtime load since the computer does not need to decide where the variables need to go during run time. Future planned additions include generated code optimisations and optimisers, Phemton Full, which has dynamic memory assignment, and Phemton Plus, which adds additional types for floats and longs. For more details view Phemton's developer guide. 

Other Notes: The memory wrappers allow external chips to interact with the main data control system, in this case used for RNG, controllers, the keyboard, and driving the text output. This makes it easy to additional chips to the computer. All assembly and Phemton code can be found in the project for the Femto-4's assembler and compiler respectively. The save data cart must be located outside of the Femto-4 circuit to ensure that its contents are automatically saved. Sorry about all the copies of this computer clogging up the top of the search results. 

For more information, please read the developer guide found in the Femto-4's Assembler, or just post a comment and ask me. 

This is a secret to everybody, unless you found it. 

A work in progress CPU. Any ideas would be helpful. 

Latest versions of the 256-Series, including the Femto-4:
https://circuitverse.org/users/4699/projects/256-series

A 16-bit computer/maybe console inspired thing, the Femto-4. This is a branch to keep a functional version around. This project was started around November 2020.

Currently runs:
Cart A: Flappy Bird
Cart B: Some Pixel Art
Cart C: Screensaver
Cart D: Snake
Bundle Cart: All carts in one

Assembler:
https://repl.it/@Sanderokianstfe/Femto-4-Assembler#DeveloperGuide.txt

Features:
Immediate, direct and indirect memory access
Jumps and conditional Jumps
16-bit address space
Switchable Memory Banks, allowing for a standard cart to hold up to 512kx16b of data
An ALU capable of logical operators, addition, subtraction, shift left, shift right, multiplying, dividing, and other specialised functions
Easy to add to buses
"Fast Execution" - Can run more than one instruction per clock cycle
"Faster Execution" - Runs instructions on both edges of the clock pulse 
16x16 pixel display with 32 "Sprites" and 15-bit direct colour
Inputs, both "controllers" and keyboards
Random number generator
Text outputs
Stack
Von Neumann Architecture
Assembler (written in an external program)
Save memory
Four pre-written carts to play with

Previous Updates:
Fixed code controlled graphics updates
Made Bootloader clear TTY, Keyboard, and Controller Pushed
Fixed Register ALU instructions
Updated Cart A and Cart B to make use of the Register ALU instructions
Updated the Cart B to respond to the start button on both controllers
Moved to new project to fix issues around searching for projects branched from private projects
Removed unnecessary EEPROM banks from all carts
Removed unnecessary write lines leading to EEPROMs in carts, preventing code from being overwritten during execution
Made Reset clear WRAM and the General Registers
Fixed Keyboard
Added a Bundle Cart that allows you to view all the carts I have made without changing carts (you must reset the console to view another cart)
Fixed bug in standard bank design which wrote data to incorrect addresses
Fixed contention issue with multiplying
Added Annotations to the In Debug

Updates:
Added Snake Player
Added Reset and Power Labels to the relevant buttons

Will have:
More pre-written carts
Bug fixes

Do fork the project and write your own code for it! If you want more information on how to do so read the Developer Guide in the assembler. 

Note:
The Flappy Bird high score and the Snake high score are mine. If you want to save your own scores permanently you will have to fork the project. 

General Architecture:
The Femto-4 is a 16-bit computer with variable length instructions that are comprised of multiple 16-bit words. First the OP Code of the instruction is read, and then depending on the OP Code, additional pieces of data may be read for the operands. This allows execution to become incorrectly offset, which can lead to the execution of garbage if the PC is jumped to an incorrect address. This is usually fine, since the OP Code space is so empty that the data will likely be passed one at a time until the next valid instruction. Data is read through the standard data retrieval system (which is handy since its design is so universal and easy to add to) making this architecture a Von Neumann architecture as opposed to a Harvard architecture, like my previous, worse, computer. The MAR always specifies the address being read to or written from, whilst the MDR always holds the data being written. Data from the data out bus can be written to any special register during the instruction. OP Codes and operands are all 16-bits, which is a bit wasteful in terms of OP Code usage, however it was easier to implement this way, and so that is what I went with (and there are a lot of ALU processes). 

Memory Mapping:
The 16-bit address space of the Femto-4 is memory mapped, with all data being stored somewhere in the address space. The last 48kx16b of memory (all addresses starting with 01, 10, or 11) are dedicated to the cart memory. This is where the interchangeable program would be stored, allowing programs to be easily changed by changing carts. The carts have 32 16kx16b EEPROM/RAM chips, which can be switched between during execution by writing to address 00cc. This gives each cart 512kx16b of memory to play with. In theory, additional memory can be added in a cart by creating a similar system on the inside of the cart, which would allow it to swap between even more EEPROM/RAM chips. The initial 16kx16b are therefore mapped to everything else, including a fixed "work" RAM chip that cannot be switched out, the bootloader, the PPU data, general use registers, the, stack, inputs, outputs, and special use registers. 

"Fast Execution":
Execution at the fastest clock speed (one pulse every 100ms, or 10Hz, which is defined as the clock changing state every 50ms, or at a rate of 20Hz) is terribly slow, and would make reasonable graphics effectively impossible. Due to this, the Femto-4 includes several execution modes that allow the computer to run much faster. There are two registers involved in this, address 00ca, the mode register, and address 00cb, the protection register. When the two least significant bits of the mode register are low, the computer runs normally, executing 1 instruction per clock pulse. When it is set high however, the computer enters fast execution on the rising edge, where it executes multiple instructions per clock pulse. This is achieved by looping a rising edge monostable circuit into a falling edge monostable circuit, producing a loop that will pulse indefinitely until the looping line is written high to by some external factor. Stopping the loop is critical since leaving the loop running will stop CircuitVerse's execution, due to it going over the stack limit of the execution. "Fast execution" is always paused by a 0x0000 OP Code, which ensures that the computer will not attempt to "fast execute" memory that has not been written to. It is also paused by the OP Code 0x0001. Setting the 3 bit of the mode register high will enable protection. This will ensure that computer only executes as many instructions as the value in the protection register. This protects execution by ensuring that the loop will always pause before the cycle limit is reached. Since some operations are far more complex than other operations, the maximum number of instructions per clock pulse is variable, and testing should always be conducted to ensure that the limit is not reached. Due to this, for games that need regular graphics updates, it is recommended that protection is not used, and instead the pauses are fully code controlled. Setting the 2nd bit of the mode register high will enable the clock to run fast execution on the falling edge of the clock as well, doubling execution speed. On the other end of the mode register are the graphics mode. The highest two bits give the graphics update mode, 00 for falling edge only (normal speed), 01 for dual edge (double speed), 10 for every other clock pulse (half speed), and 11 for code controlled, where the 0x0001 OP Code is required to update the graphics. The third most significant bit is the graphics disable bit. Setting it high stops updating the graphics, reducing lag by reducing the number of changing outputs. The mode and protection values are only updated on the rising edge of the clock pulse, and therefore there should always be pauses before and after any execution mode or protection change. 

Graphics:
The Femto-4 is capable of driving a 16x16 15bit direct colour screen. It has space for 32 "sprites" which are rectangles with an assigned colour. All the sprites are drawn to the screen whenever a graphics update occurs, depending on the graphics mode. When using dual-edge "Faster Execution", the falling edge should only be used to execute game code, since writing graphics data as the screen is being drawn may mess up the graphics. These 32 "sprites" have their data stored in the PPU RAM in the following format: The first 16 bits are the corners of the rectangle, with each coordinate being 4 bits. The coordinates are ordered x1 x2 y1 y2. The next 16 bits are the sprites colour, with the first 15 bits being used for 15 bit direct colour, and the last bit being used to enable or disable drawing the sprite. Since the screen is not wiped every time it is refreshed, the background must be a sprite to ensure that the screen is fully wiped before the rest of the sprites are drawn on. Control of this allows carts to draw a single frame over multiple updates, allowing the 32-sprite limit to be bypassed (see how Snake works). The "sprites" are drawn in memory order, with the "sprite" with the largest address always being drawn last and therefore on top, of all other "sprites". This is achieved by using the exact same monostable clock system as "Fast Execution", which reads off all the sprite data and draws them to the screen in a single clock pulse. This can loop more times safely than the main CPU since it has less dependencies which dramatically decreases the simulation's stack usage. 

ALU:
The basic ALU was inspired by the ALU-74LS181. It was designed to flexibly change between various operations by changing an additional piece of data which is bundled in the OP Code. This allows a single ALU to handle all the required processes, such as the basic binary logic operations, shift left, adding, and subtracting. This is unlike my previous computer which had different chips for each operation it could do. The Femto-4 also can multiply, divide, shift right, shift left/right by a specified number of bits, and perform operations designed to work with the Femto-4's graphics data. 

Conditional Jumps:
The Femto-4 can perform immediate and direct jumps depending on the flags, a specified bit of the accumulator, and the clock. The flag jumps allow for comparisons to be made. There are three flags, the carry, the most significant bit in the accumulator, and if the accumulator value is 0, the equals flag. By performing A-B, we can compare A and B by looking at the flags. If the equals flag is true, then A=B, since A-B = 0. If the most significant bit is 0, then the number is positive or 0 (by two's complement) and therefore A>=B. The comparison is not entirely correct for numbers in two's complement (a large positive number and a large negative number when subtracted can yield a positive number), but for small values it works well. Whilst we cannot directly check A<=B using A-B in this design, we can simply flip the subtraction to B-A to do so. 
The accumulator bit testing is mainly used to check for controller inputs. Since each button in the controller is mapped to one bit, bit testing that bit effectively allows us to check if a button has been pressed. In theory a similar test could be performed using an AND instruction, and checking if the result is equal to 0 or not.
The jump on clock is there to ensure that we can jump execution on the right clock pulse, which ensures that graphics can be updated on the edge of execution. 

Timing:
This computer is timed using several standard delay chips. The pulse length running in to the computer is about 10k units long. Therefore, different parts an instruction are separated by 20k unit delays. Further control of timings inside these periods is achieved through 1k "On Delays", which have a 1k delay turning on, but a 0k delay turning off, ensuring that pulses do not bleed into the next pulse. These pulses can tell registers to write and what source to write from, enable the read and write lines, update the ALU, and update the stack. For more information on how delay works see here: https://circuitverse.org/users/4699/projects/circuitverse-delay-introduction. 

Other Notes:
The memory wrappers allow external chips to interact with the main data control system, in this case used for RNG, controllers, the keyboard, and driving the text output. This makes it easy to additional chips to the computer. 

For more information, please read the developer guide found in the Femto-4's Assembler, or just post a comment and ask me. 

This is a secret to everybody, unless you found it. 

Based on TD4, a 4 bit CPU.

Pre-design for Minecraft.

Implementation of the processor MIPS R2000 in it's unicycle version.

An 8-bit CPU with an instruction set that includes the analytic integration and differentiation of polynomial expressions.

This is a "CPU" It's just a counter with memory stuff

help

this is my 8 bit CPU, it is nowhere near done and it is very far off from conventional CPU mechanics but I tried

This is just something I started playing with to learn how to use CV. Wish me luck...

this is a simple (but messy) computer inspired by the computer in the game Turing complete,

it currently runs a multiplication program

to run:

1: make sure program is set to 0

2: click restart button to set instruction counter to 0 and reset the registers

2: set Run to 1

to program:

1. set program to 1 and run to 0

2. click resetprogram to reset the EEPROM and the instruction counter

3. enter the instruction

4. click the insert button to submit the instruction.

Repeat step 3&4 for all the instructions

(or just load in to the eeprom directly)

the instructions work as following:

opcode  argument 1  argument 2

 01          010              110

there are the following opcodes

00 immediate: loads the value into register 0

01 copy: copies the value from the register specified in argument 1 to the register specified in argument 2

10 Calculate: takes the values in registers 1 and 2, executes the instruction specified in argument 2(see ALU instructions), and returns the outcome into register 3

11 compare: compares the value in register 3 based on argument 2(see Compare instructions), if true jump to instruction in specified in register 0

ALU instructions

0 and

1 or

2 nand

3 nor

4 add

5 sub

(6&7 are currently unspecified, i plan on making these shift left and right)

Compare instructions

0: never

1: != 0 

2: < 0

3:<= 0

4: always

5: ==0

6: > 0

7: >= 0

Plans:

i'd like to add shift left and right into the ALU

i plan on making more intuitive controls, inputs and outputs

i'd also like to add memory to read from or write to.

finaly i might make the other structure from the game but that'll be another circuit :-p

This is a WIP, I am doing this because I have a new computer and I need to branch it to continue, however I will still be using this during school so I will swap between them

Computer In Development...

Current Planned Functionality:

7 bit words (3 bit instructions and 4 bit argument)

Its elementary.

A simple CPU design for CS288, copied from Dr. Lowe.

Digital Logic Design, Sequential. Combinational Logic, ALU, CPU, Finite State Machine, FSM, State Diagram, State Table, Flip Flops, Registers, Counters

Under construction.

Under construction.

Under construction.

To change sample program, copy a eeprom from the programs tab, and replace the one near the start of the circuit in main with it

to start it, toggle on and off the CLR button down by the clock circuit in Main

Explanation of how someone got many clock cycles per clock update:https://circuitverse.org/users/4699/projects/circuitverse-delay-introduction

Also after about 2 days I successfully coded and implemented Coonways game of life in here in a 16x16 grid(so each grid takes 256 entries in the storage and theres 2 of them)

An attempt on making a 1-bit computer at its full potential.

An 8-Bit Binary CPU. It can add and subtract 2 numbers, store values in a 256-bit RAM unit, load values from RAM to 4 8-Bit Registers, and Generate Random Binary Numbers.

ALU1 operates on Registers A and B together

ALU2 operates on Registers C and D togethers

ALU1 & ALU2 use the same opcodes as the default ALU.

000-AND, 001-OR, 010-ADD, 100-A&~B, 101-A|~B, 110-SUB, 111-<.

My CPUv1 Processor as a sub circuit.

An 8-Bit Binary CPU. It can add and subtract 2 numbers, store values in a 256-bit RAM unit, load values from RAM to 4 8-Bit Registers, and Generate Random Binary Numbers.

ALU1 operates on Registers A and B together

ALU2 operates on Registers C and D together

ALU1 & ALU2 use the same opcodes as the default ALU.

000-AND, 001-OR, 010-ADD, 100-A&~B, 101-A|~B, 110-SUB, 111-<.

A more advanced and compact 8-Bit CPU.

MEL CPUv2 

4 Internal Registers, 9 External Registers (outputs), 64KB RAM by default. And a Clock speed of 50ms.

The CPU comes with a display system of Hex displays which show the value of the 9 Registers.

The ALUs are able to do 7 operations and use a 4-bit opcode.

The CPU is also able to generate random 8-Bit binary values.

The internal registers are able to be loaded either through a value stored in RAM or through a value directly inputted into the CPU.

MANUAL

The RAM input connects to the output of the external RAM unit.

Input 1 and 2 are used in ALU0 as the inputs, Input 1 is also the input for the direct load register command and is recomended to connect to the RAM input.

Opcodes 0,1, and 2 connect to ALU 0,1, and 2 respectively. The First Place turns the ALU on (1) or off(0), the rest of the bits correspond to the default ALU opcodes.

RNG On/Off determines if the Random external register shows a random value.

Load Reg. Loads a value into one of the registers. Direct will load the value from Input1 into one of the registers. RAM will load the value outputted by the RAM unit into one of the registers.

Register Address determines which register is loaded. A=00,B=01,C=10,D=11

All adders up to 16-Bit

RECOMMENDED FOR COMPUTERS 

This is the second addition of the B8 Series. Otherwise known as the BURTONABLE 8 256 it is capable of running programs 256 lines long! as well as 7 instructions to use

LDA 0001: Loads the given value into the Accumulator

ADD 0010: The given value will be added to the accumulator

SUB 0011: The given value will be subtracted from the accumulator

OUT 1110: Shows the output of A and B

HALT 1111: Stops all

PRT 0110: Prints a 7 bit ASCII character to the TTY

CLRTTY 0101: Clears the TTY element

DRAW BLACK 1001: Draws the color black to the X (4 bits) and the Y (4 bits)

DRAW WHITE 1011: Draws the color white to the X (4 bits) and the Y (4 bits)

JC 1100: Only jumps up by the given data if 2 negative numbers add up to a positive number

sometimes the codes get corrupted just spam reset a couple times

FUN CODES: To use them, just double click the EEPROM

To retrieve a code just press the save button and then open the dev console (FN + Volume up MAC) or F12 (PC)

To put codes in the EEPROM double click it and paste the code

circle.

2952,2968,2984,2999,2998,2997,2980,2964,2948,2933,2934,2935,1635,1641,1650,1635,1644,1637,3840,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

I would love to see your codes too so post them in the comments!

THIS VERSION IS OUTDATED HERE IS THE LINK TO THE NEW ONE https://circuitverse.org/users/160624/projects/b8256-v3

Oh and also The original B8 got deleted :(

USE ON A COMPUTER

Same as V2 exempt that there is a Jump if zero command

JO: Jumps if the ALU output is 0

And you can under stand things better!

(these instructions arent done)

Its not much and getting it to add and substract numbers is a pain. Just use a calculator. This is only a work of art (or architecture perhaps?).

I have made a new version of string series CPU. This new version has a minor change. When you toggle on EN, all registers and the PC will be reset. Please read before programming this CPU. 

/0. NOP- no instruction at this address

/1. wait for input - stops PC until an input (other than zero) value is detected through DI 

/2. output ANS - output ALU ANS 

/3. output loaded - output loaded data from RAM

/4. output input - output value in DI register

/5. jump if input= - skip to different part of program if a certain value is detected in DI (address can be selected by setting the value in the "addresses" stepper)

/6. jump if ANS= - same as 5 but for ANS

/7. jump if loaded= - also same as 5 but for loaded

/8. jump - like 5, but the skipping is unconditional 

/9. output PRGM - output the value from the 'Values" section in the program EEPROM (make sure you have the program value at the same time as the instruction)

/10. load - load a value from RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/11. save ANS - save ALU ANS to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/12. save input - save value in DI to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/13. reset PC - resets the PC

/14. Set ALU operation - sets ALU CTR (set ALU CTR by using "values" section at the same time as instruction Value= OPCODE value)

/15. Jump if input> - jumps if input is > than program value (make sure you have the instruction, address, and value at the same time.)

/16. Jump if input< - same as 15, but <

/17. Jump if ANS> - same as 15, but for ALU ANS

/18. Jump if ANS< - same as 16, but for ALU ANS

/19. Jump if loaded> - same as 15, but for loaded

/20. Jump if loaded< - same as 16, but for loaded

/21. wait for input= - waits for a certain DI value (DI register doesn't save)

/22. Set PRGM to A - sets program value to ALU input A (have your value from "Values" section as same time as instruction)

/23. Set PRGM to B - same as 22, but for ALU input B

/24. save PRGM - saves program value to RAM (make sure you have the instruction, address, and value at the same time.)

/25. Reset A - resets ALU input A

/26. Reset B - resets ALU input B

/27. Reset operation - resets ALU CTR

/28. Reset loaded - clears loaded data in loaded register

/29. Reset input - clears value in DI register

/30. Reset output - clears value in output register

/31. Reset ANS - clears data in ALU ANS register

/32. Reset All REG - clears data in all registers in CPU

/33. reset RAM - clears all data in RAM

/34. Reset system - clears all data off RAM and registers

/35. set input to A - sets value in DI register to ALU input A

/36. set input to B - same as 35, but for ALU input B

/37. set loaded to A - sets loaded value to ALU input A

/38. set loaded to B - same as 37, but for ALU input B

/39. set ANS to A - sets ALU ANS to ALU input A

/40. set ANS to B - same as 39, but for ALU input B

/41. submit ANS - submits ANS to ANS register (make sure you use this instruction before clearing ALU inputs otherwise the ANS will be lost)

/42. jump if carry - same as 5, but if ALU COUT = 1

There is a programming machine that you can connect an empty EEPROM (make sure bit width is 32 and address width is 10 and don't ever use ram for programming!!!). make sure that your program is starting at EEPROM address 2 and increase the EEPROM address by one every instruction you write to EEPROM otherwise you are essentially constantly overriding instructions!

This is a comparison of every CPU I make. New CPUs wont be shown here anymore, but If you have any questions, suggestions, or something is not working, in a string series CPU, please ask here. Announcements on the string CPUS will be announced here.

4-15-2024- UPDATE FOR STRING32000: (TONS OF BUG FIXES AND MULT DIV UPGRADE) A hell tons of bugs were fixed, and this CPU now supports 32-bit multiplication and 32-bit division.

4-7-2024- UPDATE FOR STRING32000: (PGMEM SAVE FIX) fixes goofy-ahh bug where PGMEM save instruction didnt work

4-6-2024- UPDATE FOR STRING32000: (MULTPLICATION UPGRADE) upgraded from the 16-bit multiplication circuit in the ALU to 32-bit multiplication. Division shall be upgraded next and then 32-bittedness shall be complete!

4-3-2024- UPDATE FOR STRING32000: (PGMEM NOW LARGER) Because CircuitVerse doesn't support EEPROM that has an address width over 10 bits and STRING32000 supports 16-bit addresses, I decided to link up 64 EEPROMS to make one big fat EEPROM with 16 bit addresses. STORAGE PROBLEM FIXED!

3-29-2024- 2 ANNOUNCEMENT: (STRING 32000 RELEASE) Great news! I have released the string 32000, which is much more capable than the STRING16 series. New CPUS will no longer be posted here but announcements will still be made. Check the page for the STRING32000 for more information. Link: https://circuitverse.org/users/92698/projects/string-32000

3-4-2024- SOME PRETTY BIG NEWS: (PRE-RELEASE STRING 32000 INFO) STRING32000 is an entirely new 32-BIT CPU. Unfortunately, this new CPU will NOT be able to run STRING16 machine language(THE language that of 1000+ -- 3000+ series string CPUS run on). Instead the new CPU will run off a language called STRING32. 

11-26-2023- UPDATE FOR STRING 3000SA: (RAND IN IN ALUE OUTPUTTING WHEN NOT IN USE) fixed broken ALU RAND FUNCTION

11-17-2023- ANNOUNCEMENT: (STRING3000SA RELEASE) released STRING3000SA

10-13-2023- GOOD NEWS FOR ALL CPUS: (CIRCUITVERSE IS HAPPY AGAIN) The glitchy simulator has been fixed and all CircuitVerse computers work like they used to

9-9-2023- BAD NEWS FOR ALL CPUS: (SIMULATION ERROR STATE) String CPUS are no longer able to run due to a glitch in the simulator. The simulator keeps entering an "error state," preventing the CPU from running; this glitch has also killed other computers and complex creations like the well-known Femto (RIP CircuitVerse computers). I hope this glitch is fixed.

7-27-2023- ANNOUNCEMENT: (NEW PROGRAM) added a new program "constantly shift to example programs of 2000 series+/ 3000 series+

7-22-2023- ANNOUNCEMENT: (STRING3000 RELEASE) released STRING3000

7-21-2023- UPDATE FOR ALL CPUS: (SAVE PRGM INSTRUCTION NOT WORKING FIX) Fixed CPU unable to save program data.

7-19-2023- UPDATE FOR ALL CPUS: (LOADED REG NOT RESETTING ON CERTAIN RESET INSTRUCTIONS FIX) Fixed LOADED REG not resetting on certain commands.

7-6-2023- ANNOUNCEMENT: (STRING2000C RELEASE) released STRING2000C

6-19-2023- UPDATE FOR ALL CPUS: (CONDITIONAL PC JUMP FIX 2) Actually fixed broken jump commands for good.

6-19-2023- UPDATE FOR STRING2000: (UNWANTED COUT FIX) Fixed sections of ALU setting C OUT to 1 when not in use.

6-18-2023- UPDATE FOR ALL CPUS: (CONDITIONAL PC JUMP FIX) Fixed CPU jumping despite not being supposed to according to conditional jump command rules.

6-18-2023- UPDATE FOR ALL CPUS: (PC REWORK) Fixed PC refusing to jump or giving a simulation stack limit error.

About string series:

Simple explanation.

String CPU series is an ongoing series of CPUS idk why I called it string CPU but whatever. They execute code in one tick. The old STRING16-series (1000-3000SA) has been discontinued to work on the newer STRING32-series (32000+) which unlike STRING16, is capable of self-modifying code and 64x more available address space to work with in its EEPROM and RAM.

How they work:

For the old STRING16 bases CPUS, they have a 32 bit program splitter which splits into 3 sections: 16 BITS (VALUES) 10 bits (ADRESSES) and 6 bits (INSTRUCTIONS). *sorry there's no assembler/compiler for these you can comment to ask for one of you want for there to be a STRING16 assembler

For the new STRING32 based CPUs, the program splitter is 32-bit like the STRING16-based, but it splits into 5 sections: 16 bits (ADRESSES) two 4 bit channels (REGISTERS SELECTION) a 3 bit channel (SELECTING ALUS, SPECIAL REGISTERS, AND MEMORY), and finally a 5 bit channel (INSTRUCTIONS). For values, an entire addresses is dedicated in the program memory to store 32-bit values. There will also be a link to the excel STRING32 assembler in the CPUS page in the future to make it MUCH, MUCH easier to program the CPU.

There is now string CPU 2000 series. This is the string CPU 2000. There has been a very major change since the 1000 series. I have added a custom ALU instead of using the one in CircuitVerse (there's still a regular ALU used to compare). this ALU supports multiplication, addition, subtraction, shifting binary values, and comparing with <,>, and =.  Please read before programming this CPU. 

CPU instructions

/0. NOP- no instruction at this address

/1. wait for input - stops PC until an input (other than zero) value is detected through DI 

/2. output ANS - output ALU ANS 

/3. output loaded - output loaded data from RAM

/4. output input - output value in DI register

/5. jump if input= - skip to different part of program if a certain value is detected in DI (address can be selected by setting the value in the "addresses" stepper)

/6. jump if ANS= - same as 5 but for ANS

/7. jump if loaded= - also same as 5 but for loaded

/8. jump - like 5, but the skipping is unconditional 

/9. output PRGM - output the value from the 'Values" section in the program EEPROM (make sure you have the program value at the same time as the instruction)

/10. load - load a value from RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/11. save ANS - save ALU ANS to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/12. save input - save value in DI to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/13. reset PC - resets the PC

/14. Set ALU operation - sets ALU CTR (set ALU CTR by using "values" section at the same time as instruction Value= OPCODE value)

/15. Jump if input> - jumps if input is > than program value (make sure you have the instruction, address, and value at the same time.)

/16. Jump if input< - same as 15, but <

/17. Jump if ANS> - same as 15, but for ALU ANS

/18. Jump if ANS< - same as 16, but for ALU ANS

/19. Jump if loaded> - same as 15, but for loaded

/20. Jump if loaded< - same as 16, but for loaded

/21. wait for input= - waits for a certain DI value (DI register doesn't save)

/22. Set PRGM to A - sets program value to ALU input A (have your value from "Values" section as same time as instruction)

/23. Set PRGM to B - same as 22, but for ALU input B

/24. save PRGM - saves program value to RAM (make sure you have the instruction, address, and value at the same time.)

/25. Reset A - resets ALU input A

/26. Reset B - resets ALU input B

/27. Reset operation - resets ALU CTR

/28. Reset loaded - clears loaded data in loaded register

/29. Reset input - clears value in DI register

/30. Reset output - clears value in output register

/31. Reset ANS - clears data in ALU ANS register

/32. Reset All REG - clears data in all registers in CPU

/33. reset RAM - clears all data in RAM

/34. Reset system - clears all data off RAM and registers

/35. set input to A - sets value in DI register to ALU input A

/36. set input to B - same as 35, but for ALU input B

/37. set loaded to A - sets loaded value to ALU input A

/38. set loaded to B - same as 37, but for ALU input B

/39. set ANS to A - sets ALU ANS to ALU input A

/40. set ANS to B - same as 39, but for ALU input B

/41. submit ANS - submits ANS to ANS register (make sure you use this instruction before clearing ALU inputs otherwise the ANS will be lost)

/42. jump if carry - same as 5, but if ALU COUT = 1

ALU operations:

0. AND

1. SUB

2. ADD

3. MULT

4. SHIFT RIGHT

5. SHIFT LEFT

6. A<B

7. A>B

8. A=B

There is a programming machine that you can connect an empty EEPROM (make sure bit width is 32 and address width is 10 and don't ever use ram for programming!!!). make sure that your program is starting at EEPROM address 2 and increase the EEPROM address by one every instruction you write to EEPROM otherwise you are essentially constantly overriding instructions!

This is the fourth CPU of the string CPU series. This CPU has a new counter that has a clock that's twice the speed of an ordinary clock. Because of this, this CPU is now twice as fast as its predecessors.

CPU instructions

/0. NOP- no instruction at this address

/1. wait for input - stops PC until an input (other than zero) value is detected through DI 

/2. output ANS - output ALU ANS 

/3. output loaded - output loaded data from RAM

/4. output input - output value in DI register

/5. jump if input= - skip to different part of program if a certain value is detected in DI (address can be selected by setting the value in the "addresses" stepper)

/6. jump if ANS= - same as 5 but for ANS

/7. jump if loaded= - also same as 5 but for loaded

/8. jump - like 5, but the skipping is unconditional 

/9. output PRGM - output the value from the 'Values" section in the program EEPROM (make sure you have the program value at the same time as the instruction)

/10. load - load a value from RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/11. save ANS - save ALU ANS to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/12. save input - save value in DI to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/13. reset PC - resets the PC

/14. Set ALU operation - sets ALU CTR (set ALU CTR by using "values" section at the same time as instruction Value= OPCODE value)

/15. Jump if input> - jumps if input is > than program value (make sure you have the instruction, address, and value at the same time.)

/16. Jump if input< - same as 15, but <

/17. Jump if ANS> - same as 15, but for ALU ANS

/18. Jump if ANS< - same as 16, but for ALU ANS

/19. Jump if loaded> - same as 15, but for loaded

/20. Jump if loaded< - same as 16, but for loaded

/21. wait for input= - waits for a certain DI value (DI register doesn't save)

/22. Set PRGM to A - sets program value to ALU input A (have your value from "Values" section as same time as instruction)

/23. Set PRGM to B - same as 22, but for ALU input B

/24. save PRGM - saves program value to RAM (make sure you have the instruction, address, and value at the same time.)

/25. Reset A - resets ALU input A

/26. Reset B - resets ALU input B

/27. Reset operation - resets ALU CTR

/28. Reset loaded - clears loaded data in loaded register

/29. Reset input - clears value in DI register

/30. Reset output - clears value in output register

/31. Reset ANS - clears data in ALU ANS register

/32. Reset All REG - clears data in all registers in CPU

/33. reset RAM - clears all data in RAM

/34. Reset system - clears all data off RAM and registers

/35. set input to A - sets value in DI register to ALU input A

/36. set input to B - same as 35, but for ALU input B

/37. set loaded to A - sets loaded value to ALU input A

/38. set loaded to B - same as 37, but for ALU input B

/39. set ANS to A - sets ALU ANS to ALU input A

/40. set ANS to B - same as 39, but for ALU input B

/41. submit ANS - submits ANS to ANS register (make sure you use this instruction before clearing ALU inputs otherwise the ANS will be lost)

/42. jump if carry - same as 5, but if ALU COUT = 1

ALU operations:

0. AND

1. SUB

2. ADD

3. MULT

4. SHIFT RIGHT

5. SHIFT LEFT

6. A<B

7. A>B

8. A=B

There is a programming machine that you can connect an empty EEPROM (make sure bit width is 32 and address width is 10 and don't ever use ram for programming!!!). make sure that your program is starting at EEPROM address 2 and increase the EEPROM address by one every instruction you write to EEPROM otherwise you are essentially constantly overriding instructions!

This CPU is the first 3000 series string CPU. This CPU supports a new instruction called save loaded. This instruction saves a value in the LOADED register to the memory. This is useful if you want to copy a value from one address to another.

CPU instructions:

/0. NOP- no instruction at this address

/1. wait for input - stops PC until an input (other than zero) value is detected through DI 

/2. output ANS - output ALU ANS 

/3. output loaded - output loaded data from RAM

/4. output input - output value in DI register

/5. jump if input= - skip to different part of program if a certain value is detected in DI (address can be selected by setting the value in the "addresses" stepper)

/6. jump if ANS= - same as 5 but for ANS

/7. jump if loaded= - also same as 5 but for loaded

/8. jump - like 5, but the skipping is unconditional 

/9. output PRGM - output the value from the 'Values" section in the program EEPROM (make sure you have the program value at the same time as the instruction)

/10. load - load a value from RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/11. save ANS - save ALU ANS to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/12. save input - save value in DI to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/13. reset PC - resets the PC

/14. Set ALU operation - sets ALU CTR (set ALU CTR by using "values" section at the same time as instruction Value= OPCODE value)

/15. Jump if input> - jumps if input is > than program value (make sure you have the instruction, address, and value at the same time.)

/16. Jump if input< - same as 15, but <

/17. Jump if ANS> - same as 15, but for ALU ANS

/18. Jump if ANS< - same as 16, but for ALU ANS

/19. Jump if loaded> - same as 15, but for loaded

/20. Jump if loaded< - same as 16, but for loaded

/21. wait for input= - waits for a certain DI value (DI register doesn't save)

/22. Set PRGM to A - sets program value to ALU input A (have your value from "Values" section as same time as instruction)

/23. Set PRGM to B - same as 22, but for ALU input B

/24. save PRGM - saves program value to RAM (make sure you have the instruction, address, and value at the same time.)

/25. Reset A - resets ALU input A

/26. Reset B - resets ALU input B

/27. Reset operation - resets ALU CTR

/28. Reset loaded - clears loaded data in loaded register

/29. Reset input - clears value in DI register

/30. Reset output - clears value in output register

/31. Reset ANS - clears data in ALU ANS register

/32. Reset All REG - clears data in all registers in CPU

/33. reset RAM - clears all data in RAM

/34. Reset system - clears all data off RAM and registers

/35. set input to A - sets value in DI register to ALU input A

/36. set input to B - same as 35, but for ALU input B

/37. set loaded to A - sets loaded value to ALU input A

/38. set loaded to B - same as 37, but for ALU input B

/39. set ANS to A - sets ALU ANS to ALU input A

/40. set ANS to B - same as 39, but for ALU input B

/41. submit ANS - submits ANS to ANS register (make sure you use this instruction before clearing ALU inputs otherwise the ANS will be lost)

/42. jump if carry - same as 5, but if ALU COUT = 1

/43. save loaded - saves loaded value to memory (make sure you use instruction and address at same time)

ALU operations:

0. AND

1. SUB

2. ADD

3. MULT

4. SHIFT RIGHT

5. SHIFT LEFT

6. A<B

7. A>B

8. A=B

There is a programming machine that you can connect an empty EEPROM (make sure bit width is 32 and address width is 10 and don't ever use ram for programming!!!). make sure that your program is starting at EEPROM address 2 and increase the EEPROM address by one every instruction you write to EEPROM otherwise you are essentially constantly overriding instructions!

A CPU! this took me a while to figure out, mostly how to get it to run comands, but I eventually found a solution of using 4 bits as function indicators, 4 as where to save the output, 4 as the 2nd input, and 4 as the first input!

Pls Help me!
i made RAM and MAR for my computer and i want know how to make it better, if you have somthing on your heart pls tell me it. I am still working on it.

(I'am new, please dont hurt me)

The Sixth string CPU has finally arrived. This new CPU has a new function in the ALU called RAND This is a simple function which the ALU can output a random value. The second new thing is the way the string CPU writes to the value memory. In the older string CPUS, the write pin would be triggered when a value above 0 is detected being saved in a save instruction, which severely bottlenecks the processor's ability to operate. since you can't override a value above 0 with 0 in the memory. This new system, however, activates the write pin when a save instruction is detected. This means that values in the memory can now be overridden with 0 in save instructions! 

CPU instructions:

/0. NOP- no instruction at this address

/1. wait for input - stops PC until an input (other than zero) value is detected through DI 

/2. output ANS - output ALU ANS 

/3. output loaded - output loaded data from RAM

/4. output input - output value in DI register

/5. jump if input= - skip to different part of program if a certain value is detected in DI (address can be selected by setting the value in the "addresses" stepper)

/6. jump if ANS= - same as 5 but for ANS

/7. jump if loaded= - also same as 5 but for loaded

/8. jump - like 5, but the skipping is unconditional 

/9. output PRGM - output the value from the 'Values" section in the program EEPROM (make sure you have the program value at the same time as the instruction)

/10. load - load a value from RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/11. save ANS - save ALU ANS to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/12. save input - save value in DI to RAM (make sure you have your address from the "addresses" section at the same time as the instruction)

/13. reset PC - resets the PC

/14. Set ALU operation - sets ALU CTR (set ALU CTR by using "values" section at the same time as instruction Value= OPCODE value)

/15. Jump if input> - jumps if input is > than program value (make sure you have the instruction, address, and value at the same time.)

/16. Jump if input< - same as 15, but <

/17. Jump if ANS> - same as 15, but for ALU ANS

/18. Jump if ANS< - same as 16, but for ALU ANS

/19. Jump if loaded> - same as 15, but for loaded

/20. Jump if loaded< - same as 16, but for loaded

/21. wait for input= - waits for a certain DI value (DI register doesn't save)

/22. Set PRGM to A - sets program value to ALU input A (have your value from "Values" section as same time as instruction)

/23. Set PRGM to B - same as 22, but for ALU input B

/24. save PRGM - saves program value to RAM (make sure you have the instruction, address, and value at the same time.)

/25. Reset A - resets ALU input A

/26. Reset B - resets ALU input B

/27. Reset operation - resets ALU CTR

/28. Reset loaded - clears loaded data in loaded register

/29. Reset input - clears value in DI register

/30. Reset output - clears value in output register

/31. Reset ANS - clears data in ALU ANS register

/32. Reset All REG - clears data in all registers in CPU

/33. reset RAM - clears all data in RAM

/34. Reset system - clears all data off RAM and registers

/35. set input to A - sets value in DI register to ALU input A

/36. set input to B - same as 35, but for ALU input B

/37. set loaded to A - sets loaded value to ALU input A

/38. set loaded to B - same as 37, but for ALU input B

/39. set ANS to A - sets ALU ANS to ALU input A

/40. set ANS to B - same as 39, but for ALU input B

/41. submit ANS - submits ANS to ANS register (make sure you use this instruction before clearing ALU inputs otherwise the ANS will be lost)

/42. jump if carry - same as 5, but if ALU COUT = 1

/43. save loaded - saves loaded value to memory (make sure you use instruction and address at same time)

ALU operations:

0. AND

1. SUB

2. ADD

3. MULT

4. SHIFT RIGHT

5. SHIFT LEFT

6. A<B

7. A>B

8. A=B

9. RAND

There is a programming machine that you can connect an empty EEPROM (make sure bit width is 32 and address width is 10 and don't ever use ram for programming!!!). make sure that your program is starting at EEPROM address 2 and increase the EEPROM address by one every instruction you write to EEPROM otherwise you are essentially constantly overriding instructions! (I know, disgusting machine code. Comment in string CPU comparison if you want to, suggest a way to type code for the CPU.)

For those who want to see what is going inside string3000SA

Functional Electronic Machine Binary Operator Yes - 8-bit cpu

Working on a NEW CPU: Femboy-16!

ASSEMBLER:

https://output.jsbin.com/wutikij

INSTRUCTION SET:
00: NOP - Nothing
01: HLT - Halt program
02: OUT [id] - Output the accumulator out of an output
03: LDI A, [d8] - Loads immediate 8 bit word into the accumulator
04: MOV [r], A - Move register to accumulator
05: MOV A, [r] - Move accumulator to register
06: INC [r] - Increment a register
07: DEC [r] - Decrememt a register
08: ADD [r], A - Add the accumulator from a register
09: SUB [r], A - Subtract the accumulator from a register
0A: AND [r], A - And the register and accumulator
0B: IOR [r], A - OR the register and accumulator
0C: XOR [r], A - XOR the register and accumulator
0D: NOT [r] - NOT a register
0E: SRR [r] - Barrel shift accumulator right
0F: SRL [r] - Barrel shift accumulator left
10: JUP [d8] - Jump to a location
11: JPP [r] - Jump to a register value
12: JPL A, [d8] - Jump if accumulator is less than 0
13: JZO A, [d8] - Jump if accumulator is 0
14: JPG A, [d8] - Jump if accumulator is greater than 0
15: JLE A, [d8] - Jump if accumulator is less than or equal to 0
16: JGE A, [d8] Jump if accumulator is greater than or equal to 0
17: JNZ A, [d8] Jump if accumulator is not 0
18: CLR [r] - Clear a register
19: INP [id] - Store INPUT id in accumulator
1A: MOV pA, [r] - Move the value at address A register r
1B:  MOV [r], pA - Move register r into address A
1C: MOV [p], A - Move a value in a pointer to the accumulator
1D: MOV A, [p] - Move the accumulator to a location
1E: MLT [r], A - Multiply register r by the accumulator
1F: DIV [r], A - Divide register r by accumulator

REGISTERS:
00: REGISTER 1
01: REGISTER 2
02: REGISTER 3
04: REGISTER 4
05: ZERO FLAG (R)
06: PC (R)
07: ALU Result (R)

Update Notes:
So this is the 4th iteration of my CPU lol... I added a few programs for you all to try out and you can even use an assembler now!

To-Do:
Increase amount of registers to 8
Make a simple command line
Make an assember
Make a simple operating system for the CPU
Add rgb output

idk what to type💀

So Its not mine its some one else

Its nice its not mine tho its someone else

Not MINE!!

NOT MINEEE!!!

Cool

yup

here's 10 hours of my life ill never get back

note: click "clr" before use

OP codes and Input numbers:

OP1 0 OP2 0 null

OP1 0 OP2 1 add

OP1 1 OP2 0 write

OP1 1 OP2 1 read

number - binary equivalents

A1 A2 =       B1 B2 =

0   0  =  0   |  0   0  =  0 

1    0  =  1   |  1    0  =  1

0   1   =  2  |  0   1   =  2

1    1   =  3  |   1    1   =  3

wip 8 bit cpu

About the Combinox R1:

This is the third 16-bit CPU I have made. Its new name was inspired by the new combinational code. It is also my first computer to feature a graphics and base ten display. As a result of its brand new architecture, code, and clock it is much faster than my previous CPUs. 

Directions for use:

Choose the desired EEPROM program and insert it into the slot. First press the "RESET" button. Now press the "ON" button and enjoy your program.

Descriptions of programs:

blank: A blank EEPROM to be coded.

count up forever: Counts up by one until it reaches 65,535 then loops back to 0.

2+2: adds 2+2 and displays the output to the number display

transfer from keyboard to display: Displays the ascii value of whatever key is being entered on the keyboard.

random noise: Displays random noise on the screen.

Fibonacci: calculates the Fibonacci sequence 

Credits:

Sanderokian Stfetoneri - clock

Sanderokian Stfetoneri - 16 bit division

Functional Electronic Machine Binary Operator Yes - 8-bit cpu

This is a work in progress right now.

INSTRUCTION SET:
00: MOV [r], A - Loads a register into the accumulator.
01: MOV A, [r] - Saves a register into the accumulator.
02: INC [r] - Increment a register 
03: DEC [r] - Decrement a register
04: ADD [r] - Add the accumulator to a register
05: SUB [r] - Subtract the accumulator to a register
06: OUT [r] - Output a signal from a register
07: HLT - End program

REGISTERS:
00: REGISTER 1
01: REGISTER 2
02: REGISTER 3
04: REGISTER 4

Update Notes:
Final design before update of is a.

To-Do:
Add WIP instructions
Add the accumulator to a register address
Increase amount of registers to 8
Add Ram manipulation instructions
Add Input to CPU
Add more operations to the ALU
Add ASCII i/o
Make a simple command line
Make an assember
Make a simple operating system for the cpu
Add rgb output

Functional Electronic Machine Binary Operator Yes - 8-bit cpu

This is a work in progress right now.

INSTRUCTION SET:
00: NOP - Nothing
01: HLT - Halt program
02: OUT [r] - Output a register
03: LDA [d8] - Loads 8 bit data into the accumulator
04: MOV [r], A - Move register to accumulator
05: MOV A, [r] - Move accumulator to register
06: INC [r] - Increment a register
07: DEC [r] - Decrememt a register
08: ADD [r], A - Add the accumulator from a register
09: SUB [r], A - Subtract the accumulator from a register
0A: AND [r], A - And the register and accumulator
0B: IOR [r], A - OR the register and accumulator
0C: XOR [r], A - XOR the register and accumulator
0D: NOT [r] - NOT a register
0E: SRR [r] - Shift register right
0F: SRL [r] - Shift register Left

REGISTERS:
00: REGISTER 1
01: REGISTER 2
02: REGISTER 3
04: REGISTER 4

Update Notes:
The instruction set now has 16 instructions with logic operations, loading, shift, and nop. 

To-Do:
Add WIP instructions
Add the accumulator to a register address
Increase amount of registers to 8
Add Ram manipulation instructions
Add Input to CPU
Add more operations to the ALU
Add ASCII i/o
Make a simple command line
Make an assember
Make a simple operating system for the cpu
Add rgb output

A port of the NandGame CPU into CircuitVerse

This is the CTH-10 CPU. By CrEePeRz24321. (most updated version of the CTH Series) This uses all binary to operate. First click on Power to start. Turn Op to 1 and double click the RAM. Then type in the Op code you want. Only put inputs and read outputs of the User Interface. Wait until the Red light turns Green then start. If you want to change operations, then turn Op to 1 and double click the RAM. Then type in the Op code you want. (^{If you use full screen, and it keeps on kicking you out when you type, click full screen and then look to the bottom right and press + or - and don't touch the full screen after that unless the RAM input kicks you out})

0 is No Operation - Inputs unavailable

1 is RAM - write the address into In1, write the number you want to store into In2 and press Write.

2 is ADD - write the first digit into In1, write the second digit into In2

3 is Subtract - write the first digit into In1, write the second digit into In2

4 is Counter - Inputs unavailable

5 is AND Gate - write the first digit into In1, write the second digit into In2

6 is a Clock - Inputs unavailable

7 is Accessing the ROM - Inputs unavailable

8 is Binary to Decimal converter

9 is Random Number - Inputs unavailable

10 is Not Gate - write the converting digit into In1

11 is Shift Right* - write the converting digit into In1, write the shift number into In2

12 is Shift Left* - write the converting digit into In1, write the shift number into In2

13 is Multiply - write the first digit into In1, write the second digit into In2

14 is Divide - write the first digit into In1, write the second digit into In2**

HALT is to halt operation

*when using shift the first 3 digits of Out will be nonfunctional

**when using divide the first 4 digits away from the CPU are remainders and the last 4 digits closest to the CPU are quotients.

(There is also a Computer version that doesn't get updated much.)

This is the CTH-10 CPU. This uses all binary to operate. First click on Power to start. Turn Op to 1 and double click the RAM. Then type in the Op code you want. Only put inputs and read outputs of the User Interface. Wait until the Red light turns Green then start. If you want to change operations, then turn Op to 1 and double click the RAM. Then type in the Op code you want. (If you use full screen, and it keeps on kicking you out when you type, click full screen and then look to the bottom right and press + or - and don't touch the full screen after that unless the RAM input kicks you out)

0 is No Operation - Inputs unavailable

1 is RAM - write the address into In1, write the number you want to store into In2 and press Write.

2 is ADD - write the first digit into In1, write the second digit into In2

3 is Subtract - write the first digit into In1, write the second digit into In2

4 is Counter - Inputs unavailable

5 is AND Gate - write the first digit into In1, write the second digit into In2

6 is a Clock - Inputs unavailable

7 is Accessing the ROM - Inputs unavailable

8 is Binary to Decimal converter

9 is Random Number - Inputs unavailable

10 is Not Gate - write the converting digit into In1

11 is Shift Right* - write the converting digit into In1, write the shift number into In2

12 is Shift Left* - write the converting digit into In1, write the shift number into In2

13 is Multiply - write the first digit into In1, write the second digit into In2

HALT is to halt operation

*when using shift the first 3 digits of Out will be nonfunctional

Functional Electronic Machine Binary Operator Yes - 8-bit cpu

This is a work in progress right now.

INSTRUCTION SET:
00: NOP - Nothing
01: HLT - Halt program
02: OUT [id] - Output the accumulator out of an output
03: LDI A, [d8] - Loads immediate 8 bit word into the accumulator
04: MOV [r], A - Move register to accumulator
05: MOV A, [r] - Move accumulator to register
06: INC [r] - Increment a register
07: DEC [r] - Decrememt a register
08: ADD [r], A - Add the accumulator from a register
09: SUB [r], A - Subtract the accumulator from a register
0A: AND [r], A - And the register and accumulator
0B: IOR [r], A - OR the register and accumulator
0C: XOR [r], A - XOR the register and accumulator
0D: NOT [r] - NOT a register
0E: SRR [r] - Shift register right
0F: SRL [r] - Shift register Left
10: JUP [d8] - Jump to a location
11: JPP [r] - Jump to a register value
12: JPL A, [d8] - Jump if accumulator is less than 0
13: JZO A, [d8] - Jump if accumulator is 0
14: JPG A, [d8] - Jump if accumulator is greater than 0
15: JLE A, [d8] - Jump if accumulator is less than or equal to 0
16: JGE A, [d8] Jump if accumulator is greater than or equal to 0
17: JNZ A, [d8] Jump if accumulator is not 0
18: CLR [r] - Clear a register
19: INP [id] - Store INPUT id in accumulator
1A: MOV pA, [r] - Move the value at address A register r
1B:  MOV [r], pA - Move register r into address A
1C: MOV [p], A - Move a value in a pointer to the accumulator
1D: MOV A, [p] - Move the accumulator to a location
1E: MLT [r], A - Multiply register r by the accumulator
1F: DIV [r], A - Divide register r by accumulator

REGISTERS:
00: REGISTER 1
01: REGISTER 2
02: REGISTER 3
04: REGISTER 4
05: ZERO FLAG (R)
06: PC (R)
07: ALU Result (R)

Update Notes:
Welcome to the 3rd iteration of my Femboy-8 CPU! This might be the last version with 32 instructions.

To-Do:
Increase amount of registers to 8
Make a simple command line
Make an assember
Make a simple operating system for the CPU
Add rgb output

Femboy-16

Functional Electronic Machine Binary Operator Yes

A 16 bit CPU by Kain and Pacifiky

ABOUT

Made as a Successor to the FEMBOY-8.

Functional Electronic Machine Binary Operator Yes - 8-bit cpu

Working on a new CPU: Femboy-16

ASSEMBLER:

https://output.jsbin.com/wutikij

INSTRUCTION SET:
00: NOP - Nothing
01: HLT - Halt program
02: OUT [id] - Output the accumulator out of an output
03: LDI A, [d8] - Loads immediate 8 bit word into the accumulator
04: MOV [r], A - Move register to accumulator
05: MOV A, [r] - Move accumulator to register
06: INC [r] - Increment a register
07: DEC [r] - Decrememt a register
08: ADD [r], A - Add the accumulator from a register
09: SUB [r], A - Subtract the accumulator from a register
0A: AND [r], A - And the register and accumulator
0B: IOR [r], A - OR the register and accumulator
0C: XOR [r], A - XOR the register and accumulator
0D: NOT [r] - NOT a register
0E: SAR [d8] - Barrel shift accumulator right
0F: SAL [d8] - Barrel shift accumulator left
10: JUP [d8] - Jump to a location
11: JPP [r] - Jump to a register value
12: JPL A, [d8] - Jump if accumulator is less than 0
13: JZO A, [d8] - Jump if accumulator is 0
14: JPG A, [d8] - Jump if accumulator is greater than 0
15: JLE A, [d8] - Jump if accumulator is less than or equal to 0
16: JGE A, [d8] Jump if accumulator is greater than or equal to 0
17: JNZ A, [d8] Jump if accumulator is not 0
18: CLR [r] - Clear a register
19: INP [id] - Store INPUT id in accumulator
1A: MOV pA, [r] - Move the value at address A register r
1B:  MOV [r], pA - Move register r into address A
1C: MOV [p], A - Move a value in a pointer to the accumulator
1D: MOV A, [p] - Move the accumulator to a location
1E: MLT [r], A - Multiply register r by the accumulator
1F: DIV [r], A - Divide register r by accumulator

REGISTERS:
00: REGISTER 1
01: REGISTER 2
02: REGISTER 3
04: REGISTER 4
05: ZERO FLAG (R)
06: PC (R)
07: ALU Result (R)

Update Notes:
So this is the 4th iteration of my CPU lol... I added a few programs for you all to try out and you can even use an assembler now!

To-Do:
Increase amount of registers to 8
Make a simple command line
Make an assember
Make a simple operating system for the CPU
Add rgb output

Overview

The STRING32000 is a 32-bit CPU. It reads and executes each instruction in q clock cycle like all the old string CPUS. It has addressed pins and can modify its own code. While this CPU usually needs special external circuitry to interact with complex outputs like the RGB LED matrix, these external drive circuits are just meant to store the bitmap being drawn on the screen. The overall unspecialized nature of this CPU allows it to address up to input and output 65,536 32-bit pins.

Self-modifying code

Probably the most exciting feature about this CPU is that it can write to its main memory, which is where its program is stored. This means it supports self-modifying code. Self-modifying code is the ability for the computer to alter its own code that it is running. This was very very annoying to get working properly.

Executing values in registers as instructions

The second most exciting feature of this CPU is temporary instructions. This means that the CPU can make a very temporary custom instruction and execute it while it's in a register instead of being in something permanent like main memory, which is much safer since it decreases the risk of accidental corruption of the program. This was mildly annoying to get working.

Memory

There are two memories, which are both 32-bit with 16-bit addresses. The main memory sits outside the CPU and is nonvolatile and stores the program to execute and data to save. The second memory is located inside the CPU and is volatile and used to store temporary values that are needed when operating. For the safety of the program and the user's mental wellbeing, the CPU cannot activate the reset pin on the main memory to delete its own program all at once, since if there was some dumb bug and the CPU deleted data that the user didn't have a copy of, that could result in severe depression because of how heartbreaking it would be for an entire program that you didn't have a copy of to be deleted in the blink of an eye. So yeah, better to be safe than sorry.

About the morbidly obese main memory

Since the only memory that can be edited by circuitry and be used as permanent storage (EEPROM) only supports up to 10-bit addresses and STRING32000 supports up to 16-bit addresses, I have decided connect 64 EEPROM, which in total supports up to 16-bit addresses, fully utilizing the CPU's address space.

-----------------------

This computer currently only runs one program where you can make 32x32 pictures in black and white, but I'll make more programs for it in the future.

Controls for 32x32 painter:

keyboard controls: WASD to move cursor, Q to display an image, E to toggle pixel between black and white.

stepper: Use to select the picture slot. There is a face drawn in slot 0

PWR and EN: toggle both on to run. PWR is the main switch and EN freezes the clock when disabled.

-----------------------

CREDITS:

Credit to Sanderokian Stfetoneri (author of Femto) for the fast clock circuit

FORK FOR BEST USER EXPIERIENCE

This is just a quick little computer I tossed together

A programable CPU/Proccessor/computer/whatever this qualifies as! 256 bytes of RAM/Memory, a working ALU and processor, and programable. Takes commands as 32 bit inputs, explained at the top of the "CURRENT PROGRAM" subcircuit, currently setting the first variable to 3 and then incrementing it. to edit the program, change the constants at the top of the CURRENT PROGRAM subcircuit to the commands you want(commands are listed in the processor subcircuit). note: variables, if not set to a value somewhere previous in a program, will not be 0, but undefined(red). also, all numbers are stored as 8 bit, and will roll over. there is no difference between adding 255 and subtracting 1. if you want to use a different ALU, make sure to either adjust commands in the programs you make or use the same ones as mine.