This is insane! I don't think I'd have it in me to make something like this! :)
Neutrinos
Recent community posts
Hey! So sorry for not seeing your response sooner!
It's just how the busses take inputs. You wire from the input pin to the pin on the bus line you want it to use, and it will make the wire disappear, with a red dot on the input pin to let you know it's hooked up!
Here's a link to this project's files so you can try the chips out for yourself! (Be careful, the big storage chips can be pretty laggy!)
https://drive.google.com/drive/folders/1izAIND0fSJdlHVHxr_yGPsGMboNPWQWl?usp=dri...
Hey, glad to know this hasn't been forgotten about after so long!
I do still have them, and I can attach the files if you like! To be honest though, I highly encourage attempting to make your own. Mine are, let's be honest, quite crude, and I'm sure you could come up with something better!
For now, here is the project file. I haven't done much with it since my last post, but I hope you enjoy it!
P.S. be careful of the large memory chips, they will lag DLS worse than Blighttown.
https://drive.google.com/drive/folders/1izAIND0fSJdlHVHxr_yGPsGMboNPWQWl?usp=dri...
Hey! Thanks for your response.
Sorry about the confusing short-handed chip names!
The "C4" Chip is a 4-bit counter I made.
The "M41" Chip is a Multiplexer that chooses from four inputs to be sent to one output.
As for sending my save, that's good to know! I'll attach the project file in this response after I give it a once-over. That way you can see how each chip was built!
When you have conflicting data going to a pin, it will flicker. This is intentional to let you know something is wrong. If you want either input to send data to the pin, use an OR gate to combine them, and send the output to the pin.
2 NOR gates can be used to make a simple Set-Reset Latch.
Sebastian has a tutorial on memory!
Hope you get these solved! Good luck!
I'm confused. What do you mean they are "gone?"
Can't you make all of those in DLS several different ways?
Invert the output of an AND gate to get a NAND.
Invert the inputs of a NAND gate to get an OR gate.
Chain the OR gates together to get OR3 and OR4.
To make an XOR, use 1 OR gate, 2 AND gates, and 1 NOT gate. Have both inputs go into the OR gate and one of the AND gates. Invert the output of that AND gate with the NOT gate. Then use the second AND gate to combine the OR's output and inverted AND's output.
And I'm not sure what you mean by, "4-bit block," to be honest. Are you referring to a register?
I'd also like to show my modified clock, since it's kinda the heart of the serializer;
The base clock runs constantly. The enable signal gets written to the register on the next rising edge of the clock. The register output is AND-ed with the base clock output. This ensures the clock always has a consistent output when being enabled, as the enable signal can't make the output pulse prematurely.
The F0 and F1 signals control the frequency of the clock.
It's about time I started experimenting with serial encoding in DLS.
First things first, What's the difference between parallel and serial communication?
In Sebastian's amazing Digital Logic Sim YouTube series, all communication has been done in parallel. This is where we send a given amount of bits all at the same time on their own wires. For serial communication, we need to send those bits one after the other, over time, on a single wire.
We'll need two chips to do this. A serializer, and a deserializer.
The serializer will take in a parallel binary input, and convert it into a series of pulses that represent the original number.
The deserializer will take in that series of pulses and convert it back into the original number.
So, in reality, at least for the way I went about this, the serial output will require two wires. one for the clock signal, and one for the data signal.
Here's how that would look;
Pretty neat, right? Don't worry, it get's very ugly from here! Boy, I really need to rework these things to be simpler, or at least look nicer.
Alas, here are my first iterations of the serializer and deserializer;
Serializer:
Deserializer:
To be honest with you, I'm quite terrified to try and explain how these actually work. I'm almost certain there's a far better way to accomplish this behavior, but this is what I came up with.
Long story short, they both use a counter and multiplexor to select which bit is being written/read to/from a register. There is some logic to decide when the clock runs the counter, and some logic to decide when to write to the registers.
One concern for the future that I have, is that I've made the serializer with an internal clock. This may, or may not come back to haunt me later on.
And that's as much as I currently feel comfortable saying about these things!
I'll happily answer any questions you ask to the best of my ability!
This one took some time to get right, as I pretty much just built it from scratch using the diagram I showed as my guide. I'd love to hear your opinions on it! I'd also love to see someone come up with their own version and share it with me. I can't wait to experiment with creating more components that use serialized signals!
That's all for now! I've more DLS hijinks to get up to! Thanks for reading! <3
Hey, Angus! I decided to catch up with you! Have a look, yeah?
I've made an update to my registers using the new Bus lines. In short, it helped me greatly reduce the number of wires to be, well, wired!
I kept stacking and stacking using this design until, well, the simulator couldn't really take much more. I learned the hard way why you stopped at 4kB! :D
Let's start from the ground up, shall we? Here are all the registers I've built.
Here is what is inside each one of these, from left to right.....
![](https://img.itch.zone/aW1nLzExODc4ODA5LnBuZw==/original/jc0H1k.png)
![](https://img.itch.zone/aW1nLzExODc4ODE5LnBuZw==/original/Y1LMsg.png)
![](https://img.itch.zone/aW1nLzExODc4ODIxLnBuZw==/original/d5hL0A.png)
What a climb! As you can see, I got a little lazy with the wiring towards the end there.
This was also around the point where DLS's framerate began to give me flashbacks to Blighttown.
Because the simulator was running so slow, I couldn't be bothered to try and build 4kB, but I did set the chips down to conceptualize what it would look like. Not too much different, but I was beginning to run out of workspace, so I had to rearrange a few things;
If you ask me, 1kB is probably more storage than I'll ever need in DLS, so I'm happy with what I've made here.
Maybe when performance improvements are made I'll continue to stack this design.
These aren't too terribly different from the register in my original post; They still use binary counting to select which byte is being read from / written to, but there is one main thing I'd like to point out, and get an opinion on.
If you take a look at the yellow pin, you'll notice it's connected to two small MUXs. One MUX has a Not gate behind it. It's the one connected to the Orange Bus Buffer chips. By doing this, I've made it so you can only either read or write to the chips at any given time. Turning the yellow Store, or, "Write" pin turns off the connection to the output pins. I'm not sure if this will be useful, but for some reason it seemed like the logical thing to do. (see what I did there? :p) I can, of course, always change it if needed.
I've also considered making a version that uses a counter to select the bytes, like a stack pointer or something? I've made one that has a toggle for counting in reverse, and so it would work. It would drastically reduce the amount of input pins needed, as you would only need the Data pins, Write pin, Clock pin, and reverse-counting toggle pin, and counter reset pin. Unfortunately, since the current version doesn't allow 7-Segment Displays to be embedded into chips, there would be no way to visualize which Byte is selected, without re-introducing all of the pins we just tried to bypass by adding the counter in the first place.
You could build a chip to convert a binary number into the same number of clock pulses, I imagine this would best be done using a multiplier, as it would require less pins than just inputting the Byte number you want to select. Having the reset pin can act as a sort of workaround to visualizing the selected byte, as you can just reset the stack pointer to 0 before moving it again.
The downside to the whole stack pointer Idea is that you can no longer select a Byte by sending bits in parallel; it has to be done with a given number of clock pulses. This means the read / Write time goes from nearly instantaneous to being dependent on where in the register you are writing to, because of the time it takes for the stack pointer to move there. Perhaps this feature would be better served in a serialized register, Which I also plan to make sometime.
Here's a 16-bit counter I made that would work well for this;
This counter doesn't slow down the simulation at all, and it can already select over sixty-five times the amount of Bytes I've managed to fit in a register. Although, because of the current maximum clock speed, it takes several minutes to count all the way up.
Here's the base counter that I stacked up to make this one; I think it may need a modification or two.
Because of the issues I mentioned, I think using a SerDes setup (Serializer - Deserializer) would work better than a counter. They could even be used together; We'll get there in a later post, but I have ideas.
(Side note; Inside the 256 Byte chip, you'll notice a bug I encountered where, if you screw up the bus line placement by only setting down pins, they cannot be deleted. Or, at least, I haven't yet found a way to do so.)
I already understood what you were saying in terms of hardware, but now I understand why you suggested the change, so thanks for clarifying!
Your explanation wasn't bad, and yes, to you and I, having NAND be the initial chip is more intuitive, but hear me out.
Imagine for a second you've never touched digital logic:
"Here's a NAND gate."
".... What on Earth is a NAND gate."
vs.
"Here's an AND gate, and here's a NOT gate."
"I can immediately tell what these two things do."
"Furthermore, I wonder what I'll make if I put one in front of the other and wire them up." (It's a NAND.)
You could, of course, just, well, explain what a NAND is at the start, I suppose. Although, I still think it's not the best option. So, here's why I initially said I both agree and disagree with you...
You are 100% correct when you say starting with the one NAND chip would be simpler.
However, I believe starting with the two concepts of AND and NOT makes it even more intuitive, to more people in general. It gives new users a clearer picture concerning how segments of logic should fit together going forward.
There are dozens of other logic sims that tick the boxes you described, and I think this one being the way it is helps it better serve as a teaching tool.
Glad we had this talk, can't wait to show you what I'm doing with DLS! Cheers!
I was curious to learn about error correction, so I hopped over to 3B1B's channel. I found an awesome video on an early type of single-error correction known as Hamming Codes. I think it's something I could manage to implement into a computer in DLS, and it would be fun to try! Again, isn't binary counting just the greatest? I might be a digital logic noob but I've got my sights set high :)
Ben Eater - 7-Segment Hex Decoder (YouTube)
Hey guys! Found this video showing how to build a hex decoder for our beloved 7-segment displays!