Ja das ist clever.

Motorola hat was ähnliches gemacht für ihre 8 Bit CPU 6809.

Allerdings mit erheblich mehr Aufwand.

Motorola hat der 6809 eine MMU verpasst, die MMU 6829.

Mit der MMU wird ein 6809 System extrem aufgeputscht:

• physikalischer Adressraum von 2MB
• sehr flexibles Banking (32 Pages zu 2KB)
• Super User Modus
• getrennte Adressräume einzelner Tasks
• geschützte IO Bereiche
• Ein User Task läuft in einer 64K Sandbox, wo er nicht raus kann

Die MMU überwacht die Arbeit der CPU. Bei Reset oder Interrupt wartet die MMU bis die CPU die Register auf den User Stack gelegt hat. Bevor die CPU den Interrupt Vektor fetched schaltet die MMU auf die System MAP um. Der System User Modus wird aktiviert.

Dadurch hat jeder User Task seinen eigene 64K Speicher MAP. Es wird kein einziges Byte verschwendet für OS Routinen oder Hardware Vektoren. Der User Task hat die vollen 64K für Daten und Benutzer Code. Das OS selbst und Buffer für Disk Zugriff sind vollkommen separiert.

Erinnert mich daran: Vortrag "Virtueller Speicher für den 6502" - Hans Franke - RETROpulsiv 9.0 (Augsburg).

Könnte man wohl auch mit dem 6502 machen.

Quote from peiselulli

Erinnert mich daran: Vortrag "Virtueller Speicher für den 6502" - Hans Franke - RETROpulsiv 9.0 (Augsburg).

Könnte man wohl auch mit dem 6502 machen.

Ein sehr informatives Video, danke, das kannte ich noch nicht.

Mal ehrlich: 8-Bit CPUs waren Spielzeug und nicht für richtige Computer gedacht. Die Leistung reichte eh nur für einen Task, und dass nur mit sehr schlankem oder gar keinem OS.

Hardware-banging in Assembler war doch nötig, um überhaupt akzeptable Performance für irgendwas zu erreichen.

Was will man da vor was und wem schützen?

Entweder die Software läuft oder sie ist buggy und crasht. Dann gibt es ein Reset und die nächste Software wird genommen.

Eine MMU für einen 1-4 MHz 8-Bit Computer ist so nützlich, wie ein Spoiler am Trabi.

Quote from RexRetro

Mal ehrlich: 8-Bit CPUs waren Spielzeug und nicht für richtige Computer gedacht. Die Leistung reichte eh nur für einen Task, und dass nur mit sehr schlankem oder gar keinem OS.

Hardware-banging in Assembler war doch nötig, um überhaupt akzeptable Performance für irgendwas zu erreichen.

Was will man da vor was und wem schützen?

Entweder die Software läuft oder sie ist buggy und crasht. Dann gibt es ein Reset und die nächste Software wird genommen.

Eine MMU für einen 1-4 MHz 8-Bit Computer ist so nützlich, wie ein Spoiler am Trabi.

Du hast dir noch nie OS9 angeguckt, hmmm?

Es gab 8 Bit Computer die Multitasking und Multiuser fähig waren, zum Beispiel der Positron 9000.

Da konnten 8 Studenten daran arbeiten.

Und das lief wirklich sehr flink und flüssig.

Aber man muss gar auf solche High Tech Maschinen wie die P-9000 gucken.

Der Tandy CoCo-3 hatte auch schon OS9.

Quote from Diddl

Du hast dir noch nie OS9 angeguckt, hmmm?

Es gab 8 Bit Computer die Multitasking und Multiuser fähig waren, zum Beispiel der Positron 9000.

Da konnten 8 Studenten daran arbeiten.

Und das lief wirklich sehr flink und flüssig.

So ein (ähnliches) OS9-System mit Terminals hatten wir auch an unserer Schule, worauf wir Pascal und Assembler gelernt haben.

Aber das System ließ sich durch den Aufruf eines bestimmten, eigentlich privilegierten Befehls komplett einfrieren und musste danach resetet werden, mit evtl. Datenverlust an allen Arbeitsplätzen. Habe ich natürlich nieee gemacht, um den ahnungslosen Informatik-Lehrer zu ärgern.

Quote from RexRetro

Mal ehrlich: 8-Bit CPUs waren Spielzeug und nicht für richtige Computer gedacht. Die Leistung reichte eh nur für einen Task, und dass nur mit sehr schlankem oder gar keinem OS.

Hmm, Deine Meinung in allen Ehren, aber dann stelle ich mir die Frage, was Du in einem Forum wie diesem hier überhaupt machst?

Und als Unix anno 1970 aus der Taufe gehoben wurde, da wäre man um die Performance eines Z80 mit 4 MHz oder gar eines 6809 mit 2 MHz sehr froh gewesen... Warum ich diese beiden CPUs erwähne und nicht die 6502? Weil diese beiden 8bit-CPUs bis heute -teils embedded in SoCs in vielen industriellen Anwendungen werkeln, in denen teils harte Echtzeit bis runter in den einstelligen ms-Bereich, teils aber auch zig Tasks und deutlich mehr als 64KB Speicher zu bedienen sind.

Und die-meist Z80 basierten- CP/M Computer der frühen 1980er hatten mit ebendiesem auch ein "richtiges" Betriebssystem, das intern durchaus mehrere Tasks pseudoparallel laufen hatte, wie übrigens auch der C64 schon im Basic-Prompt 2 Tasks wechselweise bedient, in Spielen mit Scrolling, Sprite-Kollision und Sound sind es teils 5 oder mehr Tasks und das funktioniert wie zig Millionen Spieler seit 40 Jahren wissen, auch mit 1MHz doch ziemlich zackig, ne hochgetaktete 650x CPU wie im Apple GS war gar in der Lage ein OS mit GUI sinnvoll nutzbar anzutreiben, GEOS am C64 war leider etwas durch den seriellen IEC-Bus ausgebremst...

Spiele und Spielzeug sind zwei verschiedene Paar Schuhe, denn Spiele brauchen meist mehr Rechenleistung und geringere Latenzen als "normale" Anwendungen ;-), daran hat sich bis heute wenig geändert.

Spielzeug sind eher die Touch-Phones heutzutage, wo die immense Rechenleistung ohne jeglichen Gegenwert/Nutzen versickert...

Ein Task ist m.E. dadurch definiert, dass er im wesentlichen unabhängig von anderen Aufgaben läuft. Für den IRQ im Hintergrund von Basic ist das m.E. erfüllt, aber die verschiedenen Aufgaben in einem Spiel sind ja meist alles andere als unabhängig, und oft allesamt durch die Framerate getimed und damit komplett sequentiell. Tatsächlich finden sie ja sogar oft allesamt innerhalb der selben IRQ-Routine statt, während im Mainloop praktisch nix passiert.

Ein "richtiger" Task erfordert das Speichern und Wiederherstellen des entsprechenden "Zustands". Im einfachen Fall (wie bei Basic mit IRQ) sind das nur Prozessorregister und Flags. Für ein wenig aufwändigere Tasks wäre das noch der Stack, I/O-Zustände etc. Dafür ist zumindest der 6502 (z.B. durch seinen festen HW-Stack) denkbar schlecht vorbereitet (vom Z80 habe ich zu wenig Ahnung um das zu bewerten).

Quote from Claus

Dafür ist zumindest der 6502 (z.B. durch seinen festen HW-Stack) denkbar schlecht vorbereitet (vom Z80 habe ich zu wenig Ahnung um das zu bewerten).

Naja, prinzipiell gebe ich dir recht, jeder "TASK" benötigt einen eigenen HW Stack Bereich.

Aber das hängt nun mal nicht von der CPU ab.

Wie man auch in dem oben verlinkten Video sehen kann.

Ein bisschen Hardware (10 bis 12 TTL Chips) und schon hat jeder Task seinen eigenen Zeropage und HW Stack, auch bei einer 6502.

Der RAM Bereich wird eingeblendet, jeweils ein anderer für jeden Task.

Im Video spricht er von 40µS für einen Taskwechsel.

Das fällt kaum ins Gewicht beim ausführen von 10 oder 15 Tasks.

Es gab ja alles schon vor 40 Jahren.

Es wurde halt nur sehr selten genutzt.

Vermutlich haben die meisten Anwender keinen Bedarf dafür gehabt.

Wie auch immer, hätten sich MMU und Co durchgesetzt bei 8 Bitter, dann hätte sich die breite Einführung von 16 Bitter stark verzögert.

Quote from Diddl

Es gab ja alles schon vor 40 Jahren.

Es wurde halt nur sehr selten genutzt.

Vermutlich haben die meisten Anwender keinen Bedarf dafür gehabt.

Wie auch immer, hätten sich MMU und Co durchgesetzt bei 8 Bitter, dann hätte sich die breite Einführung von 16 Bitter stark verzögert.

Glaube ich nicht. 8 Bitter mit 1-4 MHz waren einfach zu langsam und hatten zu wenig (vernünftig addressierbaren) Speicher, um für ernsthafte Aufgaben eingesetzt zu werden.

Und MMUs haben sich in der breiten Masse erst mit 32 Bit CPUs durchgesetzt, und wurden teils erst 10 Jahre nach deren Erscheinen ernsthaft für Speicherschutz und virtuellen Speicher richtig genutzt.

80286 - 1982, segmentorientierte MMU, kaum genutzt ( naja, außer die zwo OS/2 Nutzer halt)

68020 - 1984, optionalen MMU als CoPro 68851, paging, kaum in 68K Consumer Systemen, eher in Unix Workstations genutzt

80386 - 1985, Segmente + Paging MMU, erst mit Windows 95 und NT (oder Linux) Mitte der 90er richtig genutzt

68030 - 1985, integrierte paging MMU, fast nur von Unix Systemen genutzt (Consumer HW bekam eher 68EC030 ohne MMU)

Also für mich ist die 16 Bit Ära 68000 und 8088/8086/80186/80286, und da ging es erstmal um mehr Rechenleistung und Speicher von 128KB-16MB.

Ausser dem Amiga waren alle verbreiteten Systeme single-tasking OS mit nur rudimentären Multitasking-Ansätzen (DOS TSRs, Mac OS 6 und TOS accessories).

Dann kooperatives Multitasking meist erst Anfang der 90er (Win-16 API, Mac OS System 7, Multi-TOS).

Keines dieser Systeme hatte richtigen Speicherschutz, virt.Speicher nur in Ansätzen. Wer mehr wollte, sollte zu teureren 68020/68030 Varianten mit angepasstem UNIX System V Rel.2-4 greifen

(Atari TT System V, Amiga 2500UX/3000UX AMIX, Apple Mac II A/UX).

Aber wie viele Fans von ST, AMIGA und Mac haben das getan. Wie viel bezahlbare Software gab es dafür und wie kompatibel war das mit der alten Software?

Und wie teuer im Vergleich zu einer "richtigen" Unix-Workstation?

Quote from Ruudi

Quote from RexRetro

Mal ehrlich: 8-Bit CPUs waren Spielzeug und nicht für richtige Computer gedacht. Die Leistung reichte eh nur für einen Task, und dass nur mit sehr schlankem oder gar keinem OS.

Hmm, Deine Meinung in allen Ehren, aber dann stelle ich mir die Frage, was Du in einem Forum wie diesem hier überhaupt machst?

Dass ich mich für 8 (und 16) Bit Homecomputer interessiere, bedeutet ja noch lange nicht, dass ich sie für ernsthafte Arbeitsgeräte halte. Auch wenn ich die Architektur und das System des IBM-PC/XT/AT nicht mag, und die Geräte für damals sehr überteuert hielt, so würde ich im Zweifelsfall doch lieber an so einen Gerät als an einer 8-Bit Kiste arbeiten wollen.

ZX81 (1KB), VC20 (5KB), diverse 16KB Rechner, waren schon aufgrund der Speicherausstattung Spielzeug. Mit 64KB konnte man vielleicht kleine Texte und Datenbanken betreiben. Die Software war aber meist wegen Speicher und Geschwindigkeitsmangel in ASM geschrieben. Brauchbare Hochsprachencompiler für C/Pascal waren eher PoCs statt ernsthafte Entwicklungssysteme.

Quote from Ruudi

Und als Unix anno 1970 aus der Taufe gehoben wurde, da wäre man um die Performance eines Z80 mit 4 MHz oder gar eines 6809 mit 2 MHz sehr froh gewesen...

1970 war Unix noch ein Spielzeug von gelangweilten Bell Lab Forschern, die von einem richtigen OS-Projekt (Multics) abgezogen wurden. Ja, die verwendete PDP-7 hatte auch wenig Speicher und Leistung, aber das System war ja auch noch komplett in ASM gecodet und hatte weder Speicherschutz noch (gleichzeitig) viele User. Und die PDP-7 war immerhin eine 18 Bit CPU und hatte bis 64K Words, also über 128KB RAM. Aber ein richtig (intern produktiv eingesetztes) Arbeitssystem wurde Unix auch erst nach dem Rewrite in C auf die PDP-11 Familie, also einem noch lange Zeit respektablen 16 Bit Minicomputersystem, das einen deutlich mächtigeren Befehlssatz hat, als ein 6502 oder 8080 (und in größeren/späteren Modellen auch FPU und MMU).

Quote from Ruudi

Warum ich diese beiden CPUs erwähne und nicht die 6502? Weil diese beiden 8bit-CPUs bis heute -teils embedded in SoCs in vielen industriellen Anwendungen werkeln, in denen teils harte Echtzeit bis runter in den einstelligen ms-Bereich, teils aber auch zig Tasks und deutlich mehr als 64KB Speicher zu bedienen sind.

Ich rede nicht von embedded Systemen, da reichen oft 8 Bit und wenige MHz, selbst wenn man in hardwarenahen Hochsprachen wie C programmiert (aber dies auf einem Entwicklungsrechner, nicht der MCU selbst).

Dafür war der 8008, 8080 und 680x und 6502 ja auch gedacht. Aber eben nicht als "Personal Computer" für richtige Arbeit. Die lief deswegen auch noch bis Mitte-Ende 80er in jedem größeren Unternehmen auf der mittleren Datentechnik, und eben nicht 1974-1984 auf irgendwelchen 8-Bit Personal-/Mikro-/Home-Computern mit 1-64 KB. Das war Spielzeug für Nerds und Kids und brauchte daher kein OS mit memory protection.

Quote from Ruudi

Und die-meist Z80 basierten- CP/M Computer der frühen 1980er hatten mit ebendiesem auch ein "richtiges" Betriebssystem, das intern durchaus mehrere Tasks pseudoparallel laufen hatte, wie übrigens auch der C64 schon im Basic-Prompt 2 Tasks wechselweise bedient, in Spielen mit Scrolling, Sprite-Kollision und Sound sind es teils 5 oder mehr Tasks und das funktioniert wie zig Millionen Spieler seit 40 Jahren wissen, auch mit 1MHz doch ziemlich zackig, ne hochgetaktete 650x CPU wie im Apple GS war gar in der Lage ein OS mit GUI sinnvoll nutzbar anzutreiben, GEOS am C64 war leider etwas durch den seriellen IEC-Bus ausgebremst...

Ein paar Hintergrund-Aktivitäten in Interrupts sind kein Multitasking-OS und da diese keine eigenständigen Prozesse beschreiben, müssen sie Daten meistens ohne Schutz mit System und Anwendung teilen.

Und weil sie meist im Interrupt zeitkritisch, sind sie in ASM gecodet. CP/M war sicher ein netter Versuch, auf besseren 8-Bit Kisten wie 4MHz Z80 ernsthaft zu arbeiten. Mit 48-64KB waren einfache Textverarbeitung, Tabellenkalkulation und kleine Datenbanken machbar, Hochsprachen-Compiler (TP) gingen gerade so. Aber nicht umsonst waren das System ratzfatz vom Markt, als es auch nur minimal bessere 8/16Bit Systeme (8088 PC mit DOS) gab.

Warum? Weil man mit DOS immerhin halbwegs problemlos bis 640KB kam.

Und auch da war noch viel in ASM, kein richtiges Multitasking, kein Speicherschutz.

Quote from Ruudi

Spiele und Spielzeug sind zwei verschiedene Paar Schuhe, denn Spiele brauchen meist mehr Rechenleistung und geringere Latenzen als "normale" Anwendungen ;-), daran hat sich bis heute wenig geändert.

Und wurden auf 8 Bit in ASM gecodet und dabei die gesamte HW direkt übernommen, für ein ausgereiftes OS war da kein Bedarf und keine Ressourcen.

Quote from Ruudi

Spielzeug sind eher die Touch-Phones heutzutage, wo die immense Rechenleistung ohne jeglichen Gegenwert/Nutzen versickert...

Ein modernes Smartphone nutzt sehr wohl die vorhandene Rechneleistung. Echtzeit-Bilderkennung und Optimierung in 12 Megapixel HDR Bildern oder 4K Videos macht man auch nicht mit 8Bit, 1MHz und 64KB.

Fast fotorealistisches 3D Rendering mit 60 fps in mehr als Full HD im Web-Browser, schafft auch kein Amiga 4000/060 bei noch so optimaler ASM Programmierung.

Quote from RexRetro

Aber nicht umsonst waren das System ratzfatz vom Markt, als es auch nur minimal bessere 8/16Bit Systeme (8088 PC mit DOS) gab.

Ich geb dir in vielem Recht, besonders grundsätzlich in der Aussage, dass 8-Bit-HCs so grade unter den Minimalanforderungen für ernsthafte Arbeitsgeräte dahin vegetieren, aber hier würde ich es doch anders sehen. CP/M ist "ratzfatz" vom Markt gewesen, weil IBM MS-DOS, das in den ersten Versionen kein Stück besser gewesen ist als CP/M, stark bevorzugt hat. Die Geschichte zu Gary Kildall, und wie er IBM vor den Kopf gestoßen hat, ist doch bekannt, und wie Bill Gates die Situation ausgenutzt hat. Wäre es damals CP/M geworden, hätte sich das ganz genauso weiterentwickelt wie dann eben MS-DOS, das sogar als quick-and-dirty-Nachbau von CP/M begonnen hat.

Quote from Claus

Dafür ist zumindest der 6502 (z.B. durch seinen festen HW-Stack) denkbar schlecht vorbereitet (vom Z80 habe ich zu wenig Ahnung um das zu bewerten).

Deshalb hatten ja spätere Reinkarnationen der 6502 Serie wie 65816 dann verschiebbare Zeropages (Register-Ersatz) und variablen Stapelspeicher, d.h. konnte man bei sauberer Programmierung und entspr. Speichermodell auch die 2nd generation 65xx noch dazu ertüchtigen...

Was den "einen" IRQ bei Spielen anbelangt, so bin ich da anderer Meinung, min. 2 (Timer und Sprite-Collision) sind doch eigentlich immer aktiv, natürlich auf ein und den selben HW-IRQ gelegt (mehr hat der 6502 eben nicht und dedizierte IRQ-Controller eben die CBMs auch nicht), aber nach kurzer Unterscheidung "wer klopft an", geht es dann in die jeweilige Routine. Natürlich muss man dann aufpassen, nicht den Stapel durch zeitlich überlappende IRQs zum Überlauf zu bringen.

Z80 hat damit deutlich weniger Probleme, wie ja insgesamt ein deutlich ausgefeilteres "industrietaugliches" Design, aber dadurch natürlich auch komplizierter in Assembler zu programmieren.

Und was die Verdrängung von CP/M durch MS-Dos anbelangt: bis Mitte der 1980er lief CP/M durchaus noch parallel und belegte das niedrigere PROFESSIONELLE Preissegment, bis dann die PC-Clones allmählich dieses Feld übernahmen. Und es gab durchaus Z80- oder 6809-basierte Multiuser-Systeme, die im Mittelstand sich reger Beliebtheit erfreuten, da der Preissprung zur mittleren Datentechnik insb. beim TCO extrem hoch war.

Ne, die Mehrzahl der Spiele verwendet wohl einen Raster-IRQ, damit Animationen smooth aussehen. Wenn das Spritekollisionsregister überhaupt verwendet wird (und Kollisionen nicht einfach anhand der Koordinaten detektiert werden), dann wird es wohl einfach im selben IRQ gelesen, anstatt einen Extra-IRQ durch die Kollision auszulösen.

Quote from Ruudi

Z80 hat damit deutlich weniger Probleme, wie ja insgesamt ein deutlich ausgefeilteres "industrietaugliches" Design, aber dadurch natürlich auch komplizierter in Assembler zu programmieren.

Mehrere IRQ, also mehrere Hardware Vektoren wären natürlich ein großer Vorteil. Die 6502 ist für low cost ausgelegt. Man hat alles so billig wie möglich gemacht.

Aber aus heutiger Sicht lässt sich auch dieses Manko sehr leicht beheben. Zumindest bei der neueren 65C02. Die signalisiert ja einen Vektor Ferch. Sehr einfach kann man da den Vektor durch eine Zusatz Hardware (IRQ Manager) anbieten, sodass die "richtige" IRQ Routine sofort automatisch angesprungen wird.

Quote from Zirias/Excess

Quote from Ruudi

Was den "einen" IRQ bei Spielen anbelangt, so bin ich da anderer Meinung, min. 2 (Timer und Sprite-Collision) sind doch eigentlich immer aktiv,

Das ist eigentlich nur in Spielen mit eher trivialer Grafik überhaupt machbar. Sobald man mehrere IRQ-Quellen hat wird es passieren, dass Raster-IRQs "verzögert" ausgeführt werden. Und sobald die Grafik etwas komplexer wird, wird das direkt sichtbar sein. Selbst das Timing fürs Musik spielen hängt deshalb fast immer am VIC-II.

Sprite-Collision kann man natürlich auch so abfragen (einmal per Frame). Ich persönlich halte es für DAS Missfeature des VIC, weil das in Software IMHO genausogut geht. Aber manche Spiele verwenden es tatsächlich

Dumme Frage: Wie? Hardwaremässig wird doch nur dann ein IRQ ausgelöst, wenn wirklich zwei nicht-Hintergrund-Pixel übereinander zu liegen kommen, oder täusche ich mich? Softwaretechnisch ist es leicht, die Rechtecke abzufragen, aber die Berechnung? Oder kann man das aus einem Register auslesen?