CP/M-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Memberlist || Home || Statistik || Kalender || Staff Willkommen Gast!
[ Unofficial CP/M Website ] [ Z80 Family Support Page ] [ Forum-Regeln ] [ Impressum/Kontakt ]

CP/M-Forum » Computer » ELO Moppel 8085 » Threadansicht

Autor Thread - Seiten: [ 1 ] -2-
025
22.03.2015, 18:07 Uhr
Hein_Ko

Avatar von Hein_Ko

Die Laufwerke habe ich folgendermaßen eingeteilt:

A: virtuelle SRAM-Disk mit 1 MB
B: CF0 Boot-Laufwerk mit 32 MB
C: CF1 second drive mit 16 MB

Siehe: http://www.kolter.de/SEPIA-DRIVES.JPG

Grüße, Heinrich
--
Es gibt keine Probleme - nur Lösungen !
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
026
22.03.2015, 20:55 Uhr
Werner_8085



Hallo Heinrich,

ein kleines Stückchen weiter - der Versatz auf der CF-Karte ist jetzt beseitigt.
IM AVR-Teil habe ich die angelieferten Sektornummern neu berechnet:
Spuren * 16 + aktueller Sektor = Summe Sektoren
Summe Sektoren / 2 + (Summe Sektoren mod 2) + Offset = CF-Sektoren

[Im DPB ist derzeit das Moppelformat eingetragen und Offset ist der CP/M Datenbereich auf der CF_Karte - muss natürlich noch geändert werden]

Musste erstmal durch das Blocking/Deblocking durchsteigen. Im Bios müssen ja die CP/M Records auf den 1kByte Buffer abgebildet und nochmals für das Moppelformat heruntergebrochen werden - jetzt ist der Zusammenhang etwas klarer.

Leider funktionieren die kopierten Programme von der CF-Karte noch nicht.
Ein Dateivergleich mit der CF-Karte hat noch nichts konkretes ergeben ...

LG Werner
PS: Welche CP/M version läuft auf deinem Sepia, denn nach meinen
bescheidenen Kenntnissen ist doch bei 8MB Schluß.
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
027
22.03.2015, 21:45 Uhr
Hein_Ko

Avatar von Hein_Ko

Hallo Werner

Ich nenne es Advanced CP/M 2.2 , da es ein wenig "aufgebohrt" wurde

Die Quellen stammen aus verschiedenen Versionen und Projekten, die
jetzt auf einem DOS-Rechner + Z80-MacroAssembler übersetzt werden.
Siehe: http://www.tni.nl/products/tniasm.html

Dabei haben mir
Michael, Alfred, Wolfram, Volker, Mario, Ralf, Werner, Tilmann und Peter
sehr geholfen. (ich hoffe, das ich keinen vergessen habe)

Das BIOS musst Du dennoch selbst schreiben und an den Moppel anpassen.
Den kenne ich jedoch leider nicht. Entscheidend ist hierbei die CF-Hardware.
Bei mir habe ich noch einen 16-Bit DataBuffer eingefügt und eine Menge an
IDE-Prüfroutinen eingebaut, welche die Medien prüft und "nachschaut",
ob die Hardware present und i.o. ist... (nach Art von plug-and-play).

Grüße, Heinrich
--
Es gibt keine Probleme - nur Lösungen !

Dieser Post wurde am 22.03.2015 um 21:46 Uhr von Hein_Ko editiert.
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
028
23.03.2015, 22:25 Uhr
Werner_8085



Hallo Heinrich,

aha, daher ;-) - ist dann ehr was für ein zukünftiges Projekt, da der Moppel
einen 8085er CPU hat, hab zwar ein NSC800 dafür - funktioniert sogar -
aber erstmal dieses Projekt abschließen ...

Habe einige Dateien auf der CF-Karte mit den orginalen verglichen - alles OK.
Nur starten lassen sie sich davon leider nicht -
Computer hängt dann irgenwo rum ;-((

Ich vermute einen Ladefehler vom Buffer 1kB zum TPA-Bereich.

Kann ich den DDT dazu überreden eine Datei von einem anderen Laufwerk zu lesen ? Im Handbuch steht da nichts und meine Versuche waren leider vergebens.

Erläuterung zum Speicherabbild:
Da der Moppel kein reiner CP/M Computer ist, sind die Speicherbereich etwas eigensinnig angelegt:
Bank #0
0000h - 27FFh ROM ; Monitorprogramme
2800h - 3FFFh RAM ; User und Video-RAM
4000h - 7FFFh ROM ; Assembler, Editor, Basic
8000h - FFFFh RAM ; User RAM, Buffer, etc.

Bank #1
0000h - 3FFFh wie oben
4000h - FFFFh RAM, hier lädt das Bootprogramm CP/M im oberen Bereich

Das BIOS schaltet dann den unteren Bereich als RAM frei
Tastatur, Video-Routinen werden über die Bankumschaltung aus dem ROM
Bereich 0000h - 3FFFh genutzt.

Eine Möglichkeit wäre, ein Kopierprogramm am oberen Ende der Bank #1
was die Daten häpchenweise ins User-RAM ab 2800h Bank #0 läd
und als nächstes dann in den größeren RAM-Bereich ab 8000h transportiert.
Sehr umständlich, gibt es eine andere schlaue Möglichkeit sich den TPA-Bereich zu listen ???

LG Werner
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
029
24.03.2015, 21:46 Uhr
Hein_Ko

Avatar von Hein_Ko

Hi Werner

Idealerweise benötigt man für CP/M 64kB freies RAM.
Wenn Dein RAM beim Laden von den Systemspuren noch
anderseitig benutzt wird, kann das zu Datenkollisionen führen.

Bei SEPIA schalte ich das IPL-EPROM transparent, sobald das BS in
den obenen RAM-Teil (ab D400h) mit "LDIR" geladen wurde und ein "Jp" zum
Startvector (im BIOS-Teil) erfolgt ist. Danach ist alles nur noch im RAM.
Die Freischaltung erfolgt mit einem OUT-Befehl, der dann im CPLD die
/CS-Leitungen von EPROM auf SRAM umschaltet. Danach kommt erst
die JP-Tabelle und GOCPM -> zum CCP.

Wenn bei Dir noch Monitore u.a. Routinen das RAM blockieren, werden
die Programme (typische Startadresse 0100) nicht funktionieren.
Die Video-Routinen musst Du auch ins BIOS verlegen, oder einen
Schattenspeicher anlegen.

LG Heinrich
--
Es gibt keine Probleme - nur Lösungen !

Dieser Post wurde am 24.03.2015 um 22:00 Uhr von Hein_Ko editiert.
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
030
24.03.2015, 22:11 Uhr
Werner_8085



Hallo Heinrich,

also das orginal BIOS funktioniert einwandfrei.
Für die Consolen Ein-Ausgaben schaltet es zwischen den Bänken hin und her
da ja der Video-Speicher in der Bank #0 steht.

Mein Problem sind die nachgefrickelten CF-Routinen:
Überträgt genauso wie die Floppyroutinen immer 1kByte in den BIOS-Buffer
Der dann über Blocking/deblocking das in den DMA Buffer kopiert.
- Transport über den 1k Bios Buffer funktioniern fehlerfrei
- Dateien werden von Disk nach Cf und umgekehr einwandfrei übertragen.

soweit so gut

Wenn aber Dateien in die TPA geladen werden kommen diese dort nicht vollständig an ;-((
Habe ein Testprogramm eingebaut, was die TPA unter Monitorkontrolle
in den BIOS-Buffer zurückschaufelt um es sich dort anzusehen.

Es fehlt pro Block(1kByte) jeweils ein Byte, eigenartigerweise nicht an den
Grenzen zum Record oder CF-Sektor sondern im 4.Record beim 20.Byte -
schön regelmäßig ???

Ich schalte mal die Interrupts aus (werden bei den CF-Routinen nicht genutzt) - bin gespannt ...

LG Werner

Dieser Post wurde am 24.03.2015 um 22:13 Uhr von Werner_8085 editiert.
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
031
24.03.2015, 22:27 Uhr
Werner_8085



Nachtrag:

also die Interrups sin es nicht - schade.
Also werde ich meine TPA-Analyse noch etwas verbessern müssen, damit
ich die Daten vollständig wieder herauslesen kann - in 1k-Häpchen ist es ein bischen mühselig ...

LG Werner
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
032
24.03.2015, 22:50 Uhr
Hein_Ko

Avatar von Hein_Ko

hmmm...

Fummelt Dir da irgendetwas synchron dazwischen? Bildschirmausgaben?
Hinkt bei der Übertragung der AVR hinterher, oder umgekehrt der 8085?

Was passiert, wenn Du den 8085 anstatt mit 6 MHz mal mit 4 MHz
laufen lässt? Kommt der Fehler dann immer noch im 4.Record beim 20.Byte?

LG, Heinrich
--
Es gibt keine Probleme - nur Lösungen !

Dieser Post wurde am 24.03.2015 um 22:59 Uhr von Hein_Ko editiert.
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
033
26.03.2015, 12:38 Uhr
Werner_8085



Hallo Heinrich,

um ganz sicher zu sein, habe folgenden Test durchgeführt:
- Dateien
STAT.COM
ASM.COM
ED.COM

1.) von Floppy LW A nach CF-Karte kopiert
2.) von CF-Karte auf neue Diskette in LW B kopiert

3.) Vergleich der Orginaldaten aus LW A - mit CF-Karte
4.) Vergleich der Orginaldaten - mit der Kopie aus LW B
Damit sind dann alle Schreib/Lese-Routinen der CF-Karte abgedeckt.

Ergebnis: Dateien sind immer identisch

Somit gehe ich davon aus, dass die CF-Routinen OK sind.

Es kann eigendlich nur an der Kopierroutine zwischen 1kBuffer
und TPA liegen, die im CF-Betrieb irgendwo Zeichen schlabbert.
Waren in den vorhergenden Tests zwar nur ein Byte pro Buffer
, Programme tolerieren das aber nicht.
(Interrupts sind im CF-Betrieb bereits ausgeschaltet)

Das schaue ich mir nun genauer an ...

LG Werner
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
034
26.03.2015, 17:03 Uhr
Hein_Ko

Avatar von Hein_Ko

Hallo Werner

Ich habe bei meinem Z80-System 2 Waitstate bei den CF-Zugriffen
eingefügt. Kannst Du das bei Dir auch so (testweise) einrichten?

Wie zählst Du denn den Byte-Stapel im 1k Buffer runter?
Irgendwo beim BC/HL...-Register Push/Pop vergessen?

LG Heinrich
--
Es gibt keine Probleme - nur Lösungen !
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
035
26.03.2015, 17:55 Uhr
Werner_8085



Hallo Heinrich,

zu 1- waitstates sind im 8085 nicht vorgesehen,
dann müsste ich runter auf 4Mhz Quarz.

zu 2- möglich ist alles, aber dann müsste er viele Daten verwurschteln.
Der "Datenverlust" ist ja mit 1Byte pro 1kByte ja im Promillbereich

die Kopierroutine ist ganz schlicht:
(HL) Quelladresse
(DE) Zieladresse
(B)= 80h für 128Byte (Record)
Anmerkung: beim schreiben werdden nur die Register (HL), (DE) getauscht
sonnst alles gleich

copyx: mov a,m
stax d
inx h
inx d
dcr b
jnz copyx
ret

vor Aufruf wird noch die Blocking/Deblocking-Routine durchlaufen
um den Buffer auf Recordgröße abzubilden.

Die ganzen Routinen werden von Floppy und CF-Interface genutzt
somit schließe ich hier eigendlich Fehler aus. Meine Cf-Routinen
habe ich da angedockt, wo ursprünglich die Floppy-Routinen den Buffer füllen.
Es kann natürlich sein, das ein Rückgabeparameter von den CF-Routinen
nicht richtig zurückgegeben wird.
Da das Moppel-Bios nicht sonderlich gut dokumentiert ist, habe ich immer noch einige Fragezeichen "über meinen Kopf stehen" ;-))

Ich versuche mal ein Testprogramm, was die TPA (aus Bank #1) nach dem
Speicher ab 8000h in Bank #0 transportiert, damit ich das besser analysieren kann.

LG Werner
PS: kann man hier eigendlich Textdateien anhängen, denn Listings werden im
Textbereich schlecht dargestellt, keine TAB's
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
036
26.03.2015, 22:02 Uhr
Werner_8085



Zwischenstand

die Kopierroutinen sind fertig, im "Dreisprung" wird nun aus der TPA
Recordweise der Inhalt nach Bank #0 Adresse 8000h geschaufelt.

Das Bild wird aber nicht klarer

- Versuch mit STAT.COM sieht alles schön aus.
Jedes Byte an richtiger Stelle - Programm bricht aber mit "BDOS Error on A"
ab, obwohl es von LW (CF-Karte) gestartet wurde ?

- Versuch mit DDT.COM sieht nicht gut aus - bleibt in der Begrüßungszeile hängen
kein Wunder denn im 5.Record fehlt Byte 13 - 13 = Unglückszahl ;-)

Der Gegencheck mit DDT von Floppy ist wie erwartet einwandfrei.

Es geht kein Weg daran vorbei, das BIOS Listing muss ich nochmals ganz genau
unter der Lupe nehmen und versuchen es zu verstehen ...

zu kurz vorm Ziel kann ich ja nicht aufgeben ;-)

LG Werner
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
037
27.03.2015, 23:11 Uhr
Hein_Ko

Avatar von Hein_Ko

Hallo Werner

Wie ist denn die CF-Schnittstelle (Hardware) an den Rechner gekoppelt?
Kannst Du in etwa abschätzen, wie schnell die Transferzeiten sind?

"zu kurz vorm Ziel kann ich ja nicht aufgeben ;-)"
...aber auf gar keinen Fall !

LG Heinrich
--
Es gibt keine Probleme - nur Lösungen !

Dieser Post wurde am 27.03.2015 um 23:11 Uhr von Hein_Ko editiert.
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
038
28.03.2015, 00:27 Uhr
Werner_8085



Hallo Heinrich,

auf CP/M Seite ist es ein 8255 paralelle Schnittstelle im Modus 2
also bidirektional mit Handshake. Die Datenrate beträgt ca. 20-25kByte/sek.
Der AVR langweilt sich zu tode ;-))

Versuch gerade den BIOS-Quellcode zu verstehen.
Da STACK-Fehler komische Efekte hervorrufen können habe ich mir das mal
genauer angesehen, in den Floppy-Routinen wird ein eigener STACK eingerichtet
um den BDOS-STACK zu entlasten. Meine CF Routinen belasten den STACK nur
mit CALL und RET, da alle Übergabewerte in Speicher und nicht über den STACK laufen, ggf. werde ich das nachrüsten ...

Anmerkung:
Aufgeben geht sowie so nicht, dies ist hier ja nur der erste Schritt.
Wenn das hier funktioniert, muss der AVR richtig ran. Denn er soll
ja das CP/M-Dateisystem ja noch ins FAT gespiegelt werden um
den Datentransport zwischen den Welten zu ermöglichen ...

LG Werner
http://werners-seiten.de/

Dieser Post wurde am 28.03.2015 um 00:28 Uhr von Werner_8085 editiert.
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
039
29.03.2015, 14:59 Uhr
Werner_8085



Hallo Heinrich,

unter:
http://www.mikrocontroller.net/topic/63505

habe ich mal die Analyse von STAT.COM hinterlegt.

Bei allen drei Versuchen fehlen die 4bytes immer an der gleichen Stell
in der TPA, auf der CF-Karte sind sie alle vorhanden und beim Weiterkopieren
auf Diskette kommt alles richtig an und funktioniert auch von da.

Da das immer innerhalb eines Records ist und die Kopierroutine so einfach,
finde ich das schon komisch.
Speicherbausteine schon gewechselt, natürlich kein Erfolg und mit Floppy
klappt ja auch alles gr....

LG Werner
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
040
01.04.2015, 21:02 Uhr
Hein_Ko

Avatar von Hein_Ko

Hallo Werner

Es wäre doch mal interessant, ob ein langsamerer CPU-Takt eine
Veränderung bewirkt.

Bei der Zähl-Routine würde ich nochmal genau nachrechnen, ob die Blöcke
passen. Vielleicht ist es ja noch ein Überlauffehler oder Flag-Problem?

LG, Heinrich
--
Es gibt keine Probleme - nur Lösungen !
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
041
02.04.2015, 10:46 Uhr
Werner_8085



Hallo Heinrich,

Ist ja ein langes Wochenende mit sehr schlechtem Wetter angesagt,
die Zeit werde ich nutzen und den Quarz umlöten.

Derzeit schreibe ich eine Test-Routine, die den Buffer bei jedem Lesezugriff
in Bank #0 sichert. Damit werde ich ja sehen ob da schon der Fehler vorliegt
oder erst bei der Kopierroutine die Recordweise die Daten in dem DMA-Buffer
schaufelt.

Die BIOS-Analyse zeigt, dass die Floppyzugriffe in "Aufgaben" struktruiert ist.
# Diskmanager:
- SEL-DRIVE, SET-TRACK, SET-SECTOR
- Blocking/Deblocking
- Umrechnung der Records auf Moppelsektoren
- Abbildung der Records auf den 1k Buffer
- Bufferüberwachung

# Get/Put Track:
- liest/schreibt den 1k Buffer
- ! hier habe ich auch die CF-Routinen eingebunden
- über Prüfung der LW-Nr. bei drei geht es dann zur CF-Karte

Die Parameterübergabe Drive, Track, Sektor erfolgt über Speicherstellen.

# Floppy-Routinen
- FDC-einstellen
- und jeweils vier Sektoren lesen/schrieben

hier wird für das lesen ein eigener Stack eingerichtet und die Routinen
nutzen den Interrupt



LG Werner
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
042
06.04.2015, 19:37 Uhr
Werner_8085



Hallo Heinrich,

ich habe da ein "Ei" gefunden - ist ja auch Ostern ;-))

Der Lesefehler passiert schon im 1kBuffer, dort fehlen bereits die vier Bytes
von STAT.COM (auf der CF-Karte stehen sie an richtiger Stelle).
Habe das weiterkopieren nochmals getestet und nun taucht auf der Zieldiskette
der Fehler auch auf. (Warum das bei den vorherigen Versuchen geklappt hat kann
ich nicht nachvollziehen).

Jetzt ist es eindeutig - die CF-Leseroutine schluckt die bytes !

Der versuchsweise eingebaute 4Mhz Quarz brachte kein Erfolg.

Dann werde ich mich nun auf die Schnittstelle ECB-AVR konzentrieren ...

LG Werner
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
043
08.04.2015, 13:39 Uhr
Werner_8085



Hallo Heinrich,

Fehler ist gefunden !!
Die 4MB-CF Karte macht die Probleme, wahrscheinlich
kommt sie mit den 12MHz AVR nicht ganz klar.

War ja eigendlich schon beim AVR-DOS das Problem mit den
kleinen alten Speicherkarte, erst eine 1GB-Karte funktioniert
mit dem AVR-DOS. Die kleinen klappen zwar augenscheinlich mit den
Grundroutinen Sektor Lesen/schreiben aber sind dann im Timing
wohl sehr kritisch ...

Im BIOS und auf der AVR-Seite habe ich noch ein paar kleine Verbesserungen
durchgeführt, Timing für das Strobesignal etwas verlängert uund Parameterübergabe berichtigt.

Jetzt mit der 1GB CF-Karte sieht alles schon recht gut aus,
kopierte Programme funktionieren nun.
Wenn dann der DPB angepasst ist gibt es erstmal einen Stresstest.

LG Werner
Die ollen Karten hätte ich besser entsorgen sollen, eine Woche Fehler gesucht, die keine sind ;-)
Macht aber nichts, eine Menge dabei gelernt und nebenbei
das BIOS-Listing besser dokumentiert.

Das mit den Timingproblemen werde ich mir nochmals zur Brust nehmen,
Deinen Ansatz mit den Wartezyklen könnte ich eigendlich mal im AVR testen.

Wie sehen Deine Erfahrungen mit den CF-Karten aus ?
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
044
09.04.2015, 23:59 Uhr
Werner_8085



Hallo Heinrich,

habe mich mit dem DPH und DPB vertraut gemacht,
Eine gute Quelle:
http://hc-ddr.hucki.net/wiki/doku.php/cpm:write_a_bios:teil_1

Das vorläufige Ergebnis:
;
; CF-Karte derzeit experimentel
;
; 32 Sektoren a 128Byte
; 2kBlöcke
; 256 Dir Einträge
; ohne Check
; keine Systemspuren
;
dpb3:
dw 32 ; Sectors per Track
db 4 ; Block shift
db 15 ; Block Mask
db 0 ; Extnt Mask
dw 1023 ; Disk Size-1
dw 255 ; Directory max.
db 11110000b ; Alloc0
db 0 ; Alloc1
dw 0 ; Check Size
dw 0 ; Offset
;
xlt3: equ xlt0

das funktioniert bereits einwandfrei und in der Disk Size
ist ja noch eine menge Luft.

Wollte den Eintrag Sectors/Track raufsetzen,
da macht mir aber das BIOS einen Strich durch die Rechnung ;-(
Denn diese Umrechnung schiebt die Sektor-Nr nach rechts und addiert
eine eins hinzu um die Recordgröße an den physikalische Sektorgröße
anzupassen 256B/sektor, die verechnet sich aber ab 32.

Entweder muss diese überarbeitet werden oder ich belasse es dabei,
dann gibt es halt mehr "Spuren" auf der CF-Karte.

In jedem Fall ist nun die größte Hürde geschafft...
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
045
10.04.2015, 18:17 Uhr
Hein_Ko

Avatar von Hein_Ko

Hallo Werner

Gratuliere !! Hartnäckigkeit zahlt sich am Schluss meißtens aus.

Es konnte nur ein "Stack/Zähl-Problem" oder ein Timing-Fehler sein.
Das der Fehler auf der AVR-Seite im Zusammenhang mit der CF-Karte
liegt, hatte ich zunächst ausgeschlossen, da diese Schaltung ja erprobt war.

Bei meinem System takte ich den Z80 mit 20 MHz und erreiche damit
ca. 4 MB/s. Da das für manche IDE-Geräte auch noch zu schnell scheint,
habe ich im Treiber viele Abfragen und Sicherheitsroutinen mit variablen
Delay beim Datentransfer eingebaut. Damit passt es sich dem IDE-Device
quasi automatisch (optimal) an. ...war ca. 1 Jahr Arbeit...

Schön, das Dein Moppel nun mit CF moppelt

LG, Heinrich
--
Es gibt keine Probleme - nur Lösungen !
Seitenanfang Seitenende
Profil || Private Message || Suche Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] -2-     [ Computer ]  



gaby.de

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek