Improved counter component

[DGM]

I wasn't happy with the standard counters forcing you to choose between incrementing and overwriting each tick, as there are times when you want to just preserve the current value. So I made a custom counter with some extra features and uploaded it to the schematic hub.

The name is "CounterPlus_8". As the name implies, it's just an 8-bit counter. I plan to make versions for the larger word sizes but I figured I should submit this one for testing and feedback first.

This counter has separate increment and overwrite pins and will retain it's current value if you don't activate either one. Triggering both in the same tick will act as a clear, resetting it to 0.

There's also a "maximum" pin that takes a byte value. Leaving this at 0 has no effect, but feeding any other number to it will prevent the counter from exceeding that value. If it tries to go over (either by incrementing or overwriting) it will immediately reset to 0 instead.

Bug reports and suggestions for improvements are welcome. Also, is there another place I should show stuff like this off?

[SunCat]

you can join discord, and share screenshots in #show-and-tell channel =)
(discord invite is linked inside the game itself)

[SunCat]

(i haven't seen your circuit yet, just commenting based on description)
for my arches i usually make a conseptually simpler custom adder - where instead of an increment pin it has an increment input, and that input is fed directly into adder - so if you feed 2 in there, the counter increments by 2; if you feed 0, the counter "increments" by 0 = halts
and i think keeding the regular relationship between overwrite and increment is useful (at least in architectures):
1. clearing can just be done by overwrite + not giving anything into data input (or giving 0);
2. there's an instruction that can need either variable increment or a counter overwrite - a conditional jump. if condition is true, then the overwite signal is on, and you want to jump to specific address, not 0. if condition is false, you want to continue execution as usual, thus have correct increment value to skip jump instruction. so, it's easier to just feed increment value regardless of whether condition is true or false, but when it's false, you only have to give overwrite signal to accept jump value correctly - which is equal to signal from condition evaluation

[pleegwat]

My LEG uses a counter with a 6-bit pure incrementer. When incrementing the bottom two bits are cleared, because they are not wired up.

[SunCat]

Originally posted by pleegwat:

My LEG uses a counter with a 6-bit pure incrementer. When incrementing the bottom two bits are cleared, because they are not wired up.

tip: program component accepts 16bit values, so instead of discarding 2 least significant bits, you can shift the whole number to the left by 2, allowing you to use 256 instructions at barely any cost (just means that the labels in assembler have to be divided by 4 to produce correct address that you can save into counter)