Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » Turbo Loader für PC-> KC überspielen. » Themenansicht

Autor Thread - Seiten: -1-
000
21.11.2016, 06:44 Uhr
Hobi



Am Wochenende hatte ich mich wieder mit Kodierungen für den Audioeingang auseinandergesetzt. Da neuerdings die Aufzeichnungsgeräte nicht mehr magnetisch sind, sollte sich doch da was verbessern lassen.

Die Idee dahinter war
a) eine schnellere Abspielmöglichkeit für Micha's KC85 Recorder zu finden
b) die Programme vom SDCC Compiler ohne langes Warten direkt auf der Zielmaschine auszuführen (ohne zusätzliche Hardware wie z.B. ein V24 Modul)

und sollte es gut funktionieren
c) kann man es einfach aufs Handy portieren und hat so ein mobiles Datenabspielgerät.

Der erste Ansatz war die Grenzen des Originalverfahrens auszutesten. Man kann das Sample 10-20% schneller abspielen und zusätzlich die Pausen verkleinern. Im besten Fall gibt es 40% Verbesserung, ohne dass man etwas an der Software drehen muss. Auf der anderen Seite ist das auch nicht wahnsinnig schneller. Statt 100 Bytes pro Sekunde, käme man im besten Fall auf 140 Bytes pro Sekunde. Oder anders gesagt: 6,3 KByte brauchen 45 Sekunden, statt 58.

Der zweite Ansatz war die NRZ Kodierung bei der eine 1 als Phasenwechsel und bei 0 eben kein Phasenwechsel verwendet wird. Hier kommt man bei 2400 Hz auf 4800 Bits pro Sekunde. Die UART oder USB verwenden wahrscheinlich diese Art der Übertragung.
Blöderweise geht es am KC so einfach nicht. Hier war konnte schon zwischen 3 oder 4 Nullbits nicht mehr klar unterschieden werden. Irgendwer auf dem Kabel oder dahinter verschiebt den Nulldurchgang etwas. Die Daten sollten möglichst Gleichspannungsfrei ankommen.

Nach längeren Rumprobieren habe ich dann die kürzeste NRZ Kodierung gewählt ( 1 als Phasenwechsel, 0 eben kein Phasenwechsel gefolgt von einer 1). Diese Kodierung ist in etwa gleich als würde man ein Halbwelle für ein 1 Bit verwenden und für die 0 eine Halbwelle mit halber Frequenz - 1 steht für Kurz, 0 lang. Damit kommt man im Mittel auf 3600 Bits pro Sekunde.

Im wesentlichen ist es dann das gleiche Verfahren wie beim KC geblieben, nur dass der eine komplette Welle verwendet und beide Nulldurchgänge aufaddiert. Mit der Methode konnte man etwas den Gleichspannungsanteil herausmitteln.
Im Idealfall gibt es bei uns keinen Gleichspannungsanteil, also reicht mir ersteinmal eine halbe Welle pro Bit. Eine bessere Kodierung habe ich noch nicht gefunden.

Die Frequenz ist momentan noch bei 2400 Hz. Damit bekommen wir maximal 4800 1 Bits pro sekunde oder 2400 Nullbits. Im Mittel habe ich eine Datanrate von 380 Bytes pro Sekunde. 6,3 KByte brauchen jetzt nur noch 17,3 Sekunden.

Das ist schon mal ein guter Start, verglichen mit dem Original und der Tatsache, dass ich die gleiche Maximalfrequenz verwende. Ohne grosse Änderungen konnte ich die Frequenz auf über 3kHz erhöhen. Dann aber fingen die Probleme schon wieder an, zu unterscheiden, ob die Welle eine 1 oder 0 ist. Auch wenn die Daten im PC perfekt aussehen, irgendwer verschiebt den Nullpunkt und so kommen nicht so an, wie beabsichtigt. Vielleicht liegt es an meinem PC oder Kabel.

Die Frequenz will später noch erhöhen für den Moment experimentiere ich mit 2400Hz und möchte ersteinmal den Loader fertigstellen. Später könnte man noch eine simple Komprimierung verwenden und so die Datenrate noch etwa erhöhen, falls es die Gesamtgeschwindigkeit verbessert. Wenn es langsamer als vorher wird, macht es keinen Sinn.
--
-------------------------------------------
Corontäne
-------------------------------------------
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
21.11.2016, 14:28 Uhr
Heiko_P



Nur als Anregung: Schau dir mal das Turbo-Aufzeichnungsverfahren vom AC1 und LLC2 an, eine kurze Beschreibung dazu findest du auf www.ac1-info.de unter AC1-SCCH -> Kassettenaufzeichnungsverfahren. Das ist deutlich schneller als das Verfahren vom KC85, lief mit der damals verfügbaren Technik sehr zuverlässig und lässt sich mit wenig Aufwand auf andere Rechner portieren. Vielleicht kannst du dort ansetzen und nach weiteren Optimierungen suchen.

Gruß
Heiko
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
21.11.2016, 14:52 Uhr
volkerp
Default Group and Edit
Avatar von volkerp

Tipp: das ist das vom Poly-Computer, später Z1013 und AC1 :-)

http://hc-ddr.hucki.net/wiki/doku.php/z1013:kassettenformate
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
21.11.2016, 18:18 Uhr
Mobby5



Es gibt eigentlich schon laaaaange einen Turbo-Loader für den KC. Glaube ZXLOAD und ZXSAVE oder so, wenn ich mich nicht irre. Zumindest für den 85/3, ob er aufwärtskompatibel ist, entzieht sich meiner Kenntnis.
--
und ausserdem muss in Zeile 20 der Doppelpunkt durch ein Semikolon ersetzt werden
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
22.11.2016, 06:52 Uhr
Hobi



Das es schon lange Turbo Lader gibt ist unbestrtitten. Die Idee hier ist ja, dass man kein Magnetband mehr braucht oder anders gesagt, da heutzutage selbst "normale" Audiohardware recht gut ist, liegt der limitierende Faktor einzig am KC interface.
Meine Gedanke war, wo dort die Grenze liegt.

Der AC1 verwendet 2 Halbwellen für ein 1-bit. Bei der digitalen Aufzeichnung braucht man nur eine halbe.

Das Hauptoroblem war die sichere Flankenerkennung. Ich habe versucht, das Signal so niedrigfrequent wie nur irgendmöglich zu gestalten. Das war ein Fehler. Langsame Anstiege mag anscheinend das Interface nicht. Ich habe viel Mathematik hineingesteckt, um die jeweils beste Kurvenform zu berechnen. Jeden x-beliebigen Anstellwinkel ausprobiert. Sinnlos.

Ein einfacher Low-Pass am Ausgang hat dann aber die Probleme gelöst. Wahrscheinlich hat das Micha's Box in HW genau so gemacht. Danach konnte ich die Frequenz beliebig nach oben schrauben. Bei 3400 Hz war Schluss, da meine Interruptroutine die Bits nicht schneller lesen kann.

Alles zusammen habe ich momentan etwa 450 Bytes pro Sekunde. Für 6.3K brauche ich 13.5 Sekunden.


So sieht der Funktionsverlauf im Endeffekt aus. Es ist kein echter Low-Pass, tut aber was es soll.
--
-------------------------------------------
Corontäne
-------------------------------------------

Dieser Beitrag wurde am 22.11.2016 um 07:56 Uhr von Hobi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
22.11.2016, 08:13 Uhr
Bert




Zitat:
Hobi schriebIch habe versucht, das Signal so niedrigfrequent wie nur irgendmöglich zu gestalten. Das war ein Fehler. Langsame Anstiege mag anscheinend das Interface nicht.



Hallo Andreas,
die Kasetteninterfaces dürften einen Bandpass darstellen.
Du hast es also mit einer Kombination aus Hochpass und Tiefpass zu tun. Der Hochpass filtert die Gleichspannung und die niedrigen Frequenzen aus.
Du kannst also nich beliebig weit runter gehen. Der Effekt lässt sich etwas kompensieren, wenn Du bei den niedrigen Frequenzen die Amplitude größer machst.

Das Verfahren nennt sich Pre-Emphasis bzw. Vorverzerrung, wird aber vornehmlich bei hohen Frequenzen angewandt:
https://de.wikipedia.org/wiki/Pre-Emphasis

Den Anstieg den Du siehst, das ist die Ladekurve vom Tiefpasskondensator.

Um Michas KC-Recorder zu beschleunigen bietet sich eher die Kombination M003 und RS-232 an. Dort gehen out-of-the-box 1200 bps (= 120 Byte/s).
Wenn man erst einen kleinen 'Bootloader' in den KC lädt und die Schnittstelle auf 19200 bps umkonfiguriert, funktioniert es auch mit 1,9 kByte/s. Ich habe meine Tests nur mit dem PC gemacht. Beim KC-Recorder hat man mehr Freiheitsgrade, was die Schnittstellenegschwindigkeit angeht.
Dort könnte auch nochmal Faktor 3 zu holen sein.
Das funktioniert allerdings nur bei den KC85/4 und KC85/5. Deine Methode ist universeller.

Grüße,
Bert
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
22.11.2016, 11:19 Uhr
Hobi



Jetzt noch was zu den Grenzen. Man braucht wahrscheinlich nicht unbedingt einen CTC zum Zählen. Wenn wir den Overhead weglassen den wir brauchen um den CTC einzustellen, haben wir vielleicht etwa 200 Taktzyklen um ein Byte zu schreiben. Das sollte ausreichen um eventuell bis zu 1K pro Sekunde zu übertragen.

Die andere Sache ist ja, dass diese Verbindung bidirektional ist. Über das Audiointerface können beliebige Pakete ausgetauscht werden. Auf der anderen Seite kann ein Fileserver hängen oder ein anderer Wasauchimmerfüreinservice.
--
-------------------------------------------
Corontäne
-------------------------------------------

Dieser Beitrag wurde am 22.11.2016 um 14:09 Uhr von Hobi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
22.11.2016, 17:15 Uhr
Mobby5



Ich meinte damit, dass es schon lange Turboloader gibt, dass man das Rad nicht neu erfinden muss, um schneller Laden und Speichern zu können. Ob die Daten nun auf Magnetband oder Digital gespeichert werden ist doch unerheblich. Irgendwo ist doch beim Kassetteninterface im KC auch Ende. Der digitale Rekorder muss natürlich die Daten des Turboloaders "verarbeiten" bzw. diese auch wieder bereitstellen können.
--
und ausserdem muss in Zeile 20 der Doppelpunkt durch ein Semikolon ersetzt werden
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
23.11.2016, 00:08 Uhr
Hobi




Zitat:
Irgendwo ist doch beim Kassetteninterface im KC auch Ende.



Du hast es richtig getroffen. Die Frequenz vom Kassetteninterface ist aber wesentlich höher, als bisher verwendet und es ist heutzutage der einzige Flaschenhals.

Um vielleicht doch noch etwas anzuhängen:

Ich denke schon, dass man noch etwas dazuerfinden kann. Der Kassetteneingang ist ein Band-Pass bis etwa 4kHz. Dennoch kann man weit aus höhere Frequenzen übertragen und auch noch messen. Ich mag das vorher genannte Modell mit dem Kondensator. Man kann versuchen höhere Frequenzen mit mehr Energie zu übertragen. Der Eingang vom meinem KC kann noch bei 8-10 kHz den Nulldurchgang erkennen.

beit 6kHz kann man noch sicher zwischen 0 und 1 unterscheiden. Das würde dann eine Bitrate von 9-10 kBit/Sekunde ergeben. Damit sind wir sogar noch schneller als die UART.

Wenn die Idee dann auch noch so funktionieren würde, wäre das eine tolle Anwendung.
--
-------------------------------------------
Corontäne
-------------------------------------------

Dieser Beitrag wurde am 23.11.2016 um 05:23 Uhr von Hobi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
27.11.2016, 13:51 Uhr
Hobi



Geschafft!!!

So nun habe ich mir das ganze Wochenende um die Ohren gehauen und mich mit Interrupts und Takte-zählen beschäftigt. Herausgekommen ist eine optimierte Variante die etwa alle 128 Takzyklen ein Bit erzeugen kann. Leider ist die Tonausgabe auf dem KC85/4 etwas aufwändig. Es geht nur über den Zähler und um den im Interrupt einzustellen braucht man schon allein 60 Zyklen.

Das Verfahren kann man sinngemäß für andere Rechner anpassen. Ich habe es nur auf dem KC geschrieben, da ich keinen anderen Rechner zum Testen habe. Theoretisch klappt das selbe Verfahren auch am EC1834.

Im wesentlichen läuft es darauf hinaus jeweils eine halbe Welle zu verwenden.

In kurz: die Frequenz ist etwa 6.1kHz, was in etwa 9200 Bits Netto pro Sekunde entspricht.
Mit Overhead und Checksumme sind das Netto 820 Bytes pro Sekunde.

8KB sind dann in 10 Sekunden überspielt. Gibt es eventuell jemand, der mir beim Testen helfen kann?

Die umgekehrte Variante ist schwieriger, aber dafür habe ich auch eine Lösung. Das aufgenommene Signal kann nicht wieder zum Abspielen verwendet werden, da wahrscheinlich noch ein Frequenzfilter am Eingang blockiert. Transformiert man aber das digitale Signal in geeigneter Weise, kommt man auch da durch.
--
-------------------------------------------
Corontäne
-------------------------------------------

Dieser Beitrag wurde am 27.11.2016 um 13:57 Uhr von Hobi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
01.12.2016, 04:28 Uhr
Hobi



Die Save-Routine ist soweit fertig und ich bin einen Schritt weiter die Software aufs Handy zu portieren.

16KB in 13,5 Sekunden! Das sind 1200 Bytes pro Sekunde.

Ich würde gern wissen, ob die Software auch auf anderen Rechnern funktioniert. Gibt es hier im Forum jemand, der die Beispiele auf dem KC85/2 oder KC85/3 ausprobieren kann?

wav2kcc.exe (für Windows 32-bit)
save.kcc
save.wav

Quellcode:
%TSAVE
TSAVE4 V4.01 Hobi's Schnellkopierer
Aufruf: AADR EADR (SADR)
AADR - Anfangsadresse
EADR - Endadresse (letztes Byte!)
SADR - (optional) Startadresse
%TSAVE C000 FFFF 0000
Name:DUMP C+E
%_



Falls es Probleme gibt, kann man das Programm wav2kcc auch mit der Option -hist starten. Damit kann man sehen, ob das Signal klar getrennt hereinkommt.


Quellcode:
0       0 <    80 :      1   0.00%   |     4000 <  4080 :   1196   0.45%
1      80 <   160 :      0   0.00%   |     4080 <  4160 :  46932  17.55%
2     160 <   240 :      0   0.00%   |     4160 <  4240 :  27106  10.13%
3     240 <   320 :      0   0.00%   |     4240 <  4320 :  35172  13.15%
4     320 <   400 :    258   0.10%   |     4320 <  4400 :  17124   6.40%
5     400 <   480 :      0   0.00%   |     4400 <  4480 :    754   0.28%
6     480 <   560 :      0   0.00%   |     4480 <  4560 :      0   0.00%
7     560 <   640 :      0   0.00%   |     4560 <  4640 :      0   0.00%
8     640 <   720 :      0   0.00%   |     4640 <  4720 :      0   0.00%
9     720 <   800 :      0   0.00%   |     4720 <  4800 :      0   0.00%
10    800 <   880 :      0   0.00%   |     4800 <  4880 :      0   0.00%
11    880 <   960 :      0   0.00%   |     4880 <  4960 :      0   0.00%
12    960 <  1040 :      0   0.00%   |     4960 <  5040 :      0   0.00%
13   1040 <  1120 :      0   0.00%   |     5040 <  5120 :      0   0.00%
14   1120 <  1200 :      0   0.00%   |     5120 <  5200 :      0   0.00%
15   1200 <  1280 :      0   0.00%   |     5200 <  5280 :      0   0.00%
16   1280 <  1360 :      0   0.00%   |     5280 <  5360 :      0   0.00%
17   1360 <  1440 :      0   0.00%   |     5360 <  5440 :      2   0.00%
18   1440 <  1520 :      0   0.00%   |     5440 <  5520 :      0   0.00%
19   1520 <  1600 :      0   0.00%   |     5520 <  5600 :      0   0.00%
20   1600 <  1680 :      0   0.00%   |     5600 <  5680 :     96   0.04%
21   1680 <  1760 :      0   0.00%   |     5680 <  5760 :    838   0.31%
22   1760 <  1840 :      0   0.00%   |     5760 <  5840 :   4440   1.66%
23   1840 <  1920 :      0   0.00%   |     5840 <  5920 :  31804  11.89%
24   1920 <  2000 :      0   0.00%   |     5920 <  6000 :  21966   8.21%
25   2000 <  2080 :      0   0.00%   |     6000 <  6080 :   7926   2.96%
26   2080 <  2160 :      0   0.00%   |     6080 <  6160 :   7982   2.98%
27   2160 <  2240 :      0   0.00%   |     6160 <  6240 :  41064  15.35%
28   2240 <  2320 :      0   0.00%   |     6240 <  6320 :  19162   7.16%
29   2320 <  2400 :      0   0.00%   |     6320 <  6400 :   2722   1.02%
30   2400 <  2480 :      0   0.00%   |     6400 <  6480 :    836   0.31%
31   2480 <  2560 :      0   0.00%   |     6480 <  6560 :     82   0.03%
32   2560 <  2640 :      0   0.00%   |     6560 <  6640 :      2   0.00%
33   2640 <  2720 :      0   0.00%   |     6640 <  6720 :      0   0.00%
34   2720 <  2800 :      0   0.00%   |     6720 <  6800 :      2   0.00%


--
-------------------------------------------
Corontäne
-------------------------------------------

Dieser Beitrag wurde am 01.12.2016 um 04:40 Uhr von Hobi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
01.12.2016, 07:47 Uhr
PIC18F2550

Avatar von PIC18F2550

Handy & wav Dateiwiedergabe?
Mein Samsung streikt da ( warum auch immer mp3 geht ist aber ein anderes Thema )
Oder willst Du eine App schreiben die das macht?

Ich hatte mal eine Variante für der Z1013 da wurde das bit im Tastverhältnis einer Schwingung gespeichert.
Mono 1,3k/sek und in Stereo 2,6k/sek es währe auch mehr möglich gewesen aber das Tonband brachte nicht mehr.
Die trägerfrequenz war 12khz 8datenbits mit einem sync bit.

Wenn du bei Wav bleibst ist das ok den Fraunhofers mp3 ist ungeeignet.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
01.12.2016, 08:18 Uhr
Hobi



Ich denke 1.3KByte sind sehr unwahrscheinlich. Beim Tonband sollte bei etwa 8kHz die Grenze sein.
Auf der anderen Seite ist meine Frequenz so um die 6kHz. Könnte noch reinpassen.

Beim Z1013 ist nach der Methode die Datenrate nach oben offen. Im Gegensatz zum KC muss dort kein Interrupt bedient werden (-20 Takte) und auch kein CTC (-22) . Da kann ich mindestens 4x schneller laden und speichern. Theoretisch könnte ich alle 19 Takte umschalten (CCF,RLA,OUT A). Das wuerde ich gern mal ausprobieren, wenn der Z128 kommt.

Was das WAV Format anbetrifft, so ist das ersteinmal der Start auf dem PC, sozusagen der Algorithmus, wie man die Audiodaten erstellt. Die meisten Handys können aber auch .WAV direkt abspielen. Aber man kann den Datenstrom auch direkt on the fly erzeugen. Ich hatte ein Demo programmiert, dass .KCC Files direkt "abspielen" kann.
--
-------------------------------------------
Corontäne
-------------------------------------------

Dieser Beitrag wurde am 01.12.2016 um 08:25 Uhr von Hobi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
01.12.2016, 10:00 Uhr
PIC18F2550

Avatar von PIC18F2550

Die Kennlinie geht bei den meißten Geräten dort nach unten endet aber nicht dort.

Mann muss das ausmessen.

Bei meinem Gerät war ein brauchbares Signal noch bei 14khz. Das heist es ging im Rauschen noch nicht unter.

Der Sender bestand aus einem Schieberegister und einigen logikgattern.
Der Empfänger bestand aus zwei zählerketten die verglichen wurden.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
01.12.2016, 10:40 Uhr
kaiOr

Avatar von kaiOr


Zitat:
Service-Anltg. KC85/4:
In der E/A-Steuerung wird im Unterschied zum KC85/3 statt des 2fach-Operationsverstärkers
ein 4fach-Operationsverstärker eingesetzt. Die zwei zusätzlichen Verstärkersysteme werden
statt der im 85/3 enthaltenen Transistorstufe zur Realisierung des aktiven Tiefpaßfilters,
welches durch das Fernsehgerät bedingte Störungen (Zeilen- und Schaltnetzteilfrequenz)
unterdrücken soll, eingesetzt. Gleichzeitig wurde die Filtergrenzfrequenz von 3 auf etwa 9
kHz erhöht
, um die Anwendung schnellerer Laderoutinen zu ermöglichen. Das bei den
Vorgängertypen bewährte Hochpaßverhalten des Eingangsteiles (untere Grenzfrequenz 1
kHz
) wurde beibehalten. Nach dem Filterteil folgen wie bisher Komparator (jetzt mit einer
Hysterese im Millivoltbereich zur Unterdrückung des Rauschens bei leeren Bandstellen) und
Monoflop.
Zur Vermeidung von Komplikationen bei der Interruptbearbeitung wurde das Monoflopausgangssignal
mit ARDY verknüpft. Diese Maßnahme findet sinngemäß auch beim
Tastaturkanal Anwendung. An die Flip-Flops für die Tonausgabe (Schaltkreis D3023) ist
zusätzlich das Signal trück herangeführt, durch welches beide Flip-Flops vor Beginn der Tonausgabe
in eine definierte Ausgangslage zurückgesetzt werden. Hierdurch wird eine
gegenseitige Auslöschung beider Tonkanäle vermieden, falls sie mit gleicher Frequenz
angesteuert werden.

Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
01.12.2016, 13:37 Uhr
PIC18F2550

Avatar von PIC18F2550

doppelt
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen

Dieser Beitrag wurde am 01.12.2016 um 13:38 Uhr von PIC18F2550 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

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