Damit ist klar, dass bei einem Wert von $47 (=70 Zyklen) dann der Timer-Interrupt noch in der Setup-Prozedur passiert und nicht im zu untersuchenden Befehl, der Interrupt sofort unmittelbar auslöst bevor der Befehl überhaupt abgearbeitet wurde und weshalb TW nicht funktioniert.
$47 sind natürlich 71 Zyklen. 
2. Hardware-Architektur:
a) BASIC+KERNAL zusammenlegen und den I/O Bereich ans Speichende legen.
Dann hätte man Grafiken(10kB) problemlos in einem Zug in den oberen 16kB Bereich laden können.
Problem: Die Vektoren sind in der letzten Page. Da hätte man dann Reset-Vektor und ev. andere aus dem ROM an diese Stelle einblenden müssen. Eine Konstruktion, die die Entwickler wohl unter Zeitdruck vermieden haben. Dass man mit Bankswitching auch fast die gesamten 64 K hätte nutzen können, liegt ja nur am BASIC, das BASIC 3.5 der 264er-Linie zeigt es ja. Nur, das ist ein massive Änderung am BASIC-Interpreter, die weit mehr Aufwand ist, als den VC20 als Prototyp zu nehmen und einige Speicherstellen anzupassen ... aber dabei ist jedenfalls egal, wo I/O- und ROM-Bereiche liegen.
4. Ein paar zusätzliche Maschinensprachebefehle hätten dem C64 eine höhere Geschwindigkeit geben können.
z.B. TXS, TYS,TSX,TSY
Ja, das ist ja unrealistische Träumerei. Als könnte man einer CPU so aus der Laune heraus mal den einen oder anderen Befehl "dazutun" ... Die Beispiele sind gerade die so selten benötigten Befehle, die hätten tatsächlich nichts gebracht.
Nett wären die Verbesserungen von 65C02 gewesen. Aber auch da, den BASIC-Interpreter dahingehend zu optimieren, damit die CPU auch ausgenutzt wird ... das schreibt man nicht an einem Nachmittag um. 
4. Auch das Basic hätte natürlich noch verbessert werden können.
Den Fehlermeldungsbereich hätte man ganz weglassen können.
und statt dessen die BASIC-BEFEHLE für Fehlermeldungen verwenden können: PRINT-ERROR, LET-ERROR, usw
Bei vielen BASIC-Befehlen hätte man die Leistungfähigkeit natürlich auch noch stark verbessern können.
Ist eigentlich 5.
Den Fehlermeldungsbereich weglassen? Was soll das sein. Primitiver geht es ja kaum. Alles andere wäre ja mit mehr implementierungsaufwand verbunden.
Andere MS-BASICs haben statt lesbare Fehlermeldungen 2-Buchstabenkürzel. Ist das gemeint? Z.B. beim Dragon oder CoCo. Obwohl die Dank 6809-CPU weit kompakter codieren können, hat man dort zugunsten der Funktionalität auf ausschweifende Fehlertexte verzichtet. Für einen Anfänger sicherlich auch nicht lustig (aber die langen Fehlermeldungen sind ja auch nicht immer auf den ersten Blick verständlich ).
Aha, also der Timer A läuft 2 Zyklen länger. Da X vorher 0 ist, läuft der Timer also 73 (Zyklen).
Im reverse-engineerten Source-Code ist das der Bereich mit den T-Befehlen, genau genommen im TW-Teil.
TW scheint so zu funktionieren, dass ein Timer-Interrupt unmittelbar in dem Befehl auftritt, der gerade "getracet" wird. Wenn ich richtig gezählt habe werden 71 Zyklen veranschlagt, das ist etwa die Zeit, die SMON braucht, um die Ausführung an der Trace-Stelle laufen zu lassen. Der Timerinterrupt ist auf 73 Zyklen eingestellt. D.h. der Interrupt kommt so etwa im 2. Takt des Befehls (also der Mindestdauer eines Opcodes). Der Befehl wird (falls er länger dauer) ja noch fertig abgearbeitet, bevor dann tatsächlich der Interrupt bedient wird.
Damit das zyklenexakt läuft, ist da auch das Display (der VIC) weggeschaltet.
Damit ist klar, dass bei einem Wert von $47 (=70 Zyklen) dann der Timer-Interrupt noch in der Setup-Prozedur passiert und nicht im zu untersuchenden Befehl, der Interrupt sofort unmittelbar auslöst bevor der Befehl überhaupt abgearbeitet wurde und weshalb TW nicht funktioniert.
Display MoreMan findet zwar "alles" auch "irgendwo" im Netz, aber es spart etwas Zeit und ist recht übersichtlich, wenn vieles an Unterlagen an einer Seite gesammelt sind.
Genau das hat Lars Brinkhoff auf dieser github-Seite für ältere CPUs und Mikrocontroller gemacht:
Awesome CPU and MCU documentation
QuoteThis repository contains documentation for various CPUs. There are data sheets, programmer's manuals, quick reference cards, etc.
Aufpassen muss man halt trotzdem hinsichtlich der Richtigkeit der Dokumente. Nicht nur, dass die Hersteller jede Menge Fehler in Ihren Dokumenten haben (mein Favorit ist da etwa WDC), die aufgearbeiteten Dokumente und Zusammenfassungen sind auch nicht fehlerfrei. Da wären Quellen zu Fehlerzusammenfassungen oder Erratas dazu auch ganz praktisch, wenn sie an der Stelle eingebunden wären.
So z. B. https://github.com/larsbrinkho…/master/MCS6500/65c02.txt, PLA ändert dort angeblich keine Flags, was aber falsch ist, kann nämlich N und Z beeinflussen (auch beim 65C02, der da meines Wissens nicht inkompatibel ist).
Da ist die Frage, ob Brinkhoff hier Pull-Requests zulässt ... (mal probieren )
Ein bisschen lästig ist halt die Benennung der CPUs im Top-Level und damit die Sortierung. Da wird für die 68000er-Familie M68000 (M steht aber glaub ich für Mitsubishi?), der 6809 aber als MC6809 (was richtig wäre, MC steht für Motorola).
Wer kommt schon bei der 65xx(x)-Familie auf MCS?
Da wäre es angebrachter gewesen einfach nur die umgangssprachliche Bezeichnung zu wählen. 68000 oder 68K und wo unüblich, den Herstellerpräfix einfach weglassen ... 
Siehe auch C64wiki XOR, in der Beispielerubrik auch Varianten, wenn man sich gemütlich unter BASIC (2.0) damit rumspielen möchte ...
Update.
Ich habe jetzt einfach aus anderen Quellen alles an SMON Varianten geladen die ich finden konnte und siehe da ich habe eine gefunden in der das mit dem TW Befehl funktioniert.
Wäre interessant welche zwei Versionen das sind. Gibt es Checksums von diesen Versionen? Oder ein diff von den Hexdumps der beiden Varianten. Das würde eventuell genau klären, wo der Unterschied liegt ...
Dies Pokerei (noch dazu ohne Erklärung) kann man sich ersparen, indem man
OPEN1,3:CMD1
Damit ist das Ausgabe-File nun 1 (was genau dann auch in der Speicherstelle 19 zumindest beim C64 vermerkt ist). Wenn dort der Wert ungleich 0 ist, wird di e Ausgabe nicht für den Bildschirm gehalten und es wird keine Bildschirmmagie angewendet (wie CRSR-rechts statt Space etc.).
Abstellen muss man das dann mit
PRINT#1:CLOSE1
damit der Bildschirmeditor nicht verwirrt ist.
Update.
Ich habe jetzt einfach aus anderen Quellen alles an SMON Varianten geladen die ich finden konnte und siehe da ich habe eine gefunden in der das mit dem TW Befehl funktioniert.
Das könnte in der Tat eine frühe Version gewesen sein (vom Abtipplisting, später auf 64'er-Disks). Es gab ja welche mit Diskmonitor und welche ohne. Vermutlich wurden da auch Bugs beseitigt. Mich hat immer genervt, dass SMON die Farben umgesetzt hat (und dann nicht immer zurückgestellt hat) und hab mir dann halt eine Variante gemacht, die die Farben einfach in Ruhe lässt).
Wenn du beim dem Print-Befehl nach der Zahl noch 4 Leerzeichen anhängst, dann werden alle möglichen vorherigen Stellen gelöscht.
PRINT <deine zahl>;" ", ...
Genau genommen muss an CRSR-Left noch einfügen, da PRINT bei einer Zahl an CRSR-Right anhängt (am Bildschirm, bei einem File ein Leerzeichen). D.h. da könnte noch eine Ziffer der vorigen Zahl in der Lücke über bleiben.
Also:
PRINT ZAHL;"{crsr left}{space}{space}"
um 3-stellige Zahlen auszugeben. (ein Space weniger, wenn man davon ausgeht, dass eine Zahl mindestens eine Ziffer hat).
Ja, ich weiß.
Der 6502 ist über vierzig Jahre alt, und es gibt drei(!) Beispiele für die "echte" Nutzung dieser Adressierungsart. Wenn das nicht als "komplett nutzlos" durchgeht, was dann? Nur mal so als wilder Vergleich: Die Adressierungsart lässt sich mit acht Mnemonics kombinieren, es gibt also mehr als doppelt so viele Opcodes mit dieser Adressierungsart als Beispiele für die sinnvolle Verwendung dieser Adressierungsart.
Ob das wirklich nur die einzigen Beispiele sind ... das sind halt die prominenten Beispiele. Das seriös zu beantworten, müsste man das schon eine Codeanalyse an einer nennenswerten Codebasis (nicht nur Spiele) durchführen. Aber stimmt, es wird nichts daran ändern, dass diese Adressierungsart selten in Verwendung ist, selbst wenn größere Zahlen dabei heraus kommen.
Schließlich muss man noch bedenken, wo der 6502 herkommt: man wollte die 6800-User ansprechen und ins 6502-Lager ziehen. Dabei hatte der 6502 das Problem, dass das X-Register plötzlich nur noch 8 Bit, statt 16 Bit beim 6800 hatte. Konnte man mit letzterem mit 0,X bequem über den gesamten Speicher streichen, war man beim 6502 plötzlich auf eine Page beschränkt. Ein (ZP,X) war m. E. ein Versuch einen gewissen Ausgleich zu schaffen (ohne sich groß zu überlegen, mit welcher Häufung und wie nützlich sich diese Adressierungsart sein wird) oder das (ZP),Y dieser Adressierung den Rang abläuft. Chuck Peddle können wir leider dazu nicht mehr befragen bzw. ich weiß nicht, ob er das je einmal kommentiert hat.
Die Entwicklung des 6502 war glaub ich unter enormen Zeitdruck passiert, so dass vermutlich die Adressierungsart schneller in Hardware umgesetzt war, als lange darüber zu forschen, wie sinnvoll die ist. Im Gegensatz dazu hat ja Motorola beim 6809 enormen Aufwand getrieben, herauszufinden, was 6800-Anwender sich wünschen und brauchen könnten und das Design nach einer Evaluation danach ausgerichtet.
Da kann man das Missgeschick "(ZP,X)" vielleicht verstehen, selbst wenn man sich darüber ärgern mag.
Nebenbei darf man vielleicht auch noch erwähnen, dass mit dem 65C802/816 schon wieder praktischer wird. Das X-Register bei (DP,X) kann da wieder 16 Bit sein und man kann mit X einen Pointer auf eine Datenstruktur zeigen, mit DP hat man ein Displacement in der Struktur. Pferdefuß dabei ist, dass man da auf Bank 0 beschränkt (wo die Direct-Page sein muss) ist. Die Zieladresse kann dabei allerdings im ganzen Adressraum liegen (vom Data Bank Register abhängig). Natürlich auch nicht der Kracher, sieht man auch daran, dass WDC dieser Adressierung kein Long-Pendant spendiert hat (wie etwa für [ZP],y korrespondierend zu (ZP),y ).
An der TU Wien war Ende der 1980er Anfang der 1990er COBOL noch als Programmiersprache für die Kommerzielle Datenverarbeitung und für zu absolvierende Übungen in Verwendung (ob Pflicht, kann ich nicht mehr sagen).
Das war gerade zu Zeiten, wo die Objekt-Orientierung in aller Munde war und als Heilbringer der IT galt, während man COBOL schon damals als Relikt ansah, aber - wie hier schon immer wieder gesagt - in etlichen kommerziellen Anwendungen vorhanden war oder überlebt hat.
Ich kann mich nicht mehr so genau an unser Projekt erinnern, aber es ging um Flug-Management und es war insofern recht nett, weil die Datenbank-Anbindung einfach implizit in die Sprache eingebunden war. Das könnte der Reiz bei der Sache gewesen sein, dass alles mit der Datenbank mehr oder weniger "schön" (ohne extra Aufwand) zugänglich war.
Mein Kollege von der Projektgruppe ging dann in de Universitätsadministration und dort war dann auch alles COBOL-lastig (er hatte da dann seinen Spaß).
Hi, danke für die Antwort.
Na dann, gerne. Beiträge hätten ja auch den "Thumbs up"-Knopf in dieser Forums-Implementierung, um einen nützlichen Betrag zu honorieren.
Wahrscheinlich ist es genau so wie immer.
Jeder verteidigt bis aufs Messer was er kennt und alles andere ist schlechter, insbesondere wenn das eigene mit viel Geld bezahlt wurde (muss ja gut sein, sonst hätte man sich ja falsch entschieden).
Nein, eigentlich nicht. Man hat ja für das Gesamtsystem viel Geld bezahlt, nicht für die CPU an sich. Dann zu glauben die CPU verteidigen zu müssen, ist halt bestens Futter für Flame-Wars, aber eher nicht, die Entscheidung für die Investition zu verteidigen. Das kommt ja nur daher, weil die aus dem jeweiligen anderen Lager dann ein CPU-Bashing betreiben, um das jeweilige System "schlecht zu machen".
Die CPU ist nebensächlich und es ist eigentlich sinnlos darüber zu diskutieren (was früher wie heute gerne leidenschaftlich von Leuten aus den jeweiligen Lagern geführt wurde und wird), denn der Zusammenhang ist nicht so, dass jemand je einen Homecomputer ausgewählt hätte, weil er Z80 oder 6502 hat. Es war das Gesamtpaket ausschlaggebend, die Verbreitung der Plattform und schließlich das Software-Angebot.
In meinem Fall, als ich vom ZX-81 kam und vom Z80 beseelt war, stand ich dann beim VC-20 bzw. C64 als Folgesysteme dann vor dem 6502. Selbst als die Entscheidung noch zwischen ZX-Spectrum und VC-20 stand, ging es bei mir nicht im Geringsten um die CPU. Ich glaube, dass das bei anderen nicht anders war. Die 6502-CPU war halt da. Also ich dann dort mit dem Assemblerprogrammieren auch dort begann, war der Ernüchterung groß. Fast könnte man sagen, ich glaubte mich im "falschen Film", den 6502 zu programmieren. Aber, man muss den "Spirit" der CPU erst mal in sich aufnehmen. Die Denkweise an Probleme heranzugehen, ist völlig anders. Die Kochrezepte für die üblichen Aufgaben sind völlig anders. Wenn man etwa vom Z80 kommt, ist es eher ein Nachteil, wenn es zum 6502 geht. Am besten bei 0 beginnen und alles vom Z80 vergessen/ausblenden. Einfach die CPU eines Rechner unvoreingenommen aneignen. Das war auch später so, ob PC mit x86, Workstations mit 68K, SPARC, Embedded-Systeme mit 68K, i960, 6809 usw.
Eins noch: Wundere Dich nicht, wenn Dir für die x-indiziert-indirekte Adressierung (also sowas wie
) kein Anwendungsfall einfällt. In der Praxis ist diese Adressierungsart komplett nutzlos, und wenn sie überhaupt verwendet wird, dann mit konstantem X als Ersatz für das nicht vorhandene
.
Wenn ich helfen darf: Die Anwendung ist, wenn man in der Zeropage (die könnte man beim 6502 ja als einen Bereich aus 256 Registern ansehen ) eine Datenstruktur hält. Da man 256 Bytes hat, kann man sich das ja leisten.
Beispiele:
Display MoreHallo,
ich versuche zwei Funktionen zu schreiben. Die eine soll eine LEN Funktion sein, und die andere soll einen String in einer Box ausgeben. Dabei soll sie sich der LEN Funktion bedienen. Ich müsste also an den Funktionsaufruf irgendwie den Pointer für den String übergeben. Wie mache ich das am besten? Mit ZP?
ZP Idee:
Ich stelle die Startadresse des Strings in eine bestimmte ZP und verwende dann LDA $ZP, X um den String zu loopen (bis 00) und die Länge in Y abzulegen.
Fragestellung: Und wenn ich eine Variable ZP haben möchte ? wie kann ich denn eine ZP in einem Register übergeben? Geht z.B. daß man LDA (Y), X macht, wobei Y die ZP enthält?
Indirekte Addressierung mit Index Idee:
Ich stelle die Addresse irgendwo hin und verwende dann LDA ( Absolut ), X -> Langsamer, aber dafür nicht durch ZP begrenzt.
Absolute Addressierung mit Modifying Code:
Ich stelle die Addresse wieder irgendwo hin und verändere den LDA Absolut, X eintrag im Memory (muss nur einmal gemacht werden und sollte den Loop beschleunigen) <- Aber sehr unschön zu debuggen
Habe ich irgendwas übersehen, oder macht Ihr das einfach im Assembler (Also ZP im Assembler definieren und dann einfach benutzen?).
Irgendwie fehlt mir grade eine Gehirnwindung ...
Mit ZP,X geht das nicht. Da kann man nur über die Zeropage-Speicherstellen selbst "loopen", aber nicht über den String-Inhalt!
Hier verwendet man üblicherweise die indirekte Adressierung, die lautet z.B. für LDA korrekterweise LDA (ZP),Y
D.h. in ZP steht das Low-Byte der String-Adresse, in ZP+1 das High-Byte.
Mit Y=0 bis Y = LEN-1 kann man dann auf den String-Inhalt zugreifen.
Es stellt sich die Frage, wo die Länge gespeichert ist oder wird 0 als String-Terminator verwendet?
Länge ermitteln mit String-Terminator 0:
Wenn man Strings allerdings mit 0 terminert, dann ermittelt man üblicherweise die Länge nicht vorher (es sei denn, man braucht den Wert tatsächlich), sondern lässt entsprechende Routinen immer auf die 0 abfragen, statt dann relativ umständlich die Länge zu übergeben.
Also entweder oder. Strings aus dem BASIC-Interpreter haben hier z.B. einen String-Descriptor, der aus dem Längen-Byte und den beiden Bytes für die Adresse des String-Anfangs besteht, also 3 Bytes (das steht z.B. in eine String-Variable drinnen).
Selbst dann, die Software in den ROMs ist ja nicht nur das BASIC, den KERNAL haben die vermutlich auch nicht "neu" nachprogrammiert. Sonst wär's mit der Kompatibilität schnell dahin ...
Hier geht es nur um die Behauptung aus dem Artikel wonach das 64er BASIC 'Freigegeben' wäre.
Vom Kernal steht da nix im Artikel.
Richtig, aber es steht dort "Sie nehmen das Gehäuse-Design, modifizieren die Schriftzüge und bastelten einen Software-Unterbau, der sich exakt so wie die C64-Hardware verhält. Einzig das Basic ist als mittlerweile freigegebene Freeware implementiert.", was andeutet, als Software steckt da "nur" das BASIC drinnen. Da das KERNAL nicht explizit erwähnt wurde, wäre mitunter davon auszugehen, dass hier vereinfacht von "BASIC" die Rede ist, aber das KERNAL hier implizit mitgemeint war. Bei dem Artikel wird man wohl nicht diese Spitzfindigkeiten den Lesern zumuten (das ist ja nicht an Forum64-Experten adressiert). Wie gesagt, der "Software-Unterbau" abzüglich des "freien Basics" müsste demnach der KERNAL sein. Das die denn wie im Text "exakt nachgebaut hätten" will ich mal in Frage stellen. Ich wollte da nicht Wortklauben, sondern lediglich auf einen weiteren Aspekt in dieser Berichterstattung hindeuten.
Afaik ist das BASIC 2.0 aber keine Freeware.
Es gibt wohl ein 6502 BASIC im Netz, aber ob die 'Frei' ist, ist unklar.
Selbst dann, die Software in den ROMs ist ja nicht nur das BASIC, den KERNAL haben die vermutlich auch nicht "neu" nachprogrammiert. Sonst wär's mit der Kompatibilität schnell dahin ...
Sorry, aber müssem die nicht entweder im Formal .xml oder als dll vorliegen? Ich bekomme hier in der Version 7.8.7 nur diese beiden als Auswahl angezeigt.
Die Dateien im 7zip-Archiv die Endung .xml verpassen, dann als Designs importieren.
Einstellungen -> Import -> Design(s) importieren ...
Soweit hat es geklappt. Bei einem BASIC V2 Source-Code für Vice (.bas) hat aber keine Veränderung in der Darstellung ergeben.
Auch bei einem .asm-File zeigt mir Notepad++ nur die Standard Assemble-Source-Hervorhebung.
In den Menüs sehe ich das nicht als "Sprachauswahl" ...
Was ist da noch falsch?
Habe ich mir gestern Abend komplett angesehen. Wirklich gut, in dem Video hört man es aus Tramiels Mund, dass er seinen Firmennamen tatsächlich vom Opel Commodore hat.
Auch wenn es Tramiel hier im Interview tatsächlich so sagt, so kann es schlichtweg nicht stimmen. Hier trügt ihn seine Erinnerung. Das ist ein nicht unbekanntes psychologisches Phänomen, dass man im Laufe der Zeit Erinnerungen mit neuen Eindrücken "anreichert".
Zurück zum Einwand: Der Opel Commodore war erst seit 1967 am Markt. Wenn der Firmenname bereits um 1952 aufscheint, dann kann es kein Opel gewesen sein. Ich glaube, im Angesicht des Schriftzuges "Commodore" und der Tatsache, dass er nun einen Namen gefunden haben könnte, ist die Automarke sicher nicht mehr die primäre Information gewesen, die man sich behält. Zu der Zeit dürfte es eher eine Hudson Commodore gewesen sein, der in die Zeit auch passt. Siehe auch C64-Wiki-Diskussion (bitte gerne Erkenntnisse ergänzen). In der Erinnerung hat dann "Opel" dominiert, da dieser eher die "neueren" Eindrücke geprägt haben dürfte (in vermutlich ganz anderem Kontext).
Hmm, mal gucken, ob ich sowas nicht mal gebastelt kriege. Die grundlegenden Sachen sind ja wirklich einfach. Interessant sind ja dann die abweichenden Makro-Verhalten etc.
Das ist in der Tat ein Problem. Beispielsweise sind ACME-Makros mit einem Typkonzept hinterlegt, was Makros eher wie Funktionen agieren lässt, statt wie üblich eine Textexpandierung. D.h. gewisse Konvertierungen sind nur in eine Richtung möglich.
So war es mir etwa nicht möglich C32-Sourcecode ins ACME-Format zu bringen (das auch entsprechend assembliert worden wäre) und musste auf TASS ausweichen. Leider ist mein Konverter ziemlich auf Quell- und Zielformat hingetrimmt (auch wenn es mehrere dedizierte Ausprägungen davon gibt). Da bräuchte man schon einen saubereren Ansatz, wo etwa eine allgemeine Zwischendarstellung erzeugt wird, die dann wiederum in jedes beliebige Assemblerformat übergeführt werden könnte.
