You are not logged in.

Dear visitor, welcome to Forum64. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

HOL2001

Super Moderator

  • "HOL2001" is male
  • »HOL2001« is a verified user

Posts: 6,915

Date of registration: Dec 23rd 2004

Location: Bei Arnsberg in NRW

  • Send private message

member since 90 month member since 90 month member since 90 month member since 90 month member since 90 month

81

Monday, December 15th 2008, 2:15pm

Hmm, irgendwie werden die Directories bei mir nicht mehr im CBM Zeichensatz angezeigt. Was mache ich falsch? :nixwiss:

DoReCo #37 am 22.06.2013 - Infos HIER!

TheRyk

KKK?! That's not good.

  • "TheRyk" is male
  • »TheRyk« is a verified user

Posts: 8,017

Date of registration: Mar 14th 2008

Location: Ostereierinsel

  • Send private message

member since 54 month member since 54 month member since 54 month

82

Monday, December 15th 2008, 2:38pm

Gecheckt, bei mir das Gleiche...
Habe es allerdings auch vor heute lange nicht geprüft, wenn überhaupt schon mal richtig.

Wenn Du ein altes Archiv brauchst, um zu testen, sag Bescheid,
brauche dann 'ne e-Mail-Adresse.
würde es hier ja uploaden, wenn es mit >1MB nicht leider knapp zu groß wäre...
Habe auf jeden Fall noch die d und/oder die c-Version hier als ZIP.

PS: Noch 'n paar Klitzekleinigkeiten festgestellt
- unwichtig: beim Importieren von .PRG oder .T64 etc. nimmt er nicht den Default, sondern den letzten Ordner, auch wenn man 'nen Default eingestellt hat
- befremdlich: wenn man .T64 importiert, zeigt "er" links eine kleinere Dateigröße an als rechts nach dem Schreiben... (und die rechts stimmt wiederum mit der Größe, die man über DirMaster-Import eines .T64 erhält, überein, sollte also die richtige sein)
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)

This post has been edited 2 times, last edit by "TheRyk" (Dec 15th 2008, 3:03pm)


Birger

Trainee

  • "Birger" is male
  • "Birger" started this thread

Posts: 101

Date of registration: Sep 22nd 2008

  • Send private message

member since 54 month member since 54 month member since 54 month

83

Monday, December 15th 2008, 9:23pm

Hallo,

das mit der Schrift hat folgende Ursache:
Ich habe die Schrift selbst gebastelt und hatte zu Beginn nur das Große Alphabet drin. Um aber die meisten Trennlinien im Directory einigermaßen originalgetreu darstellen zu können, hatte ich die Schrift nochmals angepasst. Nun scheint es so, das Windows die Schriften als zwei unterschiedliche ansieht, der Dateiname aber gleich ist. Da PRGMover nur nachschaut ob die Schrift mit dem Dateinamen vorhanden ist, kann es sein dass ihr noch die alte drin habt, da PRGMover diese findet, Windoof aber nicht :-(

Abhilfe:
Geht in den Schriftordner von Windows (normalerweise C:\WINDOWS\Fonts) löscht die dortige Schrift "CBM PRG-Mover.ttf" und kopiert die neuste Version (findet man im Ordner PRGMover/bin) wieder in den Windowsschriftordner... fertig

@TheRyk: Das mit dem Import von einzelnen Files, also dem Default Ordner habe ich angepasst. Jetzt laufen diese mit dem Öffnen für Images parallel...

Die T64-Geschichte ist in der tat seltsam. Also verständlich für mich ist, dass die Blocks direkt nach dem Importieren nicht ganz stimmen. Jedoch sollte dies spätestens nach Ansicht/Aktualisieren bzw. Directory Neuladen bei der Floppy korrekt angezeigt werden. Hintergrund: Um Zeit zu sparen und die Anwendung etwas weniger hakelig laufen zu lassen, wird nicht nach jeder Aktion das Directory neu geladen. Beim Importieren von Dateien rechnet PRGMover die "Windows-Bytes" in "Commodore-Blocks" um. Das funktioniert bei PRG, BIN und ROM recht zuverlässig, aber bei T64 gibt es scheinbar keine feste Formel, oder ich bin noch nicht dahinter gekommen, von daher gibt es Abweichungen, die bis 150 Blocks im einstelligen Blockbereich liegen... meines Erachtens hinnehmbar. Wie auch immer, nach einem aktualisieren der Directorys sollten diese jedoch gleich sein, sind sie aber nicht. Jetzt ist es so, das ich erst letztens die Anwendung für das Importieren von T64-Dateien getauscht habe. Das hatte die ganze Zeit T642PRG + c1541 erledigt. Da aber auf 64Bit-Rechnern T642PRG nicht mehr läuft, nutze ich jetzt nur noch c1541, welches auch auf 64Bit-Kisten läuft. Mit T642PRG stimmen die Blocks... hm, hast du mit dem Importierten Programm anschließend Probleme?... Also ich habe eben mal en Spiel (Snokie - sehr geil:-) getestet, es bläht sich zwar um satte 6 Blocks auf, funzt hinterher aber noch... zumindest im VICE... Ich schau mir das ganze mal im HexEditor an... Ahah... C1541 schippelt den T64-Container nicht weg. So ein Mist! Ich schau mir c1541 noch mal genau an, irgendwas ist da faul... :wacko:

This post has been edited 3 times, last edit by "Birger" (Dec 15th 2008, 9:57pm)


Birger

Trainee

  • "Birger" is male
  • "Birger" started this thread

Posts: 101

Date of registration: Sep 22nd 2008

  • Send private message

member since 54 month member since 54 month member since 54 month

84

Monday, December 15th 2008, 9:32pm

Directory-Auslesen: Da es hierfür wohl Verwendung gibt, setzte ich dem ganzen noch ein Sahnehäubchen auf und integriere eine Batchroutine, mit der man alle Image-Files eines Ordners, wahlweise in ein Textdokument, oder je Directory in ein separates Textfile auslesen kann... im letzteren Fall werden die einzelnen Textfiles im gleichen Ordner abgelegt wo sich auch die Images befinden, dabei wird für das Textfile der entsprechende Image-Name + .txt verwendet... schön schön, dan code ich mal los :hammer:

TheRyk

KKK?! That's not good.

  • "TheRyk" is male
  • »TheRyk« is a verified user

Posts: 8,017

Date of registration: Mar 14th 2008

Location: Ostereierinsel

  • Send private message

member since 54 month member since 54 month member since 54 month

85

Tuesday, December 16th 2008, 12:19am

Nochmal zum "Aufblähen": Ich denke eben eher, es wird zunächst als unnatürlich "geschrumpft" angezeigt.

Denn ein Test mit dem Dir-Master lieferte auf Anhieb auch die größere Block-Anzahl .

Ansonsten Danke für die Infos und frohes Weiter-Coden :winke:
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)

Birger

Trainee

  • "Birger" is male
  • "Birger" started this thread

Posts: 101

Date of registration: Sep 22nd 2008

  • Send private message

member since 54 month member since 54 month member since 54 month

86

Tuesday, December 16th 2008, 2:17am

Hm, bei mir waren sie immer größer als wie sie sein sollten... Wie auch immer, jetzt ist die Blockzahl gleich dem von DirMaster und sie laufen auch nach dem Rübernudeln noch im Emulator. Ich denke das passt so :rolleyes:
Da ich mit der Batch-Directory-Geschichte heute nicht fertig geworden bin (hätte nie gedacht dass die Sache so umfangreich wird...) , gibts auch noch kein Update mit den Verbesserungen... Sobald es fertig ist, werde ich es hier posten... Ich muss jetzt Bubu machen sonst fall ich morgen auf der Arbeit um :sleeping:

HOL2001

Super Moderator

  • "HOL2001" is male
  • »HOL2001« is a verified user

Posts: 6,915

Date of registration: Dec 23rd 2004

Location: Bei Arnsberg in NRW

  • Send private message

member since 90 month member since 90 month member since 90 month member since 90 month member since 90 month

87

Tuesday, December 16th 2008, 7:35am

Geht in den Schriftordner von Windows (normalerweise C:\WINDOWS\Fonts) löscht die dortige Schrift "CBM PRG-Mover.ttf" und kopiert die neuste Version (findet man im Ordner PRGMover/bin) wieder in den Windowsschriftordner... fertig
Ahh, alles klar !

Directory-Auslesen: Da es hierfür wohl Verwendung gibt, setzte ich dem ganzen noch ein Sahnehäubchen auf und integriere eine Batchroutine, mit der man alle Image-Files eines Ordners, wahlweise in ein Textdokument, oder je Directory in ein separates Textfile auslesen kann... im letzteren Fall werden die einzelnen Textfiles im gleichen Ordner abgelegt wo sich auch die Images befinden, dabei wird für das Textfile der entsprechende Image-Name + .txt verwendet...
Gute Sache ! :)

DoReCo #37 am 22.06.2013 - Infos HIER!

Birger

Trainee

  • "Birger" is male
  • "Birger" started this thread

Posts: 101

Date of registration: Sep 22nd 2008

  • Send private message

member since 54 month member since 54 month member since 54 month

88

Wednesday, December 17th 2008, 1:55am

OK, die neue Version 0.3f ist jetzt oben und kann gesaugt werden.

Zusammenfassung:

- Beim Importieren wird auch auf den Defaultordner zugegriffen, falls angegeben und gecheckt!
- Problem mit T64 Einlesen sollte jetzt funktionieren
- Directory auslesen von Floppy und Image + Batchauslesen von kompletten Ordnern

Näheres ist ab jetzt auch in der Hilfe zu finden, dort sind alle Funktionen aufgeführt und beschrieben.

Für Quereinsteiger zu diesem Faden: Das Tool steht hier - > http://tech-ecke.de/pc_tools.htm :!:

TheRyk

KKK?! That's not good.

  • "TheRyk" is male
  • »TheRyk« is a verified user

Posts: 8,017

Date of registration: Mar 14th 2008

Location: Ostereierinsel

  • Send private message

member since 54 month member since 54 month member since 54 month

89

Wednesday, December 17th 2008, 2:07am

Hört sich wieder mal gut an *saug* Danke :winke:
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)

HOL2001

Super Moderator

  • "HOL2001" is male
  • »HOL2001« is a verified user

Posts: 6,915

Date of registration: Dec 23rd 2004

Location: Bei Arnsberg in NRW

  • Send private message

member since 90 month member since 90 month member since 90 month member since 90 month member since 90 month

90

Wednesday, December 17th 2008, 7:35am

*saug*

DoReCo #37 am 22.06.2013 - Infos HIER!

Birger

Trainee

  • "Birger" is male
  • "Birger" started this thread

Posts: 101

Date of registration: Sep 22nd 2008

  • Send private message

member since 54 month member since 54 month member since 54 month

91

Thursday, December 18th 2008, 12:41am

Hi,

wir alle würden doch gerne G64-Images, ohne den Umweg über D64 zur Floppy senden, um somit auch kopiergeschützte Disketten wieder zur Floppy senden zu können. Ich habe eben mal ein wenig gegoogled und festgestellt, dass mnib (Markus Brenner) unter dem Namen nibtools seit 2004 weiterentwickelt wurde. Ich dachte bislang immer das die Entwicklung komplett eingestellt wurde... Wie auch immer mit nibtools ist es nun auch möglich G64-Images wieder auf eine original Diskette zu verbannen. Prinzipiell kann man dies natürlich auch im PRGMover einbinden, jedoch benötigt man neben dem XA/M-Kabel noch ein XP1541 bzw. XP1571 Parallelkabel. Darüberhinaus sind die Settings zu dem Tool sehr umfangreich und können je nach verwendetem Kopierschutz individuell gesetzt werden. Wie weit man mit den Defaultwerten bei kopiergeschützten Disketten kommt kann ich nicht sagen. Die Frage ist, lohnt sich der ganze Aufwand? Ich mache mir ungern die ganze Arbeit, wenn es hinterher keiner nutzt, zumal ich persönlich es wohl eher weniger bis überhaupt nicht nutzen würde. Das einbinden in PRGMover wäre dabei eine Sache, man muss das Tool aber auch vorher in allen Lagen testen, wo mir dann schon mal die Originaldisketten mit Kopierschutz fehlen würden. Dann müsste ich mir auch ein XP-Kabel bauen, denn so etwas besitze ich zur Zeit auch noch nicht, obwohl das eher simpel ist im Gegensatz zum XA oder XM.

Wie auch immer, meint ihr man sollte dies angehen?

Hier mal ein Auszug der Settings von nibtools:

usage: nibread/nibwrite [options] filename
(some options are for reading only, some are for writing only, some are for both)

-D[n] : Drive # (default 8)

-S[n] : Starting Track (default 1)

-E[n] : Ending Track (default 41)

-s[n] : Track skew in microseconds - Some protections depend on data being perfectly aligned from
track to track. Some depend on them being skewed a specific amount from each other. You
can use this feature to reproduce this if you know the skew. There is a tool to determine
the skew in OpenCBM called rpm1541.

-t : Timer-based track alignment. Used to simulate track to track alignment using tightly controlled
delays. It can be accurate to 10ms or so on a stable drive, nearly useless on others.

-u : Unformat disk (removes *ALL* data) This option writes all $00 bytes (bad GCR) to the entire disk
surface, simulating the state of a brand new never-formatted disk.

-l : Limit functions to 40 tracks (R/W) Some disk drives will not function past track 41 and will click
and jam the heads too far forward. The drive cover must then be removed and the head pushed back
manually. If this happens to you, use this option with every operation. There are only a few disks
which utilize track 41 for protection.

-h : Use halftracks (R/W) This option will step the drive heads 1/2 track at a time during disk
operations instead of a full track. This protection is only very rarely used. I have only found
2 disks out of thousands. Bounty Bob Strikes Back is one.

-k : Disable reading 'killer' tracks (R) Some drives will timeout when trying to read tracks that consist
of all sync. If you cannot read a disk because of timeouts, use this option.

-r : Disable 'reduce syncs' option (R) By default, NIBTOOLS will "compress" a track when writing back out to
a disk if the track is longer than what your drive can write at any given density (due to drive
motor speed). Some (very rare) protections count sync lengths so the protection might fail with this
option. For 99.9% of disks, it is fine and is the default setting.

-g : Enable 'reduce gaps' option (R) This option is another form of "compression" used when writing out a
disk. "gaps" are inert data placed right before a sync mark that can usually be safely removed. It
is not on by default, but if NIBTOOLS is truncating tracks and they still won't load, you can try this
option to squeeze a bit more onto the track.

-0 : Enable 'reduce bad GCR' option (R) This option is another form of "compression" used when writing out a
disk. "Bad GCR" (when not used for copy protection) is unformatted or corrupted data that can
usually be safely removed. It is not on by default, but if NIBTOOLS is truncating tracks and they still
won't load, you can try this option to squeeze a bit more onto the track.

-f : Disable bad GCR detection (W) "bad GCR" is either corrupted (or illegal) GCR that are
either intentionally placed on a disk for protection, or are simply unformatted data on the disk.
NIBTOOLS will by default zero out this data and write it to disk as if it were unformatted. This option
can be disabled if the disk image is using illegal GCR on purpose, such as how V-MAX! does on the
track 20 loader.

-c : Disable automatic capacity adjustments. By default NIBTOOLS measures the speed of your drive and makes
adjustments to the data (compression) based on that speed. If your drive is exactly 300rpm or the
tracks you are writing are standard (D64), you can bypass this and save a few seconds.

-aX: Alternative track alignments (W) There are several different ways to align tracks when writing them
back out. By default, NIBTOOLS will do it's best to figure out how the original disk had it by analyzing
the data. To force other methods, use this option.

-aw: Align all tracks to the longest run of unformatted data.
-ag: Align all tracks to the longest gap between sectors.
-a0: Align all tracks to sector 0.
-as: Align all tracks to the longest sync mark.
-aa: Align all tracks to the longest run of any one byte (autogap).

-eX: Extended read retries (R) This is used on deteriorated disks to increase the number of read attempts
to get a track with no errors. Use any numerical value, but if it's too high it could take a while
to read the disk. Default is 10.

-pX: Custom protection handlers (W) This is used to set some flags to handle copy protections which don't
remaster with default settings.

-px: Used for V-MAX disks to remaster track 20 properly.
-pg: Used for GMA/Securispeed disks to remaster track 38 properly.
-pr: Used for Rapidlok disks to remaster them properly.
-pv: Used for newer Vorpal disks, which must be custom aligned to load when remastered.

-G[n] : Match track gap by [n] bytes. By default the pattern matching looks for repeating
patterns of 7 (56 bits) bytes to find the gaps. You can adjust this if you are getting too small
track length detection (or too large).

-d : Force default densities. By default NIBTOOLS tries to detect the density of the written data. If
you're sure the disk is standard, you can use this to bypass the checks and save time. This is useful
because sometimes badly damaged tracks can detect at the wrong density.

-v : Verbose. Output more detailed data to console.

-m : Enable track matching. This is a crude read verification

-i : Interactive mode. This allows for reading many disks in one sitting without having to initialize
the disk drive every time. Imaging a disk in this way takes about 8 seconds for a full 41 tracks.

TheRyk

KKK?! That's not good.

  • "TheRyk" is male
  • »TheRyk« is a verified user

Posts: 8,017

Date of registration: Mar 14th 2008

Location: Ostereierinsel

  • Send private message

member since 54 month member since 54 month member since 54 month

92

Thursday, December 18th 2008, 12:51am

Huh. Klingt natürlich verlockend.

Aber mit XP1541-Kabel habe ich mich noch nicht befasst. Geht das auch in 'ner 1541-II? Was wird damit verbunden? Also auf den ersten Blick klingt das für mich komplex... Heißt nicht, dass ich es mir nicht zutraue. Aber vielleicht sollten mal ein paar andere Meldung machen, HOL z.B., was er so meint bzgl. Machbarkeit und ob es sich für die breite Masse der User lohnen würde.
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)

Birger

Trainee

  • "Birger" is male
  • "Birger" started this thread

Posts: 101

Date of registration: Sep 22nd 2008

  • Send private message

member since 54 month member since 54 month member since 54 month

93

Thursday, December 18th 2008, 1:06am

Hier mal en Link zum XP-Kabel... klick klack

HOL2001

Super Moderator

  • "HOL2001" is male
  • »HOL2001« is a verified user

Posts: 6,915

Date of registration: Dec 23rd 2004

Location: Bei Arnsberg in NRW

  • Send private message

member since 90 month member since 90 month member since 90 month member since 90 month member since 90 month

94

Thursday, December 18th 2008, 7:49am

Moin !
Hmm, also verlockend klingt das ganze schon. Aber um ehrlich zu sein: Ich würde es nicht nutzen, da mir der ganze Aufwand (Kabel, Settings etc.) zu viel wäre.
Wenn du es implementierst OK, wenn nicht auch OK. ;)

DoReCo #37 am 22.06.2013 - Infos HIER!

TheRyk

KKK?! That's not good.

  • "TheRyk" is male
  • »TheRyk« is a verified user

Posts: 8,017

Date of registration: Mar 14th 2008

Location: Ostereierinsel

  • Send private message

member since 54 month member since 54 month member since 54 month

95

Saturday, December 20th 2008, 1:27am

Wollte nur mal lobend erwähnen, dass ich gerade ein paar Disketten bespiele und das echt superkomfortabel finde mit dem Markieren/Drag&Drop der Einzelfiles. Eigentlich wird damit beinahe der "Umweg" DirMaster überflüssig.
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)

Birger

Trainee

  • "Birger" is male
  • "Birger" started this thread

Posts: 101

Date of registration: Sep 22nd 2008

  • Send private message

member since 54 month member since 54 month member since 54 month

96

Saturday, December 20th 2008, 9:11pm

So, mein XP-1541 Kabel bzw. XAP-Combokabel ist fertig. Im Grunde kann
man aber auch recht simpel sein vorhandenes XA/XM Kabel zum Combokabel
erweitern. Im Grunde muss man nur 8 weitere Kabel vom LPT-Port (Pin 2-9) mit dem ersten VIA Chip der 1541 verbinden, hier auch von Pin 2-9, also 1 mit 1, 2 mit 2 verbinden... usw. Da es aber in meinem Fall bedeutet hätte, en zweites Kabel
vom LPT zur Floppy zu legen, da mein vorhandenes Kabel mit den Litzen
am Ende war, hab ich gleich en neues gebastelt. Hier mal die Bilder...


http://www.bildercache.de/minibild/20081220-204738-233.jpg
Bild1 in Originalgröße -> bei der 1541-II muss auch Pin 2 (rot) vom VIA#1 von der Platine getrennt werden


http://www.bildercache.de/minibild/20081220-205552-255.jpg
Bild2 in Originalgröße -> mal von weiter weg...


http://www.bildercache.de/minibild/20081220-205647-188.jpg
Bild3 in Originalgröße -> angestöpselt

Da ich das Kabel nun habe, wird auch in der nächsten Version (eventuell heute Abend/Nacht noch) nibtools mit eingebunden sein :D

Mein Tipp: Bastelt euch das Kabel auf jeden Fall, egal ob ihr nibtools benutzen werdet oder nicht, der Geschwindigkeitszuwachs auch bei CBM4Win ist es alleine schon wert (Images lesen/schreiben)

So, ich mach mich mal wieder ans coden :hammer:

This post has been edited 1 times, last edit by "Birger" (Dec 20th 2008, 9:46pm)


Birger

Trainee

  • "Birger" is male
  • "Birger" started this thread

Posts: 101

Date of registration: Sep 22nd 2008

  • Send private message

member since 54 month member since 54 month member since 54 month

97

Wednesday, December 24th 2008, 5:20am

So, nach einer durchzechten Nacht am PC... so mitten in den Heiligen Morgen rein... ist es nun endlich vollbracht. Mal wieder eine neue Version von PRGMover (V0.3g), die es aber in sich hat... quasi nibtools in sich hat ;-) Aber auch noch mehr...
Die wichtigsten Änderungen:

http://www.mysmilie.de/smilies/xmas/img/003.gif

- Unterstützt nun auch voll D71 Images Lesen/Schreiben bei angeschlossener 1571
- beim Lesen/Schreiben kann nun auch wahlweise Track 36-40 verarbeitet werden (nur D64 bzw. G64 über nibtools bis 41)
- G64-Images können mittels nibtools direkt zur 1541/71 übertragen werden (nur mit XP-1541-Kabel)
- Der Fortschrittsbalken kann in Einstellungen an die Rechnergeschwindigkeit angepasst werden

nibtool lehnt sich übrigens an den bekannten Burst Nibbler an und ist quasi die Windows-Reinkarnation dieser Anwendung aus längst nicht vergessenen Tagen ;-)

So, dann sag ich mal FROHE WEIHNACHTEN !!!

PS: schaut mal wie oft ich den Beitrag schon editiert habe... ich bin sau müde... ich muss weg... :zzz:

This post has been edited 4 times, last edit by "Birger" (Dec 24th 2008, 5:28am)


C64-CAMPER

Liemke - das Paradies auf Erden ;-)

  • »C64-CAMPER« is a verified user

Posts: 7,443

Date of registration: Mar 31st 2006

Location: 33758 SHS

  • Send private message

member since 72 month member since 72 month member since 72 month member since 72 month

98

Wednesday, December 24th 2008, 5:29am

Das klingt alles super :)

Aber bitte die Bilder ins Forum hochladen!
Externe Verlinkung ist nicht erlaubt.
Classic Gamers -->http://www.classic-gamers.de<--

HOL2001

Super Moderator

  • "HOL2001" is male
  • »HOL2001« is a verified user

Posts: 6,915

Date of registration: Dec 23rd 2004

Location: Bei Arnsberg in NRW

  • Send private message

member since 90 month member since 90 month member since 90 month member since 90 month member since 90 month

99

Wednesday, December 24th 2008, 9:06am

Na, das nenne ich doch einmal ein Weihnachtsgeschenk !
Vielen Dank Birger und Frohe Weihnachten ! :winke:

DoReCo #37 am 22.06.2013 - Infos HIER!

TheRyk

KKK?! That's not good.

  • "TheRyk" is male
  • »TheRyk« is a verified user

Posts: 8,017

Date of registration: Mar 14th 2008

Location: Ostereierinsel

  • Send private message

member since 54 month member since 54 month member since 54 month

100

Wednesday, December 24th 2008, 12:32pm

Jou, finde ich auch fein. Dann können meine nächsten Transferorgien ja losgehen zwischen Weihnachten und Neujahr.
:respect:
Allseits frohe Festtage!
Ryk
Wenn Sie irgendwelche Satzzeichen in meinen Postings vermissen, bedienen Sie sich, bitte:
@!#?@! (Zitat Q*bert, Arcade Version, 1982)