Da ich weder fit bzgl. 6502- noch x64-Maschinencode bin, will ich mir sowas nicht antun. Aber vielleicht mag ja jemand genauer reinschauen.
Mir fiele nur ein Name ein, dem ich sowas zutrauen würde und der -da seit ein paar Jahren in Rente- auch Zeit dafür haben könnte: Andreas Stiller von der ct, der Prozessorflüsterer und Autor von FACHbeiträgen, die dieses Wort noch verdienten!
Der ist nicht zufällig auch hier im Forum?
Da ich weder fit bzgl. 6502- noch x64-Maschinencode bin, will ich mir sowas nicht antun. Aber vielleicht mag ja jemand genauer reinschauen.
Mir fiele nur ein Name ein, dem ich sowas zutrauen würde und der -da seit ein paar Jahren in Rente- auch Zeit dafür haben könnte: Andreas Stiller von der ct, der Prozessorflüsterer und Autor von FACHbeiträgen, die dieses Wort noch verdienten!
Genau. Wäre doch ein prima Artikel für die nächste "Retro"-ct. Am besten mit dem Label "Hardcore" versehen.
Der ist nicht zufällig auch hier im Forum?
Leider wohl eher nicht...
[...] häufigen, willkürlichen Abstürzen aufgrund timing-Problemen (trotz mehrfachen Versuchs, dass mittels dem Potentiometer zu korrigieren) [...]
Das war mit dem Vorgänger der Flash8, Turbo Process, ähnlich.
auch eine riesengrosse REU könnte man damit realisieren
die unterstützt doch prinzipiell bis zu 16 MB. Auch mit einer erweiterten GeoRAM wären mehr als 512 kB möglich, wenn man weitere Bits zur Bankumschaltung realisieren würde.
würde sowas nicht reichen?
Als GeoRAM Ersatz gibt es doch NeoRAM. Hab gerade eine gekauft mit 2 mb, da sollte ich sicherlich die wichtigsten GEOS-Files und Apps unterbringen können ....
Als GeoRAM Ersatz gibt es doch NeoRAM. Hab gerade eine gekauft mit 2 mb, da sollte ich sicherlich die wichtigsten GEOS-Files und Apps unterbringen können ....
Dann müssen wir jetzt wohl bald -nach dem Kompressor-Thread neulich- auch bald mit "Notstromaggregate-taugt-das-was"- Threads hier rechnen, damit die Daten sicher sind im NEORAM... 
Bin ja nun kein Geos-User (nie gewesen, was den C64 anbelangt, aber GeoWorks am PC und ab 1996 dann im Nokia Communicator, das war meine Welt..), daher die Frage:
SD2IEC und Jiffy-DOS, wäre das nicht die bessere Datei-Ablage?
GEOROM (für schnellen Start) hat ja offenbar noch keiner hinbekommen...
kein Notstromaggregat nötig.
Das ist ja das schöne am NeoRAM, der Speicher ist Batterie-gepuffert.
Mein Plan ist es daher, eine fertige 2mb NeoRAM einzurichten mit einem möglichst umfangreichen GEOS.
Die RAMCartridge kann ich dann einfach vom C64 abziehen und genauso am SX64 oder C128 verwenden.
Und wenn das alles so funktioniert, also kompletter Boot von der NeoRAM ohne Floppy, sollte man den Ram-Inhalt theoretisch auch
für andere hier bereitstellen können, also für diejenigen, die GEOS einfach mal ausprobieren wollen ohne vorher viel Admin-Arbeit reinzustecken.
Da an dieser Stelle OT, hab ich dazu hier einen eigenen Post
Dann müssen wir jetzt wohl bald -nach dem Kompressor-Thread neulich- auch bald mit "Notstromaggregate-taugt-das-was"- Threads hier rechnen, damit die Daten sicher sind im NEORAM...
Sofern im korrekten Unterforum angelegt, spricht nichts gegen einen Thread zu dem Thema.
- Der 6502 hat nicht viele Befehle. x64 hat inzwischen über 1000. Da sollte es oft was "Passendes" geben.
Der Z80 hat auch über 1000 Befehle. 
- Der 6502 hat nicht viele Befehle. x64 hat inzwischen über 1000. Da sollte es oft was "Passendes" geben.
Der Z80 hat auch über 1000 Befehle.
Opcodes sicher. Zumindest mit all den undokumentieren zusammen sind es afair ca. 1200 beim Z80. Aber bei x86/x64 sind es an die 1200 Befehle.
Mit allen möglichen Register- und Speicheradressierungs-Varianten sind es ein Vielfaches.
Muss es halt auch sein. Der Z80 ist nunmal eine recht einfache 8/16-Bit Integer CPU und hat nicht mal Multiply oder Divide.
x86/x64 hat 16/32/64 Bit Modi und mit all den SIMD-Erweiterungen 8/16/32/64/80/128/256/512-Bit Operationen für Integer und Fließkommavarianten.
Gerade die ganzen MMX/SSE*/AVX* Varianten haben die ISA aufgebläht. Und demnächst soll wohl auch noch Unterstützung für SIMD mit fp16 kommen (wie es GPUs haben und es gerne für Deep Learning nutzen).
Also ja: der Z80 hat deutlich mehr Opcodes als ein 65xx. Aber gegenüber modernen CISCs (und auch RISCs - so "reduced" wie der Name suggeriert sind die auch nicht mehr) ist das alles ein Klax.
Opcodes sicher. Zumindest mit all den undokumentieren zusammen sind es afair ca. 1200 beim Z80. Aber bei x86/x64 sind es an die 1200 Befehle.
Mit allen möglichen Register- und Speicheradressierungs-Varianten sind es ein Vielfaches.
Haben die die Anzahl so stark erweitert? Mein Buch vom Rudolf Schief geht nur bis zum 386er und da sind die Befehle sehr überschaubar.
Meine Sammlung von Z80 Befehlen/Opcodes hat 1268 Einträge in einer Exceltabelle.
Meine Sammlung von Z80 Befehlen/Opcodes hat 1268 Einträge in einer Exceltabelle.
Und wieviele davon sind sinnvoll nutzbar?
Schon die offiziellen waren viel zu viel, das kann sich kein Mensch mehr merken und einen wirklich optimierenden Compiler dafür zu schreiben ist auch fast unmöglich...
Zudem sind viele Register nicht immer optimal belegbar und erschweren auch die Portierung von Software, da jedes Betriebssystem sich jeweils einige dieser Register "reservierte", was direkt Einfluss auf den Code hat... Hier ist das Zero-Page-Konzept der 6502 überlegen, wenngleich es natürlich - wie vieles Andere - nicht konsequent implementiert wurde...
Das war ja der große Vorteil der 6502-CPU, dass diese quasi RISC aus Anwendersicht vorweg nahm und mit einer überschaubaren Anzahl an Befehlen und einer -natürlich auch der sehr einfachen Architektur geschuldeten- fast vollständigen Orthogonalität eine sehr logische und "menschengerechte" CPU ist, auf Assemblerebene versteht sich.
Und es war der Start eines weltweiten Siegeszuges von Risc, dass sich Acorn für die Entwicklung der (strong-)ARM Architektur auf die 6502 als Vorlage stützte, aber nicht auf HW-Ebene, wie beim 65C816, sondern nur strukturiell.
Was x86 oder x64 anbelangt, müsste man dort -spätestens ab dem Ur-Pentium- eine Ebene tiefer in die MikroCodes gehen, da diese CISC-CPUs unterhalb der Assembler-Ebene eben noch eine programmierbare (inzwischen sogar nachträglich updatebare!) Mikrocode-Ebene besitzen, wie man bei den div. Schwachstellenbehebungen von Intel wie AMD die letzten Jahre ja gut mitverfolgen konnte...
Die Nutzung von illegal opcodes beim 6502 und in geringerem Umfang auch beim Z80 (Sinclair, Schneider ohne CP/M, MSX?) war damals historisch gesehen der hohen Raubkopierrate und damit verbunden der Notwendigkeit eines möglichst langen zeitlichen Vorsprungs zw. Erscheinen des Originals und den ersten erfolgreichen Hacks geschuldet, es wurde eben jede aber wirklich JEDE Möglichkeit genutzt, um Verwirrung im Code zu stiften und damit etwas Zeit zu gewinnen. Spiele sind ja auch nix wirklich Kritisches, d.h. konnte nicht viel schiefgehen, worst case war eben, dass es auf zukünftigen Varianten möglicherweise nicht laufen würde, was aus Herstellersicht so schlecht ja nun auch nicht wäre...
Allerdings ist es eine Unsitte, die man keinesfalls unterstützen sollte, d.h. bin ich auch kein Fan der "Demo"-Szene, die nun auch sehr viel damit operieren!
Und wieviele davon sind sinnvoll nutzbar?
So viele Befehle sind es ja nicht wirklich. Das ist nur aufgebläht weil es so viele Register gibt.
Das war ja der große Vorteil der 6502-CPU, dass diese quasi RISC aus Anwendersicht vorweg nahm
Und der Z80 nahm das Multiprocessing vorweg, durch den doppelten Registersatz. 
Die Nutzung von illegal opcodes beim 6502 und in geringerem Umfang auch beim Z80 (Sinclair, Schneider ohne CP/M, MSX?)
Die undokumentierten machen in meiner Sammlung 251 Befehle aus. Da bin ich mir aber nicht sicher ob es wirklich schon alle sind.
Und dann soll es noch diesen geheimnisvollen MEMPTR im Z80 geben.
Die Nutzung von illegal opcodes beim 6502...
Allerdings ist es eine Unsitte, die man keinesfalls unterstützen sollte, d.h. bin ich auch kein Fan der "Demo"-Szene, die nun auch sehr viel damit operieren!
Warum nicht?
Was x86 oder x64 anbelangt, müsste man dort -spätestens ab dem Ur-Pentium- eine Ebene tiefer in die MikroCodes gehen, da diese CISC-CPUs unterhalb der Assembler-Ebene eben noch eine programmierbare (inzwischen sogar nachträglich updatebare!) Mikrocode-Ebene besitzen, wie man bei den div. Schwachstellenbehebungen von Intel wie AMD die letzten Jahre ja gut mitverfolgen konnte...
Mikrocode hatte schon der 8086 - und auch 68000 sowie diverse andere Prozessoren aus der Zeit. Die Möglichkeit zum nächträglichen Patchen hat Intel aber erst ab dem Pentium Pro eingebaut.
Was x86 oder x64 anbelangt, müsste man dort -spätestens ab dem Ur-Pentium- eine Ebene tiefer in die MikroCodes gehen, da diese CISC-CPUs unterhalb der Assembler-Ebene eben noch eine programmierbare (inzwischen sogar nachträglich updatebare!) Mikrocode-Ebene besitzen, wie man bei den div. Schwachstellenbehebungen von Intel wie AMD die letzten Jahre ja gut mitverfolgen konnte...
Mikrocode hatte schon der 8086 - und auch 68000 sowie diverse andere Prozessoren aus der Zeit. Die Möglichkeit zum nächträglichen Patchen hat Intel aber erst ab dem Pentium Pro eingebaut.
Ja, klar, aber erst als dieser Mikrocode extern zugänglich wurde, ergab sich defakto aus ANWENDERsicht eine neue Stufe und man ruft heute quasi bei der Programmierung auf der vermeintlichen und "historischen" Maschinenebene nur noch Makros auf, die teils richtig viel Code die Ebene drunter dann enthalten... Am Anfang wars ja eher so, dass da nur ne mehrstufige Statemachine noch drunter lag, mit eben nem ROM, das die richtigen Weichen je Mikroschritt und Befehl stellte, was beim 6502 durch sehr einfache Befehle und den 2-Phasentakt eben gelöst wurde... (stark vereinfacht gesprochen...)
Ja, klar, aber erst als dieser Mikrocode extern zugänglich wurde, ergab sich defakto aus ANWENDERsicht eine neue Stufe
Der Intel-Microcode war aber für Anwender nie wirklich zugänglich, die Updates sind verschlüsselt und bei neueren CPUs zusätzlich signiert. Wirklich Einfluss durch den Programmierer gabs eher auf DEC Alpha (RISC!) mit dessen PALcode oder IIRC auf manchen Modellen aus IBMs System/360-Reihe mit ins RAM geladenen Microcode beim IPL, aber da bin ich mir nicht sicher ob ausser IBM jemals dafür jemand Code geschrieben hat.
man ruft heute quasi bei der Programmierung auf der vermeintlichen und "historischen" Maschinenebene nur noch Makros auf, die teils richtig viel Code die Ebene drunter dann enthalten...
Das ist aber bei allen CPUs mit Mikrocode so, die Stringoperationen eines 8086 werden zB mit einer Schleife im Mikrocode ausgeführt. Beim 68000 ist es sogar zweistufig, da gibt es Mikro- und Nanocode weil gar nicht genug Platz war, um den Prozessor nur mit einem Mikrocode-ROM zu realisieren.
Am Anfang wars ja eher so, dass da nur ne mehrstufige Statemachine noch drunter lag, mit eben nem ROM, das die richtigen Weichen je Mikroschritt und Befehl stellte, was beim 6502 durch sehr einfache Befehle und den 2-Phasentakt eben gelöst wurde
Beim 6502 streiten sich die Geister, ob man dessen Decoder-PLA Microcode nennen sollte oder nicht - ich tendiere zur "Nein"-Seite, da es ein reiner Sequencer ohne Sprünge oder (beabsichtigte) Schleifen ist.
