Been developing a logic sim

[MatCat]

I am not simulating any real concept of impedance, just 'high' and 'low'.  BUT Low works 'like' a high Z, as in if a device has ANY high inputs, it will stay high, so there is no true pull down, only pull up, which effectively emulates the concept of High Z connections.  So as long as you know 2 or more circuits outputs will never be on at the same time, you can happily connect them to a single output to emulate a bus concept.

Yes. I realised that on a do'h moment shortly after posting…  You're doing quite literal wired-OR logic…  Could have skipped a whole bunch of OR gates in some of the IC's I'd put together.  Certainly greatly simplifies the simulator logic…

That's three things now you kind of need to make more obvious…  Wires can be removed by re-doing them, it uses wired-OR logic, and the buffers thing…

On the downside, that and the buffers thing also instantly made me feel like it's very much a toy simulator, tacked on the side of a fancy UI — more to give the UI a purpose than to actually be a simulator.  I think at least the 3 basic logic levels is the very lowest bar on a "possibly useful digital simulator"…  meh…  Maybe I'm just not part of your intended audience…  still gonna try make some portion of my pet imaginary processor in it, though…  but it does instantly tank my first impression.  (Though that could be mostly because I've made one myself, and so have a better idea of just what goes into it all.)

The keypad actually got an update after you posted this I believe, the Fn keys are just there for user convivence, they can either be set to switch, or button mode.  I also added an output to the Clr button (it will output a 100ms pulse), it's not there yet but I do plan to add a Clr input as well to the peypad, so that you could have it self-clear itself on clocking in an input or whatever.

I'll have to give that another try…  Could I suggest doing the keypad reset on the trailing edge of the Clr output pulse…?  That would allow the current output to be captured before the reset happens, and I can't think of any downsides.  Though I personally still think a "digit pressed" output signal would be the more useful.

Improvements to IC editing is coming, soon there will be a button on an IC to edit it.  Technically you could have it open in other tabs just fine, but you would have to save whatever you are doing and load it to the other to get any changes in.  That will improve once I have server persistent storage going.

I think I'd prefer client persistent personally, maybe with the option later on to push it up to the server for storage, or if you want to share your design…  Client persistent also opens the possibility of letting it run offline by aggressively caching all your pages — give the kids something to do on a long trip outside of cellular coverage areas — browsers have provisions for that kind of thing.  But also, still keep the ability to save and load the design locally, and add the ability to do that on a per-IC basis, also, so someone could have their own private parts folder.

"Server persistent storage" sounds a lot like making an account…  not gonna happen for a toy simulator…  If you step the simulator up to the basic 5 signal levels, a vague representation of chip delays, and a library of "realistic" built-in IC's to play with like a good slice of the 7400 series gates (can still have a separate panel of ideal/easy IC counterparts also), then maybe — that's the bare minimum I was aiming for myself.  As it is though, the moment an account is required, or any public visibility of my self-amusement dirt scratching designs, it'll be just a flat out nope.

A wire join is an interesting idea, I mean you could do the same with OR (not buffered) or a buffer to do the same thing, but It is an interesting idea to have just an element that acts as a wire joining mechanism.  Dedicated Busses are something I do plan to do in the future.

The main point I was going for there, is that wire joins would also function as routing, so you can bring the wires around other logic, rather than stomping right over top, and in a way that makes it easier to keep track of your design.  Your wires also do straight lines just fine, and a little smarts would allow you to do both pretty well (indicating a curved corner vs. a 45° diagonal corner, I'm not sure how to achieve, though two chess-knight steps could quite easily be recognised and trigger a bezier curve).  And it would be an easy way to throw in a makeshift bus in the meantime.  (Even with busses, if I'm running a four wire bus, I'd rather have the wires separated for easier and clearer joining, and reserve an actual bus lines for 6-width and up, or where the design is getting a little on the tight side.)  Net labels as was brought up earlier, also comes into play here.  Also, some basic drawing primitives that aren't electrically active…  Being able to draw a dotted line separating parts of the design would be really nice.

My main issue here, though, is I simply wanted a set of straight bus lines right down the centre of the design, onto which I could hook the IC's as I put them together.  The design will still work as it is, but, it's a horrible gruesome mess that's seriously hard to take in any way seriously.  (Also, bidirectional pins.)  If you can split the UI wires from the internal representation — assuming you're not already doing this — you can take all those wire joins, and flatten them into a single "star connection" to simplify the simulation (also, prevent recursion problems with wire loops)…  Also, bi-directional pins…

Making CPU's IS my intended purpose for making this, not UI .  I just want a nice UI to use in my endeavors.  To that effect everything needed to do so will eventually get added.  A bus element is planned,  I have also put some thought into bi-directionality, realistically its not absolutely necessary at a logic level,  but it does at IC level, so will probably end up in as an IC pin option.

[Berni]

Yeah tristates are mostly used for implementing buses without a predefined directionality.

Since a lot of older CPUs share and reuse as much internal resources as possible means that the buses inside can actually be quite spread out. One of these internal buses might have the capability to be driven from the external data bus, from any of the CPU registers, from the ALU output, from program counter...etc so this sort of architecture of every possible "bus master" simply having a tristate buffer driving the bus lines is convenient to implement on hardware and makes it easy to add extra masters by simply connecting them onto the same bus lines.

If you implement the bus as a ORed together MUX you need to get a wider set of OR gates every time you want to add a mus master. Works fine, its just messy looking as a big pile of buses converges onto the mountain of OR gates. But it is the way buses are done inside FPGAs since they also typically don't have any internal tristate capability. For the same reason RAM in FPGAs always has 2 data buses, one for write, one for read, since that removes the need for tristate, but makes the bus twice as wide.

But for the case of your simulator i can see how not having tristate makes things a lot simpler since an input can only be driven by a single output, making the wire connection a simple object pointer for "check your logic state here"

[MatCat]

Yeah tristates are mostly used for implementing buses without a predefined directionality.

Since a lot of older CPUs share and reuse as much internal resources as possible means that the buses inside can actually be quite spread out. One of these internal buses might have the capability to be driven from the external data bus, from any of the CPU registers, from the ALU output, from program counter...etc so this sort of architecture of every possible "bus master" simply having a tristate buffer driving the bus lines is convenient to implement on hardware and makes it easy to add extra masters by simply connecting them onto the same bus lines.

If you implement the bus as a ORed together MUX you need to get a wider set of OR gates every time you want to add a mus master. Works fine, its just messy looking as a big pile of buses converges onto the mountain of OR gates. But it is the way buses are done inside FPGAs since they also typically don't have any internal tristate capability. For the same reason RAM in FPGAs always has 2 data buses, one for write, one for read, since that removes the need for tristate, but makes the bus twice as wide.

But for the case of your simulator i can see how not having tristate makes things a lot simpler since an input can only be driven by a single output, making the wire connection a simple object pointer for "check your logic state here"

Actually you can put more then one output to a single input, if ANY incoming connection is high it will stay high even if someone connected to it goes low, so High Z IS doable as it is via line level ORing

[Berni]

Yeah tristates are mostly used for implementing buses without a predefined directionality.

Since a lot of older CPUs share and reuse as much internal resources as possible means that the buses inside can actually be quite spread out. One of these internal buses might have the capability to be driven from the external data bus, from any of the CPU registers, from the ALU output, from program counter...etc so this sort of architecture of every possible "bus master" simply having a tristate buffer driving the bus lines is convenient to implement on hardware and makes it easy to add extra masters by simply connecting them onto the same bus lines.

If you implement the bus as a ORed together MUX you need to get a wider set of OR gates every time you want to add a mus master. Works fine, its just messy looking as a big pile of buses converges onto the mountain of OR gates. But it is the way buses are done inside FPGAs since they also typically don't have any internal tristate capability. For the same reason RAM in FPGAs always has 2 data buses, one for write, one for read, since that removes the need for tristate, but makes the bus twice as wide.

But for the case of your simulator i can see how not having tristate makes things a lot simpler since an input can only be driven by a single output, making the wire connection a simple object pointer for "check your logic state here"

Actually you can put more then one output to a single input, if ANY incoming connection is high it will stay high even if someone connected to it goes low, so High Z IS doable as it is via line level ORing

Ah that is a pretty good solution to it then. The end result even looks a lot like a tristate bus

[MatCat]

"Server persistent storage" sounds a lot like making an account…  not gonna happen for a toy simulator…  If you step the simulator up to the basic 5 signal levels, a vague representation of chip delays, and a library of "realistic" built-in IC's to play with like a good slice of the 7400 series gates (can still have a separate panel of ideal/easy IC counterparts also), then maybe — that's the bare minimum I was aiming for myself.  As it is though, the moment an account is required, or any public visibility of my self-amusement dirt scratching designs, it'll be just a flat out nope.

Yes, there will be user accounts, however it will not be mandatory, in fact this entire project is designed from the ground up to run as is standalone, and will remain that way, I will make hooks into the engine to integrate into my own web solution, but the git project as cloned will ALWAYS work as it standalone.  Very soon the engine will support using localStorage so there will be persistence of files and the same exact management UI as will eventually be used for the accounts feature and sharing of designs, only the engine will support handling saves either as local actual files, localStorage, or server side, choice is users.  Only designs that are published to server side as public share would be visible to anyone else even if stored server side.

[MatCat]

Added some pretty big features since I last posted, copy and paste, various improvements, optimizations to the draw routine, etc.