Hello, Guest the thread was viewed840 times and contains 18 replies

last post from Retrofan at the

Artikel auf Golem: "Multitasking im 8-Bit-Stil"

  • Auf Golem ist ein Artikel zum CPC mit SymbOS erschienen. :ChPeace


    Wir bringen unseren Schneider CPC mit einem Betriebssystem mit

    grafischer Oberfläche und viel Speicher im Golem retro_Spezial

    ins neue Jahrtausend.


    Multitasking im 8-Bit-Stil

  • :achtung Alle 6510-Verteidiger sofort in Verteidigungs-Linie antreten .

    Die Z80-Seuche darf sich nicht weiter verbreiten, jeder Konspirant wird mit :sm::dafuer: bestraft. :bgdev

  • In Abwandlung eines bekannten Sagers:


    "Ein 6502 kann nur eine Sache zu einer Zeit tun, während ein Z80 durchaus in der Lage ist, zeitgleich mehrere Dinge nicht richtig zu machen ..."

    :guenni:

  • Ich find den Bericht von Martin richtig gut gelungen!

    Die genannte 64K Beschränkung beim C64 bezieht sich nur auf das fehlende mögliche RAM-Bankswitching.


    (PS: Jeder, der mich kennt, weiß, daß ich unendlichen Respekt vorm C64-GEOS und seinen Killer-Apps habe (GeoWrite, GeoCalc, GeoPublish).)


    Eventuell kommt nochmal was ausführlicheres später)


  • Die genannte 64K Beschränkung beim C64 bezieht sich nur auf das fehlende mögliche RAM-Bankswitching.

    Lässt sich nachrüsten :


    https://archive.org/details/64er_1987_07/page/n33/mode/2up


    Ich hab sie, nur noch nicht aufgebaut, seit 37 Jahren. :schande:


  • Die genannte 64K Beschränkung beim C64 bezieht sich nur auf das fehlende mögliche RAM-Bankswitching.

    Lässt sich nachrüsten :


    Coole Sache! Schade, daß sowas nicht rein über den Expansion-Port möglich ist. Wenn man bedenkt, was vielleicht sonst passiert wäre...

  • Echtes Bankswitching im C64, serienmäßig schnelle Verbindung zur Floppy und mehr/erweiterbares RAM in der Floppy, und man hätte für kaum erhöhte Produktionskosten eine Multiprozessormaschine mit potenziell sehr viel RAM gehabt...


    Zum Bankswitching hätte es auch schon geholfen, die 8 gemultiplexten Adressleitungen, die 8 Datenbits und CAS/RAS/WE per Jumperfeld intern sauber verfügbar zu machen (mit CASOUT und CASIN, damit man per Modul dem internen RAM das CAS wegnehmen kann). Dann hätte man wenigstens intern Speichererweiterungen ganz trivial einbauen können.


    Aber so war der C64 halt marketingmäßig wohl nicht positioniert...

  • Aber so war der C64 halt marketingmäßig wohl nicht positioniert...

    Mit CPC wäre das nicht passiert. :prof:

    Richtig! Mit dem CPC ist nämlich überhaupt nix passiert.
    Der ist sang- und klanglos(sic! :-D ) in der Versenkung verschwunden. :bgdev

    :thumbsup:  :bgdev


    ich seh schon den :guenni: kommen. :D

  • Aber so war der C64 halt marketingmäßig wohl nicht positioniert...

    Mit CPC wäre das nicht passiert. :prof:

    Richtig! Mit dem CPC ist nämlich überhaupt nix passiert.
    Der ist sang- und klanglos(sic! :-D ) in der Versenkung verschwunden. :bgdev

    :guenni:

  • Aber so war der C64 halt marketingmäßig wohl nicht positioniert...

    Mit CPC wäre das nicht passiert. :prof:

    Richtig! Mit dem CPC ist nämlich überhaupt nix passiert.
    Der ist sang- und klanglos(sic! :-D ) in der Versenkung verschwunden. :bgdev

    :guenni:

    Wieso, hat der noch einen CPC?

    Kann ich mir nicht vorstellen. :-D

  • Ich finde ja alternative Betriebssysteme (vor allem mit GUI) für klassische Plattformen sehr spannend. Dass sich das SymbOS-GUI einiges bei Windows 95 (und folgende) abgeguckt hat (markant die Startleiste), ist wahrscheinlich der Entstehungszeit geschuldet. Die erste SymbOS-Version wurde 2006 veröffentlicht und da klang wahrscheinlich das erste brauchbare Windows (gerade mal eine Dekade her) noch ein wenig nach.


    Beeindruckend finde ich weniger das Multitasking (aus meiner Sicht müssten auf einem 8-Bitter die Fenster nicht alle permanent aktualisiert werden, was sicherlich der Vordergrund-App Rechenzeit raubt) als viel mehr, dass das OS multiplattformkompatibel ist. DAS hat für den 65xx noch keiner geschafft, oder? GEOS z.B. gab es neben dem C64/C128 auch für den Plus/4 und den Apple II aber soweit ich weiß, waren die Apps nicht untereinander kompatibel.


    Wäre das beim 6502/6510 so viel schwieriger als beim Z80?


    Etwas schade finde ich, dass das OS anscheinend bei Anwendungs-Programmierern nicht so sehr eingeschlagen ist. Die meisten verfügbaren Apps sind kleine Hilfs-Tool, um das Arbeiten mit dem OS selbst angenehmer zu machen – und einige Games, die sich vom Multitasking nicht so schnell aus dem Tritt bringen lassen. Die Verfügbarkeit eines eMail-Clients finde ich aber toll.

  • Quote

    Dass sich das SymbOS-GUI einiges bei Windows 95 (und folgende) abgeguckt hat (markant die Startleiste), ist wahrscheinlich der Entstehungszeit geschuldet. Die erste SymbOS-Version wurde 2006 veröffentlicht und da klang wahrscheinlich das erste brauchbare Windows (gerade mal eine Dekade her) noch ein wenig nach.

    Ich weiß, du magst das Win95 Konzept (eigentlich ist es sogar Archimedes Arthur + Startmenu) nicht so :) und bist der Meinung, heute müßten wegen dem Platz 8bit Rechner eher so Handy-mässige UIs haben? Was ich komplett nicht so sehe... Jeder 8bit Rechner hat einen nicht-touch-fähigen Monitor und eine physikalische Tastatur, und die Größe der Bildschirme haben nichts mit denen von Smartphones zu tun.


    Beeindruckend finde ich weniger das Multitasking (aus meiner Sicht müssten auf einem 8-Bitter die Fenster nicht alle permanent aktualisiert werden, was sicherlich der Vordergrund-App Rechenzeit raubt)

    Das ist aber eine Vermuting/Unterstellung ("aus meiner Sicht", "was sicherlich"). Nee, da wird nichts geraubt. Ja klar, wenn Du ein Video laufen läßt, dann wird das System irgendwann langsamer. Ist jetzt auch nicht wirklich verwunderlich. Wenn Du aber einfach ein paar Apps am laufen hast, die ab und zu irgendwas machen, dann merkst Du auch im Vordergrund gar nichts, selbst wenn die im Hintergrund mal was aktualisieren. Bestes Beispiel ist Unzip: Es läuft standardmässig mit niedrigerer Priorität. Man kann also Megabytes an Daten unzippen, aber im Vordergrund merkt man exakt nichts davon, alles ist genauso responsive als wenn eben Unzip nicht laufen würde.

    Fenster werden nicht "permanent" aktualisiert, das wäre ja völlig schwachsinnig. Nur, wenn sich was ändert, warum auch sonst?

    Quote

    Beeindruckend finde ich [...] dass das OS multiplattformkompatibel ist. DAS hat für den 65xx noch keiner geschafft, oder? GEOS z.B. gab es neben dem C64/C128 auch für den Plus/4 und den Apple II aber soweit ich weiß, waren die Apps nicht untereinander kompatibel.

    Danke! Aber was 6502 Zeugs betrifft, ich finde das interessant, warum war das so? Alle genannten Systeme sind 6502 kompatible und sollten einfach auf die GEOS-Api zugreifen. Warum müßten die dann noch wissen, ob darunter ein C64, Apple II, oder 264 liegt?

    Der neue GEOS port für den Atari8bit zeigt doch eigentlich wie es geht, oder müssen da auch alle Apps angepasst werden?


    Quote

    Etwas schade finde ich, dass das OS anscheinend bei Anwendungs-Programmierern nicht so sehr eingeschlagen ist. Die meisten verfügbaren Apps sind kleine Hilfs-Tool, um das Arbeiten mit dem OS selbst angenehmer zu machen – und einige Games, die sich vom Multitasking nicht so schnell aus dem Tritt bringen lassen. Die Verfügbarkeit eines eMail-Clients finde ich aber toll.

    Tja, so ist das leider im Jahr 2024 :( Bin trotzdem froh, daß es in diesem Jahr wieder viel neues Zeugs gab, wie z.B. den SymbOS C Compiler aus Texas, mit dem man sogar Pozix-Anwendung von Unix für SymbOS compilieren kann. Vom selben Autor kamen auch noch mehr coole Sachen., ja, endlich auch Solitair, was mich schon Tage gekostet hat.

    SymCalc aka "Excel" für den Z80 hat mir dieses Jahr allerdings am meisten Spaß gemacht.


    http://www.symbos.de/bloginfo.htm?269

  • Ich weiß, du magst das Win95 Konzept [...] nicht so

    Ich behaupte, das siehst du falsch. Ich habe W95 sogar als erstes brauchbares Windows bezeichnet, was ja erstmal eher ein Lob denn ein Tadel ist. Was ich bemängele ist, dass einige Hobby-GUI-Bastler meinen, es sei (aufgrund des unwiderlegbaren wirtschaftlichen Erfolgs) das beste Konzept unter vielen oder sogar das einzig denkbare. Ich habe in den letzten Dekaden oft gesehen, dass GUI-interessierte Coder erst einmal Taskleiste, überlappende Fenster, Menüleiste usw. programmiert haben, bevor auch nur ein einziger Gedanke verschwendet wurde, ob das alles für potentielle bzw. wünschenswerte Apps nötig ist. Erst einmal die WIMP-Vierfaltigkeit runtercoden, bevor man grundsätzlich versteht und definiert, wofür potentielle Anwendungen und Szenarien das "Gelumpe" einsetzen sollen.


    Das ist aber eine Vermuting/Unterstellung ("aus meiner Sicht", "was sicherlich")

    Richtig erkannt – meine Formulieren sind da eindeutig. Ich versuche meistens klar zu trennen, was Sache und was Meinung ist.


    da wird nichts geraubt.

    Nun ja, wenn sich 1 MHz auf 12 aktive Tasks verteilt, bekommt eine einzelne zwangsläufig etwas weniger ab (natürlich nicht nur 1/12 aber eben auch nicht 100%). Das ist kaum von der Hand zu weisen. Der Scheduler, der die Rechenleistung verteilt, benötigt auch etwas eigene Rechenleistung, nichts bekommt man geschenkt. Das ist übrigens der Grund, weswegen viele frühe PC/HCs kein Multitasking hatten, obwohl das Prinzip dank Mainframes, Mini-Computern und Unix bekannt war. Auch der Macintosh und Atari ST (anfangs single-tasking-Maschinen) bekamen zu spüren, dass Multitasking (MultiFinder, MultiTOS/MiNT) den Rechner aus Sicht der Vordergrund-App etwas langsamer macht.


    Bestes Beispiel ist Unzip: Es läuft standardmässig mit niedrigerer Priorität. Man kann also Megabytes an Daten unzippen, aber im Vordergrund merkt man exakt nichts davon, alles ist genauso responsive als wenn eben Unzip nicht laufen würde.

    Auf einem 1- bis 4-MHz-Rechner? OK, vielleicht wenn wirklich nur entpackt wird, wenn keine Nutzer-Interaktion stattfindet.


    Fenster werden nicht "permanent" aktualisiert, das wäre ja völlig schwachsinnig. Nur, wenn sich was ändert, warum auch sonst?

    Sie können aber permanent aktualisiert werden. Wenn ich auf meinem Rechner multitaske, dann findet nicht nur im vordersten Fenster etwas statt. Selbst wenn ich nur etwas im Hintergrund entpacke, wird irgendwo ein Fortschritts-Balken aktualisiert und im Datei-Browser erscheinen die entpackten Dateien.


    Aber was 6502 Zeugs betrifft, ich finde das interessant, warum war das so? Alle genannten Systeme sind 6502 kompatible und sollten einfach auf die GEOS-Api zugreifen. Warum müßten die dann noch wissen, ob darunter ein C64, Apple II, oder 264 liegt?

    Genau das war auch meine Frage. Haben die Z80-Rechner da konzeptionelle Vorteile? Oder haben die GEOS-Entwickler da einfach "geschludert"?


    SymCalc aka "Excel" für den Z80 hat mir dieses Jahr allerdings am meisten Spaß gemacht.

    Finde ich (nach Video-Beurteilung) auch gut.


    bist der Meinung, heute müßten wegen dem Platz 8bit Rechner eher so Handy-mässige UIs haben? Was ich komplett nicht so sehe... Jeder 8bit Rechner hat einen nicht-touch-fähigen Monitor und eine physikalische Tastatur, und die Größe der Bildschirme haben nichts mit denen von Smartphones zu tun.

    Ich glaube, du missverstehst mich auch hier. Sie müssen keine Handy-mäßigen GUIs haben. Ich finde es aber nachlässig bis fahrlässig, so zu tun, als habe es in den letzten 30 Jahren keine IT-Entwicklung bzgl. UI/UX gegeben. Selbst Windows sieht nicht mehr aus wie Windows (95). Und Handys und Tablets haben längst gelernt, mit externen Tastaturen und Mäusen umzugehen. Es stimmt auch nicht, dass viele Homecomputer-Bildschirme und Smartphone-Screens nichts miteinander zu tun hätten. Auf beiden ist "wenig Platz" – oft zu wenig für Fenster-Gedöns. Windows CE/Mobile hat doch gezeigt, dass es eine schlechte Idee ist, auf kleinen Screens krampfhaft eine Desktop-Metapher umzusetzen. Auch wenn man einen Atari ST mit Farbmonitor hatte, konnte man feststellen, dass 320 x 200 Pixel (ST-low) arg wenig für multiple Windows sind (was nützt z.B. der Papierkorb auf dem Desktop, wenn ihn andauernd Fenster verdecken? – und 4 Fenster (max. beim ST) sind auf der kleinen Fläche eher schon zu viel).


    Viele von SymbOS unterstützte Systeme können 640 px horizontal darstellen. Das ist das Doppelte von dem, was C64 und Atari XL/XE maximal zur Verfügung haben. Bei doppelt so vielen Pixeln kann ein Fenster schon eher mal sinnvoll sein, um den Bildschirm aufzuteilen. Aber was will man bei 320 x 200 Pixeln noch großartig aufteilen? Da stören die ganzen Überlappungen doch eher als wenn man z.B. fullscreen oder mit (flexiblen aber nicht überlappenden) "Areas" (oder Frames oder Cells) – wie von mir vorgeschlagen – arbeitet.


    Es geht mir dabei gar nicht darum, einen gegensätzlichen Ansatz zu forcieren, sondern einfach darum, anzuregen, zu reflektieren, was wirklich sinnvoll ist, BEVOR man loscodet und irgendwas aus dem letzten Jahrhundert nachahmt, was man vielleicht "cool" fand, ohne über alternative – auch modernere (aber vielleicht uncoolere) – Möglichkeiten nachzudenken. Und es geht beim GUI auch gar nicht nur um "Bildschirme mit wenig Platz", sondern auch um veränderte Nutzungs-Szenarien. Will man heute mit einem (wenn auch alten) Computer-System das gleiche tun, wie vor 30 oder 40 Jahren? Will man z.B. WLAN und Internet ignorieren? Will man immer noch vorwiegend mit Dokumenten arbeiten? Wofür ein neues OS/GUI? Neue Möglichkeiten bieten?


    Auch generative KI wird Veränderungen bei Userinterfaces und Nutzungs-Szenarien bringen – da stellt sich schnell die Frage, ob das Prompt für Normalo-User so tot ist, wie man noch vor wenigen Jahren glaubte. Und so fort ... Gutes behalten aber Neues nicht ignorieren, und was kann man davon für klassische Systeme nutzen/umsetzen? – vielleicht sogar leichter/sinnvoller als 30 Jahre alte Ideen.