Webbrowser für 8-Bit-Rechner

  • muhahaha schrieb:

    Hier einige Screenshots in 320 x 200 zur Ansicht:
    Danke, aber ich dachte eher an eine Browserauflösung von 320x200. Davon dann einen Screenshot. Das das so unlesbar wird, war zu erwarten.
    Je nach Schriftgröße könnte das etwa so aussehen:


    Oder in der mobilen Variante (wenn vorhanden):


    Retrofan schrieb:

    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?
    Kaufen, kaufen.
    carrier lost...
  • Bei eurem Browser-Fachgerede komme ich eh nicht mit, aber:

    Retrofan schrieb:

    Weil die Auflösung dafür zu gering ist.
    Ja, eingesehen. Stimmt leider.

    Rapid Eraser schrieb:

    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:
    [Bild siehe Beitrag #167]

    Der Screenshot vom Forum64 macht das Problem des Projektes richtig klar und quasi auch (fast) zunichte.

    Die Forum64-Seite müsste bei der kleinen Schriftart vertikal in mindestens zwei Teile zerhackt werden, um sie vernünftig darstellen zu können. Eher sogar noch in drei.

    Retrofan schrieb:

    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
    So 60-65 Zeichen ist optisch noch eine gesunde Darstellung, darüber würde ich nicht gehen. Für das Programm gehen (mindestens) 16K drauf. Pro vorgehaltener Seite nochmal 8K + 2K (für den Text-/Steuerzeichen-Zwischenspeicher)=10K. Bei zweiteiliger vertikaler Trennung könnte man dabei zumindest noch zwei (folgende/vorhergehende) Seiten im Speicher halten. Bei drei wird das nix mehr. Idealerweise sollten die vorhergehende und folgende Seite im Speicher sein (=min. 40K). Bei vertikal zweiseitig ginge das ja wohl noch. Hmm...
    Read'n'Blast my jump'n'stop-text-sprite-scroller Select A Move

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?
  • Retrofan schrieb:

    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.
    [...]
    Vielen Dank für den Überblick über die verschiedenen Systeme. :) Ich habe auch noch etwas herumgesucht und bin dabei über - hoffentlich - interessante Paper gestolpert wie Power Browser: Efficient Web Browsing for PDAs. Gelesen habe ich sie zwar noch nicht, aber das steht ziemlich weit oben auf meiner Todo-Liste.

    Retrofan schrieb:

    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. [...] Die mehrspaltige Darstellung, wie du sie zeigst, könnte der C64 ja ohnehin nicht darstellen, selbst mit 80 Zeichen pro Zeile nicht.
    Hmm, da möchte ich erneut auf die Screenshots von Links verweisen. Die sehen für mich ehrlich gesagt ziemlich vielversprechend aus. Überfordern würde man den C64 wohl höchstens insofern als das der Speicher für eine einzelne Webseite einfach nicht ausreicht. Aber das wäre ein grundsätzliches Problem.
    Und ob der jeweilige Browser Gebrauch von den Boxen macht oder ob er sie ignoriert um einfach alles untereinander darzustellen - das können wir ruhig ersteinmal dahingestellt lassen. Persönlich finde ich allerdings schon, daß das System das Potential haben sollte um einiges mehr als nur PETSCII anzubieten.

    Retrofan schrieb:

    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.
    Gehen wird das sicherlich, und es bietet ja einige Vorteile. Es bedeutet jedoch auch eine nicht unerhebliche Last für den Proxy. Aber das ist wieder ein anderes Thema. Sooo furchtbar viele User würde ich zunächst nicht erwarten, da halte ich die Verwendung von Webkit&Co durchaus für eine sehr interessante Alternative.

    Retrofan schrieb:

    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.
    Genau, ich schätze auch das es weniger am praktischen Nutzen sondern eher "am Gefühl" hängen wird. Aber ob das alleine den Aufwand rechtfertigt? Ich jedenfalls hätte damals "das Gefühl" beim Ascii-Browsen sofort gegen eine komfortablere Lösung eingetauscht... :P

    Retrofan schrieb:

    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?
    Frei zugängliche Server mit Shell-Accounts wird's vermutlich nirgends geben. Vielleicht betreibt PING sowas noch, doch auch da wirst du dich ersteinmal anmelden müssen. Aber google mal nach "tcpser", damit kann man glaube ich auf seinem eigenen PC "Mini-Internet" spielen und mit Vice in seinem eigenen Web surfen. :D
    Als Terminalprogramme taugt dabei so ziemlich alles. Spontan erinnere ich mich noch an Novaterm, CCGMS und Desterm,

    Retrofan schrieb:

    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.
    Stimmt. Aber das haben wir damals trotzdem irgendwie gebacken bekommen. Wo die Bookmarks gespeichert sind ist eigentlich egal, und surfen+downloaden gleichzeitig will man sowieso nicht... Zur Not gab es unter Unix auch immer noch das Programm "screen", mit dem man mehrere Shells gleichzeitig fahren konnte (naja, Multitasking halt; alle Shells liefen parallel und man konnte per Hotkey auswählen welche Shell gerade angezeigt werden sollte).

    enthusi schrieb:

    Mit Interlace? ;)
    Oder man stellt sich noch'n zweiten Monitor daneben. ^^

    Chagizzz schrieb:

    Ich bin für Screenshots eines Browserfensters in 320x200 px und Umrechnung in c64 (oder andere) Grafikformate.
    Ich glaube auch, das ginge am einfachsten. (Wir dürfen Retrofan dann aber nicht verraten das es nicht der C64 selber ist, der die Bitmap rendert. :D )
  • Nochmal zum Thema Markdown:

    Ich war gestern mal auf dieser Seite: fuckyeahmarkdown.com/

    Diese kann beliebige Seiten in Markdown umrechnen. Von den 6-7 Seiten, die ich spontan mal probiert habe, war etwas die Haelfte unbrauchbar. Klar kann das jetzt auch an dem Konvertierungs-Algorithmus liegen, aber ich glaube, es trifft einfach zu, was ich schon weiter vorne versucht habe zu sagen: Webseiten sind einfach viel zu unterschiedlich und koennen viel zu flexibel gestaltet sein, als dass man einen verlaesslichen Konvertierungs-Algorithmus schreiben koennte, mit dem man wirklich vernuenftig etwas anfangen kann.

    Wo ich evtl. noch einen Lichtblick drin sehe: Viele Seiten heutzutage basieren ja auf den gleichen Frameworks wie WordPress usw, vielleicht kann man zumindest hier einen Ansatz finden, um diese Seiten vernuenftig darstellen zu koennen. Trotzdem gibt es aber immer noch eine gewisse Anzahl an Webseiten die anders aufgebaut sind, und gerade auch im Retro-Bereich duerfte das zutreffen (lemon64.com hat in dem Teil da oben z.B. ueberhaupt nicht funktioniert, denn die Seite verwendet Frames). Auch wird es unmoeglich sein, jemals alle Seiten zu testen, daher weiss man auch nie, wann man damit "fertig" ist.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • Hexworx schrieb:

    [Bild siehe Beitrag #167]

    Die Forum64-Seite müsste bei der kleinen Schriftart vertikal in mindestens zwei Teile zerhackt werden, um sie vernünftig darstellen zu können. Eher sogar noch in drei.
    Ich verstehe deine Überlegung hier nicht. Ich gehe weiterhin nicht davon aus, dass Bitmaps übertragen werden. Eine Webseite ist so lang, wie sie lang ist – das können auch mal 20 Bildschirmseiten sein. Diese Seite ist auf meinem Rechner (etwas zusammengeschobenes Fenster) auch 7 Seiten lang – das ist beim WWW nun mal so und deshalb käme ich auch nicht auf die Idee, die Inhalte fest auf "Screens" aufzuteilen. Je nach Ausgabe-Gerät könnten das unnötig viele sein, wenn man sich auf ein (zu kleines) Raster festlegen würde.

    In dem F64-Beispielbild werden hauptsächlich Link-Wüsten angezeigt, die ich ja zu Klapp-Menüs umwandeln würde, damit man schon sehr früh auf der Seite, und nicht erst nach langem gescrolle, Inhalte sehen kann.

    Hexworx schrieb:

    So 60-65 Zeichen ist optisch noch eine gesunde Darstellung, darüber würde ich nicht gehen.
    Wie gesagt, das soll sich jeder selbst aussuchen. Ein Vorteil bei der Browser-Lösung gegenüber so Konzepten, wie BTX/VT. Ich finde die 60-Zeichen-Darstellung auch sehr smart und noch besser lesbar als die 40-Zeichen-Darstellung. Aber einige fanden auch die 80-Zeichen-Darstellung noch gut lesbar. Jeder, wie er mag.

    Hexworx schrieb:

    Für das Programm gehen (mindestens) 16K drauf. Pro vorgehaltener Seite nochmal 8K + 2K (für den Text-/Steuerzeichen-Zwischenspeicher)=10K. Bei zweiteiliger vertikaler Trennung könnte man dabei zumindest noch zwei (folgende/vorhergehende) Seiten im Speicher halten. Bei drei wird das nix mehr. Idealerweise sollten die vorhergehende und folgende Seite im Speicher sein (=min. 40K). Bei vertikal zweiseitig ginge das ja wohl noch. Hmm...
    Ich rechne auch mal rund 16 KB für den Markdown-Browser. 9 KB gehen für den Bildschirmspeicher drauf, rund 2 KB je Font, der Rest (TCP/IP-Stack in der Hardware vorausgesetzt) kann für den MD-Quelltext der Webseite vorgehalten werden. Bei dieser Speicheraufteilung würde ein Sprung auf die nächste vertikale Bildschirmseite (man könnte aber auch beispielsweise nur halbseitenweise hüpfen, um den Lese-Anschluss nicht zu verlieren) diese dann aus dem RAM gerendert werden. Das wäre schon mal deutlich schneller als bei Contiki, der anscheinend beim Umschalten schon aus dem Netz nachladen muss. Alles, was noch nicht ins C64-RAM passt, würde vom Proxy vorgehalten und bei Bedarf nachgeladen werden.

    Man könnte aber auch schon etwas mehr Screen "vorrendern", damit man ein Bitmap-Scrolling realisieren kann. Bitmap-Scrolling ist nicht utopisch, wie man an einigen wenigen Spielen sehen kann, die das (im Multicolor-Mode) tun. Man muss halt wissen, ob man den Speicher dafür opfern möchte. Allerdings ist es auch so, dass wieder die flexible Proxy/Browser-Lösung erlaubt, dass sich "jeder" den Browser programmieren könnte, den er gerne hätte. Der Proxy würde liefern, was immer der Browser haben möchte: Nur Text (beliebige Zeichen-pro-Zeile), auf Wunsch Farbe oder sogar Bilder. Die Lösung wäre flexibel und erweiterbar.
  • Voellig andere Idee: Wie waere es, eine art Standard fuer minimale Webseiten zu etablieren, die hauptsaechlich dafuer gedacht sind, C64-Themen und insbesondere z.B. PRGs zu hosten? Ich weiss, weiter vorne wurde sowas in der Art mal angesprochen und direkt auch als schlechte Idee abgestempelt - was durchaus gerechtfertigt ist. Aber andersherum betrachtet: Da die meisten C64-Fans, oder zumindest diejenigen Leute, die C64-Seiten betreiben, Enthusiasten sind, koennte man sich vorstellen, dass viele eine solche Seite anbieten wuerden, wenn der Standard sehr simpel umzusetzen ist und es einen echten Mehrwert bietet.

    Ich persoenlich koennte mir z.B. vorstellen, eine Mini-Website fuer meine Spiele zu machen, fuer jedes Spiel eine einzelne, mit einer kurzen Beschreibung und einem Download fuer das PRG. Meine tatsaechliche Seite geht ja eigentlich schon sehr in diese Richtung. Aber das waere dann eine speziell fuer den C64 angepasste Seite. So wie man heutzutage auch Apps runterlaedt, um echte Webseiten NICHT benutzen zu muessen, z.B. eBay-App, amazon-App, usw. Ich stelle mir diese Mini-Seiten vor wie eine Art Wikipedia-Artikel pro Spiel oder Programm usw. Und sie sollten auch sehr simpel sein, also so wie WAP usw., ohne allzu viel Schnickschnack.

    Damit haette man zwar nicht die Moeglichkeit, im gesamten Web zu surfen, aber ich sehe einen konkreten Mehrwert dadurch, dass man direkt fuer jedes downloadbare Programm eine kleine Seite oeffnen kann und dieses direkt downloaden kann. Natuerlich koennte man auch fuer Geraete wie SD2IEC kleine Info-Seiten machen usw, aber fuer Programme sehe ich da den groessten Vorteil. Denn da ist auch der Use-Case am direktesten und sinnvollsten. Ob man auf dem C64 surfen moechte, ist ja wie man schon in den Diskussionen hier sieht fraglich, aber dass man vielleicht direkt Programme herunterladen moechte, das sehe ich durchaus als einen validen Anwendungsfall.

    Wenn sich so etwas etablieren wuerde, dann koennte man auch fuer einzelne Seiten wie csdb.dk oder gamebase64.com oder auch das C64-Wiki einen Konverter schreiben, oder die Betreiber dieser Seiten wuerden vielleicht sogar ihren eigenen schreiben. Somit koennte man dann auf dem C64 diejenigen Seiten bequem anschauen, bei denen man den vermutlich direktesten Nutzen haette. Und daher kann ich mir auch vorstellen, dass Leute einen Sinn dahinter sehen, solch eine Mini-Seite anzubieten.

    EDIT: Die Existenz eines solchen Systems (eine Art "C64-Netz") wuerde vielleicht auch wiederum einige davon ueberzeugen, sich eine Netzwerk-Loesung fuer den C64 anzuschaffen.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • @Rapid Eraser: Dir antworte ich später, weil das wahrscheinlich etwas aufwendiger wird.

    ZeHa schrieb:

    Von den 6-7 Seiten, die ich spontan mal probiert habe, war etwas die Haelfte unbrauchbar. Klar kann das jetzt auch an dem Konvertierungs-Algorithmus liegen, aber ich glaube, es trifft einfach zu, was ich schon weiter vorne versucht habe zu sagen: Webseiten sind einfach viel zu unterschiedlich und koennen viel zu flexibel gestaltet sein, als dass man einen verlaesslichen Konvertierungs-Algorithmus schreiben koennte, mit dem man wirklich vernuenftig etwas anfangen kann.
    Ich sehe das durchaus anders. Man darf nicht den Fehler machen, das Ergebnis eines einzelnen Konvertierungstools für die eigenen Entscheidungen zugrunde zu legen. Ein gutes Ergebnis wird nur erzielt werden, wenn man die Konvertierung in mehrere Schritte aufteilt. Die Umwandlung von schon zuvor simplifiziertem HTML (z.B. über Lynx) zu Markdown ist der letzte Schritt, um damit den Code nochmal etwas kompakter zu bekommen. Das ist nur ein Vorschlag meinerseits, um möglichst viel Quelltext in den C64-Speicher zu bekommen. Wenn das MD-Konzept scheitern sollte, dann nimmt man halt HTML/WML – das braucht halt ein wenig mehr RAM aber Contiki zeigt, dass der C64 auch damit fertig werden würde.

    ZeHa schrieb:

    Wo ich evtl. noch einen Lichtblick drin sehe: Viele Seiten heutzutage basieren ja auf den gleichen Frameworks wie WordPress usw
    Das weiß ich natürlich auch und das habe ich die ganze Zeit im Hinterkopf. Deshalb ist das Basteln an einem möglichst guten Konverter ja auch kein unmögliches Unterfangen. Wenn man nur eine Handvoll Frameworks testet und dem Proxy/Konverter damit brauchbare Ergebnisse entlocken kann, hat man schon 50 – 70% des Internets erschlagen. Alleine WordPress stellt 30 – 50% (je nach Zählweise) aller CMS-basierten Seiten im Internet. Und dessen Blog-optimierter Code ist wirklich sehr einfach zu parsen.

    ZeHa schrieb:

    lemon64.com hat in dem Teil da oben z.B. ueberhaupt nicht funktioniert, denn die Seite verwendet Frames
    Wer heute noch Frames oder Flash verwendet, dem kann ich echt nicht helfen, der hat die letzten 15 jahre geschlafen. Dann wird die eine Website halt nicht auf dem C64 dargestellt.

    ZeHa schrieb:

    Auch wird es unmoeglich sein, jemals alle Seiten zu testen, daher weiss man auch nie, wann man damit "fertig" ist.
    Wie oben beschrieben: ALLE Seiten muss man gar nicht testen. 5 Forensoftwares und 5 CMS – und schon kennst du 80% des Netzes. Dann noch die Top-10-IT-Nachrichtenseiten und ein paar wichtige Exoten, dann bist du auf einem guten Weg. Es kann auch bei aktuellen Systemen und Browsern immer mal sein, dass eine Seite nicht richtig funktioniert – Nutzer von Mobil-Browsern werden das evtl. schon mal erlebt haben.

    Ich gehe auch nicht davon aus, dass man sowas programmiert und nach 6 Wochen ein Ergebnis hat, dem man die Versionsnummer "1.0 Final" gibt und nie wieder anfasst. Wie das Internet, wie HTML (jetzt schon Version 5), wie CSS, so sollte auch der angedachte Proxy natürlich wachsen und sich weiter entwickeln. Wenn mehrere Nutzer feststellen, dass eine bestimmte Website nicht funktioniert, dann können Sie ja eine Rückmeldung geben (vielleicht baut man dafür sogar einen Button ins Browser-Interface) und dann guckt sich das Proxy-Team (im Optimalfall wäre es ein Team) das Problem an und kann ja evtl. eine Lösung finden. Und irgendwann werden dann halt aus 90% lauffähigen Seiten 95%.
  • Retrofan schrieb:

    ZeHa schrieb:

    lemon64.com hat in dem Teil da oben z.B. ueberhaupt nicht funktioniert, denn die Seite verwendet Frames
    Wer heute noch Frames oder Flash verwendet, dem kann ich echt nicht helfen, der hat die letzten 15 jahre geschlafen. Dann wird die eine Website halt nicht auf dem C64 dargestellt.
    Grundsaetzlich bin ich da voll bei Dir. Aber es geht hier im Beispiel um die Seite lemon64.com, eine Seite, die durchaus moeglicherweise von dem ein oder anderen C64-User aufgerufen werden will. Die Seite c64.com hat ebenfalls Frames. Und ich wette, es gibt noch zig andere retro-bezogene Seiten, die nicht auf dem neuesten Stand der HTML-Technik sind. Da einfach zu sagen "dann wird die halt nicht auf dem C64 dargestellt" finde ich in diesen konkreten Faellen ziemlich kurzsichtig ;)
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • ZeHa schrieb:

    Wie waere es, eine art Standard fuer minimale Webseiten zu etablieren, die hauptsaechlich dafuer gedacht sind, C64-Themen und insbesondere z.B. PRGs zu hosten? Ich weiss, weiter vorne wurde sowas in der Art mal angesprochen und direkt auch als schlechte Idee abgestempelt - was durchaus gerechtfertigt ist.
    Meines Erachtens bleibt es eine schlechte Idee, weil sie eben einfach kein bisschen universell ist. Klar, als Notfall-Lösung immer noch besser als nichts – aber es kann nicht mal mit Contiki mithalten – und das gibt es schon.

    Neben der Tatsache, dass man Anpassungen für jede einzelne Website vornehmen müsste, existiert auch das Problem (wenn die Anpassungen auf Domainseite erfolgen sollen), dass oft fertige Frameworks verwendet werden, auf deren Output man nur schwer Einfluss hat. Dieses Forum z.B. nutzt die Burning-Board Forums-Software und ich hätte keine Lust, dort im Code herumzufrickeln, um C64-spezifische Tags unterzubringen. Und beim nächsten Update wäre ohnehin alles verloren. Und bei Client-basierter Anpassungen wäre man in der App-Falle, in der man bei jeder Änderung der Website Gefahr laufen würde, dass die zu Webseite passende C64-"App" nicht mehr liefe.

    Und PRG-Downloads kommen in meinem Proxy/MD-Browser-Konzept auch vor. Das ist überhaupt kein Hexenwerk bei einer Browser-Lösung.

    Wie gesagt: Vielleicht besser als nichts – von daher: Wenn ein Programmierer das machen möchte, dann los. Ich persönlich habe die Befürchtung, dass das eine Sackgasse wäre (aber tolle Ergebnisse können mich immer umstimmen).
  • ZeHa schrieb:

    Grundsaetzlich bin ich da voll bei Dir. Aber es geht hier im Beispiel um die Seite lemon64.com, eine Seite, die durchaus moeglicherweise von dem ein oder anderen C64-User aufgerufen werden will. Die Seite c64.com hat ebenfalls Frames. Und ich wette, es gibt noch zig andere retro-bezogene Seiten, die nicht auf dem neuesten Stand der HTML-Technik sind. Da einfach zu sagen "dann wird die halt nicht auf dem C64 dargestellt" finde ich in diesen konkreten Faellen ziemlich kurzsichtig
    Naja, lemon64.com aus den Frames zu befreien ist ja nun auch nicht so der erhebliche Aufwand.

    Aus eins mach drei, eine ist Chat und kann ignoriert werden. Eine ist die Navigation und kann direkt als Menu vor die dritte gesetzt werden.
    Sicherlich nicht mehr aufwand, als das Menü aus dem Quelltext einer Seite zu suchen und aufzubereiten.
    carrier lost...
  • @Retrofan

    Ich verstehe Deine Sichtweise und sehe das teilweise auch selbst so. Aber ich sehe das eben nun von einer voellig anderen Betrachtungsweise heraus. Universell ist schoen und gut, aber ich stelle mir vor, wenn ich allein die csdb.dk und c64.com auf einem C64 aufrufen koennte, in einer gut bedienbaren Form (die sich nicht zwingend am Layout der Original-Seite orientieren muss), dann haette ich einen massiven Use-Case abgedeckt, naemlich koennte ich dann direkt per C64 Software runterladen und auf meinem SD2IEC speichern, ohne dass ich das erst auf meinem PC machen muss und dies dann auf die SD-Karte uebertragen muss usw. Auch koennte ich somit immer wieder mal schauen, was es so neues gibt, usw.

    Dafuer hat man halt nicht die Moeglichkeit, alle anderen Webseiten anzuschauen, aber die (berechtigte) Frage ist ja auch, wer moechte das ueberhaupt. Wenn ich mir allein schon vorstelle, ich wuerde die oben genannten Seiten mit einem "universellen Browser" auf dem C64 lesen, da glaube ich, dass ich extrem leiden muesste, bis ich endlich an einen Download gelange. Erstmal rumscrollen, suchen, usw, dann gehen irgendwelche Formulare nicht richtig, oder ich bin mit der Bedienung des Browsers nicht gut vertraut etc, dann lade ich die Datei runter und es ist womoeglich ein ZIP, wie entpacke ich das dann usw, ich glaube dass ich da nicht wirklich Lust drauf haette. Ich komme mir ja jetzt zum Teil schon wie ein Computer-Legastheniker vor, wenn ich so manche Seite auf meinem HANDY bedienen moechte (was technisch sicherlich weitaus fortgeschrittener ist als jeder C64-Browser es jemals sein wird). Gaebe es nun aber eine Art "C64-Web" wie oben beschrieben, dann waere alles darauf ausgelegt, dass dieser Use-Case reibungslos funktioniert. Zwar nur mit einer handvoll Seiten, aber zumindest mit den Seiten, die ich noch am ehesten auf einem C64 ueberhaupt besuchen moechte.

    Daher ist es zwar richtig, dass das nie und nimmer universell sein wird, aber die Frage ist eher, wie universell muss es ueberhaupt sein, denn wie wuerde man es letztendlich ueberhaupt nutzen wollen. Und da sehe ich eben persoenlich deutlich mehr Nutzen in einer solchen Loesung als in einem universellen Browser.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • Chagizzz schrieb:

    ZeHa schrieb:

    Grundsaetzlich bin ich da voll bei Dir. Aber es geht hier im Beispiel um die Seite lemon64.com, eine Seite, die durchaus moeglicherweise von dem ein oder anderen C64-User aufgerufen werden will. Die Seite c64.com hat ebenfalls Frames. Und ich wette, es gibt noch zig andere retro-bezogene Seiten, die nicht auf dem neuesten Stand der HTML-Technik sind. Da einfach zu sagen "dann wird die halt nicht auf dem C64 dargestellt" finde ich in diesen konkreten Faellen ziemlich kurzsichtig
    Naja, lemon64.com aus den Frames zu befreien ist ja nun auch nicht so der erhebliche Aufwand.
    Aus eins mach drei, eine ist Chat und kann ignoriert werden. Eine ist die Navigation und kann direkt als Menu vor die dritte gesetzt werden.
    Sicherlich nicht mehr aufwand, als das Menü aus dem Quelltext einer Seite zu suchen und aufzubereiten.
    Das sind aber Dinge, die Du als Mensch zwar machen kannst, aber schreib mal ein Programm das selbstaendig erkennt, welche Frames wichtig sind und welche nicht. Klar koennte man auch einen Konverter schreiben, der spezielle Seiten gesondert behandelt, aber es geht ja hier um eine allgemeingueltige Loesung.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • ZeHa schrieb:

    EDIT: Die Existenz eines solchen Systems (eine Art "C64-Netz") wuerde vielleicht auch wiederum einige davon ueberzeugen, sich eine Netzwerk-Loesung fuer den C64 anzuschaffen.
    Das sehe ich allerdings bei jeder Lösung, die dem C64 einen angenehmen Web-Zugriff erlaubt. Und zwar um so mehr, je mehr Inhalte (vielleicht sogar 95% des Webs?) aufgerufen werden können.

    ZeHa schrieb:

    Grundsaetzlich bin ich da voll bei Dir. Aber es geht hier im Beispiel um die Seite lemon64.com, eine Seite, die durchaus moeglicherweise von dem ein oder anderen C64-User aufgerufen werden will.
    Das mag schon sein. Nur sind halt Frames eine wirklich schwierige Angelegenheit – schon zu Zeiten, als man sie noch eingesetzt hat. Ich weiß echt nicht, wie man die ohne Spezialbehandlung sauber darstellen will, egal mit welcher Technik (eine Videotext-Technik oder WAP wäre hier noch viel aufgeschmissener). Das liegt halt daran, dass es sich nicht um EIN HTML-Dokument handelt, sondern um mehrere, die komplett unabhängig von einander sind und nur mit dem Frameset parallel dargestellt werden. Das ist maximaler Pain-in-the-ass.

    Es kommt hinzu, dass lemon64 so ziemlich alles falsch macht, was man falsch machen kann – nur mit einem Shockwave-basierten Menü könnten sie es noch toppen. Die Lemon64-Menüleiste ist ein einziges, großes Bild, dessen Verlinkungen mit einer Image-Map realisiert wurde – Oh, Gott.

    Wenn man eine möglichst universelle Lösung für solche Frame-Patienten finden möchte, dann würde ich es folgendermaßen tun: Meistens bestehen Frame-Sites aus einem Hauptframe (meistens im Frameset mit "content" oder "main" benannt), einem Navigationsframe (meistens mit sowas wie "menu" oder "navigation" benannt) und weiteren, meisten für die Funktion unwichtigen, Frames (Chat, Werbung, Sponsoren, Blablah).

    Bei einem leistungsfähigeren Client als dem C64 (Amiga z.B.) würde ich evtl. das Original-Layout nachbilden, also dem Browser Frames beibringen. Technisch ist das recht simpel, daher ist es ja damals gemacht worden – nur die Auswirkungen sind halt katastrophal, u.a. weil Deeplinks und Bookmarks nicht wirklich gut realisierbar sind und die Hauptseite von der externen Navigation nichts "weiß".

    Beim C64 würde ich evtl. einen anderen Weg gehen, weil Frames naturgemäß den Screen aufteilen und bei der geringen Auflösung für Inhalte dann zu wenig Platz bliebe. Ich würde den Content-Frame laden und rendern, wie andere Webseiten auch. Und den Menu-Frame würde ich getrennt laden, die Links (egal, ob verlinkte Bilder, Imagemaps oder saubere Textlinks) extrahieren und auf einem einblendbaren Extra-Screen unterbringen. Oder aber der Proxy baut daraus, wie aus sauberen Bullet-List-Menüs, ein Hamburger-Menü für den Content-Bereich. Dann wäre es auf dem C64 kein Unterschied, ob ursprünglich Frames verwendet wurden oder was moderneres.

    Ja klar, auch hier wird es immer Websites geben, die auf Anhieb nicht laufen würden – aber wieder wäre ein Großteil erschlagen und beim Rest müste man halt gucken, ob es sich lohnt, die spezielle zu filtern.
  • Retrofan schrieb:

    ZeHa schrieb:

    EDIT: Die Existenz eines solchen Systems (eine Art "C64-Netz") wuerde vielleicht auch wiederum einige davon ueberzeugen, sich eine Netzwerk-Loesung fuer den C64 anzuschaffen.
    Das sehe ich allerdings bei jeder Lösung, die dem C64 einen angenehmen Web-Zugriff erlaubt. Und zwar um so mehr, je mehr Inhalte (vielleicht sogar 95% des Webs?) aufgerufen werden können.
    Ich nicht unbedingt, denn nach wie vor ist es eine berechtigte Frage, ob die User das nun wirklich machen wollen oder nicht. Nur weil es moeglich ist, heisst es nicht, dass es auch gemacht wird. Natuerlich moechte ich Dir Deine Idee nicht ausreden - es waere sicherlich cool, wenn es sowas gaebe. Aber ganz realistisch betrachtet ist es eben MEINER Meinung nach so, dass die meisten Leute nicht wirklich regelmaessig einen C64-Browser nutzen wuerden, sondern eher nur mal so um zu zeigen, dass es geht. Den INHALT von Seiten wie die csdb.dk und c64.com jedoch wuerden bestimmt viele direkt auf dem C64 abrufen koennen, inkl. dem Download der dort gehosteten Software. Allerdings muesste das alles super-bequem gehen, sprich, genau dafuer geschaffen worden sein. So wie eine App, die das Benutzen der eigentlichen Website ersetzt, weil es auf dem Handy zu umstaendlich waere. Im Prinzip also eher ein Client fuer "C64-bezogene Datenbanken".

    Es sind zwei sehr unterschiedliche Loesungen, Herangehensweisen und Anwendungsszenarien, daher moechte ich jetzt auch hier den Thread nicht damit zumuellen. Ich persoenlich denke aber, dass so etwas mehr realen Nutzen haette als einen Browser der alle Seiten anzeigt, selbst wenn er das relativ gut hinkriegen sollte (denn dann ist immer noch die Bedienbarkeit das naechste Manko).
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • ZeHa schrieb:

    naemlich koennte ich dann direkt per C64 Software runterladen und auf meinem SD2IEC speichern, ohne dass ich das erst auf meinem PC machen muss und dies dann auf die SD-Karte uebertragen muss usw.
    Das kannst du mit dem angedachten Browser-Konzept genauso – ich sehe es sogar als Killer-Argument für den C64-Browser. Die VT100-Lösung würde sowas verhindern, weswegen das für mich ein Grund gegen die Terminal-Lynx-Idee ist.

    ZeHa schrieb:

    Erstmal rumscrollen, suchen, usw, dann gehen irgendwelche Formulare nicht richtig, oder ich bin mit der Bedienung des Browsers nicht gut vertraut etc, dann lade ich die Datei runter und es ist womoeglich ein ZIP, wie entpacke ich das dann usw, ich glaube dass ich da nicht wirklich Lust drauf haette.
    Erst einmal kann der Proxy verhindern, dass du Download-Links angezeigt bekommst, die für das Zielsystem ungeeignet sind. C64 und (beliebig große) ZIPs sind halt nicht wirklich kompatibel. Für den C64 sollte der Proxy nur PRG- und vielleicht noch D64-Links anzeigen.

    Und auch eine spezielle CSDB-C64-App kann nicht verhindern, dass du erstmal zum gewünschten Download hin-navigieren musst.

    ZeHa schrieb:

    aber die Frage ist eher, wie universell muss es ueberhaupt sein, denn wie wuerde man es letztendlich ueberhaupt nutzen wollen. Und da sehe ich eben persoenlich deutlich mehr Nutzen in einer solchen Loesung als in einem universellen Browser.
    Ich sehe es so: Das eine verhindert das andere nicht – dafür sind die Konzepte zu unterschiedlich. Wenn jemand eine CSDB-App und eine Lemon64-App für den C64 schreiben möchte, dann kann er das gerne tun. Und wenn jemand einen Browser und einen Proxy programmieren möchte (was ich ja immer noch hoffe), dann kann er das tun – ob es die beiden (oder 10) Apps gibt oder nicht.
  • Neu

    ZeHa schrieb:

    Das sind aber Dinge, die Du als Mensch zwar machen kannst, aber schreib mal ein Programm das selbstaendig erkennt, welche Frames wichtig sind und welche nicht. Klar koennte man auch einen Konverter schreiben, der spezielle Seiten gesondert behandelt, aber es geht ja hier um eine allgemeingueltige Loesung.
    Man könnte nach Größe und Namen der in den Frames aufgerufenen Seiten gehen. Sicherlich liegt man da auch mal falsch - aber das lässt sich so oder so nicht vermeiden.

    Retrofan schrieb:

    Es kommt hinzu, dass lemon64 so ziemlich alles falsch macht, was man falsch machen kann – nur mit einem Shockwave-basierten Menü könnten sie es noch toppen. Die Lemon64-Menüleiste ist ein einziges, großes Bild, dessen Verlinkungen mit einer Image-Map realisiert wurde – Oh, Gott.
    Nun, da Du vom Fach bist, will ich mal nur vorsichtig widersprechen:
    1. Das Frame mit dem Menu heißt: Menu, das Frame mit dem Hauptinhalt heißt: Content
    2. Die Links in "dem einzigen, großen Bild" sind alle mit ALT-Texten versehen, die zur Erstellung des Hamburger Menüs reichen.

    Ich denke damit kann man arbeiten - es wird nicht die einzige Seite sein, die ein BILD oder mehrere Bilder für das Menü benutzt.
    area... href... alt könnte man ebenso automatisiert als Linkliste suchen, wie die <li><a href... Geschichten.

    Du sagst zwar, dass der größte Teil der Seiten im Internet bereits "modern" gestaltet sind, aber gerade unser Hobby ist weniger "modern" und ich denke, die eine oder andere Seite diesbezüglich arbeitet vermutlich mit sehr "einfachem" HTML bzw. wurden seit Jahren nicht modernisiert.
    carrier lost...
  • Neu

    Retrofan schrieb:

    Und auch eine spezielle CSDB-C64-App kann nicht verhindern, dass du erstmal zum gewünschten Download hin-navigieren musst.
    Das ist schon richtig, aber Du hast doch bestimmt schonmal auf dem Handy eine Seite benutzt, die eigentlich nicht fuers Handy optimiert war. Bis Du da teilweise das erledigt hast, was Du am PC mit 3-4 Klicks in 5 Sekunden schaffst, vergehen auf dem Handy manchmal Minuten, gefuehlt Stunden. Wenn man jedoch eine spezielle "App" schreiben wuerde, um auf dem C64 Software zu finden und herunterzuladen, dann waere diese Software 1:1 drauf zugeschnitten, dass man genau diesen Use Case auf dem C64 durchfuehren kann, und zwar so bequem wie moeglich. Das ist schon ein riesiger Unterschied in meinen Augen.

    Retrofan schrieb:

    Für den C64 sollte der Proxy nur PRG- und vielleicht noch D64-Links anzeigen.
    Auch hier sehe ich wieder einen grossen Unterschied in der Betrachtungsweise. In Deiner Loesung wuerdest Du Links unterschlagen, waehrend ich in meiner Loesung eher dafuer sorgen moechte, dass es gar nicht erst unpassende Links gibt, bzw. die Leute dazu ermutigen, ihre Seiten so zu gestalten, dass stets C64-konforme Downloads angeboten werden.

    Retrofan schrieb:

    Ich sehe es so: Das eine verhindert das andere nicht – dafür sind die Konzepte zu unterschiedlich. Wenn jemand eine CSDB-App und eine Lemon64-App für den C64 schreiben möchte, dann kann er das gerne tun. Und wenn jemand einen Browser und einen Proxy programmieren möchte (was ich ja immer noch hoffe), dann kann er das tun – ob es die beiden (oder 10) Apps gibt oder nicht.
    Ich wollte hier nur auch diese Anregung mal geben. Es schadet ja nicht, verschiedene Konzepte zu erlaeutern bzw. eroertern. Was davon umgesetzt wird, liegt letztendlich an den Programmierern. Aber durch die Diskussion kommt man evtl. noch auf weitere Ideen und Anwendungsszenarien und kann vielleicht am Ende etwas viel besseres erschaffen, als anfangs angedacht gewesen waere.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • Neu

    Chagizzz schrieb:

    ZeHa schrieb:

    Das sind aber Dinge, die Du als Mensch zwar machen kannst, aber schreib mal ein Programm das selbstaendig erkennt, welche Frames wichtig sind und welche nicht. Klar koennte man auch einen Konverter schreiben, der spezielle Seiten gesondert behandelt, aber es geht ja hier um eine allgemeingueltige Loesung.

    Man könnte nach Größe und Namen der in den Frames aufgerufenen Seiten gehen. Sicherlich liegt man da auch mal falsch - aber das lässt sich so oder so nicht vermeiden.

    Genau DAS ist aber in meinen Augen der springende Punkt. Es gibt einfach viel zu viele Seiten, die nicht gescheit funktionieren werden. Und genau das waere z.B. fuer mich ein Grund, solch ein Vorhaben gar nicht erst umzusetzen. Weil ich genau weiss (oder glaube zu wissen), dass das niemals etwas vernuenftiges werden wird. Ich lasse mich gerne vom Gegenteil ueberzeugen, aber ich glaube das wird der Grund sein, warum hier bisher kein Programmierer schreit "auja geile Idee, ich setz mich sofort dran". Aber wie gesagt, nur meine Meinung.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • Neu

    ZeHa schrieb:

    Genau DAS ist aber in meinen Augen der springende Punkt. Es gibt einfach viel zu viele Seiten, die nicht gescheit funktionieren werden. Und genau das waere z.B. fuer mich ein Grund, solch ein Vorhaben gar nicht erst umzusetzen. Weil ich genau weiss (oder glaube zu wissen), dass das niemals etwas vernuenftiges werden wird. Ich lasse mich gerne vom Gegenteil ueberzeugen, aber ich glaube das wird der Grund sein, warum hier bisher kein Programmierer schreit "auja geile Idee, ich setz mich sofort dran". Aber wie gesagt, nur meine Meinung.
    Lt. Retrofan entspricht doch genau der Großteil der Seiten den regeln einer modernen und einheitlichen Programmierung und wäre damit erfassbar. (Dazu kann ich nicht wirklich was sagen)
    Für die übrigen müsste man die eine oder andere "Standardabarbeitung" entwickeln, nach und nach könnte man eine Datenbank mit Informationen zu "idealen" Aufbereitung einzelner Seiten aufbauen.

    Ich denke eher, dass es schwer wird jemanden zu finden, der seine Seite zusätzlich in c64-HTML programmiert. Insbesondere, da fertige Produkte (Foren, Wiki...) verwendet werden und z.T. nicht die Kenntnisse vorhanden sind. Von der Lust der Umsetzung für eine doch eher überschaubare Fanbase mal ganz zu schweigen.
    Wenn der Betreiber einer Seite allerdings die Mögichkeit hat die "Datenbank" zur Optimierung der Anzeige seiner Seite auf <32 Bit Hardware etwas zu füttern, ist das vielleicht noch ein Überschaubarer aufwand für diesen...

    Für den/die Programmierer dieses Proxy ist es wohl ein wachsendes / endloses Projekt mit wenig Nutzung.

    Grundsätzlich ließe sich ja auch die Abfrage einer Seite über diesen Proxy erkennen und dann ggf. eine bereits reduzierte Seite (ähnlich der mobilen Seiten) liefern. Dann wäre die Abfrage einheitlich über den Proxy möglich und der liefert unverändert den Quelltext einer Seite, wenn diese es so vorgibt (z.B. durch Hinweis im bzw. vor dem Quelltext).
    carrier lost...