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.
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.
Nicht W. schrieb:> Dokumentation in LatexS. 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.
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.
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!
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.)
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.
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 :)
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".
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.
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
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!
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.
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…
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. :-)
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.
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"
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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
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.
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.
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 :-)
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.
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ß!
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?
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
