So yeah, a somewhat eventful weekend !
Gates implemented :
- XOR (types 1 and 2)
- XNOR (types 1 and 2)
- PULL UP
- PULL DOWN
Also implemented :
- Update cascading.
- More than 2 inputs accepted for <AND, OR, XOR, NAND, NOR, XNOR, BUS> gates up to 8
(Tested with extreme prejudice, one of my test outputs fills a .txt file of 53MB, see here : https://nb0174.github.io/betterly/res/SomeVeryBigTestOutputFile.txt).
- High Impedance Signals (ZSignals) that are emitted by TRI-STATE gates and can be received by <PULL UP, PULL DOWN, BUS, BUFFER>.
- A Website start (https://nb0174.github.io/betterly/) : maintained on my Github account (Nicolas) by Maria and Kevin.
Upcoming features :
- More "inputs", such as a ZSwitch for IC's, a Button (quick toggle), <High, Low, Z> Constants, a Clock.
- "Advanced Gates" such as the 2 Input Multiplexer (2MUX) or the SR Flip-Flop to cite but 2.
- "Custom Gates" => Integrated Circuit import/export in a non proprietary format (JSON probably).
- A GUI at some point.
To anyone building this :
- You are probably insane.
- Made in Scala for some reason.
- Seriously get yourself checked.
- The logic part by me (Nicolas) is interestingly built, so interestingly that it can withstand a barrage of 250'000 consecutive commands. 300'000 made the JVM crash, I didn't bother asking questions. The output of which is the aforementioned 53MB .txt file.
- There is a psych ward at the Hopitaux Universitaires de Genève, and most any big city, so yeah, maybe reevaluate the prospect of making this yourself.
A small group of rag-tag students with hearts of gold start their quest to build the probably-somewhat-mighty open-source education tool that might one day be used by someone.
Their names, stored here for posterity, are :
- Maria Paramonova
- Clément Jeannet
- Kevin Colombara
- Nicolas Boeckh
May thy names in the future resonate through the bountiful halls of a castle inhabited by people that actually had a project work.
The idea being to replace commercial tools like Logicly and unsupported tools like Logisim.
As such, I started coding the "backend" of the application, allowing for basic circuits to be built (NOT, AND, OR, XOR, NAND, NOR, XNOR Gates, Input switches) using a "command line".
We are of course planning on having a GUI done.
Everyone is sick ! (Except me, I'm just crazy !)
So yeah, my part is nearing it's official end !
I've mostly finished object serialization (-> formalization of how to represent things in order to recreate them from raw data).
I've added support for K-Bit circuits ! Which means that people can now make circuits with compression ! Although the concept is mostly theoretical, it doesn't hurt to have the ability to use and demonstrate it. If related feedback is negative, we will add a setting required to enable them.
We'll try to obtain feedback on our progress from a professor that implied that if this software was completed and released, he would probably use it.
At the moment our GitHub repository remains private, but as soon as we have a working beta, we will make it public (Soon to very soon, do not fear !).
We've had interactions with Xoeseko from Project 1 [CUI] / Local , where we discussed linking our project on the [sdg.market] project he is active on.
- create graphical nodes
- drag & drop
- Beginning of the different elements of the GUI ;
- First tries to currently using CSS styleable elements;
- Reading draggable elements.
Original by Clément on December 1, 2018 at 15:07 : <https://nb0174.github.io/betterly/SDGIP/originalTexts/01122018_1507.md>
Edited by Nicolas on December 1, 2018 at 22:41.
Dear diary, something had me frustrated these last two days.
In all seriousness, I hit a snag on Thursday evening. All was well until I had to create a functioning sequential logic fulfilling circuit. The most basic being the SR-Latch.
The mass update paradigm that I had been using functioned in such a way that so long as nodes needed to be updated, they would be.
If you know the topology of an SR-Latch, you know that this poses a problem, as an SR-Latch contains 2 NAND or 2 NOR gates that need to feed into each other (see https://nb0174.github.io/betterly/SDGIP_Images/SRLATCH.png).
This caused in my previous generalized update paradigm what is called a livelock (basically a while(true) loop), making the program nonfunctional.
The new paradigm I implemented today that fixes this is actually something that is somewhat generalized : instead of looking at the individual gates, I check that all outputs have normalized.
This has a couple of advantages and a couple of disadvantages :
- (+) It allows for sequential logic fulfilling circuits.
- (+) Less polling / update.
- (-) On huge circuits it might cause memory problems.
- (+/-) Will force the program to have a preset thread for the logic handler, allowing for the user to kill the simulation should there be some kind of infinitely oscillating circuit.
Next up will be a continuation of my serialization and deserialization efforts to set the ability to "include" an IC into a project or into another IC (probably in the .json files, I'll need to tweak my deserialization, as well as adding a name, a label, and optionally a description and an author (for a form of posting using CC-BY, I think). This also includes finishing up my IC class.
Have a nice week end !
For the program to be user friendly, we need an easy and simple interface to work with!
That is why this section is here, to provide an example and help the development of the software in question!
For a really basic guide, follow this link: Design1 (embedded picture in post also).
Original by Kevin on December 2, 2018 at 08:51 : <https://nb0174.github.io/betterly/SDGIP/originalTexts/02122018_0851.html>
Edited by Nicolas on December 2, 2018 at 15:20.
Cool stuff is going on. I'm currently in the process of finishing up my custom IC's. The RS Latch works (I think i talked about that previously but I'm still happy).
So yeah, exporting an IC has been slightly amped, as the IC's now support A Name, a Label, an optional Description and an optional Author. They also support an <includes> system, allowing for an IC to require other IC's (in other files).
I'm not sure about packaging all of it, as it would take more time to generate a sort of compressed file and is overall less open. On the downside sending a project to someone would require the user to send all individual files.
In this sense we could make a "package for export" system, which would either put everything in one same file with an explicit delimiter (safe, less work), or 'zip' them together (risk of a badly integrated compression algorithm, data loss and server side refusal on certain school/enterprise servers - the famous Zip Bomb issue).
I will try to finish this this evening, then clean up my code (already pretty clean in my opinion) and add comments and documentation.
I'll then lose an hour or two on the website establishing a correct CSS image as link (good luck to me).
I might then start making custom ScalaFX containers based off of Kevin and Marcy's designs so as to help relieve the pressure on Clément and let him worry more about the functional side of the interface and not the pretty colors.
Tune in tomorrow for another update of me writing pages of text in 15 different locations. This is Nicolas, signing off. *static*
It's the end of the day, so I'll make this quick.
All our exports work !
We have successfully managed to export both an SR_Latch and a 2-way Muliplexer and re-import the SR_Latch into another IC that is the Delay Flip-Flop. And it works (well, if one counts the fact that all circuits are firing and it considers the clock and the update have cycled... minor details).
That is way cool... Now I'm going to sleep.
We are nearing the end.
So yeah, imports and everything works. I can build a DFF_Set Gate from a DFF gate and a 2-way multiplexer with no issues, the DFF being itself built upon 2 IC's. That works.
The problem is that all of these cascading updates tax the system a lot. I'm thinking about implementing a shortcut by generating clock/value variation tables, that would be stored in the save file or generated on creation (most likely the former, to avoid redundant calculation).
My only conundrum is as to how I would proceed, but I'll get there soon enough.
The one downside of this is that people would have to indicate what switches / connectors are clock-bound.
We can then have the added benefit of differentiating normal IC's from sequential IC's with a small triangle, which is the "standardized" notation.
Food for thought. Good night.
After working for a few hours on designing a Logo for our application, I finally made one that could be a first prototype! This could be represented as an artwork for the logo.
It was designed after the idea of a circuit and some logic circuits, but simplified!
The black and white is the representation of something really simple, as if the program is a different way of writing circuit on paper! Also, those colors will be the main "theme colors" of the software.
The original icone was created on a site, hence it can still be modified quite easily!
Here's the link: https://logomakr.com/8kSQa0
As of now, I am starting the development of the potential future button.
Betterly is an open source alternative in the realm of education, specifically for lessons about circuit design. Betterly is a digital logic simulator built with SCALA using IntelliJ IDEA.
There exist many alternatives to Betterly for different platforms with different licenses such as Logic.ly, BOOLR, Wired Logic, Hradlia and others. All these software share some characteristics, some of them are open source, some of them are free.
These kinds of educational tools are mostly used by students. The first appearance that we have recorded of those tools happened around 2001 and since then there have been more and more users and alternatives.
So which applications to learn circuits design are used in Switzerland?
We are going to contact some of the Universities all over the country to find this out.
Original by Maria on December 9, 2018 at 08:43 : <https://nb0174.github.io/betterly/SDGIP/originalTexts/09122018_0843.md>
Edited by Nicolas on December 10, 2018 at 21:15.
My part for the moment is more or less done. I'm shifting my attention to relieving Clément in the tedious aspects of the GUI (making things nice, as opposed to making them interact).
Making things nice.
Integrated Kevin's logo design. Made a container that folds ! (I have absolutely no clue what I am doing, but it seems to work nicely.).
I'm using my previous file system implementation to make a config/lang system.
We thought that it would be interesting to find similar applications and compare them. This helped us to understand their similarities and differences. The information that we were looking for was
- Creation date
-Date of the last update
-Type of license that they use
- On which platforms it runs
-Is the application is Open Source
The useful sites for that were > Alternativeto.net
> Official sites of this applications
- Connectors on gates
- Connections between gates
- Multiple selection
- Elements deletion
Merge with the logic part
Finish the diferents gates with the corresponding logic one
To continue on the design development, we actualy need to make some easy to comprehend icones for the user to use.
At first, I tried to use a 2D software to create those icones, but due to the lack of experience with those softwares, it was really difficult and time consuming to even create a good looking one.
After spending a lot of time trying to get one done, I switch to another software that I'm familiar with. Its called blender, a 3D open source software that can do a lot things from creating a 3D model, making textures, animating, game engine, etc
From there, after maybe 10 minutes I got the first icone done and it was looking quite good actualy. Because I used a 3D based software, the icone is actualy a 3D model in a virtual scene. Then I made a render of this scene to get a 2D image and due to the three dimensional scene, I got some small shadows on the icone that gives it a real feel.
Since I switched softwares, the development's been doing great!
Advances were made, the logic and graphical parts were merged (at least in the sense that the code compiles and the features exist). Now we need to smoothly integrate the graphical state of the circuits, make the view cleaner, and make it pretty.