Bertus
-
Aantal items
107 -
Registratiedatum
-
Laatst bezocht
Alles dat geplaatst werd door Bertus
-
Er gaat een spreekwoord rond in electronica in de trend van: "The best chip is the one you have in stock." 😉 Het voordeel om 74HC00 (NAND) te gebruiken is omdat het net zoals NOR een universele gate is. Je kunt er dus elke andere gate mee maken. Een inverter is beperkter, maar komt met het voordeel dat je er 6 op 1 chip hebt (74HC04) versus 4 voor een 74HC00. Bij een schema probeer ik het aantal chips te minimaliseren, maar wel bij de gangbare chips te blijven. Soms is er een voordeel door te inverteren met NAND gates omdat je die gates toevallig nog 'over' hebt in je schema. Hetzelfde geldt voor NOR gates. In het specifieke geval waar je naar refereert heb ik al een revisie gemaakt (zie mijn vorige post met .pdf en de .svg bestanden) en daar gebruik ik nu 1x74HC32 (4xOR), 1x74HC00 (4xNAND) en 1x74HC04 (6xNOT). Het kan best dat het nog eenvoudiger kan met mindere of andere chips, dus voel je vrij om mee te puzzelen! Om even het absurde op te zoeken: ik zou de 00, 04 en 32 nog kunnen vervangen voor bijvoorbeeld een EECPLD zoals de ATF16V8B-15PU omdat de timing niet heel kritisch is (de chip heeft een tpd van 15 us, wat genoeg zal zijn voor de P2000T), maar dat zou ik dan weer persoonlijk een brug te ver vinden. Die chip is niet eenvoudig en behoeft een flasher. Meestal proberen we binnen de 74' serie blijven en dan specifiek die chips die nog actief geproduceerd worden.
-
Als je de 688 en de tweede 62256 weglaat dan heb je een karige 24k uitbreiding. (Edit: dit klopt niet; zie bericht van cancom hieronder)
-
Vanaf wanneer moeten we ons gaan schamen? Enfin, nog een poging aan mijn zijde voor dit puzzelwerkje: Als A13 en A14 beiden niet hoog zijn, dan zit je op de eerste 16kb van chip 1. (CS1/=0; A14_1 = 0; A13_1=A14) Als A13 en A14 hoog zijn, dan zit je in banked geheugen ($E000-$FFFF). Wanneer S1 en S2 beiden laag zijn, dan zit je op het chip 1 (CS1/=0; A14_1 = 1; A13_1=S0), anders op chip 2 (CS2/=0). Op chip 2 kunnen we A13_2 = S0 en A14_2 = S2 zetten om 2-5 te mappen op 0-3. Goed punt; die andere poorten ga ik niet snel gebruiken. Echter zoals je al correct vermoedde: Die 688 zit op 41 cent en 4 extra boorgaatjes kost niets extra's want je betaalt tegenwoordig 1 euro per PCB (bij afname van 5) ongeacht het aantal gaatjes. Ik gebruik trouwens meestal THT componenten, tenzij ik echt geen plaats heb of heel erg veel zin heb om met mijn oude bankpasje soldeerpasta door een sjabloon te strijken. Ik zie geen instelling in Kicad om die resolutie aan te passen dus ik had een vector-PDF gemaakt en die met Photoshop omgezet naar een .png. In Photoshop gaf ik 300dpi aan en ik heb een .png van 3315 x 2265 pixels. Leek me groot genoeg, maar ik weet niet wat het forum doet met plaatjes. Misschien worden die weer gedownsampled? Zal ik .svg en .pdf eens proberen dan maar? Beide vectorformaten die je "oneindig" kunt inzoomen. Hoop dat dit goed voor je werkt. p2000t-ram-expansion-board.svg p2000t-ram-expansion-board.pdf
-
Zo gaan die dingen. 🙂 Terwijl ik beide schema's aan het bestuderen was kwam ik ook al op die conclusie uit. Ik heb een revisie gemaakt van mijn schema (en me laten inspireren door ook een 74HC158 te gebruiken). Ik kom hier op uit: Op basis van A14 toets je dus eerst of de adresbus tussen A000-DFFF zit. Indien zo, dan zit je in de eerste 16kb en moet A13 direct op de A13_1. Staat de adresbus op E000-FFFF, dan is A14 hoog en moeten we kijken of we op chip1 of op chip2 moeten zitten. Dan kan door S1 en S2 te toetsen. Als tenminste een van beide hoog is, dan zit je op chip 2, anders op chip 1. Op basis van die logica kun je een ~CS1 en ~CS2 signaal bouwen. Tenslotte moeten de adreslijnen A13_1, A14_1, A13_2 en A14_2 nog gekoppeld worden op A13, S0, S1, en S2, maar dat gaat allemaal via een enkele 74HC157. NB: Ik heb S0 en S2 respectievelijk op A13_2 en A14_2 gekoppeld via de HC157, maar dat is strict genomen niet nodig. @cancom Klopt mijn redenatie of zie ik nog iets over het hoofd?
-
Als het goed is zou de PDF een vector-afbeelding moeten bevatten, dus dan kun je zover inzoomen als je wilt. Voor de PNG heb je gelijk, daar moet ik even op de resolutie letten. Ik hoop dat ik het nu beter heb gedaan. (300 DPI, maar je moet wel nog steeds op het plaatje drukken om hem groot te maken) Goede vraag. Ik was onder de aanname dat die 40-pin expansion board header geen (stabiele) 5V had. Ik had mijn ontwerp gebaseerd op het ontwerp in de P2000GG nieuwsbrief (1-7; blz 58) en daarin haalde men alles vanaf het moederbord. Wat is die DISA (D in FSM) pin eigenlijk? Op basis van onderstaand diagram van de Z80 ging ik ervan uit dat eerst de adreslijn stabiel wordt gemaakt en dan pas het ~MREQ signaal wordt gegeven. We krijgen dus exclusief toegang tot de databus wanneer ~MREQ laag is. Op alle andere momenten zijn de chips inactief. De ~IOREQ timing ziet er overigens vergelijkbaar uit. Weinig chips gaat het hem sowieso niet worden, maar de chips zijn heel goedkoop tegenwoordig dus dat is niet echt een beperking. Onafhankelijk van jou had ik onderstaand diagram gebouwd, maar ik vind de bank logics via 3x74HC157 een heel stuk eleganter dan mijn oplossing met al die gates. Ik ga alles nog een keertje doorspitten en dan maar eens een proef-PCB'tje bestellen.
-
Ik dacht dat ik hem met voldoende resolutie had geëxporteerd. Je kunt op het plaatje klikken en dan wordt hij vergroot in je browser geopend. Desalniettemin: ik heb hier ook een download link voor de PDF welke je heel ver kunt inzoomen: https://www.dropbox.com/scl/fi/t6dhlmnuyb13zmxagfe9i/p2000t-ram-expansion-board.pdf?rlkey=ab8gcy0ecogt94enopx6it52r&dl=0 Ik hoop dat dat zo fijn voor je werkt. Je hebt helemaal gelijk dat die 62256 supergoedkoop zijn (2,14 euro per stuk). Wat zou je voorstel dan zijn qua schema als ik er twee zou gebruiken?
-
Ik ben me aan het verdiepen in het bouwen van een RAM expansion board met moderne chips. Op basis van het field-support manual kwam ik op het volgende schema uit (zie afbeelding). Naar ik heb begrepen zitten er op dit forum een paar befaamde componentenbouwers en ik zou graag hun input eens horen of dit schema zou kunnen werken. Samengevat: ik koppel een 32kb static ram chip op data en adrespoorten. Middels ~MRQ (memory request) en RAMS2 wordt deze chip uit de low-impedance modus gehaald via ~OE. ~RD en ~WR lijnen zijn direct op deze chip gekoppeld. De onderste 16kb zitten gekoppeld op 0xA000-0xDFFF. De bovenste 16kb moeten aangeboden worden via bank switching. De bank switch kan bepaald worden door een bit op D0 te schrijven naar poort 0x94. Dit laat ik via een flip-flop gebeuren, die 0x94 op de adresbus uitleest (via o.a. een dual quad-AND gate en 5 inverters) tezamen met ~IORQ. Dit geeft RAMSW als uitvoer. Door middel van een multiplexer (U6) wordt A13 vanuit de adresbus doorgeschakeld naar de ram chip als A14 laag is (wanneer je dus A000-DFFF benadert). Wanneer A14 hoog is (wanneer je dus E000-FFFF benadert), dan bepaalt RAMSW of je het laagste of hoogste 8kb segment van de bovenste 16kb op de RAM chip benadert.
-
@blanka Wat mij verteld werd was dat hij een aansluiting had gebouwd op zo'n LED lichtkrant. Ik weet er het fijne niet van, maar volgens werken die led-bakken met een simpel protocol dus het lijkt me niet onredelijk dat je dat aan kunt sturen met je P2000T. Ik was in de veronderstelling dat dat lichtkrant programma enkel een lichtkrant op het scherm projecteert.
-
Wat zie je dan precies? Ik heb het spelletje zelf zonder problemen kunnen spelen. Ik was zelf positief verrast dat het allemaal net past op een 16kb versie. Het spelletje neemt 14619 bytes in beslag en wordt geplaatst vanaf (ik gebruik even voor het gemak hex-notatie) 0x6547. Je vult dan alles van 0x6547 + 0x391B = 0x9E62. Je zit dus net onder de stack pagina en ik neem aan dat er ook nog variabelen ergens opgeslagen moeten worden.
-
Deze stond op een tape die ik bij een P2000T had gekocht. De vorige eigenaar had een eigen zaak (een snackbar) en was een computer-enthousiast. Hij vertelde dat hij de P2000T ook gebruikte voor het aansturen van een lichtkrant. Enfin; kan er niet heel veel over vertellen. Alle bestanden hebben ook een 'AVR' extensie waarvan we ook nog niet duidelijk hebben wat die precies zijn en de tapes beginnen allemaal met een '?-index' bestand.
-
Compilatie voor Ubuntu werkt in ieder geval als een zonnetje. Instructies vallen hier te vinden: https://github.com/ifilot/p2000t-tape-monitor/tree/master/gui Het zit inmiddels ook ingebakken in de Github Actions procedure (CI/CD), dus wordt bij elke nieuwe commit ook telkens getest dat het valt te compileren onder Ubuntu. Zie bijvoorbeeld: https://github.com/ifilot/p2000t-tape-monitor/actions/runs/6486774883/job/17615657820
-
Ik verwacht geen enkel probleem om dit te compileren op Linux. De Windows variant op Github Actions wordt zelfs op een Linux distro gecross-compiled voor Windows. Alles zit volledig in Qt en Qt doet zelf de juiste kernelinstructies per OS uitrollen. Welke distro heb je precies? Ik kan eventueel voor je uitproberen.
-
Ik zit ook in die situatie. Ik heb in het verleden wel PM rechten gehad, maar volgens mij moet je nu 50 posts daarvoor hebben om te mogen versturen. Ik kan wel ontvangen. Enfin, zou ik ook PM-toegang mogen hebben?
-
Mooi om al deze ontwikkelingen te zien op dit forum. Ik heb zelf ook weer een nieuwtje om toe te voegen. Ik heb een cartridge gebouwd voor SLOT2 waarmee je .CAS kunt inladen en kunt opstarten. In de cartridge zit een 128kb ROM met de firmware om programma's op te starten en aan de achterzijde zit een 512kb ROM om .CAS bestanden op te zetten. Ook zit er een 32kb RAM chip in de cartridge, maar die acteert niet als een expansie van het RAM geheugen van de P2000. De ROM chip heeft zijn eigen bestandssysteem (een soort hybride systeem tussen FAT en wat de P2000T zelf gebruikt) en er is in totaal plaats voor 480 blokken van 1kb, waarbij elk blok 64 bytes aan metadata bevat. In de metadata staat o.a. een CRC16 checksum om te kunnen controleren of het overzetten goed gaat. De blokken hoeven niet achter elkaar te staan, dus als je een programma verwijderd van de cartridge, dan hoef je niet te 'defragmenteren'. Om programma's toe te voegen of te verwijderen heb ik een simpele GUI geschreven. Deze GUI maakt gebruikt van de PICO Flasher welke ik al eerder op dit forum heb geïntroduceerd. Programma's overzetten vanaf de tape naar de chip is mogelijk, maar is op dit moment nog niet erg gebruiksvriendelijk. Dat wil ik nog verbeteren. Ook programma's wegschrijven vanaf de cartridge naar een tape staat op de verlanglijst. De cartridge werkt niet op zichzelf en je hebt een aangepaste BASIC cartridge nodig. Die zit in SLOT1. Bij het opstarten wordt een stukje firmware van de 128kb ROM chip gekopieerd naar het RAM geheugen van de P2000T en dat wordt opgestart. Dat stukje firmware leest de SLOT2 cartridge uit en toont de bestanden op het scherm. De gebruiker kan het gewenste programma selecteren (elk programma heeft een index) en het programma opstarten. Bij het opstarten wordt het gewenste programma op de juiste positie gezet voor BASIC programma's en vervolgens wordt het 'RUN' commando aangeroepen via een call routine. Wanneer je op reset drukt kun je makkelijk terugkeren in het keuzemenu. De broncode, schema's, STL voor de enclosure, installers voor de GUI, en (nog beperkte) documentatie tref je hier aan: https://github.com/ifilot/p2000t-tape-monitor Voor een impressie, zie ook onderstaand filmpje (sorry dat het aardappel-kwaliteit is, ik ben geen cameraman.) https://www.youtube.com/watch?v=oFVSTNTA5YM Ik heb op dit moment nog vier printplaatjes over (vijf besteld, eentje voor mezelf), dus als iemand interesse heeft om met deze cartridge uit te proberen en mij van gebruikersfeedback te voorzien, neem even contact met me op. Je hebt naast de data cartridge, ook een programmeerbare SLOT1 cartridge nodig (bijv. mijn ZIF-cartridge) en een PICO flasher.
-
Ik heb even een snel scriptje geschreven want er is een chronisch tekort aan monniken met ICT kennis. Op dit moment hebben 81/ 198 CAS bestanden in het archief een ongeldige header (om een of meerdere redenen). Ik zal het scriptje uitbreiden om op nog wat andere zaken te toetsen en dan toevoegen via een PR. Headers repareren is an sich niet zo moeilijk.
-
Mooi werk @dionoid!!! Ik zou bijna voorstellen om dit gewoon uit te rollen voor alle CAS bestanden en de nagenoeg random data in de header-secties te wipen (alles buiten 0x30 - 0x4F). Ik zou voor het vergelijken van bestanden de header secties niet volledig negeren. Ben het met je eens dat het nut van die headers beperkt is, maar bijvoorbeeld 0x4F neemt af per blokje en op z'n minst zou je de andere 'metadata' (programmalengte e.d.) minstens een keer willen meenemen in het vergelijk. Je kunt het scriptje voor de cartridges eventueel recyclen voor de .cas bestanden. Nog een voorstel: we zouden de controle van de .cas bestanden en de .bin bestanden (cartridges) kunnen opnemen in Github actions. Bij elke commit kunnen we dan toetsen of alles uniek is. Je zou zelfs per commit automatisch een overzichtlijstje kunnen uitrollen.
-
Het programma gebruikt fopen en niet _wfopen. Als je die laatste gebruikt kun je inderdaad UTF-16 bestandsnamen gebruiken. Ik ben niet thuis in Java, maar kan goed zijn dat de JVM meteen koppelt op de 'wide char' functies. De discussie doet me eraan denken dat we tegenwoordig ook emoticons kunnen gebruiken in bestandsnamen, maar dan blijft de vraag resteren of we dat zouden moeten willen. 😅
-
@w2510a had nog een aantal cartridges die nog niet in het P2000 Preservation Project stonden. Hij was zo vriendelijk om een dumpje van de ontbrekende cartridges te maken welke ik nu via een pull-request heb aangeboden voor het project. Zodra @dionoid de pull request (PR) accepteert (indien naar tevredenheid natuurlijk), dan zijn op de PPP de volgende extra cartridges te vinden: BASIC 1.0 in het Engels Bildschirmtext Text 1 in het Duits Text 2 in het Duits Maintenance (deze maintenance wijkt met een paar bytes af van "Maintenance 1", dus ik heb hem maar voor de volledigheid toegevoegd) In de tussentijd kunnen de nieuwe cartridges in mijn fork gevonden worden (na acceptatie van de PR verwijder ik deze tekst) https://github.com/ifilot/p2000t-software/tree/additional-cartriges/cartridges
-
Klopt, maar er zou ook een EOT geschreven moeten worden op de cassette. Heb je het stopje erin zitten? Uitleg: Op adres 0x0018 begint de machinecode voor de cassette. Via DEF USR=&H18 wordt een pointer gezet naar dat adres. Wanneer je ?USR(1.1) aanroept dan wordt 1.1 als een single precision float weggeschreven naar adres 0x650D en bevat HL een referentie naar dat adres. We gebruiken dit getal overigens verder niet (HL wordt overschreven met de waarde van het transfer adres). De waarde in de accumulator wordt echter wel bepaald door het type argument en voor een single precision float is dat een 4. Wanneer 0x0018 aangeroepen wordt met 4 in register A, dan wordt het vijfde adres (tellen vanaf 0) van de cassette jump table aangeroepen die wijst naar de EOT-schrijf functie die je nodig hebt. Zie ook de volgende regels in de monitor code: * Effect van waarde in a: https://github.com/p2000t/documentation/blob/master/programming/Monitor Documented Disassembly/Symbols.asm#L212 * Effect van waarde in register A op de jump table: https://github.com/p2000t/documentation/blob/master/programming/Monitor Documented Disassembly/Cassette.asm#L28 * Start van de EOT schrijf functie: https://github.com/p2000t/documentation/blob/master/programming/Monitor Documented Disassembly/Cassette.asm#L1707
-
Volgens mij refereert @cancom naar een handgeschreven opmerking op pagina 34: van https://download.homecomputer.museum/Files/Philips/P2000T/Documentation/P2000T.pdf. (zie afbeelding) De monitorroutines werken natuurlijk ook. Als je het vervelend vindt om een serie 'pokes' in BASIC uit te voeren kun je ook de instructies via Zemon inkloppen en eventueel de machinetaalinstructies op een (ander) bandje opslaan. Tenslotte heb je ook nog een "cassettehulp" programma met wat handige utilities. Ik kan me niet herinneren of die je toetstaat om specifiek het laatste bestand te wissen, maar wellicht de moeite waard om daar eens naar te kijken: https://github.com/p2000t/software/blob/master/tapes/utilities/Cassettehulp%2B.cas
-
Ik zag je commits en de pull request inderdaad al tegenkomen. Knap gedaan allemaal. Men is inderdaad heel strict qua integratie bij mame-dev. 😅
-
De commit historie van MAME suggereert dat de P2000T emulator geport is vanuit MESS (ergens in 2012): https://github.com/mamedev/mame/blob/7285b359d259b2ae0fdf85096571c386ec8c991a/src/mess/drivers/p2000t.c Verder doorgraven in de MESS-svn laat zien dat de eerste commit van de P2000T broncode door de maintainer van MESS is geplaatst (ergens in 2007): https://github.com/mamedev/mess-svn/blob/50516e2f0095095fc28f569c0db3176012579447/src/mess/drivers/p2000t.c Deze forumpost doet suggereren dat de user met de nickname "The Wiz" de auteur van die code is: https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=33117 Ik kom met die nickname echter niet verder. Dit document suggereert dat "Paul Daniels" de auteur is, maar het zou ook een maintainer of een contributor kunnen zijn: https://github.com/mamedev/mess-svn/blob/master/docs/messnew.txt#L12208 Als ik de broncode van beide emulatoren vergelijk, specifiek de Z80 emulatie, dan ziet dat er wezenlijk anders uit. Zie bijvoorbeeld: https://github.com/CodeAsm/M2000/blob/main/Z80.c https://github.com/mamedev/mess-svn/blob/d1714d79dcb4e1f671c2ba92c86b544b5d6d8c7f/src/emu/cpu/z80/z80.c
-
I am sure I can help you out. 😉 Due to the "minimum of 50 posts" restriction on the forum, I cannot (yet) send any direct messages. Can you share some contact details so I can reach out to you? edit: Or contact me on Marktplaats, that is fine as well.
-
Ik weet niet of dit je veel gaat helpen, maar op x64 architectuur zal een operatie met 64-bit integers in de regel resulteren in een optcode met 64 bit registers; een 64 bit integer operatie dus. Afhankelijk van de programmeertaal die je gebruikt, welke variabelen je daarin declareert en de bibliotheek waartegen je aan compileert kan dat een 32bit integer zijn. In C++ is de de-facto integer op een 64 bit systeem LP64, dus 64 bits per integer. Op 32 bit systemen is dit ILP32, dus 32 bit. Wil je 8 bit operaties afdwingen, dan kun je ervoor kiezen om 8 bit variabelen te declareren. In C++ heb je bijvoorbeeld de familie uint8_t, uint16_t, etc. Wat er daadwerkelijk onder de motorkap gebeurd is niet gegarandeerd en wordt bepaald door je compiler. Soms worden er daadwerkelijk 8 bit operaties gedaan, maar het kan ook dat als je meerdere van daar soort operaties in een for-loop hebt, dat je compiler dan SIMD parallellisatie uitvoert. Als je wilt weten wat je compiler ervan maakt, dan kun je ervoor kiezen om de gegenereerde assembly uit te lezen. Als je 100% controle over je operaties wilt behouden, dan kun je ervoor kiezen x64 assembly te schrijven (of de x86 assembly voor 32 bit systemen). Als je beter begrip wilt hebben over de interne werking van de Z80 kun je een emulator gebruiken zoals onderstaande. Deze laat netjes het flag register zien en je kunt stappen per cyclus of per instructie maken: https://floooh.github.io/visualz80remix/ Als je in deze emulator de machineinstructies 3E 80 C6 81 intypt (LD A,128 ; ADD 129), en de rest op 00 (NOP) zet en doorspoelt, dan kun je kijken naar het resultaat in het flag register. Deze is szyhxVnC, dus overflow en carry zijn allebei gezet. Stel je pakt LD A,128, ADD 128, dan worden naast overflow en carry, ook nog eens zero en half-carry gezet. Edit: Er schiet me nog iets te binnen: Je kunt natuurlijk ook helemaal all-in retro gaan en op je P2000T met Zemon dit uitvogelen. Je kunt weliswaar niet direct het flag register naar een ander register overzetten, maar wel indirect via de stack. Je zou dus na een operatie van interesse 'af' naar de stack kunnen duwen, dan eraf halen in 'bc' en vervolgens de waarde van het flag register in je accumulator stoppen waarna je ermee kunt doen wat je wilt (bijvoorbeeld wegschrijven als een string). push af pop bc ld a,c
-
Goed nieuws. De ROM flasher is zover af dat ik hem graag de deur uit stuur om door geïnteresseerden te laten testen. Ik heb een GUI in Qt geschreven om (hopelijk) makkelijk met de flasher te interfacen. Daarbij heb ik ook een bijbehorende cartridge ontwikkeld met een ZIF socket op de achterzijde (zie foto). Daarmee kun je de ROM chip inserteren zonder dat je de cartridge hoeft open te maken. Aan de voorzijde van de cartridge zit een piano-type dip switch om de bank te selecteren. Een paar kanttekeningen: De GUI is ontwikkeld in Qt op Windows. Zover ik kan zien werkt deze out-of-the-box maar ik raad geïnteresseerden desondanks aan om eerst even te testen of de GUI werkt voordat je overweegt om het in gebruik te nemen. Ik heb zelf beperkte ervaring met Mac en ik gebruik een kant-en-klare MacOSx image in Github actions om de GUI te compilen voor Mac. Deze compilatie werkt op MacOSx versie 11 en nieuwer, maar niet op de oudere MacOSx versies. Wederom; als je enkel een Mac systeem hebt, test dan even de Mac GUI voor gebruik. @blanka heeft de flasher zelf getest voor MacOSx (dus niet de GUI) en dat werkt zonder problemen. De flasher gebruikt een simpel UART protocol voor de communicatie en Blanka heeft daar zelf iets voor geschreven in Java. Je kunt met deze flasher ook de ROM in de zwart-oranje cartridge herprogrammeren. Je moet daarvoor de cartridge wel openmaken. Tevens heb je een adapterplaatje nodig voor PLCC32 naar DIP (heb ik inmiddels ook gemaakt). Het herhaaldelijk open- en dichtschroeven kan echter wel het plastic beschadigen zodat de schroef niet meer goed hecht. Ik heb daarom een herziene versie van de enclosure (doosje) gemaakt met threaded inserts die dit probleem oplossen. @RoykeA en @Bekkie; ik stuur jullie een DM voor e.e.a. verder af te stemmen. Edit: Blijkbaar heb ik nog niet genoeg "forum-credits" om (nieuwe) DMs te sturen. Dus willen jullie mij benaderen?
