Hallo Habe ein bisschen in der Wikipedia über alte Gamekonsolen gestöbert. Beispielsweise das NES, die erste Konsole (?) von Nintendo CPU: 8bitter auf 1.77 MHz RAM: 2 kB Auflösung: 256 x 240 Pixel, 25 aus 53 Farben gleichzeitig Video-RAM: 2 kB Mir ist ein Rätsel, wie die mit dieser Hardware die Grafik hinkriegen können. 256 x 240 Pixel mit 25 Farben pro Pixel belegen mindestens ca 38 kB - das NES hat gerade mal 2 kB Video-RAM. Mit Echtzeit-Berechnung der Bilddaten dürfte auch nix sein - immerhin liegt der Pixeltakt bei 4.9 MHz. Wie, wie bloss kriegen die das hin? Gruss Michael
Die alten Gamekonsolen haben alle einen Videoprozessor, meistens funktionieren die nur mit Sprites. Man ist also nicht darauf angewiesen, immer das ganze Bild im Speicher zu haben. Gruß, Feadi
> Die alten Gamekonsolen haben alle einen Videoprozessor, meistens > funktionieren die nur mit Sprites. Man ist also nicht darauf angewiesen, > immer das ganze Bild im Speicher zu haben. Ja, aber die Sprites müssen ja auch irgendwo gespeichert werden - zählt dieser Speicher etwa nicht zum Videoram? Die 64 beim NES darstellbaren Sprites belegen immerhin auch schon ungefähr 5 kB. Und für dieses Bild braucht man wohl definitiv mehr als 64 dargestellte Sprites: http://forum.romov.net/files/yo__noid_nes_screenshot2_311.jpg
Wenn der Prozessor nichts besseres (nebenbei) tun muß, als ein paar Bytes in der Gegend herumzuscheiben, dann kann auch ein 1,77MHz Prozessor sowas machen. Bei der Grafikdarstellung wurde ein Grafikchip dafür benutzt, aus den Informationen im (Grafik-)RAM z.B. ein FBAS-Signal zu erzeugen. (Für den APPLE ][ gab es eine PAL-Grafikkarte - der Kerl konnte von Haus aus nur NTSC - die aus einem LM1886 und einem LM1889 und etwas Hühnerfutter bestand...) Sprites sind ja eigentlich auch nichts anderes als Datenfelder. Verknüpft man die per XOR mit dem Hintergrund, dann kann man sie setzen, noch eine XOR-Verknüpfung, und sie sind wieder weg. Das "Scrollen" ist auch nichts anderes als Bytes durch die Gegend zu schieben bzw. die Startadresse der auszugebenden Daten zu verändern.
Angehängte Dateien:
-
gitter8x8.PNG
221 Bytes
http://en.wikipedia.org/wiki/Nintendo_Entertainment_System Hier stehts: "PPU external memory (Video RAM): 2 KiB of RAM for tile maps and attributes on the NES board and 8 KiB of tile pattern ROM or RAM on the cartridge (with bankswitching, virtually any amount can be used within manufacture cost)" Es sind insgesamt also 10 kB VideoRAM/ROM.
Angehängte Dateien:
-
bild3.PNG
5,2 KB
Leg mal das Gitter auf das Bild, dann kannst Du sehen wie wenig (verschiedene) Kacheln da eigentlich sind. Gruß, Feadi
Kennt jemand eigentlich einige Links zu selbst gebauten Spielkonsolen? Mir ist aufgefallen das eigenbau Spielkonsolen mit wechselbaren Spielen doch sehr selten sind. Hat das einen grund? Habe mal ein Systhem gesehen was 3 spiele eingebaut hatte, aber das waren nur diese "Ping Pong Strich Spiele" (soll nicht abwertend gemeind sein, ist bestimmt sehr schwer sowas zu bauen und zu programmieren)
Ein besonders eindrucksvoller Vertreter der Kategorie "Ping Ping Strich Spiele" ist auf http://www.cyberniklas.de/pongmechanik/ zu sehen. Man beachte, daß es ganz ohne Prozessor, Speicher oder andere Halbleiterelemente auskommt.
> Kennt jemand eigentlich einige Links zu selbst gebauten Spielkonsolen? Hab selbst mal was gebastelt: http://www.thinkcool.ch/index.php?content=cgen;id=32;team=technik (Doku ist ziemlich ausführlich) Zurzeit arbeite ich an einer Farbgrafik-fähigen Konsole - genau deswegen bin ich ja auch auf den Thread hier gekommen. Hab mal ein bisschen die alten Gamekonsolen mit meinem groben Entwurf verglichen, und kam mir dann ein bisschen dumm vor :-) Naja, mal sehen, was ich von den angesprochenen Ideen so alles in mein CPLD kriege... > Leg mal das Gitter auf das Bild, dann kannst Du sehen wie wenig > (verschiedene) Kacheln da eigentlich sind. Ja schon - aber es sind sicherlich mehr als 64 gleichzeitig dargestellt. Und z.B. für Textausgabe werden es dann doch einige verschiedene. Und kann der Grafikprozessor tatsächlich in Echtzeit aus den Sprites und ihren Koordinaten ein Videobild zusammenschustern? Also die CPU mit 1.77 MHz schafft das bei einem Pixeltakt von knapp 5 MHz auf gar keinen Fall auch nur ansatzweise!
@gonzoo: Ich verstehe das auch nicht ganz: Ein ARM7 mit Color-LCD und einem 64kiB EEPROM (seriell) sollte schon eine schöne Spielekonsole geben. Mir fällt aber auch nicht wirklich ein, wonach man suchen könnte um solche Projekte zu finden. Gruß, SIGINT
> Also die CPU mit 1.77 > MHz schafft das bei einem Pixeltakt von knapp 5 MHz auf gar keinen Fall > auch nur ansatzweise! Das macht die CPU ja auch garnicht, dafür ist die PPU da. Hast Du Wikipedia zu dem Thema nicht richtig gelesen? Hier nochmal den Link: http://en.wikipedia.org/wiki/Nintendo_Entertainment_System "PAL version, named RP2C07, runs at 5.32 MHz and outputs composite video" Die PPU läuft mit 5.32 MHz. "PPU internal memory: 256 bytes of on-die sprite position/attribute RAM ("OAM") and 28 bytes of on-die palette RAM" In der PPU selbst werden die Sprites definiert. Gespeichert sind diese entweder in den 2 kB VideoRAM, oder in der gamecartridge "PPU external memory (Video RAM): 2 KiB of RAM for tile maps and attributes on the NES board" In diesem VideoRAM liegt eine (oder mehrere) 'tile map' (Kachel-Karte), die das zu generierende Bild beschreibt. Kacheln kann das Ding so viele verarbeiten wie in den Speicher passen, nur die Sprites sind auf 64 limitiert. Der Unterschied zwischen Sprites und Kacheln (tiles) ist recht minimal. Eigentlich ist beides das gleiche, aber die Sprites haben Fähigkeiten die die Kacheln nicht haben. Dafür sind die Sprites auf 64 limitiert. Gruß, Feadi
sowas hier? http://www.embeddedartists.com/products/boards/lpc2104_pro002.php .. hätte da fast mitgemacht :-)
nochmal eine andere console (ziemlich genial, da mit propeller-chip, dh. 8 cores): http://en.wikipedia.org/wiki/Hydra_Console http://www.parallax.com/detail.asp?product_id=32360 http://www.xgamestation.com/ :-)
Wobei man sich dann imho schon fragen muss, warum man nicht einfach einen 486er vom Schrottplatz programmiert, der kann das Gleiche, kostet nix und ein größeres Publikum für die Spiele hat man auch.
> Wobei man sich dann imho schon fragen muss, warum man nicht einfach > einen 486er vom Schrottplatz programmiert, der kann das Gleiche, kostet > nix und ein größeres Publikum für die Spiele hat man auch. Naja, dann am besten gleich DirectX oder Flash, dann kanns jeder auf beliebiger Hardware spielen... Dieses Frage muss sich jeder in einem technisch-kreativen Hobby mal stellen: Was will ich selbst tun, wo will ich Eigenleistung erbringen und was kaufe ich mir eben. Alles schafft man nicht - weder vom Know-How, noch von der Zeit. In meinem Fall geht es darum eine einfache Game-Hardware zu entwickeln - nicht jedoch darum, ein Game zu schreiben und zu verbreiten.
Im Hobby ist ja alles erlaubt, aber ich frage mich desöfteren, warum man sich so einer Materie widmen sollte. (Sorry vorab an jene, deren Schlips gleich Fußspuren aufweist) Der Aufwand, Hardware zu realisieren die bei weitem nicht mit einem modernen Handy mithalten kann ist enorm - ohne daß dabei etwas wirklich neues realisiert wird... ...im Gegenteil - voller Stolz weiden sich die Augen des Entwicklers an der entstandenen Grafik, die 1981 (wohlgemerkt vor 26 Jahren) Spielhöllenstandard war. (Referenz: DonkeyKong http://www.klov.com/game_detail.php?letter=&game_id=7610) Natürlich ziehe ich meinen Hut vor jedem, der solches aus einem Mikrocontroller herausholt, aber gleichzeitig nähert sich mein kreisender Zeigerfinger der freigewordenen Fläche ;-)
@antworter: Schon mal folgenden Spruch gehört? : "Der Weg ist das Ziel" Meistens ist das Ergeniss nur nebensache... es geht darum den Umgang mit der Technik zu lernen. Zudem bekommt man das Gefühl selbst was geleistet zu haben... warum glaubst du gibts so viele Heimwerker?! Preiswerter kommt man in den seltensten Fällen weg: Wenn ich mir z.B. ein ARM7-Board bauen möchte auf dem Linux läuft, dann komm ich da nicht unter ca.80Euronen dran. (Platinen, ARM7, FLASH,RAM,etc. ) Einen preiswerten Router mit Linux als BS bekomm ich bei E-Pay für ca. 40 bis 60 Euronen. Eigenbau lohnt sich in fast allen Fällen nur,wenn ich Funktionen benötige die kein Gerät so leistet. Oder wenn die Funktion halt nebensache ist. Gruß, SIGINT
@Mr. Chip: > In meinem Fall geht es darum eine einfache Game-Hardware zu entwickeln - > nicht jedoch darum, ein Game zu schreiben und zu verbreiten. Das hatte ich nicht gemeint, Projekte mit Controllern, bei denen man wirklich was an der Hardware baut, sind völlig in Ordnung. Ich hatte mich auf die La-Mothe-Projekte bezogen, die "nicht der Rahul" gepostet hat und wo man im Endeffekt für 100 Öcken eine fertig bestückte Platine bekommt, die man dann z.B. in ein Gehäuse bauen kann. Und da entzieht sich mir der Lerneffekt schon. Beste Grüße, Bartl
> Im Hobby ist ja alles erlaubt, aber ich frage mich desöfteren, warum man > sich so einer Materie widmen sollte. Irgendwie hast du schon recht, manchmal fragt man sich, was man da tut. Warum man nächtelang debuggend vor dem Computer sitzt und warum man sich Gerätschaften und Material kauft, für deren Preis man das Endprodukt auch bekommen könnte. Manchmal fragt man sich, warum man das tut - ist es wirklich nur das Interesse und die Freude an der Materie? Oder spielt auch das Gefühl von "Macht-und-Kontrolle" über die Technik mit? Selbstbestätigung? Selbstverwirklichung? > Der Aufwand, Hardware zu realisieren die bei weitem nicht mit einem > modernen Handy mithalten kann ist enorm - ohne daß dabei etwas wirklich > neues realisiert wird... Das stimmt. Man findet z.B. im Deutschprachigen Raum nur einige wenige Projekte, die sich beispielsweise mit Farbgrafik befassen. Eines mit Echtzeit-Farbgrafik wäre mir nichtmal bekannt. > ...im Gegenteil - voller Stolz weiden sich die Augen des Entwicklers an > der entstandenen Grafik, die 1981 (wohlgemerkt vor 26 Jahren) > Spielhöllenstandard war. Wobei man sagen muss, dass damals ganze Teams von ausgewachsenen Ingenieuren mit siebenstelligen Budgets, umfassender Ausrüstung und als Fulltimejob am Werk war, während ich beispielsweise gerade mal ein einzelner lumpiger Student bin mit einem Budget von jährlich maximal einigen hundert Euro, mit meiner Lötausrüstung auf DIL-Packages angewiesen und nicht mal ein Oszi besitze und kaum über 10 Stunden pro Woche zum Basteln komme...
>Manchmal fragt man sich, warum man das tut - ist es wirklich nur das >Interesse und die Freude an der Materie? Da ich selber bastele (Synthesizer etc.) und es nur als Hobby neben dem Studium laufen lasse, kenne ich den Gedankengang gut. Allerdings bin ich der Meinung, daß es sinnvoller ist sich gerade bei der Elektronik mit Neuem zu beschäftigen. Das Gebiet Grafikprogrammierung ist extrem ausgelutscht - selbst die "Bibel" dieses Bereiches (Foley, van Damme) behandelt Themen, die von einer Realisierung mit Mikrocontrollern noch weit entfernt ist. ...und wenn dann der tausendste Voxelgrafik-, Bresenham-, Raycasting-, Spritealgorithmus implementiert wird, muß ich mich einfach nach dem Sinn fragen. Was ich (persönlich) interessanter finde, sind Bereiche in denen noch was "zu löten ist" (Heimautomatisierung, Prozeßsteuerung, verteilte Systeme, Audio/Synthese) - und wenn der tausendste Roboter nicht schon wieder ein Linienfolger ist, schaue ich mir auch diesen gerne an. Aber wie dem auch sei, eine Konsole zu bauen ist immer noch sinnvoller, als dieselbe Zeit mit zocken zu verschwenden :-) >@antworter: > Schon mal folgenden Spruch gehört? : "Der Weg ist das Ziel" Kommt mir bekannt vor, aber wenn das Ziel der uralt-Spieleautomat auf dem Dachboden ist, ist der Weg ziemlich vorhersagbar ;-)
> Das Gebiet Grafikprogrammierung ist extrem ausgelutscht - selbst die > "Bibel" dieses Bereiches (Foley, van Damme) behandelt Themen, die von > einer Realisierung mit Mikrocontrollern noch weit entfernt ist. > ...und wenn dann der tausendste Voxelgrafik-, Bresenham-, Raycasting-, > Spritealgorithmus implementiert wird, muß ich mich einfach nach dem Sinn > fragen. Es ist zwar tatsächlich ein umfassend abgehandeltes Gebiet, aber die meisten Projekte setzen auf bestehender Hardware auf - mir geht es eben gerade um den low-level Teil, d.h. um die nötige Hardware um eben anspruchsvolle Grafik ausgeben zu können. Und irgendwie hat mich die Digitaltechnik seit der entsprechenden Vorlesung an der Uni einfach gepackt :-) > Was ich (persönlich) interessanter finde, sind Bereiche in denen noch > was "zu löten ist" (Heimautomatisierung, Prozeßsteuerung, verteilte > Systeme, Audio/Synthese) - und wenn der tausendste Roboter nicht schon > wieder ein Linienfolger ist, schaue ich mir auch diesen gerne an. Also bei den Robotern gehts mir ähnlich... Jeder zweite im Roboternetz vorgestellte Robby kann (ausschliesslich oder als Hauptfunktion) Linien folgen und Hindernissen ausweichen. Für ein Einsteigerprojekt ne hübsche Sache, aber irgend wann hat man es gesehen :-) Die Frage ist halt: Wo liegen noch Herausforderungen? Die Anforderungen an mögliche sind hoch: Sie müssen eine echte Herausforderung bieten, aber doch nicht zu schwer sein. Sie müssen sich mit einem (Teil-)gebiet befassen von dem man Ahnung hat und das einem interessiert. Sie sollen etwas hergeben, aber doch nicht Jahre dauern usw. > Aber wie dem auch sei, eine Konsole zu bauen ist immer noch sinnvoller, > als dieselbe Zeit mit zocken zu verschwenden :-)
> Sprites sind ja eigentlich auch nichts anderes als Datenfelder. > Verknüpft man die per XOR mit dem Hintergrund, dann kann man sie setzen, > noch eine XOR-Verknüpfung, und sie sind wieder weg. Wie genau läuft das jetzt mit diesem XOR und den Sprites? Verstehe ich nicht ganz, kannst du das nochmals langsam zum mitschreiben? :-)
Angehängte Dateien:
-
eine-methode.png
17 KB
Das ist recht einfach, Du brauchst eine 'Schwarzmaske' die Du auf den Hintergrund mit AND verknüpfst. Danach musst Du die 'Farbmaske' mit XOR darüber legen. Alles was in der Schwarzmaske weiß und in der Farbmaske schwarz ist, ist nachher transparent. Das ist aber vielleicht nicht das was Rahul Der trollige meinte. Gruß, Feadi
Hmmm...aber damit löse ich das Problem, dass mir die 'Sprites' jedes mal den Hintergrund zersudeln und ich ihn neu zeichnen muss, ja noch nicht. Bisher dachte ich daran, entweder der von den Sprites verschmutzte Hintergrund vorher zu sichern und danach wieder zurückzuschreiben (Blittering / BOBs) oder eben die Sprites erst in Echtzeit in das Bildsignal einzubauen, ohne den Bildspeicher zu berühren (echte Hardware-Sprites). Irgendwie fand ich das aber unelegant, aber nach dem Wikipediaartikel http://de.wikipedia.org/wiki/Sprite_%28Computergrafik%29 wird's genau so gemacht. Werde eher einen Blitter / BOBs verwenden als Hardware-Sprites, das scheint mir ein bisschen einfacher. Wobei "einfach langsam" relativ wird. Mittlerweile habe ich ein CPLD als Speichercontroller, zwei 32k SRAMs als Videospeicher, einen Mega8 als Sync-Generator, einen 24 Bit breiten Bus für die Dateneingabe und jetzt möglicherweise noch ein 32k SRAM sowie einen Mikrocontroller für den Blitter. Bauen kann man sowas (Wobei ich langsam Bedenken habe, ob hier Lochraster noch eine gute Idee ist, wegen den 40 MHz CPLD-Takt) - debuggen hingegen wird unglaublich schwer. Vielleicht sollte ich doch lieber einen linienfolgenden Roboter bauen :-)
@antworter du baust synthesizer und audio-zeugs ? was denn so ? die rein analoge schiene ? (vco/vcf) ich selbst bin auch mit einem audio-system dran. wenn du magst können wir uns ja mal austauschen gruß rene
@TheMason Mein letztes großes Projekt war ein (polyphoner) FM-Synthesizer mit digital gesteuerten analogen Filtern (Cutoff und Resonanz werden gesteuert). Momentan sitze ich an einem Sample-Player (Drumcomputer) - diesmal mit `nem ARM7 (vorher ATMega). Welche Teile analog und welche digital sind, mache ich meist von Klangpotential und Aufwand abhängig. Was willst Du denn machen ?
@antworter ich hab hier (schon seit längerem) ein projekt auf under construction (genannt audio-projekt)das ein programmierbaren audio-prozessor basierend auf einem fpga darstellt. werde das teil auch bald hier reinstellen (muß nur noch was doku machen). mit dem teil kann man filtern, mischen, routen, oszillatoren erstellen und delays bauen. also alles was man für einen synthesizer, mischpult, effektgerät und dergleichen braucht. bin da auch noch auf der suche nach leuten, da das alleine schon recht mächtig ist (sitze da auch schon ne weile dran). basis des ganzen ist ein fpga-board von xilinx (spartan 3), an den ich ein msp430 und 2 audio-codecs angeschlossen habe. das board selbst hat noch 1MB Ram das im moment nur für delays genutzt wird. evtl. kann man da noch einen sampleplayer mit bauen. im späteren ausbau würde ich gerne (erstmal eine eigene platine daraus machen) und evtl. noch eine cf-card an den fpga anschließen um evtl. später auch hd-recording machen zu können. hast du bock mit zu machen ?
@TheMason Habe gerade gesehen, daß dazu schon viele Infos auf diesem Board rumschwirren - aber heute werde wohl nicht mehr dazu kommen, das alles durchzulesen. Wie könnte ich Dich am besten kontaktieren, wenn es mir zusagt ?
schreib mir einfach eine email : reneboellhoff (at) gmx (dot) de
@antworter wenn du mir deine email zukommen lässt, kann ich dir mal ein mp3-demo schicken wie ein synthesizer mit dem audio-prozessor klingt.
Hmm...so wies aussieht, muss ich das Projekt fallenlassen. Die Grafikausgabe an sich wäre kein allzugrosses Problem, allerdings fand ich keine Lösung für die Frage, wie ich die Daten für halbwegs brauchbare (NES/Gameboy-Stil) Animationen genügend schnell anliefern kann. Hat irgend wer ne Idee, was man mit dem (bereits bestellten) CPLD doch noch anfangen könnte? Oooder: Mit nem FPGA sollte es eigentlich gehen - aber gibts die irgendwo im hobbylötbaren Format?
Leg doch die Grafiken in nem Speicher ab, auf die dein Grafikcontroller zugriff hat. Dann brauchst du letztendlich nur noch die Position der einzelnen Grafiken zum Grafikcontroller übertragen (und wenn sich nix ändert, noch nicht mal das). Wahrscheinlich machen die älteren Konsolen das auch nicht anders. Kopieren die einzelnen Grafikblöcke, soweit notwendig, erstellen ein Hintergrundbild und sagen dann nur noch, wo der Charakter mit welchem Sprite steht.
@Frank: Ist alles bereits so geplant. Ich möchte die bewegten Grafiken als sogenannte BOBs http://de.wikipedia.org/wiki/BOB_%28Computergrafik%29 implementieren. Das Datenaufkommen ist aber immens. Die andere Variante sind die echten Sprites, aber dort ist die Logik für die Einblendung relativ komplex - kaum etwas für ein CPLD.
http://darkwatcher.psxfanatics.com/console/ Hier findet man eine Übersicht über alte Konsolen, die ersten hatten noch weniger als 1 MHz CPU Frequenz und hatten trotzdem schon beeindruckende Spiele. Für solche alten Systeme zu entwickeln ist bestimmt ziemlich interessant (besonders der Intellivision interessiert mich)
Hmmm, ok. Es gibt durchaus FPGAs, die man auch noch selbst löten kann. Guck z.B. mal bei Altera bei den Cyclones (I oder II) . Gibts noch bis PQFP 244. Die Frage ist halt, wieviel Logikelemente du brauchst. (Ich glaub, ich muss auch mal was in der Art basteln, wenn ich denn Zeit dazu hätte... :-) )
> Es gibt durchaus FPGAs, die man auch noch selbst löten kann. > Guck z.B. mal bei Altera bei den Cyclones (I oder II) . Gibts noch bis > PQFP 244. Die Frage ist halt, wieviel Logikelemente du brauchst. Muss ich mir mal ansehen. Allzuviel Logik brauch ich nicht, wenn ich das so überdenke, wäre es mit 2 CPLDs hinzukriegen. Vielleicht werde ich es dann doch so versuchen, denn bis ich in der Schweiz an FPGAs komme... :-S > Hier findet man eine Übersicht über alte Konsolen, die ersten hatten > noch weniger als 1 MHz CPU Frequenz und hatten trotzdem schon > beeindruckende Spiele. Für solche alten Systeme zu entwickeln ist > bestimmt ziemlich interessant (besonders der Intellivision interessiert > mich) Hmm...motiviert mich jetzt doch nochmals. Jedenfalls ist ein AVR den damaligen Prozessoren weit überlegen, und mit einem CPLD liessen sich zumindest einfache ASICs "ersetzen". Und der Speicher ist sowieso kein Thema.
@mr.chip: Sind Dir die alten SIMMs (DRAMs) aus PC`s bekannt ? Hier im Forum gab/gibt es mehrere Leute (mich eingeschlossen), die diese erfolgreich zum laufen gebracht haben - ist auch nicht sonderlich kompliziert. (Du bekommst bis zu 4MByte pro Modul gratis, wenn Du einen PC zum Schlachten findest.) Wenn Du dann für jedes neu generierte Bild (25 Bilder pro sek) die Sprites aus dem DRAM in Deinen Bildbuffer blittest, hättest Du ohne überlappende Sprites eine fest nach oben begrenzte Datenrate. Der DRAM selbst könnte alle in dem Spielelevel vorhandenen Sprites enthalten. Der CPLD würde dann das eigentliche Blitting übernehmen (Ansteuerung des DRAM-Moduls), und z.B. einfache Operationen wie z.B. Transparenz gegenüber dem Bild-Hintergrund ausführen. Du kannst es ja mal durchrechnen mit einer typischen RAM-Random-Access-Zeit von 200ns (als Hausnummer). Kopf hoch, IC runter und Lötkolben `drauf :-)
@ mr.chip: Du kannst welche bei Segor kaufen, oder ich kann Dir einen bei Reichelt mitbestellen. Michael Ributschka macht auch Sammelbestellungen bei Digikey, da habe ich auch schon mehrfach zufrieden mitgemacht. Beitrag "Digikey Sammelbestellung" Möglichkeiten gibt es viele. Gruß, Feadi
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.