Forum: Mikrocontroller und Digitale Elektronik Elite auf dem STM32


von Josef (Gast)


Lesenswert?

was haltet ihr davon? Glaubt ihr das er das hinbekommt?
LINK: http://mikrocontroller.bplaced.net/wordpress/

wäre schon cool, denke aber das wird ein haufen arbeit sein
(wobei der STL viewer ja scheinbar schon fast fertig ist)

: Verschoben durch User
von soso... (Gast)


Lesenswert?

Josef schrieb:
> was haltet ihr davon? Glaubt ihr das er das hinbekommt?
> LINK: http://mikrocontroller.bplaced.net/wordpress/
>
> wäre schon cool, denke aber das wird ein haufen arbeit sein
> (wobei der STL viewer ja scheinbar schon fast fertig ist)

Natürlich geht das, Elite kam damals für den Amiga 500. Der hatte einen 
68000 mit rund 7MHz, der F4 hat einen Cortex-M4 mit >100MHz. Der 68000er 
ist eine 16-Bit-CPU der F4 ein 32bitter.
Der F4 dürfte Faktor 50 mehr Leistung haben, oder mehr.

80 frames sind ein absolutes Armutszeugnis für die Implementierung.

von Safari (Gast)


Lesenswert?

soso... schrieb:
> Der 68000er
> ist eine 16-Bit-CPU der F4 ein 32bitter.
> Der F4 dürfte Faktor 50 mehr Leistung haben, oder mehr.

Der 68k ist ein 32bitter.

Faktor 50 kann echt eng sein bei der Emulation eines kompletten Systems.

von Xperte (Gast)


Lesenswert?

Safari schrieb:
> Der 68k ist ein 32bitter.

Nö. Er konnte zwar intern mit 32Bit-Zahlen rechnen, hatte aber nur einen 
16-Bit Datenbus. Er war also ein 16bitter.

von Safari (Gast)


Lesenswert?

Xperte schrieb:
> Er konnte zwar intern mit 32Bit-Zahlen rechnen, hatte aber nur einen
> 16-Bit Datenbus. Er war also ein 16bitter.

Was für eine Quatsch-Definition.

Es ist eine 32bit CPU, die nach aussen nur einen 16bit Datenbus hat. Nur 
weil jeder Zugriff auf zwei aufgeteilt werden muss, wird da keine 16bit 
CPU draus.

von Safari (Gast)


Lesenswert?

Achja, meine 486GX Systeme sind 16bitter, haben ja auch nur einen 16bit 
Datenbus.

von Safari (Gast)


Lesenswert?

... und der 68008 ist ein 8bitter.

von Josef (Gast)


Lesenswert?

soso... schrieb:
> Der hatte einen
> 68000 mit rund 7MHz

aber auch einen eigenen Grafik-Coprozessor
ich denke die CPU funktionen sind bei der Umsetzung nicht das Problem

von Mario L. (mlatzig)


Lesenswert?

Elite gab es schon auf 8Bittern (C64 & andere), mit 1 Mhz. Ich würde mal 
salopp behaupten, sogar auf einem ATmega könnte man Elite mit einem GLCD 
spielen (nicht emuliert), wobei hier wohl eher der RAM als der CPU-Takt 
der Flashenhals wäre.

Josef schrieb:
> ich denke die CPU funktionen sind bei der Umsetzung nicht das Problem

Nein, denke ich auch nicht. Wenn man es nicht emuliert, müsste man den 
Ursprungscode haben (evtl. in Assembler) und ihn für die Zielplatform 
erneut umsetzen (in C oder auch wieder Assembler). Kniffe im Code, die 
reichlich bei den 8Bittern angewendet wurden, sind evtl. nicht 1:1 
umsetzbar bzw. man müsste z.B. für den ATmega eigene Kniffe anwenden, 
aber machbar würde ich das Ganze (z.B. auf einem ATmega128 o.ä. mit 
genügend RAM) halten.

Für einen 32Bitter (STM32) halte ich das für keine Herausforderung.

von Paul L. (Gast)


Lesenswert?

wollte es gerade chriebe.
Auf dem Schneider CPC gab es das Spiel ebenfalls..oder auch MArble 
Madness .-)

von soso... (Gast)


Lesenswert?

Josef schrieb:
> soso... schrieb:
>> Der hatte einen
>> 68000 mit rund 7MHz
>
> aber auch einen eigenen Grafik-Coprozessor
> ich denke die CPU funktionen sind bei der Umsetzung nicht das Problem

Was der genau tut, weiß ich natürlich nicht.

Aber 3D-Beschleuniger (solche die Vektorgrafiken berechnen) hatter der 
Amiga meines Wissens nach nicht.

Mal im Ernst, auf dem STM32F4 wurden schon viel anspruchsvollere Spiele 
zum Laufen gebracht:
https://www.youtube.com/watch?v=bRNcfsDIc2A
Und ja, Doom ist erheblich anspruchsvoller als Elite. Erheblich.

ES wäre sogar Quake möglich. Das müsste nämlich laufen, das benötigt 
einen Pentium 75. Da könnte ein STM32F4 durchaus noch mithalten.
Der Quellcode ist offen:
https://github.com/id-Software/Quake
Quake benötigt keinen 3D-Beschleuniger.

von Markus M. (adrock)


Lesenswert?

Es gibt im Amiga mehrere "Custom Chips" die dafür emuliert werden 
müssen.

Zum einen der Copper, welcher einfach gesagt an bestimmten Rasterzeilen 
während des Bildschirmaufbaus bestimmte Aktionen ausführen kann (nämlich 
die anderen Custom Chips steuern), zum anderen der Blitter, welcher 
schnell Flächen füllen und Linien zeichnen kann.

Wenn das "Gast-"Programm trickreich programmiert ist, muss diese 
Emulation zyklengenau und natürlich zeitgenau erfolgen, damit es richtig 
funktioniert.

Nicht zu vergessen die Emulation der bitplane basierten Grafik.

Die Soundausgabe über D/A-Wandler ist da eher Nebensache.

Außerdem ist der 68k ein CISC, der ARM ein RISC. Ich denke es ist nicht 
trivial das effizient hinzubekommen, an ASM führt wohl kein Weg vorbei.

: Bearbeitet durch User
von Mr. Big (Gast)


Lesenswert?

Safari schrieb:
> Xperte schrieb:
>> Er konnte zwar intern mit 32Bit-Zahlen rechnen, hatte aber nur einen
>> 16-Bit Datenbus. Er war also ein 16bitter.
>
> Was für eine Quatsch-Definition.
>
> Es ist eine 32bit CPU, die nach aussen nur einen 16bit Datenbus hat. Nur
> weil jeder Zugriff auf zwei aufgeteilt werden muss, wird da keine 16bit
> CPU draus.


Unsinn. Der 68000er hat ein 16-Bit ALU, daher ist es ein 16-Bitter.
Hat auch Motorola nie anders behauptet.
Allenfalls kann man ihn als 16/32-Bit Hybriden bezeichnen. Er ist aber 
definitiv kein 32-Bitter.

von soso... (Gast)


Lesenswert?

Markus M. schrieb:
> Es gibt im Amiga mehrere "Custom Chips" die dafür emuliert werden
> müssen.

Mag ja sein, im Fall von Elite ist das jedoch völlig irrelevant.

Das Spiel ist 34 Jahre alt. Es ist 1984 zuerst erschienen. Elite ist auf 
vielen Plattformen erschienen, dem C64, dem PC, dem Amiga, und vielen 
anderen. Ich dachte, das wäre allgemein bekannt.

Siehe auch:
https://de.wikipedia.org/wiki/Elite_(Computerspiel)

Da es eine C-64-Emulation auf dem STM32 gibt:
https://hackaday.com/2014/10/23/a-complete-c64-system-emulated-on-an-stm32/

Würde ich zunächst versuchen, die C64-Version auf dem (schon 
existierenden) Emulator zu starten ;-)

Im Übrigen:
NATÜRLICH ist die Rechenleistung eines STM32 weit jenseits der einem 
Amiga. Chips hin, Chips her. Er ist fast 30 Jahre jünger, seit dieser 
Zeit hat sich die Performance um mindestens 3 Größenordnungen 
verbessert. Da ist es doch keine Kunst, die Rechneleistung zu toppen.
Der Amiga 500 war zu seiner Zeit wirklich revolutionnär. Aber gegen 
zeitgenössischer Hardware sieht das kein Land. Ist doch völlig normal.

von Xperte (Gast)


Lesenswert?

Safari schrieb:
> Es ist eine 32bit CPU

Nö. Erst der 68020 war eine 32bit  CPU. Und hatte dann auch einen 32bit 
Datenbus.

von Arc N. (arc)


Lesenswert?

Xperte schrieb:
> Safari schrieb:
>> Es ist eine 32bit CPU
>
> Nö. Erst der 68020 war eine 32bit  CPU. Und hatte dann auch einen 32bit
> Datenbus.

68k = Registerbreite 32-Bit und - bis auf ein paar Ausnahmen 1) - auch 
alle arithmetischen und logischen Operationen auf 32-Bit Operanden. Wie 
die Daten in die CPU rein oder raus kommen ist egal, ebenso ob bspw. 
eine Addition in einem Schritt oder mehreren durchgeführt wird 
(abgesehen davon, dass es u.U. langsamer ist).

1) muls und mulu 16x16=32, ab 020 32x32=32 und 32x32=64
divs und divu 32/16=16q+16r (16-Bit Quotient und 16-Bit Rest), ab 020 
auch 32/32=32q, 32/32=32q+32r, 64/32=32q+32r

von S. R. (svenska)


Lesenswert?

Mr. Big schrieb:
> Unsinn. Der 68000er hat ein 16-Bit ALU, daher ist es ein 16-Bitter.

Dann wäre der Z80 ein 4 bit-Prozessor. Ist er aber nicht.
Folglich ist deine Definition nicht so ganz sinnig.

von Bülent C. (mirki)


Lesenswert?

Entspannt euch mal... Der 68000'er war ein 16/32 Bit'ter. Erst später, 
mit dem 68020,68030,68040, wurde der Amiga 500 zum echten 32 Bit'ter.

Ab 68020 hatte diese Prozessoren Komponenten was viele andere CPU's erst 
viel viel später hatten... Ich denke da z.b. an den barell shifter

Also, ich würde den STM32F4 nicht unbedingt im dreistelligen 
Faktorbereich schneller als den 68040 im Amiga 4000 sehen..eher im 
unteren zwei stelligem Faktor.

Also redet nicht den 68000'er schlecht, auf dem habe ich noch gelernt.

von Markus M. (adrock)


Lesenswert?

soso... schrieb:
> Mag ja sein, im Fall von Elite ist das jedoch völlig irrelevant.

Achso, das weisst Du genau woher?

> Das Spiel ist 34 Jahre alt. Es ist 1984 zuerst erschienen. Elite ist auf
> vielen Plattformen erschienen, dem C64, dem PC, dem Amiga, und vielen
> anderen. Ich dachte, das wäre allgemein bekannt.

Ja, ich hab's damals sogar auf dem C64 gespielt. Verdammter 
Docking-Autopilot :)

> Da es eine C-64-Emulation auf dem STM32 gibt:
> https://hackaday.com/2014/10/23/a-complete-c64-system-emulated-on-an-stm32/
>
> Würde ich zunächst versuchen, die C64-Version auf dem (schon
> existierenden) Emulator zu starten ;-)

Eine C64 Emulation dürfte - bis auf den SID - wesentlich einfacher sein. 
(Und Elite hatte wimre nicht wirklich viel Sound).

Aber es ging ja um den Amiga, und die Emulation eines solchen, inklusive 
der CC, dürfte nunmal relativ aufwändig sein. Die Programmierung der 
Custom-Chips gehörte damals - auch bei einfachen Spielen - zu den 
Grundlagen. Jedes Programm (selbst die grafische "Workbench") hat diese 
verwendet - meistens (im Gegensatz zu Spielen) allerdings indirekt über 
die Bibliotheken.

Erzähl mir nix vom Amiga / 68k, habe auf den Dingern 10 Jahre lang 
programmiert :)

: Bearbeitet durch User
von S. R. (svenska)


Lesenswert?

Markus M. schrieb:
> Aber es ging ja um den Amiga, und die Emulation eines solchen, inklusive
> der CC, dürfte nunmal relativ aufwändig sein.

Es ging um Elite auf dem STM32. Dazu gehört nicht unbedingt die 
vollständige Emulation eines kompletten Amiga, nur weil es das Spiel 
auch für diese Plattform gab...

von Bernd K. (prof7bit)


Lesenswert?

Markus M. schrieb:
> Aber es ging ja um den Amiga, und die Emulation eines solchen,

Nein, wenn ich die Titelzeile dieses Threads und den Inhalt des ersten 
Postings richtig interpretiere ging es nicht um Amiga oder irgendeine 
andere Plattform sondern um Elite.

von Markus F. (mfro)


Lesenswert?

Bernd K. schrieb:
> sondern um Elite

... auch nicht wirklich. Er fragt nur "ist es möglich?", mehr nicht 
(insbesondere hat er nicht gesagt, dass er das angehen will - zumindest 
habe ich das nirgendwo gefunden).

Elite ist deutlich mehr als der eine Gouraud-schattierte, rotierende 
12-Flächner den's da zu sehen gibt.

Oolite (ein freier, OpenGL-basierter Elite-Klon, der übrigens ganz 
passabel funktioniert) hat z.B. mehr als eine halbe Million Code-Zeilen. 
Auch wenn ein wesentlicher Anteil davon sicherlich auf die (gegenüber 
dem Original deutlich verbesserte) Grafik zurückzuführen sein dürfte, 
ist das nicht mal eben an einem Nachmittag gemacht.

von soso... (Gast)


Lesenswert?

Markus M. schrieb:
> soso... schrieb:
>> Mag ja sein, im Fall von Elite ist das jedoch völlig irrelevant.
>
> Achso, das weisst Du genau woher?

Weil Elite vor lange vor dem Amiga 500 erschienenn ist (Elite : 1984 <> 
Amiga 500 : 1987).
Weil man 1984 nicht nichtexistente Hardware von 1987 emuliert hat.
Weil Elite auf zig Plattormen erschienen ist.

Daher. Es gibt noch mehr Argumente ;-)

von Johnny B. (johnnyb)


Lesenswert?

Josef schrieb:
> was haltet ihr davon? Glaubt ihr das er das hinbekommt?
> LINK: http://mikrocontroller.bplaced.net/wordpress/

Ja klar ist das machbar.
Sieh Dir mal die Demos an, welche auf dem Acorn RiscPC liefen im Jahr 
1997, z.B. dieses hier:
https://www.youtube.com/watch?v=NR2Xw38Sp-c
Ich glaube das Demo lief gut auf einer ARM610 CPU, die mit 30MHz 
getaktet wurde und der RiscPC hatte nicht mal einen Grafikbeschleuniger.
Also sollte Elite auf einem STM32F7 auch machbar sein.

von Markus M. (adrock)


Lesenswert?

Ihr habt recht - es ging tatsächlich NUR um Elite - nicht um Elite auf 
dem Amiga xxx, hatte ich irgendwie falsch gelesen.

Somit stimmt es natürlich, das sollte man in der Tat gut umsetzen 
können. Man könnte wahrscheinlich sogar den z.B. 6502 Code nach ARM 
umsetzen (lassen), also nicht emulieren, und muss dann nur noch die 
Stellen anpassen, wo die Grafik ausgegeben wird.

Soweit ich mich erinnere war Elite auf dem C64 ja nur s/w Grafik.

von Bernd K. (prof7bit)


Lesenswert?

Markus M. schrieb:
> Soweit ich mich erinnere war Elite auf dem C64 ja nur s/w Grafik.

Die Polygone waren nicht gefüllt, das hat das Zeichnen schonmal sehr 
beschleunigt, das einzige das gefüllt war war das Zentralgestirn eines 
jeden Systems und das war meist immer weit weg und klein (es sei denn 
man hat ne Fuel-Scooping Tour gemacht, dann wars groß und ruckelig). Und 
noch wichtiger: Die Schiffe hatten alle eine konvexe Form so daß jedes 
Polygon immer entweder komplett sichtbar war oder gar nicht, so musste 
man immer nur das Vorzeichen der Z-Komponente des Normalenvektors 
betrachten (bzw testen ob es linksrum oder rechtsrum war) um zu 
entscheiden ob ein Polygon gezeichnet werden muss oder nicht -> 
Hidden-Line Problematik quasi zum Nulltarif umschifft.

: Bearbeitet durch User
von 6a66 (Gast)


Lesenswert?

Markus M. schrieb:
> C64 ja nur s/w Grafik.

Neee, die war farbig :)

rgds

von Bernd K. (prof7bit)


Lesenswert?

6a66 schrieb:
> Markus M. schrieb:
>> C64 ja nur s/w Grafik.
>
> Neee, die war farbig :)
>
> rgds

Ja, die Schrift, Instrumente und HUD waren farbig. Die ganze 3d-Grafik 
war weiße Linien auf schwarzem Grund.

von C. A. Rotwang (Gast)


Lesenswert?

Markus M. schrieb:
> Es gibt im Amiga mehrere "Custom Chips" die dafür emuliert werden
> müssen.
>
> Zum einen der Copper, welcher einfach gesagt an bestimmten Rasterzeilen
> während des Bildschirmaufbaus bestimmte Aktionen ausführen kann (nämlich
> die anderen Custom Chips steuern), zum anderen der Blitter, welcher
> schnell Flächen füllen und Linien zeichnen kann.

Alles kein Hexenwerk, die Beschleunigerhardware ist im wesentlichen 
nichts weiter als ein paar DMA-counter und ein bisser bitmap XOR/OR.

> Außerdem ist der 68k ein CISC, der ARM ein RISC. Ich denke es ist nicht
> trivial das effizient hinzubekommen, an ASM führt wohl kein Weg vorbei.

Naja CISC macht die Sache eher einfach als schwierig, weil CISC bedeutet 
das ein Befehl über mehrere Takte gestreckt wird. Selbst für ein NOP 
braucht der 68k 4 Takte, für ein simples OR können es je nach Operanden 
auch 20 Takte sein.
Und das nur wenn die CPU mal an den Speicher darf, weil der der CPU 
öfters für die Extrachips entrissen wurde:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node02D4.html

Und viele Commodore "Spezialchips" wie der CIA, lassen sich reltiv 
leicht durch die ARM -Peripherals Timer, UART etc. ersetzen.

Das Geniale am Amiga war eher die UMA-Architektur, also der vereinfachte 
Zugriff auf den zentralen Speicher ohne über extra AddOns wie 
Grafikkarten gehen zu müssen. Das erspart auch der CPU unnötoges 
Datenschaufeln (Blockcopies). Deshalb könnte ein 7.* MHz Amiga mit 512K 
einen 386 mit 40 MHz und extra Grafikkarte ausstechen, Bei Auflösungen 
von 320×256 mit 32 Farben ...
https://youtu.be/rsuWgLEQBxM?t=211

Da mal eine Entwicklung der Elite-Grafik über die Jahre:
https://www.youtube.com/watch?v=iKUaxSBe6oc

von Markus F. (mfro)


Lesenswert?

Amiga emuliert auf ARM gibt's doch längst: 
https://github.com/Chips-fr/uae4arm-rpi

von Thomas F. (igel)


Lesenswert?

Bernd K. schrieb:
> Und
> noch wichtiger: Die Schiffe hatten alle eine konvexe Form so daß jedes
> Polygon immer entweder komplett sichtbar war oder gar nicht, so musste
> man immer nur das Vorzeichen der Z-Komponente des Normalenvektors
> betrachten (bzw testen ob es linksrum oder rechtsrum war) um zu
> entscheiden ob ein Polygon gezeichnet werden muss oder nicht

Klingt interessant, leider hab ich das mit dem Normalenvektor auf Anhieb 
nicht ganz verstanden. Kann man das irgendwo nachlesen?

von M. K. (sylaina)


Lesenswert?

Thomas F. schrieb:
> Klingt interessant, leider hab ich das mit dem Normalenvektor auf Anhieb
> nicht ganz verstanden. Kann man das irgendwo nachlesen?

Was genau hast du nicht verstanden? Du weißt, was ein Normalenvektor 
ist?

Ein Normalenvektor ist ein Vektor, der orhtogonal auf einer Graden/Bogen 
bzw. Fläche oder Körper steht.

Ein Polygon, dass von einem anderen Polygon verdeckt wird, muss nicht 
gezeichnet werden. Und wenn man die Normalenvektoren bestimmt kann man 
bestimmen wer wen potentiell verdeckt.
Hier ist was interessantes dazu (habs grad nur überflogen)

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiH0KeOvM3bAhWrHpoKHVSZDTkQFggrMAE&url=https%3A%2F%2Fwww.inf.tu-dresden.de%2Fcontent%2Finstitutes%2Fsmt%2Fcg%2Fteaching%2Flectures%2FCG2WS0203%2Fsecure%2Fsichtbar_script.pdf&usg=AOvVaw1CGyl7IxPr8mz1XHOE6XSm

von Thomas F. (igel)


Lesenswert?

M. K. schrieb:
> Thomas F. schrieb:
>> Klingt interessant, leider hab ich das mit dem Normalenvektor auf Anhieb
>> nicht ganz verstanden. Kann man das irgendwo nachlesen?
>
> Du weißt, was ein Normalenvektor ist?
Das ist klar.

> Ein Polygon, dass von einem anderen Polygon verdeckt wird, muss nicht
> gezeichnet werden. Und wenn man die Normalenvektoren bestimmt kann man
> bestimmen wer wen potentiell verdeckt.

Das war meine Frage: Wie läuft diese Prüfung - verdeckt oder nicht - ab?
Kennt jemand spontan einen Pseudocode-Algorithmus?

Gerade gefunden:
https://de.wikipedia.org/wiki/Culling#Backface_Culling

Deinen Link werde ich jetzt erst mal durchlesen...

von Markus F. (mfro)


Lesenswert?

Thomas F. schrieb:
> Das war meine Frage: Wie läuft diese Prüfung - verdeckt oder nicht - ab?
> Kennt jemand spontan einen Pseudocode-Algorithmus?

Eigentlich simpel. Wenn der Normalenvektor einer Fläche eine 
Z-Komponente hat, die auf die Kamera zeigt (also nicht davon weg), 
siehst Du die Vorderseite, ansonsten nur die Rückseite.
Wenn Du nur konvexe "Volumen-" Objekte hast, wird die Rückseite immer 
von einer anderen Fläche verdeckt, ist also unsichtbar.

Bei konkaven Objekten kann eine "hintere" Fläche ganz oder teilweise von 
einer "vorderen" verdeckt werden. Dann muss man die "hintere" Fläche mit 
der vorderen "verschneiden", um den evt. sichtbaren Teil zu ermitteln. 
Und das ist ein erheblicher Zusatzaufwand.

: Bearbeitet durch User
von Thomas F. (igel)


Lesenswert?

Markus F. schrieb:
> Eigentlich simpel. Wenn der Normalenvektor einer Fläche eine
> Z-Komponente hat, die auf die Kamera zeigt (also nicht davon weg),
> siehst Du die Vorderseite, ansonsten nur die Rückseite.

Die Normalenvektoren der einzelnen Flächenelemente des Volumenkörpers 
müssen so definiert sein dass diese 'nach außen' zeigen, nicht nach 
innen, oder?

> Wenn Du nur konvexe "Volumen-" Objekte hast, wird die Rückseite immer
> von einer anderen Fläche verdeckt, ist also unsichtbar.

Soweit klar.

von Markus F. (mfro)


Lesenswert?

Thomas F. schrieb:
> Die Normalenvektoren der einzelnen Flächenelemente des Volumenkörpers
> müssen so definiert sein dass diese 'nach außen' zeigen, nicht nach
> innen, oder?

Ja. Die Eckpunkte der Deckflächen werden dazu entweder im oder gegen den 
Uhrzeigersinn angelegt/sortiert. "Rechtsrum" (oder entsprechend 
"linksrum") bedeutet dann per Konvention "aussen" oder "innen".

Wenn man das sicherstellt, braucht man ab da nicht mehr mitzudenken 
(bzw. unterschiedliche Fälle zu berücksichtigen), die Berechnung der 
Normalenvektoren stimmt "automatisch" immer.

von Thomas F. (igel)


Lesenswert?

Danke, jetzt habe ich einiges zum Nachdenken.
Da dauert es wohl noch ein wenig bis ich das auf einem Atmega umgesetzt 
haben...

von The Man (Gast)


Lesenswert?


Bitte 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
Noch kein Account? Hier anmelden.