Posts by Mike

    Du hast nicht zufällig einen gefunden, den man auf Slave jumpern kann?

    Ich muß zugeben, da habe ich nicht speziell drauf geachtet. Priorität war eben, die Kiste wieder ans Laufen zu bringen und da war als CF-Karte alles in der Richtung >=120 MB und eben <=512 MB (+/-) recht.


    Aufgefallen ist mir nur, daß dieser Adapter und viele andere die da so rumfleuchen auf der zweiten Seite ebenfalls Lötpads zur Aufnahme eines "CF-Sockels" aufweisen, so daß es auch Adapter geben sollte, die direkt einen Verbund aus Master- und Slave-"IDE"-Laufwerk mit zwei CF-Karten ermöglichen.

    Als Nachtrag hier noch ein Blick in meinen A5000, der zeigt, wie der "kritische" Teil der Hauptplatine mit drumherum dort jetzt aussieht:



    Auch bei mir war letztes Jahr der Austausch des Akkus fällig. Ich hatte aber Glück, denn im wesentlichen war nur die Zelle an den Seiten ausgeblüht. Zur Vorsicht war trotzdem der RTC-Chip mal kurz von der Platine runter um anoxidierte Lötstellen in der Nähe besser reinigen zu können.


    Kurz nach der erfolgreichen Wiederinbetriebnahme verabschiedete sich allerdings dann noch die originale Festplatte, eine 120 MB Quantum Prodrive ELS: die blieb auch früher immer schon mal beim Hochfahren 'hängen' und brauchte dann einen zweiten Reset um endlich hochzutouren. Nach der obigen Reparatur war es dann aber nach ein paar Stunden Testbetrieb endgültig vorbei und sie tourte definitiv nicht mehr hoch. Zum Glück gab es ein rückspielfähiges Backup mit Stand Anfang 2005 als der Rechner eingemottet wurde.


    Eine 'neue' Harddisk einzubauen war so ziemlich ein Ding der Unmöglichkeit (wirklich neu zu kriegen ging ohnehin nicht, maximal unterstützte Kapazität durch Filecore/ADFS: 512 MB) - nächste Idee also wie oben zu sehen: CF-Karte mit IDE-CF-Adapter.


    Allerdings ist die oben gezeigte swissbit-CF-Karte wieder draußen. Die hält sich nämlich nicht 100% an den ursprünglichen IDE-Standard und läßt sich bei einigen Operationen zuviel Zeit, was das Dateisystem mit Fehlern quittiert. Stattdessen steckt jetzt eine SanDisk-CF-Karte (auch mit 512 MB) drin, und die tut's einwandfrei. :)

    hast du auch das (Standard?) graue Hintergrundbild wo mittig nur (auch in grau) nur ein 3-dimensionaler Eichel (Acorn) abgebildet war? Das suche ich nämlich krampfhaft für mein Raspberry Pi 2 Risc-OS.

    Genau dieses Hintergrundbild habe ich so echt nicht in Erinnerung und ich hatte auf den !Arche-Club-Treffen schon einige Rechner 'zwischengehabt'.


    "Standard" auf dem A5000 war zunächst mal überhaupt kein Hintergrundbild, nur mittelgrau. Einrichten des Hintergrundbildes und Ändern der Fenster-Icons ging aber schon ab Werk. Üblich beim RiscPC war denn auch ein marmoriertes Hintergrundbild. Ansonsten haben sich die Leutz' da schon ausgetobt und den Desktop nach eigenem Gusto eingerichtet. :)


    Ich hab' aber noch mal gebuddelt, und bin insofern fündig geworden, daß ich eine Anwendung gefunden habe, die einem bestehenden Hintergrund ein Acorn-Logo mit 3D-Schattenwurf überlagert. Das sieht dann so aus (Emulator-Screenshot):



    Ich habe es mal angehängt. Beim Entpacken soll eine leere Datei mit einem 'harten' Leerzeichen als Name (Alt+Space) und mit Dateityp &AAA extrahiert werden, was SparkFS (zumindest bei mir) mit einem Fehler quittiert. Wenn der Fehler auch bei dir auftritt, überspringst Du am einfachsten den Fehler und erstellst die Datei im Anwendungsverzeichnis von !AcornLogo selber neu (mit Namen und Typ wie angegeben).


    Viele Grüße,


    Michael


    P.S. wahrscheinlich liegt der Fehler am HostFS des Emulators. Muß mal schauen was passiert wenn ich das Archiv auf den A5000 herüberziehe und da entpacke.

    Files

    • AcornLogo.zip

      (5.74 kB, downloaded 4 times, last: )

    Die Horror-Story oben gerade zum Anlaß genommen, den eigenen A5000 mal wieder hochzufahren um den Akku zu laden und die Uhr auf Sommerzeit umzustellen. Mit Beweisbild:



    ayvazhzf: Ich drück' dir ganz dick die Daumen, daß Du deinen A5000 wieder ans Laufen kriegst.

    Das Dingen funktioniert leidlich gut mit BASIC-Programmen (biegt PEEK/POKE-Zugriffe auf den Bildschirmspeicher/Farb-RAM, den VIC und die Joystick-Register im VIA) geeignet ab, bis hin zu umdefinierten Zeichen. Der Bildschirmeditor selbst wird nur unvollständig nachgebildet (funktioniert bei Programmausgaben, beim LISTen, etc. nur eingeschränkt).


    Multicolor funktioniert nicht so gut, da die Zeichenfarbe beim VC die Bitkombination %10 hat, beim C64 aber %11.


    Maschinenprogramme die direkt auf die Hardware zugreifen, booten das Teil direkt mal aus.


    Fazit: netter Versuch. Das Original ist nun mal das Original. Gibt auch Sachen, die man mit einem VC-20 machen kann, die mit dem C64 nicht gehen, und dann nimmt man einfach besser das Original her. :D

    Interessant als Tabelleneintrag wäre noch der zusätzliche Overhead, den der Interpreter betreiben muß, wenn sich die Formelauswertung selbst rekursiv aufruft. Das ist dann der Fall, wenn ein Unterausdruck in Klammern steht.


    Heißt, im Original-Benchmark wäre noch die Zeile:


    5 V=(A)


    zu testen. Hab jetzt nur in VICE getestet, mit V=A kommen bei mir 153 Jiffies raus, mit V=(A) 176 Jiffies. Das dürfte auch erklären, warum USR() trotz Leeroperation so kräftig zuschlägt.


    Des weiteren sollte man beim RUN-Befehl die [RETURN]-Taste wirklich mit spitzen Fingern betätigen (heißt: nicht mit'm dicken Daumen darauf hängenbleiben), da sonst durch den Tastaturscan alles gleich mal 10% länger braucht ... :whistling:

    Ups. Es sollte auch eigentlich [X] anstelle von [C] (für rechts) heißen.


    Nun ja, das Hauptprogramm ist in BASIC geschrieben und die Richtungsvorgabe erfolgt in den Zeilen 13 bis 17. Ist also kein großes Problem, die gegen eine Joysticksteuerung oder ein anderes, eher gewohntes Tastaturlayout, wie etwa WASD oder OLUR (<- :D) auszutauschen.


    Ich hab das Spiel letzte Nacht zusammengezimmert. Wenn ich schon behaupte, daß Snake kein Hilfs-Array braucht und eine geschickte Kodierung des Bildschirminhalts ausreicht, damit der Schwanz den Schlangenkörper wieder 'abbauen' kann, dann muß ein Machbarkeitsnachweis schon drin sein. :)

    ... dafür aber einer mit richtig viel Platz:



    Benötigt wird mindestens eine +8K RAM-Erweiterung. Gesteuert mit den Tasten [Z], [C], [;] und [/].


    Das Feld hat 78x62 Kacheln, der maximal erreichbare Score liegt also bei etwas über 4800 Punkten ... die zu erreichen dürfte so einen Tag dauern ... :D


    Viele Grüße,


    Michael

    Files

    • mg_snake.zip

      (2 kB, downloaded 11 times, last: )

    Hab ich mir auch als Original geholt (und nicht bereut). ^^

    Mein Exemplar hat einen Ehrenplatz im Regal und ist auch noch vollständig (plus noch einem Schnipsel aus der 64'er mit der Spielerezension - "Ultimativ Elitemäßig" ...) 8o

    Wenn Du die 1581-Version erstellt hast, wird Dir sicherlich aufgefallen sein, daß ein Teil der Diskette als Datenbank für die Anzeigestrings gebraucht wurde.

    Aus diesem Grund enthält meine Version in einer CBM-Partition mit dem Namen "DIRECT ACCESS" eine 1:1-Sektorkopie der zweiten Diskettenseite. ^^

    Mit reinem Kernal-Load funktioniert das Spiel also auch nicht.

    Gibt ja nun auch andere Methoden, wie man auf eine Diskette zugreifen kann, und die sieht man ja auch hier. Ist dann zwar kein KERNAL-Load, aber immer noch Zugriff per Einzelcharakter-I/O über das KERNAL-API. :)

    Diese "Lösung" hat gleich mehrere Haken, [...]

    Immerhin werden diese Haken dort ja auch benannt.


    Auf jeden Fall war ich doch schon etwas verblüfft, wie ich mir das genauer angeschaut hab. Eine vergleichbar kleine Änderung der Befehlsabfolge (verglichen mit der Original-Routine im ROM) sorgt dafür, daß die Wartezeit auf 'Laufwerk-ist-bereit-zur-Übertragung-des-nächsten-Byte' unterbrechbar gehalten wird.


    Im Original wird der Interrupt direkt beim Eintritt in die Routine gesperrt. Das sorgt z.B. bei einem neuen Sektor, oder gar bei Trackwechseln dafür, daß bis zu 200+X Millisekunden vergehen können, bis die Interrupts wieder erlaubt sind. In einer Musikabspielroutine fällt das sicher auf.


    Sicher steht diese Methode in der Tradition vieler anderer, ähnlicher Routinen welche OS-Funktionalität dadurch abändern, daß Teile des ROMs geändert übernommen werden, aber dann etwas weiter wieder ins ROM eingesprungen wird. Das wird bei Wedges so gemacht, bei BASIC-Erweiterungen, etc. - alternativ bleibt einem sonst nur übrig, Originalhardware (C64 + 1541) vorausgesetzt, ein eigenes IEC-Bus-Protokoll zu verwenden, wo sich Byte-Transfers beliebig unterbrechen lassen. Dazu hatte ich vorher ja auch schon auf Tools wie Spindle verwiesen.


    ...


    Um noch mal auf das Originalthema zurückzukommen:


    Programme, die nachladen (egal ob Spiele oder Anwenderprogramme), haben eben den Umfang und die Komplexität erreicht, daß das auch nötig wird. Vor allem dann, wenn man sich die Frage stellen darf, ob denn gewisse Teile des Programmcodes bzw. Grafikdaten, etc. zum derzeitigen Programmzustand denn notwendigerweise gleichzeitig im Speicher stehen müssen.


    Bei Elite könnte man sich z.B. gut vorstellen, daß der Code, der zu den Vorgängen in der Raumstation gehört und der Code im Flugmodus sich jeweils hätten abwechseln können. Gut, bei Elite wurde das nicht gemacht.


    Space Rogue von Origin hat das allerdings so umgesetzt. Hier gibt es - abgesehen von Ladebildschirm, Intro und Abspann - drei unterschiedliche 'Betriebsmodi': Cockpit, Navigation und Raumstation. Beim Wechsel wird nachgeladen. Das hat mich damals nicht so wirklich gestört und ging selbst ohne Schnelllader mit der von mir selbst gebauten 1581-Fassung auch noch etwas schneller als mit einer 1541.


    Dankenswerterweise hatte das Spiel davon abgesehen, irgendwelche eigenen Schnelllader einzusetzen. Damals hieß das dann eben: einen eigenen Schnelllader nutzen (der kompatibel zum Spiel sein mußte) oder sich in Geduld (+/-) üben. Hat heute den Vorteil, daß es jetzt sogar eine EasyFlash-Version von Space Rogue gibt! 8o

    Ich hab diesen Fall so gelöst, [...]

    Auch eine Idee. :)


    Noch eine Anmerkung zum allgemeinen Threadverlauf: wahrscheinlich gibt es mehr Lösungen zum Auslesen der Laufwerks-Fehlermeldung als User hier ... :D ... zeigt aber auch nur, daß hier (leider) ein Problem vorliegt, das man am liebsten gar nicht hätte, und welches "ab Werk" erst mit BASIC 3.5/4.0/7.0 beseitigt wurde (über PRINT DS$). ;(

    Richtig. Die Variante, Kanal 15 zu öffnen, wurde meiner Erinnerung nach in der 64'er mal so begründet, dass sich das leichter merken ließe (weil die Zahl 15 sich damit wiederholt, denn Fehlermeldungen von Laufwerken lassen sich eben nur über die Sekundäradresse 15 auslesen) und es bei der hohen Kanalnummer unwahrscheinlich sei, mit eventuell schon geöffneten Kanälen in Konflikt zu kommen. Halte ich beides für etwas sehr bemüht.

    Abgesehen davon, daß man auch ohne die 64'er auf diese Idee kommen konnte: diese Vorgehensweise hilft durchaus, Resourcen wie logische Filenummern und Kanalnummern geordnet zu halten. Weder mag es der C64, wenn man eine logische Filenummer bei OPEN doppelt vergibt, noch mag es das Laufwerk, wenn man über die Sekundäradresse einen Kanal doppelt vergibt. Bei dem Einsatz von zwei oder mehr Laufwerken gilt letzteres natürlich nicht, tut aber trotzdem nicht weh: die maximale Anzahl gleichzeitig geöffneter Dateien im KERNAL - 10 - sorgt schon dafür, daß einem die Sekundäradressen/Kanäle nicht ausgehen, und so wirst Du in meinen Programmen durchaus OPEN 2,8,2,"..." , OPEN 3,8,3,"..." , OPEN 4,8,4,"..." plus OPEN 15,8,15 finden: nicht als Cargo-Cult, sondern weil es auch im praktischen Gebrauch einfach Sinn macht.


    An der Stelle irgendwelche Tastendrücke einsparen zu wollen, ist inkonsequent.


    In den Fällen, wo ich bei einem zweiten Laufwerk dessen Kommandokanal ebenfalls brauche, werden die zwei dann mit OPEN 14,8,15 und OPEN 15,9,15 eröffnet - setze 8 für Quelllaufwerk und 9 für Ziellaufwerk, so wie hier:

    Was wäre denn zu empfehlen, wenn ich ein bisschen Grafik laden/speichern, Pixel lesen/setzen will?


    Scheint ja auch heute noch nicht von Natur aus enthalten zu sein, sondern von Dritten als Pakete bereitgestellt zu werden. Bin zwar auf Windows, aber es wäre doch schön, wenn es auch auf anderen Systemen laufen würde, darum eher keine GDI-Wrapper.

    Dazu mal der Hint auf Beitrag #16 aus dem vorliegenden Thema.


    Zugegeben eher was für Fans der Kommandozeile, aber dafür kompiliert die Bibliothek auf so ziemlich allem, was einen C-Compiler hat. :)


    Wandlung zwischen Graustufen- bzw. Farbbildern einerseits und *.pgm- bzw. *.ppm-Dateien andererseits erfolge durch das Bildanzeigeprogramms des Vertrauens. In meinem Fall, IrfanView. :D

    Angenommen, du hast eine große Wiese, auf der ein kleiner Mensch steht.

    Challenge accepted! :D


    Ich hab' mal im eigenen Fundus gegraben, und ein Bild mit viel Grün herausgesucht:



    Und hier das Ergebnis nach Heckbert-Median-Cut und k-Means-Clustering mit 240 Farben, *nicht* gedithert:



    Die 16 freigehaltenen Farben am Ende der Palette sind die Standard-Desktop-Farben von RISC OS, damit ich mir das Bild auf meinem Acorn A5000 mit ColourCard Gold in einem 256-Farben-Modus anschauen kann, ohne daß der Desktop Farbstiche bekommt. :saint:

    In Lab arbeitet man grundsätzlich ohne Gamma. Lab ist geräteunabhängig und Gamma bezieht ja immer ein medienspezifisches Verhalten mit ein. Schon alleine deshalb sollte man bei Umrechnungen und Farbmatching auf Lab setzen, die empfindungsabhängigen Abstände sind ein weiterer wichtiger Faktor. Umrechnungen von z.B. sRGB zu Lab und zurück gibt es, kann man einfach verwenden.

    O.K. - ich hätte das jetzt nicht in einen Topf werfen sollen.


    Die hier relevanten Farbräume spannen lineare Vektorräume auf. Jede der Komponenten entspricht einer "Farb"intensität in dieser Richtung, es gibt "Einheitsvektoren", die bestimmten Farben (mit Helligkeit, Farbton und Farbsättigung) entsprechen und - ganz wichtig! - es gilt der Überlagerungssatz.


    sRGB tanzt da insofern aus der Reihe, da die Komponenten zwar in Richtung der reinen Rot-, Grün- und Blauphosphore zeigen, die Intensität aber nicht linear geteilt ist. Der Überlagerungssatz gilt in sRGB nicht.


    Wie ich in einem vorherigen Beitrag schon geschrieben hab, kann man die linearen Farbräume mit einer Koordinatentransformation ineinander umwandeln. Dreht man nun Paletteneinträge und die Farben des Bildes gleichermaßen und berücksichtigt man auch die Abstandsmetrik korrekt, dann drehen sich die 'Wände' zwischen den Paletteneinträgen genauso mit. Insofern sollte es für die Wahl des nächstgelegenen Paletteneintrags überhaupt keinen Unterschied machen, in welchem Farbraum man rechnet!


    Daher hat es für mich noch nie groß Sinn ergeben, für diese Anwendung mit anderen Farbräumen als linear-RGB zu rechnen: die Aufnahmegeräte liefern RGB (außer vielleicht bei medizinischen Röntgenaufnahmen und in der Astronomie) und die meisten Ausgabegeräte geben RGB wieder (jetzt mal nicht Drucker, und irgendwelche Flachbildfernseher mit Gelb als Phosphor auch mal außen vor).


    Was *wirklich* haarig ist, ist die jeweilige spektrale Empfindlichkeitskurve für die R-, G- und B-Komponenten bei der Aufnahme, und das Spektrum des Phosphors. Obwohl bei 'puren' Farben die Farbempfindung eines Objekts direkt per Auge und über die Kette Aufnahme -> Wiedergabe gleich aussehen, können Mischfarben ganz erheblich abweichen. Von der Zwischenverarbeitung in der Retina (Simultankontrast, Wasserfarbentäuschung, etc.) fangen wir am besten erst garnicht an ... :D