Einen Emulator bauen, der Bus und Timing der echten Hardware nachbildet

## Ungewöhnlichen Hardwarecode erklären und Typprüfungen und Tests ausführen Schreiben Sie Emulatorcode für Fachleute, die mit der ursprünglichen Hardware möglicherweise nicht vertraut sind. Erklären Sie, warum eine Zeitregel, eine Nebenwirkung oder eine Umgehungslösung existiert, statt anzunehmen, eine ungewöhnliche Umsetzung sei selbsterklärend. Verweisen Sie auf maßgebliche Hardwarequellen, wenn diese das Verhalten verdeutlichen. Ermitteln und verwenden Sie die im Projekt dokumentierten Befehle für Formatierung, statische Prüfung, Typprüfung, Tests, Erstellung, Überwachungsmodus und Leistungsmessungen. Behandeln Sie vorgeschriebene Prüfungen als Bestandteil der Änderung: - Führen Sie während der Bearbeitung die Formatierung und gezielte Tests aus. - Führen Sie Typprüfungen aus, wenn sich öffentliche Deklarationen oder typisierte Grenzen ändern. - Führen Sie vor dem Einchecken oder der Übergabe die maßgebliche vollständige Testsammlung aus. - Führen Sie bei größeren Änderungen oder vermuteten Leistungseinbußen die Leistungsmessung aus. - Halten Sie sachfremde Umstrukturierungen von einer gezielten Korrektur getrennt. Aktualisieren Sie öffentliche Beispiele und API-Verweise, wenn sich Methoden, Optionen, Rückruffunktionen, exportierte Elemente oder unterstützte Eingabeformen ändern. Halten Sie örtliche Umsetzungsdetails in naheliegenden Kommentaren fest; beschränken Sie projektweite Hinweise auf die Architektur und Regeln, die für mehrere Bausteine gelten. ## Den Emulator in Bausteine nach den Hardwareteilen aufteilen Gliedern Sie den Emulator nach den Hardwareteilsystemen, die er abbildet. Verwenden Sie einen kleinen Koordinator, der die Bausteine abstimmt und Rückruffunktionen für Bildausgabe, Ton, Status und Aktualisierungen des dauerhaften Speichers bereitstellt. Trennen Sie die Zuständigkeiten für Prozessoren, Bild, Ton, Steckmodul- oder Speicherzuordnung, Programmladen, Hilfsfunktionen der Bildausgabe, Steuergeräte und Serialisierung. Geben Sie jedem Baustein eine eindeutige Schnittstelle und lassen Sie ihn seinen internen Zustand selbst verwalten. Verwenden Sie Vererbung nur, wenn Hardwarevarianten tatsächlich ein gemeinsames Grundverhalten besitzen und lediglich bestimmte Zuordnungs- oder Speicherbankregeln überschreiben. Bevorzugen Sie für unabhängige Teilsysteme die Zusammensetzung und vermeiden Sie verborgene Zugriffe über Bausteingrenzen hinweg. Legen Sie eine gemeinsame Zeitbasis fest. Auch die Ausführung in Einzelbildern erfordert eine genaue Taktzählung innerhalb jedes Einzelbildes, während die Trägeranwendung weiterhin für Darstellungszeitpunkt und Ablaufplanung verantwortlich bleibt. Bündeln Sie die Umwandlung von Speicherständen durch symmetrische Serialisierungs- und Wiederherstellungsverträge, die jeder zustandsbehaftete Baustein verwendet. ## Jeden Buszugriff samt Scheinzugriffen wie die echte Hardware nachbilden Modellieren Sie den Bus als zustandsbehaftetes Verhalten und nicht als reine Zuordnung von Adressen zu Werten. Echte Hardware kann den letzten Wert beibehalten, gehaltene Daten von nicht zugeordneten oder nur beschreibbaren Adressen zurückgeben oder nur ausgewählte Bits treiben. Verfolgen Sie getrennte Halteregister, wenn verschiedene Hardwarebusse voneinander unabhängige Zustände bewahren. Aktualisieren Sie das passende Halteregister bei jedem beobachtbaren Lese-, Schreib- oder Stapelvorgang sowie bei jedem Opcode- und Unterbrechungsvektorabruf. Wenn ein Gerät nur einen Teil eines Werts treibt, verbinden Sie diese Bits genau wie die Hardware mit dem beibehaltenen Buszustand. Setzen Sie Scheinlese- und Scheinschreibzugriffe als echte Busvorgänge um. Sie können gehaltene Werte aktualisieren und I/O-Nebenwirkungen auslösen, selbst wenn das Programm den zurückgegebenen Wert nie verwendet. Kodieren Sie die Busreihenfolge für jede Adressierungsart ausdrücklich: - Indizierte Adressierung kann vor einer Seitenkorrektur eine Zwischenadresse lesen. - Indizierung auf der Nullseite kann vor Anwendung des Indexes die nicht indizierte Adresse lesen. - Indirekte Indizierung kann vor Erreichen der wirksamen Adresse einen Zeiger oder eine Zwischenadresse lesen. - Speicherbefehle und Lesen-Ändern-Schreiben-Befehle können auch ohne Seitenwechsel vorgeschriebene Scheinzugriffe ausführen. - Ein Lesen-Ändern-Schreiben-Befehl kann zunächst den ursprünglichen und danach den geänderten Wert schreiben. Bewahren Sie die befehlsspezifische Reihenfolge, wenn ein Abruf vor oder nach einem Stapelvorgang stattfindet. Eine Neuordnung von Vorgängen, die dieselben endgültigen Registerwerte erzeugen, kann auf dem Bus dennoch beobachtbar falsch sein. ## Geräte auch mitten im Befehl synchron halten und DMA als echte Buszyklen behandeln Wenn der Emulator einen Baustein unteilbar ausführt, die Bausteine der echten Hardware aber im Gleichschritt fortschreiten, kann bei Registerzugriffen innerhalb eines Befehls ein veralteter Zustand sichtbar werden. Korrigieren Sie dies an der Grenze, an der der Zugriff beobachtbar wird. Erfassen Sie, wie viele Busvorgänge der aktuelle Befehl abgeschlossen hat. Lassen Sie ein synchronisiertes Gerät vor einem Lese- oder Schreibzugriff auf sein Register entsprechend dem genauen Taktverhältnis der vergangenen Vorgänge fortschreiten. Ziehen Sie bereits angewandte Arbeit vom späteren Fortschritt auf Bildebene ab, damit Zeit niemals doppelt gezählt wird. Modellieren Sie die Erzeugung eines Unterbrechungskennzeichens getrennt von der Zustellung der Unterbrechung. Eine Sperrsteuerung kann verhindern, dass ein Zustandskennzeichen entsteht, anstatt lediglich das äußere Unterbrechungssignal zu unterdrücken. Tests müssen diese Verhaltensweisen unterscheiden. Stellen Sie DMA als Belegung echter Buszyklen dar. Eine Übertragung kann den aktuellen Buswert ändern, den Prozessorfortschritt verzögern oder das Ergebnis von Befehlen verändern, deren Ausgabe vom Buszustand abhängt. Bewahren Sie die Reihenfolge zwischen DMA, Befehlszugriffen und Gerätenebenwirkungen. Setzen Sie dokumentierte inoffizielle Befehle oder Grenzfallbefehle nur anhand verlässlicher Quellen und Tests um. Vereinfachen Sie ihr Zyklusverhalten nicht allein deshalb, weil übliche Software sie nicht verwendet. ## Mit Programmen testen, die auf echter Hardware nachweislich korrekt laufen Verwenden Sie mehrere Prüfebenen mit jeweils eigenem Zweck: - Modultests prüfen Initialisierung, Befehlssemantik, Zuordnungsregeln, Speicherspiegelung, Zustandsübergänge und Fehlerbehandlung. - Gezielte Regressionstests schreiben Bildpuffer, Tonabtastwerte, Busprotokolle oder andere deterministische Ausgaben fest. - Integrationsprüfstände führen verlässliche Diagnoseprogramme aus und vergleichen den genauen Maschinenzustand oder Fehlerkennungen. - Prüfungen der Hardwaretreue decken Wechselwirkungen ab, die isolierte Befehlstests nicht sichtbar machen können. Behandeln Sie etablierte Referenzprogramme als korrekt, wenn bekannt ist, dass sie auf echter Hardware bestehen. Untersuchen Sie Emulator, Prüfstand, Prüfanordnung und Umgebung, bevor Sie dem Referenzprogramm einen Fehler zuschreiben. Erfassen Sie akzeptierte Fehler ausdrücklich mit einer eng begrenzten Begründung. Eine Liste bekannter Fehler erlaubt weder, neue Regressionen zu verbergen, noch eine bestehende Ausnahme auszuweiten. Prüfen Sie sowohl Endwerte als auch die Vorgangsreihenfolge, wenn Hardware Zwischenzugriffe beobachten kann. Ergänzen Sie einen Regressionsfall, sobald eine Berichtigung der Spezifikation oder ein zuvor falsch eingeordnetes Verhalten die Umsetzung ändert. ## Speicherstände vollständig wiederherstellbar machen und nach einem Absturz anhalten Speicherstände müssen jeden Baustein enthalten, der die weitere Ausführung beeinflusst, darunter die Zustände von Prozessor, Bildausgabe, Ton, Zuordner, Halteregister, Unterbrechungen und Zeitsteuerung. Prüfen Sie, dass Serialisierung mit anschließender Wiederherstellung die Ausführung reproduziert, und nicht nur, dass sich die Daten einlesen lassen. Stellen Sie dauerhaften Speicher über eine eindeutige Rückruffunktion oder Speichergrenze bereit, statt den Kern an eine einzelne Trägerumgebung zu koppeln. Halten Sie gewöhnliche Steuergeräte als einfache Zustandsautomaten mit eindeutigen Tastenübergängen und seriellen Protokollen. Modellieren Sie besondere Peripheriegeräte über eigene APIs, die ihr unterschiedliches räumliches, zeitliches oder lichtempfindliches Verhalten bewahren. Setzen Sie nach einer nicht behebbaren Ausführungsausnahme einen eindeutigen Absturzzustand und verhindern Sie die weitere Ausführung von Einzelbildern. Fordern Sie zur Wiederherstellung einen dokumentierten Neustart oder ein erneutes Laden des Programms, statt mit einem teilweise veränderten Zustand fortzufahren. Halten Sie akzeptierte Programmeingaben und öffentliche Rückruffunktionstypen stabil. Pflegen Sie öffentliche Typdeklarationen gemeinsam mit der Umsetzung, damit Nutzer im Browser und auf dem Server denselben API-Vertrag vorfinden. ## Erzeugte Dateien nur über den Build erstellen und Ungetestetes melden Erzeugen Sie Verteilungspakete, minimierte Dateien, Quellcodezuordnungen und Deklarationen durch den genehmigten Erstellungsvorgang. Bearbeiten Sie erzeugte Ausgaben nicht unmittelbar. Prüfen Sie jedes unterstützte Laufzeitziel und Modulformat, das das Projekt zusichert. Die fortlaufende Integration muss dieselben lokal vorgeschriebenen Prüfungen für Formatierung, statische Prüfung, Erstellung, Typprüfung und Tests ausführen. Ziehen Sie vor einer Änderung des Hardwareverhaltens maßgebliche Spezifikationen und verlässliche Umsetzungshinweise heran. Dokumentieren Sie den Grund für nicht offensichtlichen Code nahe am betroffenen Vorgang, einschließlich der beobachtbaren Folge einer Änderung seiner Reihenfolge. Prüfen Sie den abschließenden Änderungsvergleich auf versehentliche Bearbeitungen erzeugter Dateien, veraltete öffentliche Dokumentation, ungeprüfte Zeitpfade und sachfremde Aufräumarbeiten. Berichten Sie die ausgeführten gezielten Prüfungen, gegebenenfalls Ergebnisse der Leistungsmessung, bekannte Fehler und jeden noch ungeprüften Hardwarepfad.