DIY Ambilight howto?

Xandrios & Clock: Als het inderdaad met een ATMega88 op de manier die ik in gedachten heb kan (dus zonder voorschakelpruttel, geen lijnversterkers) ben je voor een tientje, misschien 2, aan onderdelen klaar. Daar komen dan nog de LEDS/CCFLs en de voeding bij/

quote:

Glewellyn schreef op donderdag 12 januari 2006 @ 21:36:
[...]


Je hebt de code dus nog iets aangepast? In mijn code kon hij maximaal 1280*800 aan, de resolutie van mijn laptop's tft...

Oh en over die processoren, SpriteTM heeft had een inkoopactie lopen: inkoopactie

Ja, 'k heb het aangepast tot 1.32 miljoen pixels maximaal (1280 x 1024)....veel plaatjes/wallpapers zijn op dat formaat

Als die "Nr. 7 - LPC2132" van 28 euro het zou aankunnen, dat is idd best wel betaalbaar Mooi

quote:

Sprite_tm schreef op donderdag 12 januari 2006 @ 21:50:
Xandrios & Clock: Als het inderdaad met een ATMega88 op de manier die ik in gedachten heb kan (dus zonder voorschakelpruttel, geen lijnversterkers) ben je voor een tientje, misschien 2, aan onderdelen klaar. Daar komen dan nog de LEDS/CCFLs en de voeding bij/

Dat is helemaal goed te doen, super

Xandrios wijzigde dit bericht 12-01-2006 21:52 (26%)

quote:

Sprite_tm schreef op donderdag 12 januari 2006 @ 21:50:
Xandrios & Clock: Als het inderdaad met een ATMega88 op de manier die ik in gedachten heb kan (dus zonder voorschakelpruttel, geen lijnversterkers) ben je voor een tientje, misschien 2, aan onderdelen klaar. Daar komen dan nog de LEDS/CCFLs en de voeding bij/

Kan je die niet samplen? Het gaat uiteindelijk om een educatieve oplossing, we leren gezamenlijk om toepassingen in elkaar te knutselen met µP, waardoor meer mensen met µP kunnen werken, en er ook meer gebruik van wordt gemaakt in bedrijven (daar waar ze hun geld halen).

PIC's kan je perfect samplen (20% van de omzet van Microchip zit in samples), werken ook op 20MHz, en kunnen gemakkelijk geprogrammeerd/in een print gezet worden, misschien handig? (Misschien zijn PIC wat moeilijker te programmeren, of wat minder krachtig?)
Edit: ik heb ff een datasheet bekeken van die ATMega88, enige verschil lijkt me dat die ATM een grotere instrucieset heeft (PIC heeft 35 instructies, is dus gemakkelijker te begrijpen), en als voordeel ook hardwarematig kan vermenigvuldigen (kunnen we nodig hebben, in PIC's moet je daarvoor een compiler gebruiken of zelf het vermenigvuldigen maken).

Nuja, de µP zelf doet er ws niet toe, het systeem waarmee we werken des te meer (werk kleurkiesalgoritme, hoe data inlezen).

naftebakje wijzigde dit bericht 12-01-2006 22:26 (23%)

quote:

naftebakje schreef op donderdag 12 januari 2006 @ 22:15:
Kan je die niet samplen? Het gaat uiteindelijk om een educatieve oplossing, we leren gezamenlijk om toepassingen in elkaar te knutselen met µP, waardoor meer mensen met µP kunnen werken, en er ook meer gebruik van wordt gemaakt in bedrijven (daar waar ze hun geld halen).

Tja zo kun je samplen ook goedpraten natuurlijk AVRs zijn prima te verkrijgen, de zwaardere misschien wat minder maar futurlec heeft bijvoorbeeld een hele serie AVRs voor prima prijzen.

quote:

PIC's kan je perfect samplen (20% van de omzet van Microchip zit in samples), werken ook op 20MHz, en kunnen gemakkelijk geprogrammeerd/in een print gezet worden, misschien handig? (Misschien zijn PIC wat moeilijker te programmeren, of wat minder krachtig?)
Edit: ik heb ff een datasheet bekeken van die ATMega88, enige verschil lijkt me dat die ATM een grotere instrucieset heeft (PIC heeft 35 instructies, is dus gemakkelijker te begrijpen), en als voordeel ook hardwarematig kan vermenigvuldigen (kunnen we nodig hebben, in PIC's moet je daarvoor een compiler gebruiken of zelf het vermenigvuldigen maken).

Ik geloof dat PICs meestal meer clockcycles nodig hebben voor instructies, de AVRs kunnen er veel in 1 clockcycle doen. Maar misschien dat het bij nieuwe/zwaardere PICs anders is. Ik gebruik altijd AVRs.

madwizard wijzigde dit bericht 13-01-2006 14:03 (6%)

Heeft er iemand trouwens nog ideeën over het verwerken van composite (of s-video) als aansturing, aan de hardware kant? RGB is natuurlijk lekker makkelijk maar een SCART aansluiting (of los RGB/Component) heb je meestal niet 'over', terwijl er vaak naast zo'n aansluiting nog wel een composite of s-video aansluiting over is. Die zou je mooi kunnen gebruiken om je ambilight aan te sturen, scheelt ook een hoop losse / 1 dikke kabel. Vervelende is dat composite zeker niet direct te verwerken is. Ik heb al flink gezocht naar ICs die hier iets mee kunnen. Er zijn wel wat ICs die composite omzetten naar analoog RGB maar deze zijn uit de jaren 80 en worden al lang niet meer gemaakt. Van de nieuwere ICs is zijn er veel PAL decoders te vinden maar deze hebben allemaal een digitale output met een dusdanige kloksnelheid dat je daar niet even makkelijk mee kunt werken in een microcontroller. Je kunt waarschijnlijk wel met een aantal ICs de boel weer in analoog RGB omzetten maar dan zit je alleen maar analoog naar digitaal naar analoog te converteren met een paar ICs van 10 euro per stuk en dat is ook weer wat overdreven. Weet er iemand nog ICs die hiervoor geschikt zijn? Of is er alleen nog maar digitaal spul te krijgen tegenwoordig?

Kom op, die AVRs kosten EUR2,17 (geen spam, afaik is dit gewoon de goedkoopste shop), je mag natuurlijk altijd free samplen als je dat wilt, maar imo kan je het voor die prijs net zo goed kopen.

madwizard: Da's inderdaad een leuke... Vroegah had Elektuur hier wel een schakeling voor, maar die kan ik zo 123 niet terugvinden... Nja, je kan altijd nog een sortta scart-tussenstekker maken die het RGB-signaal aftapt en een extra female scartstekker heeft waar je dan je andere apparaat aan kan hangen.

quote:

Sprite_tm schreef op woensdag 11 januari 2006 @ 22:04:
Een ATMega88 zou het misschien ook nog net kunnen redden: op z'n rapst kan dat ding met 500KHz samplen, dat zou betekenen (met 3 kanalen) dat je eens per 10 pixels een sample kan nemen, waardoor je kleine details misschien meer waarde geeft dan het zou moeten hebben.

Volgens mij haal je nog veel minder pixels. Weet niet hoe je het aantal pixels hebt uitgrekend (hangt van je resolutie af) maar ik als volgt: Een beeldlijn is 64uS, waarvan 52uS zichtbaar. Op 500KHz samplen betekent 2uS per sample. Dat is 52/2=26 samples per beeldlijn. De ATmega's (iig de 88 en 8) kunnen niet alle kanalen tegelijk samplen, er wordt er steeds een geselecteerd. Dus die 26 moeten ook nog eens verdeeld worden over 3 kleuren, zodat je er max ~ 8 overhoud per beeldlijn.
Op zich genoeg als je het signaal eerst analoog middelt, dan heb je 8 gemiddelden per lijn. Alleen zit er dus wel een redelijke tijd tussen de samples waardoor het gemiddelde misschien te veel verschoven tussen de kleuren.

Als ik een beetje werkend iets heb wil ik het eigenlijk testen op VGA, omdat dat nou eenmaal (extra) uit m'n videkaart komt En het zou wel leuk zijn als het op zowel VGA als RGB uit SCART zou werken. VGA is alleen normaal gesproken 60Hz wat dus nog sneller gesampled moet worden.

Het beste is volgens mij toch een aparte ADC, bij voorkeur een die meerdere kanalen tegelijk kan samplen.

madwizard wijzigde dit bericht 18-01-2006 11:52 (4%)

madwizard: krek, je hebt gelijk Nja, dan zullen we inderdaad toch aan de externe AD-converter(s) moeten.

quote:

headhunternl schreef op woensdag 11 januari 2006 @ 17:28:
[...]


Die vertraging, is dat dan de reden dat ik het beeld op een pixelplus/ander digitaal effect philips-tv er zo nep uit vindt zien? alsof het een home-video is (mist een beetje dat filmgevoel).

Heeft ook te maken met de beelden die er tussen worden berekend, het geheel wordt dan "vloeiender" waardoor het lijkt als of je een homevideo bekijkt. Ik ben der persoonlijk ook geen fan van, omdat het soms bij snelle pan/scan camerabewegingen dan nep uit ziet (lastig uitleggen, maar je ziet gewoon dat er wat tussen wordt gefantaseerd...)

quote:

Sprite_tm schreef op woensdag 18 januari 2006 @ 12:17:
madwizard: krek, je hebt gelijk Nja, dan zullen we inderdaad toch aan de externe AD-converter(s) moeten.

Toch denk ik dat je prima kan werken met 8 samples per line... Je hebt 288 beeldlijnen per interlaced beeld dat geeft je denk ik een representatief genoeg gemiddelde.

Verder lijkt het mij verstandig om met een voortschrijdend gemiddelde te werken van de laatste 50 (halve) frames, op die manier fade je in een seconde van blauw naar geel bijvoorbeeld. Door te spelen met het aantal historische waarden kan je dan relatief makkelijk je reaktiesnelheid varieren.

Het effect van een kleinere steekproef op 1 frame kan je uitproberen met mijn php scriptje:
http://ambilight.100webcu...old.jpg&samplerate=20

Glewellyn wijzigde dit bericht 18-01-2006 14:33 (13%)

Is het id van een samplende voorschakeling echt geen goeie oplossing? Als je met een PLL bijvoorbeeld de lijnfrequequentie *3 doet, kan je het gemiddelde van rechts, midden en links gemakkelijk maken (3 buffers, wat logica, sample-and-hold, moet te doen zijn). Dan heb je de 3 delen van het beeld, voor de 3 kleuren, dus 9 waarden die je inleest. Door de snelheid van op/ontladen te regelen van de sample-and-hold's, kan je dan nog regelen welke horizontale strook je meet.
Zo voorkom je (dure) externe A/D's, ik heb echter niet de tijd om nu schema's te bedenken, eerst mijn examens doen.

quote:

Glewellyn schreef op woensdag 18 januari 2006 @ 14:31:
Toch denk ik dat je prima kan werken met 8 samples per line... Je hebt 288 beeldlijnen per interlaced beeld dat geeft je denk ik een representatief genoeg gemiddelde.

Ik ging in mijn algoritmes steeds al uit van 8 samples per lijn, alleen is mijn doel om 8x8=64 gemiddelden per beeld te berekenen, in plaats van 1 gemiddelde wat jij nu hebt in je script. Over het hele beeld genomen zal het wel loslopen met de volgorde van de R, G en B samples maar als je per lijn 8 gemiddelden wil is het lastiger, groen zou dan dichter bij de volgende sample zitten dan bij de rode waar ie bij hoort.

quote:

Verder lijkt het mij verstandig om met een voortschrijdend gemiddelde te werken van de laatste 50 (halve) frames, op die manier fade je in een seconde van blauw naar geel bijvoorbeeld. Door te spelen met het aantal historische waarden kan je dan relatief makkelijk je reaktiesnelheid varieren.

Dat ook, alleen bij mij zou dat dan in de uiteindelijke waarde gedaan worden omdat ik meerdere gemiddelden heb.

quote:

naftebakje schreef op woensdag 18 januari 2006 @ 14:50:
Is het id van een samplende voorschakeling echt geen goeie oplossing? Als je met een PLL bijvoorbeeld de lijnfrequequentie *3 doet, kan je het gemiddelde van rechts, midden en links gemakkelijk maken (3 buffers, wat logica, sample-and-hold, moet te doen zijn). Dan heb je de 3 delen van het beeld, voor de 3 kleuren, dus 9 waarden die je inleest. Door de snelheid van op/ontladen te regelen van de sample-and-hold's, kan je dan nog regelen welke horizontale strook je meet.
Zo voorkom je (dure) externe A/D's, ik heb echter niet de tijd om nu schema's te bedenken, eerst mijn examens doen.

Voor 3 kleurensamples is dat nog te doen, voor 64 is het wat minder

madwizard wijzigde dit bericht 18-01-2006 14:54 (26%)

de optie die xandrios aanhaalt was ook wat ik in gedachten had tijdens het lezen van dit topic.
capacitor opladen met signaal (versterkt signaal/gebufferd signaal/whatever) en dan de leds/lampen aansturen adhv de spanning over de condensator.

dat is de goedkoopste en doeltreffendste oplossing imo.
Wil je het geavanceerder, dan kun je zorgen voor een systeem die links/rechts boven/onder kan onderscheiden door het voltage te "delen" door een factor afhankelijk van de locatie die je uit het sync-signaal haalt. dit vereist op z'n minst wat meer logica.

ik wil echter wel nog een andere aanmerking maken:
hetzelfde grijs is donkerder tov wit en lichter tov zwart. maw: kleurgewaarwording is afh van de omgeving. als je dus lichten/leds met eht foute spectrum gebruikt kan je serieus je beeldkwaliteit om zeep helpen. Ideaal zou dus zijn om je spectrum te meten met rood/groen/blauw beeld en dan lampen/leds te kopen met een overeenkomstig spectrum. natuurlijk is de doe-het-zelf test met lampen/leds + R/G/B-beeld ook wel voldoende.

quote:

madwizard schreef op woensdag 18 januari 2006 @ 14:51:
[...]
Voor 3 kleurensamples is dat nog te doen, voor 64 is het wat minder

64 kleursamples per horizontale lijn lijken me erg duur en ook enigzinds overkill.

quote:

naftebakje schreef op woensdag 18 januari 2006 @ 15:31:
64 kleursamples per horizontale lijn lijken me erg duur en ook enigzinds overkill.

Niet per lijn, in totaal per beeld. 8 horizontaal en 8 verticaal. Horizontaal analoog gemiddeld, verticaal over de lijnen heen digitaal.

quote:

madwizard schreef op woensdag 18 januari 2006 @ 11:51:
[...]

Volgens mij haal je nog veel minder pixels. Weet niet hoe je het aantal pixels hebt uitgrekend (hangt van je resolutie af) maar ik als volgt: Een beeldlijn is 64uS, waarvan 52uS zichtbaar. Op 500KHz samplen betekent 2uS per sample. Dat is 52/2=26 samples per beeldlijn. De ATmega's (iig de 88 en 8) kunnen niet alle kanalen tegelijk samplen, er wordt er steeds een geselecteerd. Dus die 26 moeten ook nog eens verdeeld worden over 3 kleuren, zodat je er max ~ 8 overhoud per beeldlijn.
Op zich genoeg als je het signaal eerst analoog middelt, dan heb je 8 gemiddelden per lijn. Alleen zit er dus wel een redelijke tijd tussen de samples waardoor het gemiddelde misschien te veel verschoven tussen de kleuren.

Als ik een beetje werkend iets heb wil ik het eigenlijk testen op VGA, omdat dat nou eenmaal (extra) uit m'n videkaart komt En het zou wel leuk zijn als het op zowel VGA als RGB uit SCART zou werken. VGA is alleen normaal gesproken 60Hz wat dus nog sneller gesampled moet worden.

Het beste is volgens mij toch een aparte ADC, bij voorkeur een die meerdere kanalen tegelijk kan samplen.

Volgens mij haalt zo'n atmel slechts 200kHz, en niet 500kHz. Je houdt dan nog maar 10 samples per beeldlijn over, dus 3 per kleur.
Omdat de atmel zo goedkoop zijn (E2,17) zou je ook 1 atmel voor elke kleur kunnen nemen. Deze kunnen elk dan één kleur voor hun rekening nemen. Een vierde atmel zou de drie kleuren weer kunnnen combineren en de ledjes / lampen aansturen. Als je dit alles in een doosje propt zou je het zelfs een quad-core atmel systeem kunnen noemen

quote:

TweakPino schreef op donderdag 19 januari 2006 @ 16:03:
Volgens mij haalt zo'n atmel slechts 200kHz, en niet 500kHz. Je houdt dan nog maar 10 samples per beeldlijn over, dus 3 per kleur.

200kHz voor z'n volledige resolutie ja, maar z'n maximum ligt geloof ik op 1MHz. Dan heb je minder resolutie maar ik denk nog wel voldoende. Er staat in de datasheet van de atmega8 '3 LSB' bij de specificaties op 1MHz, weet iemand wat dit precies inhoud? Betekent het dat de 3 laagste bits dan niet nauwkeurig genoeg zijn?

quote:

Omdat de atmel zo goedkoop zijn (E2,17) zou je ook 1 atmel voor elke kleur kunnen nemen. Deze kunnen elk dan één kleur voor hun rekening nemen. Een vierde atmel zou de drie kleuren weer kunnnen combineren en de ledjes / lampen aansturen. Als je dit alles in een doosje propt zou je het zelfs een quad-core atmel kunnen noemen

Tja dat is een idee maar het mooist is natuurlijk alles in 1. Ik ben toevallig een tentamen parallel programmeren aan het leren, dan krijg je vanzelf al ideeën over meerder controllers combineren

Ik denk trouwens dat als je de analoge schakeling zo maakt dat ie kan switchen tussen 2 buffers (condensators) het misschien wel haalbaar is met de interne A/D converter. Je zit dan niet met het probleem dat het meten van R, G en B te ver uit elkaar ligt. Qua tijd verandert er dan niets natuurlijk maar in ieder geval meet je de kleuren dan juist. Desnoods kun je nog per beeldlijn 4 samples doen om en om, en dan combineren tot 8.

Daarnaast zou het nog leuk zijn als ook HDTV ondersteund werd. Bij 720p zit je bijvoorbeeld met beeldlijnen van 27uS wat het allemaal nog lastiger maakt

Er is trouwens op IA.net een animocheck opgezet voor een digikey inkoopactie, dus als je nog ICs nodig hebt voor dit project is het handig even te kijken.

Hmm als ik het datasheet nog eens beter bekijk zie ik dat die 200kHz (of 500, max 1MHz) de klok is van de A/D converter maar het samplen minimaal 13 clockcycles duurt. Op 1MHz dus zelfs al 13uS .

Erg interessant project, ik vroeg me eigenlijk af wat de beste lichtbron was, en wat gebruikt Philips zelf eigenlijk?
CCFL's lijken me op het eerste gezicht het meest geschikt, maar in hoeverre zijn deze te dimmen. Het gebruik van LED's icm PWM lijkt me het makkelijkste, maar daar heb je weer veel LED's voor nodig, wat prijstechnisch gezien niet de beste oplossing is.

quote:

M-ThijZ schreef op donderdag 19 januari 2006 @ 21:43:
Erg interessant project, ik vroeg me eigenlijk af wat de beste lichtbron was, en wat gebruikt Philips zelf eigenlijk?
CCFL's lijken me op het eerste gezicht het meest geschikt, maar in hoeverre zijn deze te dimmen. Het gebruik van LED's icm PWM lijkt me het makkelijkste, maar daar heb je weer veel LED's voor nodig, wat prijstechnisch gezien niet de beste oplossing is.

Philips gebruikt CCFL's, deze zijn perfect te dimmen (PWM op de 12V voeding van de inverter). De eerste bedoeling lijkt me hier om ledjes (via PWM) aan te sturen, omdat die rechtstreeks op de meeste microcrontrollers kunnen gehangen worden. Als je die PWM ipv een ledje een FET laat aansturen, kan je er CCFL's mee aansturen.

Dit lijkt me wel een geschikt ding:
Texas Instruments THS10064

• 4 analoge inputs
• 10 bits
• Gelijktijdige sample & hold!
• 6 MSPS op 1 input, 2 MSPS op 3 inputs (6 / #inputs)
• Interne referentie van 1.5V of 3.5V.
• Parallele digitale output
• Ingebouwde 16 word FIFO buffer

Kost € 8,36 (digikey), valt op zich nog mee en dan heb je ook wel wat.

Denk trouwens dat er zowieso 2 controllers nodig zijn, een voor het aansturen van de A/D en het berekenen van de gemiddelden en 1 voor het algoritme dat de kleur bepaald. Dacht eerst dat het wel samen kon maar met dit soort sample snelheden heb je eigenlijk best heel veel cpu cycles nodig

madwizard wijzigde dit bericht 20-01-2006 16:51 (26%)

quote:

madwizard schreef op vrijdag 20 januari 2006 @ 16:50:
Dit lijkt me wel een geschikt ding:
Texas Instruments THS10064

• 4 analoge inputs
• 10 bits
• Gelijktijdige sample & hold!
• 6 MSPS op 1 input, 2 MSPS op 3 inputs (6 / #inputs)
• Interne referentie van 1.5V of 3.5V.
• Parallele digitale output
• Ingebouwde 16 word FIFO buffer

Kost ¤ 8,36 (digikey), valt op zich nog mee en dan heb je ook wel wat.

Denk trouwens dat er zowieso 2 controllers nodig zijn, een voor het aansturen van de A/D en het berekenen van de gemiddelden en 1 voor het algoritme dat de kleur bepaald. Dacht eerst dat het wel samen kon maar met dit soort sample snelheden heb je eigenlijk best heel veel cpu cycles nodig

hmm, dit is idd wel een mooi ding. Alleen jammer dat ie niet zo makkelijk te solderen is.

Drie atmels die elk een kleur samplen is trouwens wel mogelijk als je 4 samples ipv 8 per beeldlijn neemt. één sample duurt 13us, 4 samples dus 52us, precies evenlang als het zichtbare deel in een beeldlijn. Je zou dan van twee opeenvolgende beeldlijnen 4 samples kunnen nemen in plaats van 8 samples op één beeldlijn, zoals ik hieronder heb proberen te teken:

code:

8 samples per beeldlijn:

  0...0...0...0...0...0...0...0...


4 samples per beeldlijn

  0.......0.......0.......0.......
  ....0.......0.......0.......0...

quote:

TweakPino schreef op vrijdag 20 januari 2006 @ 20:41:
hmm, dit is idd wel een mooi ding. Alleen jammer dat ie niet zo makkelijk te solderen is.

Mja ik ben bewust een beetje over aan het gaan op SMD maar denk dat dit soort dingen in DIP ook veel lastiger te vinden is.

quote:

Drie atmels die elk een kleur samplen is trouwens wel mogelijk als je 4 samples ipv 8 per beeldlijn neemt. één sample duurt 13us, 4 samples dus 52us, precies evenlang als het zichtbare deel in een beeldlijn. Je zou dan van twee opeenvolgende beeldlijnen 4 samples kunnen nemen in plaats van 8 samples op één beeldlijn, zoals ik hieronder heb proberen te teken:
[...]

edit: Zag te laat dat je 'drie atmels' zei , nouja dit was m'n post :p:
Dat is ook wat ik in gedachte had, maar je vergeet dat je 3 keer zoveel samples moet nemen, 1 voor elke kleur. Er zit een multiplexer aan de ingang die een bepaald kanaal selecteerd. En zelfs al zou je het dan redden zou je een sample & hold achtig iets moeten maken om de kleuren ook op hetzelfde moment te meten (of in ieder geval de samplen). Het IC dat ik noemde kan niet alleen veel sneller samplen maar heeft ook een sample & hold voor elk kanaal, waardoor ze dus altijd op hetzelfde moment gesampled worden (alleen niet verwerkt, het duurt evengoed nog 3x zo lang voor 3 kleuren, maar op 6 megasamples is dat te doen).

Verder wilde ik ook letten op andere standaarden die nog sneller zijn, zoals VGA en HDTV.

madwizard wijzigde dit bericht 20-01-2006 20:54 (5%)

Als je idd ook rekening wilt houden met VGA en HDTV dan valt de atmel al gauw af en kom je bij de THS10064 uit.

Ik heb ook nog even bij microchip gekeken of zij nog een handige pic hadden. De dsPIC30F2010 heeft net als de THS10064 een gelijktijdige sample en hold voor 4 kanalen. Helaas haalt de AD omzetter 'slechts' 500ksps. Het voordeel van deze PIC is dat hij wel beschikt over 3 PWM units om lampen / leds aan te sturen.

oud, i know maar ik wil dit project wel zien werken, dus een subtiele voet.

Ik zat rond te kijken op spam, en kwam dit tegen: http://www.voti.nl/winkel/catalog.html?IC-TDA8703-DIP
is die niet aan een PIC te hangen?
Ze zijn niet goedkoop nee, maar wel snel genoeg?

Canule wijzigde dit bericht 06-03-2006 21:05 (4%)