Josef G. schrieb: > Vielleicht könnte man bei der VGA-Schnittstelle die > Widerstände in den Farbsignal-Leitungen größer wählen > als von mir vorgeschlagen. Das Bild wäre dann dunkler. Wie wäre es mit HDMI und 8 Bit pro Farbe? > Ein Problem ist, dass man eine PS/2-Tastatur braucht, > die mit 3.3-V Versorgungs-Spannung auskommt. Wenn > man die Tastatur mit 5-V versorgt, müsste man noch > die Eingangs-Signalpegel auf 3.3-V begrenzen. Da sollten vier Widerstände ausreichen. Aber zukunftssicher wäre eher eine USB-Schnittstelle. Wie lange brauchst Du schäzungsweise, bis der USB-Treiber in bo8-Assembler läuft?
Bernd schrieb: > Wie wäre es mit HDMI und 8 Bit pro Farbe? > ... > Wie lange brauchst Du schäzungsweise, > bis der USB-Treiber in bo8-Assembler läuft? Ist mir durchaus bewusst, dass das nicht machbar ist.
Josef G. schrieb: > Bernd schrieb: > Wie wäre es mit HDMI und 8 Bit pro Farbe? > ... > Wie lange brauchst Du schäzungsweise, > bis der USB-Treiber in bo8-Assembler läuft? > > Ist mir durchaus bewusst, dass das nicht machbar ist. Besser noch Dir wär bewusst, daß mit Deinem Teil überhaupt *nichts sinnvolles* machbar ist weil es in jedem Fall billigeren und kleineren und leistungsfähigeren und komfortableren Ersatz gibt. Immerhin taugt Dein Projekt als Endlos- Diskussions-Vehikel, aber nur weil dabei zwangsweise ganz andere Dinge in den Fokus der Leute geraten. Schon bemerkt?
Maik schrieb: > Besser noch Dir wär bewusst, daß mit Deinem Teil überhaupt *nichts > sinnvolles* machbar ist weil es in jedem Fall billigeren und kleineren > und leistungsfähigeren und komfortableren Ersatz gibt. Vielleicht ist es gut etwas zu haben wo kein Patent drauf ist ...
Sepp schrieb: > Vielleicht ist es gut etwas zu haben wo kein Patent drauf ist ... Und jeden Morgen steht einer auf, der sich den Code noch nicht angeschaut hat...
Bernd schrieb: > Sepp schrieb: >> Vielleicht ist es gut etwas zu haben wo kein Patent drauf ist ... > Und jeden Morgen steht einer auf, der sich den Code noch nicht > angeschaut hat... und einer, der unnötig meckert und negativ kommentiert. Brauchen wir das ?
Edi M. schrieb: > und einer, der unnötig meckert und negativ kommentiert. Unnötig? Gehts hier um konstruktive Rückmeldung oder realitätsferne Lobhudelei? Oder gehts gar nur um pure Selbstdarstellung von jemandem, der sein Projekt permanent im Blick sehen möchte? > Brauchen wir das? Wir nicht. Aber Josef. Und ich fürchte es war immer noch nicht genug.
Viele Studenten haben mit dem bo8 bereits erfolgreich experimentiert und sicherlich auch einige Forumsteilnehmer. Das sich (in diesem Thread) wenige zu Wort melden hat nichts zu bedeuten. Ist eben leider wie bei den negativen Amazon Bewertungen. Für Wissbegierige ist der bo8 wie ein 6000er für den Bergsteiger.
Nicht W. schrieb: > Für Wissbegierige ist der bo8 wie ein 6000er für den Bergsteiger. Vielleicht schreibt ja mal jemand eine verbesserte Dokumentation.
Josef G. schrieb: > Nicht W. schrieb: >> Für Wissbegierige ist der bo8 wie ein 6000er für den Bergsteiger. > > Vielleicht schreibt ja mal jemand eine verbesserte Dokumentation. Prima wäre hierzu eine Dokumentation in Latex bei vorgegebener Kapitelstruktur, in der jeder der möchte mitwirken kann.
Josef G. schrieb: > Vielleicht schreibt ja mal jemand eine verbesserte Dokumentation. Du kannst ja ein Wiki aufsetzen...
Nicht W. schrieb: > Dokumentation in Latex S. R. schrieb: > Du kannst ja ein Wiki aufsetzen... Latex, Wiki, ... Das sind alles Dinge, von denen ich nichts verstehe. Das kann gerne jemand machen, durch die CC-Lizenz habe ich alles mehr oder weniger freigegeben. Es braucht auch niemand denken, es wäre mir nicht recht, wenn jemand das macht. Im Gegenteil. Wenn sich nun tatsächlich abzeichnen sollte, dass Interesse am bo8/bo8h-Projekt besteht, würde ich vor allem noch versuchen, von der Software der Hauptplatine einen Assembler-Quelltext zu erstellen, den habe ich bisher nur handschriftlich. Ich habe vor längerer Zeit mal damit angefangen, die Software mit dem Disassembler zu disassemblieren, das Ergebnis händisch nachzubearbeiten und mit dem Assembler wieder zu assemblieren. Es kam tatsächlich wieder der ursprüngliche Code heraus. Das für die gesamte Software der Hauptplatine zu machen, wäre noch viel Arbeit, und ich würde das nur tun, wenn tatsächlich Interesse daran besteht. Aber vielleicht habe ich ja was missverstanden, und das Interesse beschränkt sich nur auf die CPU allein.
Josef G. schrieb: > Wenn sich nun tatsächlich abzeichnen sollte, dass Interesse am > bo8/bo8h-Projekt besteht, Bei solchen Beobachtungen kann man sich wirklich nur noch an den Kopf fassen. Aber das ist einfach der Stoff der den Thread am Leben hält. Ab und zu noch jemand der Mut macht und die Motivation reicht wieder für die nächsten Hundert Beiträge :)
Josef G. schrieb: > Das sind alles Dinge, von denen ich nichts verstehe. Du scheinst da ja eine echte Inselbegabung zu haben. Anscheinend verstehst du vom bo8 alles, aber von allem anderen nichts. Wie findest du dich nur im Leben zurecht?
Josef G. schrieb: > Wenn sich nun tatsächlich abzeichnen sollte, dass Interesse am > bo8/bo8h-Projekt besteht, würde ich vor allem noch versuchen, > von der Software der Hauptplatine einen Assembler-Quelltext > zu erstellen, den habe ich bisher nur handschriftlich. Das gehört eigentlich dazu, aber da ich - zugegeben - da nicht weiter reingeschaut habe... Josef G. schrieb: > Ich habe vor längerer Zeit mal damit angefangen, die Software > mit dem Disassembler zu disassemblieren, das Ergebnis händisch > nachzubearbeiten und mit dem Assembler wieder zu assemblieren. > Es kam tatsächlich wieder der ursprüngliche Code heraus. Das hätte ich von einem Disassembler/Assembler eigentlich auch ohne händische Nachbearbeitung erwartet... Josef G. schrieb: > Aber vielleicht habe ich ja was missverstanden, und > das Interesse beschränkt sich nur auf die CPU allein. Sagen wir mal so... Dein Steckkartenkonzept ist nichts neues. Sowas wird seit Jahrzehnten gemacht und ist inzwischen auch von der Grundidee vollständig veraltet. Es gibt keinen Grund, sowas von Grund auf neu hochzuziehen. Dein Ansatz unterscheidet sich grundsätzlich nicht von vorhandenen Systemen, ist aber inkompatibel zu allem, was es gibt oder je gab. Das heißt "viel Arbeit" für "kein Nutzen". Ich habe sowas mit einem Z80 gemacht und festgestellt, dass außer mir nie jemand Steckkarten bauen wird. Und da ich das auch nie tun werde, wird es nie Steckkarten geben. Als Konsequenz habe ich ISA-Slots angebaut, denn damit kann ich vorhandene Hardware benutzen. Daher mein Vorschlag: Mach dein Bussystem zu irgendwas kompatibel. Sinnvoll wäre ISA, meinetwegen auch S100 oder PCI. Damit reduzierst du viel nutzlosen Aufwand. Im Gegensatz zum Restsystem ist deine CPU tatsächlich etwas besonderes. Sie ist zu nichts kompatibel, macht alles anders, ist schwer zu verstehen und noch viel schwerer zu programmieren, unverständlich dokumentiert - also eigentlich ein großer brauner Haufen. Aber sie ist neu, und das zeichnet sie aus. Es wäre an dir, die Grundlagen zu schaffen, dass man damit was sinnvolles machen kann. Es ist dein Projekt, es ist deine Aufgabe, zu liefern. Niemand wird sich ohne Gegenleistung viele Wochen in ein System einarbeiten. Ob die Gegenleistung nun ein paar Uni-Punkte sind (wie der genannte Spartan6-Port) oder ein System, mit dem man was tun will, oder auch nur die Freude am Lernen, ist egal. Es muss aber für irgendwas ansprechend sein, und das ist es bisher nicht. Ich habe bisher nicht das Gefühl, dass du aktuell am Projekt weiterarbeitest oder auch nur ein Interesse dafür zeigst. Wenn du als Projekteigentümer den Code veröffentlichst und dann das Projekt verlässt, dann ist das Projekt effektiv tot. Du hast keine Kunden, die ein Interesse haben, das Projekt auf eigene Kosten zu betreiben. Es ist deine Spielwiese, und du bist bisher nicht besonders erfolgreich darin, es irgendwie schmackhaft zu machen. Auch nicht für deine Wunschzielgruppe.
Ich frage mich, was die Motivation jener Leute ist, die nun sogar den User Nicht W. negativ bewerten. Da müssen einige Leute ja wirklich große Angst haben, dass aus dem Projekt doch noch etwas werden könnte.
S. R. schrieb: > Ich habe sowas mit einem Z80 gemacht Wie groß war der Adressraum für die Karten-Software?
Im Grunde versündigt sich jeder an Josefs Lebenszeit die er weiter in diesem nutzlosen Projekt versenken wird wenn er sich positiv darin bestärkt sieht. Das endlich zu beerdigen ist schwer genug, gerade bei soviel Herzblut, Zeit und Einsatz die da drin stecken. Wer hier tatsächlich Positives bewirken möchte ebnet besser den Weg zu etwas Sinnvollem!
S. R. schrieb: > Das hätte ich von einem Disassembler/Assembler eigentlich > auch ohne händische Nachbearbeitung erwartet... Der Disassembler gibt immer Absolut-Adressen aus. Der Assembler erwartet an manchen Stellen Labels oder Relativ-Werte aus 1 oder 2 Byte. Der einfachste händische Eingriff ist, die Absolut-Adressen durch einen vorangestellten Buchstaben in ein Label zu ver- wandeln und dieses auch an die Zielzeile zu schreiben, wo bereits der Disassembler die Adresse hingeschrieben hat.
:
Bearbeitet durch User
Schön, wie Haliigqualli's scheiß geheipt wird, während Josef was vorzuzeigen hat!
malsehen schrieb: > während Josef > was vorzuzeigen hat! Ich denke er sollte damit bei Elektronik-Firmen vorsprechen. Vielleicht übernimmt ein großer Controller-Hersteller sein Design und für Josef sollte dann eine entsprechende Position im Unternehmen drin sein. Manche Welt-Marken sind so entstanden!
Sehr guter Einwand! Nur sollte man da aufpassen welche Rechte bereits vergeben wurden.
Nicht W. schrieb: > Sehr guter Einwand! Nur sollte man da aufpassen welche Rechte > bereits vergeben wurden. Da müsste er sich mal umfassend beraten lassen und sich ggf. eigene Markennamen beim Patentamt schützen lassen! Ein erfolgreicher Start am Markt will heutzutage gut vorbereitet sein!
Josef G. schrieb: > Der einfachste ... Eingriff ist, die Absolut-Adressen durch > einen vorangestellten Buchstaben in ein Label zu verwandeln Einen Buchstaben und einen "." (Bindestrich auf Grundlinie).
Josef G. schrieb: > Josef G. schrieb: > Der einfachste ... Eingriff ist, die Absolut-Adressen durch > einen vorangestellten Buchstaben in ein Label zu verwandeln > > Einen Buchstaben und einen "." (Bindestrich auf Grundlinie). Nein
Josef G. schrieb: > Josef G. schrieb: > Der einfachste ... Eingriff ist, die Absolut-Adressen durch > einen vorangestellten Buchstaben in ein Label zu verwandeln > > Einen Buchstaben und einen "." (Bindestrich auf Grundlinie). Eher umgekehrt. Den Punkt davor hast Du auch vergessen. Erst mit Unterstrich verbunden ergibt beides dann wirklich einen Sinn! Sonst kommt es nur unnötig zu Missverständnissen.
Josef G. schrieb: >> Ich habe sowas mit einem Z80 gemacht > Wie groß war der Adressraum für die Karten-Software? Was verstehst du unter "Karten-Software"? Auf den Karten selbst lief überhaupt keine Software. Ein Z80 hat immer einen 64 KB-Adressraum. Josef G. schrieb: >> Das hätte ich von einem Disassembler/Assembler eigentlich >> auch ohne händische Nachbearbeitung erwartet... > > Der Disassembler gibt immer Absolut-Adressen aus. > Der Assembler erwartet an manchen Stellen Labels > oder Relativ-Werte aus 1 oder 2 Byte. Dann solltest du das ändern. Ein Disassembler sollte immer in der Lage sein, eine assemblierbare Ausgabe zu erzeugen.
S. R. schrieb: > Was verstehst du unter "Karten-Software"? > Auf den Karten selbst lief überhaupt keine Software. > ... > Ein Z80 hat immer einen 64 KB-Adressraum. Bei meinem Steckkarten-Konzept bestehen die Karten aus Spezial-Hardware (zB. IO-Hardware) und mitgebrachter Software ("Treiber" oder andere Software). Für jede Steckkarte allein stehen volle 64-KByte Adressraum zur Verfügung, dazu IO-Adressraum. Nach der weiter oben angesprochenen Umdisposition befürworte ich aber nicht mehr, dass die 64-KByte Karten-Speicher physikalisch auf der Karte selber liegen, sondern als reservierter Bereich auf der Hauptplatine liegen. S. R. schrieb: > Dein Steckkartenkonzept ist nichts neues. Sowas wird > seit Jahrzehnten gemacht und ist inzwischen auch von > der Grundidee vollständig veraltet. > ... > Ich habe sowas mit einem Z80 gemacht Ist offenbar doch bei mir anders und vielleicht neu. --- S. R. schrieb: > Dann solltest du das ändern. > Ein Disassembler sollte immer in der Lage > sein, eine assemblierbare Ausgabe zu erzeugen. Die händische Nachbearbeitung habe ich bereits teilweise in ein C-Programm verlagert, das könnte man noch ausbauen. (Der Disassembler läuft auf dem PC, nicht auf dem 8bit-System.)
:
Bearbeitet durch User
Josef G., wenn ich bei dir längerfristig vor meiner Frau untertauchen kann (5€ Essen/Tag + Dusch-/Schlafmöglichkeit), arbeite ich gerne als Gegenleistung Vollzeit am bo8-Projekt. Falls du einen Lebenslauf benötigst, gib Bescheid!
Ich glaube das NES hat immer nur einen Teil des ROM-Moduls in den Adressbereich gemapped, und dann über Register-Schrieb immer einen anderen Teil des ROM ausgewählt der eingeblendet werden soll.
Josef G. schrieb: > Kann ich beides leider nicht bieten. Ein bischen Einsatz wirst Du wohl bringen müssen wenns mit dem Bo8 Siegeszug über die Welt noch was werden soll.
Josef G. schrieb: > Bei meinem Steckkarten-Konzept bestehen die Karten aus > Spezial-Hardware (zB. IO-Hardware) und mitgebrachter > Software ("Treiber" oder andere Software). Wieviele Steckkarten gibt es, wie gut funktionieren sie, und welche Vorteile hast du in der Realität von deinem Konzept? Das Konzept eines "Option ROM" gibt es übrigens auch bei ISA-Karten. Dies ermöglicht es, z.B. SCSI- oder Netzwerkkarten zu benutzen, obwohl das BIOS dafür keine Treiber hat. > Für jede Steckkarte allein stehen volle 64-KByte > Adressraum zur Verfügung, dazu IO-Adressraum. Meine Steckkarten haben das nicht, denn ich habe festgestellt, dass es in der Realität keinen Vorteil bringt. Grafikkarten (im Grafikmodus) brauchen weit mehr als 64 KB, dafür ist dein Konzept ungeeignet. Im Textmodus reichen auch 4 KB. Netzwerkkarten benötigen einen, maximal zwei Paketpuffer, also etwa 3 KB. Sinnvollerweise nutzen sie aber DMA in den Systemspeicher und brauchen daher keinen eigenen Speicher. Massenspeicher (IDE, SCSI, SD) nutzen 512 Byte-Sektoren. Mit 1 KB hat man sowohl einen Schreib- als auch einen Lesepuffer. Auch hier ist DMA die bessere Lösung als ein großer Puffer. Für Flash-Speicher ist die Erase-Größe sinnvoll. Diese liegt oft bei 4 MB oder mehr, dafür ist dein Konzept ungeeignet. Wenn du einen ISA-Bus implementieren würdest, hättest du einen externen 20 Bit-Adressraum, den du beliebig auf die Karten verteilen kannst. Die meisten Karten brauchen nicht mehr als ein oder zwei Blöcke. > Nach der weiter oben angesprochenen Umdisposition > befürworte ich aber nicht mehr, dass die 64-KByte > Karten-Speicher physikalisch auf der Karte selber > liegen, sondern als reservierter > Bereich auf der Hauptplatine liegen. Warum sollten auf der Hauptplatine getrennte Speicher für jede Steckkarte bereitgestellt werden, unabhängig davon, ob eine Steckkarte vorhanden ist oder nicht? Das empfinde ich als Verschwendung. Im Übrigen behinderst du damit Steckkarten, die mehr als 64 KB benutzen möchten und dafür Banking selbst implementieren. > S. R. schrieb: > Die händische Nachbearbeitung habe ich bereits teilweise > in ein C-Programm verlagert, das könnte man noch ausbauen. Du solltest lieber die Grundprogramme reparieren, als Zusatzprogramme zu entwickeln. Es sollte doch nicht schwer sein, den Assembler auch relative Angaben verstehen zu lassen? > (Der Disassembler läuft auf dem PC, nicht auf dem 8bit-System.) Dass dein System nicht selbstständig ist, wissen wir bereits.
S. R. schrieb: > Es sollte doch nicht schwer sein, den Assembler > auch relative Angaben verstehen zu lassen? Das tut er ja. Josef G. schrieb: > Der Disassembler gibt immer Absolut-Adressen aus. > Der Assembler erwartet an manchen Stellen Labels > oder Relativ-Werte aus 1 oder 2 Byte.
Josef G. schrieb: >> Es sollte doch nicht schwer sein, den Assembler >> auch relative Angaben verstehen zu lassen? > Das tut er ja. ...und den Disassembler relative Angaben ausgeben zu lassen?
Josef G. schrieb: > Vielleicht schreibt ja mal jemand eine verbesserte Dokumentation. Du machst wohl Witze? Josef G. schrieb: > Das sind alles Dinge, von denen ich nichts verstehe. Dann setz dich auf deinen Hintern und wirf dein Gehirn an, bevor es total eingerostet ist… Leider funktioniert IT nicht so, dass man sich für ewig auf irgend welchen Lorbeeren ausruhen könnte, die man Jahrzehnte vor der einsetzenden Demenz mal erworben hat. > Aber vielleicht habe ich ja was missverstanden, und > das Interesse beschränkt sich nur auf die CPU allein. Ich fürchte, du hast noch viel mehr missverstanden.
Josef G. schrieb: > Ich frage mich, was die Motivation jener Leute ist, > die nun sogar den User Nicht W. negativ bewerten. Frag Lothar, der weiß es: Beitrag "Re: 8bit-Computing mit FPGA"
Uhu U. schrieb: > Frag Lothar, der weiß es: > Beitrag "Re: 8bit-Computing mit FPGA" Glaubst du, dass das folgende frei erfunden ist? Nicht W. schrieb: > sieht unser Prof ähnlich, weshalb zum bo8 ein Laborversuch existiert. Nicht W. schrieb: > Viele Studenten haben mit dem bo8 bereits erfolgreich experimentiert
Uhu U. schrieb: > Leider funktioniert IT nicht so, dass man sich für ewig auf irgend > welchen Lorbeeren ausruhen könnte, die man Jahrzehnte vor der > einsetzenden Demenz mal erworben hat. Die letzte größere Verbesserung liegt noch nicht so lange zurück: Josef G. schrieb: > Josef G. schrieb: >> Als Alternative habe ich mir folgende Lösung überlegt: >> H.. gibt nach dem Einlesen des folgenden Opcodes in jedem Fall >> statt BN ein BP aus. Zusätzlich wird auch nach HA stets ein BP >> statt BN ausgegeben. Falls also auf H.. kein J.. folgt, hebt >> das zweite BP die page-Umschaltung des ersten BP wieder auf. > > Habe das jetzt so umgesetzt. Das Einlesen von > Read-Daten erfolgt jetzt erst zum Zeitpunkt 2.
Josef G. schrieb: > Glaubst du, dass das folgende frei erfunden ist? > > Nicht W. schrieb: >> sieht unser Prof ähnlich, weshalb zum bo8 ein Laborversuch existiert. > > Nicht W. schrieb: >> Viele Studenten haben mit dem bo8 bereits erfolgreich experimentiert Erstunken und erlogen. Ein Zuckerl für den Threadinhaber damit der nicht die Motivation verliert :)
S. R. schrieb: > Ein Z80 hat immer einen 64 KB-Adressraum. Nein zwei mal 64 kB Adressräume: einen für Speicherzugriffe und einen für I/O-Zugriffe.
Josef G. schrieb: > Glaubst du, dass das folgende frei erfunden ist? Ja. Das mag bitter für dich sein, aber der Typ verascht dich ganz offensichtlich - in einem gelöschten Beitrag von ihm stand ein Link auf Github, der mit deinem Ding absolut überhaupt nichts zu tun hatte. Aber frag Lothar, der kann dir den Beitrag sicherlich zukommen lassen.
Uhu U. schrieb: > in einem gelöschten Beitrag von ihm Nein, der gelöschte Beitrag stammte von einem anderen (nicht angemeldeten) User. Ich dachte auch erst, es handele sich um den User "nichtsowichtig".
:
Bearbeitet durch User
Route 6. schrieb: > Nein zwei mal 64 kB Adressräume: > einen für Speicherzugriffe und einen für I/O-Zugriffe. Soweit ich mich erinnere war das immer eine Schwäche des Z80 eben nur 256 Adressen für I/O zu haben. (0-255)
Stephan schrieb: > Soweit ich mich erinnere war das immer eine Schwäche des Z80 eben nur > 256 Adressen für I/O zu haben. (0-255) Soweit ich mich erinnere, waren lediglich die gängigen Adressdecoder für Z80-I/O meist auf 8 Bit beschränkt. Das ist aber keine Schwäche des Z80, sondern einfach nur Sparsamkeit der Hersteller, die irgendwelche Peripherie an den Z80 angebunden haben. Mit IN r,(C) bzw. OUT (C),r hat der Z80 schon immer 16 Bit auf den Adressbus gelegt, nämlich das Registerpaar BC. Auszug aus dem ZILOG Z80 Manual: "In all Register Indirect input output instructions, including block I/O transfers, the contents of the C Register are transferred to the lower half of the address bus (device address) while the contents of Register B are transferred to the upper half of the address bus." Der ZX81 und der ZX Spectrum haben dieses Feature durchaus genutzt, nämlich fürs Keyboard. Auch der Amstrad CPC verwendete 16 Bit I/O. Ich habe damals auch schon externe Geräte für den ZX Spectrum gebaut, welche die vollen 16 Bit Adressraum dekodierten. P.S. Die Verwendung/Dekodierung von 16 Bit I/O auf dem Z80 hat lediglich einen kleinen Nachteil: Man verbaut sich hier die Verwendung von Block-IO auf solchen Adressen, denn das Register B wird bei Block-IO als Repeat-Counter für den Block verwendet.
:
Bearbeitet durch Moderator
Stephan schrieb: > Soweit ich mich erinnere war das immer eine Schwäche des Z80 eben nur > 256 Adressen für I/O zu haben. (0-255) Das ist ein Irrtum. Bei jedem(!) I/O-Zugriff waren alle 16 Adressbits definiert gesetzt. Bei einem einfachen OUT 86h,A findet man auf A0-7 die Adresse 86h, der Akku liegt auf dem Datenbus aber A8-15 geben den Akku ebenfalls aus. Bei OUT (C),A wird C auf A0-7 gelegt, A auf den Datenbus und(!) B kommt auf die Adressen A8-15. So kann man über das BC-Register volle 64 kB direkt adressieren. Sorry, zu lange kontrollgelesen
:
Bearbeitet durch User
Stephan schrieb: > Soweit ich mich erinnere war das immer eine Schwäche des Z80 > eben nur 256 Adressen für I/O zu haben. (0-255) Das gilt für den 8080 und damit für dessen Peripherie. Entsprechend wurden viele Systeme auch nur dafür ausgelegt. Da man oft nur wenige I/O-Ports braucht, stört das nicht weiter und vereinfacht die Leiterplatten. Daher nochmal als Nachtrag: Route 6. schrieb: >> Ein Z80 hat immer einen 64 KB-Adressraum. > > Nein zwei mal 64 kB Adressräume: > einen für Speicherzugriffe und einen für I/O-Zugriffe. In meinem Z80-System werden beide 64 KB-Adressräume für Steckkarten bereitgestellt. Der Speicheradressraum für die Speicherkarte, der I/O-Adressraum je nach Slot aufgeteilt (32 x 256 Ports pro Karte). Die Adressen werden ebenso wie die (Vektor-)Interrupts zentral auf dem Mainboard decodiert.
S. R. schrieb: > In meinem Z80-System Da du es jetzt schon mehrfach erwähnt hast: Ist das Projekt Geschichte oder noch aktuell? Hast du das Projekt in einem eigenen Thread oder einem Wiki-Artikel vorgestellt?
Josef G. schrieb: > Ist das Projekt Geschichte oder noch aktuell? Das Projekt lag ein paar Jahre im Schrank, aber ich habe vor ein paar Wochen eine Steckkarte mit zwei ISA-Slots gebaut. Leider ist die FDC-Karte, die ich eigentlich haben wollte, kaputt (funktioniert auch im PC nicht). Die COM/LPT-Karte braucht ±12V (für UART), also habe ich ein passendes Netzteil bestellt, aber noch nicht eingebaut. Stattdessen habe ich den gesamten Code (sowohl die AVR-Firmware als auch das CP/M BIOS) einmal neu umgebaut, aber an der Steckkarte nicht weiter entwickelt. Bei der Arbeit daran habe ich aber gemerkt, dass das ursprüngliche Konzept (also ein Mainboard mit Erweiterungskarten nach eigenem Standard) heutzutage nicht mehr sinnvoll ist. Das betrifft auch dein System und daher mein Ratschlag: Mach es neu, und diesmal ordentlich. Ich werde irgendwann eine Neuentwicklung machen, auf Basis eines TMPZ84C015, 256 KB Flash, 512 KB SRAM und ISA-Slots. Das erspart mir viel Arbeit und bringt mir mehr Freude. Josef G. schrieb: > Hast du das Projekt in einem eigenen Thread > oder einem Wiki-Artikel vorgestellt? Schaltplan und Bilder gibt es hier, die Grundidee im ersten Post: Beitrag "Re: eigenes Z80 Mainboard - geht das so?"
S. R. schrieb: > und daher mein Ratschlag: Mach es neu, und diesmal ordentlich Was stellst Du Dir unter konkret "ordentlich" vor? Meinst Du irgendwas könnte Josefs proprietär eigenwilliges System retten? > irgendwann eine Neuentwicklung machen > bringt mir mehr Freude Ja, die Freude am Entwickeln und Funktionieren. Aber aus purer Anwendungssicht sind das heutzutage allesamt Fehlkonstruktionen. Schlimmer noch, von letztendlichen konkreten Anwendungen ist noch nichtmal die Rede und vermutlich besteht zwischen beidem sogar ein Zusammenhang!
Jeff schrieb: > Aber aus purer Anwendungssicht sind das > heutzutage allesamt Fehlkonstruktionen. Das Leben auch.
S. R. schrieb: > Jeff schrieb: > Aber aus purer Anwendungssicht sind das > heutzutage allesamt Fehlkonstruktionen. > > Das Leben auch. Das muss man nicht pessimistisch sehen. Freude am Entwickeln und Funktionieren darf durchaus das Entscheidende sein. Nur darf man eben nicht erwarten, daß sich mit dem puren Funktionieren allein, und sei es noch so komplex, automatisch passende Anwendungen und Anwender finden!
Mit der von hinten, von der Anwenderseite her denkenden Sichtweise tun sich Programmierer und Systementwickler generell schwer. Viel lieber beschäftigen und erfreuen sie sich mit/an ihren technischen Möglichkeiten und tollen, eleganten Umsetzungen. Den bequemen Anwender im Fokus zu haben ist oft viel anstrengender, umständlicher, aufwändiger. Dummerweise sind jedoch Projekte so kommerziell am erfolgreichsten :)
Mr.Sam schrieb: > Viel lieber > beschäftigen und erfreuen sie sich mit/an ihren technischen > Möglichkeiten und tollen, eleganten Umsetzungen. Wenn Josef wenigstens was tolles, elegantes geschaffen hätte. Leider hat er sein Projekt eher nach der "von hinten durch die Brust ins Auge"-Methode gestaltet und sich nie gefragt warum die Entwickler von 6502, Z80 und aller anderen 8-Bit-Prozessoren nie ein ähnliches Konzept verfolgt haben wie er.
Manfred F. schrieb: > Wenn Josef wenigstens was tolles, elegantes geschaffen hätte. Eleganz lässt sich nur im Vergleich mit Nicht-Eleganz beurteilen.
Wer will denn ernsthaft den Z80 als elegant bezeichnen? Aus heutiger Sicht muss man sagen: für die Logik die ein Z80 braucht bekommt man problemlos einen 32 Bit RISC im FPGA implementiert. Bei einem Bruchteil an nötigem Code. Mit deutlich höherer IPC. Einer der wenigen Vorteile, die geringe Codegröße, ist aus heutiger Sicht nicht mehr soviel Wert und macht es auch nicht elegant. Die Mächtigkeit der Assembler Befehle schon garnicht, so will eh kaum jemand programmieren. Elegant ist für mich ein vollständige RISC mit weniger als 20 Opcodes übersichtlich auf unter 1000 Zeilen Code, dem aber trotzdem nichts fehlt um ein vollständiges System aus Betriebssystem und Anwendungsprogrammen laufen zu lassen.
FPGA zum Spass schrieb im Beitrag #5954514: > Aus heutiger Sicht muss man sagen: für die Logik die ein Z80 braucht > bekommt man problemlos einen 32 Bit RISC im FPGA implementiert. > Bei einem Bruchteil an nötigem Code. > Mit deutlich höherer IPC. Schwachsinn!
FPGA zum Spass schrieb im Beitrag #5954514: > Elegant ist für mich ein vollständige RISC mit weniger als 20 Opcodes > übersichtlich auf unter 1000 Zeilen Code, dem aber trotzdem nichts fehlt > um ein vollständiges System aus Betriebssystem und Anwendungsprogrammen > laufen zu lassen. Elegant ist für mich ein vollständige RISC mit weniger als 20 Opcodes übersichtlich auf unter 42 Zeilen Code, dem aber trotzdem nichts fehlt, um ein vollständiges System aus Betriebssystem und Anwendungsprogrammen laufen zu lassen.
Klaus Banaus schrieb: > Schwachsinn! Meine Z80 Implementierung steht bei 5000 LUTs @ 100 Mhz. Der A-Z80 auf Opencores bei 2000 Luts, schafft aber nur 18 Mhz Der T80 bei ~3000 Luts und 35 Mhz 32 Bit RISCs gibts zur Genüge. Z.b. Nios2 mit 2300 LUTs im gleichen FPGA bei etwa 160 MHz. Dann bitte, zeig doch mal das es besser geht für den Z80. @ Andreas S: natürlich sind die Zahlen aus der Luft gegriffen. Ändert aber nicht daran, das ich übersichtliche Cores nach dem KISS Prinzip für eleganter halte als vollgequetsche Prozessoren, denen nicht mal 256 OPCodes reichen. Oder lass es mich so ausdrücken: wenn ich einen Z80 funktionsidentisch nachbaue und einen Tag danach dreiviertel alle OPCodes nachkucken muss, dann ist das für mich das Gegenteil von elegant.
FPGA zum Spass schrieb im Beitrag #5954723: > Klaus Banaus schrieb: >> Schwachsinn! > > Meine Z80 Implementierung steht bei 5000 LUTs @ 100 Mhz. > Der A-Z80 auf Opencores bei 2000 Luts, schafft aber nur 18 Mhz > Der T80 bei ~3000 Luts und 35 Mhz > > 32 Bit RISCs gibts zur Genüge. > Z.b. Nios2 mit 2300 LUTs im gleichen FPGA bei etwa 160 MHz. > > Dann bitte, zeig doch mal das es besser geht für den Z80. Schau, es ist bleibt Schwachsinn die Effizienz der Logik einer CPU anhand der LoC einer FPGA-Implementierung zu bewerten. Für eine Z80 (8bit) brauchts ca. 8500 Transistoren; für den Motorola 68000 (32bit) schon das Achtfache. Transistoren waren halt auch integriert sauteuer damals, ohne Grund greift man nicht zu Spartricks wie Akkumulatoren. Und die Taktrate wird eben von der Fertigungstechnologie (damals 5 µm, Transfergates geschaltet von überlappenden Taktsignalen) bestimmt und nicht von der Logiktiefe.
Ich vergleiche anhand von LUTs im FPGA. Das sind nicht Lines of Code, sondern Lookup-Tables, das Äquivalent zu deinen Transistoren. Aber spätestens damit: Klaus Banaus schrieb: > Und die Taktrate wird eben von der > Fertigungstechnologie (damals 5 µm, Transfergates geschaltet von > überlappenden Taktsignalen) bestimmt und nicht von der Logiktiefe. beweist du, das du von FPGAs noch nicht viel verstehst. Mag sein das ein Z80 heute im ASIC schnell wäre, aber darum gehts hier bei einem FPGA-Softcore Thread wohl eher nicht. Für ein FPGA ist der halt sehr suboptimal und wird eigentlich nur aus Kompatiblitätsgründen mit alter Software genutzt. Also nochmal: - ein NIOS2(32 Bit) braucht 2300 "Logikgatter" bei 160 Mhz und ~1 Instrutionen pro Takt - ein Z80 im FPGA braucht mindestens genausoviele "Logikgatter" im FPGA, eher mehr, erreicht aber nicht die Taktrate und liefert auch nur maximal 0.25 Instruktionen pro Takt
FPGA zum Spass schrieb im Beitrag #5954776: > Mag sein das ein Z80 heute im ASIC schnell wäre, aber darum gehts hier > bei einem FPGA-Softcore Thread wohl eher nicht. Doch genau darum geht es! Schau, man kann eine Architektur nicht losgelöst von der Herstellungstechnologie betrachten, jedenfalls nicht bei Hardware. Deshalb ist es Schwachsinn für CPU-Architekturen Softwaremetriken wie LoC heranzuziehen. >- ein NIOS2(32 Bit) braucht 2300 "Logikgatter" bei 160 Mhz und ~1 >Instrutionen pro Takt Klar "Logikgatter" in "Gänsefüßchen" gegen 'harte' Transistoren, es soll ja Leute geben die können sogar Elchen Gamasken verkaufen ... Und wenn schon Vergleiche dann richtig, 96 LUT für den 8bit Xilinx-Picoblaze, da sieht dein 32bit NIOS ganz schön fett dagegen aus und liefert 75% Blindleistung bei 8 bit daten, wenn schon ineffizient dann aber richtig! >- ein Z80 im FPGA braucht mindestens genausoviele "Logikgatter" im FPGA, >eher mehr, erreicht aber nicht die Taktrate und liefert auch nur maximal >0.25 Instruktionen pro Takt Und MC68000 brauchte 4 Takte für ein NOP, das bedingt die verwendete Technologie damals, aber du Grünschnabel ignorierst das befliesentlich historische Gegebenheiten nur um vorlaut Birnen mit Äpfel vergleichen zu können...
FPGA zum Spass schrieb im Beitrag #5954776: > Ich vergleiche anhand von LUTs im FPGA. Das sind nicht Lines of Code, > sondern Lookup-Tables, das Äquivalent zu deinen Transistoren. Doch benutz Lines of Code zum Vergleich, ich zitiere: "Elegant ist für mich ein vollständige RISC mit weniger als 20 Opcodes übersichtlich auf unter 1000 Zeilen Code," Erzähl mir nicht "Es regnet" und pinkele mir dabei ans Knie!
Klaus Banaus schrieb: > Doch benutz Lines of Code zum Vergleich Blödsinn, alle VERGLEICHE zwischen Z80/NIOS2 von mir oben sind in LUTs. Du zitierst den einen Satz wo es um etwas völlig anderes geht, nämlich um Eleganz. Aber wenn für dich Eleganz und Effizienz das gleiche sind, dann bitte. Klaus Banaus schrieb: > Schau, man kann eine Architektur nicht losgelöst von der > Herstellungstechnologie betrachten Genau das tust du doch die ganze Zeit. Die Technologie hier im Thread heißt FPGA. FPGAs haben keine harten Transistoren die man direkt programmieren könnte, sondern nur LUTs. Für FPGAs eignen sich bestimmte Architekturen besonders gut. Der Z80 gehört nicht dazu. Dein Picoblaze Beispiel ist doch der beste Beweis. Das Ding ist ein RISC mit rund 20 Opcodes. Das hat mit einem Z80 sehr wenig gemeinsam. Soviel zu Äpfen und Birnen.
Weswegen ich eigentlich hier schreiben wollte habe ich bei dem ganzen Blödsinn von antiken Prozessoren vergessen: @ bome: meine Empfehlung an dich ist: hab Spaß mit deinem Projekt und lerne davon. Gerade im FPGA Bereich kann man ohnehin nicht mehr erwarten. Hier gab es grandiose, riesige Projekte die trotzdem tot sind. z.b.: https://www.mikrocontroller.net/articles/16/32Bit_Computer/Konsole Ähnlich geht es fast allen Projekten auf Opencores. Die wenigen FPGA-Community Projekte die aktiv sind, z.b. Mister, werden von einer handvoll Leuten aktiv betreut. Kurz: die FPGA Community ist verdammt klein und zerstreut. Fast immer kocht jeder ein bischen sein Süppchen und dann stirbt das Projekt. Das der Thread hier überhaupt noch aktiv ist, liegt wohl fast ausschlisslich daran wie kontrovers diskutiert wird. Leider zu einem großen Teil von Leuten die mit FPGAs garnichts am Hut haben und vor allem die Aufmachung kritisieren. Wobei man realistisch doch sagen muss: wenn die Aufmachung richtig gut wäre, dann wäre das Projekt warscheinlich genauso tot. Vielleicht ist das so eine Maßnahme es am Leben zu halten. Ich wünsche dir auf jeden Fall noch weiter gutes Gelingen.
FPGA zum Spass schrieb im Beitrag #5954514: > Wer will denn ernsthaft den Z80 als elegant bezeichnen? Verglichen mit dem 8080 ist er es… > Die Mächtigkeit der Assembler Befehle schon garnicht, so will eh > kaum jemand programmieren. Vor einem RISC-Prozesser muss er sich nicht verstecken…
:
Bearbeitet durch User
Beitrag #5954882 wurde von einem Moderator gelöscht.
Wer portiert denn mal den Dhrystone auf bo8? https://de.wikipedia.org/wiki/Dhrystone Achso, dafür braucht man erstmal einen C-Compiler...
Ich finde es vermessen, einen aktuellen 32 Bit-Prozessor in einem aktuellen FPGA mit einem erfolgreichen Design der 70er zu vergleichen. Den NIOS2 (oder RISC-V) hätte man damals schlicht nicht fertigen können. Realistisch betrachtet ist der bo8 auf der Ebene eines Z80, nicht auf der Ebene eines RISC-V. MaWin schrieb im Beitrag #5954882: > Wer kann einen guten Schnaps empfehlen der zwar "dicht" macht, aber am > nächsten Tag keine Kopfschmerzen? Водка Архангелская. Wurde uns in Russland empfohlen und mehrfach für sehr gut befunden.
Ist es vermessen alte Technik mit Neuer zu vergleichen? Was soll daran schlimm sein? Ich will mir auch nicht anmaßen heute oder gar in den 70ern ein besseres Design machen zu können. Trotzdem darf ich ja eine Meinung dazu haben. Und wenn hier der bo8 als unübersichtlich usw kritisiert wird und man etwas eleganteres zum Vergleich anbietet, dann kommen für mich nicht nur 40 Jahre alte Design als Referenz in Frage, sondern natürlich auch aktuelle Entwicklungen, wenn die eleganter sind. Dazu auch von bome selbst: >> Das von mir erarbeitete Projekt eines 8bit-Rechners soll kein >> Retro-Projekt sein. Der Rechner soll ein moderner Rechner sein. Was liegt dann näher, als moderne Designs anzusetzen? Ich bin der Meinung ein 32 Bit RISC mit starren 32 Bit OPCodes und 3 Operanden ist viel leichter zu verstehen und in VHDL für ein FPGA zu implementieren als z.b. ein Z80. Ich habe beides durch, ist also keine bloße Theorie.
FPGA zum Spass schrieb im Beitrag #5955071: > Was liegt dann näher, als moderne Designs anzusetzen? Unter dem Aspekt gewinnt immer das moderne Design. In einem 100m-Spring kann man auch einen einigermaßen geübten Läufer mit einem Dreijährigen vergleichen. Das Ergebnis sollte dann aber niemanden überraschen... selbst dann nicht, wenn der Läufer im Rollstuhl sitzt. "Retro" impliziert irgendeine Form von Kompatiblität mit alter Technik, und bo8 ist definitiv zu nichts kompatibel. Trotzdem ist es eine Entwicklung, die technisch irgendwo in den 70ern klebt. Vielleicht leistungsfähiger als ein Z80, umständlicher als ein i8042. Für einen halbwegs fairen Vergleich sollte man schon mit Gleichwertigem vergleichen... und das heißt auch, dass nichts davon für Neuentwicklungen sinnvoll ist - auch bo8 nicht.
Jeff schrieb: > von letztendlichen konkreten > Anwendungen ist noch nichtmal die Rede Tooootal unbequem und lästig diese Frage! Wen interessiert das hier? FPGA zum Spass schrieb im Beitrag #5954834: > Ich wünsche dir auf jeden Fall noch weiter gutes Gelingen. Nett. Hilft aber alles nix, besser Klartext reden: Das ist alles so gründlich missraten, der Herr sollte besser (seit gestern) sinnvolleres mit Zeit und Wissen anstellen.
Spielt doch keine Rolle ob der bo8 leistungsfähiger ist als ein Z80 oder nicht. Aus heutiger Sicht ist jeder Softcore lahm im Vergleich zu dem was sonst so verfügbar ist, auch ein NIOS2 oder RISC-V im FPGA. Im aller besten Fall erreicht man mit einem Softcore heute die Geschwindigkeit, die Mitte der 90er für PCs üblich war. So gesehen müsste eigentlich jeder sofort aufhören etwas in die Richtung zu entwickeln. Hier wird das zumindest immer so hingestellt. Sehe ich aber nicht so. Wenn man dabei Spaß hat und etwas lernt ist es das auf jeden Fall wert. Man sollte nur nicht unbedingt darauf hoffen das Andere das hinterher benutzen. Um bei der Läufer Analogie zu bleiben: nur weil ich langsamer bin als Andere und mein Laufstil für nahezu jeden völlig unverständlich, heißt das doch nicht das ich das Hobby aufgeben müsste. Ich sollte dann halt nicht erwarten damit Pokale zu gewinnen oder Andere für meine Art zu Laufen zu begeistern.
FPGA zum Spass schrieb im Beitrag #5955221: > Ich sollte dann halt nicht erwarten damit Pokale zu gewinnen > oder Andere für meine Art zu Laufen zu begeistern. Ich kann's aber versuchen. :-)
Beitrag #5955338 wurde von einem Moderator gelöscht.
FPGA zum Spass schrieb im Beitrag #5955071: > Trotzdem darf ich ja eine Meinung dazu haben. Ja natürlich darfst du das… > Und wenn hier der bo8 als unübersichtlich usw kritisiert wird und man > etwas eleganteres zum Vergleich anbietet, dann kommen für mich nicht nur > 40 Jahre alte Design als Referenz in Frage, sondern natürlich auch > aktuelle Entwicklungen, wenn die eleganter sind. Das ist in etwa so, als würdest du Hochspringer der 1920er Jahre mit einem heutigen vergleichen. > Dazu auch von bome selbst: >>> Das von mir erarbeitete Projekt eines 8bit-Rechners soll kein >>> Retro-Projekt sein. Der Rechner soll ein moderner Rechner sein. Na ja, was bome dazu sagt, muss man - den entsprechenden Sachverstand vorausgesetzt - nicht unbedingt für bare Münze nehemen. > Was liegt dann näher, als moderne Designs anzusetzen? Wenn man sich auf bomes Niveau begeben will, kann man das tun - es verhält sich allerdings nicht anders, als mit den Hochspringern.
:
Bearbeitet durch User
FPGA zum Spass schrieb im Beitrag #5955221: > Um bei der Läufer Analogie zu bleiben: nur weil ich langsamer bin als > Andere und mein Laufstil für nahezu jeden völlig unverständlich, heißt > das doch nicht das ich das Hobby aufgeben müsste. Da hast du Recht. Man sollte aber auch nicht so vermessen sein, zu erwarten, dass Ergebnis das Non-Plus-Ultra ist, das mit der heutigen µC-Technik mithalten kann. Bomes Haltung "Ich habe da was ganz tolles gemacht und jetzt macht bitte was damit" und gleichzeitig immer Wünsche nach einer halbwegs brauchbaren Dokumentation und einer zeitgemäßen Entwicklungsumgebung incl. Compiler mit dem Hinweis abzulehnen, davon verstünde man nichts, ist doch etwas merkwürdig. Findest du nicht?
FPGA zum Spass schrieb im Beitrag #5954834: > Leider zu einem großen Teil von Leuten die mit FPGAs garnichts am Hut > haben und vor allem die Aufmachung kritisieren. Selbst wenn alles was "am Hut haben" wäre das völlig unzureichend. Hier geht es nicht um plumpe Erfahrung mit FPGA sondern deteiliertes Verständniss der Auswirkungen von Architekturentscheidungen. Aber mindestens braucht es den Mut selber eine Architektur zu entwerfen und zu evaluieren. Und wie ich das sehe, hat das ausser dem TO noch keiner gewagt. Aber alle meinen mit Dummdödelargumenten wie moderenes design schlägt altes design Mit-palavern zu können. >Dein Picoblaze Beispiel ist doch der beste Beweis. Das Ding ist ein RISC >mit rund 20 Opcodes. Du kennst den Picoblaze nicht wirklich, der hat rund 50 Opcodes (grad im Befehlsdecoder nachgeschaut). Und statt einer RISC-Registerbank bringt er ein kleines DP-SRAM Feld mit. Und der picoplace ist nach seinem Schöpfer Ken Chapman keine CPU sondern lediglich eine Programmable State Machine (deswegen hiess der picoblaze auch ursprünglich KCPSM). Deshalb fehlen ihm im Unterschied zum Z80 einige addressierungsverfahren, div. Interruptregime, Buswechselmechanismen für DMA, die Flags HC, SG, PA, etc. pp. Wass ich überhaupt nicht verstehe, angeblich haste ja Z80 Code vorliegen. Dann schau doch bitte mal durch die netzliste nach der Synthese oder log-files wo die CLB's verloren gehen. Dort findest du die wahren Gründe warum die FPGA- Nachäffungen weit mehr resourcen benötigen als nötig. Hint 1: https://www.xilinx.com/support/documentation/white_papers/wp275.pdf Hint 2: https://www.xilinx.com/support/documentation/white_papers/wp272.pdf und diverse weitere Implementierungsschnitzer. Die Architektur ist von Grund auf sparsam angelegt. Aber Personen, die Eleganz lediglich an der zahl von weggehämmerten Zeilen messen wollen, ignorieren das gewöhnlich.
Der Code ist im Gameboy Thread drin. Steht dir frei den zu optimieren. Meiner braucht mehr als z.b. der T80 weil ich 100 MHz erreichen wollte. Und auch weil ich Dinge die sonst in mehreren Cycles passieren in einem machen wollte, weil mir 4 Takte pro Instruktion zu viel waren. Zudem steht die Synthese auf Speed. Stelle ich auf Area schrumpft er von 5000 Luts auf <3000. Dann sinds aber nur noch <70 Mhz. Den Picoblaze kenne ich tatsächlich nur von der Wikipedia Seite, wo nur rund 20 OPcodes vermerkt sind, manche davon sogar optional. Die 50 Opcodes hat der sicherlich auch nicht in der erwähnten 96 Lut Variante. Uhu U. schrieb: > Compiler mit dem Hinweis abzulehnen, davon verstünde man nichts, > ist doch etwas merkwürdig. Findest du nicht? Sicherlich, da würde ich mir aber nicht zumuten mitreden zu müssen. Ich mag keine Assembler Programmierung und habe für meine eigenen Softcores seit jeher Compiler eingesetzt. Andere scheinen damit klar zu kommen. WENN man aber andere ansprechen will, dann ist ein Compiler sinnvoll, da stimme ich uneingeschränkt zu.
S. R. schrieb: > Vielleicht leistungsfähiger als ein Z80, Würde ich nicht behaupten wollen. In mancher Hinsicht ist meine CPU sicher sogar weniger leistungsfähig. Aber sie kann eines sehr viel besser als ein Z80, nämlich mehr als 64-KByte adressieren. Da ist nicht nur der Sprung von einer 64-KByte-Seite in eine andere, sondern auch die Tatsache, dass die CPU auf den Steuerleitungen anzeigt, von welchem der vier Adressregister P,X,Y,Z eine ausgegebene Adresse kommt. Dadurch kann eine externe Logik die Adressregister zum selben Zeitpunkt in unterschiedliche 64-KByte-Seiten zeigen lassen. Die Berechnung der Dauer von Befehlsfolgen ist einfacher als beim Z80, und der Befehlssatz ist leichter zu merken.
Josef G. schrieb: > Aber sie kann eines sehr viel besser als ein Z80, > nämlich mehr als 64-KByte adressieren. Ja, wobei das ein gelöstes Problem ist. Damals übliches Banking löst 90% des Problems und 16 Bit-Chips den Rest. Josef G. schrieb: > Die Berechnung der Dauer von Befehlsfolgen ist einfacher > als beim Z80, und der Befehlssatz ist leichter zu merken. Das lese ich als Witz, nicht als Vorteil.
S. R. schrieb: > löst 90% des Problems und 16 Bit-Chips den Rest. Keine CPU ist ideal für alles. Meine hat ihre Nische da, wo man keine 16-Bit-CPU verwenden will. > Das lese ich als Witz, nicht als Vorteil. Für Hochsprachen-Programmierer ist es kein Vorteil. Für Assembler-Hobbyisten schon.
Josef G. schrieb: > Nische da, wo man keine 16-Bit-CPU verwenden will. Dann nimmt man einen AVR oder einen anderen marktüblichen 8Bit Controller. Deine Nische gibts nicht, gabs nicht und wirds nie geben.
Josef G. schrieb: >> löst 90% des Problems und 16 Bit-Chips den Rest. > Keine CPU ist ideal für alles. Meine hat ihre > Nische da, wo man keine 16-Bit-CPU verwenden will. Kannst du mir ein Beispiel für deine Nische geben? >> Das lese ich als Witz, nicht als Vorteil. > > Für Hochsprachen-Programmierer ist es kein Vorteil. > Für Assembler-Hobbyisten schon. Ich wollte damit zum Ausdruck bringen, dass dein Befehlssatz alles andere als "einfach zu merken" ist. Hochsprachen-Programmierer gibt es mangels Hochsprache ohnehin nicht und Assembler-Hobbyisten sind in erster Linie fremd.
S. R. schrieb: > Kannst du mir ein Beispiel für deine Nische geben? Jetzt treib ihn doch nicht so in die Enge seiner Nische! Ob es ihm diesmal gelingt daraus wieder wie ein schleimiger Aal zu entwischen?
Wieder was im Markt-Forum: Ein Altera DE0-Board. Das Board ist allerdings auch neu noch erhältlich. Beitrag "[V] FPGA terasic Development Board Altera DE0" Beim zweiten Angebot desselben Users bin ich nicht sicher, ob es sich um das Spartan-3E-Starter-Board handelt, auf dem ich mein Systen realisiert habe. Auf dem Foto sieht es jedenfalls so aus. Es scheint kein Netzgerät dabei zu sein, aber preislich wäre es interessant. Beitrag "[V] Digilent Xilinx FPGA Development Board Spartan-3E"
:
Bearbeitet durch User
Josef G. schrieb: > Wieder was im Markt-Forum: Ein Altera DE0-Board. Und diese Big News musst Du nun in Deinem Thread wiederkäuen? Erzähl uns lieber was von der herbeifantasierten Nische, das wär tausendmal interessanter. Aber das scheut der Projektherr natürlich wie der Teufel das Weihwasser :) > aber preislich wäre es interessant. Für Dein System??? Da wär jeder Cent zuviel!
FFlarsen schrieb: > Und diese Big News musst Du nun in Deinem Thread wiederkäuen? Mein System läuft auch auf dem DE0, das Board wäre also für die hier mitlesenden interessant. Darum.
Josef G. schrieb: > Aber sie kann eines sehr viel besser als ein Z80, nämlich mehr > als 64-KByte adressieren. Nein, Deine CPU kann auch nicht mehr als 64 KByte adressieren als der ursprüngliche Z80, sondern arbeitet mit Bankumschaltung. Und wie schon etliche Male erwähnt, vertragen sich Bankumschaltungen und (die bei Deiner CPU nicht vorhandenen...) Interrupts sehr schlecht. Ich hatte auch schon sehr deutlich darauf hingewiesen, dass es auch schon seit mehreren Jahrzehnten Z80-Ableger mit erweitertem Adressraum, z.B. HD64180, gibt.
Josef G. schrieb: > Beim zweiten Angebot desselben Users bin ich nicht > sicher, ob es sich um das Spartan-3E-Starter-Board > handelt, auf dem ich mein Systen realisiert habe. Und noch einmal: Spartan-3 ist tot für Einsteiger und neue Projekte, weil die hierfür benötigte ISE-Version auf PCs mit Windows 10 nicht mehr aus der Tüte fällt, sondern über Hintertüren zurechtgefrickelt werden muss. Bei Xilinx sind derzeit die siebte und achte Generation von FPGA als "Mainstream" anzusehen, d.h. mit Deinem Festklammern an Spartan-3 hinkst Du rund zehn Jahren hinter dem üblichen technischen Stand hinterher. Das ist nicht neu, das ist nicht modern. Du versuchst, einen Dinosaurier wiederzubeleben, den es allerdings nie gegeben hat.
Andreas S. schrieb: > dass es auch schon seit mehreren Jahrzehnten Z80-Ableger > mit erweitertem Adressraum, z.B. HD64180, gibt. Siehe https://de.wikipedia.org/wiki/Zilog_Z180 Dort heisst es: > Die MMU blendet den physikalischen Speicher > in 4 kByte-Blöcken in den logischen Adressraum ein. Bei mir sind es 64-KByte-Blöcke.
Josef G. schrieb: > Bei mir sind es 64-KByte-Blöcke. Das ändert jetzt aber alles :) Also mal im Ernst: Was soll dieses übelst umständliche Banking wenn sich heute sehr viel größere Speichermengen in flachen Speicherhiarchhien ganz unkompliziert linear adressieren lassen? Andreas S. schrieb: > Du versuchst, einen > Dinosaurier wiederzubeleben, den es allerdings nie gegeben hat Und Du redest (so wie ich) gegen eine Wand. Dort ist alles an längst überlebtem Urteil und Expertise für alle Zeiten festzementiert.
Josef G. schrieb: > Dort heisst es: >> Die MMU blendet den physikalischen Speicher >> in 4 kByte-Blöcken in den logischen Adressraum ein. > > Bei mir sind es 64-KByte-Blöcke. Also noch ein Nachteil Deiner Architektur. Je feiner die Granularität solcher einblendbaren Speicherblöcke, desto besser, und nicht umgekehrt. 64 KByte große Blöcke bei nur 64 KByte Adressraum sind doch ein großer Mist.
Uraltverkleider schrieb: > wenn sich heute sehr viel größere Speichermengen in flachen > Speicherhiarchhien ganz unkompliziert linear adressieren lassen? Ist dann halt keine 8-Bit-CPU und hat andere Nachteile, zB. nicht exakt vorhersagbare Dauer der Befehle. Andreas S. schrieb: > 64 KByte große Blöcke bei nur 64 KByte Adressraum > sind doch ein großer Mist. Warum?
Hallo, Josef G. schrieb: > und hat andere Nachteile, zB. nicht . Warum ist dir die exakt vorhersagbare Dauer der Befehle so wichtig? rhf
Beitrag #5958898 wurde von einem Moderator gelöscht.
Josef G. schrieb: > Ist dann halt keine 8-Bit-CPU Kann auch keine sein. Sonst könnte man auch nicht >64kB linear adressieren. Leuchtet Dir das ein? > zB. nicht exakt vorhersagbare Dauer der Befehle. Warum sollte man sich mit Deinem Konstrukt einen abbrechen wenn man zu jedem anderen marktüblichen 8Bitter greifen kann der das Gleiche und noch viel mehr beherrscht?
Josef G. schrieb: >> wenn sich heute sehr viel größere Speichermengen in flachen >> Speicherhiarchhien ganz unkompliziert linear adressieren lassen? > > Ist dann halt keine 8-Bit-CPU und hat andere Nachteile, > zB. nicht exakt vorhersagbare Dauer der Befehle. Das eine hat mit dem anderen nichts zu tun. Es gibt auch 16 Bit-Architekturen mit exakt vorhersagbaren Befehlsdauern. > Andreas S. schrieb: >> 64 KByte große Blöcke bei nur 64 KByte Adressraum >> sind doch ein großer Mist. > > Warum? Weil man bei 16 Bit-Adressen und 64 KB großen Blöcken immer den gesamten Adressraum auf einmal tauscht. Damit verliert man naturgemäß den Zugriff auf Daten, die in einem anderen Block liegen... Beispiel: Mit 4 KB-Blöcken gibt es 16 Blöcke im Adressraum. Ein Spiel kann das sinnvoll aufteilen: 1 Block für das Hauptprogramm und globale Variablen, 12 Blöcke für die Spieldaten und 3 Blöcke für Unterprogramme. Die Unterprogrammblöcke werden vom Hauptprogramm je nach Bedarf ein- und ausgeblendet. Damit hat jedes Unterprogramm vollen Zugriff auf die Spieldaten, das Spiel kann aber im Prinzip unbegrenzt viele Unterprogramme haben (und bei Bedarf sogar weitere von Diskette oder Festplatte nachladen). Außerdem hat jedes Unterprogramm zusätzlich lokalen Speicher zur Verfügung. Praktische Sache, sowas. Setzt aber eine flexible Banking-Logik voraus, die du nicht hast. Ein Texteditor würde z.B. 4 Blöcke für den Code und 12 Blöcke für die zu bearbeitende Datei reservieren. Da die Datei aber größer als 64 KB sein kann, schaltet der Code immer den gerade aktuellen Ausschnitt in die 12 Blöcke. Wie würdest du soetwas implementieren?
Uraltverkleider schrieb: > Josef G. schrieb: >> Ist dann halt keine 8-Bit-CPU > > Kann auch keine sein. > Sonst könnte man auch nicht >64kB linear adressieren. > Leuchtet Dir das ein? Warum fragst du? Was lässt dich daran zweifeln? S. R. schrieb: > Josef G. schrieb: >> Andreas S. schrieb: >>> 64 KByte große Blöcke bei nur 64 KByte Adressraum >>> sind doch ein großer Mist. >> >> Warum? > > Weil man bei 16 Bit-Adressen und 64 KB großen Blöcken immer den > gesamten Adressraum auf einmal tauscht. Damit verliert man natur- > gemäß den Zugriff auf Daten, die in einem anderen Block liegen... Bei mir nicht, zB. kann Register X auf die 64-KByte mit den alten Daten zeigen und Register Y auf die 64-KByte mit den neuen.
:
Bearbeitet durch User
Josef G. schrieb: > Bei mir nicht, zB. kann Register X auf die 64-KByte mit den alten > Daten zeigen und Register Y auf die 64-KByte mit den neuen. Das heißt, diese Register sind mindestens 17 Bit breit, oder du verschenkst Opcodes.
S. R. schrieb: > Josef G. schrieb: >> Bei mir nicht, zB. kann Register X auf die 64-KByte mit den alten >> Daten zeigen und Register Y auf die 64-KByte mit den neuen. > > Das heißt, diese Register sind mindestens 17 Bit breit, > oder du verschenkst Opcodes. Auf den Steuerleitungen wird angezeigt, ob eine ausgegebene Adresse von Register X kommt oder von Register Y. Eine externe Logik teilt beiden Registern unterschiedliche 64-K-Bereiche zu.
Josef G. schrieb: > Auf den Steuerleitungen wird angezeigt, ob eine ausgegebene > Adresse von Register X kommt oder von Register Y. Eine externe > Logik teilt beiden Registern unterschiedliche 64-K-Bereiche zu. Ach so. Das ist auf einem Z80 auch kein Problem. Dazu muss man nur die Präfixe für IX bzw. IY mitlesen (unter /M1 natürlich) und entsprechend der Banking-Logik mitgeben.
Bernd schrieb: > Aber zukunftssicher ich glaube, DIESES Wort kann man bei diesem Projekt getrost zur Seite lassen :-)
S. R. schrieb: > Ach so. Das ist auf einem Z80 auch kein Problem. Dazu muss man nur die > Präfixe für IX bzw. IY mitlesen (unter /M1 natürlich) und entsprechend > der Banking-Logik mitgeben. Es ist ja nicht zielführend, bei einem Selbstbauprojekt existierende Produkte anzuführen, die das auch könn(t)en. Wem hilft das? Dem Ego des Besserwissers? Ich frage mich eher, was jemanden dazu bewegt, in einem FPGA-Projekt absichtlich eine CPU mit Bankumschaltung zu designen? Da muss das Interesse schon sehr spezifisch sein. Aber ja, auch ein solches Interesse ist schlussendlich legitim!
Eddy C. schrieb: > Es ist ja nicht zielführend, bei einem Selbstbauprojekt existierende > Produkte anzuführen, die das auch könn(t)en. Wem hilft das? Dem Ego des > Besserwissers? Nein, es geht ja nicht darum, das Projekt "grundlos" zu kritisieren, sondern Josef behauptet ja, dass es viele technischen Konzepte so noch nie gegeben hätte. Und dies lässt sich anhand von Beispielen sehr leicht widerlegen. > Ich frage mich eher, was jemanden dazu bewegt, in einem FPGA-Projekt > absichtlich eine CPU mit Bankumschaltung zu designen? Da muss das > Interesse schon sehr spezifisch sein. Aber ja, auch ein solches > Interesse ist schlussendlich legitim! Dieses Interesse wäre durchaus legitim, wenn es wirklich nur um ein rein privates Projekt ginge. Josef versucht jedoch, Dritte zum Mitmachen zu animieren, und träumt von einer Implementierung der bo8-CPU in Silizium. Hierfür muss ein Projekt entweder so überzeugend sein, dass sich Dritte gerne daran beteiligen und ernsthafte Marktchancen sehen, oder man muss einfach sehr viel eigenes Geld einwerfen, um einen Chip herstellen zu lassen und/oder Entwickler zu beschäftigen.
Beitrag #5979914 wurde von einem Moderator gelöscht.
Wo kann man denn das Programm bekommen? Die weiter oben angegebene Homepage ist nicht erreichbar. Gruss Robert
:
Bearbeitet durch User
R. F. schrieb: > Die weiter oben angegebene Homepage ist nicht erreichbar. Klicke auf meine Benutzerseite rechts neben dem Benutzernamen.
Beitrag #5980173 wurde von einem Moderator gelöscht.
R. F. schrieb: > Wo kann man denn das Programm bekommen? > Die weiter oben angegebene Homepage ist nicht erreichbar. Vorsicht! Nach langen Diskussionen (siehe oben) hat Josef zwar Teile des Projektes unter die Creative-Commons-Lizenz gestellt, hierbei jedoch wesentliche Punkte vergessen. Durch die CC wird zwar u.a. die Weitergabe ermöglicht, und Josef ermuntert auf seiner Projekt-Homepage auch zum Herunterladen, aber er räumt Dritten keineswegs das Recht ein, die Dateien durch Herunterladen zu kopieren! Ich finde die Ähnlichkeiten zu "Marions Kochbuch" nämlich schon frappierend: Hierzu verweise ich auch die meine Ausführungen: Beitrag "Re: 8bit-Computing mit FPGA" Beitrag "Re: 8bit-Computing mit FPGA"
Ich wollte das eigentlich nur lesen. Ich habe noch ein Spartan3- kit und kann (vielleicht) das Webpack installieren (unter Linux), aber vielleicht nehme ich etwas vom OpenCore, da liegt reichlich herum. Der immer auftretende Nachteil: Man muss sich entscheiden. Robert
Andreas S. schrieb: > hierbei jedoch wesentliche Punkte vergessen. > ... > aber er räumt Dritten keineswegs das Recht ein, > die Dateien durch Herunterladen zu kopieren! ???
Josef G. schrieb: > ??? Diese ganze Lizens-Diskussion geht völlig an der Realität vorbei. Der bo8 ist ein Liebhaberprojekt und wenn der im Moment einzige Liebhaber nur starken Mundgeruch hätte, fände er vielleicht eine(n) Gleichgesinnte(n). Aber: -> Matthäus 7 Vers 7. Ich drücke ihm die Daumen!
Josef G. schrieb: > ??? Oh, offenbar war in meinem Webbrowser noch eine alte Version des Textes auf Deiner Homepage gecacht. Mittlerweile gibt es in der Tat nur noch den Verweis auf die CC-Lizenz, so dass der Download wohl auch halbwegs rechtssicher erfolgen kann. Damit können sich Dritte Dein Projekt zumindest schon einmal anschauen, aber der wirklich sinnvolle Schritt bestünde darin, es bei einem Dienst wie Github o.ä. in geeignet strukturierter Form bereitzustellen, damit auch Dritte darauf basierend ihre Beiträge veröffentlichen können. Irgendwelche ZIP-Dateien o.ä. auf privaten Homepages abzulegen wäre 1995 zwar noch der heißeste Scheiß gewesen, aber heutzutage reicht das nicht.
Andreas S. schrieb: > aber der wirklich sinnvolle Schritt bestünde darin den Unsinn hier komplett einzustampfen. Mach ihm doch keine Hoffnungen! Was soll das???
Reiner schrieb: > den Unsinn hier komplett einzustampfen. > Mach ihm doch keine Hoffnungen! Was soll das??? Welche Hoffnungen? Josef ignoriert doch schließlich alle konstruktiven Ratschläge und macht anschließend ziemlich genau das Gegenteil. Warum sollte er also daraus irgendwelche Hoffnung schöpfen?
Reiner schrieb: > Mach ihm doch keine Hoffnungen! Die Hoffnung stirbt bekanntlich zuletzt und nirgends sonst sind Wiederbelebungsversuche mit so geringem Aufwand möglich und 100%-ig erfolgreich…
Eddy C. schrieb: >> Ach so. Das ist auf einem Z80 auch kein Problem. Dazu muss man nur die >> Präfixe für IX bzw. IY mitlesen (unter /M1 natürlich) und entsprechend >> der Banking-Logik mitgeben. > > Es ist ja nicht zielführend, bei einem Selbstbauprojekt existierende > Produkte anzuführen, die das auch könn(t)en. Wem hilft das? Wenn Produkt A mit einer besonderen, einzigartigen Funktionalität XY beworben wird, dann ist ein Verweis auf ein vergleichbares Produkt B, was das so nebenbei auch kann, durchaus zielführend - finde ich. Vor allem, wenn Produkt B in so ziemlich allen anderen Kategorien objektiv unbestritten gewinnt. Das hat was mit der Wahl der Maßstäbe zu tun, nicht mit Besserwissertum.
S. R. schrieb: > Besserwissertum Auf den Lösungsansatz gebracht hat dich womöglich erst Josef selbst. Wo ist das Produkt B, von dem Du sprichst?
Eddy C. schrieb: > Auf den Lösungsansatz gebracht hat dich womöglich erst Josef selbst. Du liest hier seit 10min mit, oder doch schon länger? Tu Dir mal den gesammten Thread an. Das einzige worauf Josef hier jemanden bringt, ist sich einfach umzudrehen und zu gehen, weil es Menschen gibt die vollständig unberatbar sind und jedweder Argumentation unzugänglich. Diese völlig verkorkste Totgeburt hat doch erst wieder Fahrt aufgenommen seit über das Lizenzmodell gestritten wurde. Ansonsten informiert Josef uns alle paar Tage / Wochen mal über eine sinnlose Änderung von irgendwas um den Tread am Leben zu erhalten. 1119 Beiträge und nicht ein einziger hat jemals wirklich mit Josefs System gearbeitet. Ein paar haben sich das mal angeschaut. Jeder Versuch in irgendeiner Form Einfluss auf diese gelebte Katastrophe zu nehmen hat Josef immer weggelabert. Wohlgemerkt ein System das Josef für so genial einfach und übersichtlich hält, das es für 'jederman' das super duper Einstiegssystem zum lernen sein soll. Wie gesagt 1119 Beiträge, aber aus Josephs Zielgruppe war noch nicht ein einziger hier. Wie gerne würde ich diesen schlimmen Unfall aus 'Threads mit meinen Beiträgen' entfernen, weil ich mich doch immer wieder dazu hinreissen lassen mir den Schrott anzusehen.
Haha, hinreissen lassen, ja das stimmt wohl, da hängen ein paar in einer Tretmühle fest und ich will mich da nicht ausschliessen. Aber die Vehemenz, mit der manche Josef einreden wollen, dass alles Mist ist, grenzt an Irrsinn und ist auch dumm. Schweigen, lächeln und weggehen würde ich empfehlen.
Josef kann doch machen, was er will. Meine Güte. Wenn es ihm Spaß macht, dann soll er halt. Sachliche Kritik finde ich ja Ok. Aber solche Aussagen, dass das Projekt sinnlos wäre oder ähnliches, sind unangebracht. Es ist ein Hobbyprojekt. Das ist per Definition nicht sinnlos. (oder per Definition sinnlos. Je nachdem, wie man es sieht)
Eddy C. schrieb: > Aber die Vehemenz, mit der manche Josef einreden wollen, dass alles Mist > ist, grenzt an Irrsinn und ist auch dumm. Da redet man dem nichts ein. Das IST alles Mist. Über >1000 Beiträge in allen Details bis zum Erbrechen durchgekaut. Sinn einer technischen Diskussion ist der Meinungsaustasuch und fachliche Disput im Sinne der Verbesserung. Josef konzipiert das nicht als Hobby Spaß Projekt. Wäre das so würde keiner was sagen. Dumm ist es weiter mit Josef zu diskutieren. Da kann ich mit zwei Euro an den Parkautomaten gehen und habe einen nutzbringenderen Meinungsaustausch mit der blöden Kiste.
Angehängte Dateien:
-
ZeichenA.png
1002 Bytes -
ZeichenZ.png
1008 Bytes
Habe ein wenig am Aussehen des Zeichensatzes experimentiert. Zum Vergleich rechts die bisherige Version.
Josef G. schrieb: > Habe ein wenig am Aussehen des Zeichensatzes experimentiert. > Zum Vergleich rechts die bisherige Version. Michael K. schrieb: > Ansonsten informiert Josef uns alle paar Tage / Wochen mal über eine > sinnlose Änderung von irgendwas um den Tread am Leben zu erhalten. quod erat demonstrandum
Michael K. schrieb: > quod erat demonstrandum Nein. Vor meinem letzten Beitrag war der Thread ohnehin ganz oben, und man kann mir nicht vorwerfen, ich hätte den Beitrag nur gepostet um den Thread nach oben zu bringen. Ausserdem war es diesmal nicht ich, der den Thread nach oben geholt hat. Beitrag "Re: 8bit-Computing mit FPGA"
Josef G. schrieb: > Ausserdem war es diesmal nicht ich, > der den Thread nach oben geholt hat. Wenn das zukünftig immer häufiger der Fall wäre würdest Du damit einen Lerneffekt demonstrieren :-)
Eddy C. schrieb: >> Besserwissertum > Auf den Lösungsansatz gebracht hat dich womöglich erst Josef selbst. Das stimmt tatsächlich. Die von der bo8 präferierte Lösung ist nämlich sehr unüblich, tief in der Systemarchitektur (bzw. im Befehlssatz) integriert und bietet keine nennenswerten Vorteile gegenüber erprobten Alternativen. > Wo ist das Produkt B, von dem Du sprichst? Aus meiner Sicht wäre der Z80 das auf allen Ebenen siegende Konkurrenzprodukt, sowohl in der Breite als auch in der Nische. Andere mögen stattdessen 6502 oder 6809 auf der Siegesstraße sehen. Josef G. schrieb: > Habe ein wenig am Aussehen des Zeichensatzes experimentiert. Ich habe jetzt ein paar Minuten auf die Bilder gestarrt und sehe bis auf die Hintergrundfarbe keinen Unterschied. Dafür fällt mir gerade auf, dass dein Zeichensatz ausschließlich für Englisch und (eingeschränkt) Deutsch geeignet ist. Der Name André lässt sich z.B. überhaupt nicht darstellen.
S. R. schrieb: > sehe bis auf die Hintergrundfarbe keinen Unterschied. Siehe a b d u v ä ü ' U V Ü > Der Name André lässt sich z.B. überhaupt nicht darstellen. Ist halt ein 7-Bit-Zeichensatz. Unicode ist auf einem 8-Bit-Rechner nicht machbar. Immerhin liegen die Zeichen ä ö ü ß Ä Ö Ü Sigma im RAM und sind als veränderlich konzipiert.
Josef G. schrieb: > Unicode ist auf einem 8-Bit-Rechner nicht machbar. Gemeint war: Ein kompletter Unicode-Zeichensatz ist auf einem 8-Bit-Rechner nicht machbar.
Josef G. schrieb: > Gemeint war: Ein kompletter Unicode-Zeichensatz > ist auf einem 8-Bit-Rechner nicht machbar. Ein kompletter 8-Bit-Zeichensatz wie ISO8859-1 oder ISO8859-15 ist relativ einfach machbar. Dieser beinhaltet zumindest alle westeuropäischen Sonderzeichen und ist weitgehend identisch mit Windows-1252 (aka CP1252) bzw. mit dem DEC-Multinational Character Set. In den Bereichen 128-159 (0x80-0x9F) kannst Du Dich dann noch austoben.
:
Bearbeitet durch Moderator
Josef G. schrieb: > Gemeint war: Ein kompletter Unicode-Zeichensatz > ist auf einem 8-Bit-Rechner nicht machbar. Mit solchen Zeichensätzen betreibt man im Allgemeinen kein exzessives "Numbercrunching", so dass es egal ist, ob die Zugriffe auf einzelne Zeichen aus einem oder mehreren Befehlen bestehen. Nur bei aufwändigen Textsuchen kann so etwas leistungsbegrenzend sein. Falls die Architektur Deines bo8 jedoch so scheiße sein sollte, dass es dadurch bedingt einen handfesten Grund geben sollte, warum sich keine Datentypen mit mehr als der Registerbreite verarbeiten lassen, dann es da eine massive Schwäche und kein Leistungsmerkmal. Mit einem Z80 o.ä. wäre es überhaupt kein Problem, auch UTF-16 und Konsorten zu verarbeiten. Und auch auf jedem Atmel AVR kann man in C munter mit größeren Datentypen (16 Bit, 32 Bit) arbeiten, ggf. sogar mit Fließkommatypen. Das wird eben nur bei der Ausführung entsprechend langsam.
Josef G. schrieb: >> sehe bis auf die Hintergrundfarbe keinen Unterschied. > Siehe a b d u v ä ü ' U V Ü Also nur ein paar geänderte Pixel. Danke für die Erklärung. >> Der Name André lässt sich z.B. überhaupt nicht darstellen. > Ist halt ein 7-Bit-Zeichensatz. Gibt es dafür einen bestimmten Grund? > Unicode ist auf einem 8-Bit-Rechner nicht machbar. Die Verarbeitung ist problemlos machbar, das Rendering hängt (wie bei allen Systemen) vom vorhandenen Font ab. Es spricht also nichts dagegen. Aber das meinte ich garnicht. Was hindert dich daran, einen vollen 8-Bit-Zeichensatz zu benutzen? Die üblichen Codepages für Westeuropa (CP850 oder iso8859-1) wären sowohl angemessen als auch vollkommen ausreichend. > Immerhin liegen die Zeichen ä ö ü ß Ä Ö Ü Sigma > im RAM und sind als veränderlich konzipiert. Die anderen nicht? Für Schwedisch braucht man mindestens ä ö å ü und é (letztere kommen recht häufig in Namen vor), das wäre also schonmal prinzipiell unmöglich. Obwohl es eigentlich kein großer Unterschied ist.
S. R. schrieb: > üblichen Das ist das relevante Schlüsselwort. Josef vermeidet konsequent übliche, erprobte Vorgehensweisen, um dadurch die Vergleichbarkeit seines Projektes mit anderen erfolgreichen und erfolglosen Ansätzen zu erschweren.
Andreas S. schrieb: > S. R. schrieb: >> üblichen > > Das ist das relevante Schlüsselwort. Josef vermeidet konsequent übliche, > erprobte Vorgehensweisen, um dadurch die Vergleichbarkeit seines > Projektes mit anderen erfolgreichen und erfolglosen Ansätzen zu > erschweren. Man sollte den Thread löschen oder zumindest sperren. Mehr als Gezanke gibts hier nicht!
Andreas S. schrieb: > Josef vermeidet konsequent übliche, > erprobte Vorgehensweisen, um dadurch die Vergleichbarkeit seines > Projektes mit anderen erfolgreichen und erfolglosen Ansätzen zu > erschweren. Das ist die hohe Kunst, aus der Not eine Tugend zu machen…
S. R. schrieb: > Josef G. schrieb: >> Ist halt ein 7-Bit-Zeichensatz. > > Gibt es dafür einen bestimmten Grund? Es spart im ROM Speicherplatz, wenn man nur 128 Zeichen hat. Und Bit-7 steht für Unterstreichen zur Verfügung. > Was hindert dich daran, einen vollen 8-Bit-Zeichensatz > zu benutzen? Die üblichen Codepages für Westeuropa > (CP850 oder iso8859-1) wären sowohl angemessen > als auch vollkommen ausreichend. Warum nicht auch Kyrillisch? Man muss irgendwo eine Grenze ziehen, sonst landet man beim vollen Unicode-Zeichensatz, der im ROM zu viel Platz braucht. Und ich habe mich für die minimalistische Lösung entschieden.
Josef G. schrieb: > Warum nicht auch Kyrillisch? Kyrillisch ist nicht in ISO8859-1 enthalten. > Man muss irgendwo eine Grenze > ziehen, sonst landet man beim vollen Unicode-Zeichensatz, ISO8859-x ist kein Unicode, sondern enthält ausschließlich Zeichen mit einem Byte Länge, wohingegen schon bei UTF-8 bis zu vier Byte pro Zeichen auftreten können. > der im ROM zu viel Platz braucht. Und ich habe mich > für die minimalistische Lösung entschieden. ISo8859-x benötigt nicht mehr Platz. Die einzige Einschränkung besteht darin, dass unterstrichene Zeichen nicht im Zeichensatz enthalten sind. Es ist ohnehin eine katastrophale Fehlentscheidung, unterstrichene Zeichen als eigenständige Zeichen zu sehen. Wollte man nämlich einen bo8h als "richtigen Computer" verwenden, müsste man solche Krücken z.B. bei Textsuchfunktionen berücksichtigen. Inkompatibler geht es kaum noch. Selbst mit EBCDIC könnte man sich eher noch anfreunden.
Andreas S. schrieb: > Kyrillisch ist nicht in ISO8859-1 enthalten. Eben. > ISo8859-x benötigt nicht mehr Platz. Wenn da 256 verschiedene Zeichen darzustellen sind, dann belegen die Pixelmuster im ROM mehr Platz als wenn es nur 128 verschiedene Zeichen sind. Oder wie sonst sollte das gehen? > Inkompatibler geht es kaum noch. Kompatibilität zu irgendetwas war nicht mein Ziel. Siehe hexadezimaler Ziffernsatz.
Josef G. schrieb: > Kompatibilität zu irgendetwas war nicht > mein Ziel. Siehe hexadezimaler Ziffernsatz. Und dann träumst Du noch davon, dass irgendjemand bereit wäre, Deinen Prozessor in Silizium zu gießen? Oder ihn für irgendein reales Projekt einzusetzen?
Andreas S. schrieb: > Und dann träumst Du noch davon, dass irgendjemand bereit wäre, Deinen > Prozessor in Silizium zu gießen? Oder ihn für irgendein reales Projekt > einzusetzen? Und wo genau ist das Problem?
Josef G. schrieb: >>> Ist halt ein 7-Bit-Zeichensatz. >> Gibt es dafür einen bestimmten Grund? > Es spart im ROM Speicherplatz, wenn man nur 128 Zeichen > hat. Und Bit-7 steht für Unterstreichen zur Verfügung. Ich wüsste jetzt nicht, warum man unbedingt an der Stelle die Bits sparen muss. Und selbst dann wäre es sinnvoller, einen vollen 8 Bit-Zeichensatz anzubieten und bei totaler Armut nur 7 Bit zu bestücken. Unterstreichen ist von den drei üblichen Attributen aus Anwendersicht ohnehin das ungeeignetste: Es verschlechtert die Lesbarkeit. Ein doppelter Zeichensatz (normal/kursiv oder normal/fett) wäre sinnvoller gewesen, und wenn man aus Armutsgründen nicht bestückt, bleibt das System trotzdem sinnvoll einsetzbar. Josef G. schrieb: > Warum nicht auch Kyrillisch? Verglichen mit deinem jetzigen Zeichenvorrat ist der Nutzen eines westeuropäischen Zeichensatzes größer als der eines kyrillischen Zeichensatz, selbst bei gleichen Kosten. Beides wäre natürlich zu bevorzugen. Josef G. schrieb: > Kompatibilität zu irgendetwas war nicht > mein Ziel. Siehe hexadezimaler Ziffernsatz. Vielleicht solltest du etwas an der Zielstellung feilen.
Vielleicht könnte jemand einen Forth-Interpreter für die bo8 schreiben. Forth kriegt man eigentlich fast überall zum laufen.
Josef G. schrieb: > Und ich habe mich für die minimalistische Lösung entschieden. Die Zeiten, wo man Kompromisse auf Kosten der Lesbarkeit von Displaytexten machen musste, sind glücklicherweise längst vorbei. Du hätschelst also eine Not, die keine mehr ist und erklärst sie dann auch noch zur Tugend…
Andreas S. schrieb: > Es ist ohnehin eine katastrophale Fehlentscheidung, unterstrichene > Zeichen als eigenständige Zeichen zu sehen. Um es Josef nochmal zu erklären: du mischst die Zeichencodierung mit der Zeichendarstellung – erstere betrifft die externe Darstellung der Zeichen, letztere ist eine rein interne Angelegenheit der Zeichendarstellung auf einem Display. Du mischst also zwei Ebenen, die schon sehr früh in der Hardwareentwicklung getrennt wurden, um die Interoperabilität der Geräte zu garantieren. Das ist eine ausgesprochen kurzsichtige Designentscheidung.
Uhu U. schrieb: > Das ist eine ausgesprochen kurzsichtige Designentscheidung. Nein. Es ist eine legitime Designentscheidung, die das Design wesentlich vereinfacht.
S. R. schrieb: > Ich wüsste jetzt nicht, warum man unbedingt > an der Stelle die Bits sparen muss. Es sind nicht nur "Bits". Bei mir belegen die Pixelmuster der 128 Zeichen im ROM 1 KByte. Bei 256 Zeichen wären es 2 KByte.
Josef G. schrieb: > Bei mir belegen die Pixelmuster der 128 Zeichen > im ROM 1 KByte. Bei 256 Zeichen wären es 2 KByte. Ich wüsste jetzt trotzdem nicht, was daran real ein Vorteil ist. Einerseits muss das Zeichen-ROM nicht in den Adressraum gemappt werden, andererseits hast du durch dein Architekturdesign ohnehin mehr einfach nutzbaren Adressraum als vergleichbare Systeme. Ein 8 Bit-Design auf 7 Bit zu beschränken ist einfacher, als ein 7 Bit-Design auf 8 Bit zu erweitern. Aber das weißt du sicherlich auch.
S. R. schrieb: > Einerseits muss das Zeichen-ROM nicht > in den Adressraum gemappt werden, Bei mir schon, weil es keinen Hardware-Zeichengenerator gibt und die CPU selber die Pixelmuster ins Video-RAM schreibt. Der Zeichensatz belegt 1 der 32 KByte des Hauptplatinen-ROM.
:
Bearbeitet durch User
Josef G. schrieb: > Bei mir schon, weil es keinen Hardware-Zeichengenerator gibt > und die CPU selber die Pixelmuster ins Video-RAM schreibt. Warum tust du dann die Pixelmuster nicht einfach ins RAM? Den gewünschten Kompromiss zwischen RAM-Verbrauch und Zeichensatz kann die Anwendung dann selbst vornehmen.
S. R. schrieb: > Warum tust du dann die Pixelmuster nicht einfach ins RAM? Versteh ich jetzt nicht, wie du das meinst. Die Pixelmuster müssen ja nach Power Up irgendwo herkommen und deshalb im ROM stehen. Die CPU kopiert die Muster dann für den darzustellenden Text ins Video-RAM. Der Video-Generator liest ständig das Video-RAM als Grafik aus und sendet es zum Monitor.
Josef G. schrieb: > Versteh ich jetzt nicht, wie du das meinst. Angefangen hat es mit: Josef G. schrieb: >> Der Name André lässt sich z.B. überhaupt nicht darstellen. > Ist halt ein 7-Bit-Zeichensatz. Und ich bin davon ausgegangen, dass das in deiner Hardware so vorgegeben ist. Wenn das ein reines Softwareproblem ist... Josef G. schrieb: > Die Pixelmuster müssen ja nach Power Up > irgendwo herkommen und deshalb im ROM stehen. Was hindert dich daran, einfach ein größeres ROM zu nehmen?
S. R. schrieb: > Was hindert dich daran, einfach ein größeres ROM zu nehmen? Weil selbst Josef eingesehen hat daß hier alles dermaßen wurscht ist.
PS: Mit ROM war hier gemeint das ROM im angestrebten Fertig-Gerät. In der Prototyp-Realisierung auf den FPGA-Boards ist natürlich alles RAM und erhält seinen Inhalt beim Konfigurations-Prozess.
Josef G. schrieb: > Mit ROM war hier gemeint das ROM im angestrebten Fertig-Gerät. Meinst Du damit einen "echten" bo8(h)-Prozessor als kundenspezifisches IC? Dieses IC wird es niemals geben. Kein Investor wäre bereit, auch nur einen Cent für solch einen Baustein vorzustrecken. Alternativ könntest Du natürlich Deine Ersparnisse dafür opfern, wovon Dir aber auch jeder abraten würde.
Beitrag #5988072 wurde von einem Moderator gelöscht.
Andreas S. schrieb: > Dieses IC wird es niemals geben. Kein Investor wäre bereit, auch nur > einen Cent für solch einen Baustein vorzustrecken. Ich empfehle crowd founding! Dort findet sich ein Investment-pool für jeden Scheiss!
K. L. schrieb: > Ich empfehle crowd founding! Dort findet sich ein Investment-pool für > jeden Scheiss! Nö, nur für gut präsentierten Scheiß. Und daran dürfte es bei Josef scheitern.
--------------------------------------------------------------------- Bei mir schon, weil es keinen Hardware-Zeichengenerator gibt und die CPU selber die Pixelmuster ins Video-RAM schreibt. --------------------------------------------------------------------- So macht es der Schneider CPC auch. Baujahr 1985. Josef G. dann hast du ja eine Lizenz geraubt. Bezahlst du dafür Lizenzgebühren ? An deiner Stelle würde erst mal prüfen, was du noch für weitere Produkte unerlaubt benutzt hast.
----------------------------- Gemeint war: Ein kompletter Unicode-Zeichensatz ist auf einem 8-Bit-Rechner nicht machbar. ---------------------------- Natürlich gibt es den beim VC20. Auf dem VC20 kannst du über 1500 Zeichen realisieren.
peter schrieb: > Auf dem VC20 kannst du über 1500 Zeichen realisieren. Mit Hilfe eines hochintegrierten Spezialchips.
Josef G. schrieb: > Mit Hilfe eines hochintegrierten Spezialchips. Den du nicht brauchst, weil du Vollgrafik hast. Damit kannst du unbegrenzt viele verschiedene Zeichen anbieten... also das gesamte Unicode. Die Verarbeitung ist sowieso unabhängig von der Bitbreite.
Josef G. schrieb: > Mit Hilfe eines hochintegrierten Spezialchips. Das geht natürlich gar nicht. Erlaubt sind nur reine FPGAs ;-)
SDRAM ist immer wieder mal ein Thema: Beitrag "Re: C64 auf Cyclone II" Dabei hab sogar ich es hingekriegt, SDRAM zu verwenden. Keine Burst-Zugriffe, sondern Einzelwort-Zugriffe, und Refresh während der inaktiven Halbzyklen der CPU ohne Störung des streng brechenbaren CPU-Timings.
Angehängte Dateien:
-
EP4CE10.jpg
200 KB
Es gibt nun auch eine Realisierung auf dem OpenEP4CE10-Board von Waveshare. Angesteckt sind die Module SDRAM-B, VGA-PS2, SD-Card/Micro-SD-Card, RS232, 4-digit-8-segment-LED-Display. Das Board ist erhältlich beim Distributor Eckstein. Auf dem Board ist ein Cyclone IV, der auch vom neuesten Quartus unterstützt wird. Vorteil gegenüber dem DE0-nano ist, dass man kein spezielles 5.4-Volt-Netzteil braucht. Erforderlich ist eine PS2-Tastatur, die mit 3.3 Volt funktioniert, andernfalls muss man ein wenig basteln. Im User-Manual zum alten Nexys2 habe ich die Aussage gefunden: Most PS/2 devices can operate from a 3.3V supply, but older devices may require a 5V DC supply. VHDL-Dateien und Assignments gibt es im Download-File meiner Website, eine Beschreibung steht auf der Seite Hardware des Download-Files. Diese Seite habe ich gründlich überarbeitet. http://www.bo8h.de
:
Bearbeitet durch User
Josef's Dauer-Panik vor dem Vergessenwerden. Penetrante Aufmerksamkeits-Kampf mit aussichtslosem Technik-Krampf. Uralten Käse immer wieder mit frischem Datum zu versehen- das grenzt ja fast an Betrug :)
Adam schrieb: > das grenzt ja fast an Betrug :) So ein Unsinn. Josef hat ein Hobbyprojekt. Josef hat Spaß dran. Josef teilt es mit anderen Leuten. Wo ist nun dein Problem? Es Betrug zu nennen ist eine Unverschämtheit.
MaWin schrieb: > Josef hat Spaß dran Aus soviel Postings ohne positive Resonanz spricht eher Verzweiflung, wenn nicht Schlimmeres. > Josef teilt es mit anderen Leuten mit wem? mit Dir etwa? > Es Betrug zu nennen lern erst mal lesen
Es scheint immerhin noch zwei PS2-Tastaturen zu geben, die neu erhältlich sind: Perixx PERIBOARD-107 und PERIBOARD-409 P. Allerdings brauchen sie laut Datenblatt 5 Volt, dann hätten sie keinen Vorteil gegenüber USB-Tastaturen mit Adapter. Kann aber sein, dass sie nur deshalb mit 5 Volt spezifiziert sind, weil sie mit 3.3 Volt die Ausgangspegel für die PS2-Signale nicht erreichen, aber das sollen sie ohnehin nicht. Man müsste es ausprobieren. Auf dem VGA-PS2-Modul von Waveshare sind die Leitungen für Vcc, PS2-clk und PS2-data zugänglich. Man kann sie auftrennen, an der PS2-Buchse 5 Volt anschließen und in PS2-clk und PS2-data Spannungsteiler einbauen (sie werden FPGA-seitig nur gelesen). Aber eigentlich sind PS2-Tastaturen für das Projekt ohnehin nur ein Notbehelf. Besser und viel einfacher wäre eine spezielle Tastatur, die nicht Scan-Codes liefert, sondern gleich die 128 Zeichencodes. Ein nachfolgendes neuntes Bit bliebe dann so lange aktiv, bis die Taste losgelassen wird. Es folgt der Ruhepegel bis zum nächsten Startbit. Die Festlegung der Repeat-Frequenz und ob überhaupt ein Auto-Repeat aktiv ist, bleibt dann dem Hauptgerät überlassen. Gleichzeitiges Drücken von zwei oder mehr Tasten ist nicht vorgesehen mit Ausnahme der Shift-Taste, und die würde vom Tastaturcontroller ausgewertet.
:
Bearbeitet durch User
Josef G. schrieb: > Es scheint sich wieder mal keine Sau für Deine belanglosen Verlautbarungen zu interessieren. Sag mal, redest Du oft mit Dir selbst?
Josef G. schrieb: > Allerdings brauchen sie laut Datenblatt 5 Volt, dann hätten sie > keinen Vorteil gegenüber USB-Tastaturen mit Adapter. Es gibt keine für 3.3V spezifizierten PS/2-Tastaturen, denn PS/2 ist für 5V spezifiziert. Also wird auch kein Hersteller volle Funktionsfähigkeit bei 3.3V garantieren. Josef G. schrieb: > Aber eigentlich sind PS2-Tastaturen für das Projekt ohnehin nur ein > Notbehelf. Besser und viel einfacher wäre eine spezielle Tastatur, > die nicht Scan-Codes liefert, sondern gleich die 128 Zeichencodes. Das artet in relativ viel mechanischer Handarbeit aus. Du kannst ja mal deine Referenztastatur posten (Schaltung und Bild) und sagen, ob man damit gut arbeiten kann. Eine von mir aus Holz geschnitzte Tastatur wäre auf jeden Fall schlechter als die alte PS/2-Tastatur im Schrank. Josef G. schrieb: > Gleichzeitiges Drücken von zwei oder mehr Tasten ist nicht > vorgesehen mit Ausnahme der Shift-Taste, und die würde > vom Tastaturcontroller ausgewertet. Das ist mal wieder große Scheiße.
René schrieb: > sich wieder mal keine Sau für Deine belanglosen Verlautbarungen zu > interessieren. Sag mal, redest Du oft mit Dir selbst? Warum machst Du Josef hier dumm an? Josef ist ganz bestimmt nicht doof - maximal vielleicht etwas speziell. Ich sehe es so wie MaWin (Beitrag "Re: 8bit-Computing mit FPGA"). Wen es nicht interessiert, der muß hier ja nicht mit lesen.
Nicht W. schrieb: > Josef sollte eine Auszeichnung erhalten. Wofür denn? Allenfalls für konsequente Bewohnung eines Wolkenkuckucksheims.
Gustav schrieb: > Wofür denn? Für sein Sitzfleisch und seine Sturheit. Beides dürfte so ziemlich unübertroffen sein. Zeno schrieb: > Josef ist ganz bestimmt nicht doof - maximal vielleicht etwas speziell. Da hast du Recht. MaWin schrieb: > Josef hat ein Hobbyprojekt. Ohne jeden Zweifel. > Josef hat Spaß dran. Schwer zu beurteilen, ob das Spaß oder Verbohrtheit ist. Ich vermute, dass das Gleichgewicht im Kontinuum Spaß <-> Verbohrtheit stark rechts liegt… > Josef teilt es mit anderen Leuten. Das würde er gerne. Nur steht er sich dabei selbst im Weg.
S. R. schrieb: > Es gibt keine für 3.3V spezifizierten PS/2-Tastaturen, Leider sind auf dem Waveshare VGA-PS2-Modul die Leitungen für 3.3 Volt, PS2-Clk, PS2-Data einfach zwischen Stiftleiste und PS2-Buchse durchverdrahtet. Ein Anschluss von 5 Volt und Pegelwandlung für die beiden Signale sind nicht vorgesehen. Offenbar sind die Konstrukteure des Moduls auch davon ausgegangen, dass viele PS2-Tastaturen inoffiziell mit 3.3 Volt funktionieren, so wie oben von mir geschrieben: Josef G. schrieb: > Im User-Manual zum alten Nexys2 habe ich die Aussage > gefunden: Most PS/2 devices can operate from a 3.3V > supply, but older devices may require a 5V DC supply. Meine Easy Line ET100 funktioniert problemlos an 3.3V. Leider ist sie neu nicht mehr erhältlich.
Uhu U. schrieb: > Josef teilt es mit anderen Leuten. > > Das würde er gerne. Nur steht er sich dabei selbst im Weg. Nein. Das Projekt selbst taugt schon für nichts, außer als Aufhängepunkt endloser Diskussion. Die damit verbundene Hoffnung, es möge irgendwann als etwas praktisch sinnvolles erkannt werden wird zwar auf immer unerfüllt bleiben, aber so ein Plätzchen an vorderer Stelle der Projekte-Rubrik täuscht ihm wenigstens ein bischen Wichtigkeit vor.
Roman H. schrieb: > Das Projekt selbst taugt schon für nichts, außer als Aufhängepunkt > endloser Diskussion. Als Hobby-Projekt gehts durch. Nur die Hoffnung, damit "ganz groß raus zu kommen" ist etwas naiv.
peter schrieb: > So macht es der Schneider CPC auch. Baujahr 1985. > Josef G. dann hast du ja eine Lizenz geraubt. Bezahlst du dafür > Lizenzgebühren ? Das dürfte wohl kaum noch unter einem Patent stehen. Weil dann muss jeder heutige GraPro Lizenzgebüren zahlen :-)
Man könnte eine Tastatur mit Hilfe des 3D-Druckers machen: https://3druck.com/objects/3d-druck-design-funktionsfaehige-tastatur-einstellbare-linse-und-escher-cookies-aus-dem-3d-drucker-069317/
Josef G. schrieb: >> Es gibt keine für 3.3V spezifizierten PS/2-Tastaturen, > > Offenbar sind die Konstrukteure des Moduls auch davon > ausgegangen, dass viele PS2-Tastaturen inoffiziell mit > 3.3 Volt funktionieren, so wie oben von mir geschrieben: Das mag sein. Dennoch ist PS/2 nie für 3.3V standardisiert worden, dementsprechend wird es keinen Tastaturhersteller geben, der unter diesen Bedingungen die volle Funktionsfähigkeit garantiert. Finde ich jetzt aber nicht so tragisch. Gibt schlimmeres in deinem Design. Wesentlich schlimmeres.
Uhu U. schrieb: > Beitrag "diskreter uC (und er funktioniert sogar)" Und? Ein Hinweis auf ein tolles Projekt, während meines Mist ist?
Josef G. schrieb im Beitrag #60
> Und? Ein Hinweis auf ein tolles Projekt, während meines Mist ist?
So ist es. Nachgewiesenermaßen :)
Josef, Du wirst doch nicht nach all der Zeit der offenen Ablehnung und teils überzogener Kritik... Der Link von Uhu soll wohl ein Hinweis drauf sein, dass der Erbauer der diskreten CPU, die sogar funktioniert, durch seine selbstironische Weise gute Resonanz für sein Projekt erhalten hat. Mal sehr wohlwollend gedeutet.
Josef G. schrieb: > Uhu U. schrieb: >> Beitrag "diskreter uC (und er funktioniert sogar)" > > Und? Ein Hinweis auf ein tolles Projekt, während meines Mist ist? Die Projekte sind überhaupt nicht vergleichbar. Das eine ist eine praktisch unbenutzbare undokumentierte CPU mit wenigen Bits RAM. Das andere ist eine praktisch unbenutzbare fast undokumentierte CPU mit wesentlich größerer Leistung. Beide sind nicht praktisch brauchbar. Aber beide sind Hobbyprojekte und damit vollständig legitim. Habt Spaß!
Beitrag #6022445 wurde von einem Moderator gelöscht.
Tom schrieb im Beitrag #6022445: > MaWin schrieb: >> Habt Spaß! > > Du hast noch nicht begriffen dass der Spass seit langem nur noch in > vorderer Projektthread Platzierung besteht. Nein, Tom - Du hast nicht begriffen dass Dich das nichts angeht. Das Forum gehört Andreas und solange er nicht zu Josef sagt, dass er sein Projekt hier nicht haben will, darf Josef es hier vorstellen. Ob Du das gut findest oder nicht, spielt keine Rolle - leb damit.
Maik schrieb: > Josef G. schrieb im Beitrag #60 >> Und? Ein Hinweis auf ein tolles Projekt, während meines Mist ist? > > So ist es. Nachgewiesenermaßen :) Was soll der Scheiß? Ich hab das Teil sicher nicht als Schwanzvergleich, oder zum Vergleich mit anderen Projekten gebaut
Josef G. schrieb: > Uhu U. schrieb: >> Beitrag "diskreter uC (und er funktioniert sogar)" > > Und? Ein Hinweis auf ein tolles Projekt, während meines Mist ist? So ein Schmarrn! Wenn du wüstest, wie viel Mist ich bei meinem Teil verbockt hab. Mach einfach weiter mit deinem Projekt, wenns dir Spaß macht. Dazu sind Projekte schließlich da. Und um nicht in Langeweile zu versinken.
Josef G. schrieb: > Uhu U. schrieb: >> Beitrag "diskreter uC (und er funktioniert sogar)" > > Und? Ein Hinweis auf ein tolles Projekt, während meines Mist ist? Nein, darum geht es doch nicht. Es geht vielmehr nur um die Anspruchshaltung: - Du behauptest, Dein bo8 sei gut für Einsteiger geeignet und es gäbe sogar einen Markt für ein entsprechendes IC. Diejenigen, die einen Blick auf die von Dir wie Sauerbier angepriesenen Projektdateien geworfen haben, wenden sich aber irgendwann auf Grund der Unbrauchbarkeit und Deiner Unbelehrbarkeit ab. - Klosskopf hat das Teil nur für sich selbst gebaut. Interessanterweise interessieren sich nun recht viele Leute dafür und drängen sogar auf Veröffentlichung der Unterlagen. Niemand erwartet jedoch, damit einen sinnvoll anwendbaren Computer bauen zu können.
Andreas S. schrieb: > Diejenigen, die einen Blick auf die ... > Projektdateien geworfen haben, wenden sich aber > irgendwann auf Grund der Unbrauchbarkeit ... ab. Diese Behauptung ist neu. Wieso sind sie unbrauchbar? Oder meinst du nicht die VHDL-Dateien, sondern die Doku?
:
Bearbeitet durch User
Josef G. schrieb: > Andreas S. schrieb: >> Diejenigen, die einen Blick auf die ... >> Projektdateien geworfen haben, wenden sich aber >> irgendwann auf Grund der Unbrauchbarkeit ... ab. > > Diese Behauptung ist neu. Nein. > Wieso sind sie unbrauchbar? > > Oder meinst du nicht die VHDL-Dateien, sondern die Doku? Du hast den wesentlichen Punkt bei Deinem Zitat unterschlagen: >> irgendwann auf Grund der Unbrauchbarkeit und Deiner >> Unbelehrbarkeit
Thread beobachten
Seitenaufteilung abschaltenBitte 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.