Forum: Mikrocontroller und Digitale Elektronik Eigene CPU: Architektur?


von Christoph B. (chr_b)


Angehängte Dateien:

Lesenswert?

edit:  hust hust  Mir ist gerade noch aufgefallen, dass sich bei den 
letzten beiden Dateien ein kleiner Fehler eingeschlichen hat. Das kommt 
davon, wenn man lustig Tabellenzeilen hin- und herschiebt... ;-) Wer ihn 
findet, darf ihn gerne behalten.

-------------------------------

Hallo miteinander,

ich habe schon seit längerer Zeit ein Projekt vor Augen und habe mich 
endlich mal damit befassen können.
Und zwar geht es darum, dass ich mir gerne eine kleine CPU entwerfen und 
diese dann auch hardwaremäßig (mit Logikbausteinen) unsetzen würde.

Vorweg schon einmal: Ich bein KEIN Profi und beschäftige mich mit 
Hardware, Mikrocontrollern, (Digital-)elektronik "nur" als Hobby neben 
dem trockenem Informatikstudium...
Habt deswegen bitte ein wenig Nachsicht mit mir. Das Ganze soll 
natürlich auch einen gewissen Lerneffekt haben, aber an erster Stelle 
Spaß machen.

Aber was will ich denn überhaupt hier?
Ich habe mir mal ein paar Gedanken zu einer möglichen Architektur und 
passenden Komponenten gemacht. Das habe ich mal aufs "Papier" gebracht 
und angefügt.
Vielleicht kann mir jemand von euch sagen, ob das schon mal ganz 
sinnvoll aussieht, oder ob ich mich da verrannt habe und das so nichts 
wird?

Das Ganze soll eine 8-Bit CPU werden mit eben 8-Bit breiten Daten- und 
Adressbussen. Ich habe ein Akkumulatorregister, welches immer auf den 
ersten Eingang der ALU geht und ein Cache-Register als Zwischspeicher.
AC, AZ und AN sind Flags für Überlauf, Null (Zero) und Indikator, ob im 
Akkumulator eine negative Zahl steht.
Desweiteren habe ich mir überlegt, dass die Clock den "State counter" 
treibt, der bei jeder Flanke den nächsten Ausgang schaltet, was zur 
Folge hat, dass eine der unten rechts im der Zeichnung aufgeführten 
Befehle abgearbeitet wird.
Also (jew. 1 Takt):
- Befehl aus Adresse im "CMD_ADDR COUNTER" aus dem RAM holen und an das 
Register DATA_COMMAND legen
- Register DATA_COMMAND setzen
- Datenwort aus dem RAM holen und an das Register DATA_WORD legen
- Register DATA_WORD setzen
- CMD_ADDR um 1 erhöhen
- Befehl und Daten an den Command decoder geben, dieser schaltet alles 
nötige, bzw. führt den Befehl aus und legt die neuen Daten an die 
restlichen Register an
- Die restlichen Register (ACCU, CACHE), die Flags, evtl. R/W am I/O Bus 
oder /CE am Display werden gesetzt

Das ist natürlich nicht sonderlich performant oder optimiert, aber recht 
simpel wie ich finde. Oder gäbe es da irgendwelche (technischen) 
Einwände? Ist das evtl. sogar eine total doofe Idee?
Habe ich ansonsten noch irgendetwas wichtiges vergessen oder gibt es 
eurer Meinung nach sonstige Fehler in meinen Überlegungen oder sonstige 
grobe Schnitzer?

Habe mir auch schon mal basierend auf meiner Architektur einen 
Befehlssatz herausgearbeitet und aufgeschrieben (Anhang). Ist das gut 
so? Habe ich auch hier evtl. irgendetwas vergessen/übersehen/nicht 
bedacht/etc.?

Hatte mir auch schon einige Logikbausteine rausgesucht (74HCxx Reihe) 
und auch schon kommen lassen, um damit mal ein wenig zu basteln und zu 
schauen, was wie geht.
Hätte zur Hardware vor allen Dingen mal ein paar (ganz doofe) Fragen:
- Für die Register kann ich doch einfach D-FlipFlops (wie 74HC377) 
nehmen und diese dann einfach bei L->H Taktflanke der Clock setzen wenn 
im Takt davor die Zuleitungen gesetzt wurden, oder?
Weil das Lesen aus dem RAM und die Berechnungen der ALU usw. dauern ja 
einen Moment, sodass ich nicht gleichzeitig das Register setzen kann. 
Auf dem Steckbrett funktioniert das mit einem D-FF soweit...
- Ich bräuchte natürlich auch einige Multiplexer, habe aber nur den 
74HC157 gefunden, das ist ein 4 x 2:1 MUX. Bräuchte für ein Wort dann 
aber immer schon 2. Gibt es evtl. das Ganze in 8Bit? Also quasi 8 x 2:1 
MUX?
- Als RAM-Baustein hatte ich mir diesen rausgesucht: 
http://www.reichelt.de/Drams-Srams/6264-70/3/index.html?;ACTION=3;LA=5;ARTICLE=2676;GROUPID=2954;artnr=6264-70
Dürfte doch gehen, oder? Von der Ansteuerung sieht das ja ganz einfach 
aus und die 8K bekomme ich ja nie im Leben voll.
Also könnte ich von den Adressbits 8 für meine Adressbreite abzweigen 
und den Rest dann für die Unterscheidung von Befehlsspeicher, 
Datenspeicher, vielleicht ja sogar auch noch internen RAM...?!
- Dann macht mir eine kleine Sache noch Sorgen: Wenn ich das mit dem 
State counter so mache, lese ich im einen Takt aus meinem RAM und setzte 
im nächsten das Register.
D.h. den Ausgang für das R/W für den RAM muss ich da verODERn mit dem 
Ausgang für das Register-Setzen. Als State counter habe ich hier einen 
74HC4017.
Bin allerdings aus dem Datenblatt nicht schlau geworden. Wenn der Output 
wechselt, habe ich dann eine kurze Zeit, in der an keinem Output was 
anliegt? Es sieht irgendwie so aus, als ob das gleichzeitig passiert, 
das kann ich mir aber irgendwie nicht vorstellen.
Denn sobald an einem der Outputs nichts mehr anliegt, verliere ich das 
Signal R/W für das RAM und ich müsste dann im nächsten Takt nochmal 
auslesen, was dann aber Zeit kostet und das Register aber schon gesetzt 
wird. Oder wie lange kann maximal das R/W am RAM weg?
Versteht jemand, was ich meine? :-)

Ansonsten hoffe ich mal, dass ich einigermaßen klarmachen konnte, wie 
ich mir das vorgestellt habe und dass nicht schon einige vor Lachen auf 
dem Boden liegen. Wie gesagt: Ich lese viel und habe mein "Wissen" auch 
nur daher.
Bitte seid nicht böse, wenn ich an der ein oder anderen Stelle mal nicht 
so weiter weiß oder einfach mal auf dem Schlauch stehe. Ich lern' ja 
noch... ;-)

Es würde mich sehr freuen, wenn vllt. jemand auf meine Fragen eingehen 
könnte, bzw. mir auch sagen könnte, ob das Vorhaben machbar ist (dass 
das kein Wochenendprojekt ist, ist mir ja auch klar), oder ob ich mich 
da total übernommen habe und mir das Ganze dann doch zu einfach 
vorstelle.
Ich würde das Projekt wirklich gerne umsetzen.

Besten Gruß,
Christoph

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Was unterscheidet deine CPU von den gefühlten 700 anderen Versionen?

von foo (Gast)


Lesenswert?

Man lernt einiges dabei mal seine eigene CPU entwerfen und zumindest auf 
Register-Transfer-Ebene zu simulieren.

von Mops Fidibus (Gast)


Lesenswert?

Hat doch Josef G. schon fertig entwickelt, ganz modern im FPGA. Was 
willste das Rad neu erfinden?

von Juergen G. (jup)


Lesenswert?

Na klar doch, und weil es schon gefuehlte 5Mio Led-Blinkprogramme fuer 
uC's gibt braucht ein uC-Einsteiger ja keins mehr zu schreiben.

von Mops Fidibus (Gast)


Lesenswert?

Na klar doch, Blinkprogramme und eigene CPUs sind ja fast dasselbe :) 
Josef G. hat wirklich was Perfektes auf die Beine gestellt.  Warum soll 
man darauf nicht zurückgreifen?

von Borislav B. (boris_b)


Lesenswert?

Weil es nicht um das Endergebnis geht, sondern der Weg das Ziel ist?

von (prx) A. K. (prx)


Lesenswert?

Adressbreiten/grössen konnte ich der Beschreibung nicht entnehmen. Geht 
es um Programme mit maximal 2stelliger Anzahl Operationen? Oder soll es 
dann doch eine prinzipiell vollständige CPU sein?

Denn wie gestalten sich bei dir Unterprogrammaufrufe?

Indirekte/berechnete Adressierung, beispielsweise um die Chars in 
Strings durchzudackeln, erfolgt über selbstmodifizierenden Code? Sonst 
sehe ich dazu nichts.

von derp (Gast)


Lesenswert?

Zu der oben erwähnten CPU von Josef gibt es hier einen Artikel:

http://www.mikrocontroller.net/articles/8bit-Rechner

von (prx) A. K. (prx)


Lesenswert?

Die Entwicklungen anderer Leute einfach nachzubauen beweist nur, dass 
man lesen und löten oder FPGAs programmieren kann. Darum wird es hier 
wohl kaum gehen.

von (prx) A. K. (prx)


Lesenswert?

Christoph B. schrieb:
> - Die restlichen Register (ACCU, CACHE)

Wenn du das Verständnis fördern willst, dann vermeide Begriffe, die 
bereits mit völlig anderer Bedeutung besetzt sind. Wie Cache.

von Christoph B. (chr_b)


Angehängte Dateien:

Lesenswert?

Hallo,

vielen Dank zuächst für die zahlreichen Antworten!

Abdul K. schrieb:
> Was unterscheidet deine CPU von den gefühlten 700 anderen
> Versionen?

Mops Fidibus schrieb:
> Hat doch Josef G. schon fertig entwickelt, ganz modern im FPGA.
> Was
> willste das Rad neu erfinden?

Meine CPU habe ich selbst entworfen und verstanden. Ich möchte ja nicht 
etwas noch nie dagewesenes machen oder das Rad neu erfinden, aber:

Juergen G. schrieb:
> Na klar doch, und weil es schon gefuehlte 5Mio Led-Blinkprogramme
> fuer
> uC's gibt braucht ein uC-Einsteiger ja keins mehr zu schreiben.

A. K. schrieb:
> Die Entwicklungen anderer Leute einfach nachzubauen beweist nur,
> dass
> man lesen und löten oder FPGAs programmieren kann. Darum wird es hier
> wohl kaum gehen.

Boris B. schrieb:
> Weil es nicht um das Endergebnis geht, sondern der Weg das Ziel
> ist?

Genau das! Noch soll es das Nonplusultra werden, sondern als Projekt zum 
Lernen, Verstehen, Tüfteln, Basteln und Freude dran haben dienen.

Ich schaue mir das genannte Projekt sehr gerne an, danke für den 
Hinweis!

foo schrieb:
> Man lernt einiges dabei mal seine eigene CPU entwerfen und
> zumindest auf
> Register-Transfer-Ebene zu simulieren.

Ja - mit dem Simulieren habe ich auch schon angefangen. Ist nur ein 
wenig schwierig, mit den entsprechenden ICs das Ganze zu machen. Ich 
baue bisher eher Teilkomponenten immer erst auf dem Steckbrett auf und 
gucke, was rein- und rauskommt. Aber eine schlechte Idee ist das 
Simulieren sicher nicht!

A. K. schrieb:
> Christoph B. schrieb:
>> - Die restlichen Register (ACCU, CACHE)
>
> Wenn du das Verständnis fördern willst, dann vermeide Begriffe, die
> bereits mit völlig anderer Bedeutung besetzt sind. Wie Cache.

Das stimmt natürlich. Ist geändert. Danke!

A. K. schrieb:
> Adressbreiten/grössen konnte ich der Beschreibung nicht entnehmen.
> Geht
> es um Programme mit maximal 2stelliger Anzahl Operationen? Oder soll es
> dann doch eine prinzipiell vollständige CPU sein?
>
> Denn wie gestalten sich bei dir Unterprogrammaufrufe?
>
> Indirekte/berechnete Adressierung, beispielsweise um die Chars in
> Strings durchzudackeln, erfolgt über selbstmodifizierenden Code? Sonst
> sehe ich dazu nichts.

Register- und Busbreiten habe ich jetzt drangeschrieben. 
Unterprogrammaufrufe kann ich doch über die bedingten und unbedingten 
Sprungbefehle realisieren, oder? Nur hatte ich nicht beachtet, dass die 
'Rücksprungadresse' ja irgendwie gespeichert werden muss. Habe einen 
entsprechenden Befehl eingefüht, der dann die aktuelle Befehlsadresse 
holt (,die dann irgendwo hingesetzt werden kann). Danach kann ich ja 
wieder an die gespeicherte Adresse (+1) springen. Danke für die 
Hinweise!

Bin weiterhin für jede Kritik dankbar...

von Uwe (Gast)


Lesenswert?

Lade dir Quartus II von Altera runter.
Da kann man simulieren.
Die Codeeingabe kann in VHDL oder sonstwas gemacht werden.
Es ist auch möglich Symbolisch zu arbeiten mit FlipFlops und Gattern, 
Tristte und Muxen. Da sind glaube ich auch noch die ganzen 74xxx und so 
als  Bausteine drinne.

von (prx) A. K. (prx)


Lesenswert?

Verstehe ich es richtig, dass alle Befehle aus 8-Bit Opcode und 8-Bit 
Operand bestehen, wobei vom Opcode bisher nur 5 Bits genutzt werden? Der 
Operand ist je nach Opcode eine Konstante, eine Code/Daten-Adresse oder 
unbenutzt?

Da das RAM anscheindend ausschliesslich per PC adressiert wird, sind 
alle möglichen Variablen ausserhalb der A/B-Register direkt die 
Operanden von Befehlen? Interessanter Ansatz, aber mir schwant, dass man 
damit nicht weit kommt.

von (prx) A. K. (prx)


Lesenswert?

Mit 2x 74HC670 beispielsweise an Stelle entweder des A- oder des 
B-Registers lassen sich dort mit geringstem Aufwand 4 Register 
realisieren. Was wohl ein paar Probleme lösen könnte, denn dann gibts 
immerhin ein paar echte adressierbare Variablen.

von Christoph B. (chr_b)


Lesenswert?

Uwe schrieb:
> Lade dir Quartus II von Altera runter.
> Da kann man simulieren.
> Die Codeeingabe kann in VHDL oder sonstwas gemacht werden.
> Es ist auch möglich Symbolisch zu arbeiten mit FlipFlops und Gattern,
> Tristte und Muxen. Da sind glaube ich auch noch die ganzen 74xxx und so
> als  Bausteine drinne.

Lädt! Hatte schon mit der Xilinx ISE versucht, irgendwelche 74xxxx Libs 
einzubinden, aber das war mehr so ein Topfschlagen... Ich schau mal, was 
sich damit anstellen lässt.

A. K. schrieb:
> Verstehe ich es richtig, dass alle Befehle aus 8-Bit Opcode und 8-Bit
> Operand bestehen, wobei vom Opcode bisher nur 5 Bits genutzt werden? Der
> Operand ist je nach Opcode eine Konstante, eine Code/Daten-Adresse oder
> unbenutzt?

Ja, bzw. sind die Busse für die CPU Opcodes auch nur 5 Bit breit.

A. K. schrieb:
> Da das RAM anscheindend ausschliesslich per PC adressiert wird, sind
> alle möglichen Variablen ausserhalb der A/B-Register direkt die
> Operanden von Befehlen? Interessanter Ansatz, aber mir schwant, dass man
> damit nicht weit kommt.

Du meinst, dass ich quasi zu wenig Platz habe, um irgendwas 
zwischenzuspeichern und dass die beiden Register nicht reichen? Ja - das 
habe ich auch schon gedacht. Generell könnte ich am I/O Bus ja auf ein 
RAM zugreifen, aber dann ist der auch wieder belegt. Also eigentlich 
könnte ich Werte ja mit festen Adressen in einen zusätzlichen 
RAM-Baustein legen... Dann hätte ich 256 adressierbare, zusätzliche 
Register. Wäre das eine gute Idee? Wenn ich mir noch zwei Befehle biege, 
um aus der RAM-Adresse x in den ACCU zu schreiben und umgekehrt den 
Inhalt vom ACCU an die RAM-Adresse x zu schreiben, sollte das ja machbar 
sein. Oder irre ich mich da?

A. K. schrieb:
> Mit 2x 74HC670 beispielsweise an Stelle entweder des A- oder des
> B-Registers lassen sich dort mit geringstem Aufwand 4 Register
> realisieren. Was wohl ein paar Probleme lösen könnte, denn dann gibts
> immerhin ein paar echte adressierbare Variablen.

Davon habe ich mir auch welche mitbestellt, danke für den Tipp! Würde 
sich dann aber durch eine Extra-RAM-Lösung auch erledigen, oder?

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Christoph B. schrieb:
> Abdul K. schrieb:
>> Was unterscheidet deine CPU von den gefühlten 700 anderen
>> Versionen?
>
> Mops Fidibus schrieb:
>> Hat doch Josef G. schon fertig entwickelt, ganz modern im FPGA.
>> Was
>> willste das Rad neu erfinden?
>
> Meine CPU habe ich selbst entworfen und verstanden. Ich möchte ja nicht
> etwas noch nie dagewesenes machen oder das Rad neu erfinden, aber:
>

Dann habe ich das überlesen, daß du das Teil nur zum Lernen entwickelst. 
Aus der Sicht anderer ist es eben wichtig, zu wissen ob es irgendwelche 
Mängel anderer Architekturen behebt und damit einen Blick wert ist. 
Ansonsten schränkt sich der Kreis der Interessierten halt nur auf die 
Kreise ein, die Freude am CPU-entwickeln haben.


Ich schwöre ja auf diesen Mann hier und vermutlich ist seine CPU daher 
auch nicht gerade schlecht:
http://www.holmea.demon.co.uk/GPS/Main.htm

von Jörn T. (kleinergruenerkaktus)


Lesenswert?

@Christoph B.
Ich bin auch gerade beim Aufbau einer eigenen CPU, allerdings auf 4bit 
und TTL Basis in Anlehnung an einen Schaltplan aus den 80ern. Vielleicht 
kann man sich ja austauschen. Meine Takteinheit steht schon. Nicht 
Dolles aber ein erster Schritt.

http://www.youtube.com/watch?v=_-bqaRML-e4

von chris (Gast)


Lesenswert?

Um den Befehlssatz zu optimieren, könnte man sich einen einfachen 
Simulator schreiben ( z.B. in C oder Assembler ).

Vor einiger Zeit habe ich das mal für eine einfache Übungs-CPU gemacht, 
die ich im Internet gefunden habe. Den Simulator habe ich dann auf einem 
Atmega8 laufen lassen:
http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=24

von MaWin (Gast)


Lesenswert?

> Ich habe mir mal ein paar Gedanken zu einer möglichen Architektur und
> passenden Komponenten gemacht.

Wenn man das mit 74HCxx aufbauen will, dann sollte man eine Architektur 
wählen, bei der das nicht tausende von Bausteinen werden (so wie 
http://cpuville.com/). Denn das macht nicht nur Mühe im Aufbau, kostet 
Geld und ist fehler/störungsträchtig, sondern auch das Gegenteil von 
"egegant".

Es gibt schon einige TTL CPUs im Netz, such dir die raus, die die 
wenigsten (beschaffbaren) Bauteile benötigt, wie
http://repository.cmu.edu/cgi/viewcontent.cgi?article=1595&context=compsci&sei-redir=1&referer=http%3A%2F%2Fwww.google.de%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3Dminimal%2520homebrew%2520ttl%2520cpu%26source%3Dweb%26cd%3D6%26ved%3D0CFgQFjAF%26url%3Dhttp%253A%252F%252Frepository.cmu.edu%252Fcgi%252Fviewcontent.cgi%253Farticle%253D1595%2526context%253Dcompsci%26ei%3DG8buUcmXMtDQsgbLy4H4AQ%26usg%3DAFQjCNFJCarYW01FS7ahPOhQMqzRyabnPw#search=%22minimal%20homebrew%20ttl%20cpu%22


Ansonsten fährt man besser mit einem kleinen FPGA (Development Kit) und 
kann sich die CPU so oft umdefinieren, bis sie einem gefällt.

Achsoja: Das zweite Problem: Die Software:: So bald man die Hardware 
hat, will man auch was laufen lassen. Also sollte man kompatibel zu 
einer bestehenden CPU mit interessanten Programmen sein, damit man nicht 
jedes Programm selbst schreiben muss. Es bietet sich CP/M an, das gibt's 
inzwischen auch in Source. Oder eine Gameboy-kompatible Hardware.

von (prx) A. K. (prx)


Lesenswert?

Wenn man bedenkt, dass er sich auf 256 Bytes Code beschränkt, also 128 
Befehle, dann scheint es eher ums Prinzip als um reale Programme zu 
gehen.

von W.S. (Gast)


Lesenswert?

Christoph B. schrieb:
> Meine CPU habe ich selbst entworfen und verstanden. Ich möchte ja nicht
> etwas noch nie dagewesenes machen oder das Rad neu erfinden, aber:

... tja, ABER!
Ich hab das ziemlich bestimmte Gefühl, daß du dir da was auflädst, was 
du nicht tragen können wirst.

Das Entwerfen einer CPU ist ja ganz nett und macht bestimmt auch Spaß, 
aber mit der (hoffentlich) funktionierenden Hardware ist das Rennen ja 
nicht gewonnen, sondern fängt erst an: Wohin willst du dein Ding bauen? 
Externer Flash? Externer RAM? Peripherie? Leiterplatte? UND Womit 
willst du dein Ding dann programmeren? Hast du schon mal nen Assembler 
selber geschrieben?

Das alles ist ne Menge Holz und du solltest dich fragen, ob du es bis zu 
deiner Verrentung mit (ähem.. 67? 69? 71? ..?) noch zu Ende bekommst, 
ohne dir einen vorzeitigen Herzinfarkt zuzuziehen.

Also, nette Idee, aber bedenke die nervlichen Folgekosten.

W.S.

von Christoph B. (chr_b)


Lesenswert?

Abdul K. schrieb:
> Ich schwöre ja auf diesen Mann hier und vermutlich ist seine CPU daher
> auch nicht gerade schlecht:

Ja - die Seite zum Mark 1 FORTH Computer hatte ich auch schon beim 
Stöbern entdeckt...

Jörn T. schrieb:
> Ich bin auch gerade beim Aufbau einer eigenen CPU, allerdings auf 4bit
> und TTL Basis in Anlehnung an einen Schaltplan aus den 80ern. Vielleicht
> kann man sich ja austauschen. Meine Takteinheit steht schon. Nicht
> Dolles aber ein erster Schritt.

Sehr gerne. Hatte dir vor ein paar Tagen auch schon eine Nachricht über 
YT geschickt, ging um das Video davor... ;-)
Wie ist denn deine Planung momentan?

chris schrieb:
> Um den Befehlssatz zu optimieren, könnte man sich einen einfachen
> Simulator schreiben ( z.B. in C oder Assembler ).
>
> Vor einiger Zeit habe ich das mal für eine einfache Übungs-CPU gemacht,
> die ich im Internet gefunden habe. Den Simulator habe ich dann auf einem
> Atmega8 laufen lassen:

Oh ja - das sieht sehr interessant aus. Werde ich mir morgen (bzw. 
heute) in aller Ruhe anschauen. Vielen Dank!

MaWin schrieb:
> [...] Es gibt schon einige TTL CPUs im Netz, such dir die raus, die die
> wenigsten (beschaffbaren) Bauteile benötigt [...]

MaWin schrieb:
> Ansonsten fährt man besser mit einem kleinen FPGA (Development Kit) und
> kann sich die CPU so oft umdefinieren, bis sie einem gefällt.

Ja - das stimmt generell. Aber ich würde das Projekt gerne auf der Ebene 
aufbauen, also aus Gattern, FFs, MUXen... So wie eben auch die 
Architektur ungefähr aussieht. Außerdem...

MaWin schrieb:
> Also sollte man kompatibel zu
> einer bestehenden CPU mit interessanten Programmen sein, damit man nicht
> jedes Programm selbst schreiben muss. Es bietet sich CP/M an, das gibt's
> inzwischen auch in Source. Oder eine Gameboy-kompatible Hardware.

... soll das Ganze ja kein Brecherding werden und es sollen auch keine 
Spiele, Klimasimulationen, DNA-Sequenzanalysen oder was auch immer 
darauf laufen ;-) Das würde den Rahmen eideutig sprengen.

A. K. schrieb:
> Wenn man bedenkt, dass er sich auf 256 Bytes Code beschränkt, also 128
> Befehle, dann scheint es eher ums Prinzip als um reale Programme zu
> gehen.

Genau. Wobei ich 256 Opcodes und 256 Datenwörter ansprechen kann, also 
auf 256 Befehle (inkl. Datenwort) im Programmspeicher kommme. Gut - ist 
auch nicht die Welt, aber immerhin.

W.S. schrieb:
> Wohin willst du dein Ding bauen?
> Externer Flash? Externer RAM? Peripherie? Leiterplatte? UND Womit
> willst du dein Ding dann programmeren? Hast du schon mal nen Assembler
> selber geschrieben?
>
> Das alles ist ne Menge Holz und du solltest dich fragen, ob du es bis zu
> deiner Verrentung mit (ähem.. 67? 69? 71? ..?) noch zu Ende bekommst,
> ohne dir einen vorzeitigen Herzinfarkt zuzuziehen.

Okay, um das mal ein wenig zu entdramatisieren:
Ich habe mir das modular vorgestellt: Ich entwerfe/simuliere den 
Addierer/Subtrahierer, baue ihn auf, gucke, ob alles passt. Falls ja 
bringe ich das schon mal auf eine Platine und mache mich dann 
meinetwegen an die ALU. Also Stück für Stück. Das ist zumindest mein 
Plan.
Beschrieben wird der Programmspeicher dann über den Computer mit einem 
uC als Schnittstelle. Ein entsprechender "Compiler", bzw. "Assembler" 
(wenn man in dem Ausmaß schon davon sprechen kann), der zumindest mal 
die Befehle + Daten kodieren kann und dann mit dem RAM spricht, ist ja 
keine Raketenwissenschaft.
Wenn alles am Ende funktioniert, ist der Rest dann Kür. Denkbar ist auch 
ein Modul mit einem ATmega, einem Display und Anschluss für eine 
Tastatur zum direkten Progrmmieren. Darüber kann man dann ja nachdenken 
wenn alles steht ;-) Und ja: Ein kleines Projekt ist das nicht, richtig.


Mal zwischendurch eingestreut: Es freut mich wirklich sehr, dass sich 
hier so viele Leute schon geantwortet haben. Vielen Dank an dieser 
Stelle dafür!
Ich freue mich natürlich auch weiterhin über Tipps, Hinweise, Kritik 
(auch zur Hardwareumsetzung).

von chris (Gast)


Lesenswert?

Christoph B. schrieb
>> Vor einiger Zeit habe ich das mal für eine einfache Übungs-CPU gemacht,
>Oh ja - das sieht sehr interessant aus. Werde ich mir morgen (bzw.
>heute) in aller Ruhe anschauen. Vielen Dank!

Gerade habe ich die Diskussion im MC-Netz dazu gefunden:
Beitrag "aus einer 8 bit CPU eine 16 bit CPU machen"

Da gibt es einige nüzliche Tips über historische Entwicklungen.

von Jörn T. (kleinergruenerkaktus)


Lesenswert?

Christoph B. schrieb:
>
> Sehr gerne. Hatte dir vor ein paar Tagen auch schon eine Nachricht über
> YT geschickt, ging um das Video davor... ;-)
> Wie ist denn deine Planung momentan?
>

Ach Du bist das! Tja, die Welt ist echt klein ;-)
Stand der Dinge: Taktgenerator steht. Nächster Schritt ist ein 
Programmcounter mit Zugriff auf RAM, in dem Programm und Daten stehen. 
Danach wird auf Diodenmatrix-Ebene der erste Befehl aufgebaut: NOP
Ich schicke Dir mal per E-mail meine Unterlagen bzw. einen Link dahin. 
Ich finde, der Entwurf bringt einen auf viele Idee. Aber Achtung, sind 
ein paar Fehler drin.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Christoph B. schrieb:
> Lädt! Hatte schon mit der Xilinx ISE versucht, irgendwelche 74xxxx Libs
> einzubinden, aber das war mehr so ein Topfschlagen... Ich schau mal, was
> sich damit anstellen lässt.
Ich weiß nicht: wenn du schon was Neues anfängst (FPGA-Design), warum 
lernst du dann nicht was, was du später auch brauchen kannst? Z.B. 
Verilog oder VHDL. Siehe dazu den 
Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)"

Denn noch eine weiter CPU mit handgeschnitzten Transistoren, das ist 
doch wie ein Fahrrad selber bauen: es wird auf jeden Fall schlechter, 
sperriger und teurer als etwas Fertiges und lernen kannst du am 
Fahrradbau eigentlich auch nichts mehr, du baust ja nur was nach, was 
Andere schon lange untersucht und erfunden haben...

Wie wärs, etwas zu machen, was es nicht an jeder Ecke für 1,50€ gibt:
z.B. einen Synchronen Indexer für ein paar Schrittmotoren in Hardware

von Matthias I. (matze5)


Angehängte Dateien:

Lesenswert?

hust hab auch mal so was angefangen, hier ein kleines Teil..
hab noch so einige andere Experimente gehabt.

Warum nicht mit Diskreten Logic Gates spielen ? so lernt man wenigstens 
was, oder eben auch nicht :) manche Leute nehmen ja schon UCs wo es ein 
paar Gates tun..

von W.S. (Gast)


Lesenswert?

Lothar Miller schrieb:
> Ich weiß nicht:...

Lothar, deine und meine Ansichten sind unterschiedlich und hier merkst 
du mal, daß es noch ganz andere Leute gibt, deren Ansichten mit deiner 
eben auch nicht übereinstimmen. Der Grund ist fast immer die völlig 
unterschiedliche Relation der Leute zum Thema Programmierbare Logik, 
deren sonstiges Betätigungsfeld usw. Vielleicht relativiert das mal ein 
bissel deine sonst eher kategorische Art.

Abgesehen davon halte ich symbolische Abbilder von real existierenden 
74xx Bausteinen nur dann für nutzvoll, wenn man irgend eine alte 
TTL-Schaltung unter Zeitdruck in ein CPLD quetschen muß, ohne sich 
Gedanken über die eigentliche Funktionalität zu machen. Mir selbst ist 
sowas jedoch noch nicht untergekommen.

Was das konkrete Vorhaben dieses Threads betrifft, so kommt mir das 
Gedicht von den 2 Ameisen in den Sinn, die nach Australien reisen 
wollten:
..in Altona auf der Chaussee
da taten ihnen die Füße weh
und so verzichteten sie weise
auf den letzten Rest der Reise.


W.S.

von Ale (Gast)


Lesenswert?

Hei Christoph B.!

Cool project. I have also started my own CPU dev but in verilog. The 
schematic capture of the xilinx webpack provided unstable and difficult 
to use. Even the old OrCAD was better :/.

Regarding your architecture diagrams, what I do normally is to see what 
every opcode has to do to see what is really needed. Doing multi-cycle 
opcodes is a lot easier than pipelined designs.
An older but sort of working version of one of my designs can you find 
here:

http://forums.parallax.com/showthread.php/146345-A-simpler-COG

A cog-inspired 4 clock uP.

Depending on how many clocks per opcode you want, you can time the RAM 
accesses to the opcode execution. And nowadays SRAMs are fast.

von Alex W. (a20q90)


Lesenswert?

Hallo Christoph,

las dich von den "lass das sein"-Sagern nicht entmutigen!
Auch wenn es heute kein Sinn macht eine CPU selbst zu bauen (Autotuning, 
Golf-Spielen, Radrennen etc. macht das auch nicht, dennoch ist es ein 
Gewerbe) finde ich es dennoch hervorragend!

Wenn Du die CPU zum laufen gebracht hast, kannst Du später dies bei 
einer Bewerbung als Referenz angeben. Das kann fasst keiner hier!

von Falk B. (falk)


Lesenswert?

@ Alex W. (a20q90)

>las dich von den "lass das sein"-Sagern nicht entmutigen!
>Auch wenn es heute kein Sinn macht eine CPU selbst zu bauen (Autotuning,
>Golf-Spielen, Radrennen etc. macht das auch nicht, dennoch ist es ein
>Gewerbe) finde ich es dennoch hervorragend!

Sehe ich auch so. Eine CPU baut man nicht, um besser als verfügbare zu 
sein, dass kann so gut wie niemand. Aber man kann

a) viel lernen
b) viel Spaß haben

Schon mal zwei gute Gründe.

von Sam P. (Gast)


Lesenswert?

Bezüglich Assembler und sogar Compiler: www.archc.org

Damit kann man sich mit wenig Aufwand einen CPU-Simulator entwerfen und 
kriegt nebenbei noch Assembler, Linker, Debugger und neuerdings sogar 
nen C-Compiler automatisch erzeugt.

von Ale (Gast)


Lesenswert?

Hei Sam, thanks !
Ich wollte ein neuer C Compiler für mein pdp11 Projekt, archC klingt 
geignet !

von MCUA (Gast)


Lesenswert?

Irgentwie verwirrende Beschreibung.
Der TO hat nichtmal beschrieben, wie die genaue OP-Code-Aufteilung 
(fest, variabel ? , wie viel?) gemacht ist. (OP-Code enthält nicht nur 
die Commands, sondern alles was die CPU ausm Progr-Speicher liesst (bsp 
Operanden, Registerpointer, Immed.werte, sonst. ggfs. angehängte 
Param.).

Vielleicht sich wegen Befehlssatz erstmal eine Accu-Masch (bsp HC11,12, 
STM8) anguggen.

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
> Irgentwie verwirrende Beschreibung.

Besonders leicht verständlich ist sein Enigma nicht geraten.

> Der TO hat nichtmal beschrieben, wie die genaue OP-Code-Aufteilung
> (fest, variabel ? , wie viel?) gemacht ist. (OP-Code enthält nicht nur
> die Commands, sondern alles was die CPU ausm Progr-Speicher liesst (bsp
> Operanden, Registerpointer, Immed.werte, sonst. ggfs. angehängte
> Param.).

Du denkst da mehr rein, als drin ist. 16-Bit Opcode, bestehends aus 5 
Bit Opcode und 8 Bit Wert/Adresse. Basta. Betrachte es unter dem Aspekt 
des Minimalismus, nicht der Effektivität. Wobei man es dabei auch 
übertreiben kann und bei einer Maschine landet, die wirklich kaum mehr 
zustande bringt, als eine LED blinken zu lassen.

von MaWin (Gast)


Lesenswert?

> Wobei man es dabei auch
> übertreiben kann und bei einer Maschine landet, die wirklich kaum mehr
> zustande bringt, als eine LED blinken zu lassen.

Na ja, Turing-Vollständig sollte sie schon sein (bis auf Speicher),
und damit ist sie universell genug.

von chris (Gast)


Lesenswert?

>16-Bit Opcode, bestehends aus 5 Bit Opcode und 8 Bit Wert/Adresse.

5+8=13 ;-)

von (prx) A. K. (prx)


Lesenswert?

Na und? Wenn du auf mehr als 16 Bits gekommen wärst, dann hätte etwas 
nicht gestimmt. ;-)

von chris (Gast)


Lesenswert?

Hallo Christoph B., einige Details Deiner Architektur verstehe ich 
nicht:

Welche Bedeutung hat das Flag F_AN ?
Wie funktioniert der Befehel SEF ..... ab genau ?
Beim "bitweisen Oder" AXO x wird x gar nicht benutzt ?
Wie genau soll IOW D funktionieren? Was liegt im IO-Bereich?
Gibt es einen RAM Bereich, wie wird darauf zugegriffen ?

Gruß,
chris

von ... (Gast)


Lesenswert?

Wie wärs mal mit einem one instruction set computer? Also einer CPU, die 
nur einen Befehl hat:

http://en.wikipedia.org/wiki/One_instruction_set_computer

Den kann man ja noch mit einzelnen SMD Transitoren aufbauen :-)
Der Assembler sollte dann aber schon Makros unterstützen, um "richtige" 
Befehle damit nachzubilden.

Oder wie wärs mit einer CPU, die nur ein "MOVE" kennt:

http://en.wikipedia.org/wiki/Transport_triggered_architecture

Alle Berechnungen, Vergleiche etc. werden über in den Speicherbereich 
eingeblendete Rechenwerke gemacht. Beispiel Addition: an Adresse 1 und 2 
stehen die Operanden, die man mit move dort hinschreibt. An Adresse 3 
kann man das Ergebnis lesen.

Hat sowas schon mal jemand hier im Forum gebaut?

von wire (Gast)


Lesenswert?

... schrieb:
> Oder wie wärs mit einer CPU, die nur ein "MOVE" kennt:

klasse idee, wäre sehr interessant

von Alex W. (a20q90)


Lesenswert?

Als Programmiersprache würde ich Whitespace empfehlen!

von chris (Gast)


Lesenswert?

Hallo Christoph B.,

zum Spass habe ich einige der Befehle Deiner CPU im Assembler/Simulator 
implementiert. Wenn Du Lust hast, poste ich den Code ( Java ) dort 
lassen sich relativ einfach die restlichen Befehle hinzufügen.

Gruß,
chris


1
CBCPU Assembler/Disassembler/Simulator V01
2
3
instructions implemented in this version:
4
END  END stop cpu clock
5
JMP const    jump to direct address
6
WRA const    write register to accu
7
ADI const    write register to accu
8
JCN const    jump if not null to direct address
9
SBC    a=a-b-carry
10
TAB    transfer ACC to B_REG
11
12
testcode.txt
13
//  
14
//   CBCPU test program  
15
//  
16
//  CBCPU: Christoph B. CPU   
17
//  from http://www.mikrocontroller.net/topic/303279  
18
//  
19
    
20
  wra 1      // write accu with 1  
21
  tab        // transfer accu to b register  
22
  wra 3      // write accu with 3  
23
loop:  
24
  sbc        // acc=acc-b_reg  
25
  JCN stop   // loop until acc=0  
26
  jmp loop  
27
  
28
stop:  
29
  end                
30
31
labels :
32
loop 3
33
stop 6
34
35
resulting code
36
0C01 0A00 0C03 0400 1006 1103 0000 
37
38
disassembled code
39
0000: 0C01  WRA 1                write register to accu
40
0001: 0A00  TAB                transfer ACC to B_REG
41
0002: 0C03  WRA 3                write register to accu
42
0003: 0400  SBC                a=a-b-carry
43
0004: 1006  JCN 6                jump if not null to direct address
44
0005: 1103  JMP 3                jump to direct address
45
0006: 0000  END              END stop cpu clock
46
47
simulator run
48
0 :WRA 1      0001 0000 0000 0000 0000 0000 0000 0000 
49
1 :TAB      0001 0001 0000 0000 0000 0000 0000 0000 
50
2 :WRA 3      0003 0001 0000 0000 0000 0000 0000 0000 
51
3 :SBC      0002 0001 0000 0000 0000 0000 0000 0000 
52
4 :JCN 6      0002 0001 0000 0000 0000 0000 0000 0000 
53
5 :JMP 3      0002 0001 0000 0000 0000 0000 0000 0000 
54
3 :SBC      0001 0001 0000 0000 0000 0000 0000 0000 
55
4 :JCN 6      0001 0001 0000 0000 0000 0000 0000 0000 
56
5 :JMP 3      0001 0001 0000 0000 0000 0000 0000 0000 
57
3 :SBC      0000 0001 0000 0001 0000 0000 0000 0000 
58
4 :JCN 6      0000 0001 0000 0001 0000 0000 0000 0000 
59
6 :END      0000 0001 0000 0001 0000 0000 0000 0000

von Tim  . (cpldcpu)


Lesenswert?

Da muss ich meine CPU auch noch ein einstreuen:

http://opencores.org/project,mcpu

1 Seite VHDL Source, 32 Macrozellen im CPLD...

von chris (Gast)


Lesenswert?

>Da muss ich meine CPU auch noch ein einstreuen:

Gefällt mir sehr gut :-)
Wie ich aus der Doku sehe, kann man erweiterte Befehle mit Hilfe der 4 
Grundbefehle zusammen setzen. Ist der Assembler dafür ein 
Makro-Assembler ?

von Lothar (Gast)


Lesenswert?

Habe bisher die kostenfreie 8051 Macrocell für FPGA genutzt, aber es 
gibt wohl inzwischen eine kostenfreie ARM2 Macrocell, muss ich doch mal 
testen:

http://opencores.org/project,amber

von chris (Gast)


Lesenswert?

Eine Tastemprogrammierbare Steuerung wäre vielleicht auch als Architekur 
für einen einfachen Prozessor geeignet:
http://www.elektronik-labor.de/Projekte/TPS1.html

von Tim  . (cpldcpu)


Lesenswert?

>>Da muss ich meine CPU auch noch ein einstreuen:
>
> Gefällt mir sehr gut :-)
> Wie ich aus der Doku sehe, kann man erweiterte Befehle mit Hilfe der 4
> Grundbefehle zusammen setzen. Ist der Assembler dafür ein
> Makro-Assembler ?

Ja. SMAL (der Assembler) ist ziemlich einfach gehalten. Im Prinzip ist 
alles als Macro implementiert.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hier noch etwas lesenswerte Lektüre zum Thema: http://mycpu.eu/

Das ist eine komplett mit 74xxx aufgebaute 8-Bit-CPU inkl. Rechner 
"drumherum".

von Josef G. (bome) Benutzerseite


Lesenswert?

Frank M. schrieb:
> ... mycpu.eu/

Wo findet man den vollständigen Befehlssatz dieser CPU?

von Helmut S. (helmuts)


Lesenswert?

> Wo findet man den vollständigen Befehlssatz dieser CPU?

Zumindest steht hier, dass die CPU ähnlich dem 6502 ist.
http://mycpu.selfhost.it/epj03.htm

Dieser Spruch am Ende des obigen Artikels gefällt mir.
My slogan is: "Others have a model railway in their cellar, I have my 
CPU instead."

von Christoph B. (chr_b)


Lesenswert?

So,

nach kurzer Auszeit ein kleines Update:

Diverse Teile sind gekommen, und der Schaltplan für die ALU steht 
schonmal. Werde jetzt erstmal einige Sachen aufbauen und testen.

Vielen Dank für die Kritik, aber auch für den Zuspruch und das Interesse 
an diesem Projekt!

Sam P. schrieb:
> Bezüglich Assembler und sogar Compiler: www.archc.org

Klingt in der Tat interessant, werde ich mir auf jeden Fall auch 
anschauen, besonders das mit dem Simulieren hört sich sehr brauchbar an!

chris schrieb:
> Hallo Christoph B., einige Details Deiner Architektur verstehe ich
> nicht:
>
> Welche Bedeutung hat das Flag F_AN ?
> Wie funktioniert der Befehel SEF ..... ab genau ?
> Beim "bitweisen Oder" AXO x wird x gar nicht benutzt ?
> Wie genau soll IOW D funktionieren? Was liegt im IO-Bereich?
> Gibt es einen RAM Bereich, wie wird darauf zugegriffen ?

- Das Flag F_AN, bzw. F_N gibt an, ob sich im Akkumulator nach einer 
Subtraktion ein negativer Wert befindet. Ist in diesem Fall natürlich 
genau das Carry-Flag aber ich brauche ja eh noch ein drittes Flag für 
die Vergleichsoperationen.

- Der Befehl SEF setzt die Flags F_C und F_Z nach den Bits ACCU(6) und 
ACCU(7) (in den Versionen hier waren das noch die Bits aus dem 
Datenwort, das habe ich geändert).

- Genau. Die bitweisen Operationen verknüpfen die beiden Register ACCU 
und REG_B. Nicht direkt das Datenwort aus dem Programmspeicher.

- IOW legt das Wort D an den I/O Adressbus, den Wert des Akkumulators an 
den I/O Datenbus und aktiviert die R/W Leitung.

- Ja. Habe die CPU und den Befehlssatz entsprechend erweitert. Zugriff 
erfolgt mit dedizierten Befehlen für das RAM, genau so wie auf I/O 
Einheit.

chris schrieb:
> zum Spass habe ich einige der Befehle Deiner CPU im Assembler/Simulator
> implementiert. Wenn Du Lust hast, poste ich den Code ( Java ) dort
> lassen sich relativ einfach die restlichen Befehle hinzufügen.

Wow - vielen Dank für deine Mühe! Bin ja zumindest beruhigt, dass du 
Spaß daran hattest ;-) Klar, gerne, da wäre ich sehr gespannt!

Frank M. schrieb:
> Hier noch etwas lesenswerte Lektüre zum Thema: http://mycpu.eu/

Das Ding hatte ich auch schon entdeckt. Ist zwar deutlich 
professioneller als mein Vorhaben, aber das Durchschauen der Downloads 
ist auf jeden Fall lohnenswert!


Zwischendurch nochmals vielen Dank für die regen Diskussionen und die 
hilfreichen Kommentare!

Ich habe mir bereits einen ALU-Tester aufgebaut und die entsprechende 
Software geschrieben und werde mit dem Testaufbau der ALU beginnen. Wenn 
soweit alles funktioniert, kommt diese schonmal auf Platine und ich kann 
mich an den Befehlsdecoder machen. So viel zu meiner weiteren Planung.

von Michael S. (captain-stone)


Lesenswert?

Josef G. schrieb:
> Frank M. schrieb:
>> ... mycpu.eu/
>
> Wo findet man den vollständigen Befehlssatz dieser CPU?

Hallo Josef,

ich kenne den Entwickler der MyCPU (Dennis Kuschel), ein ehemaliger 
Mitarbeiter von mir und ein begnadeter Elektroniker. Ich stelle gerne 
den Kontakt zu ihm her, wenn Du möchtest. Schick mir eine Nachricht. Ich 
bin mir sicher, er stellt Dir das benötigte Material zur Verfügung,

der Captain

von Josef G. (bome) Benutzerseite


Lesenswert?

Michael Steinbauer schrieb:
> er stellt Dir das benötigte Material zur Verfügung,
Ich hab's gefunden auf mycpu.eu auf der Seite
Downloads im MyCPU Processor Selfbuild-Guide.

von chris (Gast)


Lesenswert?

Hallo Christoph B.

Schön, dass es weiter geht ;-)
Könntest Du mal ein kleines Beispiel Programm schreiben ?
z.B. 10 mal Test ausgeben?
Ich denke, das ist nützlich, um den Aufbau der Befehle zu analysieren 
und zu verstehen.

von chris (Gast)


Lesenswert?

>- Ja. Habe die CPU und den Befehlssatz entsprechend erweitert. Zugriff
>erfolgt mit dedizierten Befehlen für das RAM, genau so wie auf I/O
>Einheit.

Könntest Du den neuen Befehlssatz posten ?

von Christoph B. (chr_b)


Angehängte Dateien:

Lesenswert?

Hallo chris,

chris schrieb:
> Könntest Du mal ein kleines Beispiel Programm schreiben ?

Das würde ja ungefähr so aussehen:
1
0: WRB 0b00000001 // REG_B = 1
2
1: WRA 0b00001010 // ACCU = 10
3
2: DCH 0b01010100 // T
4
3: DCH 0b01000101 // E
5
4: DCH 0b01010011 // S
6
5: DCH 0b01010100 // T
7
6: SBC 0b00000000 // ACCU -= REG_B
8
7: JCZ 0b00000010 // F_Z == 0 ?
9
8: END 0b00000000

chris schrieb:
> Könntest Du den neuen Befehlssatz posten ?

Natürlich - ist angehängt.



Besten Gruß!

von Seb (Gast)


Lesenswert?

> Also (jew. 1 Takt):
> - Befehl aus Adresse im "CMD_ADDR COUNTER" aus dem RAM holen und an das
> Register DATA_COMMAND legen
> - Register DATA_COMMAND setzen
> - Datenwort aus dem RAM holen und an das Register DATA_WORD legen
> - Register DATA_WORD setzen
> - CMD_ADDR um 1 erhöhen
> - Befehl und Daten an den Command decoder geben, dieser schaltet alles
> nötige, bzw. führt den Befehl aus und legt die neuen Daten an die
> restlichen Register an
Eine Mikrocode Unit wäre vielleicht dafür noch Sinnvoll, oder soll der 
Decoder genau das darstellen?


Du hast dort im Diagramm ALU und davon abgehen XOR,XAND,AND usw...
sind gerade diese nicht eigentlich Teil der alu?
Arithmetisch-Logische Einheit.

Bei dir ist nur der Akkumulator selbst in der ALU drin.
http://de.wikipedia.org/wiki/Arithmetisch-logische_Einheit
http://upload.wikimedia.org/wikipedia/commons/thumb/1/17/Simplified-ALU.svg/645px-Simplified-ALU.svg.png

von chris (Gast)


Lesenswert?

Hi Christoph,

hier der Assembler/Simulator/Debugger mit ein paar Kommandos ( nicht 
alle und nicht alle vollständig ):

http://hobby-roboter.de/forum/viewtopic.php?f=4&t=144
1
CBCPU Assembler/Disassembler/Simulator Vxx
2
3
instructions implemented in this version:
4
END  END stop cpu clock
5
JMP const    jump to direct address
6
WRA const    write register to accu
7
WRB const    write register to reg_b
8
ADI const    write register to accu
9
JCN const    jump if not null to direct address
10
JCZ const    jump if null to direct address
11
SBC    a=a-b-carry
12
TAB    transfer ACC to B_REG
13
DCH const    display ascii char
14
15
testcode2.txt
16
  
17
  WRB 1          // REG_B = 1  
18
  WRA 0x0A       // ACCU = 10  
19
  
20
loop:  
21
  DCH 0x54     //0b01010100 = T  
22
  DCH 0x45     //0b01000101 = E  
23
  DCH 0x53     //0b01010011 = S  
24
  DCH 0x54     //0b01010100 = T  
25
  SBC        //ACCU -= REG_B  
26
  JCZ loop     // F_Z == 0 ?  
27
  END   
28
29
30
labels :
31
loop 2
32
33
parse with jump labels :
34
0 0000 noType                      source: 
35
1 0000 CODE: 0D01  WRB 1                      source:   WRB 1          // REG_B = 1
36
2 0001 CODE: 0C0A  WRA 0x0A                   source:   WRA 0x0A       // ACCU = 10
37
3 0002 noType                      source: 
38
4 0002 LABEL  loop:                  source: loop:
39
5 0002 CODE: 1954  DCH 0x54                 source:   DCH 0x54     //0b01010100 = T
40
6 0003 CODE: 1945  DCH 0x45                 source:   DCH 0x45     //0b01000101 = E
41
7 0004 CODE: 1953  DCH 0x53                 source:   DCH 0x53     //0b01010011 = S
42
8 0005 CODE: 1954  DCH 0x54                 source:   DCH 0x54     //0b01010100 = T
43
9 0006 CODE: 0400  SBC                      source:   SBC        //ACCU -= REG_B
44
10 0007 CODE: 1102  JCZ loop                 source:   JCZ loop     // F_Z == 0 ?
45
11 0008 CODE: 0000  END                source:   END 
46
47
resulting code
48
0D01 0C0A 1954 1945 1953 1954 0400 1102 0000 
49
50
disassembled code
51
0000: 0D01  WRB 1                write register to reg_b
52
0001: 0C0A  WRA 10                write register to accu
53
0002: 1954  DCH 84                display ascii char
54
0003: 1945  DCH 69                display ascii char
55
0004: 1953  DCH 83                display ascii char
56
0005: 1954  DCH 84                display ascii char
57
0006: 0400  SBC                a=a-b-carry
58
0007: 1102  JMP 2                jump to direct address
59
0008: 0000  END              END stop cpu clock
60
61
simulator run
62
0 :WRB 1      0000 0001 0000 0000 0000 0000 0000 0000 
63
1 :WRA 10      000A 0001 0000 0000 0000 0000 0000 0000 
64
2 :DCH 84      ======= ascii-char: T =================000A 0001 0000 0000 0000 0000 0000 0000 
65
3 :DCH 69      ======= ascii-char: E =================000A 0001 0000 0000 0000 0000 0000 0000 
66
4 :DCH 83      ======= ascii-char: S =================000A 0001 0000 0000 0000 0000 0000 0000 
67
5 :DCH 84      ======= ascii-char: T =================000A 0001 0000 0000 0000 0000 0000 0000 
68
6 :SBC      0009 0001 0000 0000 0000 0000 0000 0000 
69
7 :JMP 2      0009 0001 0000 0000 0000 0000 0000 0000 
70
2 :DCH 84      ======= ascii-char: T =================0009 0001 0000 0000 0000 0000 0000 0000 
71
3 :DCH 69      ======= ascii-char: E =================0009 0001 0000 0000 0000 0000 0000 0000 
72
4 :DCH 83      ======= ascii-char: S =================0009 0001 0000 0000 0000 0000 0000 0000 
73
5 :DCH 84      ======= ascii-char: T =================0009 0001 0000 0000 0000 0000 0000 0000 
74
6 :SBC      0008 0001 0000 0000 0000 0000 0000 0000 
75
7 :JMP 2      0008 0001 0000 0000 0000 0000 0000 0000 
76
2 :DCH 84      ======= ascii-char: T =================0008 0001 0000 0000 0000 0000 0000 0000

von Tim  . (cpldcpu)


Lesenswert?

Vorwarnung: Ich habe nicht den ganzen Thread gelesen.

>DCH const

So high-level ein Befehl ist ziemlich ungewöhnlich. Warum wird der 
Buchstabe denn als Const definiert? Wie soll eine dynamische Ausgabe 
funktioniert? Durch selbstmanipulierenden code?

von chris (Gast)


Lesenswert?

>>DCH const
>So high-level ein Befehl ist ziemlich ungewöhnlich.

Das habe ich mir auch schon gedacht. Wie man im Programm sieht, ist es 
zwar sehr einfach, DEBUG-Meldungen auszugeben. Ein Algorithmus, der z.B. 
Groß- in Kleinschreibung umwandelt, ist damit nur schwer realisierbar.

von chris_ (Gast)


Lesenswert?

Der Thread scheint ja fast ein wenig eingeschlafen ....
Christoph B.: wie weit bist Du mit Deiner CPU?

In den Vorlesungen zu technischen Informatik gibt es einige minimal CPU 
Designs. Hier ein Beispiel, für das es sogar eine Java Applet Simulation 
gibt:
http://tams-www.informatik.uni-hamburg.de/applets/hades/webdemos/50-rtlib/90-prima/chapter.html

Vielleicht kann man sich an diesen Designs orientieren.

von chris_ (Gast)


Lesenswert?

Kennt jemand ein Design mit der 74LS181 ALU ?

http://math.hws.edu/vaughn/cpsc/220/labs/lab04/74LS181.pdf

Damit liese sich das Prozessor Design vielleicht vereinfachen.

von chris_ (Gast)


Lesenswert?

Erstaunlich, was Google alles zum Vorschein bringt:
http://ygg-it.tripod.com/id1.html
Die 74LS181 scheint bis 1997 produziert worden zu sein. Bei Mouser ist 
sie seltsamerweise aber immer noch erhältlich.

von Tim  . (cpldcpu)


Lesenswert?

Hier noch mal eine idee: Nachdem der kleinste verfügbare CPLD mit 32 
Macrozellen für eine CPU ausreicht - schafft es jemand, eine komplette 
CPU in einem GAL20V8 unterzubringen?

von Jörn T. (kleinergruenerkaktus)


Lesenswert?

@Chris
Wenn Du ein spannendes Projektfür den 74LS181 suchst, dann sieh Dir mal 
den Lehrcomputer von Conatex an: 
http://www.conatex.com/mediapool/betriebsanleitungen/BAD_1008145.pdf

Daran hocke ich gerade. Aber Achtung, es sind ein paar Fehler drin und 
der Schaltplan ist etwas ungewöhnlich. Es ist nicht alles nach der 
reinen Lehre gemacht. Man sollte das Ganze eher als Inspiration nutzen 
und nicht 1:1 nachbauen wollen.

74LS181 kriegt man übrigens ganz gut über EBay oder bei einem 
ortsansässigen Elektronikladen. Ich hatte zumindestens noch Glück. Beim 
SRAM kann man flexibel sein.

von chris_ (Gast)


Lesenswert?

>den Lehrcomputer von Conatex an:
>http://www.conatex.com/mediapool/betriebsanleitung...

Schön erklärt, wenn auch die Seiten krumm eingescannt sind.
Schade, dass kein Bild dabei ist .. vielleicht könntest Du eines posten.

von chris_ (Gast)


Lesenswert?

>Hier noch mal eine idee: Nachdem der kleinste verfügbare CPLD mit 32
>Macrozellen für eine CPU ausreicht - schafft es jemand, eine komplette
>CPU in einem GAL20V8 unterzubringen?
Ob man wohl eine Forth-fähige CPU auch in ein CPLD bekommen könnte?
( vielleicht kleiner als die J1: 
Beitrag "Re: Fragen zu Forth" )
Das wäre eine Herausforderung, und Forth bietet schon mehr Möglichkeiten 
als die CPU von Connatex

von chris_ (Gast)


Lesenswert?

von alten Taschenrechnern lässt sich vielleicht auch noch etwas lernen:
http://files.righto.com/calculator/sinclair_scientific_simulator.html
Beeindruckend ist hier das Bild des Insturction-Decoder Roms:
https://picasaweb.google.com/lh/photo/w52GQHWgId1zKOv_jj47fwj0RFV-rpgKGQkOJvHZ0i8
Man sieht direkt, welche Kontrollsignale bei welchem Befehl gezogen 
werden.

von Tim  . (cpldcpu)


Lesenswert?

chris_ schrieb:
>>Hier noch mal eine idee: Nachdem der kleinste verfügbare CPLD mit 32
>>Macrozellen für eine CPU ausreicht - schafft es jemand, eine komplette
>>CPU in einem GAL20V8 unterzubringen?
> Ob man wohl eine Forth-fähige CPU auch in ein CPLD bekommen könnte?
> ( vielleicht kleiner als die J1:
> Beitrag "Re: Fragen zu Forth" )
> Das wäre eine Herausforderung, und Forth bietet schon mehr Möglichkeiten
> als die CPU von Connatex

Prinzipiell erste einmal ja, da man mit jeder CPU auch eine Stack-CPU 
emulieren kann. So richtig effektiv ist so eine Implementierung auf 
einem CPLD aber nicht, da man recht viele Register + Stack benötigt. Ein 
FPGA ist da besser geeignet.

Minimum wären wohl 4 Register: PC, Stack pointer, TOS, Second on stack, 
addressregister. Da ist eine Akku-basierte CPU deutlich einfacher.

von Rene B. (themason) Benutzerseite


Lesenswert?

@Christoph

Also ich find die Idee eine CPU mit TTLs aufzubauen an sich ja schon 
ganz interessant, bzw sich aus Spaß an der Freud selbst ne CPU 
zusammenzubacken schon echt witzig. Nur weiter so. :-)

Ich selbst bin auch dabei ein paar Ansätze auszuprobieren.

@...

>Oder wie wärs mit einer CPU, die nur ein "MOVE" kennt:

Genau diesen Ansatz verfolge ich gerade :-)
Die Idee das man quasi nur 'einen' Move Befehl hat (wobei das so ja 
nicht stimmt, denn es müssen ja mehrere Modi unterstützt werden um 
sinnvoll arbeiten zu können, wie z.b. einen Wert in ein Register zu 
schreiben, ein Register in ein anderes zu schreiben, Speicherzugriffe 
usw, und ein paar zusätzliche Befehle brauchts ja schon noch) hat schon 
echt was interessantes.
Bei meiner Idee bzw meiner derzeitigen Bastelimplementation gehe ich 
noch einen Schritt weiter und erlaube es das jeder Befehl bedingt 
ausgeführt werden kann, wobei die Bedingung durch ein beliebiges Bit in 
dem gesamten Registersatz vorgegeben werden kann.
Somit kann dann beispielsweise die Bits des ALU-Statusregister (das ja 
auch ganz 'normal' in dem Registersatz eingeblendet ist) oder ein 
Register in dem der Vergleich der beiden Operanden dazu genutzt werden 
das beispielsweise Sprungbefehle, oder andere MOVE-Befehle ausgeführt 
werden oder nicht.
Das bietet schon einige nette Spielereien die tlw auch Sinn machen. Mir 
ist schon klar das das ganze eher eine nette Spielerei ist, und 
effizienz anders aussieht :-) Aber es geht hierbei ja um den Spaß an der 
Freud :-)
Vllt erstell ich zu diesem Design bzw dieser Idee auch mal zu gegebener 
Zeit einen Thread. Im Moment bin ich noch in der Bastel und 
Findungsphase, simulier ein paar Sachen erstmal mit ISE und schreib mir 
einen paar kleine Tools.

von ALE (Gast)


Lesenswert?

Wenn mann nur externe Speciher nutzt man könnte vielleicht ein ganz 
minimal Forth Prozessor in eine CPLD realizieren...So etwas wie ein 
95144 oder 95288... Vielleicht nur 8 bit...

von Tim  . (cpldcpu)


Lesenswert?

ALE schrieb:
> Wenn mann nur externe Speciher nutzt man könnte vielleicht ein ganz
> minimal Forth Prozessor in eine CPLD realizieren...So etwas wie ein
> 95144 oder 95288... Vielleicht nur 8 bit...

Ich habe hier ein Board mit einem 9572XL und 256x8 SRAM. Das muss 
reichen :)

Welche Befehle sollte die Stack-CPU denn unterstützen? Muss sie 
überhaupt direkte Speicherzugriff ermöglichen, oder reicht es, 
Konstanten auf den Stack zu schieben?

von chris_ (Gast)


Lesenswert?

>Welche Befehle sollte die Stack-CPU denn unterstützen?
Der Befehlssatz der F18A CPU von Greenarrays liefert hier einen guten 
Anhaltspunkt:
http://www.greenarraychips.com/home/documents/greg/PB003-110412-F18A.pdf
Diese CPU hat nur 18 Befehle.
>Muss sie überhaupt direkte Speicherzugriff ermöglichen
Ein Forth-Prozessor hat normalerweise 2 Stacks: Einen Datenstack zum 
rechnen und einen Programmstack für Unterprogrammaufrufe und Schleifen. 
Neben den Daten auf dem Datenstack gibt es normalerweise auch die 
Möglichkeit, auf den Speicher zuzurgreifen, da man ja eventuell längere 
Datenströme irgendwo speichern will.

von ALE (Gast)


Lesenswert?

Eine implementierung mit nur +, -, & und | und push/pop, call und return 
braucht 126 Slices (Lattice MachXO2) Aber mit 16 bit Werte...

von Tim  . (cpldcpu)


Lesenswert?

>>Welche Befehle sollte die Stack-CPU denn unterstützen?
> Der Befehlssatz der F18A CPU von Greenarrays liefert hier einen guten
> Anhaltspunkt:
> http://www.greenarraychips.com/home/documents/greg/PB003-110412-F18A.pdf
> Diese CPU hat nur 18 Befehle.

Ja, das ist DIE klassische Forth-CPU.

"each F18A contains 128 words of memory (up to 512 instructions) plus 20 
words of stacks and registers;"

Das schränkt die Nutzbarkeit aber stark ein. 10 Bit PC?

>>Muss sie überhaupt direkte Speicherzugriff ermöglichen
> Ein Forth-Prozessor hat normalerweise 2 Stacks: Einen Datenstack zum
> rechnen und einen Programmstack für Unterprogrammaufrufe und Schleifen.

Den Return-Stack hatte ich oben vergessen. Der macht natürlich wieder 
alles etwas komplizierter.

> Neben den Daten auf dem Datenstack gibt es normalerweise auch die
> Möglichkeit, auf den Speicher zuzurgreifen, da man ja eventuell längere
> Datenströme irgendwo speichern will.

Naja, kommt darauf an, ob es nur um ein proof-of-concept geht, oder man 
mit der CPU richtig arbeiten will.

von Tim  . (cpldcpu)


Lesenswert?

ALE schrieb:
> Eine implementierung mit nur +, -, & und | und push/pop, call und return
> braucht 126 Slices (Lattice MachXO2) Aber mit 16 bit Werte...

Das ist aber ein FPGA. Dort gibt es den Speicher für die Stacks 
geschenkt.

Ich vermute, dass ein CPLD nicht die richtige Umgebung für eine 
Stack-CPU ist.

von (prx) A. K. (prx)


Lesenswert?

Tim .  schrieb:
> "each F18A contains 128 words of memory (up to 512 instructions) plus 20
> words of stacks and registers;"

Wobei sich diese 128 Worte weiter auf 64 Worte ROM und 64 Worte RAM 
aufteilen.

Sinn ergibt dieser Minimalismus nur in der Masse. Die Klasse der davon 
abdeckbaren Probleme und die nötigen Programmiertechniken dürften sehr 
stark vom üblichen Rahmen abweichen. Man mag da an sowas wie neuronale 
Netze denken.

von ALE (Gast)


Lesenswert?

Ich habe nicht die Stacks intern gemacht sondern extern... nur die Stack 
Pointers sind intern (8 bit registers)

von Jörn T. (kleinergruenerkaktus)


Lesenswert?

Vielleicht ganz interessant. Eine 4-bit CPU mit 7400 Logik.
http://www.bigmessowires.com/category/nibbler/

von Tim  . (cpldcpu)


Lesenswert?

Thacker's Tiny Computer 3

http://www.cl.cam.ac.uk/teaching/1112/ECAD+Arch/background/ttc.html

32 Bit RISC CPU auf zwei Seiten Verilog.

von chris_ (Gast)


Lesenswert?

Um die Liste noch etwas zu vervollständigen, hier ein 4 Bit Computer für 
Lernzwecke:
http://www.randelshofer.ch/fhw/gri/holzihelp.html

von Tim  . (cpldcpu)


Lesenswert?

Eine ziemlich interessante Stack-CPU mit GCC-Toolchain:

http://opensource.zylin.com/zpu.htm

von chris_ (Gast)


Lesenswert?


von chris_ (Gast)


Lesenswert?

Wie groß ist der kleinste Befehlssatz, damit ein Prozessor ein 
vernünftiges Programm ausführen kann?
Um das heraus zu finden, habe ich eine virtuelle Maschine programmiert:

http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=145

Ein paar der Befehle könnte man sich noch sparen z.B. 1+.

von Arc N. (arc)


Lesenswert?

chris_ schrieb:
> Wie groß ist der kleinste Befehlssatz, damit ein Prozessor ein
> vernünftiges Programm ausführen kann?

Genau ein Befehl.
Maxims MAXQ-Controller wären ein Beispiel für eine 
Transport-Triggered-Architektur bei der es nur einen Befehl gibt.
1
move x y -> mem[y] = mem[x];

subleq x, y, z wäre eine andere Variante mit einem Befehl
1
mem[y] = mem[y] - mem[x];
2
if (mem[y] <= 0) goto z;

von chris_ (Gast)


Lesenswert?

>Maxims MAXQ-Controller wären ein Beispiel
Hier das Datenblatt:
http://www.maximintegrated.com/app-notes/index.mvp/id/4811

Es klingt ganz interessant. Beim überfliegen sehe ich allerdings auch 
eine Alu. Da stellt sich mir die Frage, ob der Hardwareaufwand kleiner 
als bei anderen Controllern ist.

>subleq x, y, z wäre eine andere Variante mit einem Befehl

Das verstehe ich nicht.

von (prx) A. K. (prx)


Lesenswert?

Arc Net schrieb:
> Maxims MAXQ-Controller wären ein Beispiel für eine
> Transport-Triggered-Architektur bei der es nur einen Befehl gibt.

Aber in 2 Spielarten:
  regD = regS
  regD = const

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

chris_ schrieb:
> Es klingt ganz interessant. Beim überfliegen sehe ich allerdings auch
> eine Alu.

Ohne ALU wird schwierig. Nur ist eine ALU nicht unbedingt der Gipfel des 
Aufwands.

> Da stellt sich mir die Frage, ob der Hardwareaufwand kleiner
> als bei anderen Controllern ist.

Die Dekodierung ist möglicherweise etwas einfacher.

>>subleq x, y, z wäre eine andere Variante mit einem Befehl
> Das verstehe ich nicht.

Ist auch ein eher theoretisches Konstrukt. Die Turing-Maschine pflegt 
man auch nicht praktisch zu verwenden.

von Arc N. (arc)


Lesenswert?

chris_ schrieb:
> Da stellt sich mir die Frage, ob der Hardwareaufwand kleiner
> als bei anderen Controllern ist.

Sollte
http://en.wikipedia.org/wiki/Transport_triggered_architecture

>>subleq x, y, z wäre eine andere Variante mit einem Befehl
>
> Das verstehe ich nicht.

Das was im C/Pseudocode darunter steht ist ausreichend, damit diese 
"Maschine" ebenso Turing-vollständig ist wie andere Maschinen und 
Programmiersprachen auch.

A. K. schrieb:
> Aber in 2 Spielarten:
>   regD = regS
>   regD = const

Wahrscheinlich um letztere Operation etwas effizienter zu machen

: Bearbeitet durch User
von test (Gast)


Lesenswert?

Jeder der sich für CPU Architekturen interessiert, sollte mal einen 
Blick auf http://ootbcomp.com/docs/ werfen. Eine komplett neue 
Architektur im Vergleich zu herkömlichen Architekturen.

von A. B. (funky)


Lesenswert?

Abdul K. schrieb:
> Ich schwöre ja auf diesen Mann hier und vermutlich ist seine CPU daher
> auch nicht gerade schlecht:
> http://www.holmea.demon.co.uk/GPS/Main.htm

wtf? schreibt er irgendwo wie lange er dafür gebraucht hat?! echt krass! 
hab aber nichtmal die Hälfte verstanden :(

von chris_ (Gast)


Lesenswert?

Hier gibt es den Schaltplan für eine Selbstbau 12 Bit CPU aus den 80er 
Jahren mit 74181er Alus:

ftp://ftp.dreesen.ch/

Mit 3 Platinen ist das noch einigermaße überschaubar.
Ich habe mir den Befehlssatz angesehen und einen Emulator dazu 
geschrieben:

https://github.com/ChrisMicro/T3_computer_emulation

Interessant dabei ist: der Computer hat keinen Festwertspeicher ( ROM ). 
Das Programm muss über die Schalter vorne am Frontpanel eingegeben 
werden.

Was ich am ganzen aber noch nicht verstehe: Wie kommt man in den 
Programmiermodus?

von Karl H. (kbuchegg)


Lesenswert?

chris_ schrieb:

> Was ich am ganzen aber noch nicht verstehe: Wie kommt man in den
> Programmiermodus?


Geraten.

Ich schätze mal, das ist die falsche Frage.
Denn so etwas wie einen Programmiermodus wird es da gar nicht geben. Mal 
schauen, was uns die Beschriftungen der restlichen Schalter bzw. Taster 
verraten.

Da gibt es auf der rechten Seite die Taster "BRK", "RUN" und "SST"
Ich wette mal, das bedeutet "Break", "Run" und "Single Step". Gemeint 
ist damit die CPU. Ein Druck auf RUN lässt die CPU laufen, ein Druck auf 
BRK hält die CPU an und ein Druck auf SST lässt die CPU 1 Instruktion 
ausführen. Da diese 3 Taster hier alle so schön vereint sind, rate ich 
mal weiter, dass die Taster direkt den Taktgenerator beeinflussen. Break 
klaut der CPU den Takt, Run schaltet den Takt wieder an die CPU und SST 
schaltet genau 1 Taktpuls an die CPU weiter (oder so viele, wie nötig 
sind um einen Befehl abzuarbeiten)

D.h. der Programmiermodus besteht einfach darin, dass die CPU nicht 
läuft (keinen Takt hat) und der Bediener mit den restlichen 
Konsolenelementen direkt im Speicher rumfuhrwerkt.

Wie macht er das?
Die 12 Schalter unter der Anzeige sind recht eindeutig. Das sind die 12 
Datenbits.
Wie kommen die gegebenenfalls in den Speicher?
Dazu nehmen wir die linke Tasterreihe "INC", "DEC", "STR". Ich wette 10 
zu 1, dass "STR" ausgeschrieben "Store" bedeutet und den mit den 
D-Schaltern eingestellten Wert in den Speicher schreibt. An  welche 
Adresse geschrieben wird, kann mit den Tasten INC bzw. DEC verändert 
werden. INC erhöht die Adresse an die geschrieben wird, DEC verringert 
sie und Store platziert dann den eingestellten Wert in den Speicher.

: Bearbeitet durch User
von chris_ (Gast)


Angehängte Dateien:

Lesenswert?

Das hört sich doch schon einmal gut an. Eigentlich müsste sich die 
Funktion ja auch aus dem Schaltplan ersehen lassen.
Die Schalter Inc, Dec, SST, "und der Taster nach unten?" sind an ein 
UND-Gatter angeschlossen, die einen Puls an einem Monoflop 74121 
erzeugen, der dann wiederum D-Flip-Flops zur Schalterübernahmen 
triggert.
Jetzt ist die Frage, was mit den daraus erzeugten Signalen IKF, plpc, 
und Opc angestellt wird.

von chris_ (Gast)


Lesenswert?

Nur um die Sammlung der CPUs etwas zu erweitern..

Hier gibt es die Bauanleitung für eine 1-Bit CPU:
http://laughtonelectronics.com/Arcana/One-bit%20computer/One-bit%20computer.html

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
Noch kein Account? Hier anmelden.