Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken
Gespeichert 
Die Datenleitung des Bus (der im Computer und nicht der auf der Straße ) wird auch für den "Transport" von Befehlen für CPU genutzt, oder?
09. November 2026, 18:31
- Lowlevel »
- OffZone »
- Offtopic »
- Thema: Logisim CPU
Thema: Logisim CPU (Gelesen 539330 mal)
Mhh wie funktioniert das ohne die Datenleitung dauerhaft zu blockieren? Werden die Befehle da zunächst in eine art Speicher in der CPU geladen und dann ausgeführt?
ja^^
Die Datenleitung des Bus (der im Computer und nicht der auf der Straße ) wird auch für den "Transport" von Befehlen für CPU genutzt, oder?Bei einer von-Neumann-Architektur: Ja. Bei einer Harvard-Architektur: Nein, dort werden verschiedene Busse für Befehle und Daten genutzt.
Mhh wie funktioniert das ohne die Datenleitung dauerhaft zu blockieren? Werden die Befehle da zunächst in eine art Speicher in der CPU geladen und dann ausgeführt?Ja, diese "Art Speicher" nennt man üblicherweise Register.
Gruß,
Svenska
Also ich wollte eigentlich einen Parallelen externen Bus verwenden (der zwischen CPU, RAM und I/O-Ports) der nur eine Daten- und 1 Adressleitung hat. Wenn man jetzt eine Festplatte an einem I/O Ports anschließt wie kommen dann die Befehle zur CPU ohne das die ganze Zeit die Datenleitung von der Festplatte belegt wird. Ein Register kann doch nur 1 Befehl aufnehmen oder ? Ich wollte da jetzt eigentlich so was wie eine Befehls-Cache einbauen.
Hallo,
was du da geschrieben hast, ist Müll.
Du hast nicht verstanden, wie Bussysteme funktionieren. Bitte arbeite dich in die Thematik ein und schaue dir reale Bussysteme an, ehe du versuchst, ein eigenes zu entwickeln.
Du hast nicht verstanden, wie Hardware funktioniert. Arbeite dich mal in die Materie ein, damit du ein Gefühl dafür kriegst, wie Hardware funktioniert. Am besten, du schreibst einen Treiber für eine etwas kompliziertere Hardware (z.B. IDE), ohne int 21h (DOS) und int 13h (BIOS) zu benutzen. Muss ja kein ganzes Betriebssystem werden.
Übrigens: Seriell = eine Leitung, parallel = mehrere Leitungen.
Gruß,
Svenska
was du da geschrieben hast, ist Müll.
Du hast nicht verstanden, wie Bussysteme funktionieren. Bitte arbeite dich in die Thematik ein und schaue dir reale Bussysteme an, ehe du versuchst, ein eigenes zu entwickeln.
Du hast nicht verstanden, wie Hardware funktioniert. Arbeite dich mal in die Materie ein, damit du ein Gefühl dafür kriegst, wie Hardware funktioniert. Am besten, du schreibst einen Treiber für eine etwas kompliziertere Hardware (z.B. IDE), ohne int 21h (DOS) und int 13h (BIOS) zu benutzen. Muss ja kein ganzes Betriebssystem werden.
Übrigens: Seriell = eine Leitung, parallel = mehrere Leitungen.
Gruß,
Svenska
Oje 
, was ist den genau an meinem konzept falsch?
Hab mich hier informiert über Busse informiert und mein Konzept auch so gestaltet : http://de.wikipedia.org/wiki/Bus_%28Datenverarbeitung%29
Mhh ein Treiber für den IDE Controller... naja ich versuchs mal.
, was ist den genau an meinem konzept falsch?Hab mich hier informiert über Busse informiert und mein Konzept auch so gestaltet : http://de.wikipedia.org/wiki/Bus_%28Datenverarbeitung%29
Mhh ein Treiber für den IDE Controller... naja ich versuchs mal.
Hallo Tufelix,
Keine Hardware-Komponente hat eine exklusive Verbindung zur CPU, ist spätestens bei mehreren CPUs auch Unsinn. Ein Bussystem in einem Computer stellt die Verbindung zwischen 2 Komponenten immer nur für eine kurze Zeit her damit diese 2 Komponenten eine kleine Hand voll Daten in eine der beiden Richtungen austauschen können. Ein solcher Austausch wird üblicherweise Transfer genannt und stellt einen in sich abgeschlossenen Lesezugriff oder Schreibzugriff dar (pro Zugriff kann aber mehr als ein Byte oder ein Word übertragen werden, das nennt sich dann Burst oder Block-Transfer). Für alles was komplexer ist werden mehrere unabhängige Transfers benutzt (wo dazwischen sogar der Bus von anderen Komponenten benutzt werden kann). In dem von Dir verlinkten Wikipedia-Artikel gibt es gar keine Beschreibung wie ein Datenbus in einem Computer im Detail funktioniert, dafür ist dort der NuBus verlinkt und in dessen Wikipedia-Artikel ist die zugehörige Spezifikation verlinkt. Das sind relativ wenige Seiten Text und der NuBus ist vom Feature-Umfang noch recht überschaubar und würde ungefähr das bieten was Du aktuell brauchst (was jetzt keine Aufforderung sein soll diesen Bus umzusetzen sondern das ist nur ein Hinweis auf eine Technologie in ungefähr der benötigten Gewichtsklasse). Ich hab mir die Spezifikation gerade mal durchgelesen und empfinde die als einigermaßen verständlich geschrieben und es sind auch keine zu komplexen Sachen drin (der NuBus kennt z.B. keine Bridges u.ä. so das es immer nur einen einzigen NuBus in einem System gibt was die Sache fürs erste unheimlich vereinfacht).
Ein Bussystem in einem Computer ist im Ideal absolut agnostisch gegenüber allen angeschlossenen Komponenten und auch diese Komponenten sollten möglichst agnostisch gegenüber dem Rest der Komponenten sein (außer das alle Komponenten natürlich das Protokoll auf diesem Bus beherrschen müssen wissen die üblicherweise nichts über alles was sonst noch so an diesem Bus hängt) auch die CPU interessiert sich nicht dafür was wo ist und wie diese Komponenten funktionieren (das ist Aufgabe der Software also der Gerätetreiber die ihr jeweiliges Gerät gegenüber einer generischen Schnittstelle im Betriebssystem passend darstellen), die CPU muss dazu nur Befehle wie Speicherlesen und Speicherschreiben beherrschen (und das dann natürlich mit dem richtigen Protokoll auf den Bus bringen) damit die Software das kann.
Mit einem IDE-Treiber würde ich nicht als erstes anfangen, ich würde eher die Serielle Schnittstelle als Anfang empfehlen obwohl da leider die Gefahr besteht das Du sowas gar nicht mehr in Deinem PC hast (was aber auf IDE ebenfalls zutrifft, falls Du im BIOS bereits auf AHCI-Modus umgestellt hast). Es geht natürlich auch irgendein Emulator (Qemu/VirtualBox/...) die können alle noch eine echte Serielle Schnittstelle anbieten und diese auch im Host-OS als virtuellen Port zur Verfügung stellen so das auf dem Host-System wieder ein Programm (das natürlich die API des Host-OS benutzen muss) der passende Kommunikationspartner ist.
Für den zweiten Schritt ist IDE aber eine gute Wahl wobei ich hier auch auf einen Emulator setzen würde (schon damit Du nicht aus Versehen Deine echte HDD killst).
Grüße
Erik
SCNR
OjeIch glaube ebenfalls das Deine Vorstellung davon wie Hardware funktioniert noch nicht so ganz richtig ist, ebenso von dem Zusammenspiel zwischen Software und Hardware.
Keine Hardware-Komponente hat eine exklusive Verbindung zur CPU, ist spätestens bei mehreren CPUs auch Unsinn. Ein Bussystem in einem Computer stellt die Verbindung zwischen 2 Komponenten immer nur für eine kurze Zeit her damit diese 2 Komponenten eine kleine Hand voll Daten in eine der beiden Richtungen austauschen können. Ein solcher Austausch wird üblicherweise Transfer genannt und stellt einen in sich abgeschlossenen Lesezugriff oder Schreibzugriff dar (pro Zugriff kann aber mehr als ein Byte oder ein Word übertragen werden, das nennt sich dann Burst oder Block-Transfer). Für alles was komplexer ist werden mehrere unabhängige Transfers benutzt (wo dazwischen sogar der Bus von anderen Komponenten benutzt werden kann). In dem von Dir verlinkten Wikipedia-Artikel gibt es gar keine Beschreibung wie ein Datenbus in einem Computer im Detail funktioniert, dafür ist dort der NuBus verlinkt und in dessen Wikipedia-Artikel ist die zugehörige Spezifikation verlinkt. Das sind relativ wenige Seiten Text und der NuBus ist vom Feature-Umfang noch recht überschaubar und würde ungefähr das bieten was Du aktuell brauchst (was jetzt keine Aufforderung sein soll diesen Bus umzusetzen sondern das ist nur ein Hinweis auf eine Technologie in ungefähr der benötigten Gewichtsklasse). Ich hab mir die Spezifikation gerade mal durchgelesen und empfinde die als einigermaßen verständlich geschrieben und es sind auch keine zu komplexen Sachen drin (der NuBus kennt z.B. keine Bridges u.ä. so das es immer nur einen einzigen NuBus in einem System gibt was die Sache fürs erste unheimlich vereinfacht).
Ein Bussystem in einem Computer ist im Ideal absolut agnostisch gegenüber allen angeschlossenen Komponenten und auch diese Komponenten sollten möglichst agnostisch gegenüber dem Rest der Komponenten sein (außer das alle Komponenten natürlich das Protokoll auf diesem Bus beherrschen müssen wissen die üblicherweise nichts über alles was sonst noch so an diesem Bus hängt) auch die CPU interessiert sich nicht dafür was wo ist und wie diese Komponenten funktionieren (das ist Aufgabe der Software also der Gerätetreiber die ihr jeweiliges Gerät gegenüber einer generischen Schnittstelle im Betriebssystem passend darstellen), die CPU muss dazu nur Befehle wie Speicherlesen und Speicherschreiben beherrschen (und das dann natürlich mit dem richtigen Protokoll auf den Bus bringen) damit die Software das kann.
Mit einem IDE-Treiber würde ich nicht als erstes anfangen, ich würde eher die Serielle Schnittstelle als Anfang empfehlen obwohl da leider die Gefahr besteht das Du sowas gar nicht mehr in Deinem PC hast (was aber auf IDE ebenfalls zutrifft, falls Du im BIOS bereits auf AHCI-Modus umgestellt hast). Es geht natürlich auch irgendein Emulator (Qemu/VirtualBox/...) die können alle noch eine echte Serielle Schnittstelle anbieten und diese auch im Host-OS als virtuellen Port zur Verfügung stellen so das auf dem Host-System wieder ein Programm (das natürlich die API des Host-OS benutzen muss) der passende Kommunikationspartner ist.
Für den zweiten Schritt ist IDE aber eine gute Wahl wobei ich hier auch auf einen Emulator setzen würde (schon damit Du nicht aus Versehen Deine echte HDD killst).
Grüße
Erik
Vier Räder, große Fenster, viele Sitze, ... wie ein Bus halt.Also hier in Nürnberg haben die meisten Busse mehr als 4 Räder (also auf der Straße, zusätzlich zu Lenkrad und Reserverad). Dafür sind die Fenster nur noch eingeschränkt nutzbar da die von Außen mit Spam zugekleistert sind.
SCNR
So hab jetzt mal ein komplettes Konzept gemacht: (hab einen roten Pfeil zum Adress-rechenwerk vergessen )
roter Pfeil = Steuer-Daten.
Blauer Pfeil = Adressen
Schwarzer Pfeil = Daten
Habe mich für eine einfache Harvard-Architektur für den Bus entschieden.
Ich hab jetzt mal den Ram in die CPU integriert. Dadurch kann ohne einen System-bus (also BREQ und BGRT ) zum Beispiel Daten vom Ram in ein I/O-Port laden.
Zudem habe ich meine alte CPU-architektur verwendet und ein paar verbesserungen durchgeführt. Zum Beispiel gehört jetzt der ProgrammCounter (ProgrammP) zu den Registern. Es gibt immernoch die alten Pointer-Register ( Stack-, Frame und Adresspointer) nur wird jetzt die adresse im Adress-Rechenwerk zusammengesetz.(hab mir das so gedacht das man wählen kann ob frame und Stackpointer die adresse angeben oder das der adresspointer allein die adresse angibt.
Und wie findet ihr fiesmal mein Konzept
roter Pfeil = Steuer-Daten.
Blauer Pfeil = Adressen
Schwarzer Pfeil = Daten
Habe mich für eine einfache Harvard-Architektur für den Bus entschieden.
Ich hab jetzt mal den Ram in die CPU integriert. Dadurch kann ohne einen System-bus (also BREQ und BGRT ) zum Beispiel Daten vom Ram in ein I/O-Port laden.
Zudem habe ich meine alte CPU-architektur verwendet und ein paar verbesserungen durchgeführt. Zum Beispiel gehört jetzt der ProgrammCounter (ProgrammP) zu den Registern. Es gibt immernoch die alten Pointer-Register ( Stack-, Frame und Adresspointer) nur wird jetzt die adresse im Adress-Rechenwerk zusammengesetz.(hab mir das so gedacht das man wählen kann ob frame und Stackpointer die adresse angeben oder das der adresspointer allein die adresse angibt.
Und wie findet ihr fiesmal mein Konzept
Hallo,
Für gewöhnlich baut man CPUs mit einem externen Bussystem nach außen (zu RAM und Hardware, oft multimasterfähig) und einem internen Bussystem, welches die Register, ALU, Befehlsdecoder usw. miteinander und mit dem externen Bussystem verbindet. Das macht man, damit die Hardware - einen Treiber vorausgesetzt - unabhängig von der CPU funktionieren kann (z.B. gibt es den EISA-Bus auf x86- und MIPS-Maschinen und den PCI-Bus auf x86, x86_64, ARM, PowerPC u.v.m.). Die Hardware hat es nicht zu interessieren, welche Register die CPU nun hat.
Dein Konzept sieht jedenfalls nach außen funktionsfähig aus. Den internen Aufbau hätte ich anders gelöst, aber es sollte funktionieren. Durch die fixe Verdrahtung von ProgramP an das ROM und ROM an den Befehlsdekoder sind Disketten/Festplatten für Programme aber nutzlos.
Gruß,
Svenska
Habe mich für eine einfache Harvard-Architektur für den Bus entschieden.Für die CPU, nicht für den Bus.
Ich hab jetzt mal den Ram in die CPU integriert. Dadurch kann ohne einen System-bus (also BREQ und BGRT ) zum Beispiel Daten vom Ram in ein I/O-Port laden.Hmm, also BREQ/BGRT brauchst du nur, wenn dein Bussystem multimasterfähig sein soll. Lässt du die Signale weg und definierst einen fixen Master (die CPU), ist es trotzdem ein Bus. Es ist sogar ein System-Bus, weil du nur einen Typ von Adressen kennst und daran alles, inklusive der Register, angeschlossen ist. Praktisch heißt das, dass für das Betriebssystem kein Unterschied zwischen CPU-Registern und RAM mehr besteht.
Für gewöhnlich baut man CPUs mit einem externen Bussystem nach außen (zu RAM und Hardware, oft multimasterfähig) und einem internen Bussystem, welches die Register, ALU, Befehlsdecoder usw. miteinander und mit dem externen Bussystem verbindet. Das macht man, damit die Hardware - einen Treiber vorausgesetzt - unabhängig von der CPU funktionieren kann (z.B. gibt es den EISA-Bus auf x86- und MIPS-Maschinen und den PCI-Bus auf x86, x86_64, ARM, PowerPC u.v.m.). Die Hardware hat es nicht zu interessieren, welche Register die CPU nun hat.
Dein Konzept sieht jedenfalls nach außen funktionsfähig aus. Den internen Aufbau hätte ich anders gelöst, aber es sollte funktionieren. Durch die fixe Verdrahtung von ProgramP an das ROM und ROM an den Befehlsdekoder sind Disketten/Festplatten für Programme aber nutzlos.
fiesmalNe, ich denke, diesmal brauch ich nicht fies sein. Ist ja Weihnachten und so.
Gruß,
Svenska
Nun, sollte eigentlich das Konzept für ein Micro-Controller sein (hab in "Hirn X73" getauft ), da ist es glaub nicht so wichtig ob das externe Bus-system unabhängig vom CPU läuft oder ?
Hallo,
Microcontroller haben üblicherweise keinen externen (d.h. nach außen geführten) Bus, sondern Ports. Trotzdem müssen sie einen (oder mehrere) internen Bus, über den die Komponenten miteinander kommunizieren. Stell dir einfach einen Mikrocontroller als einen Mikroprozessor (CPU) mit eingebauter Zusatzhardware vor...
Gruß,
Svenska
Microcontroller haben üblicherweise keinen externen (d.h. nach außen geführten) Bus, sondern Ports. Trotzdem müssen sie einen (oder mehrere) internen Bus, über den die Komponenten miteinander kommunizieren. Stell dir einfach einen Mikrocontroller als einen Mikroprozessor (CPU) mit eingebauter Zusatzhardware vor...
Gruß,
Svenska
Mhh, ich glaub ich bau doch ein Micrp-Computer... gibt es eigentlich neben Logisim und als Zellulärer Automat noch andere Möglichkeiten wo man mein Projekt umsetzen könnte ?
Hallo,
das hängt davon ab, was du genau möchtest... für eine Simulation von Logik mit Gattern habe ich mal KLogic benutzt (taugte aber nicht viel), KSimus wirkte stabiler, aber komplizierter. Kannst dich ja hier mal umschauen. Die professionellere Variante - mit grausamer Lernkurve - geht dann in Richtung CPLD-/FPGA-Programmierung mit VHDL oder Verilog. Auch dafür gibt es Simulatoren, aber da hält sich meine Erfahrung in Grenzen. Damit läufst du in Richtung "CPU" mit ein bisschen angebastelter Hardware (RAM, LEDs o.ä.).
Wenn du eher in Richtung "Computer" laufen möchtest (also Hardware wie Display/Tastatur/... mit einer programmierbaren CPU drin), dann gibt es dort die teure und sehr aufwändige Möglichkeit, alles diskret mit z.B. 74xx-Bausteinen aufzubauen (Beispiele hier oder hier). Das läuft aber eher auf Jahre statt Monate hinaus. Dann kannst du auch fertige Mikrocontroller (z.B. einen oder mehrere AVR) nehmen, die CPU in Software simulieren und eine Hardwareplattform außenrum zimmern (siehe z.B. hier, aber das ist schon recht extrem). Zu guter Letzt kannst du auch eine alte, vorhandene CPU-Architektur (z.B. Z80, 68000, 6502) nehmen und eine Hardwareplattform darum aufbauen. Fakt ist aber, dass du nicht weit über die Leistungsklasse der 80er Jahre hinauskommst (d.h. irgendwo bei 4 MB RAM und 16 MHz ist dann die Schmerzgrenze erreicht).
Musst mal schreiben, was du überhaupt bauen möchtest.
Gruß,
Svenska
das hängt davon ab, was du genau möchtest... für eine Simulation von Logik mit Gattern habe ich mal KLogic benutzt (taugte aber nicht viel), KSimus wirkte stabiler, aber komplizierter. Kannst dich ja hier mal umschauen. Die professionellere Variante - mit grausamer Lernkurve - geht dann in Richtung CPLD-/FPGA-Programmierung mit VHDL oder Verilog. Auch dafür gibt es Simulatoren, aber da hält sich meine Erfahrung in Grenzen. Damit läufst du in Richtung "CPU" mit ein bisschen angebastelter Hardware (RAM, LEDs o.ä.).
Wenn du eher in Richtung "Computer" laufen möchtest (also Hardware wie Display/Tastatur/... mit einer programmierbaren CPU drin), dann gibt es dort die teure und sehr aufwändige Möglichkeit, alles diskret mit z.B. 74xx-Bausteinen aufzubauen (Beispiele hier oder hier). Das läuft aber eher auf Jahre statt Monate hinaus. Dann kannst du auch fertige Mikrocontroller (z.B. einen oder mehrere AVR) nehmen, die CPU in Software simulieren und eine Hardwareplattform außenrum zimmern (siehe z.B. hier, aber das ist schon recht extrem). Zu guter Letzt kannst du auch eine alte, vorhandene CPU-Architektur (z.B. Z80, 68000, 6502) nehmen und eine Hardwareplattform darum aufbauen. Fakt ist aber, dass du nicht weit über die Leistungsklasse der 80er Jahre hinauskommst (d.h. irgendwo bei 4 MB RAM und 16 MHz ist dann die Schmerzgrenze erreicht).
Musst mal schreiben, was du überhaupt bauen möchtest.
Gruß,
Svenska
Nun will eigentlich schon was richtung Computer bauen, soll aber nur maximal so komplex sein wie ein apple 1.
Ersetze mal "Apple 1" durch "C64" oder "CP/M-basierender Heimcomputer der 80er", dann ist das vermutlich einfacher.
Schreib mal auf, was du konkret willst:
- Was soll es können? Das solltest du am Anfang relativ genau wissen (kannst es ja später noch ändern), aber das ist dein Ziel - und gibt an, wann das Projekt "fertig" ist.
- Was kannst du? Wenn du dich in jedes Thema einarbeiten musst, kannst du für komplexere Themen gern mal 1-2 Monate zusätzlich veranschlagen, bis du weißt, was du wie tun kannst, damit es funktioniert.
- Soll es eine Hardware werden oder eine Simulation? Ersteres kann ziemlich ins Geld gehen und ist viel mehr Aufwand, dafür ist die Freude am Ende größer. Setzt natürlich auch Messgeräte voraus (2 gute Multimeter sind Minimum) und ein Grundverständnis von Elektro-/Digitaltechnik (also U, I, R, C, L, Tri-State, PullUp-/PullDown-Widerstände und sowas).
Erst wenn du das Ziel kennst, solltest du loslaufen - den Weg findest du notfalls unterwegs.
Gruß,
Svenska
Schreib mal auf, was du konkret willst:
- Was soll es können? Das solltest du am Anfang relativ genau wissen (kannst es ja später noch ändern), aber das ist dein Ziel - und gibt an, wann das Projekt "fertig" ist.
- Was kannst du? Wenn du dich in jedes Thema einarbeiten musst, kannst du für komplexere Themen gern mal 1-2 Monate zusätzlich veranschlagen, bis du weißt, was du wie tun kannst, damit es funktioniert.
- Soll es eine Hardware werden oder eine Simulation? Ersteres kann ziemlich ins Geld gehen und ist viel mehr Aufwand, dafür ist die Freude am Ende größer. Setzt natürlich auch Messgeräte voraus (2 gute Multimeter sind Minimum) und ein Grundverständnis von Elektro-/Digitaltechnik (also U, I, R, C, L, Tri-State, PullUp-/PullDown-Widerstände und sowas).
Erst wenn du das Ziel kennst, solltest du loslaufen - den Weg findest du notfalls unterwegs.
Gruß,
Svenska
Zitat
- Was soll es können? Das solltest du am Anfang relativ genau wissen (kannst es ja später noch ändern), aber das ist dein Ziel - und gibt an, wann das Projekt "fertig" ist.Nun ne einfache Textausgabe mit ner Tastatureingabe würde mir reichen.
Zitat
- Was kannst du? Wenn du dich in jedes Thema einarbeiten musst, kannst du für komplexere Themen gern mal 1-2 Monate zusätzlich veranschlagen, bis du weißt, was du wie tun kannst, damit es funktioniert.Einiges, z.b das Ohmsche Gesetz, die Logik-Gatter , einigermaßen C++, grundkenntnisse im Löten zudem hab ich hier http://www.netzmafia.de/skripten/index.html fast alle Skripte im Thema Hardware und Betriebsysteme gelesen.
Zitat
- Soll es eine Hardware werden oder eine Simulation? Ersteres kann ziemlich ins Geld gehen und ist viel mehr Aufwand, dafür ist die Freude am Ende größer. Setzt natürlich auch Messgeräte voraus (2 gute Multimeter sind Minimum) und ein Grundverständnis von Elektro-/Digitaltechnik (also U, I, R, C, L, Tri-State, PullUp-/PullDown-Widerstände und sowas).Mhh Hardware wäre natürlich am schönsten, leider habe ich weder einen Lötkolben noch ein Netzteil oder ein Multimeter (wird aber ihrgentwann so sein das ich mir wegen der Schule die sachen zulegen werde.). Daher wird es wohl zunächst auf den simulator hinaus laufen.
Hallo,
für ne Hardware würde ich dir dann nen AVR mit HD44780 (Textdisplay) und ein paar I/O-Pins für eine PS/2-Tastatur empfehlen. Damit eine Textausgabe zu programmieren ist relativ einfach. Ob das dann allerdings als "Computer" zählt...
Gruß,
Svenska
für ne Hardware würde ich dir dann nen AVR mit HD44780 (Textdisplay) und ein paar I/O-Pins für eine PS/2-Tastatur empfehlen. Damit eine Textausgabe zu programmieren ist relativ einfach. Ob das dann allerdings als "Computer" zählt...
Gruß,
Svenska
Nun wie schwer wird es nen Einplatinen-Computer aufzubauen ?
Und wieso ist das eigentlich komplexer wie ein C64 ?
Und wieso ist das eigentlich komplexer wie ein C64 ?
- Lowlevel »
- OffZone »
- Offtopic »
- Thema: Logisim CPU