Mikroprozessor gesucht. Harvard Architektur.

Deutlich nach dem Harvard Mark I hat eine Harvard Architektur im Sinn 
einer Adressraumtrennung eigentlich nur im Kontext von Mikrocontrollern 
überhaupt einen Sinn.

Marek N. schrieb:
> 8051 ist Harvard.

Und ist als EFM8 Serie von Silabs auch als relativ neuer Chip zu haben.

Das ist aber eine ziemlich kranke mehrfach Havard Architektur.

Ein anderes Beispiel wäre AVR (wie z.B. in vielen Arduino).

Er will es aber ohne ROM und ohne RAM. Ohne ROM gibt's immerhin den 
8031, auch wenn wohl nur abgeschaltet. Aber ohne RAM?

Es gab allerdings wirklich einen Mikroprozessor mit m.W. getrennt 
rausgeführten Bussen: Motorola 88100. Dürfte aber selbst in Museen 
selten sein.

Also will einen 8-bit retro computer bauen. Ich schau mir 8051 und efm8 
mal an.
Sollte ich keinen geeigneten Chip finden, überlege ich einen fpga zu 
nehmen und ihn mit einem risc-v Basis Befehls Satz auszustatten, damit 
es einen ordentlichen Compiler gibt. Ich lass den thread aber noch ein 
bisschen offen für Rückfragen oder weiteren Vorschlägen

Stefan S. schrieb:
> damit es einen ordentlichen Compiler gibt

Retro mit modernem Compiler, ist das kein Stilbruch?

(prx) A. K. schrieb:
> Motorola 88100.

Darauf habe ich vor 30 Jahren mit Unix angefangen: DG/UX, Data General 
AViiON.

Aber ich geb' dir recht: scheint selbst museal nicht mehr groß zu 
existieren. Der Compiler hatte übrigens einen "Silicon filter": damit 
wurden die Hardware-Bugs des m88k im generierten Assemblercode manuell 
umschifft. :-o

Stefan S. schrieb:
> Sollte ich keinen geeigneten Chip finden, überlege ich einen fpga zu
> nehmen und ihn mit einem risc-v Basis Befehls Satz auszustatten,

Ich hoffe, dir ist klar, dass ein RISC-V keine Harvard-Architektur ist.

Natürlich, aber ich will ja auch nur den Befehls Satz benutzen und nicht 
die Architektur...
Ich will dass die Befehle möglichst gleich kodiert sind. Hab aber nur 
risc-v geschrieben, Weill mir keine andere Architektur bekannt ist, die 
gut dokumentiert und für die halbwegs aktuelle kompiler existieren.

S. R. schrieb:
> dass ein RISC-V keine Harvard-Architektur ist.

Getrennte Busse für I und D kann man aber auch bei gemeinsamem 
Adressraum implementieren. Der ARM9 Core des STR9 hat gleich 3 Busse zum 
Rest vom Chip. Ist halt wieder die Frage, woran man Harvard festmacht. 
An den Bussen oder den Adressräumen.

Für mich ist es hauptsächlich die Trennung der Busse. Ich weiß, dass ich 
darauf keinen Einfluss habe, aber meine Hoffnung ist, dass man mit 
getrennten Bussen für I und D leichter pipelining machen kann. Ich hoffe 
trotzdem dass es vielleicht ein wenig schneller sein kann.


Mein großes Endziel ist eine komplett eigene Architektur, die auf einem 
Cpld oder fpga ausgeführt ist. Deswegen möchte ich erst einmal Erfahrung 
mit verschiedenen alten Architekturen sammeln.
Ich würde da als experiment gerne die Einfachheit der alten computer mit 
den modernen Techniken verbinden.


Mit der 6502 Architektur hab ich jetzt länger gespielt. Ich würde jetzt 
noch andere Architekturen ausprobieren.
Mit dem w65c816 Bau ich gerade ein komplexere System das getrennte 
addressräume für beides besitzt. Da ist halt einiges an glue logic 
notwendig damit das funktioniert.


Dass die avr Controller auch harvard benutzen ist mir entgangen...
Wollte grad nur nochmal erklären, was mein Ziel ungefähr ist, weil die 
Diskussion ansonsten wahrscheinlich irgendwann relativ schnell zu einer 
Sinn vs Unsinn Diskussion verkommt.
Vielen Dank für das produktive feedback

Stefan S. schrieb:
> Für mich ist es hauptsächlich die Trennung der Busse.

Die mit Abstand konsequenteste Implementierung einer Havard-Architektur 
mit getrennten Bussen besitzt die SP-50-Familie von Valvo, mit den 
Ausführungen PCB5010 mit maskenprogrammiertem ROM und PCB5011 mit 
externem Speicher.

Es gibt sogar insgesamt vier verschiedene Adressräume mit getrennten 
Bussen:

1. Programmspeicher
2. X-RAM
3. Y-RAM
4. Koeffizienten-ROM

Die Befehle sind 40 Bit breit und enthalten jeweils einen Bereich für 
die verschiedenen Einheiten des Prozessors, d.h. ALU, Adresszaehler, 
usw., ähneln also vom Aufbau der VLIW-Architektur klassischer 
Cray-Rechner. Dadurch führen sie pro Befehlswort immer sechs Befehle 
gleichzeitig aus.

ALU-Operationen verwenden immer Operanden aus verschiedenen Speichern 
und somit Adressräumen, so dass man schon ganz genau planen muss, wo man 
was ablegt. Es gibt keine "Hintertür" wie bei den meisten anderen 
Harvard-basierten Prozessoren, um auf einen anderen Speicher 
zuzugreifen. Beispiel:

1

r := a + b

2

s := a + c

3

t := b + c

Dies ist nicht direkt möglich, da man die Variable a, b und c nicht so 
auf X-RAM und Y-RAM aufteilen kann, dass jeweils eine ALU-Operation auf 
X und Y zugreift. Folglich muss man eine der Variable erst ins anderen 
RAM umkopieren. Ich bin mir nicht einmal sicher, ob es solch einen 
Befehl überhaupt gibt oder ob man statt dessen die Konstante 0 ins 
Koeffizieten-ROM legen und dann eine Addition (X) + (C) => (Y) 
durchführen muss.

Es gibt zudem überhaupt keine Möglichkeit, Datenzugriffe auf den 
Programmspeicher durchzuführen, um z.B. ein Programm in den Speicher zu 
laden. Das muss man ggf. alles außerhalb des Prozessors mit Hilfslogik 
realisieren.

Ich habe vor ewiger Zeit damit begonnen, eine ISA-Einsteckkarte mit 
einem PCB5011 aufzubauen, bei der der PC (nach Deaktivieren des DSP) 
Zugriff auf alle vier Adressräume hat. Diese Karte ist leider niemals 
fertig geworden, aber ich habe es mir fest vorgenommen, das irgendwann 
in diesem Leben noch zu erledigen. Vielleicht sollte ich irgendwann 
einmal ganz vorsichtig mit dem Einlesen bzw. Umkopieren der Disketten 
für den Assembler beginnen.

Übrigens eignen sich "normale" Programmiersprachen wie z.B. C nicht 
besonders gut für die Arbeit mit solchen strikt adressraumgetrennten 
Prozessoren, da es keine Ausdrucksmöglichkeiten für Adressräume gibt, 
z.B. in Form von Speicherklassen. Auch bei Pointern müsste man sich 
irgendwelche Tricks überlegen, um zu kennzeichnen, auf welchen 
Adressraum sie sich beziehen sollen. Ansonsten müsste man viel zu viel 
dem Compiler überlassen.

Es gibt auch noch (mindestens) eine weitere DSP-Architektur, die ähnlich 
konsequent realisiert ist, nämlich Motorola DSP5600x. Hierfür sollte man 
auch noch wesentlich mehr Literatur, Software und auch Bauelemente 
finden.

PS: Wie sich vielleicht schon herumgesprochen hat, konnte sich die 
SP-50-Familie nicht wirklich auf dem Markt durchsetzen.

KORREKTUR:
Ich habe gerade noch ein Paper gefunden, in dem unter anderem die 
Architektur des PCB5010 dargestellt ist, d.h. der Version mit Masken-ROM 
und internen RAMs. Man sieht, dass alle drei Speicher wahlweise über den 
X-Bus oder Y-Bus erreicht werden können, wodurch vermutlich die obigen 
Rechenoperationen doch ohne Umkopieren möglich sind. Beim PCB5011 bin 
ich mir aber sehr sicher, dass die dort nur extern verfügbaren RAMs fest 
an die jeweiligen Busse (X-Bus, Y-Bus) angeschlossen sind. Wie es mit 
dem externen Koeffizienten-ROM (im Blockschaltbild als "DATA ROM" 
bezeichnet) aussieht, weiß ich aber nicht.

http://jjschmid.de/jjschmid-background.pdf

Motorola DSP 560xx. Ähnelt der SP-50 Familie, ebenfalls mit X und Y-RAM. 
Für Signalverarbeitung OK. Alles andere erfordert(e) Verrenkungen mit 
dauerndem umkopieren zwischen den RAM Bereichen.

Wolfgang schrieb:
> Um die Zahl der Leitungen zu reduzieren wurde da teilweise gemultiplext.

Das widerspricht ja nun aber komplett dem Ziel, durch Trennung der Busse 
möglichst schnell und einfach zu werden.

(prx) A. K. schrieb:
>> dass ein RISC-V keine Harvard-Architektur ist.
> Getrennte Busse für I und D kann man aber auch bei gemeinsamem
> Adressraum implementieren.

Stimmt, aber dann ist es für den Programmierer ja wieder ein von 
Neumann-Modell. Für die Wahre Schottische, äh, Harvard-Erfahrung braucht 
man aber auch getrennte Befehlssätze für die einzelnen Busse und das 
bietet der RISC-V-Befehlssatz nicht. ;-)

Das von Neumann-Programmiermodell hat sich durchgesetzt. Ob der 
Prozessor jetzt Harvard, von Neumann oder eine Hybridmischung macht, 
spielt für den Programmierer so gut wie keine Rolle - und so verhalten 
sich auch moderne Programmiersprachen bzw. Compiler.

Stefan S. schrieb:
> Ich hoffe trotzdem dass es vielleicht ein wenig schneller sein kann.

Du kannst dir ja modernere Ansätze der Mikroarchitekturen anschauen, 
z.B. Instruction Fusion. Mit einem CPLD wird das aber vermutlich alles 
nichts.

S. R. schrieb:
> Mit einem CPLD wird das aber vermutlich alles nichts.

Aus meinem Verständnis heraus ist ein cpld mehr oder weniger fast das 
gleiche wie ein fpga nur ohne features wie eigener RAM, ad Wandler, etc.
Auch wenn der größte fpga vllt größer ist als der größte cpld, sind die 
cplds uaf jeden fall groß genug um eine 8 bit soft CPU zu beinhalten und 
noch ein bisschen platz zu haben.

S_Hennig schrieb:
> Kennst Du das Buch "The Elements of Computing Systems -- Building a
> Modern Computer from First Principles" von Noam Nisan und Shimon
> Schocken?

Nope, kannte ich bisher nicht, steht aber jetzt auf meiner Amazon 
Wunschliste.

Nick M. schrieb:
> Also, es ging darum, dass Google und Amazon mit ihren Cloud-Servern
> langsam die Hosen voll bekommt vor Angriffen. Die Harvard-Architektur
> ist deutlich sicherer vor Angriffen von aussen auf den Programmcode. Bei
> der ganzen Sache beteiligt sich auch IBM. Es wurden paar Prozessoren
> genannt, aber die hab ich vergessen ...

Ging es vllt um IBMs power architektur? Oder war das noch was anderes?

MaWin schrieb:
> ein 1-dimensionales Array von FlipFlops "Registern" entlang der
> Aussenpinreihe

Manfred, ich glaube, dein Wissen aus dem vorigen Jahrtausend darfst du 
mal auffrischen:

https://www.xilinx.com/publications/products/cpld/coolrunnerii-product-brief.pdf

Wie du 512 Makrozellen nur an der „Außenpinreihe“ (wo ist die eigentlich 
bei einem BGA?) platzierst, wäre eine interessante Frage.

Allerdings: die Ressourcen der größten CPLDs sind etwa im gleichen 
Bereich wie die der kleinsten FPGAs. Es ist also keineswegs nur so, dass 
nur die „größten FPGAs“ da deutlich mehr zu bieten hätten, wie Stefan 
oben postulierte.

Ich würde jedenfalls für CPU-Experimente selbst kein CPLD nehmen wollen 
sondern ein FPGA. Aber das muss er selbst wissen. Für den Preis so eines 
512er CoolRunner-II-ICs (60 Euro) bekommt man jedenfalls schon 
problemlos ein komplettes FPGA-Entwicklungsboard.

Ingo E. schrieb:
> Motorola DSP 560xx. Ähnelt der SP-50 Familie, ebenfalls mit X und Y-RAM.
> Für Signalverarbeitung OK. Alles andere erfordert(e) Verrenkungen mit
> dauerndem umkopieren zwischen den RAM Bereichen.

Es wurde schon alles gesagt, aber bloß nicht von jedem. Ich hatte 
bereits auf diese Familie hingewiesen:

Andreas S. schrieb:
> Es gibt auch noch (mindestens) eine weitere DSP-Architektur, die ähnlich
> konsequent realisiert ist, nämlich Motorola DSP5600x. Hierfür sollte man
> auch noch wesentlich mehr Literatur, Software und auch Bauelemente
> finden.

MCUA schrieb:
> CPLDs wären mit ihren breiten EingangsMatrix und den breiten
> VerbindungsStrukturen prinzipiell besser geeignet als FPGAs, wenn sie
> genug MCs hätten.

Das war auch Mein letzter Stand. Ich hab mich nur nicht getraut das 
explizit zu behaupten.
Und zum Thema Preis von oben:
Ich habe ein Board das kostet 10€ incl. Versand mit einem cpld von 
altera. Da kasst der core von einem w65c816 rein und es ist noch über 
die Hälfte Platz (laut der ide von altera). Ich hab geschaut nach 
vergleichbaren fpgas und die billigsten Boards die zu meinem cpld 
ungefähr equivalent waren, waren cyclone 3 boards für 30€...


Ich glaube da ist mehr als genug Platz für das was ich machen will.

Nick M. schrieb:
> PowerPC wurde auch genannt.

Kann auch sein. Die Frage ist nur, obs da kleine PowerPC CPUs zu kaufen 
gibt.

MaWin schrieb:
> Viel weniger Speicher. Viel weniger Fähigkeit.

Ich brauche nur die Funktionalität einer logischen Schaltung. Dafür sind 
cplds völlig ausreichend. Für den selbstgebauten video chip werd ich 
einen fpga benutzen, da ich keine andere billige Möglichkeit kenne dual 
port RAM an so einen Chip anzubinden.

Jörg W. schrieb:
> Das widerspricht ja nun aber komplett dem Ziel, durch Trennung der Busse
> möglichst schnell und einfach zu werden.

Da gibt es einen Prozess namens pipelinig. Der wird durch einen Bus für 
program viel einfacher, da kein Datenzugriff dein Laden der nächsten 
Anweisung blockiert.

Ich will nicht weiter über die vielleicht Einsatz findenden Technologien 
diskutieren, denn ich bin nicht mal mit dem alten Projekt fertig. 
Vielleicht stellt sich in der Implementatierung vom Projekt raus, dass 
ein cpld nicht mehr wirtschaftlich ist und ich nehme dann am Ende doch 
einen fpga. Das schau ich aber dann.

Außerdem ist das was ich machen will ja nur ein Experiment. Ich will 
versuchen was zu bauen das von außen möglichst aussieht wie ein 8 bit 
System aus den 80ern aber intern features hat die niemals eine Alte 
Architektur hatte.


Ich ich will nach und nach auch einen eigenen optimierenden Compiler für 
meine Architektur bauen und ein eigenes Multitasking OS bauen.
Ich hoffe die großen Kritiker bemerken, dass das nur ein verrücktes pet 
Projekt ist, wo es drum geht Spaß zu haben und nicht die beste neue 
Architektur zu bauen.


Und schon wieder vielen Dank an alle interessanten Denkanstöße und 
Hinweise von allen. Und natürlich auch vielen Dank an alle kritischen 
Stimmen.

MCUA schrieb:
> Das wird ein FPGA nicht PLD sein.

Nope, das ist ein Max II cpld.

Nick M. schrieb:
> Die Harvard-Architektur
> ist deutlich sicherer vor Angriffen von aussen auf den Programmcode.

Wenn die MMU zwischen Daten und Code unterscheidet, Code nicht schreibt 
und Daten nicht ausführt, dann ist die Situation sicherheitstechnisch 
ähnlich Harvard. So geschehen mit dem NX Bit, das zum "return oriented 
programming" führte. Und dagegen hilft Harvard nicht.

Nick M. schrieb:
>> So geschehen mit dem NX Bit, das zum "return oriented
>> programming" führte. Und dagegen hilft Harvard nicht.
>
> Der Stack ist nicht im Code-Adressraum. Daher kann da auch nichts
> ausgeführt werden.

Erst nachgucken was das ist, dann kommentieren.

Selbst in quarts steht cpld. Dann sollten wir uns mal bei altera 
beschweren.

Diese Unterscheidung gab es übrigens schon früher. Intels Segmentierung 
ab 286 unterschied zwischen Code- und Datensegmenten. Und Telefunkens 
Grossrechner TR-440 von 1969 markierte Speicherworte mit 2 Bits 
Typenkennung, einer davon für Befehle, weshalb für jeden, der jemals was 
damit zu tun hatte, der Typenkennungsalarm ein Begriff ist.

Nick M. schrieb:
> Und, was nütz das? Ist das ein von dir eingeschleuster Code? Nein.
> Und wie kannst du auf den Stack zugreifen, ohne deinen eigenen Code
> einzuschleusen?

Du schleust damit nur Zeiger auf bestehenden Code ein, keinen eigenen 
Code. Auf den Stack kann man zugreifen, weil der in Programmiersprachen 
wie C ein Mix aus Daten und Returnadressen ist. Ein Bufferoverflow 
erwischt damit die Returnadresse. Das ist bloss etwas umständlich.

Weniger gut funktioniert das in Sprachumgebungen, die keine Daten im 
Stack adressieren. Wie etwa in klassischem Fortran.

MCUA schrieb:
> Man kriegt diese Bits immer irgentwie zu Instruktion.

Jo, aber wenn im Befehlsspeicher nur Masken-ROM ist, musst du schon den 
Chiphersteller bemühen, deinen Code dort unterzubringen. ;-)

Und wenn das Teil dann auch noch einen separaten Hardware-Stack für 
Returnadressen hat, dann wirds auch schwierig, diese zu manipulieren.

MCUA schrieb:
> Masken-ROM wäre wohl das relativ am sichersten.
> aber auch das nicht mit 100%.
> Man kann u.U. dieses ROM umgehen und liest diese Daten von sonst wo her.

Nö, nicht bei Prozessoren, die keinen anderen Speicher für Programmcode 
kennen. Auch bei den o.a. DSP gibt es prinzipbedingt keine Hintertür für 
anderen Programmcode.

Und da es auch gar keine Write-Enable-Leitung o.ä. für den Programmbus 
gibt, kann es auch keine Schreibzugriffe geben. Somit genügen auch 
normale EPROMs bzw. Flash-Bausteine, die extern programmiert werden.

Darf ich mich mal einschalten?
Ich hab zu Harvard immer die Vorstellung zwei Stacks zu haben. Einen 
return stack und einen data stack.
Damit wäre rop auch ausgeschlossen.


Bei meinem Projekt soll es aber nicht primär um Sicherheit gehen, 
sondern eher um Performance.


Ich finde es aber sehr interessant dass die Diskussion grad wieder total 
am abdriften ist.

Ich mach mir aber fleißig Notizen 😊. Ich hab übrigens mit Unterstützung 
von einem makro Assembler und dem 65816 schon einen getrennten Daten und 
Programm stack gebaut. Wie ich das mache passt hier aber grad nicht ganz 
rein.

MCUA schrieb:
> 100% sicher wird wohl nichts zu machen sein.
> Man kriegt diese Bits immer irgentwie zu Instruktion.

Hast Du Dir überhaupt mal die SP-50- und DSP56k-Architekturen 
angeschaut? Ohne externe Verbindung zwischen den Bussen ist da nix mit 
Hintertürchen. Der ganz große Nachteil besteht dann aber auch darin, 
dass man ohne externe Mittel kein Firmwareupdate durchführen oder 
Softwareteile nachladen kann.

Stefan S. schrieb:
> Bei meinem Projekt soll es aber nicht primär um Sicherheit gehen,
> sondern eher um Performance.

Dann solltest Du lieber ein hochintegriertes SoC mit internem SRAM 
einsetzen. Mit einem FPGA-Anteil dazu kann man auch tolle 
Rechenbeschleuniger und Wunderperipherie realisieren. Beispiel: Xilinx 
Zynq 7000, MPSoC, RFSoC.

MCUA schrieb:
> ..was ein FPGA ist.

Ist es nicht. Beweis folgt:
https://www.intel.de/content/www/de/de/products/programmable/cpld/max-ii.html

Das ist ein billiges Board mit einem altera Max II. Ich hab dir mal 
einen random link von ebay raus gesucht.

https://www.ebay.de/itm/133514948782

Andreas S. schrieb:
> Dann solltest Du lieber ein hochintegriertes SoC mit internem SRAM
> einsetzen.

Damit kann ich dann aber keinen diskreten computer mehr bauen. Mein 
Limit sind eh wenige Megahertz. Nach wie vor wird wahrscheinlich fast 
jeder arduino schneller sein als dieser computer.

Ich will trotzdem schauen, was ich aus einer alten Architektur bzw einer 
selbst gebauten minimalistischen Architektur noch rausholen kann.

Deswegen auch meine liebe zum w65c816. Das Teil gibt einem alle 
möglichen Informationen die es ermöglichen außergewöhnliche Dinge zu 
tun, wenn man den original 6502 im Hinterkopf behält.
Das Design was ich grade entwerfen und baue hat nicht nur 1M Adress 
Raum, sondern auch sondern sogar das doppelte. (64k *256. Mit 
Unterscheidung zwischen Daten und Code.)

Es läuft mit einer Art pseudo Havard, damit ich in der Zeit wo der 
Prozessor Anweisungen liest kann der Rest vom System dma machen.
Ich hab meine glue logic in einem cpld, das es ermöglicht über einen in 
Rom vorliegenden kleinen bootloader verschiedene Programme zu laden...

In Sachen Performance werd ich zwar nicht mehgr viel reißen können, aber 
ich mach das ja wegen dem Spaß....

Stefan S. schrieb:
> Damit kann ich dann aber keinen diskreten computer mehr bauen.

Wenn der Computer wirklich diskret werden soll, dann nimm einen 
74LS181 als Basis, 74LS95A als Register.

So eine Idee hatte ich vor Jahrzehnten, daher extra dazumals einen 74181 
gekauft, Projekt ist aber nie geworden …

Stefan S. schrieb:
> Das Design was ich grade entwerfen und baue hat nicht nur 1M Adress
> Raum, sondern auch sondern sogar das doppelte. (64k *256. Mit
> Unterscheidung zwischen Daten und Code.)

Wenn Du scharf auf Bankumschaltung und eine möglichst altertümliche und 
leicht verkorkste Architektur bist, dann wäre doch sicherlich bo8 das 
richtige für Dich. Dort wird ja auch sehr viel auf Steckkarten 
realisiert, was man eigentlich auch gleich mit ins FPGA integrieren 
könnte.

Jörg W. schrieb:
> Wenn der Computer wirklich diskret werden soll, dann nimm einen
> 74LS181 als Basis, 74LS95A als Register.

Oder gleich Am290x. Damit könnte man sich z.B. auch einen zur DEC 
PDP-11/34 oder Siemens R10VH kompatiblen Prozessor bauen. Leider habe 
ich vor etlichen Jahren meine Kuchenbleche voll mit Am290x entsorgt. 
:-(((

Ganz so diskret sollte es doch nicht sein.


Ich wollte halt gerne ein paar schwarze Käfer haben.

Stefan S. schrieb:
> Ich wollte halt gerne ein paar schwarze Käfer haben.

Dann drapiere die doch um ein FPGA rundrum, und hänge ein paar 
Blinkenlights mit dran. ;-)

Sorry, nicht ernst gemeint. Ich würde sowas heutzutage wohl wirklich 
komplett in einem FPGA realisieren. Habe vor Kurzem mal als VHDL-Übung 
meine alte Bildschirmsteuerung (Erzeugung des BAS-Signals für 
Fernseher), die ich vor 35 Jahren in Hardware genagelt hatte, aufgebaut.

Stefan S. schrieb:
> Ich wollte halt gerne ein paar schwarze Käfer haben.

Die Bausteine der Am290x-Familie gibt es nicht nur im grauen 
Keramikgehäuse, sondern auch im schwarzen Kunststoffgehäuse. Auch beim 
74181 waren schwarze Kunststoffgehäuse sehr gebräuchlich.

Abgesehen davon finde ich die Vielzahl an keramischen Gehäuse sogar viel 
spannender; insbesondere die Ausführungen mit vergoldetem, aufgelöteten 
Deckel machen doch richtig etwas her, insbesondere auch als EPROM.

Ich kann grad ein paar Worte vhdl und noch weniger verilog. Deshalb will 
ich keine eigene soft CPU implementieren😅

Für den address decoder schaffe ich das grad so noch.

Ich bau wahrscheinlich besser kein komplettes System nach. Mal schauen 
was ich mach, wenn ich fertig bin.

Jörg W. schrieb:
> Wenn der Computer wirklich diskret werden soll, dann nimm einen
> 74LS181 als Basis, 74LS95A als Register.
>
> So eine Idee hatte ich vor Jahrzehnten, daher extra dazumals einen 74181
> gekauft, Projekt ist aber nie geworden …

Bau doch den MIPS TTL nach ;)

Ne, kenn ich noch nicht, aber danke für den link

Andi schrieb:
> Stefan S. schrieb:
>>> ..was ein FPGA ist.
>>
>> Ist es nicht. Beweis folgt:
>> https://www.intel.de/content/www/de/de/products/programmable/cpld/max-ii.html
>
> Auf der verlinkten Seite gibt es eine FAQ mit dem ersten Eintrag: "What
> is the MAX II device family?"
> Da steht:
> "Altera’s MAX II family of low-cost CPLDs was the first architecture
> introduced that combines the best of traditional CPLD architectures with
> Altera's innovative FPGA look-up table (LUT) logic structure. "
>
> Es gibt halt Hersteller, die FPGAs mit OnChip Flash für die
> Konfiguration als CPLD vermarkten. Das man keinen externen
> Konfigurationsspeicher bei CPLD brauchte war wohl das was sie als "the
> best of traditional CPLD architectures" betrachten.

So weit ich das richtig verstanden habe was im Datenblatt steht ist es 
ein CPLD mit relativ kleinen makrozellen. Außerdem meint altera die 
machen da irgendwas damit sie die makrozellen ähnlich einfach herstellen 
können wie luts.
Und wenn selbst im Datenblatt nicht steht, dass es ein fpga ist, wird 
das wohl auch nicht so sein.