Hallo zusammen, ich möchte gerne einen Game Boy Emulator mit einem AVR Mikrocontroller realisieren. Den Programmiertechnischen Teil habe ich im Griff da ich bereits seit vielen Jahren programmiere. Um die Komplexität abzuschätzen habe ich bereits in den letzten 2 Wochen zusammen mit einem Kumpel einen Game Boy Emulator für den PC programmiert und dieser läuft bereits fast fehlerfrei. Ich brauche daher ein paar Denkanstöße zur Hardware, da ich erst seit ein paar Monaten mich mit Mikrocontrollern beschäftige. Bisher habe ich die meisten AVR Tutorials auf eurer Seite durchgearbeitet und ein wenig selbst mit Infrarotempfängern und IR-LEDs gespielt. Also zur Hardware des Game Boys. Das Display hat eine Auflösung von 160x144 und kann 4 Graustufen darstellen. Bisher habe ich da noch kein passendes Display gefunden das man nehmen kann. Bin hier für jeden Vorschlag dankbar. Bitte aber mit Auflösungen über 160x144, da ich ungern etwas vom Bild abschneiden möchte. Die CPU des Game Boys hat 1MHz also hätte ich je nach Mikrocontroller 16 oder 20 Instructions zur Verfügung, um eine Game Boy Instruction zu verarbeiten. Dazu kommt noch das viele Game Boy Instructions länger als ein Cycle dauern. Dies sind vor allem die Instructions die nicht nur Operationen auf den Registern auführen sondern auch auf den RAM zugreifen. Generell sehe ich es also als machbar an nur die CPU auf einem Mikrocontroller zu emulieren. Leider kommt noch der LCD Controller hinzu aber dazu später. Leider hat der Game Boy relativ viel RAM zur Verfügung. Insgesamt sind wir bei etwas über 16KB und dann kommt eventuell noch externer RAM von bis zu 32KB auf den Spielen hinzu. Unter den normalen AVRs scheint der ATmega1284 mit 16KB RAM schon das höchste der Gefühle zu sein. Daher frage ich mich ob man irgendwie externe RAM Bausteine nutzen kann um auf die benötigte Speichergröße zu kommen. Weiteres Speicherproblem sind die ROMs die wohl bis zu 2MB groß sein können. Auch hier wäre ein externer Flash oder EEPROM Baustein sicherlich sinnvoll. Auch hier bin ich für alle Vorschläge offen. Zum Schluss noch zum LCD Controller. Da ein Mikrocontroller mit dem Emulieren der Game Boy CPU vermutlich bereits ausgereizt ist dachte ich daran ob man für den LCD Controller nicht einen zweiten Mikrocontroller nimmt. Damit könnte man auch das RAM Problem teilweise lösen, da 8KB von den oben gennanten 16KB auf den VRAM des LCD Controllers entfallen. Allerdings stellt sich dann die Frage wie man die Controller untereinander kommunizieren lässt. Es sollte möglich sein in ca. 20 Cycles ein Byte zwischen den Controllern zu übertragen. Im echten Game Boy sind CPU und LCD Controller scheinbar auch zwei getrennte Einheiten, da es einige Flags gibt die angeben ob der VRAM grade vom LCD Controller genutzt wird. Solange kann die CPU nicht auf diesen zugreifen. Ich habe mich hier auch noch gefragt ob man bei externen RAM Bausteinen das ganze so aufbauen kann, dass beide Controller auf den gleichen Baustein zugreifen können. So das war jetzt erstmal was mir zur Hardware einfällt. Falls ihr Bauteile vorschlagt so sollten diese am besten als DIL Variante existieren und Mikrocontroller mit dem STK500 programmierbar sein.
Wenn ich mich nicht irre, verwendet der Gameboy einen Klon des Z80. Anderswo in diesem Forum gibt es einen AVR-basierten CP/M-Emulator - das ist ein Betriebssystem, das wiederum auf einem Z80 läuft ... Beitrag "CP/M auf ATmega88" Ob allerdings eine Echtzeit-Emulation möglich wird, da habe ich (bzw. mein Bauch) leichte Zweifel.
:
Bearbeitet durch User
Hej, wenn es nicht umbedingt ein AVR sein muss, dann könntet ihr z.B. dieses STM-Board nehmen: http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090 Kostet 20 € und hat fast alles drauf (Controller, Debugger, LCD, 64MBit RAM) was ihr braucht. Fehlen eigentlich nur noch Tasten und Audio. Wenn ihr aber auf eine ordentliche Herausforderung aus seit, dann solltet ihr beim AVR bleiben. :) Halt uns auf dem laufenden mit dem Projekt, würde mich interessieren, ob das klappt!
Ich bilde mir ein, bereits vor zwei Jahren oder mehr hier im Forum den Link zu einem funktionierenden GB-Emulator gefunden zu haben. Dieser beruhte auf einen ATmega64, ob noch RAM oder ein zweiter uC verbaut wurde weiß ich grad nicht. Da gabs auf jeden Fall ein Youtube Video...
Eigentlich wollte ich das ganze schon gerne auf dem AVR machen. Die einzelne Hardware selbst zusammenlöten und dann alles Schritt für Schritt in Betrieb nehmen finde ich sehr interessant. Ob das ganze anschließend in Echtzeit läuft ist dann noch eine andere Frage. Wenn nicht wäre es auch nicht so schlimm solange überhaupt irgendwas passiert. Audio soll am Anfang auch erstmal weggelassen werden. Es geht also "nur" um das Emulieren der CPU und des LCD Controllers erstmal. Den Artikel zum CP/M-Emulator hab ich mir mal angeschaut aber war nur teilweise informativ. Das schien alles irgendwie aus Teilen zusammengebaut die gerade da waren. Welche RAM und Speicherbausteine sollte man am besten nehmen wenn man mehr braucht als der Mikrocontroller zur Verfügung hat?
Meinst du eventuell dieses (http://www.youtube.com/watch?v=SaoxAr0_mec) Video? Das ist jetzt natürlich ein AVR32 und Game Boy Color Emulator. Ich würde gerne nur den Game Boy Classic emulieren und das auf einem 8-Bit AVR.
Ok, wenn ihr beim AVR bleiben wollt um alles von vorne bis hinten selber durchziehen ist das natürlich auch gut. Es gibt da ja eine ganze Menge, was man lernen kann. Einige größere AVRs haben externe Speicherbusse. Diese wären gut geeignet, da sie nicht sehr viel langsamer sind als der interne Speicher (im Vergleich mit SPI-Speicher z.B.). Allerdings gibt es diese AVRs AFAIK nur als SMD, genauso wie die Speicher-Bausteine. Das bietet dann auch gleich die Möglichkeit zu lernen wie man eine Platine layoutet.
sebi707 schrieb: > Meinst du eventuell dieses (Youtube-Video "Atmel-AVR32 uc3 Gameboy > Emulator") > Video? Das ist jetzt natürlich ein AVR32 und Game Boy Color Emulator. > Ich würde gerne nur den Game Boy Classic emulieren und das auf einem > 8-Bit AVR. Ne, also das war schon ein normaler AVR bzw. Classic-Emulator. Ich habs nur noch dunkel im Kopf, glaub aber dass da sogar zwei ATmega64 drauf waren...
>wenn es nicht umbedingt ein AVR sein muss, dann könntet ihr z.B. dieses >STM-Board nehmen: >http://www.st.com/web/catalog/tools/FM116/SC959/SS... Du meinst so wie das hier?: http://hackaday.com/2014/01/14/sega-master-system-on-a-stm32-development-board/
toss schrieb: > Hej, > > wenn es nicht umbedingt ein AVR sein muss, dann könntet ihr z.B. dieses > STM-Board nehmen: > http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090 > gerade in Arbeit :-)
Atmega169 unterstützt bis 64kb externes SRAM. Ich würde allerdings eher zu einem xmega a1 raten. Dann kann gleich das gesamte Rom in den externen SD-RAM.
Ein Gameboy hat einen Z80 der bei ca. 4.2 MHz läuft. Ich bezweifle, dass ein AVR es sicher packt, den in Echtzeit zu emulieren. Und Grafik, Sound und ein paar weitere Sachen kommen noch dazu! Der Gameboy hat außerdem insgesamt 16 KB SRAM; manche Module bringen Zusatz-RAM mit. Ich glaube ein kleiner 8-Bit AVR ist hier fehl am Platze, das ist wirklich eine Anwendung, wo du einen ARM verwenden solltest. Die gibt es billig mit mehr als genug Ressourcen für deine Anwendung.
Die 4MHz sind zwar auch richtig je nachdem ob man Clock-Cycles oder Machine-Cycles betrachtet. 4 Clock-Cycles entsprechen einer Machine-Cycle. Deshalb findet man je nach Quelle, dass der Gameboy nur 1MHz hat. Bei einem AVR mit 16MHz hätte ich also wie oben schon gesagt 16 Instructions um eine Game Boy Instruction zu emulieren. Das klingt für mich noch halbwegs machbar vor allem auch weil viele Instruction auch noch mehrere Machine-Cycles dauern. lex schrieb: > Ne, also das war schon ein normaler AVR bzw. Classic-Emulator. > Ich habs nur noch dunkel im Kopf, glaub aber dass da sogar zwei ATmega64 > drauf waren... Wenn du das noch wieder finden würdest wäre das sehr hilfreich.
Bzw: Es würde mich auch reizen deinen Emulator zu portieren- ich gab gerade einen passendes Entwicklungsboard. Wenn du den code hochlädst schaue ich das mir mal an.
sebi707 schrieb: > Bei einem AVR mit 16MHz hätte ich also wie oben schon gesagt > 16 Instructions um eine Game Boy Instruction zu emulieren. Naja, auch beim AVR brauchen viele Instruktionen mehr als 1 Taktzyklus, insbesondere wenn du Branches hast (und mind. 1 Branch/Jump hast du pro emulierter Instruktion). Du musst für die Emulation a) den Opcode laden b) den Opcode dekodieren c) die Operation ausführen d) ggf. das Ergebnis zurückschreiben e) ggf. Seiteneffekte handhaben (Statusregister usw.). 16 Taktzyklen sind da sehr wenig Zeit! > Das klingt > für mich noch halbwegs machbar vor allem auch weil viele Instruction > auch noch mehrere Machine-Cycles dauern. Selbst wenn, Grafik und Sound sind sehr aufwändig zu emulieren. Du musst ja z.B. nicht nur die Grafikdaten an das Display rausschieben, der Gameboy hat auch Sprites und anderes Zeug zur Beschleunigung von Animationen und Scrolling. Und Sound: 4 Kanäle mit ADSR-Envelope, verschiedenen Wellenformen usw. Achso: anderes "Kleinvieh" wie Timer hast du da auch noch, was emuliert werden will... Ich sehe da kein Land mit einem AVR. Vielleicht mit drei Stück: einer für CPU & Co, der zweite für Grafik und der dritte für Sound? Dann hast du aber wiederum ein Problem mit der Kommunikation zwischen den 3 Mikrocontrollern.
So hier mal der Source Code des bisherigen Emulators. Ist momentan aber eher Resourcen fressend programmiert da wir erstmal etwas funktionierendes haben wollten. Der Code ist in C++ und mit relativ neuen Features von C++11 daher brauchst du einen aktuellen Compiler. Das Rendering ist bisher auch noch nicht vollständig, da noch das Window-Rendering fehlt und bin mir auch nicht sicher ob ich schon alle Flags für Sprite-Rendering richtig unterstütze. Außerdem gibt es einen Bug z.B. bei Tetris wo man keine Punkte beim abbauen von Lines erhält. Im übrigen geht es mir nicht darum Hardware auszusuchen wo der Emulator auf jeden Fall funktioniert sondern Hardware wo man sich schon etwas anstrengen muss und nicht Resourcen verschenken kann wie sonstwas. Ansonsten könnte ich jetzt bei der PC Version bleiben oder eine Android Version basteln aber das ist nicht mein Ziel.
In Assembler ist sehr wohl möglich. Schau dir mal die uzebox an bevor du den avr so degradierst. Den oppcode in 16 Zyklen auszuführen ist kein Problem: Code laden 3 Dekodieren 2 (Sprungtabelle) Ausführen Zurückspringen 2 Also bleibt genug für die Ausführung. Die restlichen Takte werden für sound und display genutzt.
Die Datenübertragung von einem AVR zum anderem würde ich über ein 8Bit Latch machen, Daten ans Latch anlege ein bishen geklingel und man kann den Port wieder anderweitig nutzen der 2te AVR holt es sich dann vom Latch ab wenn er Zeit hat.
sebi707 schrieb: > Im übrigen geht es mir nicht darum Hardware auszusuchen wo der Emulator > auf jeden Fall funktioniert sondern Hardware wo man sich schon etwas > anstrengen muss und nicht Resourcen verschenken kann wie sonstwas. Andererseits ist es auch nicht sinnvoll, etwas anzugehen, das aussichtslos ist. Mit einem bastlertauglichen DIP-ATMega wird das nix. Zu langsam, zu wenig RAM, und so weiter. Wenn's AVR sein soll, dann lieber mindestens der fetteste XMEGA, den du kriegen kannst. Das ist immer noch Herausforderung genug. :)
ajo schrieb: > In Assembler ist sehr wohl möglich. Schau dir mal die uzebox an bevor du > den avr so degradierst. Den oppcode in 16 Zyklen auszuführen ist kein > Problem: > Code laden 3 > Dekodieren 2 (Sprungtabelle) > Ausführen > Zurückspringen 2 Statt "Zurückspringen" "Code laden".
ajo schrieb: > In Assembler ist sehr wohl möglich. Schau dir mal die uzebox an > bevor du > den avr so degradierst. Den oppcode in 16 Zyklen auszuführen ist kein > Problem: > Code laden 3 > Dekodieren 2 (Sprungtabelle) > Ausführen > Zurückspringen 2 > Was ist mit: * Statusregister aktualisieren? (trifft auf die meisten Opcodes zu) * PC inkrementieren? Das ist jetzt doch etwas zu trivialisiert. Bei den Opcodes die mehr als 4 Takte brauchen sieht es etwas entspannter aus, aber die schnellen Opcodes kann man ja nicht ignorieren oder einfach langsamer laufen lassen. > Also bleibt genug für die Ausführung. Die restlichen Takte werden für > sound und display genutzt. Wenn du tatsächlich ein paar "freie" Takte zwischen Instruktionen hast, kannst du die aber nur sehr schwer sinnvoll nutzen.
Stimmt dafür benötigt die Sprungtabelle 2 Takte mehr (ijmp+rjmp). Auf einem Xmega64A1 mit sdram müsste es eigentlich gut machbar sein. Möglichweise ist da sogar eine GameboyColor Emulation möglich.
greg schrieb: > * Statusregister aktualisieren? (trifft auf die meisten Opcodes zu) > * PC inkrementieren? Der PC ist ein Pointerregister im Avr das beim Lesezugriff inkrementiert werden kann. Die Statusregister gibt es beim Avr auch. In weit man die wiederverwenden kann müsste man prüfen. greg schrieb: > Wenn du tatsächlich ein paar "freie" Takte zwischen Instruktionen hast, > kannst du die aber nur sehr schwer sinnvoll nutzen. Man könnte die Ausführung im Timer-Interrupt machen: Dort führt man eine gewisse Anzahl von Befehlen aus und zwar ohne auf die Einhaltung der richtigen Geschwindigkeit zu achten. Allerdings zählt man mit, wie lang die Befehle hätten dauern müssen. Mit dem CTC-Modus wird dann der nächste Interrupt ausgeführt wenn diese Zeit verstrichen ist.
ajo schrieb: > Auf > einem Xmega64A1 mit sdram müsste es eigentlich gut machbar sein. > Möglichweise ist da sogar eine GameboyColor Emulation möglich. Externer RAM ist aber deutlich langsamer als interner RAM, insbesondere wenn man SDRAM verwendet. Mindestens den RAM des Gameboy sollte man IMHO für die Emulation in den internen SRAM stecken. Und dann braucht man eigentlich gleich den fettesten XMEGA mit 32 KB SRAM.
Der Xmega muss doch nur maximal 2 Byte schreiben/lesen pro µs. Einen Befehl zum Ausführen und einen Ramzugriff. Das sind 32 Takte/Byte, da das EBI mit 64Mhz getaktet wird. Außerdem hat er DMA, was den Emulator nochmal entlasten könnte.
greg schrieb: > Mit einem bastlertauglichen DIP-ATMega wird das nix. Zu langsam, zu > wenig RAM, und so weiter. Nö, geht prima. http://www.mikrocontroller.net/articles/AVR_CP/M genug RAM, genug SD-Card, DIP Gehäuse, Z80 Simulation. http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
Also wenn ich einen größeren ATxmega nutzen will müsste ich erstmal gucken wie ich damit arbeiten kann. Selbst Platinen ätzen kommt in meiner Einzimmerwohnung eher nicht infrage und herstellen lassen kostet Geld. Außerdem kann man die scheinbar nicht mit dem STK500 programmieren. Was genau macht den ATxmega denn so viel geeigneter? Der ATxmega64A1 hat 32MHz was ja immerhin das doppelte von den 16MHz der normalen ATmega ist. Allerdings brauch ich dann wohl immer noch einen zweiten Controller für Grafik sachen, da mir sonst nicht der große Vorteil gegenüber zwei ATmega mit 16MHz klar wird. Sound möchte ich im übrigen erstmal ignorieren und nicht ausgeben.
Joe G. schrieb: > Nö, geht prima. > http://www.mikrocontroller.net/articles/AVR_CP/M > > genug RAM, genug SD-Card, DIP Gehäuse, Z80 Simulation. > Toll, aber überhaupt nicht vergleichbar mit dem aktuellen Problem.
greg schrieb: > Toll, aber überhaupt nicht vergleichbar mit dem aktuellen Problem. Es war als Anregung gedacht, sicherlich nicht 1:1 zu verwenden, doch die DRAM Ansteuerung und der Z80 Simulator dürfen gerne verwendet werden.
sebi707 schrieb: > Also wenn ich einen größeren ATxmega nutzen will müsste ich > erstmal > gucken wie ich damit arbeiten kann. Selbst Platinen ätzen kommt in > meiner Einzimmerwohnung eher nicht infrage und herstellen lassen kostet > Geld. Außerdem kann man die scheinbar nicht mit dem STK500 > programmieren. Du kannst einfach ein paar billige Adapterplatinen bei eBay kaufen und den XMEGA darauf löten, dann hast du wieder DIP. > Was genau macht den ATxmega denn so viel geeigneter? Der > ATxmega64A1 hat 32MHz was ja immerhin das doppelte von den 16MHz der > normalen ATmega ist. Allerdings brauch ich dann wohl immer noch einen > zweiten Controller für Grafik sachen, da mir sonst nicht der große > Vorteil gegenüber zwei ATmega mit 16MHz klar wird. Das External Bus Interface (EBI) kann für LCD und/oder SRAM/DRAM genutzt werden, DMA kann Datenschiebereien beschleunigen, ein paar neue und nützliche Instruktionen.
Joe G. schrieb: > greg schrieb: >> Mit einem bastlertauglichen DIP-ATMega wird das nix. Zu langsam, zu >> wenig RAM, und so weiter. > > Nö, geht prima. Das glaube ich nicht. Z. B. die Geschwindigkeit dürfte lausig sein. Kannst du näheres dazu schreiben? > http://www.mikrocontroller.net/articles/AVR_CP/M > > genug RAM, genug SD-Card, DIP Gehäuse, Z80 Simulation. > > http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
Hallo alle! Ich meine einen AVR (auch XMega) Gameboy Emulator schon frueher einmal gesehen zu haben. - Ich bin aber nicht sicher. greg schrieb: > Du kannst einfach ein paar billige Adapterplatinen bei eBay kaufen und > den XMEGA darauf löten, dann hast du wieder DIP. sebi707, ich habe noch einige ATxmega128A3 TQFP64 Adapter (mit Chip) rumliegen. Gerne sponsore ich deinem Projekt ein paar davon. (Du benoetigst aber einen JTAG oder PDI faehigen Programmer - z.B. AVRISP MKII) Wenn du interressiert bist Schreib mir einfach eine PN (und wie viele du benoetigen wuerdest). Ich bin ersteinmal paar Tage weg, aber naechste Woche sollte ich wieder da sein. MfG Stephan
Skeptiker schrieb: > Das glaube ich nicht. Z. B. die Geschwindigkeit dürfte lausig sein. > Kannst du näheres dazu schreiben? Lausig ist eine Frage des Bezugspunktes. Beitrag "Re: CP/M auf ATmega88"
Joe G. schrieb: > Skeptiker schrieb: >> Das glaube ich nicht. Z. B. die Geschwindigkeit dürfte lausig sein. >> Kannst du näheres dazu schreiben? > > Lausig ist eine Frage des Bezugspunktes. > Beitrag "Re: CP/M auf ATmega88" Was sagt die Tabelle aus? Dass das CP/M auf dem Z80-Emulator des ATMega88 mit DRAM so schnell läuft, wie auf einer Z80-CPU mit ca. 3 MHz? Mit welchem Takt wird der ATMega88 betrieben?
Skeptiker schrieb: > Dass das CP/M auf dem Z80-Emulator des > ATMega88 mit DRAM so schnell läuft, wie auf einer Z80-CPU mit ca. 3 MHz? Ja Skeptiker schrieb: > Mit welchem Takt wird der ATMega88 betrieben? 20 MHz
Wie werden die MHz beim Z80 denn gezählt? Sind das 3MHz Clock-Cycles oder Machine-Cycles? Angenommen ich würde jetzt so einen ATxmega nehmen. Dann brauche ich je nach Modell trotzdem noch externen RAM und externen Speicher für die ROMs sowieso. Was würde man da für Bauteile nehmen?
Joe G. schrieb: > Skeptiker schrieb: >> Dass das CP/M auf dem Z80-Emulator des >> ATMega88 mit DRAM so schnell läuft, wie auf einer Z80-CPU mit ca. 3 MHz? > Ja > > Skeptiker schrieb: >> Mit welchem Takt wird der ATMega88 betrieben? > 20 MHz Da der Thread nicht gerade kurz ist, habe ich nur ein wenig quer gelesen. Es sieht so aus, dass die eff. Geschwindigkeit des Z80-Emulators eher bei max. 2 MHz liegt.
Kannst du mir die Quellen verraten, bei denen du genauere Informationen über die Register des Prozessors bekommen hast? Die meisten Dokumente beschreiben nur grob die Funktion der einzelnen Module...
Ich nehme an du meinst die IO-Register und nicht die Prozessor-Register? Generell findet man erstmal recht viele Infos in den pandocs (http://nocash.emubase.de/pandocs.htm). Ansonsten waren diese beiden PDFs noch recht nützlich: http://students.washington.edu/fidelp/galp/megaguides/GameBoyProgrammingManual.pdf http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf Ich versuche Momentan auch noch die Funktion der Sound-Register näher zu verstehen aber hab da auch noch nicht wirklich Informationen gefunden.
Das letzte hatte ich schon gefunden, aber das geht dann nicht weit genug in die Tiefe. Die beiden anderen sehen sehr gut aus. Danke! sebi707 schrieb: > Funktion der Sound-Register xD genau das hab ich mir gerade auch angeschaut. Ich hab PortAudio in dein Projekt eingebunden und bin gerade dabei ein paar Tests zu machen.
Falls du da irgendwas herausfindest wäre ich da auf jeden Fall daran interessiert. Nicht wegen der Ausgabe der Sounds sondern weil ich vermute, dass der Bug in Tetris eventuell an der nicht vorhandenen Emulation der Sound Register liegt. Klingt zwar etwas weit her geholt aber ich bin mir relativ sicher, dass alle CPU Instructions richtig implementiert sind (dank Test ROMs) und auch der Timer richtig funktioniert. Ich könnte mir jedenfalls schon vorstellen, dass beim abbauen der Lines ein Sound/Sweep gestartet wird und dann aufs Ende davon gewartet wird.
Channel2 müsste inzwischen vollständig implementiert sein (aber das ist auch der einfachste). Das Tetris-Problem könnte aber wirklich mit den Flags zusammenhängen. Wenn der Sound-Length-Wert eines Kanals sein Maximum erreicht wird dieser ausgeschalten. In deiner Grafikengine sind noch Bugs. Manchmal flackert nur der Bildschirm, manchmal wird der Bildschirm auch von ganzen Mapstücken überlagert, die gar nicht dahin gehören. Schick mir doch mal eine Email: lkgerr at gmail.com
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.