0.0.2 posted: Adds module/subcircuit support

Version 0.0.2 is now up. The sole goal of this version is to enable subcircuits. Admittedly, if the immediate goal were to simply bring Toves to a usable level, I might concentrate on copy-and-paste or saving files, which it still lacks in this version. But subcircuits are central to Toves’ core, and I wanted to make sure it was built into Toves as quickly as possible. Indeed, in implementing this I found that it is already more complicated than I had expected.

Subcircuits are implemented by adding “Input Pins” and “Output Pins.” This is something of a departure from Logisim, where the toolbar had these pins that doubled as Toggle Switches and LEDs. In Toves, this is currently separate, and my plan is to keep them that separate unless there’s a groundswell of disapproval. (However, I do hope to make Input Pins be interactive in the same way that Toggle Switches are.)

Unlike Logisim, signals are propagated into Toves subcircuits instantaneously. That is, suppose I have a subcircuit “Invert” that consists simply of an input feeding into a NOT gate feeding into an output. In Logisim, using “Invert” would be a bit slower than simply using a NOT gate: If I were to connect a signal into a simple NOT gate and also into an “Invert,” and if I were to connect both into a XOR gate, the XOR gate would occasionally (though very quickly) have an output of 1. In Toves, the XOR gate is always 0.

Also unlike Logisim, the pins are genuinely bidirectional. The terms “input” and “output” are somewhat misleading: The only difference is in which way they face and in what side of the subcircuit they appear. If you wanted to send a signal out the left-hand side of the subcircuit (which admittedly is a bit confusing), then you’d simply use an “input pin.” If Toves already had controlled buffers, then you could easily have a pin that sometimes acts as an input and sometimes acts as an output.

8 thoughts on “0.0.2 posted: Adds module/subcircuit support

  1. studiosi

    Would you find it nice if i collaborate with you in the development of this?

    How many people are working on this?

    1. Carl Burch Post author

      Thanks for the note! Basically I’m developing Toves on my own, and really I’m not looking for help with coding. With the exception of a few minor contributions, I wrote Logisim’s code on my own as well – though for the later versions I’d give a large amount of credit to a contributor (Ilia) who didn’t write code but helped tremendously with suggesting ideas, filing bug reports, and setting things up for translation. Maybe someday Toves will be fully developed enough to involve others, but I don’t think it’s there yet.

      That said, there is room to help! I’m very interested in feedback on how Toves should behave. Not that all ideas are feasible… but “big ideas” are difficult to implement in the context of a fully implemented system. I have several ideas rolling around in my head (several outlined at http://www.toves.org/). But now is a good time to discuss ideas!

      (Also, later on, when Toves is more fully fleshed out, I’ll be very interested in people who can contribute through testing and filing bug reports.)

      1. joha4270

        I’m also open for testing and/or development of toves

        Also how are you going to handle “plugins” where you have (in logisim) a jar file for parts. Or is that feature not going to be included in toves

        Oh and Toves just sound less impressive that logisim

  2. boztalay

    If pins on subcircuits are bidirectional, might it be better if the “input” and “output” pins weren’t differentiated, but there was simply a “pin” that could be used for both? This would also ease any confusion between an input pin and an input button/toggle/switch.

    On a similar note, I don’t think that the type of pin should determine which side of the subcircuit it appears on. It seems more intuitive to me to have the pins show up on whichever side of the circuit they’re on, and in the order they appear in the circuit.

    1. Carl Burch Post author

      This was my first reaction, and I suspect that’s how it would need to be dealt with in the final version. For now, I didn’t want to tackle the “Facing” issue yet, and so the easy way is to differentiate as I did to get a working version. (By the way, they are already done in the top-down order appearing in the circuit.)

      It may be a while before I get to “Facing,” as I think that Facing should be dealt with in an entirely different way than Logisim deals with it. Rather than have it be a property configured for each individual component, perhaps Tove would have you select a group of components and “rotate” them all as a group 90 degrees to the left or right, as you would in a drawing program. If you have multiple components selected, they would retain their positioning relative to each other, so if two east-faing AND gates (one over the other) were selected and then rotated, the AND gates would now be facing north and one would be to the left of the other.

      This may sound appealing, but there are two differences from Logisim that give me some pause. First, when Logisim rotates, often the component is not simply rotated. The multiplexer is a good example of this: The input labeled “0” is at the top whether the component faces east or west, but as I’ve proposed it the pins will simply rotate. A lesser problem is that the obvious implementation would involve any text (like the “0” label in the multiplexer) to be rotated – and possible appear upside-down; however, I think the code would simply have to special-case such labels to be drawn upside-up regardless of orientation.

      1. boztalay

        I see what you mean about the rotation issues. It’s more complex than I had originally imaged it. I agree with you that the direction a component faces probably shouldn’t be a property of the component itself. However, it will be a little inconvenient to have the pin ordering rotate with some components, like a multiplexer. That could be solved with separate components for each direction, but that seems clunky.

        Maybe pin ordering for each side could be a property of components, with just the option of flipping it? I’m not sure if that would offer too much control over things and contribute to overwhelming users. I think in some cases, if there was a good way to control that, being able to flip the pin ordering would be a nice convenience.

        1. Carl Burch Post author

          Yes, this sounds like the way to deal with it. With a multiplexer, there would probably be a property to configure whether input 0 starts at the “top” or “bottom” and another property to configure on which side the selection input.

  3. selfg

    I’m a passable technical writer and have used Logisim to teach a Digital Logic course at a community college for many years (I wrote my own book for that class). I’d be glad to offer my help with end-user documentation (help files, tutorials, and even videos) if that would be of use. I know that it may be a bit early to worry about this phase of the project, but I suspect that it would be easier for me to begin the documentation process early on while there are only a couple of gates to worry about, and then modify the documentation as the project matures. I’ll make my work available to the community as I go so users can get help even during the “0.x” versions. Let me know if this would be of interest and I’ll quietly start working.

Comments are closed.