SimulIDE trunk Tester builds.

For testing, what is the difference between SimulIDE_1.1.0-Rxxxx and SimulIDE_1.0.0-Rxxxx?
Thank you.

Added:
... and SimulIDE_1.0.1-Rxxxx.

For testing, what is the difference between SimulIDE_1.1.0-Rxxxx and SimulIDE_1.0.0-Rxxxx?
Thank you.

Added:
... and SimulIDE_1.0.1-Rxxxx.

1.1.0 is development version, it is 2 versions ahead of 1.0.0.

1.0.0 and 1.0.1 are "frozen": no new features or components are added unless it solves some error.

1.0.0 was "frozen" 7 month ago, it should be already "stable" but not much testing in this branch.
1.0.1 was "frozen" this month. Has a few improvements in debugger and many other things.
1.1.0 was started this month and is very similar to 1.0.1 (by now).

1.0.0 should be considered stable and 1.0.1 published as "unstable" (only for testing) as soon as possible.


About all the errors found by Defran I will have a look and post when I have something to say.

arcachofo wrote:

For testing, what is the difference between SimulIDE_1.1.0-Rxxxx and SimulIDE_1.0.0-Rxxxx?
Thank you.

Added:
... and SimulIDE_1.0.1-Rxxxx.

1.1.0 is development version, it is 2 versions ahead of 1.0.0.

1.0.0 and 1.0.1 are "frozen": no new features or components are added unless it solves some error.

1.0.0 was "frozen" 7 month ago, it should be already "stable" but not much testing in this branch.
1.0.1 was "frozen" this month. Has a few improvements in debugger and many other things.
1.1.0 was started this month and is very similar to 1.0.1 (by now).

1.0.0 should be considered stable and 1.0.1 published as "unstable" (only for testing) as soon as possible.


About all the errors found by Defran I will have a look and post when I have something to say.

Let us suppose something is fixed in 1.0.0 or 1.0.1, does this mean, it will be fixed in 1.1.0 as well.

I wonder what your preference could be for testing the actual 3 unpublished families.
I mean, for example, do I keep, for the time being, testing 1.0.0 or moving to 1.0.1, if not 1.1.0?

Let us suppose something is fixed in 1.0.0 or 1.0.1, does this mean, it will be fixed in 1.1.0 as well.

Yes, if the fix applies to other versions it will be solved in all these versions (including 0.4.15).
Or at least that is the idea, but sometimes I'm a bit overwhelmed (now working in 4 versions) and things can be a bit messy.

I wonder what your preference could be for testing the actual 3 unpublished families.
I mean, for example, do I keep, for the time being, testing 1.0.0 or moving to 1.0.1, if not 1.1.0?

Just to clarify:
- 1.0.0 is published as "unstable" (for a long time).
- 1.0.1 and 1.1.0 are splitting right now.

Fast reply:
In your case maybe better stick with 1.0.0 at least for a few days.

Some explanations:
Right now is a moment of several changes, not only in the program but in the whole project.


About the program:
- There is an important change in >= 1.0.1 which is being more complicated than expected.
So these versions are very unstable until I solve these issues (see all the reports from Defran and TimFisch).

- There is also another important change in 1.1.0 affecting MCUs.

- Splitting 1.1.0 from 1.0.1 was complex, it didn't happen at an exact revision (this=problems).


About the project:
- There is a problem with lack of testing and/or reporting for versions that are "frozen", because the most active testers here focus in the development branch.

- The time I can work in the project depends on many things, including how much financial support I get.
Right now Patrons are the main supporters, but keeping the current Patron benefits are affecting the development.
So this (probably) needs to change to get more freedom in other areas.

I'm implementing some changes to try to improve the situation, this is a work in progress and still not fully defined.
But during this month I hope to get some changes done.


So in your case maybe better stick with 1.0.0 at least for a few days.
Once 1.0.1 and 1.1.0 are more stable you might want to test these versions.
Preferably 1.0.1 (for your use case 1.1.0 is almost the same right now).


I add more information than what you asked, but it is all related an also relevant for the most active members here.

Not a critical bug: incorrect display of inverted signals. A similar error occurs in the program SimulIDE-1.0.1. The program SimulIDE-1.0.0 displays inverted signals with a shift of the strikethrough to the right.

Not a critical bug: incorrect display of inverted signals. A similar error occurs in the program SimulIDE-1.0.1. The program SimulIDE-1.0.0 displays inverted signals with a shift of the strikethrough to the right.

Seems like I can't find a good solution for this problem.
Every Operating System does it in a different way, especially Windows does very weird things with this character depending on the font type.
Hopefully some day I will find a proper solution...

arcachofo wrote:

Let us suppose something is fixed in 1.0.0 or 1.0.1, does this mean, it will be fixed in 1.1.0 as well.

Yes, if the fix applies to other versions it will be solved in all these versions (including 0.4.15).
Or at least that is the idea, but sometimes I'm a bit overwhelmed (now working in 4 versions) and things can be a bit messy.

I wonder what your preference could be for testing the actual 3 unpublished families.
I mean, for example, do I keep, for the time being, testing 1.0.0 or moving to 1.0.1, if not 1.1.0?

Just to clarify:
- 1.0.0 is published as "unstable" (for a long time).
- 1.0.1 and 1.1.0 are splitting right now.

Fast reply:
In your case maybe better stick with 1.0.0 at least for a few days.

Some explanations:
Right now is a moment of several changes, not only in the program but in the whole project.


About the program:
- There is an important change in >= 1.0.1 which is being more complicated than expected.
So these versions are very unstable until I solve these issues (see all the reports from Defran and TimFisch).

- There is also another important change in 1.1.0 affecting MCUs.

- Splitting 1.1.0 from 1.0.1 was complex, it didn't happen at an exact revision (this=problems).


About the project:
- There is a problem with lack of testing and/or reporting for versions that are "frozen", because the most active testers here focus in the development branch.

- The time I can work in the project depends on many things, including how much financial support I get.
Right now Patrons are the main supporters, but keeping the current Patron benefits are affecting the development.
So this (probably) needs to change to get more freedom in other areas.

I'm implementing some changes to try to improve the situation, this is a work in progress and still not fully defined.
But during this month I hope to get some changes done.


So in your case maybe better stick with 1.0.0 at least for a few days.
Once 1.0.1 and 1.1.0 are more stable you might want to test these versions.
Preferably 1.0.1 (for your use case 1.1.0 is almost the same right now).


I add more information than what you asked, but it is all related an also relevant for the most active members here.

I guess you know already that your project is a real complex one for being universal (not specific to a certain application). Not in vain, somehow similar projects of yours (mainly to simulate various MCU families) are offered for thousands of dollars.

I personally wish that you, with the support of the project Patrons, will succeed in realizing such important simulator so that your big efforts and the generous supports will be rewarded in one way or another.

I personally wish that you, with the support of the project Patrons, will succeed in realizing such important simulator so that your big efforts and the generous supports will be rewarded in one way or another.

Thanks, and don't forget that one of the most important contributions (if not the most) is the dedication of the people testing and reporting (including you).

I have reorganized tester builds, because it was confusing.
I was using the planed name for a future version in the development branch.

For example version 1.0.1 didn't really exist until a few days ago, but I was using "SimulIDE 1.0.1 Tester builds" for the development branch builds because it was the planed name.

Now the planed name for next version is 1.1.0, but this may change, so this name will not be used until next version splits from the development branch and it becomes a real version.

Development branch is "trunk", so I will use "SimulIDE trunk Tester builds." for development branch, and version numbers only for version that have split from trunk.

- Old discussion "SimulIDE 1.0.1 Tester builds" was renamed "SimulIDE trunk Tester builds." (this one).
- Old discussion "SimulIDE 0.1.0 Tester builds" was merged here.

I2C does not work absolutly.
You can test it with the projets:
#101, #123,  #140 and so on that uses I2C protocol.

(Mosfet ok)

Goog luck...

I2C does not work absolutly.

I This issue is solved at Rev 1358.
I'm not updating files here because trunk is still very similar to 1.0.1.

Fizik_S wrote:Not a critical bug: incorrect display of inverted signals. A similar error occurs in the program SimulIDE-1.0.1. The program SimulIDE-1.0.0 displays inverted signals with a shift of the strikethrough to the right.

To solve this issue I had to take another approach:
Drawing the line over the text instead of using font over-scores.

This way I can use the same font, and after some tweaks (windows spacing and weights are different) I managed to make Windows pin names similar to Linux/MacOs.
Also fixed the Chip name that looked bad in Windows.

So FINALLY!!! I could make Components look almost identical In Windows (trunk Rev 1404).

And Tunnels should not draw a line on top, just the exact text entered by the user.

Old Pin names in Linux:

Old Pin names in Windows:



New Pin names in Linux:

New Pin names in Windows:

New build at Rev 1408 uploaded.

New Undo/Redo implementation started, for more info have a look here:
https://simulide.forumotion.com/t1175-new-undo-redo-system#5171

When opening the subcircuit file, the contacts are not displayed on the packaging and on the logical symbol of the subcircuit. When trying to save the case or subcircuit, the program crashes. (Tested on Windows 8.1 x64)

It is already reported here...

https://simulide.forumotion.com/t1192-1408_incomplete-subcircuit

and solved by Arcachofo in R1412.

New build at Rev 1436 uploaded.

Check first message in this post.

New build at Rev 1452 uploaded.

Check first message in this post.

I have finalized the translation of the program into Russian for the current version.

I have finalized the translation of the program into Russian for the current version.

Thanks, translation updated.

When editing a package or logical symbol, the remote contact remains attached to the package or logical symbol.

The ROM/RAM component works with errors if the output is inverted.

Fizik_S wrote:When editing a package or logical symbol, the remote contact remains attached to the package or logical symbol.

Solved at Rev 1506.

Fizik_S wrote:The ROM/RAM component works with errors if the output is inverted.

Solved at Rev 1507.

The subcircuit incorrectly handles the "Gate delay" parameter in logical elements. If the subcircuit is made in earlier versions of the program, then this parameter is processed correctly. For example, the "Real Button" subcircuit from the "Tools" category works correctly in the current version of the program. A test model with errors in the attachment.

Fizik_S Fizik_S wrote:The subcircuit incorrectly handles the "Gate delay" parameter in logical elements. If the subcircuit is made in earlier versions of the program, then this parameter is processed correctly. For example, the "Real Button" subcircuit from the "Tools" category works correctly in the current version of the program.

Yes. I see the problem...

Let me think about it, but probably we need another property "Override Component values" or something like that.

I think there is no need for new property:

Circuit like that in your example should no be type="Logic", instead use type="None".

Subcircuits of type "Logic" are supposed to have Logic components of the same type or "family" with same characteristics.
If some Logic Component inside the Subcircuit has different characteristics, then it should not be type "Logic".