Hubersn

Frohes Fest, guten Rutsch, auf ein Neues in 2018

2017-12-26 16:22

Zunächst: allen treuen Lesern dieses Blogs wünsche ich ein Frohes Fest und einen guten Start in 2018 – ich bedanke mich für die entgegengebrachte Aufmerksamkeit und das viele Lob.

2017 empfand ich RISC OS-technisch als eher durchwachsen. An der Hardwarefront wurden ARMX6 und Titanium durch verbesserte OS-Versionen verfeinert, der RPi 3 und damit ARMv8 etablierte sich und zog den üblichen Versionswahnsinn nach sich, weil ARM ja mal wieder etwas sparsam bei der Rückwärtskompatibilität war.

RISC OS selbst war auch eher sanften Verbesserungen unterworfen. Hauptpunkt vermutlich die EDID-Unterstützung, die aber immer noch teils überraschende Effekte zeitigt. RC15 für die Pis war sicher ein Meilenstein, für Newcomer und Zurückkommer ist es nun wieder deutlich unkomplizierter, einen RPi unter RISC OS ans Fliegen zu kriegen. Nachdem Filecore nun mit 4KiB-Sektoren umgehen kann, ist nun auch der Betrieb von 2 TiB-Platten möglich – wir warten aber weiterhin auf eine Version von HForm, die das auch formatieren kann, und natürlich auf die Möglichkeit vernünftig Partitionen unter ADFS und SCSIFS zu verwalten. Fortschritt gab es an der Dokumentationsfront, das “User Manual” hat große Fortschritte zu verzeichnen, und das BBC BASIC-Referenzhandbuch gibt es in einer überarbeiteten Neuauflage. Auf echtem Papier. So richtig gedruckt.

Es gab ein neues DDE-Release, Nummer 28. Auch hier eher Evolution als Revolution. Bei einem Toolset, dass das Betriebssystem baut, keine schlechte Strategie.

Ansonsten war es softwaretechnisch m.E. eher verhalten. Die Webkit-basierten Browser erfuhren einige Verbesserungen, und es gab mit dem OBrowser den Versuch, die RISC OS-Integration dieser Browser mit einfachen Mitteln zu verbessern.

Adrian Lees hat Aemulor kostenlos freigegeben in der Version 2.40, die nun auch ARMv8-Unterstützung hat und auf aktuellen RISC OS-Builds in High-Vector-Konfiguration läuft – meine diversen Versuche auf Pi3 und Ti zeigten aber noch einige Ecken und Kanten. Demnächst mehr dazu auf diesem Blog.

Eines der wenigen Tools, die seit Jahren stetig weiterentwickelt werden, ist ADFFS – Jon Abbott ist hier unermüdlich dabei. Was anfangs ein simpler ADFS-Emulator war um auf den alten Archies mit Floppy-Disc-Images arbeiten zu können, ist inzwischen ein kompletter High-Performance-Emulator, um die Spiele der 80er auf allen RISC OS-Maschinen bis zum neuesten ARMv8-Pi 3 wiederaufleben zu lassen. Nebenbei hat Jon auch gleich das Geheimnis des IDE-ADFS-Problems gelöst, warum die alten Kisten z.B. mit CF-IDE-Adaptern oft nicht richtig zusammenarbeiten können.

Auch Fred Graute mit StrongEd ist emsig an der Weiterentwicklung und reagiert sehr schnell auf etwaige Bugs. Kompliment von mir.

Aus deutschsprachigen Landen sind Thomas Milius mit seiner SmartHome-Steuersoftware zu nennen und Anton Reiser, dessen neueste Schöpfung ein Utility zur Behandlung von Photoshop-Dateien ist. Auch Martin Würthner hat nach fünfjähriger Kunstpause mit Artworks 2.X3 endlich wieder ein neues Upgrade am Start.

Was kommt 2018? Endlich das neue Release von CDVDBurn. Versprochen. Und ich hoffe auf Fortschritte bei der Emulator-Front – RPCEmu auf Qt-Basis und damit eventuell auch eine RISC OS-Version davon, die Archimedes-Emulation in MAME, Fortschritte bei ArchiEmu, Aemulor-Verbesserungen, und die vage Hoffnung auf eine Fortentwicklung des Archimedes-Core in MIST und MISTer.

ADFFS 2.63 verfügbar

2017-12-19 12:23

Jon Abbott vom JASPP hat die Verfügbarkeit von ADFFS 2.63 verkündet. Es gab viele Verbesserungen und Bugfixes, insbesondere für ARM7-basierte Systeme (Risc PC mit ARM710, A7000(+)) und für den IYONIX, der jetzt auf Augenhöhe mit dem Pi bezüglich der Spielekompatibilität sein sollte – wichtig ist hier, ein entsprechendes MDF am Start zu haben mit den für Spiele typischerweise notwendigen Auflösungen. Nebst einem Monitor, der diese auch verarbeiten kann.

Unter den Spielen, die nun unter ADFFS funktionieren, ist sicher Heroes of Might and Magic 2 am bekanntesten.

Außerdem wurden diverse Spiele von Alpine Software im Rahmen des JASPP freigegeben. Dabei handelt es sich um klassische Grafik-/Text-Adventures, neudeutsch “Interactive Fiction”, die noch den Geist der 80er atmen. Und tatsächlich teilweise aus den späten 80ern stammen. Cool: mit ALPS wurde auch das Authoring-System freigegeben, mit dem der geneigte User selbst solche Adventures kreieren kann.

Hier kann man ADFFS 2.63 runterladen.

Titanium-Komplettsystem bei a4com

2017-12-02 18:30

Auf der Suche nach einem Titanium-System (meine Lust auf Eigenbau hielt sich in Grenzen) bin ich mir mit Detlef Thielsch von a4com handelseinig geworden. Im Gegensatz zu den Vorgängerprodukten BIK (BeagleBoard-in-Kiste – in England von R-Comp als “ARMini” verkauft), PIK (PandaBoard-in-Kiste – in England von R-Comp als “ARMiniX” verkauft) und WBK (Wandboard-in-Kiste – in England von R-Comp als “ARMX6” verkauft) sind beim Titanium aufgrund dessen Standard-Konformität – das Board ist kompatibel mit ATX-Gehäusen und ATX-Netzteilen, USB-Ports stehen sowohl intern als auch extern reichlich zur Verfügung, mit 4 S-ATA-Ports kann man problemlos SSD und optisches Laufwerk integrieren ohne auf USB-SATA-Adapter zurückgreifen zu müssen – keine größeren Handstände notwendig.

Folgerichtig bietet a4com nun das “TIK” an, “Titanium-in-Kiste”. Die Preise ab 900 EUR sind geradezu ein Schnäppchen, bei R-Comp zahlt man für die “TiMachine” denselben Betrag in Britischen Pfund, bei fragwürdigem Mehrwert (zum von R-Comp so gelobten tollen Softwarebundle werde ich zu gegebener Zeit ein paar Worte schreiben). Bei CJE sieht es beim RapidO Ti nicht besser aus. Also: das a4com-Angebot ist absolut konkurrenzfähig und empfehlenswert.

So weit, so schön. Für wen ist nun ein Titanium-System erste Wahl? Für alle, die nicht zwingend auf höchste Bildschirmauflösungen angewiesen sind (“dank” des verwendeten TI OMAP5 sind ohne einen Monitor, der die beiden Videoausgänge des Titanium “side by side” anzeigt, maximal 1920×1200@60Hz drin – in Zeiten von bezahlbaren QHD- und 4K-Monitoren definitiv zuwenig) und den anspruchsvollen Preis nicht scheuen. Denn sowohl was CPU-Leistung (der Cortex-A15 ist nicht nur aufgrund der 1,5GHz-Taktung konkurrenzlos, sondern auch bei der Leistung pro Takt mit 3,4 DMIPS/MHz den Cortex-A9-Konkurrenten i.MX6 (Wandboard, ARMX6) und OMAP4 (Pandaboard, ARMiniX) mit lediglich 2,5 DMIPS/MHz weit überlegen – übrigens nicht nur in der Theorie, auch Benchmarks untermauern das) als auch I/O-Leistung (4 S-ATA-Ports, echtes Gigabit-Ethernet – Benchmarks folgen noch) angeht ist ein Titanium-System weit vorne. Für Budget-Fetischisten würde ich eher einen Pi3 empfehlen – 4K-Video, verhältnismäßig schnelle CPU (jedenfalls deutlich vor der Cortex-A9-bestückten Hochpreiskonkurrenz), nur bei der I/O-Leistung (Netzwerk 100MBit/s und über USB2.0, Massenspeicher über SD oder USB2.0) fällt er natürlich deutlich ab – you get what you pay for.

Praxisberichte mit Titanium vs. ARMX6 folgen hoffentlich demnächst.

Das Titanium-Board und die Suche nach dem passenden Netzteil

2017-12-02 00:21

Der IYONIX pc war bekanntlich das erste RISC OS-taugliche Mainboard, das mit Standard-ATX-Netzteilen zusammenarbeitete. Auf dem langen Weg vom ersten Archimedes (vermutlich war die Parallelschnittstelle die einzige “standardkonforme” Schnittstelle – die serielle war RS423 statt RS232, der Monitorausgang war 9polig aber immerhin signaltechnisch weitgehend “PC-kompatibel”, der Floppyanschluss war zwar Shugart-kompatibel aber eher wählerisch) über den A5000 (IDE, Parallel, Seriell, VGA, Floppy – alles weitestgehend kompatibel zum damaligen PC-Standard, aber immer noch die merkwürdige Acorn-Tastatur mit dem integrierten Busmaus-Anschluss) bis zum A7000 (endlich PS/2 sowohl für Maus und Tastatur) war man immer näher an die Welt der Standardkomponenten und -schnittstellen gerückt. Nur Gehäuse und Netzteil blieben bis zuletzt proprietär.

Mit dem IYONIX pc fielen auch diese beiden Bastionen – die Platine im ATX-Format, und das Netzteil dazu passend. Allerdings stellte sich bald heraus, dass der IYONIX eine echte Mimose war wenn es um die Zusammenarbeit mit der PC-Netzteil-Welt ging. Das Problem: er brauchte zu wenig Strom, vor allem auf dem 12V-Zweig. Und so war es eine gute Idee, das Gehäuse mit Platten und Brennern vollzustopfen, was dann die häufigeren Problemchen beim Kaltstart weitestgehend eliminierte.

Das Titanium-Board von Elesar ist in gewisser Hinsicht der natürliche Nachfolger des IYONIX. Nicht nur, weil das Hauptdesign von derselben Person stammt. Sondern auch weil das Board eben in gewöhnliche ATX-Gehäuse passt und mit ATX-Netzteilen zusammenspielen soll. Soll. Denn ganz so einfach ist es auch diesmal nicht. Die Basisanforderungen scheinen noch einfach zu erfüllen zu sein: ATX 2.3 oder neuer muss es sein, und der Mainboard-Connector ist der ältere 20Pin-Typ, so dass nur Netzteile mit der 20+4-Konfiguration in Frage kommen. 4 S-ATA-Stromstecker wären auch gut, denn das Board unterstützt bekanntlich (und das ist ein echtes Alleinstellungsmerkmal) 4 S-ATA-Geräte. Aber wie immer steckt der Teufel im Detail.

Inzwischen ist die PC-Welt ja bezüglich des Leistungsbedarfs eines Rechners weit enteilt. Unter 400W kann man ja fast nur riskieren, wenn man mit Chipsatz-Grafik auskommt und nicht allzu viele Laufwerke betreiben will. Beim Titanium wäre ein 200W-Netzteil eher angebracht. Und Schaltnetzteile brauchen nun mal in den meisten Konstruktionen eine gewisse Mindestlast, um sicher anzuspringen und stabile Spannungen zu liefern. Ironischerweise gab es zuletzt ein Update an der PC-Front, damit die Netzteile auch die extrem stromsparenden C6/C7-“Deep Power Down”-Modi der Intel-Prozessorgeneration ab Haswell funktionieren.

Drei Netzteile habe ich mit dem Titanium-Board zusammen getestet: ein No-Name-550W-Netzteil, ein be quiet! Pure Power 10 300W und ein be quiet! Straight Power 10 400W. Ergebnis: nur das Straight Power 10 funktioniert ohne Macken und Zucken mit der von mir definierten Minimallast “Titanium-Board und SSD”, die anderen Kandidaten brauchten nicht weniger als 3 Brenner, bis der Startup absolut zuverlässig funktionierte. Ob das mit dem laut Datenblatt “Zero Load Design” zu tun hat, weiß ich nicht – eine Gegenprobe mit dem preiswerteren System Power 8 wäre interessant, das Pure Power 10 hat dieses Feature nicht.

Das Straight Power 10 ist auch sonst eine absolute Empfehlung. Der 135mm-Lüfter ist nahezu unhörbar, es hat absolut ausreichend Anschlüsse für S-ATA-Geräte sowie althergebrachte Molex- und Berg-Stecker (auch in S-ATA-Zeiten oft noch nützlich für Zusatzgeräte wie interne USB-Hubs oder Cardreader). Bisher bin ich so zufrieden, dass das Straight Power wohl auch den Weg in meinen nächsten Selbstbau-PC finden wird. Die fünf Jahre Herstellergarantie sind ebenfalls vertrauenserweckend.

Aemulor 2.40 ist da

2017-11-15 00:28

Adrian Lees hat sein Versprechen wahr gemacht und hat aktuelle Entwicklungsversionen von Aemulor für alle relevanten Plattformen veröffentlicht. Hier gehts zu den Downloads. Zum ersten Mal ist auch der Pi3 (Cortex-A53, ARMv8) unter den unterstützten Plattformen. Ebenfalls sollte diese Aemulor-Version nun mit den neueren RISC OS-Versionen zurecht kommen – Stichwort Zero Page Protection und High Vectors.

Alle Plattformen, für die es jemals Aemulor gab? Nein, die Formulierung “alle relevanten Plattformen” war mit Bedacht gewählt. Denn der A9home ist nicht darunter…arme kleine blaue Kiste.

 

20 Jahre CD(VD)Burn

2017-11-01 22:46

Man schrieb den 31.Oktober 1997. In London fand die Acorn World statt, und CDBurn wurde dort im Vertrieb von WSS (Warm Silence Software) zum ersten Mal öffentlich vorgestellt.

Man erinnere sich zurück: es war die letzte Acorn World, der Risc PC war noch “state of the art” und hatte gerade durch den StrongARM eine Frischzellenkur erhalten. CD-Brenner waren teuer und nur als SCSI-Geräte erhältlich. CD-R-Medien kosteten mindestens 10 DM, oft auch 15 DM. 74min/650MiB waren die maximal erhältliche Kapazität. Fast unendliche Weiten in Zeiten, wo die Festplatten noch im deutlich einstelligen GB-Bereich unterwegs waren, vor allem in der Geschmacksrichtung SCSI waren 2 GB schon fast High-End. Ironischerweise wurde die Software selbst noch auf Floppy Disc verkauft. DD 800 KiB wohlgemerkt.

Der einzige unterstützte Brenner war der Philips CDD2000, die Variante CDD2600 folge kurz darauf. Ich hatte damals das Glück, dass ich einen Brenner gekauft hatte, der eine öffentlich zugängliche Doku zum Command Set hatte – die Konkurrenz von Teac, Sony und Yamaha war da wesentlich verschlossener, man musste tatsächlich NDAs nach USA faxen, und die Antwort brauchte teilweise Monate. Von Teac habe ich bis heute nix gehört.

Die erste CDBurn-Version war “gerade so” fertig geworden (und meine Entscheidung, die Software in Ada zu schreiben, ist im Rückblick auch nur durch eine Mischung aus Optimismus und Wahnsinn zu erklären) – die Audio-CD-Funktionalität war schon recht ausgereift, aber bei den Daten-CDs haperte es noch gewaltig. Es gab noch keine Möglichkeit, ein ISO-Image zu erzeugen, ehrlicherweise war es deshalb auch die Versionsnummer 0.99 – deshalb wurde ein quick’n’dirty port von mkisofs beigelegt, um zumindest nominell dieses Feature abhaken zu können. Auf der Acorn World sprach ich mit vielen potenziellen Käufern und versprach baldige Lieferung des ISO9660-Formatters – ein Versprechen, das viele vom Kauf überzeugte und das ich Gott sei Dank noch im selben Jahr mit dem Release 1.00 (ein kostenloses Update) halten konnte.

Einzige Konkurrenz damals war CDScribe von Eesox – die verkauften aber die Software nur im Bundle mit dem Laufwerk, und dieses auch noch gut doppelt so teuer wie das Laufwerk alleine kostete. Audiotechnisch war die Software auch stark unterbelichtet, und der beigelegte ISO9660-Formatter war auch nicht der Weisheit letzter Schluss. Vermutlich deshalb eroberte CDBurn den Markt im Sturm, obwohl gemessen an der PC-Konkurrenz doch eher featurearm und nicht billig.

Über die Jahre wurde featuretechnisch kräftig aufgerüstet, die Updates blieben kostenlos: Multisession-Unterstützung, Joliet-Unterstützung und konfigurierbares Namemapping für ISO9660, CD-RW-Unterstützung, Unterstützung aller MMC-kompatibler Laufwerke, IDE-Unterstützung für Risc PC/A7000, APDL/Microdigital und Simtec/RiscStation, Upgrader um endlich neue Versionen per Download anbieten zu können, und schließlich 32bit-Kompatibilität und Unterstützung für den IYONIX pc. Abfallprodukt der IYONIX-Kompatibilität war die abgespeckte Version CDBurn Lite, die jedem Castle IYONIX pc beilag.

Besonders die 32bit-Kompatibilität halte ich bis heute für ein Wunder, das nur durch Dummenglück erklärbar ist. Klar, es hilft auch, wenn man einen Martin Würthner kennt, der mal kurzerhand eine GNAT-Runtime patchen kann. Aber dass das ARM-Backend des GCC 2.7.2.1 tatsächlich ARMv8-kompatiblen Code erzeugen kann, ist auch als so ein Wunder zu bewerten.

2004 gründete ich dann hubersn Software, um den Vertrieb in die eigene Hand zu nehmen. Es folgte die Integration der DVD-Unterstützung für die neue Generation DVD-Brenner, was die Umbenennung in CDVDBurn nach sich zog, um schon namentlich klar zu machen, dass nun sowohl CDs als auch DVDs gebrannt werden konnten.

Und damit endet die Geschichte der offiziellen Releases – bis heute sind die Ergebnisse der weiteren Entwicklung nicht in einem neuen Release gemündet, sondern werden nur an Interessierte als Beta-Testversionen verteilt. Dazu gehört die DVD-RAM-Unterstützung, die USB-Unterstützung für RISC OS 5, die Blu-Ray-Unterstützung, der CD/DVD/Blu-Ray-Extraktor, die ARMv7-/ARMv8-Kompatibilität für die neue Hardware-Generation vom BeagleBoard bis zum Raspberry Pi 3, die Unterstützung für das neue S-ATA-taugliche ADFS im Titanium.

Der letzte Plan war, all diese Erweiterungen in einem “20th anniversary release” zu bündeln, aber es fehlte etwas Zeit, um die Sache abzurunden: BD-R und BD-RE in der Dual-Layer und XL-Variante ist noch nicht unterstützt, DVD-R kann nach wie vor nicht geschrieben werden, und an der Kompatibilität mit den modernen (sprich: noch im Handel verfügbaren) Laufwerken hapert es auch noch. Ziel wäre, ein USB-Laufwerk und ein S-ATA-Laufwerk zu finden, mit dem problemlos CD-R/CD-RW/DVD+R/DVD+RW/DVD-RAM/BD-R/BD-RE geschrieben werden können.

Sollte es doch dieses Jahr noch ein Release geben – Arbeitstitel “CDVDBurn 3” – Leser dieses Blogs erfahren es als erste.

RPCEmu demnächst Qt-basiert

2017-10-21 15:21

Über die RPCEmu-Mailingliste kam heute die Bitte von Peter Howkins, sich am Test von RPCEmu 0.8.99 zu beteiligen.

Was ist neu in dieser Version von RPCEmu? Endlich wurde die unselige Allegro-Bibliothek über Bord geworfen, stattdessen wird jetzt Qt5 verwendet. Was gleichzeitig dazu führt, dass das UI (Menüs, Einstellungen) jetzt unter Windows, Mac und Linux vollwertig ist und nur einmal gepflegt werden muss.

Das Screenmode-Handling wurde im Fullscreen-Modus dahingehend geändert, dass nun auf die native Auflösung skaliert wird und nicht mehr der Bildschirmmodus selbst verändert wird, was bekanntlich unter nicht-RISC OS-Betriebssystemen erstaunlich oft zu Problemen führt – in meinem Fall hat Windows regelmäßig fälschlicherweise nach Rückkehr aus dem Fullscreen-Modus gemeldet, ich würde nicht die native Auflösung des Displays verwenden und solle das doch bitte ändern.

Gleichzeitig wurde auf das Qt-Threadingmodell umgestellt, so dass nun die Emulation sauber im Hintergrund weiterläuft, während man die Menüs öffnet oder Einstellungen anpasst. Auch gefreut hat mich der neue Warndialog, der einen auf den bevorstehenden Reset hinweist wenn man die Einstellungen ändert.

Ein paar Bugfixes bei der ARM-Emulation sind auch eingeflossen.

Ironischerweise hilft die Umstellung von Allegro auf Qt5 auch für eine RISC OS-Portierung – Chris Gransden, Meister der tausend Portierungen, hat direkt die Maschinerie angeworfen und eine mehr oder weniger lauffähige “RISC OS 5 on RISC OS 5”-Emulation vermeldet. Performancetechnisch sparsam (angezeigte 18 MIPS auf einem Titanium, also etwa ARM3-Speed – kein Wunder, enthält RPCEmu doch nur einen x86/x64-JIT und muss bei ARM-on-ARM rein interpretierend arbeiten), mit einigen Nicklichkeiten wie nicht funktionierender Tastatureingabe, aber ansonsten funktionsfähig.

Update

Chris Gransden hat einen Teaser-Screenshot veröffentlicht, RISC OS 4 in RPCEmu auf RISC OS 5-Titanium.

Zero Page und RISC OS 5 – Update

2017-08-29 00:27

Wer sich nicht mehr erinnert – seit Juli 2015 haben alle RISC OS 5-Development-Builds die Zero-Page verschoben und laufen in der sogenannten “high processor vectors”-Konfiguration. Das ermöglicht einen deutlich stabileren OS-Betrieb, führt aber dazu, dass so manche Software, die bisher einwandfrei lief, aufgrund von (vermutlich) unkritischen NullPointer-Zugriffen den Abgang macht. Auch zu Diagnosezwecken, aber auch zur Wahrung der Rückwärtskompatibilität wurde deshalb das ZeroPain-Modul erfunden, das Zugriffe auf die Zero Page loggt. So mancher Uralt-Bug wurde dadurch erfolgreich ausgemerzt.

Ursprünglich war angedacht, ab 1.1.2016 ZeroPain wieder abzuschaffen. Das war wohl viel zu optimistisch, und es gab meines Wissens erheblichen Widerstand von R-Comp und CJE, die bekanntlich fertige RISC OS-Rechner inklusive eigens getesteter RISC OS 5-Versionen für die weniger bastelfreudigen User verkaufen. Letztlich das alte RISC OS-Problem: zuwenige Entwickler, die sich um die Pflege der Software kümmern können, dazu einige Software ohne verfügbaren Quellcode.

Jetzt gibt es eine neue Marschrichtung: einen Kompatibilitätsmodus, “compatibility page” genannt. Per OS_Memory 20 auch softwaremäßig kontrollierbar. Ich denke, das ist ein guter Kompromiss – es ermöglicht allen Parteien, zu einem gemeinsamen ROM-Build zurückzukehren und je nach Zielgruppe zwischen maximaler Rückwärtskompatibilität oder gescheiter Entwicklerunterstützung einfach umschalten zu können. Software, die zu Emulationszwecken die Zero Page selbst simulieren will (ADFFS ist da ein Kandidat, siehe Post zur Verfügbarkeit von Version 2.62), kann ebenfalls entsprechend agieren. ZeroPain ist für Entwickler und Benutzer, die Entwickler unterstützen wollen, weiterhin verfügbar.

Zap und ARMv8

2017-08-29 00:24

Während StrongEd von Fred Graute kontinuierlich weiterentwickelt und ständig an neue CPU- und OS-Erfordernisse angepasst wird, liegt Zap maintenancemäßig seit längerer Zeit brach. Tank hat initial die 32bit/ARMv7-Version gebaut und ein paar aufgetauchte Bugs gefixed, dann hat André Timmermans Bugfixes beigesteuert, und nun hat Rick Murray ein paar ARMv8-Showstopper bereinigt (siehe dieser Thread im ROOL-Forum).

Im August letzten Jahres hat Ex-Zap-Mitentwickler James Aylett das Zap-CVS nach Git konvertiert und auf GitHub zur Verfügung gestellt. Ein “offizieller” neuer Maintainer hat sich leider noch nicht gefunden – es bleibt zu hoffen, dass die Zap-Interessierten das irgendwie koordiniert kriegen und sich nicht gegenseitig mit lokalen Änderungen und insonsistenten Patches und Versionen ins Knie schießen.

Als überzeugter StrongEd-Benutzer greife ich trotzdem ab und zu auf Zap zurück, wenn ich nicht gerade Ada programmiere, es wäre schlicht eine Schande wenn ein solch feines Stück Code nicht mehr in einer aktuellen und gepflegten Version zur Verfügung stünde.

Leider hat sich auch noch keiner gefunden, der den Zap-Ada-Mode nach 32bit konvertiert…leider bin ich kein routinierter Assembler-Programmierer, wird vielleicht Zeit die alten Kenntnisse wieder aufzufrischen.

Neue VNC Server-Version

2017-08-29 00:22

Der einzige verfügbare VNC-Server unter RISC OS, derzeit bei Tausendsassa Jeffrey Lee in der Pflege, hat ein Update erfahren. Zwei signifikante Bugs wurden gefixed: er funktioniert nun auch, wenn der Bildschirmspeicher auf non-packed-scanlines basiert (existiert so derzeit nur auf dem Pi, für Details siehe hier). Und es wurde ein Bug beim Clipboard-Handling im RAM transmit protocol gefixed, der im Zusammenspiel mit StrongEd aufgefallen war.

Ich selbst benutze den VNC-Server auf meinem ARMX6, um bequem vom Laptop im Wohnzimmer auf RISC OS zugreifen zu können. Funktioniert immer besser über die Jahre – die ersten Versionen von VNC Server waren nahezu unbrauchbar, vor allem bei großen Farbtiefen und Auflösungen. Inzwischen funktioniert das leidlich gut.