Hallo Besucher, der Thread wurde 7,1k mal aufgerufen und enthält 19 Antworten

letzter Beitrag von Chris5523 am

Archimedes an 15 KHz Monitor

    Es ist mir nach einigem Probieren gelungen den Archimedes Core auf meinem 1.3 Mist zum Laufen zu bekommen, er benötigt eine spezielle Version, weil die Ram Timings wohl anders sind. Allerdings gelingt es mir nicht den Core an einem RGB Monitor zu betreiben. Es funktioniert nur am VGA Monitor. Soweit ich verstehe sollte der Core zumindest mit Risc OS2 an einem RGB Monitor laufen. Gibt es eine Möglichkeit den Core zu zwingen ein RGB Bild auszugeben?

    Zitat von Chris5523

    Es ist mir nach einigem Probieren gelungen den Archimedes Core auf meinem 1.3 Mist zum Laufen zu bekommen, er benötigt eine spezielle Version, weil die Ram Timings wohl anders sind. Allerdings gelingt es mir nicht den Core an einem RGB Monitor zu betreiben. Es funktioniert nur am VGA Monitor. Soweit ich verstehe sollte der Core zumindest mit Risc OS2 an einem RGB Monitor laufen. Gibt es eine Möglichkeit den Core zu zwingen ein RGB Bild auszugeben?


    Ich habe es nie selbst versucht, aber bisher sind meine Informationen so, dass der Core nichts selbst skaliert oder framedoubled oder so. mist.ini ist also irrelevant. Man muss es RISC OS selbst beibringen.


    Das tut man, indem man den MonitorType umkonfiguriert. Von der Kommandozeile:
    *configure monitortype 1


    Damit stellt man auf "Multisync-Monitor" um, und die klassischen Modi wie 12 (16 Farben, 640x256) oder 15 (256 Farben, 640x256) sind dann 15kHz PAL. Während die VGA-Modi 25 bis 28 weiterhin verfügbar bleiben.


    Jetzt ist allerdings die Frage, ob diese Einstellung den Reboot überlebt - ich erinnere mich nicht mehr, inwiefern die CMOS-Funktionalität im Core implementiert ist, und wer eigentlich im Moment den MonitorType auf "Super VGA" einstellt - geb' mal
    *status
    ein und schaue, ob da MonitorType Auto steht.


    Gruß
    hubersn

    Vielen Dank für die Antwort. Wie komme ich an die Kommandozeile beim Archimedes? Ich bekomme ein nichtsynchronisiertes Bild (durchlaufend), ich könnte also einfach tippen, wenn man die Kommandozeile per Tastendruck aufrufen kann.


    Auf dem VGA Monitor bootet er bei Risc OS 3 automatisch in Super VGA, das Setting für den Monitor steht dann in den Displayeinstellungen des Risc OS nicht auf automatisch erkennen. Wenn ich das umschalte auf Automatisch erkennen, überlebt das den Reboot nicht, weshalb ich denke, dass er das CMOS nicht speichert.

    Zitat von Chris5523

    Vielen Dank für die Antwort. Wie komme ich an die Kommandozeile beim Archimedes? Ich bekomme ein nichtsynchronisiertes Bild (durchlaufend), ich könnte also einfach tippen, wenn man die Kommandozeile per Tastendruck aufrufen kann.


    Auf dem VGA Monitor bootet er bei Risc OS 3 automatisch in Super VGA, das Setting für den Monitor steht dann in den Displayeinstellungen des Risc OS nicht auf automatisch erkennen. Wenn ich das umschalte auf Automatisch erkennen, überlebt das den Reboot nicht, weshalb ich denke, dass er das CMOS nicht speichert.


    Zur Kommandozeile kommt man mit F12. Dort kann man beliebige "Stern-Kommandos" absetzen, der Stern ist quasi der Prompt und damit immer "vorausgefüllt", für
    *configure monitortype 1
    müsste man also
    F12 configure monitortype 1
    tatsächlich tippen. Mit Return kommt man wieder von der CLI in den Desktop zurück. Achtung, könnte standardmäßig englisches Tastaturlayout sein, also Vorsicht mit y und z vertauscht...aber alle configure-Einstellungen wirken erst nach dem Reboot, wenn das nicht überlebt kann man hier ohne weiteres nichts tun.


    Ich versuche, so schnell wie möglich zuhause mit meinem MiST ein wenig zu experimentieren, dann kann ich besser helfen. Es könnte notwendig sein, das ROM-Image zu patchen so dass direkt der MonitorType 1 aktiv wird. Es könnte auch klappen, wenn man eine der "Boot-Tasten" drückt um den MonitorType beim Startvorgang zu setzen, das muss ich aber erst prüfen, ob die USB-Emulation des MiST zu diesem Zeitpunkt schon die Tastatur an den Core angebunden hat.


    Gruß
    hubersn

    Ich werde es nachher mal probieren, schon mal vielen Dank für die Antworten.
    Ich denke die Tastatur wird schon angesprochen beim Booten, glaube ich zumindest, t und r machen glaube ich etwas. Das Problem ist, dass ich den Verdacht habe, dass der Core bei meiner Tastatur den Ziffernblock nicht aktiviert, die entsprechende LED leuchtet nicht, auch nicht, wenn ich die Num Taste drücke und ich deshalb nicht mit Ziffernblock 0 booten kann, was soweit ich verstehe monitortype 1 wäre.

    Zitat von Chris5523

    Ich werde es nachher mal probieren, schon mal vielen Dank für die Antworten.
    Ich denke die Tastatur wird schon angesprochen beim Booten, glaube ich zumindest, t und r machen glaube ich etwas. Das Problem ist, dass ich den Verdacht habe, dass der Core bei meiner Tastatur den Ziffernblock nicht aktiviert, die entsprechende LED leuchtet nicht, auch nicht, wenn ich die Num Taste drücke und ich deshalb nicht mit Ziffernblock 0 booten kann, was soweit ich verstehe monitortype 1 wäre.


    0 wäre tatsächlich MonitorType 0 aka "klassisch nur 15 kHz", während MonitorType 1 sowohl 15kHz als auch VGA kann. Wäre für Deine Zwecke aber beides genauso gut.


    Ich weiß aus dem Stand nicht, ob an der Stelle NumLock überhaupt für die RISC OS-Seite eine Rolle spielen würde, aber vermutlich tut sie das für die USB-Seite, damit die richtigen Keycodes angeliefert werden.


    Aber irgendeine Lösung finden wir da schon. Ich bin motiviert :)


    Gruß
    hubersn

    Zitat von Chris5523

    Ich hab es nun ausprobiert, der Monitortype ist 4 und ich kann ihn zwar ändern, aber ich sehe keine Möglichkeit das CMOS zu speichern, ich denke in dem Fall muss wirklich der Core angepasst werden.


    Irgendwoher nimmt RISC OS den Default-MonitorType, ich hoffe dass der vom Core nicht hart überschrieben wird. Ich werde mich bei den Experten kundig machen.


    Es gibt auch die Möglichkeit, CMOS-Inhalte vom Massenspeicher nachzuladen und die derzeitige RAM-Kopie zu speichern. Ich bin aber nicht sicher, inwiefern das dann "zur Laufzeit" bezüglich des MonitorType wirksam wird.


    Ebenfalls möglich wäre vermutlich, die Bildschirmmodi-Definitionen hart auf PAL umzuschießen. Da werde ich auch ein paar Experten konsultieren müssen.


    Irgendwie ist es schon witzig - das einzige ernsthafte Langzeithaltbarkeitsproblem bei Archimedes und Nachfolgemodelle ist die CMOS-Batterie, die oft ungünstig auf die Hauptplatine suppt und dort den CMOS-Uhrenchip himmelt nebst angrenzenden Leiterbahnen. Und jetzt haben wir ausgerechnet in einer virtuellen Archimedes-Umgebung auch ein CMOS-Problem.


    Gruß
    hubersn

    Zitat von Chris5523

    Stimmt, das ist in der Tat ironisch. Der Core legt eine CFG Datei an, in die wird aber nur das verwendete RISC OS File geschrieben. Soweit ich Dich verstehe nimmt der Core jetzt die Daten aus dem Risc OS Rom, oder? Das heißt, da sind Default Werte gespeichert?


    Es gibt im ROM codierte Default-Werte, die beim CMOS-Reset wieder aktiv von RISC OS ins CMOS geschrieben werden. Das ist das einzige, dessen ich mir momentan in der MIST-Situation ganz sicher bin.


    Was ich nicht weiß: wie handhabt der Core die I2C-Kommunikation, über die CMOS und RTC funktionieren? Es könnte sein, dass er das Auslesen aus dem CMOS irgendwie speziell hartcodiert faked (also die I2C-Kommunikation schon im Ansatz simuliert), oder dass er sein eigenes CMOS mit fixen Werten hat und diese zurückliefert. Oder dass der Chip erst gar nicht auf dem I2C-Bus erscheint, dann fällt RISC OS von allein auf hartcodierte Werte zurück (diese Situation könnte man dann durch Patchen des ROM-Images nutzen).


    Es kommt mir halt gefühlsmäßig extrem komisch vor, dass standardmäßig SVGA als MonitorType aktiv ist. Das ist m.E. niemals ein RISC OS 3-Default gewesen, auf keiner physischen Acorn-Maschine. Das lässt mich vermuten, dass der Core da selbst aktiv wird - in welcher Art und Weise auch immer. Der Autor des Cores ist gerade wieder auf GitHub aktiv, ich habe da in den Kommentaren zu einem Issue mal nachgehakt.


    Ich habe im Stardot-Forum auch mal die Experten befragt zu einigen RISC OS-Details, vielleicht bringt das Erleuchtung. Aus dem Alter, als ich noch selber ROMs disassembliert habe, bin ich leider lange raus...


    Gruß
    hubersn

    Zitat von Chris5523

    Und noch einmal vielen Dank von mir für deine Mühe. Ich bin, was den Archimedes angeht, total unbeleckt, finde es aber gerade sehr interessant etwas über den Aufbau des Geräts zu lernen, auch dafür vielen Dank.


    Ich versuche buchstäblich schon seit Jahren, endlich meinen "RISC OS für Neueinsteiger"-Artikel fertig zu kriegen, wo die Basics (und vielleicht sogar BASIC :D ) vermittelt werden, egal ob alter Archimedes, MIST, Emulator oder aktueller Raspberry Pi mit RISC OS 5. Das Problem mit RISC OS ist ja, dass es vor allem auf Deutsch kaum verständliche Einsteiger-Doku für den schnellen Überblick gibt. Und das System ist so sehr anders als die anderen, dass der "Einfach-mal-probieren"-Einstieg oft schwer fällt.


    Leider ist es bis jetzt eine teils ausformulierte, teils stichwortartige, aber insgesamt sehr chaotische Sammlung von viel Text. Ich nehme diesen Thread mal zum Anlass, den Draft zu veröffentlichen - besser, als wenn er weiter nur auf meiner Platte herumschimmelt:
    http://riscosblog.huber-net.de…sc-os-fuer-neueinsteiger/


    Nachdem Du Dich als "total unbeleckt" bezüglich des Archimedes und RISC OS bezeichnet hast, bist Du jetzt quasi zum Feedback verpflichtet - was davon versteht man, wo wird zuviel Vorwissen vorausgesetzt, an welcher Stelle braucht man Screenshots damit man den Text versteht usw.


    Gruß
    hubersn

    Zitat von hubersn


    Ich habe im Stardot-Forum auch mal die Experten befragt zu einigen RISC OS-Details, vielleicht bringt das Erleuchtung. Aus dem Alter, als ich noch selber ROMs disassembliert habe, bin ich leider lange raus...


    OK, die beiden Experten schlechthin für dieses Thema haben mir geantwortet. Anders als ich angenommen habe wird die MonitorType-Konfiguration von RISC OS sehr wohl beim nächsten screenmode change live ausgewertet, und es werden nicht nur die bekannten Bildschirmmodi sozusagen hart auf VGA-Timing oder PAL-Timing initialisiert, sondern es sind immer dieselben Screenmode-Parameter die dann "on the fly" bei MonitorType 4 VGA-tauglich per Letterboxing gemacht werden.


    Folgendes müsste also funktionieren:
    * Core starten und Bootvorgang abwarten
    * F12
    * configure monitortype 1
    * wimpmode 12
    * Return drücken um zum Desktop zurückzukehren


    Ich bin gespannt!


    Gruß
    hubersn

    Das werde ich Zuhause gleich mal ausprobieren, vielen Dank. Mit configure Monitortype allein hat es gestern ja nicht geklappt, aber da habe ich es auch ohne den Wimpmode Befehl ausprobiert. Ich gebe heute Abend auf jeden Fall Rückmeldung.


    Feedback für das Tutorial habe ich Dir übrigens im anderen Thread geschrieben.

    Zitat von Chris5523

    Das werde ich Zuhause gleich mal ausprobieren, vielen Dank. Mit configure Monitortype allein hat es gestern ja nicht geklappt, aber da habe ich es auch ohne den Wimpmode Befehl ausprobiert. Ich gebe heute Abend auf jeden Fall Rückmeldung.


    Das configure-Kommando ist quasi "passiv", es ändert nur die Werte in der RAM-Kopie des CMOS-Speichers sowie den Wert im CMOS-Speicher selbst. Erst beim nächsten echten Ändern des Bildschirmmodus kann das ggf. berücksichtigt werden. Das forciert dann das WimpMode-Kommando, und "12" ist einer der PAL-Modi (640x256, 16 Farben, 50 Hz).


    Inzwischen hat sich auch weiterer Nebel gelichtet. Der Archie-Core hat hartcodierte CMOS-Werte am Start:
    https://github.com/mist-devel/…hie/rtl/i2cslave/cmos.mif


    Inwiefern zusätzlich Werte gefaked werden, kann ich nicht sagen - eigentich trägt Byte 133 (also Zeile 134) die Information über Composite Sync vs. Seperate Sync und den MonitorType, aber da steht nur "0" in der cmos.mif.


    Cool wäre, im Archie-Core auch den Scandouble-Aktiv-Wert aus der mist.ini auslesen und je nachdem auf MonitorType 0 oder MonitorType 4 konfigurieren. Man könnte auch MonitorType Auto unterstützen, wo dann 0 oder 4 resultiert je nach mist.ini. Das ganz unabhängig davon, dass es natürlich ganz schön were, das in der Core-Konfiguration direkt beeinflussen zu können oder über eine CMOS-Datei zu arbeiten.


    Zitat von Chris5523


    Feedback für das Tutorial habe ich Dir übrigens im anderen Thread geschrieben.


    Habe ich gesehen, vielen Dank. Bin motiviert, das noch entscheidend zu verbessern in den nächsten Tagen.


    Gruß
    hubersn

    Ich konnte es jetzt ausprobieren, die Frequenz wird in der Tat geändert, aber zumindest an meinem Coomodore 1081 Monitor wird das Bild nicht synchronisiert. Wenn ich den Mist starte läuft das Bild von unten nach oben durch und ich sehe den Screen zweimal klein nebeneinander. Nach Eingeben von configure monitortype 1 und wimpmode 12 läuft das Bild weiterhin durch, aber es ich auf die ganze Breite des Bildschirms gestreckt.

    Zitat von Chris5523

    Ich konnte es jetzt ausprobieren, die Frequenz wird in der Tat geändert, aber zumindest an meinem Coomodore 1081 Monitor wird das Bild nicht synchronisiert. Wenn ich den Mist starte läuft das Bild von unten nach oben durch und ich sehe den Screen zweimal klein nebeneinander. Nach Eingeben von configure monitortype 1 und wimpmode 12 läuft das Bild weiterhin durch, aber es ich auf die ganze Breite des Bildschirms gestreckt.


    OK, ich versuche es mal mit einem meiner 15kHz-Monitore. Könnte sein, dass das ausgegebene Timing des MIST nicht 100% korrekt ist. Wenn mein NEC 3D noch läuft...der konnte sich sogar mit dem Toaster syncen :D


    Gruß
    hubersn

    Ja, ich denke mal, dass es ein Problem mit dem Timing ist, es ist immer schwer zu sehen, wie wenig oder stark die Nichtsynchronisation ist, aber das Bild läuft nicht wirklich schnell einfach durch und hat auch das richtige Format. Vom Gefühl her würde ich sagen, da fehlt nicht viel.

    Zitat von Chris5523

    Ja, ich denke mal, dass es ein Problem mit dem Timing ist, es ist immer schwer zu sehen, wie wenig oder stark die Nichtsynchronisation ist, aber das Bild läuft nicht wirklich schnell einfach durch und hat auch das richtige Format. Vom Gefühl her würde ich sagen, da fehlt nicht viel.


    Slingshot hat sich der Sache nun angenommen und einen Core produziert, der die korrekten 24 MHz Basistakt an den VIDC bringt (bisher war das 25 MHz, was für VGA gut ist, für 15kHz aber nicht). Scheint für einige zu funktionieren, sowohl über Scart-RGB als auch Component Out. Ich habe es noch nicht selbst probiert.


    Hier der Thread mit dem Link zum 24MHz-Core:
    http://www.atari-forum.com/vie…t=27637&start=150#p367798


    Gruß
    hubersn