mikrocontroller.net

Forum: Projekte & Code 8bit-Computing mit FPGA


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Bernd (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Maik (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: Sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Bernd (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Edi M. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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 
?

Autor: Tim (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Nicht W. (nichtsowichtig)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Nicht W. schrieb:
> Für Wissbegierige ist der bo8 wie ein 6000er für den Bergsteiger.

Vielleicht schreibt ja mal jemand eine verbesserte Dokumentation.

Autor: Nicht W. (nichtsowichtig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Vielleicht schreibt ja mal jemand eine verbesserte Dokumentation.

Du kannst ja ein Wiki aufsetzen...

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: Steffen (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :)

Autor: Manfred F. (manfred_f)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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?

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich habe sowas mit einem Z80 gemacht

Wie groß war der Adressraum für die Karten-Software?

Autor: Steffen (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Jungs, heute ist Freitag! Lö lö lö :)

Autor: malsehen (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Schön, wie Haliigqualli's
scheiß geheipt wird, während Josef
was vorzuzeigen hat!

Autor: VersuchMachtKluch (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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!

Autor: Nicht W. (nichtsowichtig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr guter Einwand! Nur sollte man da aufpassen welche Rechte bereits 
vergeben wurden.

Autor: VersuchMachtKluch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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).

Autor: Dr. Besser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: HexMax (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Nicht W. (nichtsowichtig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nicht W. schrieb:
> 5€ Essen/Tag + Dusch-/Schlafmöglichkeit

Kann ich beides leider nicht bieten.

Autor: Sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Linge (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Uhu U. (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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"

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Ive (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Glaubst du, dass das folgende frei erfunden ist?

Ja.

Autor: Route 6. (route_66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Route 6. (route_66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?"

Autor: Jeff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jeff schrieb:
> Aber aus purer Anwendungssicht sind das
> heutzutage allesamt Fehlkonstruktionen.

Das Leben auch.

Autor: Jeff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Mr.Sam (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Manfred F. (manfred_f)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Manfred F. schrieb:
> Wenn Josef wenigstens was tolles, elegantes geschaffen hätte.

Eleganz lässt sich nur im Vergleich mit Nicht-Eleganz beurteilen.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Klaus Banaus (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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!

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Banaus (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Klaus Banaus (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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...

Autor: Klaus Banaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Bernd (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wer portiert denn mal den Dhrystone auf bo8?
https://de.wikipedia.org/wiki/Dhrystone

Achso, dafür braucht man erstmal einen C-Compiler...

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Gugelhupf (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Uhu U. (uhu)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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
Autor: Uhu U. (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Klaus Banaus (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Lost in space (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: FFlarsen (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: FFlarsen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Uraltverkleider (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: Roland F. (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Uraltverkleider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: K. L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd schrieb:
> Aber zukunftssicher

ich glaube, DIESES Wort kann man bei diesem Projekt getrost zur Seite 
lassen :-)

Autor: Eddy C. (chrisi)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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!

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Nein, es geht ja nicht darum, das Projekt "grundlos" zu kritisieren

Schade.

Wäre gerne dabei!

Autor: R. F. (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo kann man denn das Programm bekommen?
Die weiter oben angegebene Homepage ist nicht erreichbar.

Gruss

Robert

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
R. F. schrieb:
> Die weiter oben angegebene Homepage ist nicht erreichbar.

Klicke auf meine Benutzerseite rechts neben dem Benutzernamen.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> R. F. schrieb:
> Die weiter oben angegebene Homepage ist nicht erreichbar.
>
> Klicke auf meine Benutzerseite rechts neben dem Benutzernamen.

Nein

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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"

Autor: R. F. (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andreas S. schrieb:
> hierbei jedoch wesentliche Punkte vergessen.
> ...
> aber er räumt Dritten keineswegs das Recht ein,
> die Dateien durch Herunterladen zu kopieren!

???

Autor: Uhu U. (uhu)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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!

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reiner (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Andreas S. schrieb:
> aber der wirklich sinnvolle Schritt bestünde darin

den Unsinn hier komplett einzustampfen.
Mach ihm doch keine Hoffnungen! Was soll das???

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: Uhu U. (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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…

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.