Proxy (Dither) für Atari ST, STE, Mega, TT, Falcon

[Arthur]

Ich habe mir neulich gedacht das ein Proxy für die Atari TOS Computer das darstellen von Webseiten hilfreich unterstützen könnte indem die Bilder auf die Farbtiefe des Clients gleich vom Proxy in 1, 2, 4, 8 Bit gedithert würden so dass, das darstellen der Seiten die Client-CPU entlastet. Da ich bisher mit Proxy-Servern kaum zu tun hatte frage ich mich nun ob es so etwas z.B. als Windows oder Linuxsoftware schon gibt?

Tipps rund ums Thema sind sehr erwünscht.

[gh-baden]

Ich habe mir neulich gedacht das ein Proxy für die Atari TOS Computer das darstellen von Webseiten hilfreich unterstützen könnte indem die Bilder auf die Farbtiefe des Clients gleich vom Proxy in 1, 2, 4, 8 Bit gedithert würden so dass, das darstellen der Seiten die Client-CPU entlastet. Da ich bisher mit Proxy-Servern kaum zu tun hatte frage ich mich nun ob es so etwas z.B. als Windows oder Linuxsoftware schon gibt?

Tipps rund ums Thema sind sehr erwünscht.

Nicht ganz passend, geht aber in die gleiche Richtung: wrp von Tenox

WRP is a HTTP proxy service that renders the web page in to a GIF/JPEG image associated with clickable imagemap of the original web links. It allows to use historical and obsolete web browsers on the modern web. It's still a work in progress but it's quite stable and usable for casual web browsing.

[gh-baden]

Ich habe mir neulich gedacht das ein Proxy für die Atari TOS Computer das darstellen von Webseiten hilfreich unterstützen könnte indem die Bilder auf die Farbtiefe des Clients gleich vom Proxy in 1, 2, 4, 8 Bit gedithert würden so dass, das darstellen der Seiten die Client-CPU entlastet. Da ich bisher mit Proxy-Servern kaum zu tun hatte frage ich mich nun ob es so etwas z.B. als Windows oder Linuxsoftware schon gibt?

Und von der anderen Seite gedacht …

Letztlich lagert man damit ja rechnenintensive Tasks auf eine moderne CPUs aus, die in diesem Fall "unter" dem Proxy läuft. Das ist eine Möglichkeit das Problem "zu wenig Rechenpower für moderne Daten unter den eigenen Finger" zu lösen, und kann im Extremfall dann auf wrp (s.o.) hinauslaufen – dann bleibt für den 68k-Rechner nicht mehr soo viel zu tun. Er verliert mit so einem Proxy auch Intelligenz und Einflussmöglichkeit, er wird letztlich zum dummen Terminal. Das will nicht jeder bzw. es hat auch Nachteile (die Originaldaten liegen dem ST dann nie vor, die hat der Proxy ja entfernt, bspw.)

Der andere Weg als das am Proxy zu machen wäre also, das Konzept des Coprozessors etwas weiterzudenken. So wie der Atari-68000 seine 68881-FPU fragen kann „mach mir mal den Sinus“, oder der Falcon seinen DSP „bieg mir mal die Daten zurecht“, so könnte man einen neuen Coprozessor an einen ST anflanschen. Entweder klassisch richtig gelöst, wie von Motorola vorgesehen, über das universelle Coprozessor-Interface (das ja mitnichten nur FPUs bedienen kann, und Coprozessor muss ja nicht "mathematischer Coprozessor" bedeuten), oder über eigene Wege.

Ob das jetzt am ACSI-Port ist (Supercharger läßt grüßen - nichts anderes ist der 8088 da drin nämlich, wenn man möchte. Nur rockt ein 8088 im Vergleich zum 68k nicht wirklich), oder am Druckerport (so macht man es an der Amiga, wenn man MP3 in Echtzeit hören möchte: an einem MP3-Coprozessor-Dongle am Parallelport die Daten dekodieren lassen), spielt erstmal keine Rolle.

Günstige Coprozessoren gibt es inzwischen ja wie Sand am Meer, entweder roh in Gestalt von Billigst-CPUs oder Embedded-CPU-ICs (selbst ein PIC kann inzwischen 30 MIPS bringen, vs. ~5 MIPS des 68030 im TT), oder mit mehr Leim außenrum in Gestalt eines Raspberry Pi Zero, Orange Pi Zero oder einem VoCore oder VoCore2 (*) o.ä.

Dann kann man so ein Kästchen an den ST andocken (bspw. am ROM- oder IEEE1284-Port), und der ST mit angepaßtem JPEG-Plugin rechnet die Daten nicht selbst, sondern schiebt sie zum Rechenknecht „mach mir mal das JPEG klein“.

Und wer es ganz pervers will, kann beides haben, so ein *Pi Zero kann sowohl Proxy sein, als auch Coprozessor, zur gleichen Zeit :-)


(*) https://www.indiegogo.com/projects/vocore2-4-coin-sized-linux-computer-with-wifi#/ - den ohne Header bekommt man fast in Stecker eingegossen. Der NanoPi ist etwas „dicker“, aber immer noch winzig. Kosten tun solche Kistchen nackig 6-15$.

[ari.tao]

^^-- Faszinierend, was Du da skizzierst! 
Nachdem die Festplatte ´raus ist, gibt´s im Butterfach meines TTs ja noch viel Platz für ca. ein Dutzend dieser Winzlinge. Und sogar im Falcon könnte man den einen oder anderen noch unterbringen.

... so ein *Pi Zero kann sowohl Proxy sein, als auch Coprozessor, zur gleichen Zeit :-)

Wer macht uns so ´was?!

[1ST1]

Gibts doch schon, nennt sich CosmosEx, man müsste nur die entsprechende Software dafür stricken und am Line-F-Vektor eine Routine andocken, die die Daten per ACSI/SCSI an das Device schickt und wieder abholt. Der CosmosEx stellt ja auch per TCPIP-Stack Netzwerkfuntkionalität des Raspi über STING zur Verfügung, da könnte man dann ja auch den Proxy reinprogrammieren, der die Webseiten schonmal vor-rendert. Ps: WAP lässt grüßen...

Es gab auch schonmal die Idee, einen Raspi als Grafikkarte auf den VME-Bus zu knallen, ich weiß aber nicht was daraus wurde.

[Lukas Frank]

Ideen gibt es genug, nur mangelt es an Leuten die sowas umsetzen wollen und können ...

[Arthur]

Der CosmosEx stellt ja auch per TCPIP-Stack Netzwerkfuntkionalität des Raspi über STING zur Verfügung, da könnte man dann ja auch den Proxy reinprogrammieren, der die Webseiten schonmal vor-rendert.

Mein PC steht ja im selben Raum wie der TT, daher würde mir eine Windows-Software die nebenbei die Bilder umrechnet am besten gefallen. Extra einen CosmosEx kaufen möchte ich nicht. Falls man einen BananaPi (liegt schon ewig hier herum) dafür nutzen kann oder den Raspberry Zero (müsste dafür erst angeschafft werden) dann wär das eine Lösung die mir gefallen würde. Ein Test mit WRP unter Linux (in einer VM) werde ich bestimmt einmal machen. Hier würde mich noch interessieren ob GIF-Dateien gegenüber JPG das optimum beim laden auf dem Atari wären und jeder Browser problemlos damit klar kommt.

[ari.tao]

Zu GIF / JPEG kann ich Dir nur wenig sagen:
1) CAB hat eine ganz miserable 16-Farben-Darstellung von .GIFs!
   Das macht zB. die DOITs zum Teil fast unleserlich.
   Abhilfe: HIWIRE oder zu 256 Farben wechseln.
2) Wenn die Bilder nicht eingebettet sind, kann man aber ein externes Prg. beauftragen.
   In bester Qualität und wohl auch am schnellsten macht APEX den Job. Dennoch:
3) Mehr als Blitten, ibs. jedes Dithering, ist auf unseren Oldtimern unerträglich lahm. Da fehlt eine Größenordnung an Rechenpower!
4) Mit WENSUITE/WEBSPACE habe ich fast gar keine Erfahrung.

[1ST1]

Noch ein Vorschlag: Unter (easy)Mint gibt es ja ein scheinbar komplettes X Window System. In wie weit ist das denn fähig, als XDMCP-Terminal zu arbeiten? Ok, dann findet zwar die eigentliche Programmausführung nicht mehr auf dem Atari statt, sondern auf einem Linux-PC (kann auch ein RaPi sein), aber die Darstellung erfolgt auf dem Lieblingsrechner. Man sieht dann quasi den fetten Firefox 57 auf dem Atari... Der ist dann allerdings nichts anderes mehr als ein X-Terminal.

[gh-baden]

Noch ein Vorschlag: Unter (easy)Mint gibt es ja ein scheinbar komplettes X Window System. In wie weit ist das denn fähig, als XDMCP-Terminal zu arbeiten? Ok, dann findet zwar die eigentliche Programmausführung nicht mehr auf dem Atari statt, sondern auf einem Linux-PC (kann auch ein RaPi sein), aber die Darstellung erfolgt auf dem Lieblingsrechner. Man sieht dann quasi den fetten Firefox 57 auf dem Atari... Der ist dann allerdings nichts anderes mehr als ein X-Terminal.

Kannste probieren. Ich kann dir aber sagen, dass ein X Server auf einem 68040/40 sowie auf MIPS R4300 und auf PA-RISC 7100/100 mit schneller Grafikhardware *unerträglich* lahm ist mit allen modernen Browsern. Mit 256 Farben kannst du schon die Darstellung vergessen, dafür ist kein Browser mehr vorbereitet. Und 32768+ Farben sehen dann zwar erstmal gut aus, aber wehe, wehe du willst scrollen. Es zeigt sich, dass die Browser letztlich dem X Client nur noch komplette Bitmaps der Seite schicken, keine Einzelelemente mehr, d.h. da gehen viele Megabytes durch die Leitung beim scrollen.

Kurz: Ich habe es aufgegeben, Firefox, Opera oder Chromium auf einem X Server auf „schwacher“ Hardware einzusetzen. Und die genannte Hardware oben ist z.T.  eine bis zwei Größenordnungen fixer als ein schneller Atari.

[Arthur]

Das mit dem Problem die Daten über das Netz zu kopieren muß auf dem Atari zwangsläufig scheitern weil richtig schnelle Netzwerkkarten hier sehr sehr spärlich gesäht sind. Wenn per Remote dann noch unkomprimierte Daten übertragen werden dann wird's wohl nicht flüssig laufen. Auch RealVNC ist in der Lage eine Anwendung Remote auf einem anderen Computer darzustellen doch die Bandbreite wird wohl auch hier nicht dafür ausreichen.

[gh-baden]

Das mit dem Problem die Daten über das Netz zu kopieren muß auf dem Atari zwangsläufig scheitern weil richtig schnelle Netzwerkkarten hier sehr sehr spärlich gesäht sind. Wenn per Remote dann noch unkomprimierte Daten übertragen werden dann wird's wohl nicht flüssig laufen.

Nicht nur Bilder werden so übertragen, sondern die ganze Webseite! Die kommt als ein riesiges Bild …

[ari.tao]

Geht da auch nix via DMA ?

[1ST1]

Wenns per SCSI/ACSI angebunden wird, ist es DMA...

[gh-baden]

Geht da auch nix via DMA ?

Das Problem wirst du auch mit DMA nicht lösen. Zum einen kenne ich am Atari keinen TCP/IP-Stack, der copy-free daherkommt, zum anderen ist der ST für solche Datenmengen wiederum viel zu langsam. Wie gesagt, ein 68040/40 kann da schon einpacken. Da braucht man am Falcon nicht anfangen zu tunen, da fehlen Größenordnungen.

Guckt Telnet, Gopher, MAUS, FIDO, ZMODEM, Kermit, IRC an. Das ist das richtige Zeug für den Atari. Dem ST das heutige Web beibringen zu wollen, ist ein wenig wie zu wollen, dass da "Halo 4" drauf läuft. Oder so. (hab es weniger mit 3D-Geballer)

[1ST1]

Das ist auch etwas, was ich nicht verstehe. Die Leute denken, mit einem 30 Jahre alten 8 oder 16/32 Bit Rechner kann man uneingeschränkt ins Internet.. Wozu dann die Hardwareentwicklung der letzten 30 Jahre, vom einstelligen Megaherz-Takt zu knapp 4 Gigahertz, von wenigen KB RAM zu heute oft 16 oder gar 32 GB in einen Desktop oder Notebook?

Man braucht z.B. nur unter Windows mal den Taskmanager auf zu machen und zu schauen, was der bevorzugte Webbrowser so an Speicher belegt. Bei mir sind es gerade mit FF 57 und etwa 30 Tabs in 3 Fenstern rund 1,2 GB RAM verteilt auf 7 Tasks (der größte davon belegt über 400 MB RAM). Und das muss er, weil heutige Webseiten riesige Datenmengen benötigen. Noch ein Test, Edge auf gemacht, dieses Forum geöffnet, zack, 120 MB RAM belegt. Das ist 30 mal mehr als ein normaler ST haben kann. Und selbst in die wenigsten TT oder Falcon können per spezieller Erweiterung (Magnum TT, Storm, ct60) so viel RAM eingebaut werden.

Oder mal das Grafikprogramm Photoline oder GemView geöffnet und darin die JPG aus einer einigermaßen modernen Digitalkamera geöffnet. Das dauert selbst auf einem TT mitunter Minuten! Alle Webseiten sind voller eingebetteter JPG-Bilder.

Ich erinnere mich auch noch an meine ersten Java-Script-Experimente unter Windows 98SE mit einem Pentium 200 MMX. Mit ganz einfachen Scripten lief der Prozessor bei 100% Auslastung. Kein Atari-kompatibler Rechner (außer die halbwegs kompatible Firebee) erreicht derzeit 200 Mhz Takt. Bei Flash wäre es ähnlcih, gäbe es das für Webbrowser auf dem Atari.

Wenn der PC ein MP3 abspielt, merkt man das an der Systemauslastung nicht. Lässt man das den TT machen, ertönt nach 10 Sekunden ein 1 Sekunden langer Musikfetzen, dann rechnet der TT erstmal wieder 10 Sekunden bis zum nächsten Fetzen Musik.

Das sieht heute alles halt so selbstverständluch aus, man macht ne Webseite auf und die ist sofort da und das Video in FullHD läuft los, währenddessen hat der PC-Prozessor aber 10 Millionen Maschinebefehle ausgeführt, für die ein C64, ST, Amiga oder so aber einen ganzen Tag brauchen, wenn nicht eine ganze Woche.

Diese Dimensionen wollen vielen Leuten nicht in den Kopf rein.

[ari.tao]

Geht da auch nix via DMA ?

Das Problem wirst du auch mit DMA nicht lösen.
...
 zum anderen ist der ST für solche Datenmengen wiederum viel zu langsam. Wie gesagt, ein 68040/40 kann da schon einpacken. Da braucht man am Falcon nicht anfangen zu tunen, da fehlen Größenordnungen.

Mit ca. 1,2MB/s Ü-Rate kann man zwar keine Filme gucken, aber zum Surfen tät´s langen, wenn der ganze Browser-Schlumps extern erledigt wird und nur der Bildschirm mit dem fertigen Bild gefüllt werden muß. Der Falcon schafft immerhin das doppelte. Er wäre dann aber bloß noch eine Art Fernsteuerung für den Knecht.

Ich weiß natürlich sehr gut, warum ich für´s iNet immer meinen Labtop benutze und nie auf die Idee gekommen bin, meine Ataris an´s iNet anzubinden. Aber die neuen Riesenzwerge locken... Wie können wir sie für unsere Oldies nützlich machen?

[tuxie]

Über die Vielen Jahre hinweg sind die Programmierer immer bequemer geworden und haben die Aufgaben an Frameworks übergeben die für die den größten Teil der Arbeiten erledigen. Auf unseren Maschinen gibt es auch z.t. Frameworks und auch große Librarys die viel an Arbeit übernehmen. Es macht sich heute keiner mehr darüber Gedanken wie viel Speicherplatz die Anwendung benötigt oder wie Schnell die Anwendung läuft.  Schau dir doch einfach mal das Kolibri OS an, dies ist in Assembler geschrieben was zur folge hat das die Programmierer sich genau überlegen müssen wie sie was am besten und optimalsten machen müssen da in Assembler oft der Weg Umständlicher ist als z.b. in C oder C++ oder was weiß ich.
Nimm das Kolibri OS und schau es dir genau an, schau dir die Größe an und lass es doch mal Spasses halber auf einem 4Ghz Rechner mit 32Gb Laufen. Klar ist es nicht so Bund wie Windows 10 oder Windows 7, hat aber einen nicht zu verachtenden Funktionsumfang bei wie viel Speicherplatz ?

Und ich bin mir sicher das man auf einem Pentium 1 vieles genauso schnell rendern kann wie auf einem neuen PC wenn die Software auf Performance optimiert wäre.

Das beste Beispiel ist unsere Lightning VME; Bevor wir angefangen haben zu Optimieren lag die Übertragungsrate bei 230kbyte/s

Das ist auch etwas, was ich nicht verstehe. Die Leute denken, mit einem 30 Jahre alten 8 oder 16/32 Bit Rechner kann man uneingeschränkt ins Internet.. Wozu dann die Hardwareentwicklung der letzten 30 Jahre, vom einstelligen Megaherz-Takt zu knapp 4 Gigahertz, von wenigen KB RAM zu heute oft 16 oder gar 32 GB in einen Desktop oder Notebook?

Man braucht z.B. nur unter Windows mal den Taskmanager auf zu machen und zu schauen, was der bevorzugte Webbrowser so an Speicher belegt. Bei mir sind es gerade mit FF 57 und etwa 30 Tabs in 3 Fenstern rund 1,2 GB RAM verteilt auf 7 Tasks (der größte davon belegt über 400 MB RAM). Und das muss er, weil heutige Webseiten riesige Datenmengen benötigen. Noch ein Test, Edge auf gemacht, dieses Forum geöffnet, zack, 120 MB RAM belegt. Das ist 30 mal mehr als ein normaler ST haben kann. Und selbst in die wenigsten TT oder Falcon können per spezieller Erweiterung (Magnum TT, Storm, ct60) so viel RAM eingebaut werden.

Oder mal das Grafikprogramm Photoline oder GemView geöffnet und darin die JPG aus einer einigermaßen modernen Digitalkamera geöffnet. Das dauert selbst auf einem TT mitunter Minuten! Alle Webseiten sind voller eingebetteter JPG-Bilder.

Ich erinnere mich auch noch an meine ersten Java-Script-Experimente unter Windows 98SE mit einem Pentium 200 MMX. Mit ganz einfachen Scripten lief der Prozessor bei 100% Auslastung. Kein Atari-kompatibler Rechner (außer die halbwegs kompatible Firebee) erreicht derzeit 200 Mhz Takt. Bei Flash wäre es ähnlcih, gäbe es das für Webbrowser auf dem Atari.

Wenn der PC ein MP3 abspielt, merkt man das an der Systemauslastung nicht. Lässt man das den TT machen, ertönt nach 10 Sekunden ein 1 Sekunden langer Musikfetzen, dann rechnet der TT erstmal wieder 10 Sekunden bis zum nächsten Fetzen Musik.

Das sieht heute alles halt so selbstverständluch aus, man macht ne Webseite auf und die ist sofort da und das Video in FullHD läuft los, währenddessen hat der PC-Prozessor aber 10 Millionen Maschinebefehle ausgeführt, für die ein C64, ST, Amiga oder so aber einen ganzen Tag brauchen, wenn nicht eine ganze Woche.

Diese Dimensionen wollen vielen Leuten nicht in den Kopf rein.

[mfro]

Web-Browser sind längst keine Web-Browser im ursprünglichen Sinn mehr.

Das sind virtualisierte Multitasking-Betriebssysteme mit programmierbaren (JS u.a.) interfaces. Also eigentlich "Emulatoren". Die Fähigkeiten dieser "Betriebssysteme" gehen dabei weit über das hinaus, was man zu Atari-Zeiten unter Betriebssystem verstanden hat.
Allein an einer SSL-Verschlüsselung rechnet sich ein ST halb tot.

Also eine hochkomplexe Virtualisierungsumgebung.

Oder - anders betrachtet - gigantische Ressourcenverschwendung...

[ari.tao]

^^-- Das sehe auch ich so ganz ähnlich. Allerdings hat ASM-Optimierung ebenfalls ihre Grenzen - sonst endet´s in einer anderen Verschwendung, nämlich der von ManPower.

Es macht sich heute keiner mehr darüber Gedanken wie viel Speicherplatz die Anwendung benötigt oder wie Schnell die Anwendung läuft.

Doooch, ich - aus alter Gewohnheit.

Über die Vielen Jahre hinweg sind die Programmierer immer bequemer geworden und haben die Aufgaben an Frameworks übergeben die für die den größten Teil der Arbeiten erledigen. Auf unseren Maschinen gibt es auch z.t. Frameworks und auch große Librarys die viel an Arbeit übernehmen.

Modularität trägt erheblich dazu bei, Fehler zu minimieren - und macht deshalb komplexe Systeme überhaupt erst möglich. Die Bequemlichkeit versteckt sich bloß dahinter.