Allow custom art (or at least picking from existing icons) for circuits

[peterb12]

The specific use case I'm thinking of here is people doing a "Build everything from NAND or NOR like in the nand2tetris course", who would like to use their own gates rather than the built-ins, but would still like the correct IEEE symbols.

[hneemann]

The main parts of the Digital implementation supports custom shapes for embedded circuits. The DIL shape of the 74xx library is an example. If you turn on the "DIL package" option in the "Edit Circuit Attributes" dialog, you can put your circuit in a DIL shape. The main problem of custom made shapes is the huge amount of work that it is to implement an editor for such shapes. There are no custom made shapes because there is no editor for shapes yet.

[peterb12]

Yep, and I certainly wouldn't suggest that embedding an editor is a good use of your time. If one could attach a PNG (externally created) to a circuit, that would be enough to meet this need, I'd think.

[hneemann]

But keep in mind: The shape/icon needs to be scalable and a PNG is not a good choice for such a shape. And more important: You have to define where the pins are located.

What I think about is to use an SVG editor like inkscape to define the shape and somehow specify the pin positions within the SVG file. Then you could import the SVG file to Digital.

[peterb12]

Yeah, I didn't think about the SVG issue, or the pin position aspect. good points both.

[hydrogenbomb1212]

it shouldn't be hard to do, you already have tunnels, use the code from a tunnel modify it to work as in or outputs and bind it to a blank sheet with a reference anchor and the circuit.

the only thing i can think of as issue is "how to simulate in VHDL"

a image is overkill for the circuit, and to fix the previously mentioned issue, you can make a circuit have a simulation and appearance file, then call the "tunnel" in/output from the appearance file in the compiled simulation file and the output called from the appearance file should act like the simulated output.

[hneemann]

@hydrogenbomb1212 This is not a problem of the simulation itself or tunnels or the export to VHDL. It's just a problem of how to define the shape and the pin positions of a sub circuit.

[hydrogenbomb1212]

that's why you should try making a second file defining them, it can be simple lines, only 2D you shouldn't try to simulate the shapes, they are cosmetic, i don't see what's the difference why logism does it and digital can't, i know the differences between the two but i cant see why it's harder to define the shapes. it almost seems like it should be harder in logisim since it works while simulating.

[hneemann]

Thats not the problem: You can store the shape in the circuit itself or in a separate file. That makes no difference. But you have to implement an editor for shapes. Thats not hard to do, but a lot of work. If you define an XML schema, you can edit the shape with an XML editor in a separate file. But this is not a very user friendly solution.

[hydrogenbomb1212]

well you can use what you already have, wires. you can make the appearance with a modified wire that has no function and can be seen in the higher circuit and text shouldn't be a problem since its already there

[hneemann]

Again, there is no difference: you must have at least lines, circles / ellipses, quadratic and cubic Bezier curves, a placeholder for pins. The ability to modify all these graphic elements and so on. Not hard to implement but a lot of work.

[sgparry]

This is the one feature I really need in Digital that is missing. I have a substantial project in Logisim (an binary implementation of the classic Little Man Computer in purely dual input gates, buffers and flip flops) I want to port to a simulator that can handle two way connections properly and whose codebase can be actively improved. SVG is one way forward, but has to be approached with care - it is potentially very flexible but there are pitfalls in the way the different SVG editors generate it and it can be very complex. I have some experience of this with Fritzing which uses SVGs for most of its components. Inkscape is the defacto Open Source standard for editing SVG but Adobe Illustrator is the de-facto closed source standard. They way they do some of the most basic things varies enormously - in particular sizing and scaling. AI takes a lot of short-cuts. They both like to stick to their own resolution: 72 dpi for AI, 90 for Inkscape until recently; 96 dpi in html by default and in the most recent Inkscape. This causes numerous problems when importing into Fz. If I read the source correctly Digital already uses Batik to generate SVG, so would we use it to render the SVG as well? An alternative approach: define a very simple XML schema for the graphics that are needed, perhaps based on a very limited subset of SVG. To begin with these could be hand edited - which is actually not as hard as it sounds. Then we could implement a simple export filter in Inkscape (there are several already for similar purposes) to convert from Inkscape SVG to Digital SVG.

[hneemann]

@sgparry: Digital does not use Batik to generate SVG. Digital uses a very simple interface to draw the graphics. There are only a view methods and graphical primitives available which are necessary to draw a circuit. The SVG files are generated by a simple class which implements this interface and writes a text file. And there is already the possibility to add custom graphics to subcircuits implemented in the branch customShapes. Maybe i should merge this enhancement to master. The approach uses a simple XML format to describe the shape and which is stored in the .dig file as an attribute of the circuit. What is missing is a way to define this shape. I thought about importing SVG by picking the relevant information from the SVG and store them in the .dig file. But as you mentioned, this is quite complex because SVG is a very flexible format. Very easy to create but very hard to import. Thanks for pointing to Adobe Illustrator. I will keep that in mind. The other option is the Logisim approach: Write an editor for shapes which adds a lot of code.

[sgparry]

Dear Helmut, Thanks for the helpful reply. I tried the customShapes branch - it does seem to work. If you could this branch merge it in that would be fantastic - I don't mind hand editing the XML.

On 5 May 2018 08:47:13 BST, Helmut Neemann notifications@github.com wrote:

@sgparry: Digital does not use Batik to generate SVG. Digital uses a very simple interface to draw the graphics. There are only a view methods and graphical primitives available which are necessary to draw a circuit. The SVG files are generated by a simple class which implements this interface and writes a text file. And there is already the possibility to add custom graphics to subcircuits implemented in the branch customShapes. Maybe i should merge this enhancement to master. The approach uses a simple XML format to describe the shape and which is stored in the .dig file as an attribute of the circuit. What is missing is a way to define this shape. I thought about importing SVG by picking the relevant information from the SVG and store them in the .dig file. But as you mentioned, this is quite complex because SVG is a very flexible format. Very easy to create but very hard to import. Thanks for pointing to Adobe Illustrator. I will keep that in mind. The other option is the Logisim approach: Write an editor for shapes which adds a lot of code.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/hneemann/Digital/issues/39#issuecomment-386787553

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[hneemann]

@sgparry I have added the code needed to create a custom shape. I have made the xml file a bit more human readable. And please keep in mind that the *.dig files are not intended to be modified by hand. There is almost no error checking. Therefore expect strange error messages if the xml file is broken. :-)

[sgparry]

Many thanks Helmut. As you can see below, I am already putting it to good use! ALU

"Ooo Shapeses!"

On 05/05/18 13:49, Helmut Neemann wrote:

@sgparry https://github.com/sgparry I have added the code needed to create a custom shape. I have made the xml file a bit more human readable. Please use the attached file as an example. And please keep in mind that the *.dig files are not intended to be modified by hand. There is almost no error checking. Therefore expect strange error messages if the xml file is broken. :-)

z.dig.zip https://github.com/hneemann/Digital/files/1976660/z.dig.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hneemann/Digital/issues/39#issuecomment-386803480, or mute the thread https://github.com/notifications/unsubscribe-auth/AER9PT1_yp2dxQUVoeeWudEUgAyR878jks5tvZ_GgaJpZM4O7DKM.

[hneemann]

@sgparry That's funny: The only custom shape I ever made with Logisim was also a ALU. Maybe I should add a custom shape to the ALU of the Digital example processor. :-)

[sgparry]

Sounds like a good idea to me. I have to use this shape, as it is the "standard" one in the GCSE and A level Computer Science textbooks and specifications here in the UK. One of the examining boards even uses a circle for the controller(!) and colour codes the registers, ALU and controller. I don't make my controller that shape but I do put a coloured circular label on it.

On 6 May 2018 08:13:39 BST, Helmut Neemann notifications@github.com wrote:

@sgparry That's funny: The only custom shape I ever made with Logisim was also a ALU. Maybe I should add a custom shape to the ALU of the Digital example processor. :-)

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/hneemann/Digital/issues/39#issuecomment-386859345

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[hneemann]

The Patterson&Hennessy textbooks also use an ellipse to represent the control unit. But a control unit has a lot of outputs which have to match the grid in Digital. And that makes it looking ugly.

[hneemann]

@sgparry I had to change the XML format a bit to allow labels at pins. See the attached example:

shapeExample.dig.zip

[hneemann]

The version v0.19 is required to open the file attached above.

[sgparry]

Thanks Helmut. I will have a look at this later. Really excited about finishing getting my CPU transferred across. I am looking at three big developments this summer. One is implementing animated symbols for things like showing data flows; another is porting digital to TeaVM so that it can run in browser (!) a third is running without the editor, just the simulator and a rwad-only model. Any thoughts?

On 15 June 2018 08:07:18 BST, Helmut Neemann notifications@github.com wrote:

The version v0.19 is required to open the file attached above.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/hneemann/Digital/issues/39#issuecomment-397533272

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[hneemann]

One is implementing animated symbols for things like showing data flows;

I don't know what you want to do in detail, but I think this is not a big deal. Look at the "Data Graph" component as an example.

another is porting digital to TeaVM so that it can run in browser

I don't know TeaVM but there is some quit complex interaction between the user and the model implemented in the CircuitComponent class. I have a doubt that this is easy.

running without the editor, just the simulator and a read-only model

What do you want to do in detail? Such a feature is already implemented. To run the tests in the GUI, the model must be created and run without user interaction. And for all circuit integration tests, the model is also created and executed without a GUI.

[sgparry]

On 15 June 2018 12:28:56 BST, Helmut Neemann notifications@github.com wrote:

One is implementing animated symbols for things like showing data flows;

I don't know what you want to do in detail, but I think this is not a big deal. Look at the "Data Graph" component as an example.

Thanks that's really helpful. I will look into that.

another is porting digital to TeaVM so that it can run in browser

I don't know TeaVM but there is some quit complex interaction between the user and the model implemented in the CircuitComponent class. I have a doubt that this is easy.

I won't know for sure until I try! I just know I have much more chance than with logisim or other older programs.

running without the editor, just the simulator and a read-only model

What do you want to do in detail? Such a feature is already implemented. To run the tests in the GUI, the model must be created and run without user interaction. And for all circuit integration tests, the model is also created and executed without a GUI. What I am seeking to do is add some way of running digital with all the editing tools hidden / disabled, so a student can investigate a circuit (including open subcomponents) and test it without being able to 'damage' it any way. Related to that is being able to run the simulator with no UI at all, so a student could submit a complete model or some data for a provided model (say a machine code program), and various test cases can be run by an automated tool like coderunner. This would allow me to do quiz questions based on the tool.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[hneemann]

What I am seeking to do is add some way of running digital with all the editing tools hidden / disabled, so a student can investigate a circuit (including open subcomponents) and test it without being able to 'damage' it any way.

Such a feature is already implemented: In the "circuit attributes" you can lock the circuit. Then most user interactions are disabled. Only the programming of fuses, diodes and FG-FETs is possible.

[itviewer]

Hi, I want to know when will this feature can be implemented? I am looking forward to it.

[hneemann]

@itviewer Please try the latest pre release build or the source branch "polygon". Let me know how it works for you.

[jxu]

Idk why SVG is even being considered - it's way overkill to use a vector graphics format. Simply implementing a custom sized rectangle where you can map I/O to positions along the north/east/south/west edges is good enough for most applications. This can kinda be done with DIL-Chip layout.

[sgparry]

SVG's are maybe overkill - but simple shapes need to go way beyond rectangles. Students respond to visual cues - the big flying V of an ALU for example and the oval of the controller mentally signposts the whole internal layout of a CPU.

[hneemann]

@jxu: Use the "Layout Shape" type. It does exactly what you have requested: A simple rectangle with inputs and outputs on all four edges.

[jxu]

I have tried height and width in circuit specific settings but they don't seem to affect Layout Shape.

What I mean is to be able to position the outputs on the edges like in Logisim: for example position inputs on the left and right side of the north edge.