Testing a Logisim-Evolution model of Minecraft redstone repeater

UPDATE: Dec 1, 2024

There is a bug in the configurable-delay model; it re-extends pulses that are already extended. It's fine as long as you don't put more than one >= 2-tick delay-repeater in series. I have created an improved model here https://attarc-redstone.blogspot.com/2024/12/an-improved-model-of-minecraft-repeater.html

I trying to make it easier to prototype new components for ATTARC and to simulate future versions of the architecture. I found Logisim-Evolution in my Linux Mint package manager, and it seems pretty decent.

Simulating a 1 redstone tick repeater is easy; it's just a register, or a D-flipflop, connected to a 2-logisim-tick clock (1LT high, 1LT low). So logisim ticks can be thought of as game ticks, and the 2LT clocks is a 1T global redstone clock, just like the redstone simulation built in to minecraft.

But simulating longer repeater delays is tricky; probably the second-trickiest part of redstone simulation. The trickiest would be signal strength, and would require a 4 bit bus.

The delay part is actually pretty easy. It's just a shift-register tapped at different points. Add a MUX and Bob's yer uncle.

The extension part is a bit trickier, but we can extend our shift register with more slots and tap off it with some OR gates to get working. This is similar to how you would build a pulse-extender with 1-tick repeaters in minecraft.

Finally for locking we can just toggle the write enable pins on the register parts. But here's the rub; which registers should we lock exactly? We don't want the registers to hold onto stale data or stale pulses might turn the repeater on after it unlocks. But when a powered locked repeater is unpowered and unlocked there is a slight delay before it's power output turns off. IE it visually unlocks some ticks before it visually depowers. How many? Based on my measurements in minecraft it is the repeater tick delay. So binary decoder and or gates to the rescue. Since the output register already counts for 1 RT tick delay, we need to lock tick-delay-1 shift registers so we get the full delay after unlocking.

3RT repeater depowers 3RT after unlocking

On four tick delay we leave the first three shift registers unlocked even when locked so that they can shift out their contents. On three ticks we lock the middle two, and on one-tick we lock just the 2nd one. Those plus the output register give a repeater-tick-delay length trailing-edge to the output signal before it falls after unlocking.

There you have it; tick perfect.

I'm concerned that once I have 1000 of these in a circuit the complexity may lead to simulation performance issues. Given that the implementation of a 1-tick repeater is trivial by comparison, and that 1-tick repeaters are the most common case, it seems like this implementation should be avoided except when tick delays > 1 are needed.