letzter Beitrag von Goodwell am
WiC64 als API client (zb für Wikipedia)
- Goodwell
- Erledigt
-
-
Goodwell Das ist ja schon fast das, was ich vorgeschlagen hatte! Muss ich mich nicht einarbeiten, prima Aber ich glaube fast, dass bei dem Zwecke die Georam/Neoram möglicherweise die einfachere Lösung bietet, weil da das Swappen weg fällt.
Natürlich würden von einem fertigen Programm sowohl REU als auch GeoRAM unterstützt werden
-
Der Code ist noch unterirdisch, ich hab erst vor ca 3 Wochen mit Assembler angefangen.
Verstehe nicht viel von Assembler, aber vielleicht sollte ich das mal ändern.
Aber echt gut!
-
Natürlich würden von einem fertigen Programm sowohl REU als auch GeoRAM unterstützt werden
Mir ging es nicht mal um die Unterstützung (naja, sekundär vielleciht), aber für so etwas glaube ich einfach, dass die Georam besser geeignet wäre, wegen dem Page-Einblenden und nicht das Swappen (was auf der anderen Seite natürlich ohne Zeitverzögerung geht). Hat alles seine Vor- und Nachteile!
-
The power of APIs: ich hab die selbe API auf c64-wiki.de aufgerufen (aus der API-Sandbox heraus. Die "öffentliche" API ist wohl deaktiviert)
Das ist ebenfalls MediaWiki, und hat ganz wunderbar funktioniert.
Am Screenshot sieht man gut, dass zB die Unicode zeichen noch nicht behandelt werden.
Jedenfalls kann ich mir gut vorstellen, dass man hier sogar mehrere Wikis anzapft, ohne ein neues PRG laden zu müssen.
-
Mir ging es nicht mal um die Unterstützung (naja, sekundär vielleciht), aber für so etwas glaube ich einfach, dass die Georam besser geeignet wäre, wegen dem Page-Einblenden und nicht das Swappen (was auf der anderen Seite natürlich ohne Zeitverzögerung geht). Hat alles seine Vor- und Nachteile!
Naja, mit der REU ist es genau ein Befehl um zB 32 kB Speicher rüberzuholen, mit denen man dann ganz normal arbeiten kann.
Die 256 Bytes, die das GeoRAM direkt einblendet sind so wenig, dass man wohl ohnehin erst wieder einen größeren block reinholen würde, und den dann wieder als ganzes abarbeitet...
Wobei: jede Wiki-Seite kann theoretisch unendlich groß sein, man muss also auch von der REU nachladen können.
Dh die Schleife zum Laden hat man sowieso; es wird somit nicht viel ändern.
-
Ich hatte dabei eher die Umsetzung im Hinterkopf. Einen Index brauche ich ja sowieso, egal ob direkt oder indirekt. Wenn ich die REU nutze, muss ich mir noch Gedanken um ein gewisses Speichermanagement machen. Das würde bei der Georam durch die Page-Struktur eher entfallen. Ich traue mir nicht zu sagen, ob es mit REU oder Georam leichter sein könnte.
-
Ja, die Font würd ich gern haben.
Hier ist der 8x8-Font (Da ist auch ein wenig UI-Kram drin, der dürfte dich aber nicht stören, da der auf Positionen liegt, die in der ISO-Norm nicht mit druckbaren Zeichen belegt sind) und der schmale Proportionalfont, beide mit ISO 8859-15 Encoding. Damit sollte das Ummappen der ASCII/UTF-Zeichen einfacher vonstatten gehen.
-
-
Für Online-Jobs, die der C64 selbst erledigen können soll (aber der Speicher knapp werden könnte), wäre es nicht schlecht, wenn man dem http-Request zum Laden einer Seite optional eine Paketgröße mitteilen könnte, in der der WiC den C64 stückweise beliefert.
Ich hab gestern Abend festgestellt, dass die Kontrolle über das Holen der Daten vom WiC64 ausschließlich beim C64 liegt.
In den Universalroutinen ist die Schleife in Assembler implementiert.
Es ist also überhaupt kein Problem, hier modifizierten Code zu verwenden, der die Daten unmittelbar in eine REU oder ein GeoRAM schreibt (weil man selber entscheiden kann, wo die Daten landen sollen)
-
-
Ja, ganz bestimmt.
Erstmal ist aber warten angesagt, bis HTTPS unterstützt wird.
-
Goodwell Ich find Deine Idee super und v.a. auch, dass Du den Code auf Github veröffentlichen möchtest. Bin sehr gespannt darauf, u.a. weil ich hoffe, aus Deinem Code lernen zu können. Eine ähnliche Idee hätte ich auch, habe nur leider keine Ahnung (mehr) von Assembler.
Ohne Proxy finde ich auch besser, auch wenn das ganze dann doch aufwendiger wird. Wenn Proxy hätte ich mir gewünscht, dass der Code dafür auch veröffentlicht wird, damit man seinen eigenen Server dafür aufsetzen kann (ein älterer Rasperry Pi würde dafür ja locker reichen).
Du möchtest die REU unterstützen? Das wäre sicher praktisch; würde das mit der REU aus einem TC64 funktionieren?
Ist eigentlich geplant, die Sprachvariante der Wikipedia wählen zu können? Oder vielleicht sogar das C64 Wiki?
-
Bin sehr gespannt darauf, u.a. weil ich hoffe, aus Deinem Code lernen zu können.
Ich bin weit weg vom Assembler-Profi. Es hilft aber, dass man JSON-Parsing und/oder Wiki-Markup Parsing anders betrachten kann, als Parsing im PC-Bereich.
Ein herkömmlicher JSON-Parser bildet normalerweise das komplette JSON als Objekt im Speicher ab, um es dann auf vielfältigste Weise durchsuchen zu können.
In diesem Fall hier ist das aber garnicht nötig, da das JSON nur den Rahmen vorgibt und eine handvoll Metadaten zum eigentlichen Wiki-Text mitgeliefert wird.
Es reicht also vollkommen, im JSON nach dem Schlüssel zu suchen. Keine Hierarchie, Verschachtelung, etc ist hier zu berücksichtigen.
Dh es ist eine Schleife, die so oft durchläuft, wie das JSON Zeichen hat.
Und einen C64 in Assembler von 1 bis 130000 zählen zu lassen (für 130 kB Text) geht sehr schnell
Du möchtest die REU unterstützen? Das wäre sicher praktisch; würde das mit der REU aus einem TC64 funktionieren?
REU Unterstützung äußert sich durch richtiges PEEKen, POKEn und SYSen. Ich hab zwar kein TC64, würde aber meinen, dass das dann überall funktioniert.
Ist eigentlich geplant, die Sprachvariante der Wikipedia wählen zu können? Oder vielleicht sogar das C64 Wiki?
Verschiedene Sprachen sind an sich auch kein Problem, vorausgesetzt dass die sprachspezifischen Sonderzeichen (Umlaute, etc) gerendert werden können.
Es ist also zusätzlicher Aufwand, aber kein grundlegend anderer Programmaufbau nötig.
Wikipedia baut auf Mediawiki auf. Genau wie das C64-Wiki.
Einzige Voraussetzung ist, dass der Wiki-Betreiber die API zugänglich macht, um sich die Daten als JSON holen zu können.
Weil HTML-Parsing ist ein ganz anderes Kaliber als JSON-Parsing, und das halte ich am C64 (auch am C128) und vor allem in Assembler tatsächlich für keine gute Idee.
Mir kommt der Vergleich mit Handy-Apps in den Sinn:
Mobile Webseiten sind zur Selbstverständlichkeit geworden. Trotzdem gibt es unzählige Apps, die nativ Rendern statt einfach ein HTML-View zu zeigen.
Und die Begründung dafür ist eigentlich eine sehr ähnliche wie hier in diesem Thread: HTML ist extrem inperformant und es ist sehr schwierig über verschiedene Browser ein einheitliches Erscheinungsbild zu erreichen - speziell weil sich Browser auch weiter entwickeln.
Eine native Implementierung, wo die geholten Daten ausschließlich Content-Daten sind, aber keine Layout-Daten, ist schneller und stabiler.
Falls sich die HTTPS Problematik aber nicht lösen lassen sollte, wird man wohl um einen Proxy nicht herumkommen. Allerdings würde ich den dann nur zur SSL-Terminierung verwenden.
-
Erstmal ist aber warten angesagt
Hat das Warten ein Ende ?? oder komme ich hier auch zu früh?
-
Ich hatte jetzt so viel Spaß mit 3D Druck Projekten, dass ich hier noch nicht weitergemacht hab.
Ob HTTPS schon unterstützt wird, weiß ich nicht. Aber für ein Wikipedia PRG bist du zu früh, ja
-
Goodwell Sehr interessant und informativ, was Du schreibst. Mit XML, html und JSON kennst Du Dich dann besser aus. Ich hätte vor allem das Rendern der Seite für problematisch und aufwendig gehalten. Man kann natürlich einen reinen Textbrowser machen, dann mit eigenem Zeichensatz.
Rendern von html wird die 8-bit Rechner ziemlich sicher überfordern. Das müsste man über einen Proxy machen. Ansonsten höchstens vielleicht mit REU.
Mit REU habe ich 0,0 Erfahrung. Im TC64 ist eine eingebaut, das weiß ich, aber es gibt wenig Software, die sowas nutzen würde. Bei den Dingen, die man mit einem WiC64 machen kann, würde eine REU allerdings durchaus Sinn haben.
Eine native Implementierung, wo die geholten Daten ausschließlich Content-Daten sind, aber keine Layout-Daten, ist schneller und stabiler.
Würde ich auch so sehen. Das heißt, Du baust zunächst eher eine Art von Text-Browser? Dann würdest Du vermutlich alles was Bild ist ebenfalls ignorieren.
Mir kommt der Vergleich mit Handy-Apps in den Sinn:
Mobile Webseiten sind zur Selbstverständlichkeit geworden. Trotzdem gibt es unzählige Apps, die nativ Rendern statt einfach ein HTML-View zu zeigen.
Ja, der Vergleich ist mir auch schon in den Sinn gekommen (hätte das „in den Sinn“ fast weggelassen; vielleicht hätte Sierohpätsch darauf konntern können Ich finde diese Kommentare immer super und auflockernd.). Ich kann es aber gerade nicht ganz nachvollziehen. Was meinst Du mit dem Unterschied: „nativ rendern“ vs. „html-View“? Mich nerven die Apps eher, die einfach nur stur die Desktop-Applikation nachbilden, ohne die speziellen Gegebenheiten des Endgeräts zu berücksichtigen. Das ist wie die digitale Streifenkarte für den ÖPNV in München.
Falls sich die HTTPS Problematik aber nicht lösen lassen sollte
Das wäre etwas doof. Aber TSL-Verschlüsselung ist vermutlich auch nicht so ganz ohne. Da bräuchte man einen Co-Prozessor ... kann man das WiC wirklich nicht dafür einspannen? Aber ich dachte doch, dass https für das WiC-Portal auch implementiert wird. Da hieß es, dass die Knochenarbeit vom WiC erledigt wird. Oder ich hab's falsch verstanden.
Verschiedene Sprachen sind an sich auch kein Problem, vorausgesetzt dass die sprachspezifischen Sonderzeichen (Umlaute, etc) gerendert werden können.
UTF-8 für den Commodore? Nein ... ich denke, wenn man außer Deutsch noch Englisch unterstützt, ist man doch schon weit und der Zeichensatz gibt das her.
-
Das heißt, Du baust zunächst eher eine Art von Text-Browser? Dann würdest Du vermutlich alles was Bild ist ebenfalls ignorieren.
Genau. Mit ordentlichem Rendering hab ich Null Erfahrung. Vielleicht ist aber ein Text-Browser genug Motivation für jemand anderen, der das schon kann und Spaß dran hat und die Zeit dafür.
Was meinst Du mit dem Unterschied: „nativ rendern“ vs. „html-View“?
Der Screen am Handy, wo du Einstellungen machst, der ist zB nativ gerendert. Dh da liegt kein HTML dahinter, sondern das sind ausprogrammierte Bildschirmelemente (auch wenn diese aus einer Bibliothek kommen).
Und eine HTML-View ist eben, was der Browser am Handy macht: HTML darstellen.
Das wäre etwas doof. Aber TSL-Verschlüsselung ist vermutlich auch nicht so ganz ohne. Da bräuchte man einen Co-Prozessor ... kann man das WiC wirklich nicht dafür einspannen? Aber ich dachte doch, dass https für das WiC-Portal auch implementiert wird. Da hieß es, dass die Knochenarbeit vom WiC erledigt wird. Oder ich hab's falsch verstanden.
Doch, ja, muss eigentlich der ESP am WiC machen. Der hat(te?) aber einen Bug, dass nach ein paar Requests zu HTTPs das Ding hängengeblieben ist.
Der C64 kann das garnicht selber machen, weil das würde heißen, den TCP-Stack am C64 implementieren zu müssen und dort auch das Entschlüsseln.
Wenn man nun bedenkt, dass selbst moderne IT-Hardware ca 20 % an Rechenpower nur für ver- und entschlüsselung verwendet, wird schnell klar, dass das mit 8-bit und 64k RAM nicht funktionieren wird.
UTF-8 für den Commodore? Nein ... ich denke, wenn man außer Deutsch noch Englisch unterstützt, ist man doch schon weit und der Zeichensatz gibt das her.
Also ICH fange mal mit Englisch an (weil keine Sonderzeichen) und mach dann gern mit Deutsch weiter (falls ich soweit komme).
Den Rest darf gern der Rest der Welt lösen
-
Okay, super. Dann verstehe ich schon mehr. Klingt auf jeden Fall gut.
Der Screen am Handy, wo du Einstellungen machst, der ist zB nativ gerendert. Dh da liegt kein HTML dahinter, sondern das sind ausprogrammierte Bildschirmelemente (auch wenn diese aus einer Bibliothek kommen).
Und eine HTML-View ist eben, was der Browser am Handy macht: HTML darstellen.
Ja, da hatte ich Dich missverstanden. Ich dachte, Du denkst rein an die Darstellung von html-Seiten. Da wäre mir jetzt der Unterschied nicht klar gewesen. Die Oberflächen sind ja ohnehin nicht als html ausgelegt und außerdem ist das bei Smartphones gar keine Besonderheit gegenüber anderen Oberflächen von anderen Betriebssystemen. Wobei natürlich „nativ“ gerendert ist es schon auch, wenn Firefox eine html-Seite darstellt. Das ist jetzt etwas fließend. Die Oberfläche selbst muss ja auch „gerendert“ werden. Wenn man das Auge genug verschwimmen lässt, ist alles eine virtuelle Maschine. Wollen aber nicht philosophisch werden ...
Und ganz ehrlich: Ich bin froh, dass die App-Entwickler nicht einfach nur einen html-View hinklatschen. Das wäre richtiger Mist. Das ist genau das, was ich oben meinte, dass sowas die Eigenheiten des Emdgeräts vorsätzlich nicht berücksichtigt. Extrem ist das zu sehen bei der Umsetzung einer Textverarbeitung (SoftMaker TextMaker) für Android. Das ist zwar kein html-View, aber es ist genau so, wie man es nicht machen soll: Die Desktop-Applikation nahezu 1:1 für Android umgesetzt. Das ist genau Blödsinn.
Es gab Ansätze und Ideen, GUIs durch html oder XML im Hintergrund zu definieren, aber da kam irgendwie dann nichts mehr und vermutlich ist das auch besser so.
Doch, ja, muss eigentlich der ESP am WiC machen. Der hat(te?) aber einen Bug, dass nach ein paar Requests zu HTTPs das Ding hängengeblieben ist.
Ach, wieder so ein doofer Bug. Okay, dann muss man damit leben. Wird dann eben nicht alles möglich sein oder man muss einen Proxy dazwischen schalten. Dann wäre es aber gut, den selbst betreiben zu können.
Wenn man nun bedenkt, dass selbst moderne IT-Hardware ca 20 % an Rechenpower nur für ver- und entschlüsselung verwendet, wird schnell klar, dass das mit 8-bit und 64k RAM nicht funktionieren wird.
20%? So viel? Würde ich jetzt bezweifeln, wenn man die Rechenpower ansieht. Außerdem würde sich das in der CPU-Auslastungsanzeige niederschlagen. Es dürfte schon signifikant sein, aber nicht 20%.
Aber es ist klar, dass ein 6502 das nicht können kann. Zumindest nicht, wenn man es auch noch rein von der Zeit her abwarten können will.
-
UTF-8 für den Commodore? Nein ...
UTF-8 muss ja nicht gleich sein, ISO Latin (9) bzw. ISO 8859 (-15, Westeuropa) reicht schon für viele Sprachen.