Es gibt ja auch Hardware-BTX-Decoder für C64. Immerhin wird wohl etwas in Richtung BTX entwickelt (nachdem ein anderes Projekt in dieser Richtung bereits aufgegeben wurde): Monitor für Commodore Btx-Modul?
Hallo Besucher, der Thread wurde 105k mal aufgerufen und enthält 727 Antworten
letzter Beitrag von emulaThor am
Webbrowser für 8-Bit-Rechner
- Retrofan
- Erledigt
-
-
Es gibt ja auch Hardware-BTX-Decoder für C64.
Ich verstehe den Sinn dahinter nicht, das Internet auf BTX herunter rechnen zu wollen (um dann aufwendig mit einem Modul dem C64 BTX beizubringen). Ich weiß auch gar nicht, in wie weit der CEPT-Standard frei von Rechten ist. Bei HTML, WML oder MD kann ich mir sicher sein, dass das alles frei und offen ist. Das ist alles super dokumentiert und es gibt Millionen Programmierer, die es kennen.
Aber wie gesagt, eigentlich ist die Diskussion um den Übertragungsstandard komplett sinnlos, weil man das frühesten diskutieren braucht, wenn es um eine konkrete Umsetzung geht. Und dann sollten das die Leute machen, die es auch programmieren müssen/wollen. Und die gibt es bislang nicht. Wolkenkuckucksheime sind ja toll aber wir müssen uns jetzt echt nicht um die Tapetenauswahl oder Kühlschrankbefüllung zanken.
-
Den Link zur angedachten Entwicklung für's C64-BTX-Modul hatte ich lediglich gepostet, weil hier von anderer Seite BTX in's Spiel gebracht wurde. Im dazu verlinkten Thread ist auch gar nicht die Rede davon, das Internet BTX-kompatibel abbilden zu wollen.
Einen Vorteil gäbe es bei einem solchen Vorhaben m.E. zumindest: Bei BTX handelt es sich um einen Standard, der zwar nicht mehr aktuell ist, aber auf mehreren Plattformen bereits implementiert wurde und von Homecomputern ohne zusätzliche Hardware prinzipiell darstellbar ist und dabei hardwareunabhängig mehr oder weniger identisch aussieht.
-
Aber wie gesagt, eigentlich ist die Diskussion um den Übertragungsstandard komplett sinnlos, weil man das frühesten diskutieren braucht, wenn es um eine konkrete Umsetzung geht. Und dann sollten das die Leute machen, die es auch programmieren müssen/wollen. Und die gibt es bislang nicht. Wolkenkuckucksheime sind ja toll aber wir müssen uns jetzt echt nicht um die Tapetenauswahl oder Kühlschrankbefüllung zanken.
Dann verstehe ich den ganzen Thread falsch bzw. nicht.
-
1. wäre die sinnvollste Variante. Das Hauptproblem wird doch eher sein, dass es keine generische Version geben wird, die aus allen möglichen Webseiten das wichtige herausholt. Das wird man doch für einzelne Webseiten zuschneiden müssen?
Damit zum Beispiel bei Foren, etc. die Anmeldung sauber läuft. Allein der Javascript-Rotz mit dem Auf-Animieren hier könnte schon ein nicht unerhebliches Problem darstellen. -
Im dazu verlinkten Thread ist auch gar nicht die Rede davon, das Internet BTX-kompatibel abbilden zu wollen.
Dann sind es halt zwei verschiedenen Projekte, die man nicht unbedingt zusammenführen muss. HIER geht es darum, das (ganze) WWW mit 8/16-Bit-Rechnern darstellen zu können.
Bei BTX handelt es sich um einen Standard, der zwar nicht mehr aktuell ist, aber auf mehreren Plattformen bereits implementiert wurde und von Homecomputern ohne zusätzliche Hardware prinzipiell darstellbar ist und dabei hardwareunabhängig mehr oder weniger identisch aussieht.
BTX mag ein Standard sein – aber einer aus der Vor-WWW-Zeit. Und daher meines Erachtens nicht ideal, um genau das darzustellen, was letztendlich BTX den Todesstoß versetzt hat. CEPT ist alt, wir wissen nicht, ob es frei ist und es kennt sich kaum jemand damit aus. Warum soll man ausgerechnet sowas nehmen? Auf WAP z.B. treffen deine Argumente auch zu aber aufgrund der HTML-Ähnlichkeit und des freien Zugang wäre es viel näher am Ziel. Man muss es sich ja nicht absichtlich schwer machen. Man kann auch Gopher oder HyperCard nehmen aber ich würde halt was modernes nehmen um was modernes zu tun.
Um ein weiteres Argument gegen BTX zu nennen: BTX macht es sich leicht (und konnte es, weil alle Zielgeräte identisch waren) und definiert eine feste Auflösung mit einem festen Zeichensatz. Das Internet (ich verwende den Begriff hier manchmal synonym zu WWW, was natürlich streng genommen falsch ist) hingegen versucht die Zielhardware möglichst optimal zu unterstützen. Also, hat man einen großen Bildschirm, wird der Inhalt darauf angepasst und man muss z.B. weniger scrollen. (Ich sage meinen Studenten immer: das Web ist formatlos – ganz im Gegensatz zu Plakaten oder Video.). Ist der Rechner schnell, kann er Videos in höheren Auflösungen anzeigen ... etc. Das Web passt sich also den Möglichkeiten der Hardware des Users an. Es gibt kaum hassenswertere Seiten als welche, die um einen festen Inhalt einen Rahmen malen und beim Aufziehen des Browser-Fensters nur diesen vergrößern und den Inhalt unverändert lassen (frühe Flash-Seiten). Man will als User davon profitieren, dass man u.a. eine hohe Auflösung fahren kann oder das eigene Gerät mehr Farben darstellen kann als der Durchschnitt (eine Diskussion beim Umstieg von 216 Webfarben bei 8-Bit-Farbdarstellung vs. 16.7 Mio. Farben bei 24 Bit).
Das Internet in einen BTX-Käfig zu sperren und damit dafür zu sorgen, dass ein hochgerüsteter Amiga 4000 das gleiche Bild bekommt, wie ein C64, halte ich für wenig erstrebenswert. Vor allem, wenn es so viele bessere Lösungen gibt.
Dann verstehe ich den ganzen Thread falsch bzw. nicht.
Ich will einerseits vermeiden, dass man sich zu sehr im klein-klein verliert – wir müssen noch nicht den Übertragungsstandard zum Zielgerät festlegen. Andererseits möchte ich den Entwicklern, sollten sich welche finden, möglichst viele Freiheiten lassen, um selbst Standards zu festzulegen. Wer sich die Arbeit macht, soll auch den Spaß haben dürfen, in alle Richtungen zu denken.
Aber du hast an dieser Stelle recht. Es ging hier nicht um eine Sprach-Wahl, sondern schon darum, wie letztlich die Ausgabe erfolgen soll. Starr mit 40 x 22? Zeichen (BTX) oder eben wie eine Website, die sich an die Fenstergröße anpasst. Das ist schon essentieller als nur, welcher XML-Dialekt es denn sein soll. Von daher hast du mit deinem Einwand recht.
1. wäre die sinnvollste Variante. Das Hauptproblem wird doch eher sein, dass es keine generische Version geben wird, die aus allen möglichen Webseiten das wichtige herausholt. Das wird man doch für einzelne Webseiten zuschneiden müssen?
Doch, es soll eine generische Variante geben, so wie jeder Webbrowser jede Website darstellen können soll. Es wird Ausnahmen geben, bei denen eine Extraktion des Inhaltes nicht möglich sein wird. Aber ich kann mir sehr wohl vorstellen, dass der angedachte Proxy in der Lage wäre, 90% des Webs für den C64 herunter zu rechnen.
Ich schrieb ja schon, dass es ein guter Test ist, zu gucken, was passiert, wenn man sich mit Lynx eine Webseite anguckt (und auch bedienen möchte). Dieses Forum z.B. lässt sich problemlos ansteuern und ansehen. D.h. dass uns kein Javascript o.ä. im Weg steht. Ich muss noch probieren, ob auch eine Anmeldung funktioniert, damit man sogar aktiv teilnehmen (also Postings schreiben) kann. (Wie gesagt, Lynx ist nicht für alles hier ein guter Berater aber für diesen Test gut zu gebrauchen).
Auch bei allen Seiten, bei deren Darstellung im (mobilen) Safari der "Reader"-Button (evtl. ein Textblock) erscheint, lässt sich Inhalt von Form und Werbung sauber trennen.
Man wird anfangs mit wichtigen Info-Angeboten und Foren (Forum64, Heise, Lemon64, Google, AtariAge, FAZ, SPON etc.) testen, wie gut das funktioniert und später dann eine Blacklist mit nicht funktionierenden Seiten anlegen, bei denen der Unser gewarnt wird, dass es problematisch werden könnte.
Aufgrund meiner Erfahrungen im Netz (ich baue ja auch selber Web-Seiten) bin ich mir recht sicher, dass ein Herunterrechnen heutzutage leichter denn je ist. Alleine die Abschaffung der unseligen Tables und Frames (und auch Flash) bringt uns ein Riesenstück weiter.
Es lässt sich heutzutage sogar recht sicher ermitteln, wo das Navigations-Hauptmenü steckt, weil es fast immer sehr ähnlich aufgebaut ist (Als "unsortierte Liste" mit Unterpunkten). Daraus ließe sich (ganz anders als Lynx es tut) ein richtiges Klapp-Menü (z.B. als "Hamburger"-Menü, wie man es von vielen mobilen Seiten her kennt) generieren.
ich versuche hier dafür zu werben, dass das alles möglich ist, damit sich vielleicht doch noch mutige Programmierer finden, die sich an die Sache herantrauen. In erster Linie braucht man jemanden, der technisch in der Lage ist, einen Webserver, einen Proxy, zu entwickeln. Der sollte sich eher mit PHP, Ruby und Co. auskennen und muss keine Ahnung vom C64 oder Atari ST haben. Und dazu müsste sich jemand finden, der für eine der Zielplattformen einen Referenz-Browser programmiert. Ich würde mich natürlich freuen, wenn das ein C64-kundiger wäre – aber es kann genau so gut ein ZX-Spectrum-, AtariXL- oder Amiga-Fan sein.
-
Nimms mir nicht übel, aber wenn man solche Ideen hat, dann soll man auch in der Lage sein, sie selbst umzusetzen / programmieren. Für mich klingt der Thread wie viele andere mit Recht kritisierte Threads, wo jemand eine "grandiose" Idee hat und nun sollen die anderen machen und womöglich das Rad zum X-ten mal neu erfinden.
Ferner sehe ich, wo wir hier doch bei 8-Bit sind, keinen Grund einen völlig flexiblen Browser zu programmieren... die Auflösung z.B. des Cevi ist ohnehin arg begrenzt, da würde sich ein fester Standard a la BTX ( nein, es muss nicht der BTX-Standard sein ) geradzu aufdrängen. Wüsste nicht, dass es Sinn macht, hier etwas auflösungsunabhängig / hardwareunabhängig zu programmieren, wenn man sowieso alles voll aufreissen muss, um überhaupt sinnvoll etwas lesen zu können. -
Nimms mir nicht übel, aber wenn man solche Ideen hat, dann soll man auch in der Lage sein, sie selbst umzusetzen
Ideen kommen nun mal unabhängig davon, ob man in der Lage ist, sie selbst umzusetzen. Ich habe nie einen Hehl daraus gemacht, dass der Thread dazu dient, Programmierer (mit den nötigen Fähigkeiten) für die Idee zu begeistern. Zitat aus meinem ersten Posting dieses Threads: "Ich weiß, alles Wolkenkuckucksheime. Wer soll das alles programmieren, wer soll den Proxi betreiben? Keine Ahnung – ich wollte hier nur mal die Idee in den Raum stellen." Ich kann nun mal nicht (mehr) programmieren – ich habe meine Kenntnisse aus dem Informatik-Studium komplett verloren, weil mein Hirn Platz brauchte, um den ganzen "Design-Unsinn" zu speichern.
Ich setze jeden Tag Ideen mit anderen zusammen um, die jeder alleine nicht hätte umsetzen können. Ich weiß nicht, was daran verkehrt sein soll.
Ferner sehe ich, wo wir hier doch bei 8-Bit sind, keinen Grund einen völlig flexiblen Browser zu programmieren...
Es geht auch nicht darum, einen flexiblem Browser (womöglich noch mit Fenstern) zu programmieren, sondern das Datenformat nicht künstlich zu beschneiden. Auf dem jeweiligen Gerät kann die Darstellung starr sein aber jedes Gerät kann halt unterschiedlich viel.
Wir hatten das Thema über die vielen Postings hinweg erweitert. Es gibt tausende von Gerätetypen neben dem C64, die auch zu schwach sind, heutige Webseiten darzustellen. Schon bei den 8-Bittern gibt es viele Geräte, die in der Lage sind, 80 Zeichen darzustellen (z.B. C-128). Für den Amiga oder Atari Falcon wären sogar kleine Grafiken drin. Der Palm Pilot hingegen hat einen quadratischen Screen (schwarzweiß) und der Apple Newton Screen ist hochkant, der vieler schwacher Smartphones der Frühzeit auch. ich glaube, ich kann die Aufzählung hier mal stoppen.
Daher wäre es komplett unproduktiv, ohne Not einen Uralt-Standard zu wählen, der nicht in der Lage wäre, solche Geräte adäquat mit einer Darstellung zu versorgen. BTX sieht aus, wie es aussieht, weil es für farbfähige, unscharfe Röhren-Fernsehgeräte mit festem Seitenverhältnis und immer gleicher Auflösung entwickelt wurde. Das WWW ist halt anders. Und das würde ich gerne erhalten.
Dazu kommt, dass es bei dem Proxy um eine Konvertierung von einem Format in ein anderes geht. Was ist da einfacher? Ein Zielformat, dass ehr eng mit dem Quellformat (HTML) verwandt ist oder ein Zielformat, dass möglichst weit weg davon ist?
Je mehr potentielle Geräte wir als Zielplattformen einbinden, desto höher wird die Relevanz des angedachten Proxys. Nur für den C64 wird es evtl. kaum jemand machen wollen – aber wenn der Proxy auch für Atari ST, Amiga, Apple II, 68K/PPC-Macs, DOS- und frühe Windows-PCs eine sinnvolle Darstellung realisieren könnte, dann sähe das meines Erachtens schon ganz anders aus. Vielleicht fängt man mit dem C64 als Referenz an – aber es sollte offen für alle Plattformen sein, für die es keinen aktuellen Browser mehr gibt. Wenn man einen Standard definiert, der eine gute Darstellung auf dem C64 gewährleistet aber offen für bessere Hardware ist, dann ist das erstmal nicht schwieriger als BTX – aber man verbaut sich nicht die Zukunft.
Wenn BTX die einzige Option wäre, dann würde ich sagen: OK, nehmen wir das trotz aller Nachteile. Ist es aber nicht – es gibt viel bessere Lösungen. Und das Tolle ist: damit kennen sich auch noch viel mehr Leute aus, was die Wahrscheinlichkeit erhöht, jemanden zu finden, der sich damit befassen möchte.
-
aber wenn der Proxy auch für [...] 68K/PPC-Macs, DOS- und frühe Windows-PCs eine sinnvolle Darstellung realisieren könnte ...
Ich denke gerade, wenn man für die Übertragung zum Zielgerät (zumindest optional) HTTP und ein HTML-Subset verwendet, dann bräuchte man für die Geräte, für die es einen veralteten Webbrowser gibt, gar keinen eigenen Client programmieren, sondern man "missbraucht" den alten Webbrowser dafür. Es würde vom Proxy halt alles weggeworfen, was den Ziel-Browser "verwirren" oder ausbremsen könnte und schon wären diese Geräte eingebunden – ohne dafür groß etwas tun zu müssen.
-
Wer Firefox benutzt, der kann man folgendes Addon "Textise" ausprobieren:
https://addons.mozilla.org/de/firefox/addon/textise
Das macht im Grunde genommen sowas in der Art und "rechnet" die Seiten auf "Text only" runter.
Also jetzt nur mal zum Ausprobieren, wie sowas aussehen könnte.
-
Dies ist ein Test mit Lynx
Ich bin begeistert:
Also funktioniert auch die Anmeldung und sogar eine rudimentäre Texteingabe ohne JavaScript-Kram oder ähnliches. Man kann das ganze natürlich noch kompakter formatieren und Sicherheitsabfragen [SSL error:self signed certificate-Continue? (j)] abfangen und z.B. erkannte Menüs zu echten Klapp-Menüs umbauen – aber grundsätzlich funktionieren selbst recht komplexe Dinge, wie Useranmeldung und Schreiben von Foren-Einträgen mit so einer Minimal-Lösung. Man stelle sich meine Freude vor, wenn ich das jetzt auf meinem C64 geschafft hätte.
-
Ich hab mal ein kurzes Video vom Status Quo gemacht. So funktioniert der Contiki Webbrowser (Version 2.8) auf einem C64 mit einer Nachrichtenseite. Wenn man sich die Mühe macht und ein derartiges Projekt auf sich nimmt, sollte zumindest eine eindeutige Verbesserung zu diesem recht praktikablen Browser herausschauen. Was bei Contiki fehlt: Einloggen, Eingabemasken etc. funktionieren nicht.
Zum Video (Einbetten scheint nicht zu funktionieren)
-
Ich hab mal ein kurzes Video vom Status Quo gemacht.
Vielen Dank dafür. Was ich mir vorstelle, soll natürlich "besser" sein, sonst wäre es ja sinnlos.
1) Mehr Platz für Inhalt: Dein Kontiki verschwendet 5 Zeilen für seine Statusanzeigen und Buttons, bleiben 20 Zeilen à 40 Zeichen = 800 Zeichen netto. Ich würde für Statusanzeigen und Buttons nur 2 Zeilen belegen und dank Grafikmodus würde ich in der Breite auf 40, 64 oder 80 Zeichen (einstellbar) gehen. Maximal wären das 1.840 Zeichen auf dem Screen. Das wäre das 2,3-fache. Oder aber man geht für eine bessere Lesbarkeit auf einen etwas größeren Zeilenabstand, dann würde man immer noch 80 x 16 Zeichen, also 1.280 Zeichen darstellen.
2) Moderne Darstellung: Natürlich würde man wichtige Sonderzeichen und Umlaute für die Darstellung integrieren. Links könnte man, wie gewohnt, unterstrichen anzeigen, rudimentäre Farbdarstellung wäre möglich. Je nach freiem Speicher (REU?) könnte man evtl. mehr als die gerade angezeigte Bildschirmseite in den Speicher holen und dann "scrollen". Die Bedienung könnte über Maus, wie auch per Tastatur erfolgen. Menüs (die als Bullet-Liste viel Platz verschwenden) könnten eingeklappt unter einem "Hamburger"-Icon verschwinden (wie bei Smartphones).
3) Performance: Da bei unserem angedachten Konzept der Browser nicht mehr selber filtern müsste, wäre eine Geschwindigkeitssteigerung über drei Mechanismen gegeben: Zum Einen wird die Übertragung entlastet, weil nur darstellbare Daten über die Leitung kommen müssen, zum Zweiten hat auch der Browser weniger Arbeit, weil er nicht mehr selber filtern muss und zum Dritten kann auch die Seitenbeschreibung platzsparender ausfallen (z.B. <i></i> statt <input></input>, was bei Übertragung, Speicherverbrauch und Abarbeitung Vorteile bringt. Wenn ich mir die Ladegeschwindigkeit bei deinem RR-Net so ansehe, ist die schon mal gar nicht so übel. Wenn man sich vorstellt, dass man (gefühlt/geraten) das Doppelte herausholen könnte, dann wäre das schon echt brauchbar.
4) Multiplattform-Fähigkeit: Wenn es erst einmal so einen Web-vereinfachenden Proxy gäbe, könnte jeder programmierkundige Fan eines klassischen Systems (für das eine Netzwerk-/Internet-Anbindung existiert) dafür einen Browser entwickeln und wäre, zack, im World Wide Web unterwegs. Da so ein Browser nur die nötigsten Befehle beherrschen muss, ist er schneller entwickelt als ein kompletter HTML-Browser mit umfangreichen Filtern und Konvertierungsfunktionen.
5) Funktionalität: Es sollen natürlich HTML-Formulare funktionieren, damit man Eingaben vornehmen kann. Sonst scheitert man schon an einer Suchmaschine und erst Recht an Foren, bei denen man sich anmelden muss und vielleicht auch am Diskurs teilnehmen möchte. HTML-Forms sind eigentlich sehr schlank und keine Raketenwissenschaft (gehören zu den frühesten HTML-Befehlen), sodass einer Umsetzung für C64 und Co. nur wenig im Wege stände.
In diesem Mockup kann man das aufgeklappte "Hamburger"-Menü sehen, welches der Proxy aus der "unordered list" generieren könnte, wenn man mal über die Fähigkeiten von Lynx/Kontiki hinaus gehen will.
-
Nettes Mockup. So in etwa würde ich das auch haben wollen - eher wie ein Geowrite Dokument als wie 'n oller BTX-Screen. Naja, das wäre schlußendlich Sache des Browsers (und von denen kann es freilich auch mehrere geben, je nach Geschmack).
Wie auch immer, die zunächst anstehende Frage ist ja wie man Webseiten vernünftig auf 320x200 Pixel (bzw. 40x25 Zeichen) @ 16 Farben herunterbrechen kann. Und ich fürchte die Antwort darauf lautet: Gar nicht. Zumindest habe ich selbst mein Lebtag noch keine einzige Realisierung dessen gesehen, welche diese Aufgabe dergestalt bewältigen konnte das man das Resultat ernsthaft hätte nutzen wollen. Das schaffen auch lynx, links, w3m etc. nicht (obschon ich zugeben muss das Contiki hier, Rotzwalds Video nach, erstaunliche Arbeit leistet).
Eine naheliegende Idee wäre es nun eigentlich sich von der Vorstellung der "Darstellung einer Webseite auf dem C64" zu verabschieden und sich stattdessen mit dem Gedanken der "Darstellung des relevanten Contents einer Webseite auf dem C64" anzufreunden. Eine recht simple Möglichkeit dazu wäre es das man sich (oder jemand anderen...) mal hinsetzt und versucht die generierten Webseiten gängiger CMS mittels XSLT o.ä. in ein Homecomputer-freundliches HTML-Derivat zu verwandeln. Falls das tatsächlich gelingt wäre der Aufwand dafür überschaubar, und fertige Proxies die damit umgehen können gibt es sicherlich auch schon.
Also - hat zufällig jemand der Anwesenden gerade Lust sich mit XSLT herumzuschlagen...?
-
Wow, das Mockup ist schon mal richtig gut
Ich sehe es genauso wie Retrofan, es wäre einfach cool mit dem C64 im Internet zu surfen (auch wenn es natürlich mit dem PC wesentlich besser funktioniert ), auch wenn man den Nutzen hinterfragen kann (aber streng genommen müsste man den Nutzen immer hinterfragen, schließlich haben Spiele auf dem PC auch eine bessere Grafik etc.)... Hauptsache ist, dass man nicht von einem danebenstehenden PC abhängig ist, dann geht das Gefühl, dass man mit seiner alten Kiste tatsächlich im Internet unterwegs sein kann, doch wirklich verloren. Ich habe auch mal Contiki ausprobiert, doch die 40 Zeichen und insbesondere, dass die Feldeingaben nicht möglich sind (google) sorgen dafür, dass man den Browser eben nicht wirklich nutzen kann.
Von der Darstellung her scheint der Singular Browser besser zu sein, aus irgendeinem Grunde habe ich den damals aber nicht zum Laufen gebracht... ( http://csdb.dk/release/?id=47920 )
Würden die Daten für den C64 durch einen Proxyserver vorbereitet werden, wären definitiv völlig andere Möglichkeiten gegeben und das Mockup von Retrofan keine Utopie... Inwieweit das möglich ist, weiß ich leider nicht -
Nettes Mockup. So in etwa würde ich das auch haben wollen - eher wie ein Geowrite Dokument als wie 'n oller BTX-Screen.
Erstmal: Danke. Natürlich ist der Browser nicht das Wichtigste bei dem Projekt aber halt das, was der Anwender später sieht. Und wenn das schon auf den ersten Blick keine Verbesserung zu Kontiki oder BTX darstellt, wird niemand sagen: das möchte ich gerne auf meinem C64 haben/können.
Naja, das wäre schlußendlich Sache des Browsers (und von denen kann es freilich auch mehrere geben, je nach Geschmack).
So sehe ich das auch. Wenn der Proxy flexibel genug ist, kann es auch auf einer Plattform 2 oder 3 Browser geben – wo dann für jeden Geschmack etwas dabei ist. 80-Zeichen-Bitmap-Browser oder auch 40-Zeichen-Charactermode, mit Tastatursteuerung oder mit Maus, Farbe oder monochrom, was immer man will.
Wie auch immer, die zunächst anstehende Frage ist ja wie man Webseiten vernünftig auf 320x200 Pixel (bzw. 40x25 Zeichen) @ 16 Farben herunterbrechen kann.
Eben nicht. Schon mal gar nicht starr 40x25 Zeichen. Das kann dann ja auf Wunsch der Browser machen.
Zumindest habe ich selbst mein Lebtag noch keine einzige Realisierung dessen gesehen, welche diese Aufgabe dergestalt bewältigen konnte das man das Resultat ernsthaft hätte nutzen wollen. Das schaffen auch lynx, links, w3m etc. nicht
Ich finde Lynx gar nicht so schlecht. Zumindest kann man damit sehr viel machen, z.B. hier im Forum schreiben. Die optische Aufbereitung ist natürlich suboptimal, denn das ist ja auch kein Ziel des Browsers. Die Aufbereitung kann man aber in einem 2. Schritt anschließen – denn das Ziel eines C64-Browsers ist ja nicht das gleiche, wie das von Lynx. Es MUSS ja nicht am Ende alles Text sein, sondern es darf auch ein grafisches Menü generiert werden, wenn die Daten das hergeben.
Aber Optik mal außen vor – Ein Browser, der in etwa das darstellt, was Lynx so kann, wäre auf einem C64 oder C128 oder Apple II schon eine tolle Sache. Und Kontiki ist ja sowas, nur halt noch deutlich verbesserungsfähig, z.B. durch Unterstützung von Forms (Eingabemöglichkeiten).
obschon ich zugeben muss das Contiki hier, Rotzwalds Video nach, erstaunliche Arbeit leistet
Kontiki ist für mich sehr wichtig. Ohne Kontiki würde die überwiegende Mehrheit glauben/behaupten, ein Web-Browser wäre am C64 unmöglich. Kontiki beweist das Gegenteil. Es funktioniert. Punkt. Jetzt kann man sich darum kümmern, es besser zu machen. Wenn man sich anguckt, was Kontiki aus einer komplexen Website macht, dann ist das schon erstaunlich, weil das Programm ja mit haufenweise unnützem HTML-Code bombardiert wird und das Zielgerät gerade mal 1 MHz und ein paar Kilobyte zu Verfügung hat, den ganzen Kram zu sortieren. Und genau an der Stelle greift das Proxy-Prinzip ein. Damit wird man mehr (und nicht weniger) machen können und damit wird der C64 entlastet und beschleunigt. Der Proxy ist ein Web-Turbo, wenn man so will.
Kontiki geht das ja schlau genug an: Es wird dem Server ehrlich melden, wie gering seine Grafikauflösung ist und bekommt dann die "mobile" Website-Variante (im Video am "m" in der URL zu erkennen) geschickt. Die ist ohnehin schon dank CSS kräftig abgespeckt, kann aber trotzdem JavaScript etc. enthalten. Aber wenigstens liegen dort alle Infos in der richtigen Reihenfolge untereinander und Werbung ist meistens auch nicht drin.
Eine naheliegende Idee wäre es nun eigentlich sich von der Vorstellung der "Darstellung einer Webseite auf dem C64" zu verabschieden und sich stattdessen mit dem Gedanken der "Darstellung des relevanten Contents einer Webseite auf dem C64" anzufreunden.
Aber das ist doch das, was wir hier (in Gedanken) versuchen. Die originale Optik ist weitgehend irrelevant – es geht um den Inhalt. Den kann man aber heutzutage recht gut aus einer existierenden Website herausschälen. Einfach weil modernes HTML an der Stelle viel, viel besser ist, als in den wilden frühen 2000er Jahren. Ich "programmiere" ja selber Webseiten und es ist klasse, wie wenig Code heutzutage in der Website selber steckt. Das (externe) CSS ist teils 5 Mal so lang wie der HTML-Teil. Die ganzen komplexen Tabellen-Schlachten der Frühzeit sind verschwunden. Aber auch für einen C64 kommt am Anfang einer jeden Seite erstmal der HTML-Header, der auch schon ein paar C64-Bildschirmseiten lang sein kann und der dem C64 nur wenig nützt. Kontiki muss das aber erstmal (über-) lesen, bevor der Inhalt kommt. Der Proxy kann ihm die Arbeit abnehmen.
Man kann so einen Proxy sicherlich unterschiedlich konzipieren, es wird verschiedene technische Ansätze geben. Jemand hatte hier einen Link gepostet zu einem Lynx, der als Proxy arbeiten kann. Ich habe leider nicht herausgefunden, wie man ihn anspricht. Ich finde, das wäre schon eine gute Basis: Der Proxy fordert die mobile Variante einer Website an, kürzt den Header auf das nötigste, entfernt alle (teils langen) Bilder-Links etc., versucht bestimmte Strukturen zu erkennen, die er mit speziellen Nicht-HTML-Tags versieht (Stichwort: Bullet-List-Menüs), wirft nicht unterstützte HTML-Strukturen (z.B. Tables) weg und kürzt die restlichen HTML-Tags C64-feundlich ein. Das schickt er dann (notfalls in handlichen Häppchen) an den Client.
Wie weit er die Seite zusammenkürzt, hängt natürlich davon ab, welcher Client die Anfrage gestellt hat. Bei einem Amiga könnte er die Bilder-Links in kürzere (auf dem Proxy) ersetzen und dort herunter gerechnete Bitmaps ablegen. Bei einem frühen Windows CE Gerät könnte er das HTML nur etwas abspecken aber echtes HTML erhalten, weil der Client über einen (veralteten) Webbrowser verfügt. Das würde ich aber erst nach und nach implementieren – nur sollte man diese Sachen schon im Hinterkopf behalten, um sich solche Szenarien nicht zu verbauen.
In erster Linie soll der C64 und seine Zeitgenossen ins WWW gebracht werden aber richtig relevant wird die Sache, wenn eine immer weiter steigende Zahl von ausgeschlossenen Gerätschaften diesen Proxy als Drehscheibe ins Netz sieht. Vielleicht ist das zu hoch gegriffen aber vielleicht ist das auch die Aussicht, die eine Realisierung erst interessant erscheinen lässt.
-
Kontiki geht das ja schlau genug an: Es wird dem Server ehrlich melden, wie gering seine Grafikauflösung ist und bekommt dann die "mobile" Website-Variante (im Video am "m" in der URL zu erkennen) geschickt.
Die mobile Version (m.orf.at) hab ich händisch eingegeben. Das geht nicht automatisch. Die normale Desktop-Version von ORF (orf.at) kann man auch aufrufen, ist auch brauchbar, aber die Mobilversion ist abgespeckt und besser nutzbar.
Grundsätzlich sind alle Seiten gut, die ihr Service auch barrierefrei anbieten. Die Ausgabe über eine Braillezeile für Sehbehinderte ist ein gutes Benchmark, da muss auch der ganze Müll weg und nur der sinnvolle Text darf bleiben. Ich brauch eigentlich keine Grafik, hab auch Lynx auf dem PC in Betrieb. Mir würde schon ein Textbrowser reichen, der Eingabefelder beherrscht und Umlaute darstellen kann. Würde Contiki das noch beherrschen, dann wärs für mich schon ok.
Das Mockup ist hübsch, allerdings wär mir recht, wenn die Lesbarkeit so gut wie möglich ist, da wir Retro-Fans ja auch nicht jünger werden. Aber das ist letztlich wirklich schon sehr ins Detail.
-
Die mobile Version (m.orf.at) hab ich händisch eingegeben. Das geht nicht automatisch.
Gut, das kann man aber trotzdem automatisieren, der Browser (oder Proxy) muss sich nur richtig vorstellen – bei Smartphones geht es ja auch.
Grundsätzlich sind alle Seiten gut, die ihr Service auch barrierefrei anbieten.
Und das werden immer mehr, es gibt für bestimmte Angebote in Deutschland sogar die Verpflichtung dazu. Aber auch die Möglichkeit, Braille-Leser mit dem iPhone/iPad zu verbinden und Browser mit Vorlese-Funktion, führen zu einem immer größeren Online-Angebot für Menschen mit Einschränkungen.
Das Mockup ist hübsch, allerdings wär mir recht, wenn die Lesbarkeit so gut wie möglich ist, da wir Retro-Fans ja auch nicht jünger werden.
Ich finde die Lesbarkeit nicht schlecht. Man muss halt nicht mehr soviel Scrollen und Seiten-umschalten, was etwas Ruhe in die Sache bringt. Dazu kommt, dass die Bildschirmdarstellung auch auf dem C64 besser geworden ist. In den 80er hatte ich einen 38cm-TV per Antennenkabel an meinem C64, jetzt einen 1084s über Monitorkabel (noch Composite, demnächst S-Video) und viele nutzen auch TFTs.
Und wer möchte, kann ja heutzutage auch einen C128 mit echten 80-Zeichen (640 Pixeln horizontal) als C64-"Ersatz" verwenden. Da hat man auch gleich mehr Speicher eingebaut.
Mir würde schon ein Textbrowser reichen, der Eingabefelder beherrscht und Umlaute darstellen kann.
Das wäre ja im vorgestellten Konzept quasi nebenbei mit erschlagen. Und wer lieber 40 Zeichen pro Zeile behalten will, könnte das auch mit dem Proxy – das ist ja nur eine Einstellungssache. Und es wäre eben mit Proxy bei gleicher Client-Hardware deutlich schneller (und noch etwas aufgeräumter).
-
und Umlaute darstellen kann
Das ist jetzt zwar für die Proxy-Idee nicht relevant aber mich würde interessieren, ob Kontiki die klassischen HTML-Umlaut-Umschreibungen, wie ä
für ä beherrscht. Dann läge die umlautfreie Darstellung in Kontiki nur daran, dass man heutzutage die Texte UTF-8 kodiert und diese Bastelei nicht mehr nötig ist.Versuch doch mal eine Seite zu finden, die Umlaute noch nach dem klassischen HTML-Prinzip schreibt und guck, ob Kontiki das auflösen kann. Oder guck mal, ob im Zeichensatz überhaupt Umlaute enthalten sind. Zu C64-Zeiten hatten das ja eigentlich nur explizit deutschsprachige Softwares eingebaut.
-
Fuer die, die es mit dem Pi noch einmal einfach haben wollen als Commodore User eine BBS zu nutzen:
Code- ViceSQUAD Internet BBS edition!
- WELCOME TO ViceSQUAD Internet BBS TELECOM edition! ..
- Prepare to go back to the 1980’s pre-internet “ON LINE” days of dial up bbs’s!! But this time you won’t need a modem or phone line nor need to worry about long distance by the minute charges {remember those???}, now all you need is just a standard internet connected Raspberry Pi and ViceSQUAD.!
- WHAT ViceSQUAD IS / WHAT IT IS NOT.
- Vice Squad has two primary goals,
- 1.First, While retro-gaming on the c64 is fun there are other equally interesting and important historical notes about the era in which the c64 was born, importantly for many it was the first time when people were introduced to and experienced going “on line”, a pre-cursor to our current internet era, dialing up BBSs and commercial services, meeting people and making new friends from around the world, downloading and uploading software, instant access to news and information, etc. These are all important “firsts”, ViceSQUAD makes it amazingly simple to experience that world of Internet BBS’s or TeleBBS again (but this time, accessing old school “dial up” Commodore 64/Amiga/PC BBS’s {Bulletin Board Systems} over the internet via the telnet protocol instead of using a modem + phone line).
- Many people are not aware that folks STILL RUN bbs’s in this internet day and age, traditionally you needed actual hardware, linked via user port rs232 adaptors to a null modem to a modern PC or a raspberry pi which you then “piggy backed” via a program called TCPSER to connect to them over the public internet, this setup while it worked was complicated and had many “moving parts” just to get online. It also required some degree of technical knowledge to configure and get everything working correctly, both on the host pc and on the c64. What ViceSQUAD does is all that hard work for you, it also eliminates the need to use a second computer linked via a serial connection, its all done on the one RaspberryPi. Now you can easily connect to a BBS simply by booting up your Raspberry Pi, selecting the first menu item. From there you just pick the BBS you want to “call” and its all set. Nothing to setup, configure etc. (aside from the basic of getting your Pi connected via RJ45 or Wifi). I have configured the system to allow all the VICE 8 bit emulators the ability to do this, so you can connect with a c64, or use the Vic20, PET, Plus/4 or 128 emulators to go “on-line” .. not just the C64 one!
- If you want to learn more about the whole BBS era there is a fantastic 8 part documentary on Youtube
- https://www.youtube.com/playlist?list=PL2B9EF89CE228ED0A
- If you want to learn a little more about TCPSER (A HAYES compatible modem emulator)
- https://manned.org/tcpser/e8754729
- 2. The second goal of ViceSQUAD is to shed some light on the OTHER 8-bit systems Commodore produced, The PET, Vic-20, Plus/4, C128, while the c64 does get (and deserve) a lot of the current retro-emulation spotlight and sunshine, the other machines also have a varied and interesting history of their own and also deserve to be equally explored and tried. There are many fantastic games on those other systems and I encourage you to try them and explore what those non c64 platforms have to offer.
- What ViceSQUAD is not:
- ViceSQUAD is not intended to be slimline optimized fast booting “direct boot to c64” to play games, ala AMIBIAN, Vice c64 pure, etc.. It can however play games just like any other Commodore emulator and I have provided some “vanilla” options specifically tailored to games to make it easy to do so (hopefully people will explore games on systems like the Vic20 and Plus/4, PET!)
- http://bit.ly/2cK7vJX