If you cannot extract the download, then your browser has most likely mangled the data. Check your settings and make sure you download the distribution as a binary file.
C Electric (on UNIX) requires the X Windows system, so you must have X installed. The "configure" process attempts to locate X on your machine, and it customizes the compile of the module "graphunixx11.c" with proper directories for X headers. If the compile of this module has an incorrect path to X, then you must edit the Makefile by hand and fix the paths (or perhaps you have installed X badly and need to fix that).
C Electric can be built on Macinsosh OS 10 in two ways: Carbon and Qt. The Carbon port is not fully debugged. The Qt port requires a license from Trolltech.
C Electric is compiled with MetroWerks on the Macintosh. Although it should be able to compile under MPW, there is currently no "make" file for this, and so you will have to construct one yourself.
When starting from scratch, simply include all of the source files (the exception being those in the "graph" directory, where you only include those that start with "graphmac").
C Electric comes with a "dsw" and "dsp" file that should work with Visual C++ versions 5.0 or 6.0. It also comes with a "vcproj" file that should work with Visual Studio .NET. If these files do not work, you can also use the file "Electric.mak".
The file "nafxcwd.lib" is a Visual C++ runtime library. If you cannot find this file, or any other with the letters "afx" in them, you have two possible solutions: (1) Change Electric from static linking to dynamic or (2) upgrade your Visual C++ to the latest service packs. To change to dynamic linking, use the "Settings" command of the "Project" menu. Under the "General" tab in the "Microsoft Foundation Classes" popup, select "Use MFC in a Shared DLL". Under the "Link" tab in the "Object/Library modules" section, remove "nafxcwd.lib".
I have not seen this problem personally, but one user reported this fix. He used a free download called "RamBooster" and configured it to "run only when CPU is below 0". This made Electric run more reliably and faster.
When C Electric starts up, it expects to find the file "cadrc" in the current directory. (On UNIX systems, it looks for ".cadrc" and is willing to find it either in the current directory or in your home directory.) In addition, it looks for a subfolder called "lib" which contains many useful files (at startup, the only file that is needed from that folder is "evemenus.mac"). If you move the executable away from these files, then it will not work properly.
Even when the files "cadrc" and "lib/evemenus.mac" are present, they may be corrupted by the download process. These files are plain-text files (the file "cadrc" should contain about 10 lines in it, "evemenus.mac" is much larger). If you examine these files with a text editor, you may find extra characters at the end of each line (such as ^M) or you may find that they are all on one line. Either situation indicates that the extraction of the "tar" file has been done incorrectly (keep in mind that Macintosh, Windows, and UNIX all use different line-ending conventions, and this distribution is intended to work on all three). Go back to the installation instructions and follow them carefully.
C Electric's internal graphics model uses an 8-bit deep frame buffer and a 256-long color map. Five of the 8 bits are for "transparent" layers (i.e. the most important layers of the current technology). Of the remaining three bits, one is for highlighting, one for the grid, and one is an "escape" which allows the 5 transparent layers to select one of 32 "opaque" colors.
When something on a transparent layer needs to be drawn or erased, it is only necessary to set the write-mask to that bit-plane and do the graphics directly, without regard to anything on other layers. This makes the 5 most important layers draw more rapidly. The same argument applies to highlighting and grid setting.
The problem on UNIX is that if a program demands all 256 color cell entries, the display flashes when the cursor roams in and out of the window (because the system is constantly switching the color map entries). Also, there seems to be a requirement that such programs use PseudoColor on an 8bpp display, as higher depths seem to cause the whole color-mapping scheme to fail.
To solve this problem, Electric has an offscreen buffer that is 8-bits deep and has its own colormap. After drawing in this buffer, it is copied to the screen. Windows and Macintosh systems have built-in schemes for doing this, but the UNIX X Window System does not: the copying and color map application have to be done in the user's code. This means that there has to be ANOTHER offscreen buffer that is the same depth as the screen. Finally, this second buffer is copied to the screen with an X call.
In such a scheme, there is no color-map flashing, and any depth display can be used. However, there is a great speed disadvantage. For example, to draw a line requires that the data be moved 3 times: (1) when the line is drawn into the 8 bit offscreen buffer, (2) when the 8 bit offscreen buffer is copied to the true-depth offscreen buffer, and (3) when the true-depth offscreen buffer is copied to the screen. So, rather than sending a compact command from the client to the server ("draw a line"), Electric must send a full bitmap to the server. Unless both the client and the server are running on the same machine, this can be much slower.
By default, the X driver implements this offscreen scheme. It cannot run on systems where the X client is on a different machine than the X server, because it demands too much network bandwidth. However, it runs fine on any depth display, and does not suffer from color-map flashing.
For users who do not mind the 8 bit-per-pixel limitation or the color map flashing, the X driver module can be be told to work that way. Simply edit the "Makefile" and change the value of "XPOWER" (see the comments at the top of the file).
On UNIX, it is possible to get C Electric to actually run SPICE after generating a SPICE deck. This requires that SPICE be installed and that Electric know where it is located. Change the #define of SPICELOC in the file "config.h" to set the location. Keep in mind that Electric only interfaces with batch SPICE, and does not interface to interactive versions.
C Electric is able to handle many different interpretive languages: Lisp (actually a Scheme implementation called ELK), TCL, and Java are currently available. The GNU distribution does not include any of these languages, because they cannot be redistributed under the rules of the Free Software Foundation.
If you wish to add Lisp, you can download the additional source code. If you wish to add TCL or Java, you must configure Electric to use it (see the installation documentation for your system).
C Electric has two simulators built in: ALS (our own) and IRSIM (from Stanford University). The GNU distribution does not include IRSIM, because it cannot be redistributed under the rules of the Free Software Foundation. If you wish to add IRSIM, you can download the additional source code.
C Electric has been translated into French, and can be converted to any foreign language. UNIX/Linux users already have the French interface in the GNU download, but Windows and Macintosh users must get the Static Free Software extras in order to use the French interface.
If you wish to translate Electric, please contact Static Free Software for assistance.
In an unusual twist of distribution, Static Free Software makes its source code available free of charge, but not compiled binaries. The web page offers binary versions of Electric or various platforms (Macintosh, Windows, etc.) These binary versions cost money, but they are easier to install than having to compile the source code.