Beiträge von M. J. im Thema „Startadresse C64 Basic“

    Am Interrupt hängen auch noch TI/TI$ (wichtig für simple Geschwindigkeitstests) und das Cursorblinken nebst Ab- und Wiederanschalten mit dran. Zumindest hätte so eine Emulation ein sehr irritierendes Verhalten weil man ja nie weiß ob sie sich schon aufgehängt hat oder (noch) nicht.....

    Richtig. Sorry, da war ich in Gedanken schon etwas weiter vorgesprungen nach dem Motto: Wenn man die Zeicheneingabe von außen füttern kann, kann man auch die Zeichenausgabe vom Emulator übernehmen lassen (inklusive Cursor), und TI$ hatte ich gerade wegen der Anbindung an die Hardware im Kopf verdrängt. Daher auch der Gedanke, daß gut dokumentierte Enhanced-Basic zu nehmen, welches ebenso funktioniert: Ein- und Ausgabevektoren umbiegen, und schon läuft die Maschine. Ist so natürlich auch mit Commodore Basic bzw. Applesoft möglich, die ähnlich aufgebaut sind, aber Commodore Basic ohne Peeks und Pokes wäre für mein Gefühl irgendwie nicht wirklich vollständig.
    Was mich noch interessieren würde (wenn die Nachfrage erlaubt ist): Für welche Ausbildung wäre denn dieses Projekt? Für ein schulisches Projekt wäre ein C64-Emulator oder auch nur die Emulation eines Basic-Interpreters auf 6502-Basis ein recht ambitioniertes Projekt, welches ich mir daher schlecht als Bestandteil eines Informatik-LKs vorstellen kann. (Zumindest als ich das letzte Mal in die Richtlinien geschaut hatte, standen da sehr viele spannende Sachen drin wie Zustandsautomaten oder objektorientierte Programmierung in Java, aber garantiert kein Wort zu Emulatoren.) Auch an der Uni habe ich es eher so erlebt, daß schon Assembler als ziemlich out und verpönt angesehen wird, also eine Sache, über die man besser nicht laut spricht. Vielleicht könnte reims Näheres dazu sagen, insbesondere auch zur Zeitplanung, um mal den Aufwand besser abschätzen zu können.

    Tastatureingaben kann man direkt in den Keyboard-Puffer schreiben

    Interessanter Gedanke. Da könnte man am Ende sogar auf den Interrupt völlig verzichten.

    In dem Fall wäre ein BASIC-Interpreter mit geringer Hardwaresimulation (statt Emulation) einfacher umzusetzen.

    Sofern es tatsächlich nur um ein Basic für den 6502 geht, könnte sich vielleicht ein Blick auf diesen leicht anzupassenden Enhanced-Basic-Interpreter lohnen: "Bitte melde dich an, um diesen Link zu sehen.". Im "forum.6502.org" findet sich dazu auch ein eigener Bereich. (Leider ist der Entwickler vor einiger Zeit verstorben.)
    Edit: Link korrigiert

    Ich bitte um Verzeihung, wenn das, was ich hier schreibe, für manche in einem Forum64 wie Blasphemie klingt, doch würde ich Dir gerne den Rat geben, anstelle eines C64 als erstes Zielobjekt für eine Emulation lieber den AppleII zu nehmen. Der C64 ist aufgrund seiner Spezialchips (CIA, SID, VIC) nur mit großem Aufwand zu emulieren, wohingegen ein AppleII sehr einfach strukturiert ist. So benötigt man allein schon für das C64-Basic eine Emulation des CIA für den Timer-Interrupt und die Tastatureingabe, wobei auch noch die Tastaturenmatrix entsprechend abgebildet werden muß. Der AppleII verfügt (in der normalen Grundausstattung) überhaupt nicht über Interrupts, und die Tastaturemulation beschränkt sich zumeist darauf, das Highbit im ASCII-Code zu setzen.

    Hier mal eine kurze Vergleichsübersicht:
    - Emulationsgenauigkeit:
    C64: Der Emulator sollte wenigstens zeilenexakt sein (s. alte Versionen von Frodo), um Rasterinterrupts, vertikales Scrolling oder Sprite-Multiplexer nachzubilden. Viele Programme nutzen bewußt zyklengenaue Eigenschaften des 6510 (sprich: idle-Buszugriffe), um z. B. einen IRQ zu bestätigen.
    AppleII: Für 95% der Programme reicht es aus, den Prozessor einen Frame lang laufen zu lassen und dann die Anzeige aufzufrischen (vgl. AppleWin). Der Prozessor kann für 99,9% der Programme befehlsweise, nicht zyklenweise emuliert werden.
    - Illegale Prozessor-Opcodes:
    C64: sehr häufig verwendet
    AppleII: nur eine verschwindend kleine Anzahl Programme (meistens nachträglich eingebaute Fehler des Crackers). In der Regel wird kein bestimmter Prozessortyp vorausgesetzt. 95% der Programme laufen auch auf einem 65c02 oder 65816.
    - Speicheraufbau:
    C64: Umschalten der Speicherkonfiguration hauptsächlich über $01, wobei drei Speicherbereiche jeweils verschieden eingeblendet werden.
    AppleII: Für eine erweiterte Emulation kann der Bereich $d000-$ffff (Rom) mit Ram getauscht werden (LC-Card). Viele Programme laufen auch ohne.
    - Basic:
    C64: Pokes zur Verwendung von Farben und Sprites, sowie Sound üblich. Setzt daher auch die Emulation des VIC bzw. SID voraus.
    AppleII: Baut auf dem gleichen Microsoft-Basic auf wie das C64-Basic, verfügt aber zusätzlich über ein paar Graphikbefehle und bei eingebundenem DOS 3.3 auch über einfache Diskettenbefehle.
    - Tastatur:
    C64: Umwandlung der PC-Tasten in Bits der Tastaturmatrix, die über emulierte Ports des CIA an das Programm weitergereicht werden.
    AppleII: Im ASCII-Code wird das Highbit gesetzt und das Ergebnis an der Adresse $c000 eingeblendet. Kein umfangreiches Mapping nötig.
    - Videoemulation:
    C64: sehr aufwendig (VIC-Emulation) wegen diverser Graphikmodi, Sprites, Scrolling, Rasterinterrupt etc.
    AppleII: Nur 3 Darstellungsmodi (Text, Lores, Hires) und keine Sprites, Scrolling, Interrupts... Prinzipiell würde zunächst sogar eine einfache Schwarz-Weiß (nicht Graustufen)-Darstellung schon ausreichen.
    - Sound:
    C64: sehr aufwendig (SID-Emulation)
    AppleII: einfacher Speaker, kann auch weggelassen werden
    - Diskettenlaufwerk:
    C64: Sehr aufwendig bei Programmen, die einen Schnellader voraussetzen, da neben den Controllerchips für Lesekopf- und Buszugriffe auch eine eigene Prozessoremulation notwendig ist.
    AppleII: Es genügt, beim Laden der Diskette einmal das Image ins GCR-Format umzuwandeln. Die Ansteuerung des Lesekopfes (vom AppleII aus) ist relativ einfach umzusetzen.

    Kurz gesagt: Eine AppleII-Emulation, die bereits die Benutzung von 95% aller Programme gestattet, ist um etliches einfacher umzusetzen als eine C64-Emulation. Mit relativ wenig Aufwand bringt man schon Spieleklassiker wie "Elite", "The Bard's Tale I-III", "Ultima IV", "Summergames", "Bandits", "Karateka" etc zum Laufen und hat damit ein vorzeigbares Ergebnis, und der Schritt hin zu einer vollständigen Emulation des Apple//e mit Spielen wie "Space Quest", "Leisure Suit Larry", "Test Drive", "Prince of Persia", "Maniac Mansion" oder "Dragon Wars" ist dann gar nicht mehr so weit (etwas kompliziertere Speicheranordnung und neuer Graphikmodus Double Hires). Nebenbei bemerkt schreibe ich dies nicht nur rein theoretisch, sondern durchaus auch aus eigener Erfahrung. Nahezu jedesmal, wenn ich eine neue Programmiersprache bzw. einen neuen Rechnertyp in die Finger bekomme (680x0, 8086, x86, C, Java...), schreibe ich als erstes größeres Projekt einen AppleII-Emulator, um ein Gefühl für die Sprache bzw. einen Eindruck von der jeweiligen Leistungsfähigkeit des Systems zu kriegen. Ein AppleII-Emulator wäre innerhalb eines Projektes (je nach zur Verfügung stehender Zeit) machbar, ein C64-Emulator wahrscheinlich nicht.