Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

Correct

EDIT:

Just so you know there is some known funkiness in the simulation with latches both SR-style and RS-style (or any feedback loop, really) and how their initial starting conditions (which are random) affect their future timing behavior. Sometimes it can take an extra tick to set, sometimes an extra tick to reset. Once the initial state is determined, it will be consistent, but there's no way to determine how it will act before the initial state settles.

Also (and there's some nuance to this that I'm going to skip over) RS latches that exist as their own component will always start Low, but an SR latch's will always start in an unknown state.

also if you use an RS-style latch, and have a NOT gate attached to the output to serve as the Q-compliment, there is a chance that you will have both the Q and the Q-compliment have the same value for one tick.

Interesting. What do you mean "RS latches that exist as their own component"? Does this mean instancing each latch out into its own chip might solve this issue? I guess it's worth a try.

(1 edit)

Not so with an SR Latch (aka: a NAND or NOR style latch) but yes with an RS Latch (a Not-or-and style latch).

Either style will still take an extra tick on one of either the SET or RESET action, but an RS it will always start in a low state.

I see what you mean. However, pulling the latches out into their own chip does seem to have fixed the problem.

so wait what how does that work


I've been trying this for 2 hours nothing seems to work

can you show me an eaxmple

(1 edit)

I got past the randomness, use a multiplexer. the A input would be the output of the mux (it cycles) and the B input would be the data. the select would be the output. I tested it in Sebastian's RAM-256x8 and got all 0s.