- rein theoretischer Ansatz aus Interesse: Mit welchem Aufwand wäre es verbunden, eine LED mit einem aktuellen Intel Core i7 blinken zu lassen? Wo wäre da der Haken, bei der Beschaltung mit dem Beigemüse, oder eher dem Studieren des Datenblattes? Oder das Coding mit ASM hinzubekommen?
Hmm... Ein C#-Programm dass auf eine serielle Schnittstelle "LED-EIN" und "LED-AUS" schickt (und dann natürlich auf einen i7 läuft), dazu ein Arduino der auf seinem UART nach "LED-EIN" und "LED-AUS" hört und entsprechend D13 schaltet... Aufwand: Gering - Beschaltung inkl. Beigemüse ist fertig, ASM nicht notwendig, auch kein Datenblatt studieren. Allerdings ein paar C# & Arduino-Kenntnisse, aber wohl auch nix tiefgehendes... Ach ja: heute ist ja Freitag...
Matthias S. schrieb: > Ein C#-Programm dass auf eine serielle Schnittstelle "LED-EIN" und > "LED-AUS" schickt (und dann natürlich auf einen i7 läuft), dazu ein > Arduino der auf seinem UART nach "LED-EIN" und "LED-AUS" hört und > entsprechend D13 schaltet... Nein, nix Arduino über UART, natürlich muss das Blinken low level passieren ohne irgendwelche externe Protokolle. Beschaltung inkl. Beigemüse auf Lochraster. Und auch an einem Freitag machst du das nicht auf die Schnelle, schon mal nur das Pinout zu studieren geht bis Montag ;)
:
Bearbeitet durch User
Das wäre schon mit einem deutlich einfacher zu handhabenden 386er ziemlich aufwändig. Schau Dir erstmal den in der Theorie an und überleg dann ob das mit was modernem sinnvoll machbar wäre (Spoiler: ist es nicht ;-) ).
Das ist heute in wenigen Codezeilen bewerkstelligt, einfach in der Hochsprache deiner Wahl einen Datei- oder Netzwerkzugriff implementieren, je nachdem ob die LED vorne oder hinten am Rechner leuchten soll.
Auch ein Core-i7 läuft ohne RAM und Zugemüse, er muss ja den POST Power On Self RAM Test schaffen, aber er braucht externes Flash dazu. Es muss dazu kein Betriebssystem geladen sein. Das Flash enthält kein BIOS sondern einfachen code der irgendwelche Anschlüsse des i7 (den 8 bit BPM Port) nutzt um die LED anzusteuern (oder den I2C PECI Bus). Datenblatt sollte man elesne haben, Assembler können, aber wer den POST Code eines Pentium BIOS vorliegen hat, sollte kein Problem haben.
Sim schrieb: > Das wäre schon mit einem deutlich einfacher zu handhabenden 386er > ziemlich aufwändig. > Schau Dir erstmal den in der Theorie an und überleg dann ob das mit was > modernem sinnvoll machbar wäre (Spoiler: ist es nicht ;-) ). und: Gerd schrieb: > Das ist heute in wenigen Codezeilen bewerkstelligt, > einfach in der Hochsprache deiner Wahl einen Datei- > oder Netzwerkzugriff implementieren, je nachdem ob die LED > vorne oder hinten am Rechner leuchten soll. So Freitag ist der Post wohhl doch nicht, immerhin scheint sich hier niemand einig.
Philipp G. schrieb: > Gerd schrieb: >> Das ist heute in wenigen Codezeilen bewerkstelligt, >> einfach in der Hochsprache deiner Wahl einen Datei- >> oder Netzwerkzugriff implementieren, je nachdem ob die LED >> vorne oder hinten am Rechner leuchten soll. > > So Freitag ist der Post wohhl doch nicht, immerhin scheint sich hier > niemand einig. Der Poster geht von einem FERTIGEN Rechner mit Netzwerk und Festplatte aus, da sind ja LEDs dazu am Rechner dran :-P
Sim schrieb: > Der Poster geht von einem FERTIGEN Rechner mit Netzwerk und Festplatte > aus. Das liest du wo ? Du kennst ihn persönlich ?
> > je nachdem ob die LED vorne oder hinten am Rechner leuchten soll > vorne oder hinten AM RECHNER. Er meint damit die LEDs in den LAN Buchsen oder die Festplatten LED... Aber ich bin dann mal raus hier, genug Freitagsinternet für heute.
Sim schrieb: > vorne oder hinten AM RECHNER. > Er meint damit die LEDs in den LAN Buchsen oder die Festplatten LED... Ich meinte gar nichts. Ich habe klar geschrieben: Lochraster Intel core i7 LED Beigemüse = Aufwand.
auf DICH bezog sich das doch gar nicht... ach ist eh hoffnungslos bei so einem Textverständnis.
Mach dich mal schlau im Datenblatt mit welchem min. Takt der Prozessor läuft und welche Konfiguration nach einem Reset ( wie erzeugen )vorliegt. Dann wie den i7 kontaktieren und mit Spannungen versorgen. Programmspeicher anschliessen und Transistor mit LED.
MaWin schrieb: > Sim schrieb: >> Der Poster geht von einem FERTIGEN Rechner mit Netzwerk und Festplatte >> aus. > > Das liest du wo ? Du kennst ihn persönlich ? Meine Güte. Jetzt plenkt der Namensdieb auch noch. Der Vorposter meinte mit "Poster" offensichtlich Gerd (Gast) und nicht Philipp G. (geiserp01). Philipp ist nur ein Troll. Ein armseliger noch dazu.
Sim schrieb: > Das wäre schon mit einem deutlich einfacher zu handhabenden 386er > ziemlich aufwändig. 386er \ 486er auf Lochraster - Da würde ich ernsthaft mit machen! Der passt ja super aufs Raster. Den kann man ja sogar Sockeln. :-) Dazu hab ich mir ein paar (CPUs und Sockel) für diesen Zweck zurückgelegt, und sehe mir immer mal wieder das Datenblatt (z.B. unterwegs) an. Aber so richtig durchstarten konnte ich bisher noch nicht damit. Wie geht das denn eigentlich loß? Was passiert beim Einschalten? Z.B. so etwas wie: Der ließt den "ersten Befehl" mit 16 Bit auf "Adresse 0" ein?? Oder füttert man den einfach mit Instructions? Ich finde meinen "Start" leider noch nicht. MaWin schrieb: > wer den POST Code eines Pentium BIOS vorliegen hat, sollte kein Problem > haben. Genau da klemmt es bei mir noch. Der Hardware \ Software "Übergang". Wo schaut der Prozessor zuerst? "Adresse 0"?? Wenn das klappt kann man ja vielleicht neben ASM über gcc-x86 ein ROM bauen :-) Kann das jemand beschreiben?? Vielleicht auch so, dass Philipp G. für den i7 Ableiten kann... :-)
Sim schrieb: > Das wäre schon mit einem deutlich einfacher zu handhabenden 386er > ziemlich aufwändig. Da wäre es relaiv einfach. Zwei EPROMs als Datenspeicher anschliessen und ein paar Assemblerbefehle reinbrennen. Der i386 gibt ganz klassisch Adressen aus und liest Daten ein. Die Frage des TO ist zwar ein Freitagsthema, aber es wäre schon interessant wie ein minimales i7-System aussehen müsste. Da muss man ja erst die Management Engine hochfahren und darüber den Bus konfigurieren, bevor man irgendwelchen Speicher ansprechen kann.
soul e. schrieb: > Der i386 gibt ganz klassisch > Adressen aus und liest Daten ein. Wenn man ihm statisch (ohne ROM) fest verdrahtet immer NOPs gibt, und der x86 dann seinen Adressraum "durchläuft", fängt der dann irgendwann wieder bei Adresse 0 an? Weil: Dann hänge doch einfach ne LED an den hintersten Adress-Pin. - Und bei jedem Durchlauf leuchtet die kurz... Fertig. :-)
:
Bearbeitet durch User
Tim S. schrieb: > 386er \ 486er auf Lochraster - Da würde ich ernsthaft mit machen! Der > passt ja super aufs Raster. Den kann man ja sogar Sockeln. :-) Dazu hab > ich mir ein paar (CPUs und Sockel) für diesen Zweck zurückgelegt, und > sehe mir immer mal wieder das Datenblatt (z.B. unterwegs) an. Aber so > richtig durchstarten konnte ich bisher noch nicht damit. Das ist witzig - ich hatte vor vielen Jahren genau dieselbe Idee! Auch ein paar 486er aufbewahrt und ... - mein Gott, was man damit alles machen könnte! Dann etwas Studium des 1000Seite starken Programmierhandbuches und sehr bald wieder andere Prioritäten gefunden!
Philipp G. schrieb: > - rein theoretischer Ansatz aus Interesse: > > Mit welchem Aufwand wäre es verbunden, eine LED mit einem aktuellen > Intel Core i7 blinken zu lassen? Wo wäre da der Haken, bei der > Beschaltung mit dem Beigemüse, Wenn man als "Beigemüse" einen 555 verwendet, dürfte das kein Problem sein. :-)
Beitrag #5963872 wurde von einem Moderator gelöscht.
Tim S. schrieb: > Wie geht das denn eigentlich loß? Was passiert beim Einschalten? https://wiki.osdev.org/Boot_Sequence
Eric B. schrieb: > Tim S. schrieb: >> Wie geht das denn eigentlich loß? Was passiert beim Einschalten? > > https://wiki.osdev.org/Boot_Sequence Danke, aber so viel weis ich auch schon! Da stehen echt nur grundlegende Sachen (für Endanwender) drinnen, wie man es in der frühen Schule lernt. Aber ich meinte das auf Byte \ Adress- Register-Ebene... Z.B. dass es bei Adresse 0 / mit 16Bit startet und die Adressen selber hoch zählt usw. Da fehlt mir noch einiges an Wissen, um dann selber was aufbauen zu können! Trotzdem Danke für den URL. ____ i7 Product Brief: http://download.intel.com/pressroom/kits/corei7/pdf/Core%20i7%20Product%20Brief.pdf Pinout und Pin-Beschreibung (#4 Land Listing LGA1366): https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/core-i7-900-ee-and-desktop-processor-series-datasheet-vol-1.pdf Register und Befehle: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/core-i7-900-ee-and-desktop-processor-series-datasheet-vol-2.pdf Man darf ihn laut Specs nur 15x ein- und ausbauen!!
:
Bearbeitet durch User
Ich habe sowas vor vielen Jahren mit einem 8086 gemacht, das war schon ziemlicher Aufwand trotz nur 64k SRAM (damit man sich nicht um den Refresh kümmern braucht) braucht man noch ROM zumindest für einen Bootloader (da kann man das Blink-Programm auch direkt reinschreiben), Adressdecoder und Ein/Ausgabe-Ports plus einen Taktgeber für alles. Viel zu viel Aufwand, aber es war einfach lustig, so eine x86-kompatible Mini-Steuerung zu haben. Im ROM war ein Bootloader abgelegt, der nach dem Start das Programm via RS232 ins RAM geladen und gestartet hat. Mit einem 6510 vom C64 wäre das einfacher, der hat einen Port mit 6 Leitungen (wenn ich mich richtig erinnere) integriert - da könnte man sich einen Teil der Adressdecodierung und die externen Ports sparen, der kann direkt damit ein paar LEDs blinken lassen. Okay, mit einem aktuellen i7... braucht man zuerstmal alle Spannungen, Vcore mit 100..150A Spitzenstrom, mindestens einen voll beschalteten DDR4-Speicherkanal da der Speichercontroller in der CPU sitzt und die PCIe/QPI/UPI Buslogik, über die der Prozessor Daten annehmen und wieder ausgeben kann. Sehr komplex, auch wenn man ihn nur mit einer einzelnen Verbindung anbindet. Danach folgt das Studium darüber, welchen Zustand der Prozessor beim Start annimmt, wie man ihm mitteilt welche Adressen die I/O-Ports (die mit an der PCIe/QPI-Lane hängen müssen, mit entsprechender Adressdecodierung) haben und welche Informationen man ihm geben muß, damit er überhaupt losläuft. Also auch ein rudimentärer Bootloader wenn man so will. Man kann für den Speicher usw. bestimmt sehr konventionelle feste Werte benutzen wenn man keine hohe Geschwindigkeit möchte, aber das alles ist wesentlich komplexer als das Hallo-Welt-Geblinkel, was man später einmal darauf ausführen möchte. Alternative wäre ein herkömmliches lauffähiges Mainboard zu nehmen und sich da am Bios zu schaffen zu machen. Möglicherweise kann man ein eigenes schreiben. Oder es gibt bestimmt auch sowas wie Parallel-PCIe-Umsetzer, damit könnte man sich eine Steckkarte bauen, wo man ein paar frei programmierbare Leitungen bekommt. Damit könnte man dann eine LED blinken lassen. Manche Mainboards haben auch noch parallele Schnittstellen onboard, da bräuchte man sich "nur" um die Programmierung zu kümmern. Auf Lochraster ist das natürlich unmöglich aufbaubar, allein wegen der Anzahl der Pins, deren hohe Dichte und den hohen Taktraten. Ich glaube bei Lochraster ist beim 486er oder evtl. noch Pentium 1 Feierabend. Vielleicht noch Pentium 3 oder sogar einen K7 Athlon. Irgendwelche Freaks bringen sowas bestimmt auf Lochraster zum laufen, aber wegen der FSB-Logik (GTL/EV6) wird das das wohl eher schwierig.
Der Aufbau und die Kontaktierung ist imho der anspruchsvollere Teil des ganzen Unterfangens.
*.* schrieb: > Ich fürchte das BGA wird nicht ganz Lochraster-kompatibel sein... Wann kommen endlich die Bastelopas und fordern den Core i7 im DIP Gehäuse und 5V Kompatibel? Wie soll man sonst sein hd44780 daran betreiben? Und die ganzen Shields?
Kann man alles softwaremäßig auf nem funktionierenden PC machen. Dazu benutzt man eine der seriellen Schnittstellen des PC. Die Blink LED wird dann an einer Steuer- leitung der Schnittstelle angeschlosen. Mann braucht 2 Klassen einmal die Bedien- klasse, wo man die Schnittstelle auswählen, die Blinkfrequenz ändern kann usw., das Gesicht des Blinkgebers also. Dann die Blinkklasse, die in nem eigenen Therad läuft und die reine Blinkfunktion, also das Ein und Auschalten der LED je nach den von der Bedienklasse eingestellten Parametern am gewünschten seriellen Port sorgt. Ist schon ein Projekt, ein Blinkgeber mit 4 Milliarden Transistoren für den PC. ;-P mfg
Ben B. schrieb: > bei Lochraster ist beim 486er oder evtl. noch Pentium 1 Feierabend. Wenn man vom "voll-bestücktem" LGA1366 ausgeht, hat man am Ende noch ca. 980 Stk. \ 41% Löt-Punkte frei! (Auf einer 100x160mm bzw. 39*60 Punkt Standard Lochraster-Karte) = NO WAY. Kaum Platz!! Da bräuchte man schon die "doppelten". Aber mal anders rum: Der i7 hat doch so was wie ne MCU für Microcode Updates sowie JTAG, Test- und Debug Pins (Außen oben am Rand!) aufgebracht und eingebaut. Vielleicht kannst du damit ein paar Pins spaaren, und musst am Ende nicht ganz so viel initialisieren und vorbereiten, nur um einen einzelnen Pin blinken zu lassen. So eine Art JTAG Test-Routine laufen lassen! Das hat dann aber (wahrscheinlich) mit x86-ASM wenig bis gar nichts gemeinsam... LÖL Wochenende
Ben B. schrieb: > Ich habe sowas vor vielen Jahren mit einem 8086 gemacht, das war schon > ziemlicher Aufwand trotz nur 64k SRAM Da hast Du aber einen kompletten Rechner gebaut. Um die LED blinken zu lassen reicht Takt am Clock-Pin, ein '373 als Adresslatch und ein EPROM. Die LED kommt an eine der oberen Adressleitungen (kein Mensch wird jemals mehr als 640 kB benötigen ;-). Im EPROM wird abwechselnd zwischen 0x00 0000 und 0xF0 0000 hin- und hergesprungen und damit man auch was sieht zwischendurch ein wenig gewartet. Das wäre dann der i8088. Der iAPX386 kommt ohne Adresslatch aus und lässt sich über einen Pin auf 16bit Datenbus (SX mode) runterschalten. Für 16 bit braucht man zwei EPROMs, der Rest sinngemäß wie oben. Beim Core i7 stehen wir vor dem Problem, dass der gar keine Daten- und Adressleitungen hat, sondern ein LVDS-DDR-Interface. Bootstrapping erfolgt scheinbar wirklich über die Management Engine, die den UEFI-Code aus einem seriellen EEPROM in das DDR-RAM umkopiert und dann die CPU loslässt. Edit: NOPs ausführen lassen reicht beim 8088 auch, der Speicher kann ja oben überlaufen. Nach 0xFF FFFF gehts bei 0x00 0000 weiter. Der '386 braucht dafür das A20-Gate :-)
~Mercedes~ schrieb: > Dazu benutzt man eine der seriellen > Schnittstellen des PC. > Die Blink LED wird dann an einer Steuer- > leitung der Schnittstelle angeschlosen. Ja logisch dann kann man ja geradesogut die heartbeat LED vom RJ45 Anschluss rausführen, das ist ja nicht der Witz der Sache. Oder die LED der Harddisk. Oder die caps lock led blinken lassen. Ben B. schrieb: > Okay, mit einem aktuellen i7... > braucht man zuerstmal alle Spannungen, Vcore mit 100..150A Spitzenstrom, > mindestens einen voll beschalteten DDR4-Speicherkanal da der > Speichercontroller in der CPU sitzt und die PCIe/QPI/UPI Buslogik, über > die der Prozessor Daten annehmen und wieder ausgeben kann. Sehr komplex, > auch wenn man ihn nur mit einer einzelnen Verbindung anbindet. Erzähl mir mehr davon. Zwei Spannungsregler mit +5V und +3.3V ist da nicht? Wieviel Strom nimmt das Ding eigentlich wenn er nichts zu tun hat? Im Idle doch kaum über 1A?
:
Bearbeitet durch User
Philipp G. schrieb im Beitrag #5963872: > soul e. schrieb: >> Die Frage des TO ist zwar ein Freitagsthema, aber es wäre schon >> interessant wie ein minimales i7-System aussehen müsste. > > Danke, nichts anderes habe ich gemeint. Dann hättest du das schreiben sollen. Und nicht von Lochraster und "LED blinken" faseln. Wer am Freitag einen Troll-Thread eröffnet, den nenne ich einen Troll. Ob es ihm gefällt oder nicht.
ich hab mal mit assembler eine mini boot-fähige umgebung gebaut (viel abgekuckt bei qemu). Bei den tastatur-treibern hatte ich keine lust mehr. alles sehr aufwendig und nur virtuell zu entwickeln -> sonst ständig blue screens und reboots... macht wenig bis gar keinen sinn.
Hardwareaufbau: Wer fragen muss, hat schon verloren. Software bare Metal ohne BIOS: Es könnte schwierig sein, die Minimalhardware zum Laufen zu kriegen, ohne NDAs unterschreiben zu müssen. Minimal-PC: Einfach. M.W. kann man auch heute noch DOS booten. Ist dann halt kaum mehr als ein 8088, bevor es komplizierter wird.
Ich würde da ja umgekehrt rangehen: Ein altes Mainboard besorgen und irgendeinen Pin finden, der möglichst früh im Bootprozess zu blinken anfängt (bzw. irgendwann mal von low auf high wechselt und dann nach Reset wieder auf low steht). Da hängt man dann die LED dran. Was das konkret ist, ist zum Blinken ja völlig egal, Booten muss das System ja eh nicht. Dann kann man Stückchenweise die Peripherie und später dann einzelne Bauteile abtrennen und so das ganze Zeug entfernen, das man gar nicht braucht, um im Bootprozess weiter zu kommen, als gewünscht. Letztendlich bleibt dann eine relativ knappe Beschaltung übrig, die man dann nachbauen kann.
>Minimal-PC: Einfach. M.W. kann man auch heute noch DOS booten. Ist dann >halt kaum mehr als ein 8088, bevor es komplizierter wird. Genau sobald man den real-modus verlässt, verlässt einen die Realität... und es wird wirklich kompliziert...
Cyblord -. schrieb: > *.* schrieb: >> Ich fürchte das BGA wird nicht ganz Lochraster-kompatibel sein... > > Wann kommen endlich die Bastelopas und fordern den Core i7 im DIP > Gehäuse und 5V Kompatibel? Wie soll man sonst sein hd44780 daran > betreiben? Und die ganzen Shields? :D Der TO schrieb nicht, er wolle den i7 auf Lochraster löten, er schrieb dies lediglich über das "Beigemüse": Philipp G. schrieb: > Beschaltung inkl. Beigemüse auf Lochraster.
Angenommen der Chip hätte 2000 Pins dan wäre er gute 2,5 Meter lang in DIP Ausführung;)
blub schrieb: > Angenommen der Chip hätte 2000 Pins dan wäre er gute 2,5 Meter lang in > DIP Ausführung;) Wenn dir das zu lang ist, ist dein Steckbrett einfach zu klein.
~Mercedes~ schrieb: > Kann man alles softwaremäßig auf nem > funktionierenden PC machen. > Dazu benutzt man eine der seriellen > Schnittstellen des PC. > Die Blink LED wird dann an einer Steuer- > leitung der Schnittstelle angeschlosen. > > Mann braucht 2 Klassen einmal die Bedien- > klasse, ...... > > Dann die Blinkklasse, die in nem eigenen Therad > ...... > > mfg Wie umgehst du bei einem fertigen PC das BIOS? Der TO will ein Programm starten, ohne daß irgend was anderes sich vorher eingeschlichen hat.
Cyblord -. schrieb: > Wann kommen endlich die Bastelopas und fordern den Core i7 im DIP > Gehäuse und 5V Kompatibel? Wann gibt es denn endlich einen Intel Core i7 im DIP-Gehäuse? Ich habe auch noch einen ganzen Berg gut abgehangener 7805. Auf Grund des tollen TO220-Gehäuse kann man auch ganz einfach 50 Stück auf einer Gewindestange aufreihen und elektrisch parallelschalten. Damit sollte doch der Core i7 funktionieren, oder? > Wie soll man sonst sein hd44780 daran > betreiben? Genau! > Und die ganzen Shields? Igitt, solch ein neumodischer Arduino-Kram kommt mir nicht ins Haus! So etwas verwenden doch nur Ungediente und Langhaarige.
Öh... wieviel Strom nimmt ein i7 im idle-Betrieb... denke so 10..20A bei 0,8..1V werden's schon sein. Bei dem riesen Haufen Transistoren gibts in der Summe relativ viel Leckstrom, Speichercontroller und Caches laufen trotz idle. Das Ding so zu programmieren, daß es stromsparend läuft (Kerne abschalten, variabler Takt) ist bestimmt weit aufwendiger als die blinkende LED. Von Hause aus kann ein Prozessor gar kein idle, der macht immer irgendwas - und wenn es eine lange Folge NOPs ist, die bei abgesenktem Takt und Betriebsspannung abgearbeitet werden. Was darüber hinausgeht erfordert zusätzlich (externe) Interrupts und Zeitgeber, damit der Prozi auch wieder losrennt wenn man ihn einmal angehalten hat. Das BIOS könnte (ich weiß es nicht, habe mich damit nie beschäftigt) via DMA-Transfer in den Speicher geladen werden. Da werden ja sowieso eine ganze Reihe Komponenten durch das BIOS konfiguriert bevor irgendwas auf dem Bildschirm passiert. Keine Ahnung ab wann das durch den Hauptprozessor erledigt wird. DMA müsste auch bei gestoppter CPU funktionieren nachdem man den Speicher- und DMA-Controller initialisiert hat. Alte CPUs wie der 8086 haben einen festen Reset-Vektor bzw. eine IRQ-Adresse, die beim Reset angesprungen wird. Die externe Logik muß dafür sorgen, daß an dieser Stelle "ein Stück ROM" liegt. Wenn man es bis dahin schafft, kann man sich den ganzen Rest ziemlich frei zusammenprogrammieren. Das Programm kann direkt aus dem ROM ausgeführt werden, man kann aber auch irgendwas in den RAM kopieren und anspringen... wie man möchte. Bis 640KB/1MB Adressbereich sind die alten x86er voll flexibel, man kann sich den Speicher organisieren wie man möchte. Wenns sein muß gehts auch ganz ohne RAM, aber dann gibts viele Einschränkungen in der Programmierung (wenig Flexibilität bei Interrupts, kein Stack). Üblicherweise liegt das RAM ganz unten im Adressbereich und die ROMs darüber. Beim C64 war das so gelöst, daß die ROMs oder auch die Steckkarte (ROM-Cartridge) via Bank Switching ins RAM eingeblendet werden konnten. Dadurch wurde allerdings das RAM an diesen Stellen verdeckt. Die Kiste hat volle 64KB RAM und noch 20KB ROM, die der Prozessor anders gar nicht adressieren könnte. Der x86 hat auch nur 16bit-Register und braucht für sein 1MB adressierbaren Speicher Speichersegmentierung. Es gibt also zusätzliche Segmentregister, die den Speicher in 16-Byte-Blöcke aufteilen. Die Adresse 0000h:0010h ist also die gleiche wie 0001h:0000h. Außerdem hat er 20 Adressleitungen, die nervigerweise mit dem 16-Bit-Datenbus gemultiplext sind, damit die Kiste in ein DIP40-Gehäuse passt. Irgendwann "muß" ich sowas nochmal mit dem 68000er zusammensetzen, der hat solche Schnörkel nicht. Der hat 23 Adressleitungen (glaube ich) und 16 Datenleitungen, insgesamt aber auch satte 64 Pins. > Da hast Du aber einen kompletten Rechner gebaut. Um die LED > blinken zu lassen reicht Takt am Clock-Pin, ein '373 als > Adresslatch und ein EPROM. Wenn man so rangeht reichen zwei Transistoren und ein bißchen Hühnerfutter um eine LED blinken zu lassen. Das Teil sollte ja "echten" x86-Code ausführen können, das war der Witz daran. Im Endeffekt war es sowas wie eine x86-basierte SPS oder die hier bestimmt bekannte Z80-Türklingel.
Crazy H. schrieb: > Wie umgehst du bei einem fertigen PC das BIOS? BIOS-Eprom raus, eigenes Eprom rein. Zumindest wenn das heute überhaupt noch Eproms sind.
blub schrieb: > da wirdst dann schwierig mit dem DDR-Timing ;) Das ist bereits seit dem 03.10.1990 nicht mehr möglich! Quellennachweis: https://de.wikipedia.org/wiki/Chronik_der_DDR_(1981%E2%80%931990)
> BIOS-Eprom raus, eigenes Eprom rein. > Zumindest wenn das heute überhaupt noch Eproms sind. Sind es. Serielle Flash-ROMs mit bis zu 8 Megabyte...
Ben B. schrieb: >> Da hast Du aber einen kompletten Rechner gebaut. Um die LED >> blinken zu lassen reicht Takt am Clock-Pin, ein '373 als >> Adresslatch und ein EPROM. > Wenn man so rangeht reichen zwei Transistoren und ein bißchen > Hühnerfutter um eine LED blinken zu lassen. Das Teil sollte ja "echten" > x86-Code ausführen können, das war der Witz daran. Im Endeffekt war es > sowas wie eine x86-basierte SPS oder die hier bestimmt bekannte > Z80-Türklingel. Tut es doch. Die Türklingel aus dem FA hat exakt die von mir skizzierte Architektur: https://www.mikrocontroller.net/attachment/139619/klingel.png Das EPROM enthält Code, der von der CPU ausgeführt wird. Der Lautsprecher wird hier über /IORD und /IOWR gesteuert, aber eine Adressleitung tut es genauso. In diesem Fall nutzt man aus, dass bei Nichtverwendung von A19 die Adressen 0x00 0000 und 0x80 0000 (bzw 0x0000 und 0x8000 beim Z80 mit nur 16 Adressleitungen) die gleichen Daten aus dem EPROM hervorholen. Der 8088 braucht ein zusätzliches Latch (74LS373), da die unteren Adressleitungen mit dem Datenbus gemultiplext sind.
Bernd K. schrieb: > Zumindest wenn das heute überhaupt noch Eproms sind. Wann hast du denn das letzte mal in einen PC geschaut? Muss mindestens 20 Jahre her sein. Ok, Flash Speicher sind auch elektrisch Programmierbar. Ich schätze allerdings, dass du die Dinger mit dem Fenster zum Löschen meinst. Denn nur die heißen EPROM.
Stefanus F. schrieb: > Wann hast du denn das letzte mal in einen PC geschaut? Muss mindestens > 20 Jahre her sein. Ich muss zugeben daß ich mich in letzter Zeit kaum noch für solche Details die das physikalische Innenleben meiner 08/15 Rechenknechte betreffen interessiere, ich bin dort schon fast vollständig auf die nächsthöhere Abstraktionsebene (die Ebene der Software) transzendiert.
Das schöne alte BIOS-EPROM mit dem Hologramm-Aufkleber ist heutzutage ein kleiner achtpoliger SPI-Flashbaustein mit fetten 8..32 MByte. Dessen Inhalt wird von der Management Engine in das DDR-RAM kopiert und dann dort von der CPU ausgeführt. Die Management Engine ist ein kleiner ARM-Prozessor, der quasi Vollzugriff auf die Ressourcen des Mainboards hat und dort alles für den Chef passend einrichtet. D.h. das vom TO geforderte LED-Blinken könnte auf einem PC-Mainboard auch durch die ME erfolgen, eine CPU braucht gar nicht drinzustecken. Auf diese Weise können solche Boards auch Piepcodes für fehlende oder falsch verbaute CPUs ausgeben, wozu die Haupt-CPU aus verständlichen Gründen in dem Moment nicht in der Lage wäre. Da die ME quasi Vollzugriff auf die Ressourcen des Mainboards hat, ist sie recht umstritten -- ein Bösewicht könnte da auch Code laufenlassen, der regelmäßig den kompletten Speicherinhalt auf die Netzwerkschnittstelle kopiert.
Tim S. schrieb: > 386er \ 486er auf Lochraster - Da würde ich ernsthaft mit machen! Der 486er kann (im Gegensatz zum 386er) an einem 8 Bit-Bus betrieben werden, läuft mit 5V und passt aufs Lochraster. Außerdem ist er, im Gegensatz zu modernen Prozessoren, gut dokumentiert. soul e. schrieb: > Die Management Engine ist ein kleiner ARM-Prozessor, der quasi > Vollzugriff auf die Ressourcen des Mainboards hat und dort alles > für den Chef passend einrichtet. Das ist kein ARM, sondern in älteren Mainboards ein eigener RISC-Prozessor mit eigenem Betriebssystem. Bei aktuellen Boards ist es ein kleiner x86, auf dem Minix läuft. Die Management Engine ist übrigens strikt notwendig; wenn sie nicht innerhalb von 30 Minuten (oder so) aktiv wird, wird die CPU neu gestartet. Das stört einige Open Source BIOS-Entwickler, denn so muss man den unbekannten, signierten ME-Code drin lassen. Philipp G. schrieb: > Mit welchem Aufwand wäre es verbunden, eine LED mit > einem aktuellen Intel Core i7 blinken zu lassen? Das ist ganz einfach. Du nimmst eine LED, einen 555 und ein bisschen passendes Hühnerfutter und lochrasterst dir eine gewöhnliche Blinkschaltung zusammen. Dann nimmst du dir einen Intel Core i7 und legst den daneben - einlöten geht ja nicht. Dann nur noch passend mit Spannung versorgen, fertig.
Andreas S. schrieb: >> Wie soll man sonst sein hd44780 daran >> betreiben? > > Genau! Was? Wassndas neumodisches? Gibts keine Nixie-Treiber mehr? Wo kann ich denn meinen Fernschreiber anschliessen? Und die Quecksilberverzoegerungsleitung? War ja nicht alles schlecht damals!!einself!!11 Gruss WK
Philipp G. schrieb: > Wo wäre da der Haken, bei der > Beschaltung mit dem Beigemüse, oder eher dem Studieren des Datenblattes? Da fängt es schon an. Es sind zwei Datenblätter: https://www.intel.de/content/www/de/de/products/docs/processors/core/core-technical-resources.html Dafür sind die aber ziemlich kurz. Ich glaube, dass da nochmal deutlich mehr dazu kommt.
Dergute W. schrieb: > Wo kann ich > denn meinen Fernschreiber anschliessen? Ob man das BIOS wohl auf Lochkarten drauf bekommt?
Bestellen: https://www.pollin.de/p/bausatz-led-wechselblinker-810051 LEDs auf die Rückseite löten, i7 daneben kleben und gut.
Das ist doch so ein Backdoor-hochsicherheits-Wirtschafts-Rückgrat-stützender Industrie-/Regierungs-Späh-Prozessor. Vielleicht springt er gar nicht an ohne seine geheimen Kommandos ...
Philipp G. schrieb: > Wo wäre da der Haken, bei der > Beschaltung mit dem Beigemüse, oder eher dem Studieren des Datenblattes? Beides ist bei Intel CPUs extrem aufwändig - das DB ist NDA, und das viele "Beigemüse" größtenteils auch. Die brauchen übrigens zwingen einen "Chipsatz". AMDs Sockel AM4 CPUs kann man auch ohne Chipsatz betreiben - der "nicht-Chipsatz" läuft als "A300". Gibt es AFAIK aber nur als Barebone von ASRock. Die Teile sind aber (u.a.) HF-technisch derart komplex dass man immer fertige Mainboards nutzen muss. Selber designen geht dank NDA ohnehin nicht. LED blinken am PC macht man entweder mit einem USB Wandler (z.B. IOWarrior), oder man schaut sich mal einen Schaltplan einer "Port 80" Diagnose "Karte" an. Da müsste ein Bus Dekoder für den LPC Bus drauf sein - das ist ein Nachfahre des ISA Bus.
*.* schrieb: > Ich fürchte das BGA wird nicht ganz Lochraster-kompatibel sein... Man kann natürlich auch an jeden einzelnen Anschluss des i7 einen Fädeldraht löten.
Angehängte Dateien:
-
484-bga-faedel.jpg
50 KB
Harald W. schrieb: > *.* schrieb: > >> Ich fürchte das BGA wird nicht ganz Lochraster-kompatibel sein... > > Man kann natürlich auch an jeden einzelnen Anschluss des i7 einen > Fädeldraht löten. Ok, fertig soweit. Und jetzt?
Bernd K. schrieb: >>> Ich fürchte das BGA wird nicht ganz Lochraster-kompatibel sein... >> >> Man kann natürlich auch an jeden einzelnen Anschluss des i7 einen >> Fädeldraht löten. > > Ok, fertig soweit. Und jetzt? Die Blink-LED an die beiden Betriebsspannungsanschlüsse löten.
Angehängte Dateien:
Bernd K. schrieb: > Harald W. schrieb: >> [...] > Ok, fertig soweit. Und jetzt? Ey! Halt mal! Da fehlt noch einer. :-)
Theor schrieb: > Bernd K. schrieb: >> Harald W. schrieb: >>> [...] >> Ok, fertig soweit. Und jetzt? > > Ey! Halt mal! Da fehlt noch einer. :-) Das ist der Ausgang für die LED.
Bernd K. schrieb: > Theor schrieb: >> Bernd K. schrieb: >>> Harald W. schrieb: >>>> [...] >>> Ok, fertig soweit. Und jetzt? >> >> Ey! Halt mal! Da fehlt noch einer. :-) > > Das ist der Ausgang für die LED. Ach ja! Klar. :-)
Wobei der i7 LGA ist, da musste die Lötzinnblobs erst selber ranlöten!
Ich überlege gerade ob ich dafür einen eigenen Thread aufmachen sollte: Hat jemand "freiwillig" Lust, so etwas mit 386 / 486 auf Lochraster zu bauen - bzw mich ein bisschen zu "unterstützen"? Ich hab -wie beschrieben- ein paar Sockel und Prozzis aufgehoben und dazu noch diverse alte 8085\8086 Peripherie-ICs: Parallel IO UARTs Timer usw die ich daran verwenden würde. Wichtigste Frage: Kann man x86-GCC auch ohne die restlichen Mainboard "Hardware-Einheiten" (North- Southbridge \ Memory-Controller \ Usw Etc) nutzen, und wie stelle ich das an? Muss man einfach nur die entsprechenden "includes" und Aufrufe auslassen? Dafür selber "Treiber" schreiben!? Das ist ja dann kein "richtiges PC-System" mit Standard-BIOS Unterbau und Standard-Adressen mehr (wofür man dann ein extra >1000 Seiten Programmierhandbuch bräuchte), sondern nur noch der CPU-Kern und mein Geraffel dran. Gibt es dafür einen bulk\plain\RAW-x86-gcc, oder wie nennt man das bzw. wonach kann ich suchen? ...Aber wenn ich etwas genauer drüber nachdenke, macht das doch alles der "gleiche" x86-GCC, oder? - Also nur Librarys für die weiteren Peripherie-ICs finden\schreiben, und evtl nen virtuellen Debugger und Simulator bevor es an die Hardware geht. (!?) Ist das grob der "richtige" Weg zum "anfangen"? Auf ASM "zurückfallen" kann\muss ich ja später immer noch, aber ich würde zum "Coden" gerne C verwenden! Das wäre was für die kommenden langen Winter-Monate - würde ich mir gerne antun! Gruß
Guck Dir mal den 80186 an, damit wäre der Aufwand so gerade noch überschaubar.
Mit OpenWatcom C ein Video-BIOS schreiben klappt, müsste also auch für "ganz ohne" gehen. Man muss aber schon Einiges recherchieren. Bei 386/486 hast du noch nicht viel North/Southbridge etc. Spezifischer Chipsatz war da eine Reihe von Registern, die das Speicherlayout , -timing und -mapping, und ein paar ISA-Parameter festlegten. Die PC-Hardwarekompatibilität ist zum Großteil erbracht, wenn du einen 82c206 integrierten Peripheriechip und einen 8042 Tastaturcontroller ins Projekt aufnimmst.
Moin, In den sourcen von u-boot wirds wohl den ein oder anderen Gimmick zum Angucken/Kopieren geben, wie man mit gcc bare-metal programmieren kann. Gruss WK
Tim S. schrieb: > Ich überlege gerade ob ich dafür einen eigenen Thread aufmachen sollte: > Hat jemand "freiwillig" Lust, so etwas mit 386 / 486 auf Lochraster zu > bauen - bzw mich ein bisschen zu "unterstützen"? Ich hab -wie > beschrieben- ein paar Sockel und Prozzis aufgehoben und dazu noch > diverse alte 8085\8086 Peripherie-ICs: Parallel IO UARTs Timer usw die > ich daran verwenden würde. Wer hat das nicht? Ein schönes Beispiel mit 8088 ist der Xi-8088 von Sergej Malinov http://www.malinov.com/Home/sergeys-projects/xi-8088 Das Ding ist komplett IBM PC/XT-kompatibel, man braucht nur noch eine Graphikkarte. Die Schaltung lässt sich beliebig abspecken bis auf RAM und ROM oder LED und ROM. Mit '386 und '486 gibt es im Netz einige Beispiele für den S100-Bus. Die lassen sich ebenfalls reduzieren und mit lokalem Speicher ausstatten. GCC erzeugt erstmal C-Code. Du musst Dir halt alle Ein-/Ausgabefunktionen selber stricken, die Standardbibliotheken passen natürlich nur zu Standard-Hardware.
386: http://www.s100computers.com/My%20System%20Pages/80386%20Board/80386%20CPU%20Board.htm 486: http://www.s100computers.com/My%20System%20Pages/80486%20Board/80486%20CPU%20Board.htm
Tim S. schrieb: > Ich überlege gerade ob ich dafür einen eigenen Thread > aufmachen sollte: Ja. > Hat jemand "freiwillig" Lust, so etwas mit 386 / 486 auf Lochraster > zu bauen - bzw mich ein bisschen zu "unterstützen"? Erstens nutzt du den falschen Schrägstrich, und zweitens: Eher nicht. Fragen beantworten und diskutieren ist das eine, aber bauen musst du das selbst - direkte Unterstützung wäre nur hilfreich, wenn man selber sowas bauen will. > Ich hab -wie beschrieben- ein paar Sockel und Prozzis aufgehoben > und dazu noch diverse alte 8085\8086 Peripherie-ICs: > Parallel IO UARTs Timer usw die ich daran verwenden würde. Erstens: Nimm einen Z80, 8088, 80188 oder 80486DX. Nur die kann man direkt an einem 8 Bit-Bus betreiben. Kostet Performance, spart viel Löterei. Zweitens: Verzichte auf PC-Kompatiblität. Ein halbwegs kompatibles BIOS ist viel Arbeit und für ein fertiges BIOS für den 486er wird auf deiner Hardware nicht laufen. Für den Z80 ist das irrelevant (ein CP/M-BIOS hustet man recht schnell raus) und bei den anderen läuft es auf ein Zusammenstecken bekannter Bausteine raus. Achso, ein paar ISA-Slots mit funktionierender Grafikkarte kannst du auch erstmal ziemlich lange vergessen. > Wichtigste Frage: Kann man x86-GCC auch ohne die restlichen Mainboard > "Hardware-Einheiten" (North- Southbridge \ Memory-Controller \ Usw Etc) > nutzen, und wie stelle ich das an? Der Compiler hat mit der Hardware nichts zu tun. Aber du wirst mit dem Real Mode und ohne DOS hantieren müssen, und da ist der GCC keine große Hilfe. Benutzt habe ich mal bcc (Bruce's C compiler), ansonsten sind noch ACK oder Open Watcom gebrauchbar. Oder die Klassiker wie Turbo C. In jedem Fall musst du deine Toolchain lange massieren, bis du damit ein bootfähiges ROM hinbekommst. > Das ist ja dann kein "richtiges PC-System" mit Standard-BIOS > Unterbau und Standard-Adressen mehr Wenn du einen PC bauen willst, bist du mit Lochraster falsch. Besorge dir die originalen Chipsätze (z.B. von Chips & Technologies, kannst du von alten Mainboards kratzen), löte sie passend zusammen und fertig. *.* schrieb: > Der 386EX würde es auch langweilig machen ;) Wäre aber ein schönes Projekt. :-) soul e. schrieb: > Das Ding ist komplett IBM PC/XT-kompatibel, man braucht nur noch eine > Graphikkarte. Die Schaltung lässt sich beliebig abspecken bis auf RAM > und ROM oder LED und ROM. Ist dann aber auch kein PC mehr. :-)
Die Programmierung ist doch kein Problem, so schwer ist x86 Assembler nicht. Falls man auf dem Ding wechselnden Code ausführen möchte, braucht es ein Mini-BIOS, welches zumindest die Interrupttabelle und den Stackpointer initialisiert und den Code ins RAM kopiert. Danach kann man mit dem Ding eigentlich alles machen was man will. Klar, man bekommt keine Bildschirm-Ausgabe und sowas wie Timer/BIOS/DOS-Interrupts/Funktionen stehen nicht zur Verfügung, aber sonst läuft das Teil wie ein µC. Die Hardware sollte ein paar Ein/Ausgabe-Ports im Bereich bis 1MB RAM zur Verfügung stellen, damit man mit dem Ding auch was anfangen kann. Den Code kann man problemlos mit alten Assemblern (z.B. Borland) erstellen. .COM-Dateien können direkt an eine Adresse CS:0100h geladen und angesprungen werden (wenn ich mich richtig erinnere). Bei .EXE muß man den Code extrahieren (Header überspringen) und an Adresse CS:0000h laden (auch wenn ich mich recht erinnere), ES/DS müssen auf CS-10h gesetzt werden. Diese 256 Bytes vor dem Code beinhalten das DOS-Environment mit z.B. Kommandozeilenparametern, kann sein, daß unter DOS entwickelte Programme diesen Offset erwarten auch wenn sie den Inhalt nicht beachten. Im Header der .EXE stehen auch Startwere für CS:IP und SS:SP (beides relativ zum Code-Beginn), kann man aber beides ignorieren wenn man den Stack da lässt wo er ist und das Programm keine extravaganten Einsprungpunkte benutzt. Eine .COM-Datei ist einfacher, kann aber nur maximal knapp 64kB Code enthalten. Bei mehr Code/Daten muß man also die .EXE nehmen. An eine .EXE kann man auch Daten hinter dem Code anhängen, die von DOS ignoriert und nicht mit ins RAM geladen werden. Ist aber alles schon eine Weile her, daß ich mich mit sowas beschäftigt habe. Also falls ich hier den einen oder anderen Fehler drin habe, verzeiht mir das bitte.
Ben B. schrieb: > Also falls ich hier den einen oder anderen Fehler drin habe, > verzeiht mir das bitte. Ohne vollwertiges BIOS läuft kein DOS und ohne DOS laufen keine EXE Dateien. Wobei die mir bekannten DOS Versionen den Zugriff auf die Hardware zum Teil am BIOS vorbei machen und daher auch noch PC kompatible Hardware erfordern.
Wenn es nur darum geht, mit einem Core i7 eine LED zum Blinken zu bekommen, dürfte die einfachste Möglichkeit wohl sein, den Die zu zerschlagen und dann aus den Scherben 2 Transistoren für einen Oszillator zu "bauen"
> Ohne vollwertiges BIOS läuft kein DOS und ohne > DOS laufen keine EXE Dateien. Lern Lesen! Ich habe nirgendwo geschrieben, daß ich DOS zum laufen bringen möchte. Es ging darum wie man passenden Code erzeugt bzw. Code aus .COM oder .EXE Dateien auf dem Ding starten kann. Daß diese Programme nichts machen dürfen, was das System nicht unterstützt, ist ja wohl logisch. Sprich sie dürfen natürlich keine BIOS- und auch keine DOS-Funktionen (Interrupts 13h und 21h) verwenden oder irgendwelche Zugriffe auf Hardware machen, die gar nicht vorhanden ist (ggf. Timer-Zugriffe). Übrigens passiert ähnliches auch auf regulären PC-Maschinen. Wenn ich ein Programm mit 386er-Instruktionen (z.B. MOV EAX,...) auf einem 286er startet, probiert der das - bis er auf diese Instruktionen stößt. Dann gibt's nen Fehler (illegal opcode) und das war's. Um die Fehlerbehandlung darf sich das Programm selbst kümmern. Üblicherweise verbiegt man diese Interrupts auf eigene Routinen zur Fehlerbehandlung und probiert dann einfach aus, ob der Prozessor bei solchen Instruktionen meckert oder nicht.
Tim S. schrieb: > 386er \ 486er Danke für die vielen Infos - ist ja eigentlich schon "Offtopic". Die Beispiele für den S100-Bus sind sehr gut! Tim S. schrieb: > Hat jemand "freiwillig" Lust, so etwas mit 386 / 486 auf Lochraster zu > bauen - bzw mich ein bisschen zu "unterstützen"? S. R. schrieb: > Fragen beantworten und diskutieren ist das eine, aber bauen musst du das > selbst Klar mache ich das selber. Jop, das ist wirklich nur, falls Fragen auftauchen. Warum sollte jemand anderer MEINE Platine bauen!? (Außer jemand macht einfach wieder (s)ein "Layout" fertig, und postet es hier - falls es "passend" ist, würde ich es schon nehmen...) S. R. schrieb: > direkte Unterstützung wäre nur hilfreich, wenn man selber sowas > bauen will. Ich meinte auch die Menschen, die so etwas schon können! Und ihr Wissen darüber "abladen" und beitragen könnten. Es muss (für mich) absolut überhaupt keine PC- oder DOS-Kompatibilität haben. Der 80386EX hat ja wirklich schon einiges dazu Onboard! Aber mir reicht 'Nur gcc-x86-32-raw. S. R. schrieb: > oder 80486DX. Nur die kann man direkt an einem 8 Bit-Bus betreiben. > Kostet Performance, spart viel Löterei. Naja ich hab schon daran gedacht den RAM 32-Bittig (4 Stück SRAM) anzubinden (das ist ja der 'Clou' an der Sache!) und 16 Bit ROM (2 Stück) und mindestens 8 Bit nach "draußen" zur Peripherie vorzusehen. Vielleicht sogar den Co-Prozessor dazu - Das alles als µC nutzen, wie bei den "S100-Bus" Boards oder wie Ben B. es beschrieben hat 'Beitrag #5965931' Programmiert in C. Mit dem "FirstStage" Bootloader im ROM und evtl ein Mini-OS für die Hardware usw klar. Das mit den Wait-Staits 'unterjubeln' muss ich mir noch genauer anschauen! S. R. schrieb: > Achso, ein paar ISA-Slots mit funktionierender Grafikkarte kannst du > auch erstmal ziemlich lange vergessen. (NE2000 vielleicht) Es braucht keine "echte" GPU angebunden zu sein - ein paralleles kleines Grafikdisplay tuts auch. Damit es Sinn macht: An die Wand oder die Tür hängen. ____ S. R. schrieb: > Wenn du einen PC bauen willst, bist du mit Lochraster falsch. Nein, ich möchte keinen PC bauen. S. R. schrieb: > Besorge dir die originalen Chipsätze (z.B. von Chips & Technologies, > kannst du von alten Mainboards kratzen), Ein zusammengesetztes Puzzle zerstören... > löte sie passend zusammen und fertig. ...um es wieder neu zusammenzusetzen - also Puzzle spielen. Nee da lass ich das Mainboard lieber gleich als "ein ganzes". ;-) Tim S. schrieb: > Ich überlege gerade ob ich dafür einen eigenen Thread aufmachen sollte: S. R. schrieb: > Ja. OK! Tim S. schrieb: > Das wäre was für die kommenden langen > Winter-Monate - würde ich mir gerne antun! Dauert ja noch ein bisschen!
Tim S. schrieb: > Tim S. schrieb: >> Ich überlege gerade ob ich dafür einen eigenen Thread aufmachen sollte: > S. R. schrieb: >> Ja. > OK! Bitte verlinke den neuen Thread hier. :-)
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.