Hallo Besucher, der Thread wurde 106k mal aufgerufen und enthält 727 Antworten

letzter Beitrag von emulaThor am

Webbrowser für 8-Bit-Rechner

    Die Gründe warum es kein großes Interesse an Markdown-Proxys in dieser Art gibt, ist sehr wahrscheinlich die Tatsache, dass selbst Fernseher/HDMI-Sticks/eBookReader/Billigsmartphones etc. heute einen rundimentären Browser drin haben, der meist alles an Heimcomputer-Browser-Versuchen in den Schatten stellt.


    Ein schöner Punkt wurde hier genannt. Gibt es einen Algorithmus der in der Lage ist jegliche, oder zumindest die meisten, Seiten so gut runterzubrechen, dass man sie noch bedienen und sich daran erfreuen kann?


    Was mir noch einfällt sind XSLT Geschichten. Die sind ja extra dafür erfunden XML zu transformieren. Aber das sich irgendein Webdesigner daran hält schön die CSS Tags für Navi, Formulare usw. zu verwenden, darauf brauch man nicht hoffen. Wenn im HTML5 Canvas dynamisch per Ajax und Javascript Grafiken erzeugt werden, dann is Schluss mit lustig, wenn es keine Alternativdarstellung gibt.

    Zitat von Phasengleich

    Die Gründe warum es kein großes Interesse an Markdown-Proxys in dieser Art gibt, ist sehr wahrscheinlich die Tatsache, dass selbst Fernseher/HDMI-Sticks/eBookReader/Billigsmartphones etc. heute einen rundimentären Browser drin haben, der meist alles an Heimcomputer-Browser-Versuchen in den Schatten stellt.

    Das hatte wir alles schon durch (9 Seiten Thread). Ich WEISS, dass jedes 50€-Handy besser zum Surfen geeignet ist als ein C64 und dass ein Tablet oder PC ALLES besser kann als ein C64 oder Atari. Ich glaube daher nicht, dass sich jemand extra einen C64 kauft, um damit ins Netz zu gehen. Aber wir HIER machen hunderte von Sachen mit unseren 64ern, die außenstehende für Schwachsinn halten würden – warum also nicht im Web surfen, SELBST wenn es schlechter geht als mit jedem anderen Gerät im Haushalt. Interessens-Bekundungen dahingehend hat es hier durchaus gegeben. Uns fehlen hier nicht die Leute, die es nutzen würden (und das sind hier ja nur die C64-Fans, auf die sich so eine Proxy-Web-Lösung ja nicht beschränken würde), sondern die, die in der Lage sind es umzusetzen.


    Zitat von Phasengleich

    Gibt es einen Algorithmus der in der Lage ist jegliche, oder zumindest die meisten, Seiten so gut runterzubrechen, dass man sie noch bedienen und sich daran erfreuen kann?

    Hatte ich auch schon mehrfach verlinkt. Eine denkbare Basis wäre ein Lynx, der als Proxy fungiert. Den gibt es und ich hatte ihn hier verlinkt. Dessen Ergebnis könnte dann durch den HTML2Markdown-Konverter gejagt werden und dann muss man halt noch ein paar Optimierungen vornehmen (z.B. Menüs vorbereiten), zu denen ich erst was detailliert sagen kann, wenn ich erste Ergebnis der Konvertierungen sehe.


    Zitat von Phasengleich

    Was mir noch einfällt sind XSLT Geschichten.

    Hatten wir auch schon durch. Ist evtl. für den Job geeignet – kann der Programmierer gerne verwenden, wenn er damit umgehen kann.


    Zitat von Phasengleich

    Wenn im HTML5 Canvas dynamisch per Ajax und Javascript Grafiken erzeugt werden, dann is Schluss mit lustig, wenn es keine Alternativdarstellung gibt.

    Ja, dann ist Schluss. Jetzt zeige mir die Top-500-Domains (oder Retro-relevante), die das alternativlos nutzen. Das ist so, als wenn man sagt: Was ist mit Flash? Das geht halt auch nicht – aber auf Info-lastigen Seiten (die wollen wir ja ansurfen) wird sowas glücklicherweise so gut wie nicht benutzt. Alles schon bedacht – es muss trotzdem wer machen.


    Es nützt nichts, den advocatus diaboli zu spielen und auf jedes kleine denkbare Fallstrick zu verweisen. Nach meiner Einschätzung (Web ist mein Beruf) sind 99,9% aller Webseiten (Tendenz wachsend) so gebaut, dass man sie auf (aufgepeppte) Textdarstellung herunterbrechen kann. Und wenn es nur 90% wären, wäre es immer noch grandios.

    Ja ich weiß, wurde schon alles angesprochen. Ich war mal Webentwickler(PHP). Webdesign hatte ich auch mal ein paar Jahre gemacht, bin dann aber, als es mit CSS los ging, ausgestiegen. Ich habe nur mit BlindGifs und verschachtelten Tabellen sowie Cinema4D/Photoshop/Imageready gearbeitet. Das ist so mein Kenntnisstand vom Web. Wie das aktuell im Webdesign aussieht, da habe ich wenig Ahnung von, da bist Du der Experte. Wenn das wirklich so ist dass die meisten aktuellen Seiten sich wirklich an die Regeln halten, dann müsste das für diese Seiten eine Lösung geben, oder zumindest die Bausteine dafür.


    Heute interessiert mich das Web leider nicht mehr die Bohne. Ich finde das leider alles total langweilig, sonst hätte ich bestimmt schon was versucht zu dem Thema hier.


    Nicht falsch verstehen. Ich will dir das Projekt nicht ausreden, sondern nur alle meine Bedenken äußern.

    Zitat von Phasengleich

    Heute interessiert mich das Web leider nicht mehr die Bohne. Ich finde das leider alles total langweilig, sonst hätte ich bestimmt schon was versucht zu dem Thema hier.

    Schade. Meinst du mit "langweilig" die Technik oder die Inhalte? Inhalte können es ja nicht sein, denn dann wäre ja auch diese Forum nutzlos für dich.


    Und die Technik finde ich eigentlich ganz spannend, vor allem, weil sie sich immer weiter entwickelt und zwar in die richtige Richtung: Weg von proprietärem Mist, wie er jahrelang von Adobe (Flash, Shockwave) und Microsoft (MSN, Direct-X-Controls in IE, IE-Alleingänge, BMP, WMV, WMA ...) propagiert wurde hin zu offenen Standards. Und weg vom Missbrauch von HTML zur Gestaltung von Webseiten hin zu sauberen CSS-Ergänzungen.


    Ich habe früher auch mit Frames, Tabellen und unsichtbaren GIFs meine Seiten gestalten müssen und bin extrem froh, das jetzt in sauberer Art und Weise tun zu dürfen (auch wenn es einem manchmal DIVs und CSS auch nicht leicht machen).


    Ich habe auch nichts dagegen, die Idee eines Low-Tech-Webs und dem dafür nötigen Proxy-Server zu verteidigen, nur das Wiederholen nervt halt manchmal. Aber wenn sich dafür als Lohn irgendwann ein Programmierer finden sollte, der sich an eine Umsetzung der Proxy-Idee (die ja nicht originär meine ist) wagt, dann war mir der Aufwand des ständigen Trommelns sicher nicht zu viel.

    Ich meine schon die Technik, liegt aber wahrscheinlich daran, dass ich beruflich in den Jobs extrem schlechte Erfahrungen gemacht habe und am Ende hat das auch meine Gesundheit gekostet. Das hat zwar was mit mir und meinen Arbeitgebern zu tun gehabt und nicht mit der Technik, aber mein Hohlkopf hat alles was mit Webentwicklung zu tun hat extrem negativ verknüpft. Ich habe des öfteren versucht wieder einzusteigen, aber gemerkt dass ich das nicht mehr will und kann.

    Mich hat mal interessiert, ob es von der Darstellungsqualität überhaupt realistisch wäre, Bilder zum C64 zu übertragen. Gut, auf Fotos würde man schon (im Koala-Format) etwas erkennen können – aber gilt das auch für Zahlen und Legenden in Business-Grafiken?


    Ich habe also folgendes Szenario nachgestellt: Eine Webseite enthält eine eingebettete Grafik, die beim C64 als Link (mit dem Alt-Tag als Namen) angezeigt würde. Bei Klick auf den Bild-Kasten (man könnte optional ein Popup mit Grafikformat-Auswahl anbieten) lädt der C64 vom Proxy das zuvor umgewandelte Bild (fullscreen) nach. Da man in der Komplettansicht noch nicht alles erkennen kann und für eine größere, scrollbare Grafik der Speicher evtl. nicht ausreicht, sollte eine Zoomfunktion angeboten werden. Nach meinen Tests reicht bei sehr vielen Grafiken schon eine Verdoppelung der Darstellung aus, um Zahlen erkennen zu können. Man könnte aber auch einen flexiblen Rahmen anbieten, falls man noch tiefer "reingehen" möchte. Mit dem Minus-Icon geht man zurück auf Voll-Ansicht und mit dem Back-Icon zurück zur Textseite. Im Beispiel zeige ich einmal eine Hires-Darstellung und einmal eine Multicolor-Darstellung.



    Verstehe mich bitte nicht falsch, ich finde das Projekt durchaus interessant - aber nur solange es jemand anderes coded und nicht ich...
    Motivier mich mal. :)


    Die von dir angeführten html2markdown-Konverter hatte ich z.T. schon ausprobiert und für kaum besser als Lynx befunden. Hier mal beispielhaft Webseiten die mit https://domchristie.github.io/to-markdown/ nach Markdown konvertiert und mit http://markdownlivepreview.com/ gerendert wurden:


    CSDB:


    forum 64:


    Wikipedia:


    Alternativ habe ich spaßeshalber ein Perlscript geschrieben, nur um einen schnellen Eindruck von der Darstellung bekommen zu können.
    Aufruf mit perl mdtest.pl http ://www.wasauchimmer.de
    Die Webseite wird geladen, es werden alle <ul>...</ul> gelöscht (die sollen ja später an anderer Stelle als Menu auftauchen), das verbleibende HTML wird nach markdown gewandelt und abgespeichert. Anschließend wird das Markdown wieder nach html gewandelt, ebenfalls abgespeichert und der Browser aufgerufen um das Resultat anzuzeigen.

    Wie gesagt, ich selber finde das kaum besser als Lynx. Und Lynx haben wir vor 20-30 Jahren schon benutzt um mit dem C64 zu surfen; die Technik dafür existiert also schon lange. Jedoch waren wir glaube ich alle froh davon wegzukommen... Bei dieser Technik musste der c64 zwar kein http/html/markdown handhaben sondern vt100 (oder wie auch immer die Brocken damals hiessen), aber abgesehen davon dürfte es doch ziemlich genau das sein was du suchst.
    Allein die Aussicht für dasselbe Resultat nun eine andere Methode zu verwenden (irgendetwas+Markdown statt vt100) reizt glaube ich keinen Coder... Immerhin müsste der wohl seine nächsten 20+ Wochenenden investieren um ein völlig neues System auf die Beine zu stellen.


    Lass mich mal eine andere Vorgehensweise vorschlagen. Da ich nur rudimentäre HTML-Kenntnisse habe (und die auch schon 10 Jahre alt sind) füge bitte deine Expertise hinzu. :)


    Ich würde das Rendern einer Webseite grobschlächtig in drei Bereiche Unterteilen wollen, nähhmlich wo, was und wie. Zunächst zum wo: HTML-Elemente werden glaube ich grundsätzlich untereinander angeordnet, es besteht jedoch auch die Möglichkeit sie nebeneinander zu setzen. Dadurch ergibt sich eine Art Raster in dem die einzelnen "Content-Blöcke" stehen. In etwa so:


    Wenn man ein solches Raster extrahieren könnte wäre das schoneinmal sehr viel Wert. Dann wüsste man wohl auch was in einer Zelle gerendert werden soll (Text oder Bild). Wie der Zelleninhalt gerendert werden soll (Schriftgröße/Farbe/etc) wäre dann hoffentlich auch nicht mehr das ganz große Problem und im Zweifelsfall Sache des Browsers.
    Was die Größe der Zellen angeht: Da sollte der "Proxy" schoneinmal ein Pre-Rendering durchführen um Werte für die Breite der einzelnen Zellen vorzuschlagen (z.B. in Prozent bezüglich der Gesamtbreite der Seite). Die Höhe der Zellen müsste hingegen der Browser bestimmen, halt je nach verwendetem Zeichensatz.
    Als Ausgabe des Proxies würde ich mich auch nicht unbedingt an einem "streaming-fähigen" Format versuchen sondern ruhig etwas völlig "proprietäres" nehmen. Eher so in die Richtung Geowrite oder Printfox oder was auch immer. Es soll ja in erster Linie "hübsche Texte mit Hyperlinks" auf dem C64 darstellen können; weitere Fähigkeiten sind zweitrangig.


    Was meinst du, klingt das machbar? Oder kann man heutige Webseiten aufgrund von CSS/Javscript/Flash/etc. nicht mehr so "einfach" handhaben?



    PS: Hast du auch mal geschaut wie das auf anderen Platformen aussieht? Für den Amiga gab/gibt es wohl eine Reihe von Webbrowser, aber wie sieht's bei Spectrum/MSX/Archimedes/NES/etc. aus? Gibt's da auch schon irgendetwas?

    Erst einmal danke für deine Mühe. Es ist schön, zu lesen, dass sich andere auch Gedanken zum Thema machen. Nur so kann man die Sache verbessern und die Chance auf Realisierung erhöhen.


    Zitat von Rapid Eraser

    Hast du auch mal geschaut wie das auf anderen Platformen aussieht? Für den Amiga gab/gibt es wohl eine Reihe von Webbrowser, aber wie sieht's bei Spectrum/MSX/Archimedes/NES/etc. aus? Gibt's da auch schon irgendetwas?

    Mit einem neuen Specci-Browser fängt der Thread an. Der ist aus meiner Sicht rudimentärer als Kontiki. Auf jeden Fall halt grob in der gleichen Liga und wird mit den gleichen Herausforderungen kämpfen.


    Für die UNIX Implementierung UZIX, die auf MSX(2)-Rechnern läuft, gibt es den FudeBrowser, der immerhin sogar Grafiken darstellen kann. Allerdings ist ein MSX2-Rechner ja schon deutlich leistungsfähiger als ein C64. Vergleich mal SymbOS 2.1 mit GEOS, dann sieht man die unterschiedlichen Hardware-Fähigkeiten, was Auflösung, Farben, Speicher und Performance angeht. Trotzdem würde natürlich auch so ein System von einem Browser profitieren, der nicht mehr das ganze HTML selbst interpretieren (und Bilder selbst herunter rechnen) muss.


    Für die Atari 8-Bit-Rechner habe ich auch Kontiki (Video) gefunden, welches mit 40 Zeichen pro Zeile und reiner Textdarstellung aufwartet, wie beim C64. Vielleicht können die Ataris hier mit ihrem etwas höheren Takt punkten. Für den Atari ST gibt es CAB (Video), dessen Output wie Lynx (mit ein paar herunter gerechneten Bildern als Zugabe) aussieht. Und man kann im Video sehen, dass selbst der ST sich schwer tut, das ganze HTML zu verarbeiten. Also auch frühe 16-Bitter würden sich freuen, wenn ein Proxy ihnen Arbeit abnehmen würde.


    Fürs NES kenne ich keinen Browser, allerdings wäre da ja schon die Netzwerkanbindung eine Herausforderung, oder?


    Zitat von Rapid Eraser

    Hier mal beispielhaft Webseiten die mit domchristie.github.io/to-markdown/ nach Markdown konvertiert und mit markdownlivepreview.com/ gerendert wurden

    Ehrlich gesagt, ich finde die Ergebnisse gar nicht schlecht. Wenn ich das Ergebnis zügig gerendert auf einem C64-Bildschirm sehen würde, wäre ich schon nicht schlecht begeistert. Der Wikipedia-Artikel sieht z.B. super aus. Bei Forum64 und der CSDB müsste natürlich das Login-Formular benutzbar gemacht werden (dafür hatte ich ja Markdown-Fantasie-Code ersonnen) und beim Forum64 müssten die Bullet-Listen in Menüs umgebaut werden, um sie besser bedienbar zu machen und vor allem, um vertikalen Platz zu sparen (weniger Scrollerei).


    Zitat von Rapid Eraser

    Motivier mich mal.

    Ich will es versuchen, versprechen kann ich allerdings nichts. ;)


    Zitat von Rapid Eraser

    es werden alle <ul>...</ul> gelöscht (die sollen ja später an anderer Stelle als Menu auftauchen)

    Hier müsste man später etwas vorsichtig sein und versuchen, Menüs von echten Aufzählungslisten zu unterscheiden. 2 mögliche Kriterien fallen mir dazu ein: Entweder wandelt man nur Listen in Menüs um, deren Einträge mit Links, also <li><a href..., anfangen oder aber man fahndet in den Klassennamen im HTML nach dem Begriff "menu". Beides deutet zu fast 100% darauf hin, dass es sich bei der Liste um ein Menü handelt.


    Zitat von Rapid Eraser

    Wenn man ein solches Raster extrahieren könnte wäre das schoneinmal sehr viel Wert. Dann wüsste man wohl auch was in einer Zelle gerendert werden soll (Text oder Bild). Wie der Zelleninhalt gerendert werden soll (Schriftgröße/Farbe/etc) wäre dann hoffentlich auch nicht mehr das ganz große Problem und im Zweifelsfall Sache des Browsers.

    Das sähe natürlich toll aus. Ich habe allerdings die Befürchtung, dass man den C64 mit der Darstellung überfordern würde, lasse mich aber gerne eines Besseren belehren. Selbst wenn man auf dem C64 eine Art 80-Zeichen-Darstellung wählen würde, könnte man gerade mal so einen Viewport von 640 Pixeln Breite vorgaukeln (in Wirklichkeit ist es ja nur die Hälfte). Bei der geringen Größe schalten viele Webseiten ohnehin auf die mobile Darstellung um (wenn sie nicht ohnehin dynamisches "Responsive Design" verwenden) – auch das Forum64 tut das. Die rechte Randspalte wird also entweder entfernt oder ganz nach unten gepackt, in den Beiträgen die linke Randspalte mit den User-Infos jeweils über die Beiträge, usw. Es wird (und das ist sinnvoll bei kleinen Screens) alles auf eine Spalte herunter gebrochen, quasi etwas verLynxt.


    Die mehrspaltige Darstellung, wie du sie zeigst, könnte der C64 ja ohnehin nicht darstellen, selbst mit 80 Zeichen pro Zeile nicht.


    Dazu kommt, dass du entweder das CSS analysieren müsstest oder aber das DOM-Modell. Am Einfachsten ginge das wahrscheinlich, wenn man einen vollwertigen Browser (bzw. dessen Engine), wie Firefox oder Chrome (bzw. Gecko/Blink/Webkit) als Proxy-Basis verwenden würde. In wie weit das geht, weiß ich nicht – damit habe ich mich noch nie beschäftigt.


    Im Prinzip würde der C64 "nur" die mobile Darstellung einer Website erhalten und die ist, wie bei Lynx, meist auf eine einspaltige Darstellung beschränkt, nur hat man hier halt Menüs (die ich ja auch behalten möchte), Farbe (da hat der C64 halt hohe Einschränkungen) und Bilder (die ich beim C64 (wie oben gezeigt) lieber separat anzeigen möchte, wenn überhaupt).


    Zitat von Rapid Eraser

    Was meinst du, klingt das machbar? Oder kann man heutige Webseiten aufgrund von CSS/Javscript/Flash/etc. nicht mehr so "einfach" handhaben?

    Wie gesagt, Flash ist glücklicherweise so gut wie tot. JS wird ein C64 hingegen niemals können (was in über 90% der Fälle auch gar nicht nötig ist) und CSS muss man erst einmal interpretiert bekommen, was man sicher nicht händisch programmieren möchte (Lösung, wie gesagt: Browser-Engine). Das HTML ist hingegen immer einfacher geworden, weil eben alles außerhalb des nackten Inhalts ausgelagert wird. Nur willst du ja gerne mehr als den Inhalt zum C64 rüberretten – da müsste man dann wohl ans "Eingemachte".


    Zitat von Rapid Eraser

    Bei dieser Technik musste der c64 zwar kein http/html/markdown handhaben sondern vt100, aber abgesehen davon dürfte es doch ziemlich genau das sein was du suchst.

    Ich denke, hier liegt vielleicht der Casus Knacktus. Ich wäre mit einer performanten Textdarstellung einer Webseite auf dem C64 schon gar nicht so unzufrieden – und würde versuchen, von der Basis aus das Ergebnis immer weiter zu verbessern. Vielleicht liegen meine bescheidenen Vorstellungen daran, dass mir deine Erfahrung fehlt. Mein C64 war nie online und Terminalemulation (VT52/VT100) kenne ich nur von den UNIX-Rechnern in der Uni (vom macOS Terminalfenster mal abgesehen).


    Für mich ist es ein Unterschied, ob der C64 mittels Terminalemulation auf einem Server eingeloggt ist und dessen Bildschirmausgaben (bzw. die von Lynx) darstellt oder ob er selbsttätig HTML oder Markdown rendert. Vielleicht ist es mehr ein Gefühl als ein technischer Unterschied aber für mich ist es einfach was anderes. VT100 ist einfach nicht "echt", nicht nativ, so wie VICE auch nie einen echten C64 ersetzen kann – zumindest für mich nicht. Ein Proxy nimmt mir nicht die Illusion, dass der Rechner, mit dem ich surfe, die Arbeit verrichtet. Wenn jemand in Chrome "Datenreduktion" einschaltet, hat er nicht das Gefühl, dass sein Browser (trotz zwischengeschaltetem (mitlesendem) Google-Proxy) zum dummen Terminal wird.


    Außerdem wäre bei der Lösung "Lynx-auf-Server/VT100-auf-C64" diese auch gleichzeitig der Endpunkt. Ich will ja durchaus mehr und sehe die Text-Ausgabe von Lynx oder Kontiki nur als Ausgangsbasis für bessere Ergebnisse. VT100 wäre meines Erachtens auf ASCII beschränkt, ich möchte aber die ersten 256 Zeichen (Umlaute etc.) von UTF-8 darstellen können. VT100 kann keine Farbe, ich möchte aber im endgültigen Ausbau evtl. doch etwas Farbe haben. VT100 kann keine Grafik, ich möchte aber die Option haben, Bilder übertragen zu können. VT100 erlaubt es mir nicht, grafische Pulldown-Menüs oder Formulare vernünftig darzustellen, etc. Es gibt sicherlich weitere VT100-Einschränkungen, die eine Weiterentwicklung der C64-Web-Darstellung verhindern oder erschweren würden.


    Aber wenn VT100 am C64 schon lange erprobt ist und nur ich es nicht "aktiv kenne", dann sag mir doch mal für Tests: welche C64-Terminal-Emulation soll ich nehmen und wo steht der frei zugängliche Server mit Lynx, auf den ich mich einwählen muss? Denn was nicht unterschätzt werden darf bei meiner angedachten Lösung: Sie soll einfach einzurichten sein (wenn man wirklich Nutzer haben möchte). Bestenfalls soll man den C64-Browser herunterladen und nach Bekanntmachung der verwendeten Ethernet-Hardware und Eingabe von ein paar Netzwerkeinstellungen (besonders toll, aber wohl utopisch, wäre DHCP-Unterstützung) soll man schon im Netz surfen können. Ich möchte gerne die Hemmschwelle möglichst gering halten. Vielleicht bietet man sogar für jede Netzwerkhardware einen dafür optimierten Browser zum Download an, das spart Speicher und Konfigurations-Aufwand.


    Vielleicht kannst du ja meine Bedenken bzgl. VT100 ausräumen oder wahlweise meiner Gedankenrichtung folgen, dass ich schon mehr will, als nur Lynx auf dem C64. Nur hätte ich gerne erstmal "Lynx" (mit Proxy-Unterstützung für die Performance), um das Ergebnis dann sukzessive zu verbessern (Menüs, kompaktere Darstellung, ansehnliche Formulare, Font-Wechsel, Farbe, Bilder ...).

    Ein Nachtrag: Bei einer Terminalemulation (so simpel das Prinzip auch klingen mag) hätte man keinen Zugriff auf lokale Medien, sodass der Server z.B. für alle User die Bookmarks, Einstellungen etc. verwalten müsste. Auch Downloads auf Disk (ich hatte das ja für PRGs angedacht) wären nicht so einfach möglich.


    Bei der Recherche nach MSX-Browsern bin ich auf folgenden Link gestoßen: Flybrowser. Zitat: "A web browser for MSX-1. This was my graduation project from university. The architecture was based on a proxy which parses and compress the HTML and images, and send only compressed data to the MSX." Vielleicht sollte man sich mal mit dem brasilianischen Entwickler (Ricardo Bittencourt) unterhalten, auch wenn das Projekt von 2011 ist.

    Zitat von Retrofan

    Die mehrspaltige Darstellung, wie du sie zeigst, könnte der C64 ja ohnehin nicht darstellen, selbst mit 80 Zeichen pro Zeile nicht.

    Doch bzw. wieso meinst du nicht?

    Ich bin für Screenshots eines Browserfensters in 320x200 px und Umrechnung in c64 (oder andere) Grafikformate.


    Ich fürchte einfach, dass der Großteil der Seiten einfach inhaltlich schon so umfangreich sind, dass sie sich kaum sinnvoll am c64 lesen lassen. Das macht man 4-6 mal aus Neugierde und dann ist es zu mühsam.


    ...klar habe ich in den 80ern stundenlang Texte bei 300 Baud gelesen. Aber da gab es nicht so viele "Zusatzinformationen".


    Klingt jetzt negativ, oder?
    Entwerf doch mal eine "Demo" für den c64, zum heißmachen an realer Maschine.. :D

    Zitat von Chagizzz

    Ich bin für Screenshots eines Browserfensters in 320x200 px

    Ich bin mir recht sicher, dass das Ergebnis enttäuschen wird. Aber wer immer sich auch an die Programmierung wagen sollte, kann das gerne ausprobieren. Ich bin auch nicht allwissend und vielleicht ist die Lösung ja doch zielführend. Bis ich es sehe, bleibe ich aber sehr skeptisch.


    Zitat von Chagizzz

    Ich fürchte einfach, dass der Großteil der Seiten einfach inhaltlich schon so umfangreich sind, dass sie sich kaum sinnvoll am c64 lesen lassen. Das macht man 4-6 mal aus Neugierde und dann ist es zu mühsam.

    Es gibt genügend Leute, die C64-Diskmags oder andere Sachen auf dem 1084 lesen. Man wird es keine 8 Stunden am Tag tun wollen – aber 10 oder 20 Minuten am Stück (bzw. am Tag) sollten wohl drin sein, ohne sich die Augen zu verderben.


    Zitat von Chagizzz

    ...klar habe ich in den 80ern stundenlang Texte bei 300 Baud gelesen

    Ich glaube, dass man heute mehr als 300 BAUD durch die Leitung bekommt – ist ja kein Modem, sondern LAN/DSL. Wieviel genau der C64 schafft (1200+?), habe ich aber noch nicht herausbekommen. Und die "Zusatzinfos" wollen wir ja vorher möglichst eindampfen.


    Zitat von Chagizzz

    Entwerf doch mal eine "Demo" für den c64, zum heißmachen

    Mehr als die schon vorhandenen Mockups kann ich nicht beisteuern. Auch für eine Demo würde ich einen Programmierer benötigen.

    Zitat von Retrofan

    Ich glaube, dass man heute mehr als 300 BAUD durch die Leitung bekommt – ist ja kein Modem, sondern LAN/DSL. Wieviel genau der C64 schafft (1200+?), habe ich aber noch nicht herausbekommen. Und die "Zusatzinfos" wollen wir ja vorher möglichst eindampfen.

    Naja, das WLAN Modem soll 9600 Baud schaffen. Das wäre aber wohl nur für Bilder o.ä. interessant, da ein paar Zeilen Text selbst mit 1200 Baud schon schnell genug da sind - auch wenn zusätzlich ein paar Hintergrundinformationen übertragen werden müssten (Menüs, Links).

    Zitat von Retrofan

    Mehr als die schon vorhandenen Mockups kann ich nicht beisteuern. Auch für eine Demo würde ich einen Programmierer benötigen.

    Naja, mich würde eben mal interessieren, wie sich verschiedene Menüs darstellen lassen und das ganze auch noch in vertretbarer Geschwindigkeit reagiert / öffnen. Grundsätzlich kann man ja möglicherweise die ersten vorhandenen Menüs auch mit Tastenkombinationen belegen (weiß nicht, ob das schon so gesagt wurde). Weiß auch nicht, ob schon mal über Menüs mit Untermenüs gesprochen wurde?! Also z.B. wie hier im Forum die Menüleiste.



    Kenne mich leider mit Grafikformaten nicht wirklich aus... :(

    Zitat von Chagizzz

    das WLAN Modem soll 9600 Baud schaffen. Das wäre aber wohl nur für Bilder o.ä. interessant

    9600 BAUD sind doch schon eine Ansage. Wenn der C64 das auch entsprechend verarbeiten könnte, dann wäre ein Multicolor-Bild doch in rund 8 sek. geladen oder ein 16KB-PRG in 15 sek. Das würde sich schon ganz flott anführen – im Rahmen dessen, was man vom C64 so kennt.


    Zitat von Chagizzz

    auch wenn zusätzlich ein paar Hintergrundinformationen übertragen werden müssten (Menüs, Links)

    Menüs wären ja nur Bullet-Listen, wie in HTML (nur mit weniger Code). Links könnte man, wie schon von mir vorgeschlagen, verkürzen – dann müsste der Proxy sie nur wieder auflösen, sobald man einen Anklickt.


    Zitat von Chagizzz

    Naja, mich würde eben mal interessieren, wie sich verschiedene Menüs darstellen lassen und das ganze auch noch in vertretbarer Geschwindigkeit reagiert / öffnen.

    Performance: Guck dir GEOS an – und da kann man sicherlich noch etwas optimieren. Von der Optik her: Guck die verschiedenen "Hamburger"-Menüs in iOS/Android an.


    Zitat von Chagizzz

    Weiß auch nicht, ob schon mal über Menüs mit Untermenüs gesprochen wurde?! Also z.B. wie hier im Forum die Menüleiste.

    Untermenüs sind, technisch gesehen, geschachtelte Bullet-Listen, also kein Hexenwerk . Darstellung: Siehe GEOS (oder wie man will, das ist Sache des Browsers)

    Zitat von muhahaha

    Hier einige Screenshots in 320 x 200 zur Ansicht

    Wie von mir erwartet: Unlesbar – und die sind sogar noch kantengeglättet, was der C64 in Hires nicht tun könnte. Das ist halt kein zielführender Ansatz – außer es kommt noch das Kaninchen aus dem Hut gesprungen.

    Zitat von Retrofan

    Ich glaube, dass man heute mehr als 300 BAUD durch die Leitung bekommt – ist ja kein Modem, sondern LAN/DSL. Wieviel genau der C64 schafft (1200+?), habe ich aber noch nicht herausbekommen. Und die "Zusatzinfos" wollen wir ja vorher möglichst eindampfen.

    Das "Comet" Modul von goog (commodoreserver.com) überträgt Daten mit 38.4K baud. Ich besitze selbst eines und es funktioniert einwandfrei um d.64 Images vom Server zu laden, zu chatten oder multiplayer Games auf dem C64 zu zocken. Goog arbeitet gerade an einem Nachfolgemodell, ich werde ihn mal anchatten um zu sehen was der Stand der Dinge ist.


    Zum Rest der Debatte kann ich nur von der Seite eines regelmäßigen Web-Users am C64 etwas beitragen. Mir würde ein reiner Textbrowser völlig ausreichen. Wenn man Contiki um Umlaute und Eingabeformulare erweitern würde, wärs sehr ok. (Siehe weiter vorne im Thread mein Video) Mehr würde mich gar nicht so sehr interessieren. Ich finde die Mockups interessant, finde aber dass die Lesbarkeit leidet. 40 Zeichen im klassischen Font würden nicht nur wertvollen Speicher sparen und das Original-Feeling vermitteln, es wäre auch praktikabel. Wenns wie der Teletext aussehen würde, wäre es schon das non plus ultra. Bin da ein Vertreter der "Weniger ist Mehr"-Fraktion. Projekte wie dieses scheitern oft auch an den etwas zu hoch geschraubten Erwartungshaltungen.

    Zitat von Rotzwald

    Das "Comet" Modul von goog (commodoreserver.com) überträgt Daten mit 38.4K baud

    Sowas würde uns natürlich sehr entgegen kommen. Da rauschen die Daten ja nur so in den C64. Rund 50$ plus Versand aus den USA?


    Zitat von Rotzwald

    Goog arbeitet gerade an einem Nachfolgemodell, ich werde ihn mal anchatten um zu sehen was der Stand der Dinge ist.

    Ja, das würde mich durchaus auch interessieren. Wobei man heutzutage wahrscheinlich noch was billigeres bauen könnte – vielleicht bei Performance-Abstrichen? Der Servant64 mit USB und LAN kostet rund 20/25€ für die Hardware – da müsste aber erst noch die Software aufgebohrt werden – bislang wird, glaube ich, die LAN-Schnittstelle noch gar nicht genutzt.


    Zitat von Rotzwald

    Mir würde ein reiner Textbrowser völlig ausreichen. Wenn man Contiki um Umlaute und Eingabeformulare erweitern würde, wärs sehr ok.

    In die Richtung soll die hier angedachte Browser/Proxy-Kombination ja auch erstmal gehen. Ich glaube hingegen nicht, dass jemand Contiki patchen wird. In erster Linie geht es bei diesem Browser und dem dazu gehörenden Proxy um schnelle Textdarstellung (UTF-8, also mit Umlauten), funktionierende Formulare (Interaktion) und das alles mit möglichst wenig Overhead (Speicherersparnis, Performance)


    Zitat von Rotzwald

    Ich finde die Mockups interessant, finde aber dass die Lesbarkeit leidet. 40 Zeichen im klassischen Font würden nicht nur wertvollen Speicher sparen und das Original-Feeling vermitteln, es wäre auch praktikabel.

    Wenn du meine Mockups richtig anguckst, wirst du feststellen, dass die Anzahl der Zeichen pro Zeile nicht fest ist, sondern über den Font definiert wird. Wer sich einen 40-Char-Font lädt, der bekommt halt eine 40-Zeichen-Darstellung – wer möchte, kann aber auch mehr (60 oder 80) Zeichen pro Zeile bekommen, je nach Lust und Laune, bzw. Augen und Bildschirm. Die Bitmap-Darstellung kostet zwar 8 KB mehr RAM aber man wird trotzdem mehr Inhalt von einer Webseite am Stück laden können, als es Contiki jetzt tut. Und man bekommt frei Haus besser lesbare Links, gut als solche erkennbare Formulare, platzsparende Menüs (statt Link-Wüsten) und später vielleicht noch mehr Features – wenn der Programmierer bock darauf hat.


    Zitat von Rotzwald

    Projekte wie dieses scheitern oft auch an den etwas zu hoch geschraubten Erwartungshaltungen.

    Manchen gehen meine Vorstellungen ja noch nicht weit genug – sie wollen komplette Desktop-Webseiten auf 320 Pixeln Breite darstellen, mehrspaltige Original-Layouts erhalten und noch mehr. Ich sage dazu nur: Wenn die jemanden damit überzeugen können, die Sache anzugehen und zu programmieren, soll es mir recht sein. Ich denke, dass meine eigenen Wunschvorstellungen sehr realistisch und gut umsetzbar sind. Aber auch für diesen Ansatz habe ich leider (noch) keinen Entwickler zur Hand. Es bleibt das Prinzip Hoffnung.