Thanks Tom! We look forward to users’ feedback.
I forgot to mention that you don’t have to buy EAGLE separately. There are also free trial versions for download, which are completely sufficient for drawing the schematics. Maybe the converter works with the 6 versions of EAGLE. It will certainly not work with earlier versions before 6, because they use a different file format. With later versions after 7 it should also work, tested is only with 7.7.
Tom.
I have now found a bug in the program that prevents it from working on their computer. For testing, I had set the file pointers to a fixed path. Since the path is present on my computer, I did not notice the error. Sorry.
Will fix the problem, test well and then upload the program again.
Sorry Tom
The problem is fixed. It is not necessary to have EAGLE installed to test the converter. You can also start it from the console, specifying an EAGLE schematic file. The included file “QTest.sch” is used for this purpose. The call from console is ./qeagle QTest.sch. The converter and the schematics file must be in the same directory, otherwise the path must be specified when calling. If everything has worked, the converter only reports “Ready”.
This creates the file “QTest.qsch” in the same directory. This file can be opened and edited with QSpice. It is the circuit with OpAmp from the notes.
The schematic, rename to “QTest.sch”:
QTest.h (16.2 KB)
The converter, rename to “qeagle”:
qeagle.h (131.2 KB)
1 Like
Now I have extended the notes with a functional test in the terminal without EAGLE and changed some small things in the program.
QEagleBeta.pdf (1.6 MB)
The schematic, rename to “QTest.sch”:
QTest.h (9.4 KB)
The converter, rename to “qeagle”:
qeagle.h (131.2 KB)
1 Like
Hi Tom. Question, will the direction be forced to change in less than three years when Eagle is discontinued? Seems many users are migrating to KiCAD or (gulp) Altium.
Hello MJones
The development of EAGLE 7 has been stopped for years. But this is not a disadvantage, but an advantage for me. This way is sure that the file format will not change anymore.
To write a converter for current CAD programs I see as a task of the manufacturers of these programs.
Tom
Since there is no feedback on the function of the converter, I am afraid that it will not work on other computers. That’s a pity, but because I can’t check it, publishing the doc and the program further until the problem is solved makes no sense.
I’ve tried using GE-Proton8-14 which is Wine staging with full Vulkan support and dvdx conversion.
Similar issues. Black screen on background, and while small schematics run fast and have no artifacting, loading up the PSU demo falls flat. It takes several seconds to render and has artifacts all over the trace output, suggesting it is still CPU rendering. I used AMD so maybe someone can try Intel to see if somehow that makes a difference, as this should work, it works fine for everything else I’ve thrown at it.
Hi QS,
this 4 steps I used to run Qspice in Linux (Ubuntu Mate). Hope this help.
1
2
https://www.microsoft.com/software-download/windows11
3
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.240-1/virtio-win-guest-tools.exe
4
Install Qspice
It runs like a charm! Enjoy! Toni.
3 Likes
Hello Viticleri
Nice to learn that there is now a solution to the problem. Unfortunately, however, you have to install Windows for it.
For some, however, this is certainly a suitable way. Thanks for this interesting and useful information.
Tom
1 Like
Now the converter works already useful, it does not need to be able to do much more for me. It should not replace QSpice, but help to bridge the time until QSpice works usable under Linux.
The developer notes:
QEagleBeta.pdf (2.1 MB)
The converter, rename to “qeagle” (without extend):
qeagle.h (135.6 KB)
The basic library, rename to “QSpice.lbr”:
QSpice.h (57.9 KB)
How it works is described in the notes (PDF). Tom
Is there any progress with QSPICE on Linux? I still have the black screen problem, and even though I appreciate @TomA 's work, it is too much of a hassle. I also installed a Virtual Machine with Windows and it works there. Unfortunately, Virtual Machines are not perfect, mine is a tad sluggish and looks lo-fi, it doesn’t make use of the entire computer resources, plus it overloads the computer more than if using the OS itself.
So what I ended up doing is installing Windows on a different drive, but, still, I have to reboot and load Windows if I want to use QSPICE. To be honest, I love QSPICE, but I’ve just been using LTSpice due to practical reasons.
How did you get this far? I get the black screen of death when using Bottles, I’ve tried a large combination of different dxvk and rendering hacks available and different wine versions.
QSpice is working in Linux now.
Please see my contribution to this subject here.
3 Likes
I saw your post for this just tonight and sure enough all I had to do on my Fedora box / Bottles was enable the DXVK 3D. Pretty sure I tried this before but I guess a recent bugfix in Wine/Proton DX12 rendering engine fixed it!
It appears I need to use specifically Sys-Wine-10.4 in Bottles for the software to work without the notorious DX12 graphcial issue.
In order to install it though, I had to switch to an older version of Wine that wasn’t using the experimental WOW64 implementation or smth. I think they are talking about it here. The best solution would be to compile the latest version of wine yourself it seems. WOW64 mode does not seem to work on anything - WineHQ Forums
The software is still a bit unstable within Linux. Not sure if the stability issues are also present on Windows.
Okay, that’s a good new data point. I’m surprised DXVK works as that is normally Direct X 11, 10, and 9. But maybe “DXVK 3D” is something else, perhaps a fork that focues on DX12.
I was able to get it up and running in Fedora 42 using the same settings I used in CachyOS. All I did in Fedora 42 was to install Wine and then install Lutris. It looks like it works perfectly when started from Lutris using the System 10.4 staging version, which is the default. On this Fedora installation, I’m running Wayland and I’m using Nvidia GPU and embedded Intel on-board GPU. Qspice via Lutris/Wine uses both GPUs. I’ve still not tried this on my Nvidia-only machine.
On version 10.4, I found that I while Qspice launches, I was unable to install it with this staging version, and also once installed I could not launch other processes from QUX. The model creator would not open, and the simulator would not launch. I don’t know if this is an issue with my specific system. I have a sneaking suspicion it is related to the recent refactoring of how 32 bit and 64 bit executables (wow64) was implemented to avoid the need for separate 32 and 64 bit wine installs or something?
I tried to add the repos for the latest 10.7 staging version but there was conflicts with the fedora supplied packages and while I could open the wine tools wine itself didn’t appear to install, or the PATH was not set.
Bottles is intended to be installed as a flatpak for better containerization of programs and avoiding dependency hell like what I was experiencing so I reinstalled bottles from flathub as the devs intended and then installed the kron4ek staging 10.7 version of in Preferences -> Runners menu.
I had to use flatseal to modify the permissions of the Bottles app so it can access /home and then map /home to Z:\ volume within the Qspice bottle.
It works pretty well although I still have occasional stability and performance issues. At least it is usable unlike Kicad’s included ngspice sim. It would be 
amazing @Engelhardt would contribute his knowledge to improve it! 
On my Fedora 42 installation, all I’ve done is run the demos. Every one I’ve tried works really well. The only issue I’ve seen is in the plot window. In the plot window, I don’t see the lines of the cursor. I can still see the moving values along the x and y axes and also the intersecting points on the graph in yellow (best seen with blue traces or darker colors). This is still usable, to my surprise.
In Fedora, I’ve not tried to use the symbol editor.
I can’t help but venture in saying that the difference is Lutris vs. Bottles. I’d say, try Lutris and run it within Lutris.
Go ahead and make a runner that anyone can install easily within Lutris, I was gonna try to do that with Bottles but there doesn’t seem to be a library of browsable things to install in the same way. I haven’t used Lutris in a while since I haven’t had luck with it and figured people moved on to Bottles now. Geez back in my day we were using q4wine and PlayOnLinux for these containerization and abstraction layers lol