Neue PipeDream-Version veröffentlicht

2014-11-02 22:44

Gestern wurde PipeDream 4.52/06 veröffentlicht. Seit etwa zwei Jahren sind nun PipeDream und Fireworkz als kostenlose Downloads verfügbar, früher wurden sie als kommerzielle Software für nicht gerade kleines Geld von Colton Software verkauft.

In meinen RISC OS-Anfangszeiten habe ich mal PipeDream 3 gekauft, aus zwei Gründen – es war die einzige Software, die integriert Textverarbeitung und Tabellenkalkulation anbot, und es gab eine deutsche Version – besonders letzteres war damals extrem selten, und damals war das irgendwie wichtig für mich (ich hatte auch einen der ersten deutschen A3000, mit einem an sich ganz gut übersetzten Handbuch, wäre da nicht der Schnitzer mit dem Anschluss für die 32 persönlichen Kopfhörern gewesen). Für viele Jahre habe ich damit alle meine Korrespondenz erledigt sowie Arbeiten für Schule und Uni geschrieben.

Meines Erachtens ist das Konzept von PipeDream auch heute noch interessant, wie es die Textverarbeitung mit der Tabellenkalkulation verknüpft. Nicht immer ergonomisch, aber zweifellos innovativ. Der Schwerpunkt liegt aber definitiv auf den Spreadsheet-Funktionalität.

Ich habe nie ganz überrissen, was die Detailunterschiede zwischen Fireworkz und PipeDream sind – offenbar sind sie groß genug, um beide Pakete weiter zu pflegen. Vielleicht sollte ich mir beide Pakete doch noch einmal genauer anschauen.

Von Fireworkz gibt es auch eine Version für Windows.

Die RISC OS memcpy()-Challenge

2014-11-02 20:16

Jeffrey Lee hat im RISC OS Open-Forum zur memcpy()-Optimierung aufgerufen. Die bisherige Implementierung in der SharedCLibrary stammt aus 1991 und basiert auf Code von ARM Ltd. 1991 – das war zu Zeiten des ARM3, als die Caches noch klein, ausschließlich 1st level und Write-Through waren, man von 2nd level cache nur träumen konnte und sowas wie write buffering und write coalescing noch in weiter Ferne lagen.

Heute differieren die RISC OS-Plattformen deutlich stärker als damals. StrongARM, ARM11, XScale, Cortex-A8 und Cortex-A9 haben deutlich unterschiedliche Ansätze in punkto RAM-Anbindung. Es gibt gravierende Unterschiede bezüglich der Cache-Architektur, der Verfügbarkeit von Beschleunigern wie der XScale-DMA-Engine oder des NEON-Beschleunigers. Aligned- und Unaligned-Zugriffe haben unterschiedliche Performance-Charakteristiken, ebenso wie Zugriffe auf cached vs. uncached-Speicher. Dazu noch unterschiedliches Verhalten beim Überschreiten von Page-Grenzen.

Liebe Assembler-Frickler: das ist doch mal eine Challenge, wo die investierte Zeit gut angelegt ist. Die Speicherfunktionen in der SharedCLibrary würden bei signifikanten Verbesserungen für eine Beschleunigung von zig C-Anwendungen sorgen.

Zwei RISC OS-Legenden haben schon vorgelegt: Adrian Lees (Aemulor, Cino) und Ben Avison. Also, auf geht’s!

Tolle Tools – heute: Mauser

2014-10-24 17:38

Heute will ich von einem ebenso kleinen wie unverzichtbaren Modul berichten, das die Mausbedienbarkeit von RISC OS auf einen ganz neuen Level hebt.

Mauser heißt das kleine Modul, Jörn Schröder hat es vor Urzeiten (1996) programmiert (ich habe insofern etwas dazu beigetragen, als ich es zur 32bit-Fähigkeit gepatcht habe), und trotz seiner überschaubaren Größe von 6332 Bytes (davon rund 2 KB Hilfetexte) strotzt es nur so vor Funktionalität. Mein Favorit: per Drag der mittleren Maustaste innerhalb eines Fensters kann man scrollen. Und zwar in beide Richtungen. Das spart unglaublich viele Mauswege zu den Scrollbars und tröstet über die in RISC OS eher sparsame Unterstützung des Mausrades hinweg. Drückt man gleichzeitig die linke oder rechte Maustaste, kann man das ganze Fenster bewegen – äquivalent also zu einem Drag der Fenstertitelleiste, wieder spart man Mauswege. Die Unterscheidung linke Maustaste (Fenster kommt in den Vordergrund) und rechte Maustaste (Fenster verbleibt in seiner Tiefe) ist selbstverständlich ebenso implementiert.

Ebenfalls unverzichtbar ist die Implementierung des „langen Doppelclicks“. Damit kann man Applications öffnen statt ausführen und Dateien in den Texteditor laden statt sie auszuführen. Für diese Funktionalität gibt es zig andere Module, aber wenn es das sowieso unverzichtbare Modul schon bietet…

Zusammen mit der rechten Strg-Taste kann man weiteren Schabernack treiben: mit Keypad-7 kann man den Mauszeiger auf horizontale Bewegungen einschränken, mit Keypad-9 auf vertikale. Nützlich wenn man in Draw mal schnell was ohne Gridlock zusammenzeichnet. Mit Keypad-2/4/6/8 simuliert man Mausbewegung, mit Keypad-1/3/5 die drei Maustasten.

Alternativ zu Mauser gibt es auch MouseAxess von Christian Flöter. Es wurden schon Maustooldiskussionen geführt, die durchaus den „mein-Editor-ist-besser-als-deiner“ (ursprünglich als „vi vs Emacs“ bekannt, in der RISC OS-Welt eher „Zap vs StrongEd“) Diskussionen das Wasser reichen können. Unnötig zu sagen, dass Mauser das deutlich überlegene Tool ist (Gruß an Stefan B. :-)).

Hier gibt es Mauser in der 32bit-Version zum Download. Das 26bit-Original gibt es natürlich noch auf dem FTP-Server der Uni Stuttgart, dem großen Archiv aus der guten alten Acorn-Zeit, passend zur Ära als PackDir-Archiv.

Neue RPCEmu-Version veröffentlicht: 0.8.12

2014-10-22 23:50

Heute wurde von Peter und Matthew Howkins die RPCEmu-Version 0.8.12  veröffentlicht. Die Verbesserungen betreffen HostFS, den ARM-Emulationskern und die FDC-Emulation. Ein vollständiges Changelog steht zur Verfügung. Wahre Fans überwachen natürlich direkt das Mercurial-Repository.

Bei dieser Gelegenheit wurde der RPCEmu-Homepage auch gleich ein frischer Anstrich verpasst. Schlicht, aber elegant würde ich sagen. Das alte Design war doch sehr….zweckorientiert.

Die Vorgängerversion 0.8.11 wurde vor ziemlich genau einem Jahr veröffentlicht. Ich hoffe, dass sich die zukünftigen Release-Zyklen wieder etwas verkürzen – es gibt noch viel zu tun.

Tolle Tools – heute: AppDock II

2014-10-17 00:07

Über die Jahre – nein, Jahrzehnte! – der Nutzung von RISC OS habe ich mich an einige schicke Tools gewöhnt, die bei der Arbeit unverzichtbar sind. Wann immer ich einen neuen RISC OS-Rechner einrichte (früher passierte das alle paar Jahre mal, aber dank der neuen superpreiswerten Hardware und den ganzen Emulatoren ist es inzwischen eher so gefühlter Wochentakt), packe ich das Basis-Toolset drauf. In loser Reihe will ich diese Tools kurz vorstellen. Die meisten sind Freeware, es spricht also nix für sofortiges Ausprobieren.

Mein wichtigstes Arbeitspferd im Stall ist AppDock II von Martin Würthner. Es handelt sich dabei um einen „NeXT style application launcher“, auf Deutsch: eine Startbasis für Anwendungen ähnlich des „NeXTStep application docks“. Ich verwendete bereits den Vorgänger AppDock, der von Martin in grauer Vorzeit (ich denke es war noch RISC OS 2) als Freeware beigelegt wurde auf derselben Diskette wie HD_Backup 2, damals im Vertrieb von Klein Computer aus Rüsselsheim. Ja, liebe Kinder – damals haben noch mehrere Stücke Software auf eine einzige Diskette gepasst.

AppDock II beherbergt bei mir nicht nur die Anwendungen, die ich regelmäßig nutze, sondern auch die, die ich nur „booten“ will. Also Dinge wie !NewsDir, !GCC oder GhostScript. Man kann auch Verzeichnisse ins Dock packen, ein Doppelclick öffnet dann den Filer. Auch der Shift-Doppelclick auf Anwendungen funktioniert wie vom Filer gewohnt. Und es gibt eine Blätterfunktion, so dass man wirklich alle seine Anwendungen ins Dock integrieren kann – ein Feature, das bei erschreckend vielen Docks auf anderen Systemen fehlt.

AppDock II passt sich automatisch der verfügbaren Bildschirmhöhe an. Früher, zu Zeiten von RISC OS 3.1 oder des RiscPC in der Prä-ViewFinder-Ära, war das natürlich noch deutlich nützlicher – wer erinnert sich nicht an die Bildschirmmoduswechselorgien, um den richtigen Kompromiss aus Bildschirmgröße und Farbtiefe zu finden. Bei moderneren RISC OS-Systemen nutzt man im Allgemeinen das, was der Monitor an Auflösung hergibt und es reicht locker für TrueColour.

AppDock II bietet zusätzlich auch noch eine „ShortCut-Bar“ am oberen Bildschirmrand. Damit kann man Funktionen, der per Keyboard-ShortCut in Anwendungen verfügbar sind, per Mausclick auf der ShortCut-Bar ausführen. Die ShortCut-Bar stellt dabei immer die Funktionen dar der Anwendung, die gerade den Focus hat. Mit diesem Feature bin ich irgendwie nie warm geworden – bei häufig genutzten Anwendungen kenne ich die Keyboard-Shortcuts sowieso, bei selten genutzten navigiere ich übers Menü.

Es soll ja Leute geben, die das Pinboard als App-Launcher verwenden. Ist mir ein Rätsel, wie man damit arbeiten kann. Alles, was man braucht, ist doch ständig von irgendwelchen Fenstern verdeckt. Bei AppDock II drückt man einfach Alt+Shift+Ctrl, und schon kommt das Dock in den Vordergrund.

Erst Jahre später habe ich zum ersten Mal eine NeXTStation in Natura gesehen mit dem schicken großen NeXT-Graustufenmonitor. Und ich muss sagen, ich war vom NeXT-Application Dock etwas enttäuscht. Vermutlich alles eine Frage der Gewöhnung.

Auch auf anderen Betriebssystemen verwende ich äquivalente Anwendungsstarter – unter Windows aktuell RocketDock, in grauer Vorzeit unter Linux gerne die fvwm(2)- und AfterStep-Docks. Wie gesagt, unverzichtbar.

Wer sich über die merkwürdige Schreibweise von NeXTStep wundert – hier gibt es noch mehr Varianten zu bewundern. Dagegen erscheinen ja die Schreibweisen aus der Acorn-Welt wie RISC OS, RiscPC und IYONIX pc als Ausbund an Stabilität und Konsistenz.

Eine Neuauflage der RISC OS-Lizenzdiskussion

2014-09-22 00:32

Seit Castle Technology 2006 angekündigt hat, die Sourcen zu RISC OS soweit möglich freizugeben, gibt es die Diskussion über die Lizenz, unter der das geschehen sollte. Verschärft dann seit Mai 2007, als die ersten Sourcen tatsächlich das Licht der Öffentlichkeit erblickten und die Lizenz, unter der dies geschieht, publiziert wurde.

Eine Neuauflage dieser Diskussion läuft gerade im Forum von RISC OS Open.

Ein kluger Mensch würde sich aus dieser Diskussion wegen offensichtlicher Sinnlosigkeit heraushalten. Aber so klug war ich nie. Zu Anfang der Diskussion hatte ich noch die Hoffnung, dass der Threadstarter wenigstens ein Minimum an Lernfähigkeit zeigen würde. Denn wer, der sinnvolle zusammenhängende Sätze formulieren kann, wäre denn nicht lernfähig?

Falsch gedacht. Weder freundlich formulierte Nachfragen noch scharfe Erwiderungen scheinen irgendetwas zu bewirken. Frustrierend.

Was war der Ausgangspunkt? Der Threadstarter hat vorgeschlagen, per Crowdfunding einen Betrag X zu sammeln, um Castle die Rechte an RISC OS abzukaufen um dann RISC OS unter die GPL zu stellen (der Verlauf der Diskussion legt nahe, dass damit die GPLv3 gemeint ist).

Die erste Frage, die sich bezüglich dieser Idee stellt: was wäre der Vorteil davon, die Lizenz zu wechseln? Da gibt es durchaus einige:

  • die Castle Shared Source-Lizenz ist nicht kompatibel zu einigen anderen Open Source-Lizenzen, insbesondere natürlich nicht der GPL, d.h. eine Menge interessanter Code kann nicht ohne Weiteres für RISC OS verwendet werden
  • es existieren durchaus Entwickler, die nur dann an Projekten mitarbeiten, wenn die Lizenz gewissen Anforderungen genügt – mal muss es OSI-zertifiziert, mal ist es GPL
  • die Bedingungen für die kommerzielle Verwendung von RISC OS wären günstiger, d.h. es wären keine Zahlungen an Castle im Rahmen der OEM-Lizenz fällig
  • die Begrenzung auf ARM-CPUs wäre hinfällig

Das sind diskussionswürdige Vorteile, d.h. das Ansinnen sollte nicht direkt verworfen werden.

Was müsste praktisch getan werden, um eine solche Relizenzierung durchzuführen?

  • eine Summe Y müsste aufgebracht werden, um Castle die Lizenz abzukaufen – dabei sind die Regiekosten nicht zu vergessen, um z.B. entsprechende Anwälte fürs Vertragswerk zu bezahlen, die Managementzeit von Castle usw.
  • alle Copyright-Owner der jetzigen RISC OS-Codebase müssten kontaktiert werden, ob eine Relizenzierung möglich ist (und zu welchen ggf. finanziellen Bedingungen)
  • alle Module, die nicht unter die GPL gestellt werden können, müssten nachimplementiert werden

Und ich vermute, dass aus allen drei Gründen die Idee zum Scheitern verurteilt ist. Schon die Veröffentlichung der bisherigen Sourcen hat eine Menge Zeit und Aufwand in Anspruch genommen, und benötigt immer noch „binary blobs“ (z.B. MBufManager und ShareFS), die Aufgrund der „linking“-Klausel der GPL verhindern würden, dass ein RISC OS-Image unter der GPL veröffentlicht werden könnte. Es sei denn natürlich, man will auf jegliche Netzwerkfähigkeit verzichten.

Meiner Ansicht nach steht der Aufwand in keinem Verhältnis zum Gewinn. Geld, Zeit, Energie – all das wäre anderweitig in der RISC OS-Welt deutlich gewinnbringender eingesetzt. Und für GPL-Liebhaber gibt es genügend Möglichkeiten, sich einzubringen – Anwendungen, softloadable-Komponenten, Software fürs Disc-Image – es gibt endlose Möglichkeiten.

Ebenfalls zu beachten ist, dass diverse Entwickler auch Vorbehalte gegen die GPL haben (und insbesondere die GPLv3). Die Verwendung der GPL würde neue Probleme schaffen, was die Verwendung von Code unter anderen Lizenzen bedeutet.

Letztlich muss man auch einschätzen, wie groß die Probleme der derzeitigen Lizenz tatsächlich in der Praxis sind. Die ARM-CPU-Klausel? Wer zum Geier wöllte jemals RISC OS auf eine nicht-ARM-CPU portieren? Wer stört sich wirklich an der OEM-Klausel – ist diese im Sinne des jetzigen Zustands der RISC OS-Welt mit immer noch aktiver kommerzieller Szene wirklich ein Nachteil? Was verbessert sich für den gewöhnlichen Entwickler oder Nutzer (nach momentanem Wissensstand würde ich sagen: nichts)?

Vom technischen Standpunkt aus interessant wäre die Frage, wieviel GPL-Code man gewinnbringend für RISC OS einsetzen könnte. Wenn man aber sieht, wieviel BSD-Code man völlig problemlos (lizenztechnisch, nicht implementierungstechnisch!) bereits heute für RISC OS einsetzen könnte aber es wegen fehlender Entwicklerkapazität nicht tut, verliert auch dieses Argument erheblich an Gewicht.

Relevante Quellen zum selbst nachlesen:

Ausnahmsweise sind hier Kommentare zugelassen und erwünscht.

 

ISEE IGEPv5 – RISC OS-Hardware der Zukunft?

2014-09-19 01:34

Die bereits bekannten und abgehangenen neuen RISC OS-Plattformen wie BeagleBoard, PandaBoard und Raspberry Pi sind – gemessen an dem, was heutzutage etwa in Tablets verbaut wird – schon etwas schwach auf der Brust. Und mit durchaus unschönen Kompromissen behaftet: Ethernet nur über USB, Platten-I/O nur über USB oder eine nicht besonders performante SD-IO-Schnittstelle, schwachbrüstige Grafikeinheiten mit niedrigen Auflösungen und/oder Bildwiederholraten…

Die TI-OMAP-Plattform ist für RISC OS schon fast ein Heimspiel: sowohl BeagleBoard als auch PandaBoard verwenden SoCs aus der OMAP-Reihe. Und so wurde die Ankündigung der OMAP5-SoCs mit Interesse verfolgt.

Leider hat es bis 2014 gedauert, bis das erste interessante Board auf OMAP5-Basis verfügbar war. Die Rede ist vom IGEPv5 von ISEE. Und tatsächlich liest sich die Featureliste wie ein RISC OS-Wunschkonzert: Cortex-A15 mit 1.7 GHz, Gigabit Ethernet, USB3, SATA. Und nicht etwa ein unnützer Quad-Core, bei dem einen ständig das schlechte Gewissen plagt, RISC OS darauf laufen zu lassen, weil drei Cores nur Däumchen drehen. Sondern nur ein Dual-Core. Das schlechte Gewissen also gedrittelt.

Die Bemühungen, RISC OS auf das IGEPv5 zu bringen, laufen bereits.

Frischfleisch: rRAW von Anton Reiser

2014-09-13 15:40

Der Reisers Toni hat ein neues Stück Software in die freie Wildbahn entlassen: rRAW. Ganz frisch, noch beta – die üblichen Gesundheitswarnungen gelten also.

rRAW erlaubt das Lesen und Anzeigen von RAW-Dateien, wie sie die diversen DSLR-Kameras von Canon, Nikon, Sony und Konsorten erzeugen.

RISC OS 5 und ein Haufen RAM sind zur Nutzung empfehlenswert.

Für weitere Infos bitte das PDF-Handbuch konsultieren.

 

Raspberry Pi Ethernet endlich schnell

2014-09-10 22:11

Laut vertrauenswürdigen Berichten im RISC OS Open Forum hat Colin Granville, dem wir schon die Unterstützung für den isochronen Übertragungsmodus im RISC OS 5 USB-Stack und damit USB-Audio zu verdanken haben, endlich die wirklich harte Nuss geknackt. Bisherige Versionen von RISC OS auf dem Raspberry Pi hatten das Problem, dass der Upload über Ethernet plötzlich sehr langsam werden konnte. Mit den neuesten Änderungen von Colin ist dieses Problem nun Geschichte.

Im Moment gibt es offenbar noch ein Problem, sowohl schnelles Ethernet als auch Audiounterstützung gleichzeitig zu haben – USB-Scanner scheinen aufgrund eines Problems bei der Timeout-Steuerung in DeviceFS nicht mehr zu funktionieren. Riecht nach einer lustigen Runde Remote-Debugging.

CDFaker, das unbekannte Wesen

2014-09-08 02:43

Mein neuester Beitrag zur RISC OS-Software-Welt ist die 32bit-Version von CDFaker. Erschreckend – denn das war auch schon 2011…

CDFaker ist ein CDFS-Treiber (üblicherweise „softloadable CDFS driver“ genannt), der nicht wie üblich Hardware ansteuert, sondern vielmehr eine Image-Datei dem CDFS unterjubeln kann. Unix-gewohnte Menschen würden wahrscheinlich „mounten“ dazu sagen.

Das Werkzeug ist unverzichtbar für alle, die vor einem Brennvorgang sehen wollen, was CDFS mit einem ISO9660-Image so anstellt. Wer CDFS kennt, weiß, dass das nicht immer vorhersehbar ist. Vor allem das Casing von Dateinamen und die Verarbeitung von Filetypes ist immer wieder für Überraschungen gut.

In der schönen neuen RISC OS-Welt, wo kompatible optische Laufwerke Mangelware sind, hat CDFaker nun eine neue Anwendung gefunden: zum Installieren von CD-basierter Software ohne CD-Laufwerk am RISC OS-Rechner. Einfach auf einem PC das Image extrahieren, irgendwo auf ein Netzlaufwerk legen, und per CDFaker „mounten“.

CDFaker (manchmal auch FakeCD genannt) wurde ursprünglich von Andy Armstrong (Wonderworks) entwickelt. Ich habe nur ein wenig daran rumgefrickelt, um die 32bit-Fähigkeit herzustellen. Und: auch wenn CDROMFS aktiv ist – welches bekanntlich ein Image-Filing-System für Dateien mit Filetyp DF6 registriert – kann CDFaker nun das Image korrekt verarbeiten.

Weitere Infos auf meiner CDFaker-Seite.