In 2002 some guy emailed me about the NumberCruncher, a floating point coprocessor card for the Apple II. The card was developed and built by Andreas Schmidt, a friend of mine, in 1993. I helped a bit on the software side back then. The NC was a clone of the FPE by Innovative Systems, just more reliable. On the Apple IIGS you could use it out of the box with any program that used the Standard Apple Numeric Environment (SANE) for calculations, thanks to a SANE patch from Albert Chin-A-Young.
The guy who emailed me asked if I had one to sell, but I did not want to give my single remaining NC away, so I declined and forgot about him.

2022: I was browsing the Internet out of Corona boredom, surfing on nostalgic Apple IIGS-related pages. Then I read about "NumberCruncher Reloaded", a NC clone built by reverse engineering an old NC card! In 2021! 28 years after the original NC! I was thrilled to see that, and when I found out that the creator was selling the NumberCruncher Reloaded as a cute, professional-looking product I contacted him. Turns out, he was the guy who contacted me in 2002 :)

Axel, the NC-R guy, even sent me a card! Full of anticipation I set up my old Apple IIGS again, played with it for a while and tried out my old NC card. Everything was working fine, for about three hours. The following day I wanted to show it to my son, but the GS did not boot any more. I could not find the reason, but Axel repaired my motherboard when I sent it to him. Absolutely great.

So now, with my GS up and running, I can do benchmarks of the new and the old NC cards. Here are the results, taken on the following system:

• Apple IIGS ROM03, TransWarp 12 MHz
• NumberCruncher 12 MHz (NC)
• NumberCruncher Reloaded 16 MHz (NR-R)

You will get the most impressive improvement by NC or NC-R when doing trigonometric calculations. Using MathGraphics, a shareware function plotting program I wrote back then, I timed the calculation of a plot of a Fourier series:





You see a lot of sinus function calls here, and the results are great (shorter is better, obviously):



Legend:

• Init: SANE patch FPE.PRD from V. Hemeury
• Old Init: SANE patch from Albert Chin-A-Young
• Compiled: Compiled and linked with a special FPE float lib from ByteWorks

So if you compile such a program specifically for the NC, you can expect it to run almost ten times faster. If you just rely on the SANE patch, it runs seven times faster.

Then I adapted an old Linpack benchmark (from the famous linear algebra package Linpack) for the IIGS and the NC and got these results:



The NC and NC-R give a more than three times better performance for the specifically compiled version, with the NC-R slightly ahead of the NC. kFLOPS stands for 1000 Floating Point Operations per Second. BTW, my iPhone Xs does about 12500 MFLOPS (not kFLOPS) on this test... :-)

Finally, I ran a benchmark with mixed tasks (sorting, integer and float operations etc.) where three out of seven tasks involved floating point calculations. A stock IIGS with 2.8 MHz clock frequency would reach 2.8 MHz on this benchmark, my TransWarp-accelerated IIGS reaches 11,21 MHz, and for the NC results have a look at the following diagram:



So for this benchmark a NC-R-equipped IIGS feels like a IIGS running at about 100 MHz. Your milage may vary.

You can download a ShrinkIt archive with all the benchmark programs and more from my download page (NCRStuffDF.SHK).

Tags: Apple IIGS, NumberCruncher

Zeichnungen in professionellen Veröffentlichungen wie Abschlussarbeiten, wissenschaftliche Artikel oder Skripten sollten hochauflösend und möglichst im Vektorformat sein. Viele Graphik-Programme wie CAD-Anwendungen o.ä. kopieren aber nur Bitmaps oder proprietäre Formate in die Zwischenablage. Über den Druckdialog von macOS kann man die Bilder aber in bester Qualität speichern. Diese PDFs sind dann allerdings immer ganze Seiten, so dass man sie nicht ohne einen großen Rand in ein Word-Dokument importieren kann.
Von Hand kann man ein PDF z.B. in Vorschau beschneiden, aber das ist mühselig. Ich habe darum ein Skript geschrieben, das diesen Rand entfernt und ganz einfach über das Kontext-Menü "Dienste" im Finder aufgerufen werden kann: PDFCropService.

Tags: PDF, Word, Pages, CAD, Graphik

Seit einiger Zeit ist die Standard-Einstellung bei der Erzeugung von NSTableViews mit Xcode für den Content Mode "View Based", nicht mehr "Cell Based". Cell-based Table Views sollen nicht mehr verwendet werden. Die Bindings von View-based Table Views sind aber etwas unübersichtlich. Damit ich das nicht immer vergesse, hier die Anleitung:

• Einen Array Controller in das XIB ziehen und bei den Attributen den Mode auf Entity Name stellen und den Entity Name eingeben. Dann bei den Bindings den Managed Object Context auf den von File's Owner setzen:

• Eine Spalte im Table View selektieren und dann den Value im Bindings Inspector auf das gewünschte Attribut der Arranged Objects des Array Controllers stellen (wenn man die Table View selbst an den Controller anbindet, klappt das Selektieren nicht mehr):

• Das NSTextField Table View Cell (nicht Table Cell View) auswählen und im Bindings Inspector das Value an objectValue.meinAttribut des Table Cell Views binden:

Das für alle Spalten durchführen, dann sollte es klappen. Hier im Beispiel heißt der Array Controller Messreihe Controller, meinAttribut ist temperatur.

Tags: Xcode, NSTableView, Core Data

LAPACK (Linear Algebra PACKage) ist eine Bibliothek zur Berechnung von linearen Gleichungssystemen. Sie ist in Fortran 90 geschrieben, hocheffizient, ausgereift und nutzt typische Eigenschaften und Fähigkeiten moderner Computer (Multi-Threading, Vektoreinheiten, Mehrprozessorsysteme). Auf dem Mac ist sie Teil des Betriebssystems OS X, sie fällt nur nicht so auf.
LAPACK ist Teil des Accelerate-Frameworks, das noch weitere Bibliotheken zur Daten- und Bildbearbeitung enthält, wie z.B. BLAS. Die Nutzung von LAPACK in eigenen Programmen ist einfach, wenn man erst einmal weiß, das sie schon da ist und wie sie eingebunden wird. Die LAPACK-Version, die in Mac OS X 10.8.4 (Mountain Lion) installiert ist, ist v3.2.1. Die aktuelle Version von LAPACK ist momentan 3.4.2. Wer also wirklich die neueste Version braucht, muss erst gfortran und BLAS installieren und damit LAPACK kompilieren und installieren. Das ist nicht so einfach, darum lassen wir das.
Um also LAPACK in einem C/C++/Objective C-Programm, dass in Xcode (v4.6.x) entwickelt wird, nutzen zu können, geht man folgendermaßen vor:

• Neues Projekt erstellen, hier als Beispiel C Command Line Tool:

• Accelerate-Header einfügen (dieser Header fasst alle Header der enthaltenen Bibliotheken zusammen):

• Accelerate-Framework einbinden (beim Target in der Build Phase "Link Binary With Libraries" mit dem "+" hinzufügen):

• Gewünschte LAPACK-Funktionen aufrufen. Dabei ist zu beachten, dass die LAPACK-Version von Mac OS X eine f2c-übersetzte Version ist und die Beispiele auf der LAPACK-Website zur Nutzung mit C nicht direkt funktionieren. Die Routinen sind anders benannt: Um z.B. die Fortran-Routine DGETRF aufzurufen, muss man nicht LAPACKE_dgetrf nutzen, sondern dgetrf_() . Die Deklarationen der Funktionen findet man im Header clapack.h, den man im Accelerate-Framework findet (Accelerate.framework/Frameworks/vecLib.framework/Headers):

Die LAPACK-Routinen enthalten Input- und Output-Parameter in der Parameterliste. Da in C nur By Value übergeben werden kann, müssen die Output-Parameter als Zeiger übergeben werden. In CLAPACK werden aber alle Parameter als Zeiger übergeben. Wie dem Header auch zu entnehmen ist, ist z.B. die Routine DGELS so definiert:

int dgels_(char *trans, __CLPK_integer *m, __CLPK_integer *n, __CLPK_integer *
nrhs, __CLPK_doublereal *a, __CLPK_integer *lda, __CLPK_doublereal *b, __CLPK_integer *ldb,
__CLPK_doublereal *work, __CLPK_integer *lwork, __CLPK_integer *info) __OSX_AVAILABLE_STARTING(__MAC_10_2,__IPHONE_4_0);

Das DGELS-Beispiel aus der Anleitung "The LAPACK C Interface to LAPACK", dort für LAPACK C Interface beschrieben, sieht dann für CLAPACK so aus:



Weitere Informationen zu LAPACK auf dem Mac und dem Accelerate-Framework findet man auch im Xcode-Organizer, wenn man dort nach "Accelerate" sucht.

Tags: Xcode, LAPACK, Accelerate

Mit einem Projekt, dass als Target Mac OS X 10.6 hat und den Default Compiler (Apple LLVM Compiler 3.1) nutzt, hatte ich mehrmals das Problem, dass beim Starten des Debuggers Xcode abstürzt. Gleiches Verhalten mit Xcode 4.3.2 und 4.3.3. Der Crash Report schlägt vor, Xcode neu aus dem App Store zu laden. Nutzt aber nichts. Auch ein Clean Build, Neustart des Rechners etc. nutzt nichts. Was aber hilft, ist, GCC_VERSION von Apple LLVM Compiler 3.1 auf LLVM GCC 4.2 umzuschalten und das Target neu zu kompilieren. Dann kann man mit diesem Code debuggen, aber auch wieder zurück umstellen, neu kompilieren und mit der gewünschten Default-Konfiguration weiterarbeiten.

Tags: Xcode, LLVM, Xcode 4.3