snesfreaks.com

Stunde 35
Disassembled: 15.018 / 1.048.576 Bytes (1,432%)
Gehört: Souleye - VVVVVV OST, Sivak - Battle Kid: Fortress of Peril OST

Nachdem das einstündige Bugtracking erfolglos blieb, begebe ich mich jetzt an das, was ich halbwegs verstehe: Die Grafiken und der ganze Rest.

~~~
Dank der Arbeit von vorhin und der Tatsache, dass die Programmierer ab hier endlich angefangen haben, mal dieselben DMA-Subroutinen zu nehmen, statt immer wieder neue einzuführen, weiß ich jetzt, wo die die Tiles für das Gedicht am Anfang liegen. Auf, auf, es geht ans Rippen.
~~~
Dear Diary,
Jackpot.
Das ist eine ziemlich große Sammlung an Kanjis, dafür dass die bestimmt nicht alle im Gedicht und im Menü verwandt werden. Vielleicht auch für das Ending, vielleicht auch für irgendwelche Cutscenes. Was weiß ich. Jedenfalls habe ich das jetzt schon mal.
Hier ein Screen des gesamten Sammelsoriums: ~~~ *hust*
Da ich keine Möglichkeit habe, in meiner ROM es zu testen, ob ich *wirklich* das Tileset für das Gedicht getroffen habe, musste ich die Original-ROM kopieren und zerschießen. Hat geklappt, yeah!
~~~
$2000 Byte Tiles und $800 Byte Tilemap machen zusammen $2800 = 10.240 Bytes. Das ist wie doppelter Wortwert bei Scrabble.
~~~

Stunde rum, Resümee:
Auch wenn ich meine ROM leider nicht zum Laufen gekriegt habe und wohl vorerst auch nicht zum Laufen kriegen werde, habe ich dann doch einen guten Sprung nach vorne gemacht, indem ich ein derart großes Tileset an Land gezogen habe. Auch wenn es mich reizen würde zu sehen, wo das alles noch hinführt, sollte ich jetzt besser aufhören, weil meine Ömme das gerade nicht mehr mitmacht...

Stunde 36
Disassembled: 15.188 / 1.048.576 Bytes (1,448%)
Gehört: Invalids - Eunoia

Um den Verstand, wie letzten Samstag, vollends über dieses Projekt zu verlieren: Noch eine Stunde.

~~~
Es läuft gerade eine Kettensäge Amok durch das Haus. Ich mache mal das Fenster auf, vielleicht will sie einfach nur in den Süden fliegen.
Scheinbar dient $75 als "kleiner Timer", während $10 als "großer Timer" dient.
~~~
Also, der Kram unter "ShowPmNoExit" ist der Check, ob ein Buttion gedrückt wurde, und alles unter "BEQ ShowPmExit" ist die Überleitung zum Title-Screen. Selbiger liegt bei Jump-Table-Eintrag #$19. Zu dumm, dass ich gerade nicht mehr die Konzentration habe, mich damit wirklich auseinander zu setzen.
Alles wegen dieser Nachtrappen.
~~~
"Schneewittchen, Schneewittchen, lass deine Altersversorgung herunter!"
So muss sich ein 65816 fühlen, wenn man ihn falsch branchen lässt.
Wenn ich diese Button-Test-Schingeling, die ich oben erwähnte, richtig verstehe, reagiert sie auch auf den Controller in Port 2. Theoretisch. Sollte ich mal testen.
~~~
Gut, der nächste Jump-Table-Pointer-Wert ist #$54. Ich nehme sicherheitshalber einen Taschenrechner, um die richtige Zahl zu treffen. ô_o
~~~

Stunde rum, Resümee:
Mehr von Bewährtem. Die Jump Table folgt jetzt einem sehr bekannten System, und das wird wohl noch eine Weile so weitergehen, da der Intro selbst einer festen Systematik folgt (einige Animationen, aber ansonsten konstantes Ein- und Ausblenden).
Ich habe gerade eben wieder einige Grafikdaten aufgespürt, weshalb ich jetzt sehr begierig bin, noch eine Stunde dranzuhängen.
Ja, nur wegen des Counters.
Aber, ich lass es lieber.

Wuhuuuuu Glückwunsch zum überspringen der 1% Marke

Farbauti hat geschrieben:Wuhuuuuu Glückwunsch zum überspringen der 1% Marke

Danke. Morgen werde ich wohl auch die 2 und 3 Prozent machen. Der nächste DMA Überträgt, wenn ich das richtig sehe, $B000 (= 45.056) Byte in den VRAM. Holla holla.

Stunde 37
Disassembled: 39.460 / 1.048.576 Bytes (3,763%)
Gehört: Harmony of a Hunter - 101% Run (disc 1)

Es hätte "über diesem Projekt" heißen müssen, oder?

~~~
Zunächst ziehe ich mal die Daten, die an den VRAM müssen, aus der Original-ROM. Nebenbei schaue ich mal, was das eigentlich ist / sein müsste. Denn, aufgrund der Stelle, wo das ganze im VRAM hinkommt, weiß ich, was es ist.
~~~
Hm. Interessant. Es sind nur Tiles, keine Tilemaps. Soweit verständlich - es werden alle Tiles für das Intro zusammen übertragen, und je nach dem, welche Szene gezeigt wird, wird eine andere Tilemap gezeigt. Soweit klar. Interessant ist, dass irgendetwas an den Anfang des VRAMs gespeichert wird, wobei das zurzeit für nichts genutzt wird - nicht für Tiles, nicht für Tilemaps. Mal schauen. Vielleicht ändern sie auch einfach kurzerhand die Zuweisung, wo die Tilemaps liegen, auf die Adresse, und schon haben wir einen Sinn im großen Ganzen.
~~~ Gut, das sind die Daten. Wie ich mir dachte, sind das nur Tilesets. Übrigens ist interessant, dass gern zu viel Daten ge-DMA-t werden. Soll heißen: Laut Befehl werden $2000 Bytes ge-DMA-t, beginnend bei (klaro, 'st ja LoROM) $8000. Nächster Befehl wird ge-DMA-t, $7000, beginnend bei... $85D0. Selbe Bank. Folglich wird vieles umsonst doppelt übertragen. Wir sehen in der Darstellung übrigens einen Auszug aus Bank $17, mehr als die Hälfte des Inhalts. Ich habe die Dateien übrigens so abgetrennt, wie es "Sinn" macht, nicht gemäß diesem DMA Gedöns. Soll heißen -das oben waren keine fiktiven Werte-: Die erste Datei ist $5D0 Byte groß (daher auch die häßliche Kante).
Jedenfalls, man sieht auch schon, dass auch bei der dritten Datei zuviel ge-DMA-t wird. Ab der Hälfte, wo es nadelstreifig wird, macht der Inhalt als Tiles betrachtet keinen Sinn. Ich gehe mal davon aus, dass das dritte Viertel der dritten Datei die Tilemap für das Intro ist. Denn, als ich gestern in ZSNES ein wenig mit dem Ein- und Ausschalten der Layer gespielt habe, sah ich, dass der breite schwarze Rahmen um das Intro herum auf BG3 liegt.

Gut, soweit. Dann werde ich für meinen Counter mal nur die Hälfte der dritten Datei draufhauen. Wird eh schon hoch genug sein. :]

Zum Inhalt: Datei 1 enthält den Lokomotivendampf in Nahaufnahme, Datei 2 würde ich mal schwer davon ausgehen, enthält die gesamte Landschaft, Datei 3 enthält die Lokomotive in der Fernansicht.
So weit, so gut.
~~~

Stunde rum, Resümee:
Man hat wenig gearbeitet, wenn der Byte-Counter in die Höhe schnellt.
Eigentlich habe ich nicht viel Aufwand gerade betrieben; ich habe in dieser Stunde die Daten entnommen, in Einzeldateien geteilt und in meine ROM eingebaut. Danach habe ich eigentlich nur meine Dokumentation(en) entsprechend geupdatet. Und ein paar Kommentare geschrieben.
Ich sollte mich wirklich mal an Bank $0A setzen... :-/
Eine "Hilfe" ist, dass jetzt ein zweites Mal auf die Bank verwiesen wird, durch einen Befehl, den ich bereits auseinandergenommen habe. Das bedeutet, ich kann sehen, "was das Ganze variabel macht"; welche Variablen den Ausschlag geben, dass dieses und nicht jenes geschieht. Und das sieht so aus, als wären das... zwei. $F4 und $F5. Überschaubar. Mal sehen. Vielleicht bald. Urlaub ist nicht mehr fern.
Außerdem könnte ich mir vorstellen, dass ich bald noch einen kleinen großen Schritt mit meinem Counter machen könnte - in dem jetzigen Jump Table Eintrag, der auch diese drei Riesen-DMAs enthielt, werden per Schleife zwei mal $2000 Byte in den RAM übertragen. Aber das ein andern Mal...

Noch eine lustige Übersicht: Das ist, für die nicht so bewanderten, eine Übersicht des Programms, mit dem ich meine ROM zusammensetzen lasse, und es zeigt, wie viel Platz auf den einzelnen Bänken noch ist. Die Bank, die ich heute gemacht habe, ist Bank 23. Das heißt: Die Bilddaten der drei Dateien, die ich oben zeige, nimmt bereits sieben Achtel einer Bank ein. Im Vergleich dazu: Bank 00 mit dem gesamten Code hat gerade erst mit Ach und Krach ein Zehntel voll, und das ganze Sound-Enigma auf Bank $0A (=10) nimmt nicht mal 2,5% der Bank in Anspruch. Verkehrte Welt.

Zumindest macht es gut begreiflich, dass mein Bytecounter oben in keinster Weise einen kontinuierlichen Fortschritt widerspiegeln kann.

Für alle, dies noch nicht begriffen haben.

Stunde 38
Disassembled: 39.460 / 1.048.576 Bytes (3,763%)
Gehört: The Killers - Hot Fuss

Ein wenig SPC, solange ich noch klar denken kann.

~~~
Hah, es scheinen die SPC-Register $F4 bis $F7 halbwegs relevant zu sein... haben sie wohl deshalb die DP-Register ab $F0 für den Soundbla reserviert?
~~~
Zur Zeit versuche ich mich durchzuhangeln mit allem Material, was ich habe. Nocashs Fullsnes-Doc, wiki.superfamicom.org und den wikibooks, wobei ich letzteres unsinnig kompliziert finde. Zumal ich zusehens den WLA-Makros kritisch gegenüberstehe (die hier genutzt werden), seit ich weiß, dass die mehr oder weniger stumpf "ausgeklappt" werden und in den Sourcecode geschraubt werden. Da kann ich mir den Quatsch auch sparen.
Mann, ey.
~~~
Eigentlich wollte ich nur heraus bekommen, warum, entgegen des vielfach verbreiteten "Wie bringe ich Daten zur APU", nicht mit dem Lesen begonnen wird, sondern mit dem Schreiben - es wird vor dem #$BBAA-Sülz einmal #$80 in $2143 geschrieben.
Die Lösung ist:
Irgendwie finde ich irgends etwas, wo $2143 wirklich genutzt wird. Es sind immer nur die ersten drei APU-Register.
~~~
Folglich bleibe ich jetzt bei der magischen Losung des Tages: "Isso" und mach nu weiter, ohne das verstanden zu haben.
Schließlich ist das nur ein Befehl, und was kann schon ein einzelner Befehl beim SNES bewirken?! Hah!
o_ô
~~~
Gut, "SPCIntro1" heißt jetzt "SPC_WaitForBoot".
~~~
Nach vielem Hin und Her werde ich das Soundzeug erst einmal sein lassen. Es ist wieder einmal an ikari_01, den Tag zu retten... ;____;
Das Problem ist, dass ich immer noch nicht mit den Erklärungen von Assemblerbefehlen zurecht komme. Auch nicht mit schönen schematischen Zeichnungen, die WDC zur Verfügung stellt.
Es geht um den Befehl "LDA [F0], Y", dargestellt auf Seite 305 des Handbuchs. Ich gehe davon aus, dass es die Inhalte von $F0 bis $F2 als Adresse nimmt, Y zuaddiert und das dann lädt.
Denn, bevor diese Subroutine (SPCIntro3) aufruft, werden in $F0 bis $F2 Werte geladen, die nach $0A80E4 aussehen, was insofern passen würde, weil auf Bank $0A dann $0000 bis $00E3 für eine Jump Table dienen, und ab $00E4 für ein Liederl o. ä. dienen. Theoretisch. Ich hoffe auf Vorab-Verifizierung meiner höchsten ASM-Instanz.

Bis dahin...
~~~
Zwei Minuten später hatte ich besagte Verifizierung. Yay, danke!
~~~

Stunde rum, Resümee:
Okay, ich mache jetzt hier den Cut; ich stehe gerade am Fuße des Berges.
SPCIntro2, damit auch SPCIntro3 und SPCIntro4, sind alle für den Daten-Transfer zuständig. Für diejenigen, die das hier nur beiläufig lesen: Das ist der Kram, den ich auf Seite 1 auseinandergenommen habe, wo Lord ikari erklärte. Die Geschichte mit der fußgesteuerten Schleife, you know? Genau diese Sache liegt jetzt vor mir. Und eigentlich... eigentlich will ich nur wissen, wie groß die Daten sind, die ich ausschneiden muss.

Diesmal kein Upload, habe ja so gut wie nichts gemacht (außer eine SR umbenannt).

Stunde 39
Disassembled: 39.460 / 1.048.576 Bytes (3,763%)
Gehört: Kiddos BS-Youtube-Playlists, weil ich endlich die von ihm erwähnte BS-Ihatovo-Monogatari-Werbung finden will

Es wird wohl nicht viel bringen, sich an dem Kompliziertesten bisher zu versuchen, oder zumindest das, was mich am meisten mit Respekt erfüllt, während ich mich nebenbei auf konstantes englisches Gerede zu konzentrieren versuche.
Hm. Tja.
~~~
Ich habe kurz vor dem Ende der letzten Stunde noch etwas interessantes gefunden. So klein, dass ich es übersehen habe. Geklaut von wiki.superfamicom.org:

$2140 = Status
$2141 = Command / Data
$2142-3 = Address

*bäääm*!
~~~
Gut, gehen wirs anders an. Soweit ist eigentlich alles klar. Y enthält den Counter für diesen ausgefreakten indirekten Lesebefehl und wird auf null gesetzt. A bekommt diesen Signalwert, dass der SPC-Boot abgeschlossen ist, und dann wird der Prozessor solange in einem Loop gehalten, bis das Signal auftaucht. Oookay, soweit.
Dann hauen wir den Akkumulator mit dem Schrumpfhammer und geben ihm ein #$CC. #$CC ist, laut den SPC-Transfer-Tutorials, der Startbefehl, den man immer hineinschreiben muss, um, na ja, das Ding zum Anlaufen zu bringen. #$CC muss zu $2140, dann gehts los. Wir schieben #$CC auf den Stack.
A wird entschrumpft.
Es kommt die Mutter aller Ladebefehle:
$F0-$F2 bilden die Grund-Ladeadresse: Bank $0A, Adresse: $00E4. Y ist ja noch null, folglich wird $00E4 derselben Bank gelesen. Das ist... $1870.
Y wird um zwei erhöht, A in X verschoben.
A: #$1870, X: #$1870, Y: #$0002
Jetzt wird $0E4 + Y = $00E6 in A geladen: #$0700. Y wird zweimal inkrementiert.
A: #$0700, X: #$1870, Y: #$0004
A wird in $2142 gespeichert. $2142 sollen laut obiger Beschreibung die Adressregister sein, also schätze ich mal, dass damit ab jetzt in den SPC-RAM ab $0700 geschrieben wird, woll?
A wird geschrumpft.
Ab jetzt kommt der Teil, den ikari erklärt hat... jetzt wird sich zeigen, dass ich ihn nicht verstanden habe!
Durch den Compare wird das Carry-Flag gesetzt, da X > #$0001 ist. A wird 0 und der Carryflag wird "reingedreht". #$01 wird in $2141 gespeichert (warum, erkläre ich gleich). ADC #$7F wird addiert, A enthält #$80, deshalb wird, wenn ich ikari richtig verstanden habe, der Overflow-Flag gesetzt.
Jetzt wird #$CC geladen und in $2140 gespeichert.
Dann wird im RepeatingLoop1-Solange gewartet , bis er startklar ist, dann wird zu SPCIntro4 gebrancht, da der Overflow ja gesetzt ist.

Kurzer Einschub. Um das SPC zu starten, muss man zwei Dinge tun. Bei wiki.superfamicom.org wird es so erklärt: Hier passiert dasselbe, nur in zwei Einzelschritte geteilt - zuerst wird !0 in $2141 gespeichert (man musste mir erklären, dass !0 "irgendwas, nur nicht 0" heißt; ich bin ja schließlich kein Programmierer, ich bin ja nur eine TmS), danach kommt der andere Teil. So, springen wir zu SPCIntro4. Ich sollte erst einmal rekapitulieren, was überhaupt in unseren Registern ist.
A: #$77, X: #$1870, Y: #$0004
Es wird Der nächste Wert aus der ROM geladen, A: #$20, Y wird um eins erhöht.

Und ab jetzt wirds wirklich krank. A und B werden getauscht, A und B werden überschreiben, Direct Page wird weggedrückt, A und B werden tauscht... äh?
Anyhow, X ist offensichtlich die Datenmenge, die übertragen werden soll, da X darüber entscheidet, wann der Cycle verlassen werden soll. Also, hoffe ich mal, dass es damit zusammenhängt. Den Rest... finde ich trotzdem seltsam.

Stunde rum, Resümee:
Ich habe das SPC-Getue in mich nicht zufriedenstellendem Maße grob überschauen können. Ich weiß jetzt (bzw. ... eigentlcih behaupte ich das jetzt nur), dass die SPC-Daten wohl einen "Header" haben, der die Menge der zu übertragenden Bytes enthält. Hoffe ich. Als nächstes werde ich mal versuchen, die Daten der Original-ROM zu entnehmen, einzufügen und schauen, ob meine ROM dann läuft...

Stunde 40
Disassembled: 39.538 / 1.048.576 Bytes (3,771%)
Gehört: Kiddos BS-Youtube-Playlists, weil ich endlich die von ihm erwähnte BS-Ihatovo-Monogatari-Werbung finden will

Ich werde jetzt mal halbwegs blind die Musikdaten hineinkopieren und schauen, ob das plötzlich funktioniert.

~~~
Okay, ich mache einen Test. Der X-Wert ist auf $1870 gestellt, also gehe ich zum Anfangswert der SPC-Daten ($0005:00E4) und kopiere $1870 Byte plus vier Byte für den Header, binde das in meine ROM ein, kompiliere und starte.
Nix.
DAnn kopiere ich alles zwischen $00E4 und dem Anfang der ersten Befehle alles und füge es ein.
Und es geht.
Das ist echt unbefriedigend, so.
Aber was soll man machen? :/
Gerade reicht mir meine bisherige Auseinandersetzung mit diesem Schmarrn, ich mache wann anders mit dieser Bank weiter.
Ich glaube, diese Daten werde ich nicht als "disassembled" zählen, solange ich diesen Übertragungsloop nicht komplett verstanden habe.
~~~

Stunde rum, Resümee:
Ich belasse es erstmal. Die ROM läuft, ich habe noch ein bisschen im Code selbst weitermachen können (nichts nennenswertes).
Das ist doch schonmal ein Fortschritt, was?

Kleines Gimmimmimick:

Eine ROM.

Ich habe einfach nur den Jump Table-Pointer nach dem Fade-des-Hector-Logos wieder auf das Laden und Anzeigen des Hector-Logos umgeswitcht, und schon passiert nichts schlimmes mehr...!

Okay, gutes passiert auch nicht. Aber egal! Kinders, es läuft!

Stunde 41
Disassembled: 39.789 / 1.048.576 Bytes (3,795%)
Gehört: David Wise & Eveline Fischer - Donkey Kong Country 3 OST

Weiteres stumpfes Disassemblen für einen geruhsamen Ausklang des Tags.

~~~
Stunde rum, Resümee:
Öhm... stört es wen, dass ich nichts zu sagen habe? Ich habe disassembled, ja. Stumpf, ja. Keine besonderen Vorkommnisse. Ein neuer großer Verzweiger, ein neuer großer StatChanger, ein neuer großer Aufhänger aufgrund von fehlenden Sounddaten (oder so). Alles beim Alten. Morgen mehr, vielleicht.

カイロ団長は
あくどいしょうぱいき
すろヤツなんですつて

Grandmaster Cairo
Es ist klein pie ki eklatante
Ich werde einen Mann

Also mal ehrlich. Wer braucht in Zeiten von Google-Translate noch Übersetzer.

(Grandmaster Cairo ist, glaube ich, eine Figur aus Miyazawas Erzählungen).

EDIT: Auf Anhieb gesehen, dass ich das falsche Zeichen gesetzt habe:

カイロ団長は
あくどいしょうぱいを
すろヤツなんですつて

Grandmaster Cairo
Ein kleiner Kreis eklatante
Ich werde einen Mann

Oh yeah!

Also lytron, ich verstehe nicht mal ansatzweise was du hier machst, doch ich muss dir jetzt einfach mal meinen Respekt aussprechen. Ganz große Leistung und vor allem wahnsinn was du da für eine Energie reinsteckst. Ich hätte wohl irgendwann keine Lust mehr
Weiter so.

kolwe-x hat geschrieben:Also lytron, ich verstehe nicht mal ansatzweise was du hier machst, doch ich muss dir jetzt einfach mal meinen Respekt aussprechen. Ganz große Leistung und vor allem wahnsinn was du da für eine Energie reinsteckst. Ich hätte wohl irgendwann keine Lust mehr
Weiter so.

Also, von Lust kann irgendwie auch nicht mehr die Rede sein...

Dankeschön für den ermunternden Kommentar von dir, ebenso für die der anderen, bisher. Das gibt einem immer wieder von neuem einen Anreiz, das nicht irgendwann mittendrin mal sein zu lassen.

Stunde 42
Disassembled: 40.077 / 1.048.576 Bytes (3,822%)
Gehört: Kante - Zombi

Free the Bytes!
Und wenn ihr das schon nicht macht, kauft wenigstens Fair-Trade-Kaffee.

Stunde rum, Resümee:
Öhm. Keine besonderen Vorkommnisse. Quasi.

Ich habe wieder disassembled, in großen Teilen, ohne nachvollziehen zu wollen, was ich da tu. Und ab dieser Stelle wäre quasi der Gebrauch eines handelsüblichen Komplett-Disassemblers sinnvoller.
Jein. Zumindest behalte ich so noch im Geringen den Überblick. Ich habe ein wenig den Eindruck, als hätte ich plötzlich wieder den falschen Jump-Table-Eintrag auseinandergenommen, will das aber nicht prüfen. Erschwerend kommt hinzu, dass gerade viele Variablen ins Spiel gebracht werden, deren Nutzen mir noch nicht klar ist. Alles eher komić.

Ich werde trotzdem bald besser mal Bank 00 noch einmal komplett mit dem Original abgleichen. Ich werde fahrig.

Stunde 43
Disassembled: 40.912 / 1.048.576 Bytes (3,902%)
Gehört: Ihatovo Monogatari OST

Die jetzige frühe Morgenstunde stelle ich mal unter das Zeichen der Qualitätssicherung. Erst einmal ein Abgleich des bisherigen mit der Originaldatei.

~~~
Okay, die QS ergab...
... keine Abweichungen (SNES-Header und Platzhalter ausgeschlossen), alles einwandfrei.
Schön.
Was mach ich jetzt mit der verbliebenen Dreiviertelstunde?
~~~
Weil ich so ein Counter-Miststück bin, gucke ich mir nochmal Grafikdaten an, zu denen ich gestern den Flexi-DMA-Aufruf disassemblet habe. Immerhin $300 Byte.
~~~ Shakka-Lakka, ich wedle mit dem...
... Ohren.
Das Latin-Letter-Set für den Copyright-Hinweis.
Das -oh, ich vergaß!- Flexi-DMA-Getue entstammt Jump-Table-Eintrag Nr. $19, wohin es geht, wenn ein Button gedrückt wird. Also: Titelbildschirm.
Das erklärt auch, weshalb nur, ich glaube, $14 Bytes in die entsprechende Tilemap ge-DMA-t werden.
~~~
Die erwähnten $14 Byte Tilemap liegen übrigens, erstaunlicherweise, auf Bank $00.
~~~
Gut. ROM Map geupdatet... und trotzdem noch zehn Minuten. *achselzuck* Bitte! Dann disassemble ich weiter!
~~~

Stunde rum, Resümee:
... also, wenn ich allen Hinweisen zu Grafikdaten nachgehen würde, die ich bis zu diesem Punkt disassemblet habe, würde ich vermutlich die 5%-Marke knacken. Ist doch eigentlich ein sehr interessanter Punkt, dass allein das Intro (ohne Musik) mehr als ein Zwanzigstel des Speichers einnimmt. Wie auch immer. Ich muss zur Arbeit.