Schönen Samstag Nachmittag! Ich arbeite schon länger an der Entwicklung eines diskreten 8 bit Computers. Damit das Ganze auch (ein wenig) praktischen(*) Wert hat sollte dieser auf einen möglichst großen Speicher zugreifen können. Ich dachte dabei an einen 32 bit breiten Adressbus, sodass circa 4 GB problemlos adressiert werden können. Dieser "Computer" wird in einem (oder mehreren wenn nötig) 19-Zoll Gehäuse (Höhe 3 Einheiten) untergebracht. Derzeit beschäftige ich mich mit dem Designen der Frontplatte. Über diese sollen Daten "von Hand" eingegeben und ausgelesen werden können (zu "Debug-Zwecken), außerdem sollen sich noch diverse Schnittstellen darauf befinden (RS232, VGA, PS2 für Tastatur, ...). Ich dachte an 7 Segmentanzeigen für die Ausgabe von hexadezimalen Werten (2 Stück für den 8-bit Datenbus und 8 Stück für den 32-bit Adressbus). Das "Problem" ist jedoch die Eingabe von 32 bit Werten für den Adressbus. Folgende Möglichkeiten kämen in Frage, jede hat Vorteile und Nachteile: 32 Schalter =========== Vorteile: + Einfache Verdrahtung Nachteile: - Sehr hoher Platzbedarf - Einzugebende Werte müssen erst in binäre Werte umgerechnet werden 8 Drehschalter mit je 16 Positionen =================================== (z.B. https://www.digikey.at/en/products/detail/51A22-01-1-16N/GH7686-ND/4112289?itemSeq=387241772) Vorteile: + Werte können direkt hexadezimal eingegeben werden Nachteile: - Sehr hoher Platzbedarf Hexadezimales Tastenfeld ======================== Vorteile: + Werte können direkt hexadezimal eingegeben werden Nachteile: - Viel zusätzliche Logik erforderlich (Tastenmatrix abfragen, Zähler der nach jeder Eingabe inkrementiert wird, ...) ----------------- Wie gesagt, jeder Lösungsansatz hat seine Vor - und Nachteile, deshalb dachte ich ich frage mal hier wie ihr das Problem lösen würdet. Ja, ich weiß dass ein "8 bit Computer aus diskreter Logik" ein "sinnloses" Projekt ist. --------------- --------------- "Praktischer Wert" heißt für mich in diesem Fall dass ich auf der Kiste zum Beispiel einen Texteditor oder ähnliches implementieren kann. Und ja, VGA geht in diskreter Hardware, man braucht nur eine handvoll Zähler, Komparatoren, Speicher und einen DAC.
:
Bearbeitet durch User
Ich würde 32 Taster, in Kombination mit 32 LEDs verwenden, welchem Prinzip arbeiten wie ein Schieberegister. Bits setzen Bits einspielen.
Beitrag #6944503 wurde von einem Moderator gelöscht.
HÄ? Was ist für ein Umgangston? Und was ist falsch? Ausser, das 32-Bit-Adresse für 8-Bit Prozessor doch etwas übertrieben ist. Gruss
Erich schrieb: > HÄ? > Was ist DAS für ein Umgangston? > Und was ist falsch? > Ausser, das 32-Bit-Adresse für 8-Bit Prozessor doch etwas übertrieben > ist. > Gruss
So etwas gibts auch: https://www.ia.omron.com/data_pdf/cat/a7bs_a7bl_ds_e_6_2_csm25.pdf Vorteil: beliebig anreihbar für Tafelmontage Nachteil: nicht ganz billig fchk
Andre G. schrieb: > Ich dachte dabei an einen 32 bit breiten Adressbus, sodass > circa 4 GB problemlos adressiert werden können. Ja nee, is klar. Denk nochmal über die Entscheidung nach, denn sie ist schlicht blöd. > Dieser "Computer" wird in einem (oder mehreren wenn nötig) 19-Zoll > Gehäuse (Höhe 3 Einheiten) untergebracht. Ja nee, is klar. Denk erstmal über die Gesamtarchitektur nach, bevor du dich an das Design der Frontplatte machst. > Derzeit beschäftige ich mich mit dem Designen der Frontplatte. > Über diese sollen Daten "von Hand" eingegeben und ausgelesen werden > können (zu "Debug-Zwecken), außerdem sollen sich noch diverse > Schnittstellen darauf befinden (RS232, VGA, PS2 für Tastatur, ...). Ja nee, is klar. Warum sollen die ganzen Ports vorne dran sein, wenn du das schon mit Tasten und LEDs vollstopfen willst? Das stinkt alles so richtig nach Troll. Schau dir an, wie die Frontplatte von einem IMSAI oder ALTAIR funktioniert, dann weißt du auch, wie man mit einem minimalen Aufwand da rankommt. Als Tipp: Nimm noch drei 8-Bit-Latches und einen prellfreien Taster dazu und fertig ist die Eingabe.
Andre G. schrieb: > Ich arbeite schon länger an der Entwicklung eines diskreten 8 bit > Computers. > Damit das Ganze auch (ein wenig) praktischen(*) Wert hat sollte dieser > auf einen möglichst großen Speicher zugreifen können. > Ich dachte dabei an einen 32 bit breiten Adressbus, sodass circa 4 GB > problemlos adressiert werden können Find ich gut, das diskret aufzubauen sind ca. 206 Milliarden Transistoren. Man wird sowieso nie mehr als 258 Adressen also 8 Schalter per Hand eingeben wollen, insofern kannst du ruhig 32 Schiebe- oder Kippschalter nutzen, von denen 24 nur ein Mal eingestellt werden. Andre G. schrieb: > Ich dachte an 7 Segmentanzeigen für die Ausgabe von hexadezimalen Werten > (2 Grässlich Entweder 4 LED oder hübsche https://www.ebay.de/b/Siemens-LED-Anzeigemodule/181882/bn_18158979 oder https://www.ebay.de/itm/362273946948?hash=item545935bd44:g:Y8cAAOSw0gFasCC9 aber die gelten nicht mehr als diskret.
c-hater schrieb im Beitrag #6944503: > Andre G. schrieb: > >> Das "Problem" ist jedoch die Eingabe von 32 bit Werten für den >> Adressbus. > [...] >> 8 Drehschalter mit je 16 Positionen >> =================================== > > Damit ist klar, dass du ein Troll bist (und obendrein ein dramatisch > inkompetenter). Also, verpiss dich, du Arschloch. Ein Drehschalter mit 16 Positionen (0123456789ABCDEF) für jedes halbe Byte. Also zwei Drehschalter für jedes Byte. 32 bit sind 4 Byte. Wenn man für jedes Byte zwei Drehschalter benötigt und 4 Bytes eingeben will braucht man 4*2=8 Drehschalter. Was hat das mit "inkompetenter Trollerei" zu tun?
Frank K. schrieb: > So etwas gibts auch: > > https://www.ia.omron.com/data_pdf/cat/a7bs_a7bl_ds_e_6_2_csm25.pdf > > Vorteil: beliebig anreihbar für Tafelmontage > Nachteil: nicht ganz billig > > fchk Das ist ein viel besserer Ansatz als viele einzelne Drehschalter. Genau so etwas habe ich gesucht!
MaWin schrieb: > Andre G. schrieb: >> Ich arbeite schon länger an der Entwicklung eines diskreten 8 bit >> Computers. >> Damit das Ganze auch (ein wenig) praktischen(*) Wert hat sollte dieser >> auf einen möglichst großen Speicher zugreifen können. >> Ich dachte dabei an einen 32 bit breiten Adressbus, sodass circa 4 GB >> problemlos adressiert werden können > > Find ich gut, das diskret aufzubauen sind ca. 206 Milliarden > Transistoren. Mit "diskret" meinte ich "aus Logik-ICs", nicht wirklich komplett diskret aus Transistoren. Das hätte ich vielleicht erwähnen sollen ... Ich bin verrückt, aber nicht SO verrückt ;-)
S. R. schrieb: Als Tipp: Nimm noch drei 8-Bit-Latches und einen prellfreien > Taster dazu und fertig ist die Eingabe. Werde ich mir anschauen. Zum Thema "warum die Stecker vorne": Weil auf der Rückseite des Gehäuses eine große Leiterplatte für die Bus-Verbindung der einzelnen Leiterplatten ist. (https://www.digikey.at/en/products/detail/vector-electronics/VMEBP21J1/500967?s=N4IgTCBcDaIGoEYwIQWgHIBEQF0C%2BQA) Deshlab ist auf der Rückseite kein Platz für Steckverbinder.
S. R. schrieb: > Andre G. schrieb: >> Ich dachte dabei an einen 32 bit breiten Adressbus, sodass >> circa 4 GB problemlos adressiert werden können. > > Ja nee, is klar. Denk nochmal über die Entscheidung nach, denn sie ist > schlicht blöd. Wieso das denn? Mit 32 Bit kann man 4.294.967.296 Adressen ansprechen.
Andre G. schrieb: > Das "Problem" ist jedoch die Eingabe von 32 bit Werten für den > Adressbus. Warum "Problem"? Schon bei der PDP-11 vor gut 50 Jahren hatte man das gelöst. Die Dreiergruppen der Schalter für die Tripletts sind farblich voneinander abgesetzt und gliedern dadurch die Eingabe. https://static.wixstatic.com/media/ce503a_28b23ab5475e4616a14c93abf28d1328~mv2_d_1988_1225_s_2.jpg > 32 Schalter > =========== > ... > - Einzugebende Werte müssen erst in binäre Werte umgerechnet werden Du brauchst jetzt nicht ernsthaft eine App bzw. ein Online Tool für die Umrechnung von Hexadezimal nach Binär, oder?
Wolfgang schrieb: > Andre G. schrieb: >> Das "Problem" ist jedoch die Eingabe von 32 bit Werten für den >> Adressbus. > > Warum "Problem"? > Schon bei der PDP-11 vor gut 50 Jahren hatte man das gelöst. > Die Dreiergruppen der Schalter für die Tripletts sind farblich > voneinander abgesetzt und gliedern dadurch die Eingabe. > https://static.wixstatic.com/media/ce503a_28b23ab5475e4616a14c93abf28d1328~mv2_d_1988_1225_s_2.jpg > >> 32 Schalter >> =========== >> ... >> - Einzugebende Werte müssen erst in binäre Werte umgerechnet werden > > Du brauchst jetzt nicht ernsthaft eine App bzw. ein Online Tool für die > Umrechnung von Hexadezimal nach Binär, oder? Dreiergruppen? Wieso nicht Vierergruppen, das würde mehr Sinn machen (vier bits sind ein "hexadezimales Zeichen"). Nein, das kann man schon im Kopf umrechenen, ich habe nur all die Vor- und Nachteile der einzelnen Möglichkeiten aufgelistet.
Andre G. schrieb: >>> Ich dachte dabei an einen 32 bit breiten Adressbus, sodass >>> circa 4 GB problemlos adressiert werden können. >> Ja nee, is klar. Denk nochmal über die Entscheidung nach, >> denn sie ist schlicht blöd. > Wieso das denn? Weil man keinen 250 PS Turbodiesel in einen Trabant einbaut und auch keinen Mofamotor in einen Porsche. Mit anderen Worten, man arbeitet sinnvollerweise mit halbwegs balancierten Systemen. > Mit 32 Bit kann man 4.294.967.296 Adressen ansprechen. Das sind nicht "circa 4 GB", sondern sogar ziemlich exakt. Und du brauchst wieviele Befehle, um auf deiner CPU eine 32 Bit breite Adresse zu generieren und zu dereferenzieren? Wenn du klug wärst, dann würdest du mal ein paar Algorithmen (z.B. "sortiere ein Array") grob skizzieren und dir anschauen, wie geil dein Code ist. Dann merkst du, dass 32 Bit-Adressen auf einer 8 Bit-CPU schlicht bescheuert sind. (Schon 16 Bit-Adressen auf einem i8080 sind nervig genug, und damit habe ich hinreichend Erfahrung, um das auf 32 Bit-Adressen extrapolieren zu können. Bauen wirst du es sowieso nicht.)
Andre G. schrieb: > Dreiergruppen? > > Wieso nicht Vierergruppen, das würde mehr Sinn machen (vier bits sind > ein "hexadezimales Zeichen"). Das war vor 40..50 Jahren. Damals wurden die Binärzahlen meist als Oktalzahlen dargestellt. Hexdezimal verbreitete sich erst mit den Mikroprozessoren.
Andre G. schrieb: > Ich dachte dabei an einen 32 bit breiten Adressbus, sodass circa 4 GB > problemlos adressiert werden können. Andre G. schrieb: > Mit "diskret" meinte ich "aus Logik-ICs", nicht wirklich komplett > diskret aus Transistoren. Es haben sich schon genug Leute an 4 und 8 Bit abgemüht. Wie willst du eigentlich 4 GB RAM diskret "aus Logik-ICs" aufbauen? Hast du schon ein Fußballfeld gepachtet und ein den Bau eines Kraftwerks in Auftrag gegeben? Die Taktfrequenz wird dann wohl so um 10 kHz liegen. Und das manuelle Befüllen mit Drehschaltern dauert ... wahrscheinlich stirbt die Menschheit vorher aus. Ganze ehrlich: Mach mit deiner Zeit und dem Geld was sinnvolleres. Du könntest zum Beispiel einen Bunker bauen.
Andre G. schrieb: > Nachteile: > - Viel zusätzliche Logik erforderlich (Tastenmatrix abfragen, Zähler der > nach jeder Eingabe inkrementiert wird, ...) Für solche Dinge ist 'Das CMOS Kochbuch' immer noch eine gute Quelle. ISBN 3-88322-002-7 Don Lancaster Bild 7-18 und Bild 3-34 kombiniert ergibt eine ASCII Tastatur.
Stefan ⛄ F. schrieb: > Andre G. schrieb: >> Ich dachte dabei an einen 32 bit breiten Adressbus, sodass circa 4 GB >> problemlos adressiert werden können. > > Andre G. schrieb: >> Mit "diskret" meinte ich "aus Logik-ICs", nicht wirklich komplett >> diskret aus Transistoren. > > Es haben sich schon genug Leute an 4 und 8 Bit abgemüht. Wie willst du > eigentlich 4 GB RAM diskret "aus Logik-ICs" aufbauen? Hast du schon ein > Fußballfeld gepachtet und ein den Bau eines Kraftwerks in Auftrag > gegeben? > > Die Taktfrequenz wird dann wohl so um 10 kHz liegen. Und das manuelle > Befüllen mit Drehschaltern dauert ... wahrscheinlich stirbt die > Menschheit vorher aus. Den Speicher mache ich schon aus SRAM chips, nicht aus einzelnen 8 bit Register ICs. Die größten SRAMs die ich finden konnte die halbwegs "einfach" ansteuerbar sind haben 4194304 bytes (https://www.digikey.at/en/products/detail/alliance-memory-inc/AS6C3216A-55TIN/7101642). Ja, man bräuchte 1024 Stück von denen um auf die 4GB zu kommen. Ein solcher IC kostet aber derzeit ca. 21 € un selbst mit Mengenrabatt würde das 16920,97 € kosten. Das ist dann doch schon ein wenig über meinem Budget ... Gut also ich sehe dass das so viel Speicher wenig problematisch wird ... Vielleicht ein FPGA oder ein µC der als "Interface" zwischen meineim System und einer SD Karte, die gibt es ja in beliebiger Größe für wenig Geld.
Matthias S. schrieb: > Andre G. schrieb: >> Nachteile: >> - Viel zusätzliche Logik erforderlich (Tastenmatrix abfragen, Zähler der >> nach jeder Eingabe inkrementiert wird, ...) > > Für solche Dinge ist 'Das CMOS Kochbuch' immer noch eine gute Quelle. > ISBN 3-88322-002-7 > Don Lancaster > Bild 7-18 und Bild 3-34 kombiniert ergibt eine ASCII Tastatur. Interessant, ich denke das Buch werde ich mir zulegen.
Stefan ⛄ F. schrieb: > Die Taktfrequenz wird dann wohl so um 10 kHz liegen. Und das manuelle > Befüllen mit Drehschaltern dauert ... wahrscheinlich stirbt die > Menschheit vorher aus. Also die manuelle Ein-und Ausgabe ist nur für test und debug - Zwecke. Das auszuführende Programm wird von einem EEPROM oder SRAM gelesen der von einem "modernen PC" aus programmiert werden kann. Ja, die Taktgeschwindigkeit wird nicht gerade hoch sein. Ich habe vor die Taktrate einstellbar zu machen. Für Test und Debugzwecke habe ich auch vor einen "Single Step" Modus zu implementieren. Die maximale Taktfrequenz wird wahrscheinlich bei vielleicht maximal 100 kHz liegen, wenn alles gut läuft. (ich weiß, das ist sehr sehr optimistisch) Die VGA-Ausgabeschaltung hat eine eigene Taktversorgung, unabhängig vom eigentlichen "Prozessortakt". (Ja, ich habe mir schon Gedanken über das ganze gemacht)
Andre G. schrieb: > Den Speicher mache ich schon aus SRAM chips, nicht aus einzelnen 8 bit > Register ICs. Das ist aber gemogelt.
Was soll das? 1 Milliarde Sekunden sind über 31 Jahre. Selbst, wenn du für die Eingabe von jedem der 4 Milliarden Speicherwerte auch nur Sekunde brauchst, bist du mehrfach tot, bevor du dein Programm überhaupt eingegeben hast. Dabei hast du nur max. 125 ms Zeit, jeden Kippschalter für das Datenwort umzustellen. Angenommen, das Inkrement der Adresse läuft automatisch und du schaffst es, in infinitesimaler Zeit, das korrekt Datenwort rauszusuchen und abzulesen. Übrigens: Die ESA rechnet mit einer menschlichen Fehlerrate von 1e-3. D.h. wenn du dann "fertig" bist mit abtippen, hast du mindestens 4 Millionen Fehler in deinem Programm. P.S. welcher Schalter/Taster mindestens 4e9 Schaltspiele?
@Andre G.: Gibt es schon Fotos vom Aufbau? CPU? ALU? Wenigstens einen 32bit-Adresszähler? Komm schon, das Lämpchen vom Netzteil wird es doch wohl schon geben ...
Naturlich ist das ein "sinnloses" Projekt, aber wenn es Spass macht ist das doch völlig ok! Ein Freund von mir hat sowas vor Jahren mal komplett aus TTL gebaut, rund um die 74181-ALU herum, auf Lochraster! Paar Infos des TO kollidieren aber m.E. und sind nicht ganz klar. Da ist von VGA-Ausgabe und eventuell kleiner Textbearbeitung die Rede, andererseits aber auch von "Hex-Schaltern" und "7-Segment-Ausgabe". -WENN eine VGA-Ausgabe geplant ist, WOZU dann 7-Segment-Ausgabe? -WENN am Ende sogar kleiner Texteditor laufen soll wird eh irgendeine (rudimentäre) Tastatur nötig sein, WOZU dann "Hex-Schalter" zur Eingabe? Auch das "4GigaByte-Thema" deutet darauf hin, dass der TO noch kein klares Konzept hat, mich würden aber Details interessieren, z.B. welche Architektur, OpCode-/Befehlsbreite, etc. Es gibt eine "ZX80/81-Nachbau-Gemeinde", die zwar einen Prozessor nutzt (Z80/Derivate) aber immerhin auch OHNE die damalige "ULA" -also diskret- mit 2-3Mhz eine ganz brauchbare Textausgabe @Monitor hinbekommt. Bei Hackaday/YT/Web finden sich zahlreiche Infos, die für den TO vielleicht brauchbar sind.
Es gibt den MOS6502 aus rund 4500 discreten Transistoren: https://monster6502.com/ Dieser adressiert aber "nur" 65536 Datenwörter. Hier möchte jemand diskret 4 GB RAM adressieren, ohne sich überhaupt bewusst zu sein, was 4.294.967.296 überhaupt für eine riesige Zal ist!
Moin, - Du bist nicht allein auf dieser Welt, es gibt noch andere Enthusiasten. Unter https://www.homebrewcpuring.org/ findest Du Projekte in verschiedener Bit-Groesse. Du solltest aber die 32-Bit noch einmal darueber nachdenken: Ein Acht-Bit-Rechner ist (fuer das Hobby) schon ziemlich viel (Hardware, Microprogramming, Software), der Aufwand bei 32-Bit ist schon deutlich hoeher (und Du lernst nichts neues). Gruesse, Bonne Chance Th.
BTW. Ein DIN-A4-Blatt ist ziemlich genau 0,1 mm dick. Bedruckst du es mit 80 Zeilen deines Speicherinhaltes, ergibt das nur einen Stapel von rund 5,4 km! Ok, er halbiert sich, wenn du beidseitig ausdruckst.
Murmeltier schrieb: > Es gibt den MOS6502 aus rund 4500 discreten Transistoren: > https://monster6502.com/ Ja, wie bereits erwähnt... (Liest Du die Beiträge..?)
Vielleicht ein wenig Grundlagen fuer Clock, ALU u.s.w. zu lesen (so gar mit videos) findest Du unter https://eater.net/ 8-Bitter from scratch, kannst Du ja beliebig skalieren... Gruesse Th.
Nein! Als Großrechner noch tatächlich per Hand aus diskreten Bauteilen gebaut wurden, hatten sie einen Adressraum von einigen K-Wörtern. Sie wurden von Mathematikern projektiert (die offensichtlich Ahnung davon hatten, was sie taten) und waren dennoch so kompliziert zu bedienen, dass ebenfalls nur von solchen bedient und programmiert werden konnten. Hier möchte jemand einen Adressraum von 4G mit Kippschaltern adressieren und hat offensichtlich nicht mal den Schimmer einer Ahnung, sonst würde er nicht in einem Forum nachfragen. Noch Mal: Der Kippschalter für das LSB muss mindestens 2 Milliarden Schaltspiele aushalten. Welcher Schalter macht das mit??? Der verarscht euch doch nur!
Murmeltier schrieb: > > Hier möchte jemand einen Adressraum von 4G mit Kippschaltern adressieren > und hat offensichtlich nicht mal den Schimmer einer Ahnung, sonst würde > er nicht in einem Forum nachfragen. > > Noch Mal: Der Kippschalter für das LSB muss mindestens 2 Milliarden > Schaltspiele aushalten. Welcher Schalter macht das mit??? > > Der verarscht euch doch nur! Da gehe ich auch davon aus oder hat die Komplexitaet der Aufgabe intellektuell noch nicht durchdrungen (ich wollte mal eine eigene 8-Bit-CPU bauen: Den PC habe ich hinbekommen (16 bit), Clocking auch, aber die CPU mit Mikro-Programming war schon sehr aufwaendig.) Aber ich sollte noch mal auf https://www.homebrewcpuring.org/ hinweisen, man kann Rechner auch mit Relais bauen. Gruesse Th.
Hermann Kokoschka schrieb: > Naturlich ist das ein "sinnloses" Projekt, aber wenn es Spass macht ist > das doch völlig ok! > Ein Freund von mir hat sowas vor Jahren mal komplett aus TTL gebaut, > rund um die 74181-ALU herum, auf Lochraster! Ja die 74181 ALU ist mir durchaus bekannt, ich habe eigentlich vor zwei dieser ALUs in der CPU zu verwenden. Das Teil ist aber leider sehr schwer zu beschaffen. Und da das ja ein 74er Baustein ist wäre das OK. (Ist ja nur kombinatorische Logik, genause wie ein Komparator IC) Hermann Kokoschka schrieb: > Paar Infos des TO kollidieren aber m.E. und sind nicht ganz klar. > Da ist von VGA-Ausgabe und eventuell kleiner Textbearbeitung die Rede, > andererseits aber auch von "Hex-Schaltern" und "7-Segment-Ausgabe". > > -WENN eine VGA-Ausgabe geplant ist, WOZU dann 7-Segment-Ausgabe? > -WENN am Ende sogar kleiner Texteditor laufen soll wird eh irgendeine > (rudimentäre) Tastatur nötig sein, WOZU dann "Hex-Schalter" zur Eingabe? Ich habe nicht vor von Anfang an VGA und Tastatur (über PS2 Schnittstelle) zu unterstützen. Das Ganze ist als Langzeitprojekt gedacht das im Laufe der Zeit erweitert werden sollte und irgendwann vielleicht mal VGA ausgeben können soll. Einfach anfangen ... > Auch das "4GigaByte-Thema" deutet darauf hin, dass der TO noch kein > klares Konzept hat, mich würden aber Details interessieren, z.B. welche > Architektur, OpCode-/Befehlsbreite, etc. Ich habe nicht vor 4GB "Programmspeicher" zu haben, sondern 4 GB Datenspeicher. > Es gibt eine "ZX80/81-Nachbau-Gemeinde", die zwar einen Prozessor nutzt > (Z80/Derivate) aber immerhin auch OHNE die damalige "ULA" -also diskret- > mit 2-3Mhz eine ganz brauchbare Textausgabe @Monitor hinbekommt. > > Bei Hackaday/YT/Web finden sich zahlreiche Infos, die für den TO > vielleicht brauchbar sind. Ich weiß. Aber mit einem fertigen Prozessor zu arbeiten ist irgendwie nicht das was ich will. Der Weg ist das Ziel.
:
Bearbeitet durch User
Thomas W. schrieb: > Vielleicht ein wenig Grundlagen fuer Clock, ALU u.s.w. zu lesen (so gar > mit videos) findest Du unter https://eater.net/ > > 8-Bitter from scratch, kannst Du ja beliebig skalieren... > > Gruesse > > Th. Kenn ich, die ganzen Videos habe ich schon verschlungen.
Murmeltier schrieb: > Nein! > > Als Großrechner noch tatächlich per Hand aus diskreten Bauteilen gebaut > wurden, hatten sie einen Adressraum von einigen K-Wörtern. > Sie wurden von Mathematikern projektiert (die offensichtlich Ahnung > davon hatten, was sie taten) und waren dennoch so kompliziert zu > bedienen, dass ebenfalls nur von solchen bedient und programmiert werden > konnten. > > Hier möchte jemand einen Adressraum von 4G mit Kippschaltern adressieren > und hat offensichtlich nicht mal den Schimmer einer Ahnung, sonst würde > er nicht in einem Forum nachfragen. > > Noch Mal: Der Kippschalter für das LSB muss mindestens 2 Milliarden > Schaltspiele aushalten. Welcher Schalter macht das mit??? > > Der verarscht euch doch nur! Wie gesagt, der "manuelle Eingabe" bzw. das manuelle Überschreiben von Werten ist nur zu Test und Debugzwecken gedacht. Und ich habe nicht vor 4GB große Programme " byte nach byte von Hand einzutippen". Der Programmspeicher wird ein EEPROM sein in den ein Programm mit einem EEPROM Programmer geladen werden kann. Die 4GB hätten als "Datenspeicher" dienen sollen. Aber wahrscheinlich werden die 4GBs wohl nichts, nicht ohne "moderne technische Hilfsmittel " (µC + SD-Speicherkarte, oder so) Ich "verarsche" niemanden, ich habe mich nur nicht deutlich genug ausgedrückt. (ich wollte kein halbes Buch schreiben um meine ursprüngliche Frage zu erläutern aber trotzdem ein paar Hintergrundinfos geben und nicht nur "wie realisiere ich eine 32 bit Eingabe?")
Andre G. schrieb: > Hermann Kokoschka schrieb: > Ja die 74181 ALU ist mir durchaus bekannt, ich habe eigentlich vor zwei > dieser ALUs in der CPU zu verwenden. > Das Teil ist aber leider sehr schwer zu beschaffen. Make offer: Ich habe vier 74LS181 hier liegen (fuer die selbstbau CPU die nie fertig wurde). Th.
Murmeltier schrieb: > Es gibt den MOS6502 aus rund 4500 discreten Transistoren: > https://monster6502.com/ > Dieser adressiert aber "nur" 65536 Datenwörter. > > Hier möchte jemand diskret 4 GB RAM adressieren, ohne sich überhaupt > bewusst zu sein, was 4.294.967.296 überhaupt für eine riesige Zal ist! Ja vielleicht weil ich noch nicht viel Erfahrung mit solchen Projekten habe. Und vielleicht weil ich nur "moderne Computer und Speicher" kenne, wo 4 GB nicht gerade viel Speicher ist. Vielleicht habe ich dadurch eine etwas verzerrte Sicht wie aufwendig große Speicher wirklich sind. Vielleicht aber auch weil wenn man beim Händler seiner Wahl nach Speicher ICs sucht und die Einträge nach Speichergröße sortiert man da durchaus Speicher-ICs mit hunderten Mb oder einigen Gb findet.
Andre G. schrieb: >> Auch das "4GigaByte-Thema" deutet darauf hin, dass der TO noch kein >> klares Konzept hat, mich würden aber Details interessieren, z.B. welche >> Architektur, OpCode-/Befehlsbreite, etc. > > Ich habe nicht vor 4GB "Programmspeicher" zu haben, sondern 4 GB > Datenspeicher. Aber Du redest/schreibst von 4GB Adressraum. Dazu brauchst Du latuernich einen 32-Bit PC, mit den ueblichen LS161 brauchst Du acht Stueck um den PC darzustellen. Du musst latuernich auch adressieren koennen (so ein freundlichen LD A,(0x12345678)), also Deinen Akku irgendwie in das 1. bis 4. Bytes des 32-bit-Wortes reinfalten. Nicht unmoeglich, aber auch nicht trivial. Oder alles kleiner und dann den "Massenspeicher" ueber Port anbinden. Gruesse Th.
Thomas W. schrieb: > Andre G. schrieb: >>> Auch das "4GigaByte-Thema" deutet darauf hin, dass der TO noch kein >>> klares Konzept hat, mich würden aber Details interessieren, z.B. welche >>> Architektur, OpCode-/Befehlsbreite, etc. >> >> Ich habe nicht vor 4GB "Programmspeicher" zu haben, sondern 4 GB >> Datenspeicher. > > Aber Du redest/schreibst von 4GB Adressraum. Dazu brauchst Du latuernich > einen 32-Bit PC, mit den ueblichen LS161 brauchst Du acht Stueck um den > PC darzustellen. Du musst latuernich auch adressieren koennen (so ein > freundlichen LD A,(0x12345678)), also Deinen Akku irgendwie in das 1. > bis 4. Bytes des 32-bit-Wortes reinfalten. Du meinst das 32 bit Wort in den Akku hineinfalten, nicht "den 8 bit Akku in den 32 bit wert hineinfalten". "Hineinfalten" impliziert nämlich dass etwas großes in etwas kleiners umgewandelt wird ... Und du meinst wahrscheinlich "1. bis 8. Bit". Ja, das wird natürlich nichts mit "einer Operation pro Taktzyklus", klar. Aber ich denke ich bekomme das schon irgendwie hin.
Vorschlag zur Güte: Besorg dir aus der Bucht nen alten C64-er für 30 € oder so und tipp mal ein paar Programme als Hexcode aus der gleichnamigen Zeitschrift ab. Dann kannst du dir immer noch überlegen, ob du per Kippschalter "programmieren" möchtest.
Du hattest ja geschrubt, dass Du eine 8-Bit-CPU bauen willst. Dann musst Du natuerlich das Byte aus dem Akku (mehr hast Du nicht) irgendwo hinspeichern, so dass Du Deine 32-Bit-Adresse fuer den Speicher bekommst. Jetzt kommt alles aus dem Gedaechtnis, aber Du koenntest mal die Funktionsweise der 6502 angucken, die hatten die Pointer-Verwaltung (X und Y-Register, Zero-Page Addressing) ganz schlau geloest (zumindest 1980). Relativ gut war auch der Befehlssatz (die Orthogonalitaet war schon gut geloest). Das musst Du aber noch mal nachlesen (zulange her). Du musst Dir auch ueberlegen, was willst Du denn mit dem grossen Speicher machen: Du wirst froh sein wenn Du erstmal einen Monitor zum laufen bekommst. Viele Gruesse, viel Glueck Th.
Andre G. schrieb: > Und vielleicht weil ich nur "moderne Computer und Speicher" kenne, wo 4 > GB nicht gerade viel Speicher ist. Was ist modern? Nimm dir erst mal einen kleinen Tiny zum Vorbild. Davon hast du sicher noch nie was gehört.
Andre G. schrieb: (...) > Das "Problem" ist jedoch die Eingabe von 32 bit Werten für den > Adressbus. (...) > Wie gesagt, jeder Lösungsansatz hat seine Vor - und Nachteile, deshalb > dachte ich ich frage mal hier wie ihr das Problem lösen würdet. Ich liebe diese sog. Daumenrad-Schalter (neudeutsch: thumbwheel switch). Die gibt's nicht nur in BCD- sondern auch in Hexadezimal-Codierung. https://www.mouser.de/c/electromechanical/switches/thumbwheel-switches-pushwheel-switches/ Grüßle Volker
Moin, - den kennst Du bestimmt auch: https://fritzler-avr.de/spaceage2/index.htm Hast Du denn schon eine Plan, wie Du die Opcodes dekodieren willst, das Steuerwerk, ALU, Speicher realisieren willst? Gruesse Th.
michael_ schrieb: > Andre G. schrieb: >> Und vielleicht weil ich nur "moderne Computer und Speicher" kenne, wo 4 >> GB nicht gerade viel Speicher ist. > > Was ist modern? > > Nimm dir erst mal einen kleinen Tiny zum Vorbild. > Davon hast du sicher noch nie was gehört. Doch, ich kenne die Tinys von Atmel. Und auch die Megas. Aber was haben die hiermit zu tun? Außer dass es sich auch um "relativ" einfache Computer handelt. Ich meine mit "modernen Computern" zum Beispiel das Ding das derjenige der das hier liest gerade vor sich hat.
Stefan ⛄ F. schrieb: > Andre G. schrieb: >> Den Speicher mache ich schon aus SRAM chips, nicht aus einzelnen 8 bit >> Register ICs. > > Das ist aber gemogelt. DAs ist nicht gemogelt, das war zu Zeiten, als Computer noch aus TTL-ICs bestanden (PDP8, PDP11, Nova, HP1000) auch nicht anders. Mach Kernspeicher kam MOS, allerdings selten statisch, sondern DRAMs.
Andre G. schrieb: > Ja die 74181 ALU ist mir durchaus bekannt, ich habe eigentlich vor zwei > dieser ALUs in der CPU zu verwenden. > Das Teil ist aber leider sehr schwer zu beschaffen. Nein, die sind nicht schwer zu beschaffen, jedenfalls im Moment nicht. Habe hier gerade 10 Stück gekauft, alle getestet, sind einwandfrei: https://www.ebay.de/itm/265335531711
Murmeltier schrieb: > Vorschlag zur Güte: > Besorg dir aus der Bucht nen alten C64-er für 30 € oder so und tipp mal > ein paar Programme als Hexcode aus der gleichnamigen Zeitschrift ab. > Dann kannst du dir immer noch überlegen, ob du per Kippschalter > "programmieren" möchtest. Wie ich schon geschrieben habe, die manuelle Eingabe wird nur zu Debug-Zwecken verwendet, um zum Beispiel auf eine bestimmte Speicheradresse direkt zugreifen zu können und einen Wert dort auszulesen oder zu überschreiben.
Sinus T. schrieb: > Stefan ⛄ F. schrieb: >> Andre G. schrieb: >>> Den Speicher mache ich schon aus SRAM chips, nicht aus einzelnen 8 bit >>> Register ICs. >> >> Das ist aber gemogelt. > > DAs ist nicht gemogelt, das war zu Zeiten, als Computer noch aus TTL-ICs > bestanden (PDP8, PDP11, Nova, HP1000) auch nicht anders. Mach > Kernspeicher kam MOS, allerdings selten statisch, sondern DRAMs. Ist doch egal ob das "rein" 74er Chips sind oder auch hin und wieder mal was "neues". Es ist mein Projekt, ich kann tun und lassen was ich will, oder? ;-)
Andre G. schrieb: > Mit 32 Bit kann man 4.294.967.296 Adressen ansprechen. Andre G. schrieb: > Die maximale Taktfrequenz wird wahrscheinlich bei vielleicht maximal 100 > kHz liegen, Rechnen wir doch mal kurz: Das wären knapp 12h für den gesamten Speicher, um pro Taktzyklus eine Speicherzelle zu addressieren. Selbst wenn Deine Super Duper 8-Bit CPU die 32-Bit Adressen irgendwie in 8 Taktzyklen herbeizaubern könnte, wären das dann min. 4 Tage für einen kompletten Speicherdurchgang. Ah, ja, debuggen willst Du ja auch noch. Viel Spaß ;-) Ehrlich: Bevor Du dir Gedanken über irgendwelche Frontplatten machst, überdenke erst einmal Dein Konzept. Schau Dir vorhandene 8-Bit CPUs an und überlege warum das so gemacht wurde und nicht anders. Und gehe bitte nicht davon aus, daß die Jungs in den 70ern irgendwie doof waren. Ich befürchte, Dir fehlt es massiv an Grundlagen Andre G. schrieb: > Es ist mein Projekt, ich kann tun und lassen was ich will, oder? > ;-) Das steht Dir frei. Dann mußt Du aber damit leben, daß bei Veröffentlichung eines solchen Projekts einige hier an Deinen Geisteszustand zweifeln. Wobei ich nicht glaube, daß Du in diesem Leben damit fertig wirst (Jedenfalls nicht, wenn Dein Konzept so bleibt).
Angehängte Dateien:
-
iron_sky-1.png
230 KB
Um die ursprüngliche Frage zu beantworten: Siehe Bild. Nach den Ausführungen des Professors ist DAS ein Computer. (Nachdem er abwinkend das Smartphone des Gefangenen beiseite legte.) Mich würde sehr die geplante Anwendung interessieren, die zum einen 4GB Datenspeicher erfordert und zum anderen ein kühlschrankgroßes Gerät mit hohem Stromverbrauch akzeptiert. Ach, es ist nur um zu lernen? Das geht auch kleiner. Und man hat viel schneller bzw. überhaupt die Chance auf ein Erfolgserlebnis. Du brauchst die 4GB nur, um Daten zu speichern? Dann binde sie als Peripherie an. Ich habe einen Z80-Rechner, in dem 4MB (oder waren es 16MB? - ist auch egal) DRAM SIMM drin stecken. Das Ding ist ein Druckerpuffer aus alten Tagen. Wie Du siehst, kann man mehr als 64kB Daten an dem Ding verwalten. Wie willst Du die Programme für das Ding schreiben? Hast Du schon einen Compiler? Steht überhaupt schon der Befehlssatz und die Kernarchitektur fest? Hast Du schon mal ein 8-Bit System (Z80, 8080, 6502, 6800 oder 8051 mit externem Programm- und Datenspeicher) aufgebaut? Das solltest Du vorher schon mal gemacht haben. Gruß Jobst
Murmeltier schrieb: > Hier möchte jemand diskret 4 GB RAM adressieren, ohne sich überhaupt > bewusst zu sein, was 4.294.967.296 überhaupt für eine riesige Zal ist! Ja, früher war das eine grosse Zahl, heute bekommt Microsoft das mit seinem Windows gefüllt ohne eine einzige sinnvolle Funktion darin abzubilden. Wir erinnern uns: Windows ist das 'Betriebssystem', bei dem 2 Aufträge die man gleichzeitig startet (das kopieren eines Dateibaums an eine andere Stelle) LANGSAMER wird als wenn man beide Aufträge nacheinander ausführen lässt. Jeder Betriebssystementwickler der 60er, 70er Jahre kratzt sich dabei am Kopf.
Hermann Kokoschka schrieb: > rund um die 74181-ALU herum, auf Lochraster! Das its doch auch wieder gemogelt. Wenn man an allen komplizierten Stellen auf hoch integrierte Spezial IC's ausweicht, kann man auch gleich einen normalen Mikroprozessor verwenden. Zu meiner Zeit war der Z80 für Lehrzwecke recht beliebt. Heute würde ich aber niemanden mehr dazu drängen, heute benutzt man Mikrocontroller. Was im Innern passiert, mann man sich anhand von Animationsfilmen und Simulatoren aneignen. Da gibt es großartige Web-Seiten, die den Kristall des Chips darstellen und dort im Single-Step Modus jedes einzelne Signal farblich hervor heben.
Andre G. schrieb: > Das "Problem" ist jedoch die Eingabe von 32 bit Werten für den > Adressbus. Nein, das eigentliche Problem ist der abwegig breite Adressbus. > 32 Schalter > Nachteile: > - Einzugebende Werte müssen erst in binäre Werte umgerechnet werden Umrechnen? Gibt es noch "binärere" Werte als die Schalterstellungen 0 und 1? Wenn ich eine CPU designe, dann "denke" ich in Hex. Da muss ich zwischen 1011 und 'B' nichts umrechnen. Wenn ich das Eine sehe, sehe ich das Andere. Andre G. schrieb: > Ich dachte dabei an einen 32 bit breiten Adressbus, sodass circa 4 GB > problemlos adressiert werden können. > Derzeit beschäftige ich mich mit dem Designen der Frontplatte. > Über diese sollen Daten "von Hand" eingegeben Andre G. schrieb: > Das Ganze ist als Langzeitprojekt gedacht Das muss es auch sein, denn wenn du "von Hand" 1 Datenwort zügig in 1 Sekunde eingibst, dann wird es 133 Jahre dauern, bis du den Speicher vollgetippt hast. Aber eine CPU mit 8 Bit Registerbreite an einem 32 Bit Bus ist absolut umständlich. Da brauche ich ja schon 4 einzelne Registerzugriffe, um den Adresspointer für den Speicherzugriff vorzubereiten. Diese Überlegungen sind also völlig abwegig. Wenn ich (in meinem Fall in einem FPGA) wieder mal eine CPU baue, dann macht die genau und nur das, was ich an dieser Stelle brauche. Und sie macht das auch in ihrer eigenen "Sprache". Sie ist letztlich ein Zustandsautomat, der aus einem RAM Kommandos abholt und abarbeitet. Solche CPUs sind oft nur ein paar hundert Flipflops "groß". Wenn ich eine richtige universelle CPU mit 32-Bit-Bus will, dann kaufe ich mir eine. Ich bin ja nicht so verwegen, zu meinen, ich könnte das, was zigtausend Ingenieure in abermillionen Mannstunden vor mir hinbekommen haben, selber in meinem Bastelkeller einfach so als Bastelprojekt aufziehen. Also meine Tipp: fang mal ganz klein mit einem 4-Bit Rechner an. Dabei lernst du dann deine und die Grenzen der Technik kennen und hast die reale Chance, das Ding tatsächlich mal zum Laufen zu bekommen.
:
Bearbeitet durch Moderator
Jobst M. schrieb: > Du brauchst die 4GB nur, um Daten zu speichern? > Dann binde sie als Peripherie an. Also so ähnlich wie bei einem echten PC? Der kann ja auch nur 4 GB adressieren wenn es ein 32 bit System ist und trotzdem kann man daran 10 TB Festplatten verwenden. Ich habe einen Ansatz wie ich das machen würde: Sagen wir ich habe 8 bit zur Verfügung und möchte einen 32 bit Wert "ausgeben" (um damit einen Speicher anzusprechen). Dann schicke ich einfach einzelne Bytes and den Speicher und der setzt diese dann zu einem 32 bit großen "Wort" zusammen (ähnlich wie ein Schieberegister, da kann man auch seriell Daten reinschicken und sie parallel auslesen) Jobst M. schrieb: > Wie willst Du die Programme für das Ding schreiben? > Hast Du schon einen Compiler? > Steht überhaupt schon der Befehlssatz und die Kernarchitektur fest? Nein ich habe noch keinen Compiler dafür geschrieben. Ja, der Befehlssatz steht schon fest. (Wird aber wohl noch etwas überarbeitet werden müssen da das ganze doch wohl nur 8 bits adressieren können wird)
Lothar M. schrieb: > Andre G. schrieb: >> Ich dachte dabei an einen 32 bit breiten Adressbus, sodass circa 4 GB >> problemlos adressiert werden können. >> Derzeit beschäftige ich mich mit dem Designen der Frontplatte. >> Über diese sollen Daten "von Hand" eingegeben > Andre G. schrieb: >> Das Ganze ist als Langzeitprojekt gedacht > Das muss es auch sein, denn wenn du "von Hand" 1 Datenwort zügig in 1 > Sekunde eingibst, dann wird es 133 Jahre dauern, bis du den Speicher > vollgetippt hast. Zum hunderttausendsten mal: Der "große Speicher" wird im Normalfall nicht "von Hand" befüllt. Das händische Eingeben und Auslesen ist nur für Testzwecke gedacht. ("Ist der Wert an der Speciheradresse x wirklich y, oder habe ich da was falsch implementiert?") Lothar M. schrieb: > Wenn ich eine richtige universelle CPU mit 32-Bit-Bus will, dann kaufe > ich mir eine. Ich bin ja nicht so verwegen, zu meinen, ich könnte das, > was zigtausend Ingenieure in abermillionen Mannstunden vor mir > hinbekommen haben, selber in meinem Bastelkeller einfach so als > Bastelprojekt aufziehen zu können. Ja aber der Nachteil an "fertigen CPUs" ist dass sie meist ihre (für mich) unergründlichen Eigenarten haben. Wenn man etwas selbst macht dann weiß man genau warum das so gemacht wurde und nicht anders. Bei "fertigen" CPUs denke ich mir oft "was soll das, könnte man das nciht einfacher machen (und dafür vielleicht ein wenig weniger Performance haben)?".
Moin, - wenn Du Dir wirklich eine CPU selber bauen willst gucke wie andere das geloest haben. Das Suchwort ist "computation structures", ein kleines Buechlein ist Stephen A. Ward, Robert H. Halstead, Jr., computation structures, 1990 (vom MIT). Oder Wilhelm G. Spruth, The Design of a microprocessor, Springer, 1989 (ein bischen IBM-Lastig fuer meinen Geschmack). Oder M. Morris Mano, Computer System Architecture, Prentice Hall, 1991. Im Buch sind Problems fuer den Leser, es gibt auch ein Loesungsbuch. Und wenn Du bei https://www.homebrewcpuring.org/ anfaengst findest Du ein paar sehr schoene Perlen. Aber vielleicht reicht ein 16Bit Adressbus fuer den Anfang :-( Gruesse, Th.
Andre G. schrieb: > Der "große Speicher" wird im Normalfall nicht "von Hand" befüllt. Ok. Gehen wir also mal davon aus, dass dein Mikrocomputer mit 100 kHz getaktet wird und ein recht effizientes Programm hat das mit 20 Taktzyklen ein Byte irgendwoher holt und in den Massenspeicher schreibt. Das sind dann 5 Kilobytes pro Sekunde, oder 10 Tage für 4 GB. Das Auslesen dauert nochmal so lange. Was könnten das für Daten sein, wo das Sinn ergibt? Ich habe immer noch das Gefühl, dass du dich unbewusst in phantastischen Größenordnungen bewegst. Ich käme schließlich auch nicht auf die Idee, meinen Laptop mit 64 Terabyte RAM auszustatten.
Programmier doch erst mal einen CPU-Emulator in einer beliebigen Hochsprache, meinet wegen in LISP. Synthetisier dann mal eine CPU in VHDL. Dabei lernst du Größenordnungen mehr, als mit "Kippschaltern".
Stefan ⛄ F. schrieb: > Andre G. schrieb: >> Der "große Speicher" wird im Normalfall nicht "von Hand" befüllt. > > Ok. Gehen wir also mal davon aus, dass dein Mikrocomputer mit 100 kHz > getaktet wird und ein recht effizientes Programm hat das mit 20 > Taktzyklen ein Byte irgendwoher holt und in den Massenspeicher schreibt. > > Das sind dann 5 Kilobytes pro Sekunde, oder 10 Tage für 4 GB. Das > Auslesen dauert nochmal so lange. Was könnten das für Daten sein, wo das > Sinn ergibt? Ich habe lieber "zu viel Speicher" und brauche dann nur einen Teil davon als dass ich plötzlich merke "oh ich habe zu wenig Speicher". Ja, ich weiß dass für viele Leute genau das der Reiz an solch "primitiven" System ist: Man muss sehr kreativ und effizient sein um etwas vernünftiges damit zu realisieren. Aber das ist nicht so mein Ding ... Ich habe lieber "mehr als genug Speicher".
Stefan ⛄ F. schrieb: > Das sind dann 5 Kilobytes pro Sekunde, oder 10 Tage für 4 GB. Das > Auslesen dauert nochmal so lange. Was könnten das für Daten sein, wo das > Sinn ergibt? Aus aktuellem Anlass: Das James Webb Space Teleskop sendet seine Daten mit 40kb/s, i.e. 5 kB/s, die über das DSN empfangen werden - passt also ziemlich gut.
Murmeltier schrieb: > Synthetisier dann mal eine CPU in VHDL. > Dabei lernst du Größenordnungen mehr, als mit "Kippschaltern". Ja, ich bin unter anderem auch gerade dabei mich mit FPGAs zu beschäftigen (VHDL). Ich muss schon zugeben dass das ein wenig praktischer ist als diskrete Hardware. Da muss man nicht gleich zwanzig Leiterplatten neu verdrahten wenn man merkt dass man einen Fehler gemacht hat.
Andre G. schrieb: > Ich habe lieber "zu viel Speicher" und brauche dann nur einen Teil davon > als dass ich plötzlich merke "oh ich habe zu wenig Speicher". Ja gut, aber du übertreibst gigantisch. Hast du dir mal Gedanken gemacht, wie viel Strom das Konstrukt aufnehmen wird, wie viele Leitungen und Leitungstreiber du brauchst und wie sich das alles negativ auf die Taktfrequenz auswirkt? Massen-Daten lagerte man schon immer auf andere Geräte aus. Früher waren es Magnetbänder, dann Festplatten, heute würde ich Flash Speicher in irgendeiner gängigen Variante (z.B. als SD Karte) verwenden. Es wäre sogar realistisch denkbar, die Daten über eine serielle Verbindung auf deinem PC zu speichern oder über einen Netzwerkadapter in einer Cloud. Ich will dir den Spaß nicht versauen, aber in den letzten 15 Jahren haben hier schon viele Leute ähnliche Projekte bekommen (allerdings mit realistischer RAM Größe). Aber nur einer hat es zu einem funktionierenden Ende gebracht. Soweit ich weiß, steht das Ding jetzt in einem Museum zur Schau.
Angehängte Dateien:
-
HJS21-CPU-IO.jpg
82 KB
Andre G. schrieb: > Ja die 74181 ALU ist mir durchaus bekannt, ich habe eigentlich vor zwei > dieser ALUs in der CPU zu verwenden. > Das Teil ist aber leider sehr schwer zu beschaffen. Soso - du „hast also vor“. Implizit bedeutet das: Du hast noch nichts, überhaupt gar nichts, Nada, Null-Komma-Null! Außer vielleicht feuchte Träume von einer „fetten Schalttafel mit Blinke-Lämpchen“ dran ... Vermutlich weißt du noch nicht mal, wie weit es alleine von einer ALU zu einer CPU ist ... Mach dich mal schlau über Rechner-Architekturen (Von-Neumann vs. Harward, Super-Harward und ...). An deiner Stelle würde ich mir als nächstes Sorgen machen und Control Unit und ev. Sequencer. https://en.wikipedia.org/wiki/Control_unit, hauptsächlich aber die dort aufgeführten Links könnten dich weiter bringen. Ich vermute jedoch stark, dass du das gar nicht willst bzw. nicht den Biss dazu hast. Allgemein: Google ist dein Freund, dort jeweils die Weblinks und Fußnoten. Sorry Andre, aber so seh' ich das. Der Klaus PS: Der Bitslice 74181 ist/war auch als FLH401 im Handel. Außer diesem gibt/gab es noch sicher 20 andere Chips am Markt ... PPS: Sagt dir der "home-built computers web-ring" etwas? Vermutlich nicht <sigs> ... PPS: Ein Foto wollte ich dir nicht vorenthalten - siehe Anlage
Mir kommt gerade der bo8 in den Kopf - ich bin raus hier ... Beitrag "Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" Gruß Jobst
:
Bearbeitet durch User
Klar wenn ich ein Auto Entwickle designe ich zuerst den Tacho, der Rest kommt dann von selbst.
Rüdiger B. schrieb: > Klar wenn ich ein Auto Entwickle designe ich zuerst den Tacho, der Rest > kommt dann von selbst. Der Tacho bestimmt schließlich auch, wie schnell das Auto fahren kann (dachte ich mal, als ich etwa 5 Jahre jung war).
Andre G. schrieb: > Und vielleicht weil ich nur "moderne Computer und Speicher" > kenne, wo 4 GB nicht gerade viel Speicher ist. Der PC hat einen Adressraum von 20 Bit (= 1 MB), der PC/AT hat einen Adressraum von 24 Bit (= 16 MB). Auf einem solchen System sind 4 MB RAM schon "unendlich viel". Beides sind 16 Bit-Rechner, die mit diesen Speichermengen zumindest ansatzweise umgehen können. > Vielleicht habe ich dadurch eine etwas verzerrte Sicht wie > aufwendig große Speicher wirklich sind. Ja. Und du solltest dagegen etwas tun, statt dich in eine Idiotie zu begeben, bei der du am Ende nur gelernt hast, dass du zu dumm warst. > Vielleicht aber auch weil wenn man beim Händler seiner Wahl nach > Speicher ICs sucht und die Einträge nach Speichergröße sortiert man da > durchaus Speicher-ICs mit hunderten Mb oder einigen Gb findet. SRAM in DIP-Bauform gibt es bis 512 KB. Für einen 8 Bit-Computer reicht einer davon aus. Bleiben bei 20 Bit-Adressierung noch 512 KB Adressraum übrig. VGA (640x480x8) braucht 300 KB für den VRAM, gerundet 384 KB, ein 64 KB ROM ist immens groß und die restlichen 64 KB reichen für alle anderen Peripheriegeräte vollkommen aus. Andre G. schrieb: > Ich habe lieber "zu viel Speicher" und brauche dann nur einen Teil davon > als dass ich plötzlich merke "oh ich habe zu wenig Speicher". Also doch dumm. > Ja, ich weiß dass für viele Leute genau das der Reiz an solch > "primitiven" System ist: Man muss sehr kreativ und effizient sein um > etwas vernünftiges damit zu realisieren. > > Aber das ist nicht so mein Ding ... > > Ich habe lieber "mehr als genug Speicher". Du bist also dumm und ein Troll? Habe ich das richtig verstanden? Geh in den Laden und kauf dir einen PC. Da ist "mehr als genug Speicher" drin.
Der Klaus schrieb: > Andre G. schrieb: >> Ja die 74181 ALU ist mir durchaus bekannt, ich habe eigentlich vor zwei >> dieser ALUs in der CPU zu verwenden. >> Das Teil ist aber leider sehr schwer zu beschaffen. > > Soso - du „hast also vor“. Implizit bedeutet das: Du hast noch nichts, > überhaupt gar nichts, Nada, Null-Komma-Null! Doch, ich habe schon "etwas". Ich fange nur nicht an Bauteile zusammenzulöten wenn ich mir nicht ganz sicher bin dass ich das wirklich so machen will. Der Klaus schrieb: > Vermutlich weißt du noch nicht mal, wie weit es alleine von einer ALU zu > einer CPU ist ... Doch, ich habe schon ein wenig Ahnung. Da sind noch Intruktionsdekoder, Programmzähler, die Akkumulatoren, die ganze Kontrolllogik, ... Der Klaus schrieb: > Mach dich mal schlau über Rechner-Architekturen (Von-Neumann vs. > Harward, Super-Harward und ...). An deiner Stelle würde ich mir als > nächstes Sorgen machen und Control Unit und ev. Sequencer. Ja, das sagt mir schon etwas. Ich werde die Harvard Architektur verwenden, also getrennte Speicher für Daten und das auszuführende Programm. Der Klaus schrieb: > PS: Der Bitslice 74181 ist/war auch als FLH401 im Handel. Außer diesem > gibt/gab es noch sicher 20 andere Chips am Markt ... Danke!
> Ich werde die Harvard Architektur verwenden, > also getrennte Speicher für Daten > und das auszuführende Programm. Also 2x 4GB
S. R. schrieb: > Andre G. schrieb: >> Vielleicht aber auch weil wenn man beim Händler seiner Wahl nach >> Speicher ICs sucht und die Einträge nach Speichergröße sortiert man da >> durchaus Speicher-ICs mit hunderten Mb oder einigen Gb findet. > > SRAM in DIP-Bauform gibt es bis 512 KB. Für einen 8 Bit-Computer reicht > einer davon aus. Bleiben bei 20 Bit-Adressierung noch 512 KB Adressraum > übrig. VGA (640x480x8) braucht 300 KB für den VRAM, gerundet 384 KB, ein > 64 KB ROM ist immens groß und die restlichen 64 KB reichen für alle > anderen Peripheriegeräte vollkommen aus. Klar, in DIP Bauform gibt es nichts "großes". (Was ja irgendwie auch witzig ist, es gibt keine großen Speicher in großem Gehäuse ... ) > Andre G. schrieb: >> Ich habe lieber "zu viel Speicher" und brauche dann nur einen Teil davon >> als dass ich plötzlich merke "oh ich habe zu wenig Speicher". > > Also doch dumm. Was hat das mit Dummheit zu tun? Tut mir leid aber ich verstehe nicht was vorausschauende Planung mit Dummheit zu tun hat. Oder hast du für die Lagerung von Bauteilen nur genauso viele Kisten oder Schubladen wie du brauchst? Oder kaufst du genau die Anzahl an Bauteile die du für ein Projekt brauchst und nicht ein paar mehr falls man die in der Zukunft noch für etwas benötigt? Der Klaus schrieb: >> Ja, ich weiß dass für viele Leute genau das der Reiz an solch >> "primitiven" System ist: Man muss sehr kreativ und effizient sein um >> etwas vernünftiges damit zu realisieren. >> >> Aber das ist nicht so mein Ding ... >> >> Ich habe lieber "mehr als genug Speicher". > > Du bist also dumm und ein Troll? Habe ich das richtig verstanden? Geh > in den Laden und kauf dir einen PC. Da ist "mehr als genug Speicher" > drin. Ich verstehe nicht was meine Einstellung mit Dummheit und Trollerei zu tun hat. Kannst du mir das bitte erklären?
Erich schrieb: >> Ich werde die Harvard Architektur verwenden, >> also getrennte Speicher für Daten >> und das auszuführende Programm. > > Also 2x 4GB Nein, der Programmspeicher muss nicht groß sein. Ein paar kB sind ja schon groß für wirklich selbstgeschriebene Programme.
Andre G. schrieb: > Ich habe lieber "zu viel Speicher" und brauche dann nur einen Teil davon > als dass ich plötzlich merke "oh ich habe zu wenig Speicher". hast du dir schon mal Gedanken darüber gemacht welche Art Speicher das sein soll? Statisch scheidet wohl aus sonst brauchst du einen Schrank nur für die Speicher. Also dynamisch DRams gibts nicht mehr also SD Ram wofür du einen SD Ram Controller brauchst. Sonst ist das ein Speicher bei dem deine Daten im Nirvana landen. Es hat schon Gründe warum eine 8Bit CPU nur einen 16Bit Addressbus hat.
JWST schrieb: > Stefan ⛄ F. schrieb: >> Das sind dann 5 Kilobytes pro Sekunde, oder 10 Tage für 4 GB. Das >> Auslesen dauert nochmal so lange. Was könnten das für Daten sein, wo das >> Sinn ergibt? > > Aus aktuellem Anlass: > Das James Webb Space Teleskop sendet seine Daten mit 40kb/s, i.e. 5 > kB/s, die über das DSN empfangen werden - passt also ziemlich gut. Da geht noch mehr, bzw weniger ;-) Die Voyager Sonden senden mit 0,016 Kbit/s. Zum Thema .. Ich hatte 1975 eine 16 bit CPU mit je 2 Platinen a 8 bit, mit 74181 als ALU und 74170 oder 74189 als Register gebaut. Ram war mit 2114 1k x 4 Chips und Batterie gepuffert. Bevor du überhaupt über GB Datenspeicher nach denkst solltest du dir Gedanken über die Ablaufsteuerung machen. Habe später leider alles bis auf die Ram Karte zerlegt und die Unterlagen nicht aufgehoben. Wenn ich das Heute nochmal machen wollte würde ich das ganze erst mal mit VDHL in ein FPGA kloppen und simulieren. Für die Ein Ausgabe (Schalter , Anzeigen) würde ich einen eigenen I/O Bus spendieren. Irgendwo geistern im Internet auch VHDL Beschreibungen von TTL Bausteinen herum. Ich hatte damals kein FPGA und auch noch kein Eprom, die Steuerlogik war mit Dioden kodiert und auf Lochraster. Aber dann kam ich an einen 8080 und 1702 Eprom und dann war das Geschichte ;-) Nachtrag: etwas später hat Elektor etwas ähnliches in einer 12 Bit Version heraus gebracht, da kannst du die Unterlagen vielleicht noch finden.
Andre G. schrieb: > Ich bin verrückt, aber nicht SO verrückt > ;-) Leider bist Du total verrückt und kommst außerdem 50 Jahre zu spät! Was soll denn das bringen? Kauf Dir bitte einen C64, AtariXL, ZX81 und motz den einfach auf mit neuem Frontdesign, usw. - da hat dann wenigstens auch die jeweilige Fan-Gemeinde was von. Du versuchst aber das Rad komplett neu zu erfinden und das ist schon reichlich irre.
Stefan ⛄ F. schrieb: > Hermann Kokoschka schrieb: >> rund um die 74181-ALU herum, auf Lochraster! > Das its doch auch wieder gemogelt. Mit Verlaub, aber das ist doch Unsinn! Die TTL-ALU gehört zur Familie und darf im TTL-Retrodesign daher mit dem "gleichen Recht" genutzt werden, wie alle anderen TTL-Bausteine. Nach Deiner Argumentation könntest Du dann auch verlangen alle Gatter aus Transistoren/Dioden/Widerständen zu erstellen... Dir fehlt auch wohl etwas Vorstellung über die Lichtjahre, die zwischen ALU und Prozessor liegen.
Robert K. schrieb: > Andre G. schrieb: >> Ich bin verrückt, aber nicht SO verrückt >> ;-) > Leider bist Du total verrückt und kommst außerdem 50 Jahre zu spät! > Was soll denn das bringen? > Kauf Dir bitte einen C64, AtariXL, ZX81 und motz den einfach auf mit > neuem Frontdesign, usw. - da hat dann wenigstens auch die jeweilige > Fan-Gemeinde was von. > Du versuchst aber das Rad komplett neu zu erfinden und das ist schon > reichlich irre. Wie schon gesagt, fertige System haben meist ihre scheinbar unerklärlichen Eigenehiten. Ja ich versuche das Rad für mich selbst neu zu erfinden. Damit ich den Weg zum Endergebniss wirklich verstehe.
S. R. schrieb: > Andre G. schrieb: >> Ich dachte dabei an einen 32 bit breiten Adressbus, sodass >> circa 4 GB problemlos adressiert werden können. > > Ja nee, is klar. Denk nochmal über die Entscheidung nach, denn sie ist > schlicht blöd. Naja gehen tut das schon, ist halt eine Frage des Prozessordesigns. Der gute alte Z80 hat ja auch einen 16Bit Adressbus und warum sollte für einen 8Bit Prozessor kein 32Bit Datenbus möglich sein. Es braucht dann zur Erzeugung der Adresse mehrere Prozessortakte. Ob das dann am Ende sinnvoll ist, ist ein anderes Kapitel. Für Arbeitsspeicher ist das sicher weniger sinnvoll, bei quasi statischen Speicher kann das schon Sinn machen.
Andre G. schrieb: > Ja ich versuche das Rad für mich selbst neu zu erfinden. > Damit ich den Weg zum Endergebniss wirklich verstehe. Kann ich den runden Gegenstand noch mal sehen? Th.
Andre G. schrieb: > Tut mir leid aber ich verstehe nicht was vorausschauende > Planung mit Dummheit zu tun hat. Wozu brauchst du 4 GB Datenspeicher? Oder auch nur 128 MB Datenspeicher? Da braucht alleine der Speichertest beim Start mehrere Stunden. Jeder Speicherzugriff braucht hunderte Taktzyklen, weil selbst einfache Arrayzugriffe ewig umständlich sind. Welche Programme willst du denn haben, die auf deiner CPU mit wenigen KB Programmspeicher mehrere GB Datenspeicher durchnudeln wollen? Der ganze Ansatz ist bescheuert. (Übrigens: Echtes Harvard mag zwar cool auf dem Papier sein, ist aber real kacke zu programmieren.) > Ich verstehe nicht was meine Einstellung mit Dummheit und > Trollerei zu tun hat. > Kannst du mir das bitte erklären? "Ich möchte eine 8 Bit-CPU bauen. Aber so mit Einschränkungen und kleinen Systemen, das ist mir alles nichts. Also so groß, dass ich nie zuwenig Speicher habe." Also doch ein 250 PS-Turbodiesel in einem Papp-Kleinwagen. Egal, dass man den nicht benutzen kann, weil sonst die Karosse auseinanderfällt, hauptsache ne dicke Maschine, damit immer genug Leistung da ist.
Andre wird dann berichten wie er sich die CPU vorstellt. Und den Proof of Concept kann er hat auch mit 512kB machen (oder 128k Words, 'ne PDP kam mit weniger klar). Ich warte dann auf Schaltplaene und MicroCode. Gruesse Th.
Nachtrag: Man kann auch an einen Z80 seine 4 GB RAM anflanschen. Braucht halt Banking und ist etwas umständlicher in der Nutzung. Dafür muss die CPU dann kein Schrott-Design sein.
S. R. schrieb: > Nachtrag: Man kann auch an einen Z80 seine 4 GB RAM anflanschen. Braucht > halt Banking und ist etwas umständlicher in der Nutzung. Dafür muss die > CPU dann kein Schrott-Design sein. 4 GB als Datenspeicher: Die SD Karte ist bereits erfunden.
Gut ich denke ich muss meine "Anforderungen" überdenken. Danke für die vielen konstruktiven Antworten, ab umd zu ist es ganz gut auf den Boden der Realität zurückgeholt zu werden. Ich denke ich werde mich fürs erste auf 8 bit Datenbus und 8 bit Adressbus "beschränken" und versuchen so etwas in einem FPGA zum laufen zu bringen. Wenn das klappt, kann ich ja immer noch versuchen "mehr bits" zu realisieren oder das wirklich mit Logik ICs aufzubauen. Eins nach dem anderen ...
Andre G. schrieb: > auf 8 bit Adressbus "beschränken" Dann würde ich (wie du schon schriebst) für RAM und Programmspeicher separate Busse vorsehen. Ich würde für die Peripherie einen dritten Bus einsetzen. Dementsprechend wirst du auch separate Befehle für den Zugriff auf die drei Speicher brauchen.
Stefan ⛄ F. schrieb: > Dann würde ich (wie du schon schriebst) für RAM und Programmspeicher > separate Busse vorsehen. Ich würde für die Peripherie einen dritten Bus > einsetzen. ... damit es maximal kompliziert wird :( Gibt es hier eigentlich eine Hitliste der traurigsten Threads? Warum müssen Leute mit zuwenig Fantasie und/oder Ahnung solche Hobby-Projekte sabotieren?
:
Bearbeitet durch User
Bauform B. schrieb: > ... damit es maximal kompliziert wird Nein, damit man wenigstens 256 Bytes RAM und 256 Bytes Programmspeicher hat. Mit wesentlich weniger kommt man nicht weit.
Andre G. schrieb: > Ich denke ich werde mich fürs erste auf 8 bit Datenbus > und 8 bit Adressbus "beschränken" und versuchen so etwas > in einem FPGA zum laufen zu bringen. Textverarbeitung in 256 Bytes macht allerdings auch keinen Spaß, weder Code noch Daten noch beides. Aber gut.
Andre G. schrieb: > Derzeit beschäftige ich mich mit dem Designen der Frontplatte. > Über diese sollen Daten "von Hand" eingegeben und ausgelesen werden > ... > Ich dachte an 7 Segmentanzeigen für die Ausgabe von hexadezimalen Werten > (2 Stück für den 8-bit Datenbus und 8 Stück für den 32-bit Adressbus). > > Das "Problem" ist jedoch die Eingabe von 32 bit Werten für den > Adressbus. > > > Folgende Möglichkeiten kämen in Frage, jede hat Vorteile und Nachteile: > > 32 Schalter > =========== > Vorteile: > + Einfache Verdrahtung > Nachteile: > > > - Sehr hoher Platzbedarf > - Einzugebende Werte müssen erst in binäre Werte umgerechnet werden Sieht am besten aus, ist aber total unpraktisch wenn man schnell auf viele aufeinander folgende Adressen zugreifen möchte. > > 8 Drehschalter mit je 16 Positionen > =================================== > (z.B. > https://www.digikey.at/en/products/detail/51A22-01-1-16N/GH7686-ND/4112289?itemSeq=387241772) > > Vorteile: > + Werte können direkt hexadezimal eingegeben werden > > > Nachteile: > - Sehr hoher Platzbedarf So groß ist der Platzbedarf nicht. Ich vermute, es werden nach den vergangenen Kommentaren doch nur 4 bis 6 Adressdrehschalter werden? :-) Damit kann man sich schon mal recht zügig den Inhalt 16 aufeinander folgender Adressen anschauen. > Hexadezimales Tastenfeld > ======================== > Vorteile: > + Werte können direkt hexadezimal eingegeben werden > > > Nachteile: > - Viel zusätzliche Logik erforderlich (Tastenmatrix abfragen, Zähler der > nach jeder Eingabe inkrementiert wird, ...) Ja, vermutlich zu viel Hardwareaufwand. Man kann das Ganze später in Software beliebig flexibel nachrüsten, sobald Tastatur und VGA verfügbar sind. > Wie gesagt, jeder Lösungsansatz hat seine Vor - und Nachteile, deshalb > dachte ich ich frage mal hier wie ihr das Problem lösen würdet. Drehschalter. > Ja, ich weiß dass ein "8 bit Computer aus diskreter Logik" ein > "sinnloses" Projekt ist. Ansichtssache, Hobby soll einfach nur Spaß machen. Der Weg ist das Ziel. > Und ja, VGA geht in diskreter Hardware, man braucht nur eine handvoll > Zähler, Komparatoren, Speicher und einen DAC. Wozu es natürlich schon vorteilhaft ist, wenn die CPU jeden Punkt des Bildwiederholspeichers direkt adressieren kann. Bei 600x800 Bildpunkten in je 256 möglichen Farben sind das 360kB für eine Bildschirmseite. Außerdem sollte double buffering möglich sein. So gesehen, kann ein 20 Bit breiter Adresszähler für die CPU also durchaus sinnvoll sein! Man kann natürlich auch mit dezidierten Tiles-Speicher in Hardware arbeiten, in dem fertige Buchstaben und Grafikzeichen beispielsweise als 8x8 Pixel Blöcke abgelegt sind. Dann müßte´die CPU im einfachsten Fall nur noch knapp 8kB Grafikspeicher adressieren können. Ich würde von diesem Verfahren allerdings Abstand nehmen. Es macht die Grafikausgabe sehr unflexibel und gleichzeitig die Grafikhardware viel aufwändiger.
Andre G. schrieb: > Der Klaus schrieb: >> Andre G. schrieb: >>> Ja die 74181 ALU ist mir durchaus bekannt, ich habe eigentlich vor zwei >>> dieser ALUs in der CPU zu verwenden. >>> Das Teil ist aber leider sehr schwer zu beschaffen. >> >> Soso - du „hast also vor“. Implizit bedeutet das: Du hast noch nichts, >> überhaupt gar nichts, Nada, Null-Komma-Null! > > Doch, ich habe schon "etwas". > Ich fange nur nicht an Bauteile zusammenzulöten wenn ich mir nicht ganz > sicher bin dass ich das wirklich so machen will. Aber du willst schon mal Frontplatten bohren. Alles klar !!!
Andre G. schrieb: > Wie schon gesagt, fertige System haben meist ihre scheinbar > unerklärlichen Eigenehiten. Dir ist aber schon bewußt, daß dieser Grundsatz auch auf Dein System zutreffen wird, sofern es irgendwann mal fertig sein wird; mit dem kleinen Unterschied, daß Du bei Deinem Unikat all diese Eigenheiten selbst wirst entdecken und erforschen müssen.
admg schrieb: > Bei 600x800 Bildpunkten in je 256 möglichen Farben sind das 360kB... Ups, sogar noch mehr. Am besten auf 640x480 Bildpunkte reduzieren und alles noch mal nachrechnen, was hier so geschrieben wird...
admg schrieb: > Wozu es natürlich schon vorteilhaft ist, wenn die CPU jeden Punkt des > Bildwiederholspeichers direkt adressieren kann. > Bei 600x800 Bildpunkten in je 256 möglichen Farben sind das 360kB für > eine Bildschirmseite. Außerdem sollte double buffering möglich sein. > > So gesehen, kann ein 20 Bit breiter Adresszähler für die CPU also > durchaus sinnvoll sein! > > Man kann natürlich auch mit dezidierten Tiles-Speicher in Hardware > arbeiten, in dem fertige Buchstaben und Grafikzeichen beispielsweise als > 8x8 Pixel Blöcke abgelegt sind. Dann müßte´die CPU im einfachsten Fall > nur noch knapp 8kB Grafikspeicher adressieren können. > > Ich würde von diesem Verfahren allerdings Abstand nehmen. Es macht die > Grafikausgabe sehr unflexibel und gleichzeitig die Grafikhardware viel > aufwändiger. Ich möchte (erstmal) "nur" eine reine ASCII Ausgabe realisieren, monochrom. 80 Zeichen breit, 50 Zeichen hoch. Also ich werde 8 px breite und 12 px hohe Zeichen verwenden. Es gibt einen SRAM der speichert welche Zeichen an welcher Stelle ausgegeben werden sollen. Dieser kann vom Prozessor beschrieben werden. Diser "Zeichenspeicher" wird dann periodisch abgefragt und "dekodiert". In 12 Stück EEPROMs sind die bits für die einzelnen Zeichen gespeichert. Dieser "Zeichendekoder" hat einen 8 bit Eingang für das ASCII Zeichen das dargestellt werden soll. Und einen Eingang der dem Dekoder sagt welches pixel des Zeichens dargestellt werden sollte. Der Bildschirm zeichnet ja pixel für pixel in jeder Zeile, also wenn ich zum Beispiel an der Position 0|0 (links oben) ein "A" ausgeben will muss ich in der ersten pixel-Zeile 00000000 und in der zweiten pixel-Zeile 00011000, in der dritten Zeile 00111100 und so weiter ausgeben. Also jede "Zeile" im Zeichenspeicher wird 12 mal durchgelaufen. Zwischen jedem darzustellenden Zeichen ist ein Pixel abstand, zweischen den Zeilen ebenfalls ein Pixel Abstand. Rund um den Teil auf dem Bildschirm in dem die Zeichen dargestellt werden wird noch ein mindestens 10 pixel breiter Rahmen sein. Das bedeutet dass ich mindestens 1024 x 768 pixel Auflösung benötige, also eigentlich XGA und nicht VGA. Das ganze VGA Zeug wird mit einem eigenen Oszillator betaktet, unabhängig vom Takt des Prozessors. Der Prozessor muss dann eben "warten" bis er von der VGA-Schaltung die Erlaubniss bekommt in den Zeichenspeicher zu schreiben. Ja, mit der Planung dem VGA-Ausgabeteils habe ich mich in letzter Zeit intensiv beschäftigt ...
Andre G. schrieb: > Das bedeutet dass ich mindestens 1024 x 768 pixel Auflösung benötige, > also eigentlich XGA und nicht VGA. > > Das ganze VGA Zeug wird mit einem eigenen Oszillator betaktet, > unabhängig vom Takt des Prozessors. > Der Prozessor muss dann eben "warten" bis er von der VGA-Schaltung die > Erlaubniss bekommt in den Zeichenspeicher zu schreiben. > Und du bist dir sicher das deine TLL 74181 CPU das Zeitfenster für Daten aus dem Ram zu holen und in den Video Speicher zu schreiben schaft ?. Von welchen Zeiten träumst du für einen MOV RAM -> RAM-Video Befehl über die CPU. Da bist du schnell bei DMA. Dein CPU takt bleibt gut unter 1Mhz. Aber der CPU Takt ist ja nicht identisch mit einem Befehl. Das ist der Takt mit dem dein Steuerbus läuft (Microprogramm state machine).
Hans-Georg L. schrieb: >> Der Prozessor muss dann eben "warten" bis er von der VGA-Schaltung die >> Erlaubniss bekommt in den Zeichenspeicher zu schreiben. >> > > Und du bist dir sicher das deine TLL 74181 CPU das Zeitfenster für Daten > aus dem Ram zu holen und in den Video Speicher zu schreiben schaft ?. Dagegen gibt es FIFOs, 2 Stück 74HC(T)40105 speichern 16 Byte.
Andre G. schrieb: > 80 Zeichen breit, 50 Zeichen hoch. Oh.. > Also ich werde 8 px breite und 12 px hohe Zeichen verwenden. Ohoh... > Das bedeutet dass ich mindestens 1024 x 768 pixel Auflösung benötige, > also eigentlich XGA und nicht VGA. Ohohoh... Das sind ja alles gut rund Zahlen... > Ja, mit der Planung dem VGA-Ausgabeteils habe ich mich in letzter Zeit > intensiv beschäftigt ... Na dann liegt es ja nahe, bei dieser Baugruppe mit dem Aufbau zu beginnen. Vor einiger Zeit hat hier schon einmal jemand eine VGA-Grafik auf Steckbrett realisiert... realisieren wollen. War auch sehr interessant, gab aber auch einige Probleme. Keine Ahnung ob und wie gut das am Ende lief. Ich wünsch viel Erfolg!
Also ich finde eine Grafikkarte ohne Beschleunigung langweilig, viel zu wenig Herausforderung.
Bauform B. schrieb: > Hans-Georg L. schrieb: >>> Der Prozessor muss dann eben "warten" bis er von der VGA-Schaltung die >>> Erlaubniss bekommt in den Zeichenspeicher zu schreiben. >>> >> >> Und du bist dir sicher das deine TLL 74181 CPU das Zeitfenster für Daten >> aus dem Ram zu holen und in den Video Speicher zu schreiben schaft ?. > > Dagegen gibt es FIFOs, 2 Stück 74HC(T)40105 speichern 16 Byte. Und woher weiß die VGA Logik welches Zeichen im Fifo an welche Adresse geschrieben wird. Da wird ein Daten Fifo nicht reichen.
admg schrieb: > Andre G. schrieb: > >> 80 Zeichen breit, 50 Zeichen hoch. > Oh.. >> Also ich werde 8 px breite und 12 px hohe Zeichen verwenden. > Ohoh... >> Das bedeutet dass ich mindestens 1024 x 768 pixel Auflösung benötige, >> also eigentlich XGA und nicht VGA. > Ohohoh... > Das sind ja alles gut rund Zahlen... > >> Ja, mit der Planung dem VGA-Ausgabeteils habe ich mich in letzter Zeit >> intensiv beschäftigt ... > > Na dann liegt es ja nahe, bei dieser Baugruppe mit dem Aufbau zu > beginnen. Genau. Normalerweise fängt man so etwas ja mit der ALU oder dem PC an, aber da ein solches "VGA Ausgabe Modul" auch für andere Projekte brauchbar sein könnte denke ich ich fange wirklich konkret damit an. Denn egal ob der Adressbus 8 oder 16 oder 32 oder hunderttausend bits hat, die Eingabe und Ausgabe von Daten ist eigentlich immer gleich. (VGA, Tastatur über PS2 oder RS232, ...)
admg schrieb: > Vor einiger Zeit hat hier schon einmal jemand eine VGA-Grafik auf > Steckbrett realisiert... realisieren wollen. Gefunden. Hier der finale Aufbau, wie es scheint: Beitrag "Re: Bauen oder nicht bauen ?" Immerhin kamen da schon mal Bilder raus. Verfolgt allerdings ein etwas aufwändigeres Konzept. Scrollen und Farbe sind ja hier nicht gefordert.
admg schrieb: > Vor einiger Zeit hat hier schon einmal jemand eine VGA-Grafik auf > Steckbrett realisiert... realisieren wollen. > War auch sehr interessant, gab aber auch einige Probleme. Keine Ahnung > ob und wie gut das am Ende lief. > Ich wünsch viel Erfolg! Könnte evtl mit Video-Rams, die es mal gab funktionieren. Das sind DRAMS mit eingebautem Schieberegister die ein ganze Bildschirmzeile parallel mit einem Takt übernehmen und dann seriell an den Bildschirm ausgeben. Da kann der VGA-Controller fast die ganze Zeit auf das DRAM zugreifen ohne die Ausgabe zu stören.
admg schrieb: > admg schrieb: > >> Vor einiger Zeit hat hier schon einmal jemand eine VGA-Grafik auf >> Steckbrett realisiert... realisieren wollen. > > Gefunden. Hier der finale Aufbau, wie es scheint: > Beitrag "Re: Bauen oder nicht bauen ?" > > Immerhin kamen da schon mal Bilder raus. > Verfolgt allerdings ein etwas aufwändigeres Konzept. Scrollen und Farbe > sind ja hier nicht gefordert. Da sind aber 2 40 pinner drin und der TO will das ja alles in TTL machen ... bin mal gespannt ;-)
Hans-Georg L. schrieb: > admg schrieb: >> admg schrieb: >> >>> Vor einiger Zeit hat hier schon einmal jemand eine VGA-Grafik auf >>> Steckbrett realisiert... realisieren wollen. >> >> Gefunden. Hier der finale Aufbau, wie es scheint: >> Beitrag "Re: Bauen oder nicht bauen ?" >> >> Immerhin kamen da schon mal Bilder raus. >> Verfolgt allerdings ein etwas aufwändigeres Konzept. Scrollen und Farbe >> sind ja hier nicht gefordert. > > Da sind aber 2 40 pinner drin und der TO will das ja alles in TTL machen > ... > bin mal gespannt ;-) Nicht nur ausschließlich "74er" Chips; SRAMs, EEPROMs und ähnliches ist auch "erlaubt". Wie schon gesagt, das ist kein "Reinheitsprojekt" das NUR 74er TTL oder NUR 74er CMOS verwendet. Nur eben keine "hochintegrierten" ICs, also keine speziellen Video-ICs (für VGA) oder fertige Prozessoren (die 181 ALU geht, sind ja nur eine Hand voll einfacher Logikgatter). Nein, ich habe keine klare Definition was "hochintegriert" genau heißt. (kein "oh nein, diesen IC darf ich nicht verwendet, der hat mehr als 20 Transistoren")
Andre G. schrieb: > Mit "diskret" meinte ich "aus Logik-ICs", nicht wirklich komplett > diskret aus Transistoren. > Das hätte ich vielleicht erwähnen sollen ... > > Ich bin verrückt, aber nicht SO verrückt Einfacher ist vielleicht einen alten "diskreten" Rechner zu kaufen, z.B. einen alten Siemens Prozeßrechner oder eine dec pdp.
Andre G. schrieb: > Ich möchte (erstmal) "nur" eine reine ASCII Ausgabe realisieren, > monochrom. 80 Zeichen breit, 50 Zeichen hoch. Direkt auf Grafik zu gehen ist einfacher. > Rund um den Teil auf dem Bildschirm in dem die Zeichen dargestellt > werden wird noch ein mindestens 10 pixel breiter Rahmen sein. Warum das? > Das bedeutet dass ich mindestens 1024 x 768 pixel Auflösung benötige, > also eigentlich XGA und nicht VGA. Klug wären 640x400 bei 8 Bit Farbtiefe, sind exakt 250 KB und kompatibel mit allem. Auch klug wären 640x480, aber das ist dann ekliges Zusatzbit. Höhere Auflösungen gehen auch, sind aber eher sinnlos. Du kannst ja mal kurz über die Bandbreite grübeln, die du brauchst, um das zu befüllen.
Hallo Andre, bevor Du einen Prozessor selbst baust, empfehle ich Dir, das Buch http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/pdp8i/Prosser_The_Art_of_Digital_Design_2ed_1987.pdf zu lesen. In dem Buch wird neben dem Entwurf digitaler synchroner Logik der Bau einer PDP-8 erklärt, das ist ein 50 Jahre alter 12-Bit Rechner. Für den Bau braucht man ungefähr 130 TTL-ICs. Der Entwurf einer Frontplattedafür, wird dafür auch beschrieben.
Alexander D. schrieb: > Hallo Andre, bevor Du einen Prozessor selbst baust, empfehle ich Dir, > das Buch > http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/pdp8i/Prosser_The_Art_of_Digital_Design_2ed_1987.pdf > zu lesen. In dem Buch wird neben dem Entwurf digitaler synchroner Logik > der Bau einer PDP-8 erklärt, das ist ein 50 Jahre alter 12-Bit Rechner. > Für den Bau braucht man ungefähr 130 TTL-ICs. Der Entwurf einer > Frontplattedafür, wird dafür auch beschrieben. Danke für den Link, ich werde mir das mal ansehen.
S. R. schrieb: > Andre G. schrieb: >> Ich möchte (erstmal) "nur" eine reine ASCII Ausgabe realisieren, >> monochrom. 80 Zeichen breit, 50 Zeichen hoch. > > Direkt auf Grafik zu gehen ist einfacher. Ja, hardwaremäßig schon. Aber der Prozessor muss dann die ganze "Zeichendarstellung" übernehmen. So wie ich vorhabe das zu implementieren kann der Prozessor einfach das darzustellende Zeichen und dessen Position an die "Grafikkarte" übergeben und muss sich um nichts weiter kümmern. >> Rund um den Teil auf dem Bildschirm in dem die Zeichen dargestellt >> werden wird noch ein mindestens 10 pixel breiter Rahmen sein. > > Warum das? Damit der dargestellte Text nich direkt am Bildschirmrand "klebt". Wenn du ein Blatt Papier beschreibts dann lässt du auch einen "Rand" frei, oder?
Alexander D. schrieb: > http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/pdp8i/Prosser_The_Art_of_Digital_Design_2ed_1987.pdf > zu lesen. In dem Buch wird neben dem Entwurf digitaler synchroner Logik > der Bau einer PDP-8 erklärt, das ist ein 50 Jahre alter 12-Bit Rechner. Und auf p.480 findet man den Timer 555 Th.
Andre G. schrieb: > Aber der Prozessor muss dann die ganze "Zeichendarstellung" übernehmen. Ja. Und in deinem eigenen Interesse solltest du die Hardware möglichst einfach gestalten. Eine neue Grafikkarte anflanschen kannst du später immernoch. > Damit der dargestellte Text nich direkt am Bildschirmrand "klebt". > > Wenn du ein Blatt Papier beschreibts dann lässt du auch einen "Rand" > frei, oder? Ich merke schon, du kennst dich mit Computern und Terminals nicht aus. Lassen wir das, ich bin dann auch raus. Viel Erfolg bei deinem Vorhaben. Ich warte auf Bilder.
S. R. schrieb: > Andre G. schrieb: >> Aber der Prozessor muss dann die ganze "Zeichendarstellung" übernehmen. > > Ja. Und in deinem eigenen Interesse solltest du die Hardware möglichst > einfach gestalten. Eine neue Grafikkarte anflanschen kannst du später > immernoch. > >> Damit der dargestellte Text nich direkt am Bildschirmrand "klebt". >> >> Wenn du ein Blatt Papier beschreibts dann lässt du auch einen "Rand" >> frei, oder? > > Ich merke schon, du kennst dich mit Computern und Terminals nicht aus. Mit "alten Computern" und mit Terminals generell kenne ich mich nicht aus, nein. Aber so ziemlich jeder (moderne) Computer nutzt die gesamte Fläche des Bildschirms. Und wenn ich wirklich nur Text darstellen will, dann ist ein wenig Platz am Rand doch ganz gut. Sonst kann man nur schlecht zwischen einem "L" und einem "_" unterscheiden.
Ich empfehle einen Teil des Videospeichers über Hardwarelogik zur Bilderzeugung zu nutzen. Dann wird immer genau das dargestellt, was in diesem Bereich im Speicher steht, ohne die CPU zu belasten. Ein kurzer Blick in die Apple II Hardware zeigt, wie das gehen kann und kommt mit erstaunlich wenig Hardware aus!
Andre G. schrieb: > Mit "alten Computern" und mit Terminals generell kenne ich mich nicht > aus, nein. Das solltest du dich aber reinlesen, die haben die Probleme nämlich alle gelöst, die du noch gar nicht kennst. Andre G. schrieb: > Und wenn ich wirklich nur Text darstellen will, dann ist ein wenig Platz > am Rand doch ganz gut. Du versuchst Probleme zu lösen, die du nie erreichen wirst, wenn du nicht ganz einfach anfängst.
Andre G. schrieb: > Ich denke ich werde mich fürs erste auf 8 bit Datenbus und 8 bit > Adressbus "beschränken" und versuchen so etwas in einem FPGA zum laufen > zu bringen. > > Wenn das klappt, kann ich ja immer noch versuchen "mehr bits" zu > realisieren oder das wirklich mit Logik ICs aufzubauen. Welch eine Erleuchtung! Abewr nicht mal das wirst duschaffen. Wetten? Andre G. schrieb: > michael_ schrieb: >> Andre G. schrieb: >>> Und vielleicht weil ich nur "moderne Computer und Speicher" kenne, wo 4 >>> GB nicht gerade viel Speicher ist. >> >> Was ist modern? >> >> Nimm dir erst mal einen kleinen Tiny zum Vorbild. >> Davon hast du sicher noch nie was gehört. > > Doch, ich kenne die Tinys von Atmel. > Und auch die Megas. > Aber was haben die hiermit zu tun? > Außer dass es sich auch um "relativ" einfache Computer handelt. > > Ich meine mit "modernen Computern" zum Beispiel das Ding das derjenige > der das hier liest gerade vor sich hat. Du solltest dich ja nur an der Größe des Daten- und Programmspeichers orientieren. Mehr nicht. Ist aber sowieso alles nur Spinne.
Andre G. schrieb: > Wenn das klappt, kann ich ja immer noch versuchen > "mehr bits" zu realisieren Dazu musst du deinen Befehlssatz in wesentlichen teilen neu gestalten und damit auch die entsprechende Logik. Ich würde lieber 16 Bit Adressen vorsehen, auch wenn du am Anfang nur einen Teil davon benutzt. michael_ schrieb: > Nimm dir erst mal einen kleinen Tiny zum Vorbild. Andre G. schrieb: > Aber was haben die hiermit zu tun? Das sind derzeit so ziemlich die kleinsten Mikrocontroller, die es gibt. Sie haben einen 16 Bit Address Bus, sicher nicht ohne guten Grund. Wie gesagt würde ich das von Anfang an im Befehlssatz vorsehen, auch wenn davon letztendlich nur ein Teil tatsächlich beschaltet wird. Ein großer Address-Raum gibt dir die Möglichkeit, RAM und ROM mit den gleichen Befehlen ohne Extrawürste zu adressieren. Und du hast reichlich Platz für vorzeigbare Programme. Dazu passen diese Klassiker sehr gut: 32 kB RAM 62256 https://cdn-reichelt.de/documents/datenblatt/A300/62256-80.pdf 32 kB EEPROM 28C256 https://www.reichelt.de/eeprom-256-kb-32-k-x-8-5-v-150ns-pdip-28-28c256-150-p1945.html
Gib ihm doch bis Freitag. Jetzt ist erstmal Arbeitswoche.
Wolfgang R. schrieb: > Kommt noch was? Nein, ich werde meine "Vorgaben" für dieses Projekt überdenken und etwas realistischer gestalten. Danke für alle Antworten!
Andre G. schrieb: > Nein, ich werde meine "Vorgaben" für dieses Projekt überdenken und etwas > realistischer gestalten. realistisch gestalten heißt in deinem Fall überhaut nicht gestalten. Deine Texte zeigen eine heillose Überschätzung deiner Möglichkeiten. Ich schließe mich der Meinung einiger Schreiber hier an, dass du ein Troll bist - dazu noch ein Anfänger. Um in den heiligen Grahl der Trolle zu kommen, da musst du noch ein wenig üben :-)
Con Man Hunter schrieb: > Andre G. schrieb: >> Nein, ich werde meine "Vorgaben" für dieses Projekt überdenken und etwas >> realistischer gestalten. > > realistisch gestalten heißt in deinem Fall überhaut nicht gestalten. > > Deine Texte zeigen eine heillose Überschätzung deiner Möglichkeiten. Ich > schließe mich der Meinung einiger Schreiber hier an, dass du ein Troll > bist - dazu noch ein Anfänger. Um in den heiligen Grahl der Trolle zu > kommen, da musst du noch ein wenig üben :-) Nein, wenn ich ein Troll wäre dann würde ich diese Diskussion nur zur Provokation oder aus Spaß veranstalten. Aber ich wollte schon seit ich damals in der Schule von digitaler Logik gelernt habe so ein Projekt realisieren. Das ist einfach etwas das mich sehr reizt. Ja, ich bin ein (ewiger) Anfänger und nicht wirklich gut darin die Machbarkeit eines Projekts einzuschätzen aber deswegen bin ich noch lange kein Troll. Auch wenn es vielleicht so aussieht. (-> mangelnde Kompetenz, unrealistische Zielsetzungen, will die Dinge auf meine Art machen, ...)
Andre G. schrieb: > Auch wenn es vielleicht so aussieht. (-> mangelnde Kompetenz, > unrealistische Zielsetzungen, will die Dinge auf meine Art machen, ...) Danke für deine offene Rückmeldung! In diesem Thread hast du trotz vieler Anfeindungen auch viele realistisch umsetzbare Hinweise für ein einfaches diskretes CPU-System bekommen - das solltest du mal angehen und dann hier berichten.
Ich hatte auch mal überlegt, einen eigenen 8-Bitter in nem CPLD zu entwickeln. Als Adreßraum hatte ich 8kB angedacht. Ich hab dann aber schnell die Lust verloren, da mir Assembler zu mühselig geworden ist. Und einen C-Compiler selber zu schreiben, traue ich mir nicht zu. Auch hatte ich bei anderen Projekten gemerkt, daß CPLDs/FPGAs schnell abgekündigt werden, d.h. für langfristige Projekte wenig geeignet sind. Es gab da viel Ärger mit mehrfachem Redesign der betroffenen Platinen.
Peter D. schrieb: > Ich hatte auch mal überlegt, einen eigenen 8-Bitter in nem CPLD zu > entwickeln. Als Adreßraum hatte ich 8kB angedacht. > Ich hab dann aber schnell die Lust verloren, da mir Assembler zu > mühselig geworden ist. Und einen C-Compiler selber zu schreiben, traue > ich mir nicht zu. > Auch hatte ich bei anderen Projekten gemerkt, daß CPLDs/FPGAs schnell > abgekündigt werden, d.h. für langfristige Projekte wenig geeignet sind. > Es gab da viel Ärger mit mehrfachem Redesign der betroffenen Platinen. Ist ein CPLD nicht ein wenig zu klein für so etwas?
Andre G. schrieb: > Ist ein CPLD nicht ein wenig zu klein für so etwas? Ich hatte mir damals 5 Stück PZ5128 im PLCC-84 besorgt, das sollte reichen. Für die CPU-Register hatte ich SRAM vorgesehen. Allerdings hat Philips die recht schnell eingestellt und an Xilinx abgestoßen. Die XCR3128 waren deutlich weniger flexibel und deren Fitter war zu Anfang grottenschlecht.
von Alexander D. (abadu) 16.01.2022 18:23 >>der Bau einer PDP-8 erklärt ursprünglich diskret: http://www.pdp8online.com/straight8/pdp8.shtml --- http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/2015/02/27-PDP8demoLights1.JPG
Peter D. schrieb: > Ich hatte auch mal überlegt, einen eigenen 8-Bitter in nem CPLD zu > entwickeln. Als Adreßraum hatte ich 8kB angedacht. > Ich hab dann aber schnell die Lust verloren, da mir Assembler zu > mühselig geworden ist. Und einen C-Compiler selber zu schreiben, traue > ich mir nicht zu. Ich könnte ein Small-C beisteuern, Codegenerator käme dann von Dir. Den Ansatz, CC und uC parallel zu entwicklen, ist nicht auf meinem Mist gewachsen. So hatte das damals (tm) Atmel bei der Vorstellung der AVR-Architektur der Entwicklergemeinde verkauft.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.