Does anyone have an insight on why Spectrum Software is now closed?
P.S. The man behind the company, Andy Thompson, seems to be an excessively humble person. He left a lot of details in the mist. However, all these details are priceless to us mere humans. Memoirs? A blog? 39 years in business is not a small feat.
This is very exciting! Especially the SPICE model library. Microcap's libraries have lots of SPICE models that I haven't seen anywhere else. Being able to grab them will be awesome, even if I wind up using them with LTSPICE.
I’m not familiar with microcap, but I am familiar with LTSpice. If they’re both free SPICE GUIs, surely microcap must be better than LTSpice. I can’t imagine any interface worse than LTSpice.
More than just GUIs, rather SPICE compatible simulators. LTSpice has macro models for most LT parts, that would not be compatible with MC. Likewise MC probably has models that are not compatible with LTSpice.
Now I wish LTSpice would take MC GUI and features, and implement it with their simulator. They should have bought it.
I really hope someone mirrors this on github or something, because there is no guarantee that a website for a closed company will be around for any length of time.
I lost some important records because yahoo shut down it's group archive last year (and banned the archive team from saving stuff wtf), and it's been on my mind lately.
We (ArchiveTeam) are still trying to archive portions of Yahoo Groups (our methods have changed a bit since Yahoo turned off the web archive in December, but the data isn't deleted until Jan 31).
If you're a member of the group (or can join it now) it's only a few clicks to make a request for the data. Doesn't get absolutely everything but all the emails/posts should be included.
I used this in 1991 as an EE undergrad. I initially used it on my 8086, 4.77 MHz XT. It took several minutes to simulate a simple common emitter amp. I don’t remember if I had an 8087 FPU.
I then bought a 486DX, 50 MHz and the same simulation was finished before the mouse button lifted.
Fun times. Microcap was really cool at the time as it was the only GUI based SPICE, and the student version was under $50.
Nowadays I use LTSpice specifically since LT makes good switching regulators, and only develops those models for LTSpice. Otherwise I use Microwave Office.
MC still looks much more polished than LTSpice, at least the GUI. Schematic entry in LTSpice is still abysmal.
It doesn’t. Those are not professional level simulators.
MC is a modern simulator, and professional level. I assume the guy is retiring. You are not going to be simulating large ICs, but it’s still plenty good for other stuff.
There's so pretty much seemingly unique proprietary software. A while ago I found this awesome logic minimizer called "logic Friday". [1] I don't think there's a free or open source version of a tool like this.
I have an idea that the "espresso" algorithm could be used to minimize not only electronic circuits but general boolean expressions for any programming language... I think it would do for a useful refactoring tool.
It simulates logic, supports automated testing, simulates and analyses combinatorial and sequential logic, comes with a large library of components (generic stuff, specific 7400 logic, displays and memories, etc), it can output VHDL or Verilog, and it can export JEDEC files for GALs.
Quine McCluskey is equivalent to using Karnaugh maps. Both are basic digital logic minimization workflows, and are taught in any course covering digital logic or CS-focused discrete math.
> I have an idea that the "espresso" algorithm could be used to minimize not only electronic circuits but general boolean expressions for any programming language... I think it would do for a useful refactoring tool.
I think the goal for most boolean expressions in code is for the reader to be able to conceptually grasp what's being checked for, not for the expression to be as short as possible. Distributive properties can make an expression shorter while simultaneously making the concepts behind the expression much more obscure.
As a compiler writer I can tell you that this is a complex optimisation with very limited use.
N.B. the || (logical or) operator is an "early out" operator whereas the | (binary or) operator is NOT
The compiler would need to look for special cases of value1, value2 and value3... such as: are any of them volatile, perhaps one refers to a memory mapped I/O device, perhaps one if actually a function call, or array dereference, or pointer dereference, what about value1 being a "char" which needs to be promoted before it can be or'd, what about any of the "values" being a constant < 0 which would short circuit the "if" statement and remove the need for any tests.
As I said, this is not as simple as it first appears.
That optimization fudges the difference between boolean or (comparing truth values) and bitwise or. It happens to work under the safe assumption that value1, value2, and value3 use sign bits (as all two's-complement integers do), but logically it's a disaster.
monocasa isn't saying this should be in source code, but rather the compiler should create machine code that does this. Compilers know the types, so they will know whether they're signed (if they're not signed, then < 0 can be optimized out as impossible). Compilers have no goal of creating assembly that would look good in source code.
Good point, although the idea would be you get to choose one for or the other. I think sometimes the simplified expression makes it easier to see the complement (else branch).
btw, I started to think about "boolean refactoring" when I saw J. Edwards' schematic tables video [1].
I've used Logic Friday once to make a wired remote controller device that operated on 74-logic. I haven't really seen any tools that offer more user-friendly ergonomics for that type of problem, except maybe a curve-fitting tool called Eureqa which used to be open-source and went closed-source. Or perhaps Wolfram Mathematica could be used to spit out a few solutions, again closed-source.
> There's so pretty much seemingly unique proprietary software.
Indeed. Something to consider when choosing a license and distribution model for your own projects, including web-based software. Your life is finite, but the life of your software may not be.
I found ngspice extremely useful. I have compared the results with Cadence Virtuoso and the results are usually identical or with negligeble difference. I am trying to use a combination of ngspice and magic for IC design.
Micro-Cap is Windows-only software (it runs on Linux via Wine though) and perhaps more accessible than your current (which probably is "make circuits somewhere, generate netlist, simulate with ngspice, analyze somewhere else") workflow as it has an integrated schematic editor. The most powerful Linux alternative to Micro-Cap et al is probably KiCad.
Is this good for analog stuff, at least as effective as LTSpice?
I've been using the latter on a Mac for simulating vacuum tube (UK: valve) circuits with some success and a very large amount of frustration. I would love something a little less actively user-hostile...
I didn't grow up with it, so coming at it from a perspective of someone who's gotten used to modern software, it's remarkably hard to learn.
The interface is weird. Placement of components isn't so bad but when you want to do stuff like move them or rotate, you fall into this strange mode system that's unlike any other software I've ever used.
Including models is done by writing arcane text commands on the diagram. And also by setting parameters in a hidden window on the component diagram itself.
Models != visual components.
Sometimes I have to set the model designator for a component in the UI twice before it'll "take". That's hostile!
Finickity pin alignment on custom/3rd party components sometimes leads to open circuits when they look closed.
The parameter/settings windows are cryptic.
The wire drawing tool is really nice though.
It's obviously better than writing a setlist in TextEdit but I've found the learning curve very steep, with all the underlying complexity of Spice exposed. The fairly prehistoric interface paradigm that means that any muscle memory and expectations from using any other graphical software just don't help. In fact, they hurt.
I tried your thing when I was looking for circuit design software. I liked it. It didn't have any vacuum tube models at the time (not that I blame you, it's niche) and so I couldn't use it for what I needed.
Does your tool support custom key commands and macros (also can I use it out of a browser)?
Last time I played with it that was what got me to leave. A drag and drop wysiwyg is wholly inappropriate for serious work. Also the search feature doesn’t work well, it stalled looking for “op amp”
And by “serious” work I mean a small circuit with two dozen elements.
Wow, used this extensively in my undergrad. Always used the free version. I remember occasionally running into the "too many nodes" error. Thanks to the creator for releasing the full version for free. I'm sure many EE undergrads will be grateful.
I pinched the title from https://news.ycombinator.com/item?id=20495077 since it's more informative. If this is inaccurate, please let us know. (Submitted title was "Micro-Cap User Downloads – Now Free".)
I'd love to try it out, but I'm not downloading an executable from an `http` URL.
Edit: I hope the downvotes are because it supports `https` (just not by default, thanks to progman32 for correcting me) and not because you think that not wanting to download an executable over an open connection is an unreasonable thing.
How is downloading a executable over https safer? It mitigates man-in-the-middle attacks that could modify the compressed artefact on the fly, but that's possibly the least likely attack on a download imaginable. It's far more likely that an attacker would try to replace the file on the server (that way they can also change and documentation around the file, like the reported MD5/SHA hash you might use to check the file is correct). Why would you happily download that over https?
If you're security conscious enough to not download random executables over http then you really should be aware that it's 99% as dangerous to download them over any link.
On most networks, anyone else on the same subnet as your IP can hijack your connection using ARP spoofing and send you whatever they want if you're connecting over Http instead of HTTPS. That's usually a lot easier to pull off than compromising the server and replacing the content there.
I'd wager that a large number of the system integrators, firmware engineers and random developers scattered throughout the production chains of most of the hardware and some of the software that you're currently using have run completely untested code in scenarios orders of magnitude more hair-raising than this.
The same is probably equivalently applicable to the hardware that was used to compile the compiler that compiled the compiler that compiled the compiler that
you're using.
While it's theoretically possible that a hostile party could modify the package in-transit over HTTP/TCP, it seems far more likely that the hacked package would be placed on the "legit-looking" webserver (by hacking the webserver). In this case, looking to the SSL transport layer as any kind of credibility enhancement to the unsigned binary is worse than ignoring it.
Therefore, an unsigned binary is an unsigned binary, no matter the transport mechanism. I agree that distributing unsigned binaries is poor security practice, but I also think that it is dangerous to think that the transport of an unsigned binary over an SSL connection gives it any credibility.
So.. you haven't heard of automated MITM executable-patching (infecting) solutions? I believe I read about them a couple of years ago.
Once implemented, it's much easier than hacking servers and more convenient to do targeted, semi-targeted, local network/cafe script-kiddie attacks, without it being easily detected. Unfortunately for attackers, these days people don't download and run unverified executables as often, especially over http, so you may need lots of patience if you want do infect a specific person.
I would really love some data (or good reasoning) on how server attacks are overwhelmingly more likely, so much so that the false security impression increases risk.
MITM executable patching attacks are not theoretical. AFAIU, the first hit on "mitm executable infection" [1] and an interceptor (ARP/wifi/whatever) is all a script kiddie needs.
To me, the fact that the server being exploited to deliver bad binaries is a possibility is reason enough to be cautious, and to therefore not regard them with any more credibility than if they were delivered over unencrypted http.
Fair enough, I gladly use apt for the same reason. But I mean download unsigned executables over an unencrypted connection, like this site is by default. You do it?
Does anyone have an insight on why Spectrum Software is now closed?
P.S. The man behind the company, Andy Thompson, seems to be an excessively humble person. He left a lot of details in the mist. However, all these details are priceless to us mere humans. Memoirs? A blog? 39 years in business is not a small feat.