gelangweilt schrieb: > hey, soll ich hier zu meiner belustigung auch ein tagebuch meiner > eigenen projekte aufmachen? egal obs jemand interessiert? wenn das jeder > macht?! Mach doch. Hauptsache dir machts Spaß.
Habe beim S3A und S3E Starter den Anschluss für die SD-Karte verlegt an die untere Ecke des Boards. Dadurch ist jetzt der Hirose-Stecker für die Erweiterungs-Karte besser zugänglich. Die Schnittstelle für die Erweiterungskarte habe ich überarbeitet. Ich meine, sie ist jetzt vorzeigbar. Siehe auf der Projekt-Website Seite Hawa unten. Es besteht Pin-Kompatibilität zwischen den drei Xilinx-Boards (S3A-Starter, S3E-Starter, Nexys2). Für Kompatibilität mit dem DE1 Board bräuchte man lediglich einen mechanischen Adapter. Es wurde mir in diesem Thread vorgehalten, dass mein Rechner-System zu nichts zu gebrauchen sei. Ich meine, mit der jetzt vorhandenen Erweiterungs-Schnittstelle kann es Hobby-Hardwerkern als Mittel zur manuellen Ein/Ausgabe für ihr Produkt dienen. Die Schnittstelle beruht auf dem IO-Befehl H.. der CPU. Dabei gibt die CPU das kombinierte Register AB auf dem Adressbus aus und liest den Datenbus nach A ein. Die untere Hälfte des Adressbus (Register B) übernimmt die Rolle eines Kommandos an das IO-Gerät, die obere Hälfte bildet die Ausgabe-Daten. Bei der realisierten Schnittstelle sind nur 5 Bit des Registers B verfügbar. Das IO-Gerät kann die Eingabedaten sofort liefern, oder verzögert und dazu die CPU anhalten. Für die Treiber-Software sind auf dem FPGA-Board 32KByte in Slot7 reserviert, ausserdem 32 KByte privater RAM-Bereich.
@ Josef G. (bome) Benutzerseite >zu nichts zu gebrauchen sei. Ich meine, mit der jetzt vorhandenen >Erweiterungs-Schnittstelle kann es Hobby-Hardwerkern als Mittel >zur manuellen Ein/Ausgabe für ihr Produkt dienen. Das geht mit einem Picoblaze oder reinen UART + FSM 10mal einfacher und durchschaubar. Been there, done that. Du hast nur ein weiteres Kapitel im Buch "How to shoot yourself in the foot" geschrieben.
@Falk... Der Josef ist nicht einsichtsfähig und will seinen Thread nur oben sehen. Soviel sollte doch inzwischen wirklich klar sein. Man muss ihn diesbezüglich nicht noch andauernd unterstützen, das macht er schon alleine. Die Tragikkomödie wird schon irgendwann ihr Ende finden! Also lasst ihn doch in Ruhe seinen Traum hier leben.
>Der Josef ist nicht einsichtsfähig und will seinen Thread nur >oben sehen. Was für unverbesserliche Idioten hier. Josef pflegt sein Projekt und die Unterbelichteten haben nix besseres zu tun als dumm rumzumaulen. DANN KLICKT DOCH DEN THREAD EINACH NICHT AN. Mannmannmann...
:
Bearbeitet durch User
Joachim ... schrieb: > Josef pflegt sein Projekt Josef pflegt sein Hirngespinst. Joachim ... schrieb: > die Unterbelichteten ... sind die die das noch nicht erkannt haben :-)
Einiges über Gleitpunkt-Arithmetik Bei Verwendung des Hexadezimalsystems entfallen die Rundungs- fehler bei der Umwandlung zwischen Zahl und Zahlenstring. Damit wird auch die Intervall-Arithmetik verstärkt interessant. Ich möchte nun folgendes 8-Byte-lange Zahlenformat vorschlagen: Die ersten 2 Byte bestehen aus 1sbb,bbbb,bbbb,bbbb. s ist das Vorzeichen. bb,bbbb,bbbb,bbbb ist der Exponent e. Die restlichen 6 Byte sind die vorzeichenlose Mantisse M. Die Zahl stehe für das Intervall s*[M-1,M+2]*2^(e-1fff) Wenn statt 1s am Anfang 0s steht, sollen die restlichen Bits eine Integer-Zahl mit Vorzeichen s bedeuten. Ausnahme: Wenn die 8 Byte komplett 00 sind, soll dies "unbestimmt" bedeuten. (Man kann s als Vorzeichen ansehen und 6+7*8 Bits als Betrag. Dann gibt es eine positive und eine negative Null, von denen eine überflüssig ist und durch "unbestimmt" ersetzt wird. Oder man fasst alle 7+7*8 Bits als positiven Wert W auf, welcher für die Zahl W-4000,0000,0000,0000 steht. Dann stünde W=0 für -4000,0000,0000,0000, was durch "unbestimmt" ersetzt wird.) Dieses Zahlenformat ist redundanzfrei, und es gibt zu jeder Zahl auch die dazu negative Zahl. Für den Hexadezimal-String eines Gleitpunkt-Intervalls schlage ich folgende Notation vor: sUzzzUzzzUzzz.n:EEE Dabei steht s für + oder -, U,z,n,E sind Hex-Ziffern (U: Ziffern mit Überstrich). EEE-800 ist 10er-Exponent. Die Nachkommastelle n darf nicht 0 sein. Die letzte 1 in n dient als Terminierungs-Zeichen. Die Entsprechung zwischen Zahl und String ergibt sich so: Der 2er-Exponent e sei 4*k+r mit r=0|1|2|3 Damit e-1fff = 4*k+r-4*800+1 = 4*(k+1-800)-(3-r) Also 2^(e-1fff) = 10^(k+1-800)/2^(3-r) Man erhält also EEE als k+1, wobei 000 für 1000 steht. UzzzUzzzUzzz.n erhält man, indem man an M den Wert .8 anhängt und das Ergebnis 3-r Bits nach rechts schiebt. Bei dem vorgeschlagenen Zahlenformat ist die Größe des Fehler- Intervalls stets gleich 3 mal eine Zweierpotenz. Wenn sich bei Rechenoperationen eine kleine Vergrößerung des Fehlerintervalls ergäbe, führt dies im Rahmen des Zahlenformats gleich zu einer Verdopplung des Fehlerintervalls. Um das zu vermeiden, wird man für Zwischenrechnungen zusätzlich ein "internes" Zahlenformat einführen, bei welchem wie in der üblichen Intervall-Arithmetik untere und obere Grenze als zwei unabhängige Zahlen behandelt werden. Nach Abschluss der Zwischenrechnungen wird das Ergebnis dann in das vorgeschlagene Format konvertiert und abgespeichert, wobei die dann auftretende Verschlechterung des Fehlerintervalls entsprechend seltener vorkommt. Das vorgeschlagene Zahlenformat ist auf meinem Rechnersystem implementierbar. Für die 8-Byte-Zahlen gibt es die Datentypen Data und DataConst. Die Angabe von Konstanten im Qelltext eines Programms erfolgt durch einen unterstrichenen String, welcher mit der Nummer der Steckkarte beginnt, auf welcher die String- Wert-Konvertierungsroutine liegt. Die Verarbeitung der Zahlen erfolgt durch Kommandos und Mikro-Operationen auf der Karte. Übrigens: Der IO-Befehl H.. der CPU eignet sich auch zum Beschreiben und Auslesen von Registern eines Coprozessors.
Dein geniales Zahlenformat wird sicher noch die Welt retten. Aber nur wenn es auf Deinem wegweisenden FPGA Computer läuft :)
Zu einem "Warum einfach, wenns auch kompliziert gehen kann"-Computer gehört natürlich auch ein komplexes, völlig überflüssiges neues Zahlenformat. Sonst wärs ja nicht kompliziert genug...
Kann mir mal einer erzählen, welches Problem ihr hier habt? Ihr seid doch exakt von der Fraktion: "Ich kann selber nichts, also mache ich wenigstens irgendwas der anderen schlecht, Hauptsache ich habe was geschrieben". Habt ihr schon mal irgendwas gepostet, was von Interesse ist? Das ist SEIN Thema und er kann dazu schreiben was er will. Wenn ihr das Thema nicht von Interesse findet, gibt es dazu einen sehr einfachen Mechanismus: EINFACH NICHT LESEN! Ich praktiziere das schon seit 20 Jahren erfolgreich mit der BILD-Zeitung. 90% der threads hier im Forum sind inhaltlich ganz grosses Kaka, da ist die Vorstellung seines 8 Bit Computers wenigstens noch was Sinnvolles.
Josef G. schrieb: > Bei Verwendung des Hexadezimalsystems entfallen die Rundungs- > fehler bei der Umwandlung zwischen Zahl und Zahlenstring. Deswegen arbeiten Gleitpunkt-Arithmetiken, die Wandlungsfehler vermeiden wollen, intern mit BCD-Artihmetik. > Dieses Zahlenformat ist redundanzfrei Wen juckt die Redundanz in der BCD-Codierung bei den heutigen Preisen für Digitalelektronik? Diesen Hex-Scheiß, in den du dich da verrannt hast, braucht kein Mensch...
Uhu Uhuhu schrieb: > du dich da verrannt hast Leute, das bringt doch nix... Nun lasst ihm doch die Zeit, diese Sackgasse geduldig und konsequent, mit aller unergründlichen Tiefe Josefscher Phantasien bis zum bitteren Ende zu gehen - Geschockter schrieb: > da ist > die Vorstellung seines 8 Bit Computers wenigstens noch was Sinnvolles ... zumal er doch immer noch Fans auf seiner Seite hat die das "Sinnvoll" finden und tatsächlich vom Rest annehmen, Geschockter schrieb: > 90% der threads hier im Forum sind inhaltlich ganz grosses Kaka !!!
Fpga Kuechle schrieb: > Könnte man bitte mit den Beleidigungen und Schmähungen aufhören! > Wenn es zur Sache nichts mehr zu sagen dann schweigt eben. Richtig, ich schliesse mich an. Schlimm, was hier von Arroganten, die die Grenzen nicht kennen, taktlos abgelassen werden darf.
Andreas S. schrieb: > Hi "M. Bär", > >> @Igel1: Zu einem ehrlichen Bericht hätte gehört, was dafür bezahlt wurde! > > Zunächst: > > Zu einer ehrlichen Kritik hätte gehört, sich im Forum anzumelden und zu > seinen Äußerungen mit seinem Namen und seiner Person zu stehen. solch Getrolle ignoriert man einfach und konsequent. Alles andere bedeutet, man nimmt sowas ernst. Daumen hoch für Deinen und Josefs Einsatz! Mir fehlt es leider an Zeit. LG Karl-Heinz Autor von www.sharpmz.org
Habe das Projekt überarbeitet. Die CPU brauchte ursprünglich zwei Taktsignale, welche jeweils ein unsymmetrisches Tastverhältnis hatten. Jetzt sind die Takte symmetrisch, und es gibt auch eine Version mit nur einem Takt. Die CPU steht unter Creative-Commons-Lizenz zur Verfügung. http://www.mikrocontroller.net/articles/8bit-CPU:_bo8 In der Gesamt-Konfiguration habe ich die Dauer eines Halbzyklus von 360ns auf 320ns verkürzt. CPU-Befehle dauern 2 oder 4 oder 6 Halbzyklen. Die Verwendung des Parallel-Flash bei den Xilinx-Boards habe ich aus der Konfiguration entfernt. Dadurch wurde die Dokumentation auf der Seite Hawa der Projekt-Website übersichtlicher. http://www.bomerenzprojekt.de
Hm, durch deinen neuen Post hier habe ich zufällig diesen Thread gefunden. Lustig. Ich habe mir mal das VHDL der CPU angesehen. Ich glaube ich habe noch nie so kryptischen und unverständlichen Spaghetticode gesehen (Hunderte Signale? WTF). Die Doku ist aber noch wirrer als der Code. Das Ziel, eine Hardware zu entwerfen, die man ohne langes Studium leicht verstehen und nutzen kann, hast du leider komplett verfehlt. Erstens ist die Beschreibung und Dokumentation sehr wirr, stichwortartig und (wahrscheinlich) unvollständig, zweitens brichst du mit allen Konventionen und Standards. Dein Rechner hat den Anspruch, modern zu sein, aber irgendwie kommt mir nach kurzem Blick auf die Doku ein C64 eigentlich moderner und eleganter vor. Uralte Konzepte in der Breite aufzubohren heißt nicht, dass es modern wird.
@greg Wenn Du den Thread sorgfältig studiert hättest dann wüßtest Du, daß Deine wie jede andere kritische Anmerkung hier vergeudete Zeit sind.
Josef G. schrieb: > Kombinatorik und Flipflops sind sauber getrennt. Gerade DAS ist nicht der Inhalt von VHDL.
Habe die Schnittstelle für die Hardware-Erweiterung geändert. Es gibt jetzt einen 9bit-breiten Ausgangsport und einen 8bit-breiten Eingangsport und zwei Handshake-Leitungen für asynchronen Betrieb. Damit sollte der Anschluss eines Mikrocontrollers möglich sein. Vielleicht hat ja jetzt jemand eine Verwendung für das Gerät. Allerdings: Die Schnittstelle habe ich nicht getestet. Die zugehörige vhdl-Entity hat aber nur ein paar Zeilen Code. Wer daran denkt, Hardware dafür zu basteln, möge sich den Code ansehen und sich von der Funktion überzeugen. Siehe Projekt-Website / Seite Hawa ganz unten. ------------------------------------------------------ Beim S3A Starter Kit hat sich herausgestellt, dass die Funktion nach Änderung des Takt-Routings nicht mehr gegeben war. Dies lag wohl am Zusammenspiel des 50MHz- Taktes mit dem für das DDR2-RAM gebrauchten 150MHz-Takt. Ich habe die entsprechenden Teile der Konfiguration geändert. Sie funktioniert jetzt stabil.
Hallo, guten Tag. Ich habe als Anfänger mit 65 Jahren das DE1-Board. Du hattest mal geschrieben das du den Rechner auch für das DE1-Board geschrieben hast. Wo kann man den bitte einmal laden? Danke. Gruss
peter schrieb: > Wo kann man den bitte einmal laden? http://www.bomerenzprojekt.de Seite Downloads Beschreibung siehe Seiten Hawa und SYS-doku
Josef G. schrieb: > gibt jetzt einen 9bit-breiten Ausgangsport und einen 8bit-breiten > Eingangsport und zwei Handshake-Leitungen für asynchronen Betrieb. > Damit sollte der Anschluss eines Mikrocontrollers möglich sein. Es gibt jetzt einen zusätzlichen Eingang, mit dem man 8 der 9 Ausgänge hochohmig schalten kann. Somit kann man diese mit den 8 Eingängen zusammenlegen. Dadurch reduziert sich die Anzahl der benötigten GPIO-Pins des uC auf maximal 12.
Habe die Software für die SD-Karte, welche bisher eine eigene virtuelle Steckkarte belegte, mit der Test-Steckkarte in Slot1 zusammengelegt. Man muss jetzt auch beim DE1 nur eine Karten- Software nach dem Konfigurieren laden. Ausserdem habe ich die Karten-Software überarbeitet und die Beschreibung verbessert. Siehe Seite Hawa von http://www.bomerenzprojekt.de
Auch wenn du alle vier Wochen Reklame machst um deinen Thread oben zu halten: Davon wird dein Projekt nicht besser.
Josef G. schrieb: > Man muss jetzt auch beim DE1 nur eine Karten- > Software nach dem Konfigurieren laden. ENDLICH! Jetzt wird alles gut. Jetzt rollt Josef den Markt auf!
Das Programm zum Übertragen der Steckkarten-Software mittels RS232 vom PC zum Board gibt es bisher nur für Linux. Kann sein, dass das ein Hindernis ist bei der Akzeptanz des Projekts. Vielleicht liest hier jemand mit, der in der Lage und bereit ist, das Programm für Windows umzuschreiben und das Ergebnis hier zu posten. Der Quelltext sendcard.c des Programms für Linux findet sich auf der Seite Downloads meiner Website. Die 32Kbyte der Steckkarten-Software liegen vor als Hex-Text mit 1024 Zeilen zu je 64 Zeichen / 32 Byte. Das Programm überträgt die Bytes aber als Bytes und nicht als je 2 Zeichen, so dass alle 256 Werte übertragen werden müssen und nicht manche Werte als Steuerzeichen interpretiert werden dürfen. Die Handshake-Leitungen werden nicht verwendet.
Realisierungen des Systems gab es bisher auf folgenden Boards: Spartan-3A Starter, Spartan-3E Starter, Nexys2, Altera DE1 Es gibt nun auch eine Realisierung auf dem Altera DE0 Board.
Hallo,guten Tag. Wo kann man die für dieses DE0 runterladen ? Danke. Gruss
peter schrieb: > Wo kann man die für dieses DE0 runterladen ? http://www.bomerenzprojekt.de Seite Downloads. Beschreibung steht auf der Seite Hawa.
Beim DE1 habe ich jetzt ebenfalls das SDRAM in Betrieb genommen und die Konfiguration entsprechend geändert. Das SRAM wird jetzt nur noch für die Video-Ausgabe verwendet.
Puckel schrieb: > Selbstgespräche? Das Forum Projekte und Code ist dazu da, dass man über die eigene Arbeit informiert.
Josef G. schrieb: > dass man ... informiert. Nein, Du sprichst mit Dir selbst. Vielleicht sollstest Du den Quotienten von Aufwand/Nutzen Deiner Projekte ins Vorstellbare zurückführen um das zu ändern.
Puckel, lass Joseph hier seine Sachen posten, so wie er will. Im Gegensatz zu Deinen Posts haben seine einen fachlichen Inhalt und er bleibt sachlich. Er hält sich an die Foren-Regeln. Wenn Dir diese Art Technik nicht gefällt. beschreibe fachlich bessere Methoden, ansonsten halte bitte den Mund.
Franz schrieb: > haben seine einen fachlichen Inhalt Ja, als Beispiel dafür wie man sich möglichst kompliziert von hinten durch die Brust ins Auge schießt. Hast du dir mal sein Projekt angesehen? Dann solltest du eigentlich verstehen warum ihn hier niemand wirklich ernst nimmt.
Hallo Josef, falls du noch Anregungen für einen schöneren Zeichensatz suchst; hier gibts ein paar nette Beispiele: http://damieng.com/blog/2011/02/20/typography-in-8-bits-system-fonts Grüße, Ulrich
Ulrich B. schrieb: > falls du noch Anregungen für einen schöneren Zeichensatz suchst Auf meiner Website wird der Zeichensatz vergrößert dargestellt und sieht dadurch sehr unschön aus. Am realen System auf einem kleinen Monitor sieht er etwas besser aus.
Franz schrieb: > Puckel, lass Joseph hier seine Sachen posten, so wie er will. Im > Gegensatz zu Deinen Posts haben seine einen fachlichen Inhalt und er > bleibt sachlich. So ist es. Entweder sinnvollen Beitrag zum Projekt oder Klappe! Lars schrieb: > Ja, als Beispiel dafür wie man sich möglichst kompliziert von hinten > durch die Brust ins Auge schießt. Hast du dir mal sein Projekt > angesehen? Ich arbeite seit 15 Jahren mit FPGAs und sehe fast jede Woche ein neues Design irgendeines Experten. Und ich darf Dir versichern: Josef liegt mit der Qualität seiner Arbeit voll in der Mitte! Und dass das Ganze hier kein grosses Interesse findet, hat Gründe: 8-Bit Systeme sind etwas für Retrotypen, die sich dafür interessieren (das tue ich z.b. ausdrücklich), die aber auch Zeit für sowas haben, denn die Einarbeitung insowas in aufwändig. Ich z.B. habe keinen Tropfen Zeit dafür. Wenn ich in Rente wäre, würde ich mich draufstützen. Andererseits gibt es mmit den FPGA-Arcade-Sachen schon genau das, was ich selber brauche. Josefs Bastelprojekt ist also bemerkenswert - aber für viele nutzlos. Trotzdem bleibt es beachtenswert, besonders, wenn man sich reinzieht, was sonst noch so alles hier an "Projekten" veröffentlicht wird.
FPGA-Spezi schrieb im Beitrag #3813079: > nutzlos > beachtenswert Schließt sich für meine Begriffe aus. > Ich z.B. habe keinen > Tropfen Zeit dafür. Muß nicht wirklich verwundern. > Wenn ich in Rente wäre, würde ich mich draufstützen. Noch keinen Rentner hier gesehen der das täte. Auch sonst niemanden. Ohne Bezahlung ;-)
Anders als bei den historischen 8bit-Computern erfolgt die Zeichen-Ausgabe nicht durch eine Zeichengenerator-Hardware, sondern die Pixelmuster der Zeichen werden durch die CPU ins Video-RAM geschrieben. Man kann also auch Grafiken programmieren. Das Video-RAM ist zwischen zwei Seiten umschaltbar, das ermöglicht bewegte Grafiken. Vielleicht denkt ja doch noch jemand darüber nach, Software für das System zu schreiben, nachdem sich jetzt durch ein weiteres FPGA-Board der Kreis der potentiellen Anwender nochmal vergrößert hat.
Es gibt eine kleine Änderung der CPU: Bei Code-Folge H.. H.. wird auf dem Adressbus jetzt P statt K ausgegeben, und das Einlesen des Datenbus nach A entfällt.
@Josef G. (bome) Benutzerseite >Es gibt eine kleine Änderung der CPU: Bei Code-Folge H.. H.. >wird auf dem Adressbus jetzt P statt K ausgegeben, und das >Einlesen des Datenbus nach A entfällt. Das ist ja eine FUNDAMENTALE Neuerung, die dem Projekt sicher zum Durchbruch verhelfen wird . . . !!!
Puckel schrieb: > FPGA-Spezi schrieb im Beitrag #3813079: > >> nutzlos >> beachtenswert Beachtenswert nutzlos- für den Aufwand. Josef G. schrieb: > Es gibt eine kleine Änderung der CPU: Falk Brunner schrieb: > Das ist ja eine FUNDAMENTALE Neuerung, Das sind Thread-Blähungen. Viel Luft um nix ;-)
Falk Brunner schrieb: > @Josef G. (bome) Benutzerseite > >>Es gibt eine kleine Änderung der CPU: Bei Code-Folge H.. H.. >>wird auf dem Adressbus jetzt P statt K ausgegeben, und das >>Einlesen des Datenbus nach A entfällt. > > Das ist ja eine FUNDAMENTALE Neuerung, die dem Projekt sicher zum > Durchbruch verhelfen wird . . . !!! Falk, ich bezweifle mal das DU verstehst was er da geschrieben hat! Ich finde es toll das gemand anderen seiner Arbeit zu nichte mach, nur weil der eine nicht versteht was dahinter steckt! Wenn ich verstehen würde was Josef da zusammenbastelt wäre ich wohl der FPGA-Crack schlechthin. Er hat halt spaß daran soetwas zu machen, also bitte unterlasse es ihn deswegen blöd anzumachen! Oder gehst du zu nem Golfspieler hin und pöpelst nur weil du keinen sinn in diesem sport siehst?
Alex W. schrieb: > Er hat halt spaß daran soetwas zu machen, Den kann er doch - für sich - haben. Wer aber hier was reinschreibt bekommt Rückmeldungen. Ob diese gefallen oder nicht. Die vielen negativen, z.T. sehr ironischen sind dabei noch die ehrlichsten, weil sie dem TO tatsächlich die Sackgasse aufzeigen, in der er sich befindet. Ganz im Gegensatz zu einigen leeren Absichtserklärungen weniger "Unterstützer" , die m.M. nach aus ach so hehren moralischen Motiven nur Interesse heucheln und ihn letztlich damit nur in jener Sackgasse bestärken. Es ist nun mal so: viel Arbeit, Zeit und Einsatz in ein Projekt zu stecken gibt diesem nicht per se Sinn- jedenfalls für einen praktischen Einsatz. Den sollte man sich, so wie hier beabsichtigt, tunlichst vorher überlegen. Viel Arbeit, Zeit und Einsatz führen sonst nur zu einer blinden emotionalen Bindung, von der man sich, so wie hier demonstriert, kaum noch lösen kann. Jammerschade eigentlich wenn man bedenkt, was mit dieser Zeit und den vorhandenen Fähigkeiten womöglich sonst sinnvolleres angestellt werden könnte.
M.Bär schrieb: > Es ist nun mal so: viel Arbeit, Zeit und Einsatz in ein Projekt zu > stecken gibt diesem nicht per se Sinn- jedenfalls für einen praktischen > Einsatz. Den sollte man sich, so wie hier beabsichtigt, tunlichst vorher > überlegen. Viel Arbeit, Zeit und Einsatz führen sonst nur zu einer > blinden emotionalen Bindung, von der man sich, so wie hier demonstriert, > kaum noch lösen kann. Jammerschade eigentlich wenn man bedenkt, was mit > dieser Zeit und den vorhandenen Fähigkeiten womöglich sonst sinnvolleres > angestellt werden könnte. Da sieht man, wie die Menschen sind: Nur Leidenschaft und kein Gewissen!
Hintergrund der letzten CPU-Änderung: Die IO-Operation H.. gibt K auf dem Adressbus aus und liest den Datenbus nach A ein. K ist die Kurzbezeichnung für AB. Der Sprungbefehl J.. lädt K in den Programmzähler P. Somit ist die Folge H.. J.. eine unsinnige Code-Folge, weil dabei das Highbyte des Sprungziels über eine IO-Operation geladen würde. Diese Code-Folge erhält einen Sinn dadurch, dass in diesem Fall H.. nicht als IO-Befehl wirkt, sondern bewirkt, dass J.. mit einer Memory-Page-Umschaltung kombiniert wird. Es bleibt aber jetzt die unschöne Situation, dass H.. H.. J.. eine sinnlose Folge darstellen würde, da der Sprung H.. J.. mit Seitenumschaltung auf die IO-Operation H.. folgen würde. Deshalb erhält die Folge H.. H.. eine spezielle Funktion. Die Folge wird auf den Steuerleitungen angezeigt, wobei P auf dem Adressbus ausgegeben wird. Dies kann per externer Hardware zB. ein Anhalten der CPU auslösen. Da K erhalten bleibt, kann unter Umständen ein nachfolgendes J.. eine sinnvolle Funktion haben.
Hallo Joseph, gerade wenn der Weg das Ziel ist, lass dich nicht abhalten. Ansonsten hätte ich schon eine Anwendung. Die alten Spiele haben sehr viel Spass gemacht. Da kam es auf clevere Spielkonzepte und nicht nur auf aufgepumpte Grafik an. Versuche doch Tetris, Blockout, Packman und wie sie alle hiessen zu programmieren. Und du bist nicht allein. Es gibt genug Verrückte die sich mit demn Thema Retro-Computer befassen. siehe hier: http://www.zx81.de/ :-P
@ Alex W. (a20q90) >ich bezweifle mal das DU verstehst was er da geschrieben hat! Das darfst du, wenn gleich du auf dem Holzweg bist. >Ich finde >es toll das gemand anderen seiner Arbeit zu nichte mach, nur weil der >eine nicht versteht was dahinter steckt! Ich verstehes ausreichend, um zu versthen, dass es eher unverständlich ist. Verstehst du? ;-) >Wenn ich verstehen würde was Josef da zusammenbastelt wäre ich wohl der >FPGA-Crack schlechthin. Und ein 2. Rainman, neudeutsch, Nerd. > Er hat halt spaß daran soetwas zu machen, also >bitte unterlasse es ihn deswegen blöd anzumachen! Welche wie auch immer sinnvollen oder sinnfreien Hobbys andere Leute haben, ist mir relativ egal. Aber wie schon mehrfach geschrieben, geht es Josef darum, sein Projekt anzupreisen und Anwender zu finden. Er hat sogar schon mal Tester BEZAHLT, damit sie sich das antun! Also geht es um eine sachliche Bewertung des Projekts. Leider fällt die meist weniger gut aus. Such im Forum nach Josef und meinem Namen, dort findest du ausreichend Aussagen, warum das Projekt nix taugt. > Oder gehst du zu nem >Golfspieler hin und pöpelst nur weil du keinen sinn in diesem sport >siehst? Nö, die Golfspieler preisen aber auch nicht ständig ihr Spiel in einem Forum an. Ausserdem bin ich Minigolfspieler! ;-)
Hat schon mal jemand den Befehlssatz der CPU angeschaut?
Josef G. schrieb: > Hat schon mal jemand den Befehlssatz der CPU angeschaut? Ist dort etwa der vielgesuchte Sinn versteckt ???
@Joseph Tut mir echt leid, aber wenn ich die Seite http://www.bomerenzprojekt.de/Website/CPU-doku.html so ansehe, kommt mir als erstes die Frage wo sind den die Befehle deiner CPU auf dieser Seite genau? Wo sind sie für "dumme" wie mich noch mal einzeln erklärt? Und ein paar Überschriften wären möglicherweise hilfreich. Ich habs ja auch nicht imer so mit der doku, aber im Internet sind doch schöne Beispiele für gelungene CPU-Dokumenatationen, Es muss ja nicht soo ausführlich sein, aber nur mal zur Anregung z.B. diese gelungene Seite zum "guten" alten 8051: http://www.self8051.de/einf%FChrung,13286.html 1) Funktionale Aufschlüsselung des Befehlsvorrats http://www.self8051.de/funktionale_aufschl%FCsselung_des_befehlsvorrats,13287.html 2) Die Adressierungsarten http://www.self8051.de/adressierungsarten,13289.html 3) Alle Befehle in der Übersicht http://www.self8051.de/alle_Befehle_des_8051_Mikrocontroller,13290.html 4) Und weiter wird dann noch jeder einzeln im Detail erklärt
Der vollständige Befehlssatz ist diese Tabelle:
1 | +0 +1 +2 +3 +4 +5 +6 +7 |
2 | |
3 | 00- H.. SL.S SW.X SL.X SW.Y SL.Y SW.Z SL.Z |
4 | 08- IX0 IX1 IX2 IX3 IX4 IX5 IX6 IX7 |
5 | 10- IY0 IY1 IY2 IY3 IY4 IY5 IY6 IY7 |
6 | 18- IZ0 IZ1 IZ2 IZ3 IZ4 IZ5 IZ6 IZ7 |
7 | 20- ZO.S EX.S ES.X EX.X ES.Y EX.Y ES.Z EX.Z |
8 | 28- DX0 DX1 DX2 DX3 DX4 DX5 DX6 DX7 |
9 | 30- DY0 DY1 DY2 DY3 DY4 DY5 DY6 DY7 |
10 | 38- DZ0 DZ1 DZ2 DZ3 DZ4 DZ5 DZ6 DZ7 |
11 | 40- O.VZ O.VS B.VZ B.VS O.UZ O.US B.UZ B.US |
12 | 48- O.AZ O.AS B.AZ B.AS O.KZ O.KS B.KZ B.KS |
13 | 50- O.WY O.RP B.WY B.CN GTR ADR GTA NON |
14 | 58- IKL DKL IXL DXL IYL DYL IZL DZL |
15 | 60- NR. XR. AN. GT. SV. AV. LV. AD. |
16 | 68- NRMX XRMX ANMX GTMX SVMX AVMX LVMX STMX |
17 | 70- NRMY XRMY ANMY GTMY SVMY AVMY LVMY STMY |
18 | 78- NRMZ XRMZ ANMZ GTMZ SVMZ AVMZ LVMZ STMZ |
19 | 80- NO2 TK1 TK2 TK3 TK4 TK5 TK6 TK7 |
20 | 88- EX.B TK9 TKa TKb TKc TKd TKe TKf |
21 | 90- NO1 TA1 TA2 TA3 TA4 TA5 TA6 TA7 |
22 | 98- NR.B XR.B AN.B GT.B SV.B AV.B LV.B ST.B |
23 | a0- SD.S AD.S LD.S GT.S SV.S AV.S LV.S ST.S |
24 | a8- SD.X AD.X LD.X GT.X RS.X SS.X ZO.X ST.X |
25 | b0- SD.Y AD.Y LD.Y GT.Y RS.Y SS.Y ZO.Y ST.Y |
26 | b8- SD.Z AD.Z LD.Z GT.Z RS.Z SS.Z ZO.Z ST.Z |
27 | c0- R.VZ R.VS R.UZ R.US R.AZ R.AS R.KZ R.KS |
28 | c8- R.WY R.CN R.IX R.DX R.IY R.DY R.IZ R.DZ |
29 | d0- GH.S GL.S GH.X GL.X GH.Y GL.Y GH.Z GL.Z |
30 | d8- IC.S DC.S IXE DXE IYE DYE IZE DZE |
31 | e0- TZ.B PV.B TZ.A PV.A SZ.A AZ.A LZ.A CP.V |
32 | e8- RD.B RU.B RD.A RU.A NG.V ZO.V SE.V CR.V |
33 | f0- NG.B ZO.B NG.A ZO.A NG.U ZO.U SE.U S.RP |
34 | f8- IC.K DC.K NG.K SL.K IC.A DC.A GT.Q J.. |
Beispiel: OpCode 69: XRMX
Weiter unten steht: % stehe für X|Y|Z und
XRM% | XR.B A wird A xor op mit op = (%) | B
Die letzte Zeile steht also für
XRMX A wird A xor (X)
XRMY A wird A xor (Y)
XRMZ A wird A xor (Z)
XR.B A wird A xor B
XRMX bewirkt also, dass A mit dem Inhalt jener Speicherzelle,
auf welche das Adress-Register X zeigt, xor-verknüpft wird.
Natürlich könnte man zu jedem der 256 OpCodes eine mehrzeilige
Beschreibung angeben, aber das wäre halt entsprechend lang.
:
Bearbeitet durch User
XRM% | XR.B A wird A xor op mit op = (%) | B soll eine Zusammenfassung sein von XRM% A wird A xor (%) XR.B A wird A xor B
> Da K erhalten > bleibt, kann unter Umständen ein nachfolgendes J.. eine > sinnvolle Funktion haben.
Josef G. schrieb: > Hintergrund der letzten CPU-Änderung: > > Die IO-Operation H.. gibt K auf dem Adressbus aus und liest > den Datenbus nach A ein. K ist die Kurzbezeichnung für AB. > Der Sprungbefehl J.. lädt K in den Programmzähler P. Somit > ist die Folge H.. J.. eine unsinnige Code-Folge, weil dabei > das Highbyte des Sprungziels über eine IO-Operation geladen > würde. Diese Code-Folge erhält einen Sinn dadurch, dass in > diesem Fall H.. nicht als IO-Befehl wirkt, sondern bewirkt, > dass J.. mit einer Memory-Page-Umschaltung kombiniert wird. > > Es bleibt aber jetzt die unschöne Situation, dass H.. H.. J.. > eine sinnlose Folge darstellen würde, da der Sprung H.. J.. > mit Seitenumschaltung auf die IO-Operation H.. folgen würde. > > Deshalb erhält die Folge H.. H.. eine spezielle Funktion. > Die Folge wird auf den Steuerleitungen angezeigt, wobei P > auf dem Adressbus ausgegeben wird. Dies kann per externer > Hardware zB. ein Anhalten der CPU auslösen. Da K erhalten > bleibt, kann unter Umständen ein nachfolgendes J.. eine > sinnvolle Funktion haben. Also spätestens nach diesem Beitrag kann man doch das Projekt nicht mehr ernst nehmen. Du kannst doch nicht allen Ernstes verlangen, dass sich jemand sowas antut... Um etwas Konstruktives beizutragen: schreib doch einen C-Compiler für deine CPU, dann besteht immerhin die theoretische Möglichkeit das jemand was zum Projekt beiträgt.
bal schrieb: > Also spätestens nach diesem Beitrag kann man > doch das Projekt nicht mehr ernst nehmen. Inwiefern? > Um etwas Konstruktives beizutragen: schreib > doch einen C-Compiler für deine CPU Abgesehen davon, dass ich das gar nicht könnte: Der Befehlssatz der CPU ist so Programmierer-freundlich, dass es nicht nötig ist, ihn hinter einem Compiler zu verstecken. Bei dieser CPU macht Assembler-Programmierung Spass.
Josef G. schrieb: > Bei dieser CPU macht Assembler-Programmierung Spass. Wem denn? Nenne einen Namen außer Josef G. Mir würde sie jedenfalls keinen Spaß machen. Du präsentierst dieses Thema derart trocken, dass ich flüchten würde, müsste ich mir einen Vortrag von Dir zu diesem Thema anhören. Allein Dein obiges Gestammel zu K, A, H, J (was ist das überhaupt?!?) ist absolut unverständlich. Gibts das irgendwie auch systematisch? Bitte nicht so: "Die IO-Operation H.. gibt K auf dem Adressbus aus und liest den Datenbus nach A ein." Es gibt also eine IO-Operation H.. mit zwei Pünktchen hinter dem H? Was ist K? Warum sind da keine zwei Pünktchen? Ist das ein Register? Wie breit ist das Register und warum heisst es K? Wird da eine Adresse ausgegeben? Wie breit ist denn der Adressbus? Und wieso wird der Datenbus eingelesen? Du unterscheidest also nicht zwischen RAM und I/O Operationen beim Zugriff auf den Datenbus? Und der Datenbus wird einfach so eingelesen? Ohne einen Strobe oder ein sonstiges Signal? Wo gibt es Timing-Diagramme dazu? Was ist denn A? Ein Akkumulator? Oder einfach ein Register, welches nicht K(onrad), sondern A(nton) heisst? Das sind jetzt schon zig Fragen zu einem einzigen Satz von Dir. Wenn ich mir jetzt weitere 9 Sätze von Dir anschaue, bin ich bei weit über 100 Fragen, ohne irgendwas zu kapieren. Wenn ich mir Deine vollständige Befehlssatz-Tabelle anschaue, dann stellen sich mir viele weitere Fragen. Wie breit ist der Opcode? Etwa 3 Nibble? Für SVMX ergibt sich der Opcode nach Deiner Tabelle mit Hex 684. Kannst Du Nibbles (also 4 Bit) adressieren oder wie liest Deine CPU diesen Opcode ein? Oder füllst Du den Opcode mit einem 0-Nibble auf, so dass der Opcode dann 0684 ist und damit glatte 2 Byte lang ist? Wenn ja, hältst Du dieses nicht auch für ineffizient, 1/4 aller nötigen Daten umsonst eingelesen zu haben und dabei auch noch 1/4 des Speicherplatzes zu verschenken? Oder steckt in dem überzähligen Nibble ein weiterer Operator? Fragen über Fragen.... und nichts ist ausreichend erklärt. Und jetzt nochmal zurück zu Deiner Aussage: > Bei dieser CPU macht Assembler-Programmierung Spass. Definitiv nicht. Das kann keinen Spaß machen.
:
Bearbeitet durch Moderator
Falk Brunner schrieb: > Such im Forum nach Josef und meinem Namen, dort > findest du ausreichend Aussagen, warum das Projekt nix taugt. Wenn ich nur nach Deinem Namen such komm ich auch zu einer eigenen Meinung :-D scnr
Frank M. schrieb: > Allein Dein obiges Gestammel zu K, A, H, J (was ist das überhaupt?!?) > ist absolut unverständlich. Gibts das irgendwie auch systematisch? A ist der Akku, das steht auf der Seite CPU-doku. A ist 8bit breit, das steht nirgendwo explizit, ist aber bei einer 8bit-CPU klar. K ist eine Kurzbezeichnung für das Doppelregister AB. Das steht auf der Seite CPU-doku, und nochmals in obigem Beitrag. > Es gibt also eine IO-Operation H.. mit zwei Pünktchen hinter dem H? Die Operation H.. wird auf der Seite CPU-doku beschrieben. Der Punkt steht für den von mir eingeführten auf der Grundlinie liegenden Bindestrich. Das steht auch auf der Seite CPU-doku. Dieses Zeichen gehört nach der Systematik des Zeichensatzes zu den Großbuchstaben. > Was ist K? Warum sind da keine zwei Pünktchen? > Ist das ein Register? Wie breit ist das Register Siehe oben. > und warum heisst es K? Warum nicht? > Wird da eine Adresse ausgegeben? Bei IO-Operationen wird K ausgegeben. Welche Funktion das hat, entscheidet die periphere Hardware. > Wie breit ist denn der Adressbus? 16bit. Steht auf der Seite CPU-doku (A0..Af) > Und wieso wird der Datenbus eingelesen? Weil die CPU so gemacht ist. > Du unterscheidest also nicht zwischen RAM und > I/O Operationen beim Zugriff auf den Datenbus? Doch, natürlich. Wie kommst du darauf? > Und der Datenbus wird einfach so eingelesen? > Ohne einen Strobe oder ein sonstiges Signal? Die CPU gibt keine WE, RD -Signale oder so etwas aus. Stattdessen gibt es die Typleitungen. Dort wird der Halbzyklus-Typ angezeigt. Siehe Seite CPU-doku. Die WE, RD -Signale müssen daraus per externer Hardware erzeugt werden. > Wo gibt es Timing-Diagramme dazu? Stehen auf der Seite CPU-doku. > Was ist denn A? Ein Akkumulator? A ist der Akku, das steht auf der Seite CPU-doku. > Wie breit ist der Opcode? Etwa 3 Nibble? OpCodes sind 8bit breit. Das ergibt sich zB. aus der Tabelle. > Für SVMX ergibt sich der Opcode nach Deiner Tabelle mit Hex 684. Nein. Der OpCode ist 68+4 = 6c. Sollte aus der Tabelle klar sein. > Kannst Du Nibbles (also 4 Bit) adressieren oder wie liest Deine CPU > diesen Opcode ein? Oder füllst Du den Opcode mit einem 0-Nibble auf, so > dass der Opcode dann 0684 ist und damit glatte 2 Byte lang ist? Wenn ja, > hältst Du dieses nicht auch für ineffizient, 1/4 aller nötigen Daten > umsonst eingelesen zu haben und dabei auch noch 1/4 des Speicherplatzes > zu verschenken? Oder steckt in dem überzähligen Nibble ein weiterer > Operator? Ist nach dem oben gesagten hinfällig. > Fragen über Fragen.... und nichts ist ausreichend erklärt. Ich bin bei all meinen Beiträgen hier im Forum immer davon ausgegangen, dass die Mitleser die Seite CPU-doku kennen. > Und jetzt nochmal zurück zu Deiner Aussage: >> Bei dieser CPU macht Assembler-Programmierung Spass. > Definitiv nicht. Das kann keinen Spaß machen. Vielleicht überdenkst du das nach dieser Antwort nochmal.
Josef G. schrieb: > Vielleicht überdenkst du das nach dieser Antwort nochmal. Was hälst Du von dem Gedanken daß eher Du was überdenken solltest? Nämlich nichts weniger als den kompletten Sinn Deiner ganzen FPGA-CPU Technikstudie? Nicht alles was machbar ist ist auch sinnvoll.
Josef G. schrieb: > Der vollständige Befehlssatz ist diese Tabelle: > > +0 +1 +2 +3 +4 +5 +6 +7 > > 00- H.. SL.S SW.X SL.X SW.Y SL.Y SW.Z SL.Z > > > Beispiel: OpCode 69: XRMX > > Weiter unten steht: % stehe für X|Y|Z und > XRM% | XR.B A wird A xor op mit op = (%) | B > > Die letzte Zeile steht also für > > XRMX A wird A xor (X) > XRMY A wird A xor (Y) > XRMZ A wird A xor (Z) > XR.B A wird A xor B > > XRMX bewirkt also, dass A mit dem Inhalt jener Speicherzelle, > auf welche das Adress-Register X zeigt, xor-verknüpft wird. Nun, dann schreib es doch auch so in deine Web-page! >Natürlich könnte man zu jedem der 256 OpCodes eine mehrzeilige >Beschreibung angeben, aber das wäre halt entsprechend lang. Entschuldigung aber ich verstehe deine Befehlsabkürzungen so nicht, und es geht anscheinend anderen Lesern deiner Seite hier genauso! Mach die die Mühe der Doku mit Beispielen! (also nicht als Antwort in diesem Forum sondern auf deiner WEB-Seite) -> lies doch mal ein paar CPU-Datenblätter oder Webseiten, und lerne daraus wie andere Dokumentieren; im Anhang habe ich mal ein paar Anregungen so zum Start.... >Abgesehen davon, dass ich das gar nicht könnte: >Der Befehlssatz der CPU ist so Programmierer-freundlich, dass >es nicht nötig ist, ihn hinter einem Compiler zu verstecken. >Bei dieser CPU macht Assembler-Programmierung Spass. Assembler, und ist er noch so schön, ist halt nicht portierbar. Also ich empfehle dir dich dochmal mit "forth" auseinanderzusetzen, hier z.B.: http://www.forth-ev.de/ gibt es eine deutschsprachige forth Gemeinde, hier hat jemand forth selbst portiert: http://www.forth-ev.de/wiki/doku.php/projects:r8c:r8c_forth was bei forth nicht zu schwer zu sein scheint!
Josef G. schrieb: > A ist der Akku, das steht auf der Seite CPU-doku. A ist 8bit breit, > das steht nirgendwo explizit, ist aber bei einer 8bit-CPU klar. > K ist eine Kurzbezeichnung für das Doppelregister AB. Das > steht auf der Seite CPU-doku, und nochmals in obigem Beitrag. "ist aber bei einer 8bit-CPU klar." Merkst Du eigentlich, dass Du dich mit solchen Aussagen selbst weit ins Abseits stellst und Du nur ein Diskussionspartner für andere Anfänger sein kannst. Zur Verdeutlichung: 8bit-CPU 6809: X- und Y-Register sind 16 Bit breit. 8bit-CPU Z80: HL-, IX- und IY-Register sind 16 Bit breit. Warum auch nicht... Und da gibt es noch einige Beispiele mehr, auch bei anderen CPUs. Für DICH ist es vielleicht klar, dass der Akku nur 8 Bit breit ist, Du kennst es offensichtlich nicht anders. Andere jedoch, mit einer ungleich größeren Erfahrung in Bezug auf 8 Bit-CPUs weisen Dich letztlich nur auf Deine mangelnde Dokumentation hin. Warum nur schreibt z.B. Rodnay Zaks hunderte Seiten nur für eine einzige CPU? Warum nennst Du dein Doppelregister AB denn K? Warum heist es nicht AB? Sich mit so einer CPU zu beschäftigen, kommt wirklich einer Folter nahe! Mal ein anderes praktisches Beispiel: Eine kurze Verzögerungsschleife in 6502-Assembler:
1 | LDX #$FF ;LoaD X mit $FF (255 dezimal) |
2 | Loop: DEX ;DEkrementiere X |
3 | BNE Loop ;Branch if Not Equal to zero |
Sowas kann man fließend lesen und es ist nahezu selbsterklärend! Zeige doch mal ein praktisches Beispiel mit Deiner CPU! Zum Beispiel eine Schleife, um den Bildschirm zu löschen. Also ein Allerweltsproblem... Schliessen möchte ich mit einem Zitat von Wilhelm Busch: Wenn einer, der mit Mühe kaum Gekrochen ist auf einen Baum, Schon meint, daß er ein Vogel wär, So irrt sich der.“ Schönen Abend, Thomas PS: Die erste Seite im "Forum: FPGA, VHDL & Co." umfasst bei mir 51 Threads. Im Moment sind 14 davon (das sind 27%!) von "peter" geöffnet worden. Wäre es nicht sinnvoll für ihn ein eigenes Unterforum zu eröffnen, damit man nicht so oft über seine Fragen stolpern muss?
Thomas T. schrieb: > 8bit-CPU 6809: X- und Y-Register sind 16 Bit breit. > 8bit-CPU Z80: HL-, IX- und IY-Register sind 16 Bit breit. Aber die beiden Akkus des 6809 und der Akku des Z80 sind nur 8bit breit. Also keine Widerlegung meiner Aussage "ist klar". > Warum nennst Du dein Doppelregister AB denn K? Damit man bei den Mnemonics nicht soviel schreiben muss. > Eine kurze Verzögerungsschleife in 6502-Assembler: > > LDX #$FF ;LoaD X mit $FF (255 dezimal) > Loop: DEX ;DEkrementiere X > BNE Loop ;Branch if Not Equal to zero Die Dauer des BNE falls gesprungen wird hängt davon ab, ob das BNE und das Sprungziel im selben 256Byte-Bereich liegen. Die Dauer der Schleife ist also bei Code-verschiebung nicht fix. Das ist Mist. So etwas gibt es bei meiner CPU nicht. Beitrag "Re: 8bit-Computing mit FPGA" Bei meiner CPU: GTA ff 2 Zyklen LOOP DC.K 1 Zyklus B.KS LOOP 3 Zyklen / letzter Durchlauf 2 Zyklen Dauer: 2 + 255*(1+3)-1 Zyklen > Zeige doch mal ein praktisches Beispiel mit Deiner CPU! > Zum Beispiel eine Schleife, um den Bildschirm zu löschen. Löschen von Seite E des Text-RAM: Bereich a000..bfff in Memory-Page 1. Das Schatten-Pageregister für Y zeigt standardmäßig auf diese Memory-Page (das ist keine Eigenschaft der CPU, sondern des Gesamtsystems) GTA a0 Lade AB mit 00a0 EX.B Tausch A <> B ST.Y Speichere AB in Y SW.Y Memory-Page-Umschaltung für Y GTA ff Lade AB mit 00ff AD. 1f Addiere 1f zu A ST.S Speichere AB in S ZO.A Setze A <= 00 (bei mir ist 00 das Leerzeichen) S.RP Setze Schleifenstartadresse STMY Speichere A in (Y) R.IY Falls S > 0000 : S <= S-1, Y <= Y+1 , repeat SW.Y Memory-Page-Wiederherstellung für Y
Josef G. schrieb: > GTA a0 Lade AB mit 00a0 > EX.B Tausch A <> B > ST.Y Speichere AB in Y > SW.Y Memory-Page-Umschaltung für Y > GTA ff Lade AB mit 00ff > AD. 1f Addiere 1f zu A > ST.S Speichere AB in S > ZO.A Setze A <= 00 (bei mir ist 00 das Leerzeichen) > S.RP Setze Schleifenstartadresse > STMY Speichere A in (Y) > R.IY Falls S > 0000 : S <= S-1, Y <= Y+1 , repeat > SW.Y Memory-Page-Wiederherstellung für Y UM GOTTES WILLEN! Wem soll dieses kryptische unlogische Kauderwelsch bloß Spaß machen? ... fragt ein entsetzter Assemblerfan
Josef G. schrieb: > SW.Y Memory-Page-Wiederherstellung für Y ist ja noch schlimmer als der allererste PIC-Assembler ;-( Gehts noch umständlicher?
Michael schrieb: >> SW.Y Memory-Page-Wiederherstellung für Y > ist ja noch schlimmer als der allererste PIC-Assembler Da werden ganze 64KByte-Seiten umgeschaltet, das ist etwas anderes als bei PIC.
@ Josef G. (bome) Benutzerseite >> kryptische unlogische Kauderwelsch >Bitte um nähere Begründung. Du bist ein Autist. Kein Vorwurf, reine Feststellung. Beitrag "Re: 8bit-Computing mit FPGA" Du kannst nicht vernünftig kommunizieren, sprichst in kryptischen Abkürzungen, die ausser dir KEINER versteht! Auch Assemblerbefehle sollte ansatzweise an einer "menschlichen" Sprache, oft Englisch, angelehnt sein. Load a, 0xAB ist 100 mal Verdaulicher und verständlicher, als beispeilsweise xf k, ab So in etwa sind deine Befehle kodiert bzw. abgekürzt. GRAUSAM!
Falk Brunner schrieb: > Auch Assemblerbefehle sollte ansatzweise an einer "menschlichen" > Sprache, oft Englisch, angelehnt sein. > > Load a, 0xAB > > ist 100 mal Verdaulicher und verständlicher, als beispeilsweise > > xf k, ab Load a, 0xAB würde bei mir heissen GT. ab GT steht für "get". ab sind die von mir eingeführten Hex-Ziffern. Ein Präfix braucht man nicht.
Falk Brunner schrieb: > xf k, ab Eine solche Operation gibt es bei mir nicht. PS: Sorry, eigentlich eine überflüssige Aussage, aber man weiss ja nie, am Ende liest einer nur das aber nicht meine Beiträge und glaubt es auch noch.
:
Bearbeitet durch User
Josef G. schrieb: > GTA ff Lade AB mit 00ff > AD. 1f Addiere 1f zu A GTA steht für "get absolute". In Kombination mit AD. wie hier kann man damit eine absolute Adresse laden, um sie anschließend in ein Adressregister zu übertragen oder mittels J.. zu dieser Adresse zu springen. Daneben gibt es auch GTR. Das steht für "get relative". GTR nn lädt P+nn+3 nach AB. Damit kann man eine relative Adresse im Nahbereich des Programmzählers laden. In Kombination mit AD. entfällt die Beschränkung auf den Nahbereich. Für GTA 34 AD. 72 gibt es das Assembler-Makro /GTA 7234 Entsprechend für GTR.
Der auf der Grundlinie liegende Bindestrich zB. in AD. (hier repräsentiert durch den Punkt) hat keine andere Funktion, als den Namen auf 3 Zeichen zu verlängern.
Josef G. schrieb: > Falk Brunner schrieb: >> Auch Assemblerbefehle sollte ansatzweise an einer "menschlichen" >> Sprache, oft Englisch, angelehnt sein. >> >> Load a, 0xAB >> >> ist 100 mal Verdaulicher und verständlicher, als beispeilsweise >> >> xf k, ab > > Load a, 0xAB würde bei mir heissen > > GT. ab > > GT steht für "get". > > ab sind die von mir eingeführten Hex-Ziffern. > Ein Präfix braucht man nicht. ja warum denn das? Wieso machst Du für Loead a, 0xAB nicht einfach LD für Load? Das wäre ja noch sinnvoller als ais "Load" ein "Get" zu machen?
Bei Verzweigungen mit 8bit-Distanz wird zwischen
Vorwärts- und Rückwärts-Sprüngen unterschieden.
B.xx sind Rückwärts-Sprünge ("back")
O.xx sind Vorwärts-Sprünge ("omit").
Ich fände es praktischer wenn auch noch zwischen geraden und ungeraden Adressen unterschieden würde.
Josef G. schrieb: > S.RP Setze Schleifenstartadresse > STMY Speichere A in (Y) > R.IY Falls S > 0000 : S <= S-1, Y <= Y+1 , repeat Für schnelle Schleifen gibt es die Schleifenstartadresse R. S.RP operation1 operation2 operation3 R.xx S.RP ("start of repeat") setzt R auf operation1. Die Operation R.xx ("repeat") springt zurück nach R. In C-Terminologie handelt es sich hier um eine do-while- Schleife. Es sind aber auch while-Schleifen möglich. Dazu verwendet man O.RP statt S.RP. O.RP MARKE operation1 operation2 operation3 MARKE operation4 operation5 R.xx O.RP MARKE setzt R auf operation1 und springt zu MARKE. operation1/2/3 sind das Innere der while-Schleife, operation4/5 bilden zusammen mit R.xx den Entscheidungs- und Wiederhol-Ablauf. Anmerkung (hat nichts mit der CPU zu tun): In der im ROM eingebauten Hochsprache des Gesamtsystems wird nach gleichem Muster die "Schleife mit Hineinsprung" zur Realisierung von while-Schleifen verwendet.
pork schrieb: > Ich fände es praktischer Nach meinen Erfahrungen mit Verzweigungen im Bereich -128..+127 ist dieser Bereich sehr knapp bemessen. Mit 256 Byte in jede Richtung sieht das schon wesentlich besser aus.
gustl schrieb: > Josef G. schrieb: >> Der Programmierer muss dann halt nicht darauf achten, welcher >> Operand zuerst im Akku stehen muss, das erleichtert ihm die Arbeit. > > Akku? Ach herje. Das ist zwar ein interessantes Konzept, war aber früher > eher dadurch etabliert, dass man mit der geringen Anzahl an verfügbaren > Transistoren noch kein richtiges Registerfile bauen konnte. Seit Ende > der 70er Jahre besteht dazu keine Notwendigkeit mehr. Außer zu evtl. > Forth ist eine Akkumulatorarchitektur auch zu keine Hochsprache > kompatibel. Vergleiche hierzu: Beitrag "Re: Motorola 68HC11" > Die Akkumaschinen sind (im Gegensatz zu manch Behauptung) noch nicht > tot. Ua haben Freescale, ST(bsp STM8, sehr schnell, 8bit), Fujitsu, > (auch M16C wäre möglich) noch welche im Programm. > In vielen Fällen sind die sogar schneller als RISC, weil nicht so > viele LDs/STs nötig sind. (Und ContextSwitch ist auch schneller)
Irgendwie erinnert mich das alles an Intercal, aber dann in ASM. http://en.wikipedia.org/wiki/INTERCAL
Eric schrieb: > Irgendwie erinnert mich das alles an Intercal Gefällt mir! Das war für mich das beste Intercal-Statement: PLEASE GIVE UP :-)
Eric schrieb: > Irgendwie erinnert mich das alles an Intercal, aber dann in ASM. Kannst du das an einem oder mehreren Mnemonics begründen?
Die Schreibweise für bedingte Anweisung und Verzweigung in der im ROM eingebauten Compilersprache wurde geändert und entspricht jetzt dem üblichen if und if-else.
:
Bearbeitet durch User
Josef G. schrieb: > Kannst du das .... begründen? Wozu? Aufwand ohne Nutzen, so wie das ganze Projekt. Josef G. schrieb: > Die Schreibweise für bedingte Anweisung und Verzweigung > in der im ROM eingebauten Compilersprache wurde geändert > und entspricht jetzt dem üblichen if und if-else. Das interessiert jetzt ... WEN ???
Peter schrieb: > Das interessiert jetzt ... WEN ??? Ihn selbst. Ohne diesen Thread wäre die Selbstkommunikation unterbrochen ;-)
Josef G. schrieb: > In der im ROM eingebauten Hochsprache des Gesamtsystems > wird nach gleichem Muster die "Schleife mit Hineinsprung" > zur Realisierung von while-Schleifen verwendet. *L.JP / springt zu *HERE oper1 oper2 *HERE oper3 oper4 / weist VAR einen Wert zu *RP.Z VAR / springt zu oper1 falls VAR = zero In C würde man hier eine function definieren, welche oper3/4 ausführt und den Rückgabewert VAR erhält. Und man würde eine while-Schleife verwenden, welche oper1/2 ausführt, solange die function Null liefert. Die Schleife mit Hineinsprung erfüllt den gleichen Zweck auf einfachere Weise. Die Hochsprache braucht dann auch nicht das Konstrukt einer function mit Rückgabewert, sondern es reichen einfache Unterprogramme, bei welchen alle Übergabe-Parameter gleichberechtigt sind.
Josef G. schrieb: > In C würde man hier eine function definieren, welche > oper3/4 ausführt und den Rückgabewert VAR erhält. Da kein C-Compiler für Deine CPU existiert, ist Deine Abhandlung hier rein akademisch. oper3/4 oder oper1/2... sagt mir überhaupt nichts. Solange Deine Mnemonics nicht wenigstens etwas selbsterklärend sind, damit man etwas damit verbinden kann, kommt damit keiner auf einen grünen Zweig. Du könntest auch chinesisch schreiben.
:
Bearbeitet durch Moderator
Frank M. schrieb: > oper3/4 oder oper1/2... sagt mir überhaupt nichts. Das sind keine Mnemonics. oper1 usw. habe ich hier geschrieben als Platzhalter für irgendwelche Operationen.
Frank M. schrieb: > Da kein C-Compiler für Deine CPU existiert, ist Deine Abhandlung hier > rein akademisch. Meine Aussage war, dass die von mir kreierte Hochsprache in wenigstens einem Punkt, nämlich der Schleife mit Hineinsprung, besser ist als C. Und das ist unabhängig davon, ob für die CPU ein C-Compiler existiert.
Josef G. schrieb: > Schleife mit Hineinsprung Der helle Wahnsinn. Das ist der Durchbruch!!! Leute, steigt um !!!
Josef G. schrieb: > *L.JP / springt zu *HERE > oper1 > oper2 > *HERE > oper3 > oper4 / weist VAR einen Wert zu > *RP.Z VAR / springt zu oper1 falls VAR = zero > > In C würde man hier eine function definieren, welche > oper3/4 ausführt und den Rückgabewert VAR erhält. > Und man würde eine while-Schleife verwenden, welche > oper1/2 ausführt, solange die function Null liefert. > > Die Schleife mit Hineinsprung erfüllt den gleichen > Zweck auf einfachere Weise. Die Hochsprache braucht dann > auch nicht das Konstrukt einer function mit Rückgabewert, Wenn Du diese Assemblersyntax schon als Hochsprache bezeichnest, wie sieht bei Dir dann eine maschinennahe Sprache aus? Bits? Sind Deine Bits eigentlich trinär oder quaternär? > sondern es reichen einfache Unterprogramme, bei welchen > alle Übergabe-Parameter gleichberechtigt sind. Oder aber auch in C:
1 | for (VAR = 0; !VAR; oper1, oper2) |
2 | {
|
3 | oper3; |
4 | oper4; |
5 | }
|
oder umordnen:
1 | for (;;) |
2 | {
|
3 | oper3; |
4 | oper4; |
5 | if (VAR) |
6 | break; |
7 | oper1; |
8 | oper2; |
9 | }
|
oder identisch zu Deinem Kram mit goto ... Ich weiß, es ist müßig, Dir daß zu erzählen, aber da Du so nett gefragt hast ... Viele Grüße
8Bit und n Korn schrieb: > for (VAR = 0; !VAR; oper1, oper2) > { > oper3; > oper4; > } Ok, hab ich nicht dran gedacht. Bei meiner Lösung sieht man halt unmittelbar, was ausgeführt wird. > for (;;) > { > oper3; > oper4; > if (VAR) > break; > oper1; > oper2; > } Da gilt dasselbe wie hier: Beitrag "Re: Gibt es eine Programmiersprache mit diesem Schleifentyp?"
8Bit und n Korn schrieb: > for (VAR = 0; !VAR; oper1, oper2) > { > oper3; > oper4; > } Ist das überhaupt dasselbe wie bei mir? Ich meine, die for-Schleife macht das: VAR = 0 Test !VAR ==> Abbruch oper3 oper4 oper1 oper2 Test !VAR ==> Abbruch oper3 ... Das ist etwas anderes als bei mir: oper3 oper4 Test !VAR ==> Abbruch oper1 oper2 oper3 oper4 Test !VAR ==> Abbruch oper1 ...
Josef G. schrieb: > dasselbe wie bei mir Josef G. schrieb: > etwas anderes als bei mir Wen interessiert das? Jeder mit ein paar mehr Latten am Zaun hätte diesen Katastrophentread längst dichtgemacht!
Josef G. schrieb: > Bei meiner Lösung > sieht man halt unmittelbar, was ausgeführt wird. Nee. Das ist ja das Problem: Bei deiner Lösung sieht niemand außer dir irgendwas unmittelbar. Dein ganzes Projekt ist für den Rest der Welt völlig sinnfrei.
Ach... so ganz sinnfrei ist das Projekt nun auch wieder nicht. Ist doch ein geiler Thread - So als unterhaltende Entspannung zwischendurch oder wenn man sich eh nicht mehr konzentrieren kann. Und als Studentenübung für Kryptoanalytiker ist die Doku durchaus geeignet.
Josef G. schrieb: > 8Bit und n Korn schrieb: >> for (VAR = 0; !VAR; oper1, oper2) >> { >> oper3; >> oper4; >> } > > Ist das überhaupt dasselbe wie bei mir? Hubsdi, da hast Du natürlich völlig recht. Ich bessere nach:
1 | for (oper3, oper4; !VAR; oper3, oper4) |
2 | {
|
3 | oper1; |
4 | oper2; |
5 | }
|
Allerdings auch nicht wirklich schön ... ich präferiere die while Version. Hast Du eigentlich schon einen TCP/IP Stack für Deine CPU? Viele Grüße und Prost
Zur Schleife mit Hineinsprung und anderen Aspekten der Hochsprache: Beitrag "Gibt es eine Programmiersprache mit diesem Schleifentyp?"
Josef G. schrieb: > Zur Schleife mit Hineinsprung und anderen Aspekten der Hochsprache: > Beitrag "Gibt es eine Programmiersprache mit diesem Schleifentyp?" Das wollte gar keiner wissen. Josef G. schrieb: > wird vielleicht auch einer eine ernsthafte > Anwendung dafür finden. Ich selber weiß derzeit keine. Die wär viel eher interessant. Diese Äußerung stammt noch vom Juni 2013. Ich nehme an, der Erfinder hat nun wenigstens selbst eine ernsthafte Anwendung !!!???
Angehängte Dateien:
-
GoL.jpg
210 KB
Angeregt durch diesen Thread Beitrag "Conways Game of Live zu langsam auf Z80" habe ich Conway's Game of Life für meinen Rechner programmiert. Das Spielfeld hat Torus-Topologie und 128*128 Zellen. Jede Iteration dauert 1 Sekunde. Das Startbild kann ausgewählt werden, die bisher zur Verfügung stehenden Startbilder sind noch vorläufig. Als Entwicklungs-Regel gibt es bisher nur die bekannte Standard-Regel. Die Auswertung der Regel erfolgt mittels einer Tabelle, für andere Regeln wäre nur diese Tabelle zu ändern. Siehe Seite Hawa meiner Website. Hier noch der Wikipedia-Artikel zum Thema: http://de.wikipedia.org/wiki/Conways_Spiel_des_Lebens
Hast du das mit deiner Sprache erschaffen, die du hier vorgestellt hast? Gruss
peter schrieb: > Hast du das mit deiner Sprache Nein. Das Programm ist unmittelbar in Maschinencode geschrieben und Teil der Software der Test-Steckkarte in Steckplatz 1.
Josef G. schrieb: > Das Programm ist unmittelbar in Maschinencode geschrieben Hast du mal einen Quelltext?
Josef G. schrieb: > Das Programm ist unmittelbar in Maschinencode geschrieben > Jede Iteration dauert 1 Sekunde. Hast du das absichtlich so lansam gemacht? Selbst auf dem guten alten PET2001 lief das wesentlich schneller.
X. schrieb: > Hast du das absichtlich so lansam gemacht? Nein, geht nicht schneller. > Selbst auf dem guten alten PET2001 lief das wesentlich schneller. Wieviele Zellen hatte das Spielfeld?
Christian J. schrieb: > Hast du mal einen Quelltext? Den Assembler-Quelltext habe ich leider nur handgeschrieben auf Papier. Der Code macht Gebrauch davon, wie die Pixel des Bildschirms ins RAM gemapped sind, und wird deshalb für eine andere Hardware kaum von Interesse sein.
Habe das Emulations-Programm für Linux-PC geändert. Es kann nun auch einen Teil der Software der Datei teca ausführen. Man kann Conway's Game of Life auf einem Linux-PC testen. Falls jemand daran denkt, das Programm auszuprobieren: Es muss damit gerechnet werden, dass während der Iteration die Anzeige flackert, jedenfalls ist das an meinem PC so. Auf der Seite Emul meiner Website wird das Emulationsprogramm beschrieben. Nach dem Starten des Emulationsprogramms startet man Game of Life mit 1.CGL (zur Eingabe des Zeichens 1 die Tasten 6 1 drücken). Nach Auswahl des Startbildes (0..7) und der Entwicklungs-Regel (bisher nur 0 verfügbar) startet die Iteration. Anders als am FPGA-Board ist das Gedrückt-Halten der Leertaste erforderlich. Die Iteration stoppt nach dem Loslassen der Taste, wenn alle aufgelaufenen Leerzeichen abgearbeitet sind. Das Drücken einer beliebigen anderen Taste beendet das Programm. Die 8 Startbilder liegen in der Datei teca ab Adresse 0x4000. Jedes Bild belegt 2 KByte. Wer andere Startbilder testen möchte, kann sie in die Datei teca kopieren. Das Bitmapping würde ich hier mitteilen, falls Interesse besteht.
PS: Bei Bild 5 interessantes Detail ab Iteration 018f,
welches bei Iteration 01a8 periodisch wird.
Josef G. schrieb: > PS: Bei Bild 5 interessantes Detail Sorry, falsche Aussage. Offenbar habe ich das Startbild versehentlich überschrieben, ich finde es nicht mehr. Josef G. schrieb: > Es muss damit gerechnet werden, dass während der Iteration > die Anzeige flackert, jedenfalls ist das an meinem PC so. Das gilt natürlich nur für die Emulation am PC. Am realen System flackert nichts. X. schrieb: >> Jede Iteration dauert 1 Sekunde. > Hast du das absichtlich so lansam gemacht? Inzwischen habe ich eine Lösung mit nur 0.75 Sekunden. Habe ich aber noch nicht auf der Website. Ich bin noch am Nachdenken über Änderungen der Startbild-Auswahl.
Ich sehe im Bild diesen Pollin TV Decoder. taugt der was? Den wollte ich mir ggf auch bestellen, um den Stromfresser "Monitor" mal beiseite zu legen.
Der Neue schrieb: > Ich sehe im Bild diesen Pollin TV Decoder. Hab ich nicht, kenn ich nicht. Muss ein Irrtum sein. Josef G. schrieb: > Inzwischen habe ich eine Lösung mit nur 0.75 Sekunden. > Habe ich aber noch nicht auf der Website. Ist jetzt auf meiner Website verfügbar (Datei teca). Ausserdem gibt es eine neue Version des Emulationsprogramms mit verbesserter Eingabemöglichkeit für Ziffernfolgen.
Josef G. schrieb: > Ist jetzt auf meiner Website verfügbar (Datei teca). > Ausserdem gibt es eine neue Version des Emulationsprogramms > mit verbesserter Eingabemöglichkeit für Ziffernfolgen. Falk Brunner schrieb: > Das ist ja eine FUNDAMENTALE Neuerung, die dem Projekt sicher zum > Durchbruch verhelfen wird . . . !!! Furchtbar aufregende Neuerungen ohne Ende, nur der Nutzen bleibt stur bei Null,Nichts. Tipp: Mal ein anderes Projekt versuchen.
Marius schrieb: > der Erfinder hat nun wenigstens selbst eine ernsthafte > Anwendung: Josef G. schrieb: > habe ich Conway's Game of Life für meinen Rechner programmiert Da sage noch einer es gäbe keine ernsthafte Anwendung :-)))
Bei Startbild 0..3 hat jetzt das Spielfeld nur noch 64*64 Zellen. Jede Iteration dauert nur noch 0.27 Sekunden. Bei Startbild 4..7 gilt wie bisher 128*128 Zellen / 0.75 Sekunden.
Peter schrieb im Beitrag #3959749: > Bei mir braucht das FPGA Board ungefähr 0,35 ns pro Berechnung Wie hast du das gemessen? Ich habe es so gemacht: 60 Sekunden laufenlassen und aus dem Zählerstand die Anzahl der Iterationen ablesen. 60 Sekunden durch diese Zahl dividieren. > Reicht das für genügend Iterationen bevor das Bild ruckelt? Die Frage verstehe ich nicht. Der Video-Generator liest die aktive Seite des Video-RAM aus. Die CPU erzeugt das nächste Bild in der inaktiven Seite des Video-RAM. Wenn das Bild fertig ist, schaltet die CPU die Video-Ausgabe um. Die vorher inaktive Seite wird jetzt zur aktiven Seite. Der Video-Generator übernimmt diese Umschaltung verzögert während der Austast-Lücke zwischen zwei Bildern. Die CPU beginnt mit dem Aufbau des nächsten Bildes in der jetzt inaktiv gewordenen Seite des Video-RAM erst eine Sechzigstel Sekunde, nachdem sie die Video-Ausgabe umgeschaltet hat. Spätestens ab diesem Zeitpunkt liest der Video-Generator nicht mehr aus der inaktiv gewordenen Seite.
Hier ist ein ziemlich interessanter Artikel von 1982 über die "Erfindung des Diamanten" durch das De Beers-Kartell: http://www.theatlantic.com/magazine/archive/1982/02/have-you-ever-tried-to-sell-a-diamond/304575/ Es ist schon ziemlich unglaublich, wie sich Märkte durch Werbung manipulieren und "schaffen" lassen. In den Köpfen der meisten Menschen von Heute ist das ja eher eine neue Entwicklung, aber De Beers hat es in der 1930ern schon sehr effektiv praktiziert. Abgesehen davon möchte ich anmerken, dass es generell ziemlich schwierig ist, Zeiten von weniger als 1 ns auf einem FPGA zu messen. Ohne weitere Tricks, würde man dafür Taktfrequenzen von über einem GHz benötigen. Das erscheint auf einem Spartan 3 doch sehr unwahrscheinlich. Es ist also davon auszugehen, dass Peter (Gast), uns hier einen Bären aufbinden will. Eine andere Frage ist natürlich, welche Geschwindigkeit man von einem Game-Of-Life zellulären Automaten erwarten würde. Josef G. erwähnt, dass seine Implementierung für ein 64x64 Feld mit 4096 Elementen 0.27s (270 000 µs) Sekunden für die Berechnung benötigt. Das sind 270 000 / 4096 = 65.9 µs pro Element. Für die Bewertung der Programmeffizienz wäre die Anzahl der benötigten Taktzyklen pro Element die ausschlaggebende größe. Leider kenne ich die Taktfrequenz des Bomerenzcomputers nicht. Dem Ansatz, diese Information aus der Dokumentation zu entnehmen, stehen in diesem Thread schon häufiger dargestellte Hürden gegenüber. Aus diesem Grund will ich zur Vereinfachung einmal annehmen, dass der Prozessor ca. 1 MIPS erreicht. Auf Basis dieser Annahme kommt man zu dem Schluss, das die Berechnung eines Elements in der Implementation von Josef G. ca 65 Befehle benötigt. Wie viele Befehle benötigt eine Idealisierte Implementierung? Der Regeln des Zellulären Automatens lassen sich Wikipedia entnehmen: https://de.wikipedia.org/wiki/Conways_Spiel_des_Lebens Auf den ersten Blick lässt sich dieses durch einen population Count der acht benachbarten Zellen und zwei Vergleiche erledigen. Je nach Art der verfügbaren Adressmodes des Prozessors sind dieses zwischen 8 und 24 Befehle. Die zwei Vergleiche benötigen 4-6 weitere Befehle. Zum Darstellen des Ergebnisses und Schleifenzähler würde ich Pauschal 10 weitere Befehle annehmen. Damit komme ich auf 22-40 Befehle. Dieses lässt also annehmen, dass sich gegenüber einer Implementation mit 65 Befehlen noch einiges Optimieren lässt. Hier übrigens eine Seite mit GOL Implementation in vielen unterschiedlichen Sprachen: http://rosettacode.org/wiki/Conway%27s_Game_of_Life Man scheint sich Mühe gegeben zu haben, die Varianten möglichst ineffizient und schwer verständlich darzustellen. Wie z.B. an der C-Implementiert ersichtlich. Zelluläre Automaten sind etwas tolles. Wer erinnert sich nicht an Stephen Wolframs Buch "A New Kind of Science" vor 10 Jahren? Im Vorfeld wurde erzählt, er könne an Hand bestimmer zellulärer Automaten die Enstehung intelligenten Lebens nachweisen. Wie wir jetzt wissen, ist ihm dieses aber nicht gelungen. Stephen Wolfram ist übrigens der Entwickler/Erfinder der Mathematiksoftware "Mathematika" und hat mit 20 Jahren am Caltech promoviert. Eine interessante, neuere, Entwicklung im Bereich der Automaten ist Microns Automata-Prozessor. http://www.micron.com/~/media/documents/products/other-documents/automata_processing_technical_paper.pdf?la=en Hierbei handelt es sich aber wiederum um etwas völlig Anderes. Micron hat einen Prozessor entwickelt, der nichtdeterministische finite Automaten evaluieren kann. Hiermit lassen sich z.B. sehr komplexe Pattern matching Probleme lösen. Spannend ist dieses, weil es sich eigentlich um ein sehr akademisches Konzept handelt, dass jetzt tatsächlich von einer Firma mit den entsprechenden Mitteln zur Umsetzung gebracht wird. Natürlich ist dieses auch den Aufgabenstellung der aktuellen Zeit geschuldet. Denn gerade für Anwendungen im Bereich der Homeland Security ist es notwendig, Muster in sehr großen Datenmengen zu erkennen. Sollte Micron am Aufbau des neuen NSA Datacenter beteiligt sein? http://www.forbes.com/sites/kashmirhill/2013/10/07/the-nsas-hugely-expensive-utah-data-center-has-major-electrical-problems-and-basically-isnt-working/ Man könnte es sich vorstellen, denn Micron hat eine große Fertigungsstätte in Lehi, in der diese Prozessoren gefertigt werden können. FPGAs sind übrigens auch interessant. Allerdings sind Soft-Cores inzwischen ein relativ alter Hut. Zu frühen Implementierungen kann man in Jan Gray Blog Viel nachlesen.
Trillian ist ein Cybernaut schrieb: > Leider kenne ich die Taktfrequenz ... nicht. Josef G. schrieb: > habe ich die Dauer eines Halbzyklus ... auf 320ns verkürzt. > CPU-Befehle dauern 2 oder 4 oder 6 Halbzyklen. Ist richtig, dass die Information auf meiner Website nicht leicht zu finden ist. Die Dauer 320ns für einen Halbzyklus steht auf der Seite Hawa, und man muss erst auf der Seite CPU-doku nachschauen, was das bedeutet. Vielleicht sollte ich da was ändern.
Sehe ich genauso wie Holm. Klasse Projekt. Gute Doku. Wichtig ist aber auch, 2x mal die Woche ein Zeichen im Wikiartikel zu ändern, oder hier etwas zu posten (wie ich es gerade mache), damit der Thread gepusht wird. Wir verfolgen das alle mit Spannung.
Josef G. schrieb: > Trillian ist ein Cybernaut schrieb: >> Leider kenne ich die Taktfrequenz ... nicht. > > Josef G. schrieb: >> habe ich die Dauer eines Halbzyklus ... auf 320ns verkürzt. >> CPU-Befehle dauern 2 oder 4 oder 6 Halbzyklen. > > Ist richtig, dass die Information auf meiner Website nicht leicht > zu finden ist. Die Dauer 320ns für einen Halbzyklus steht auf der > Seite Hawa, und man muss erst auf der Seite CPU-doku nachschauen, > was das bedeutet. Vielleicht sollte ich da was ändern. Das ist alles, was Dir auf meinen konstruktiven und gut recherchierten Beitrag einfällt? Ich bin enttäuscht! 640ns pro Taktzyklus ist aber nicht sehr schnell. Da muss sich ein 6502 nicht verstecken.
Trillian ist ein Cybernaut schrieb: > Das ist alles, was Dir auf meinen ... Beitrag einfällt? Der Beitrag hat mich durchaus beeindruckt. Josef G. schrieb: > Ist richtig, dass die Information auf meiner Website nicht > leicht zu finden ist... Vielleicht sollte ich da was ändern. Die Information zur Taktfrequenz der CPU ist jetzt hervorgehoben. ----------------------------------------------------------------- Wegen der Torus-Topologie des Spielfeldes beim Game of Life sind manchmal interessante Muster schlecht zu erkennen, weil sie auf gegenüberliegende Ränder verteilt sind. Deshalb habe ich jetzt eine Möglichkeit zum vertikalen und horizontalen Scrollen des Bildes mittels Cursortasten programmiert. Siehe Seite Hawa. Zur geänderten Bedienung bei Verwendung des Emulationsprogramms am PC siehe Seite Emul.
Josef G. schrieb: > peter schrieb: >> Hast du das mit deiner Sprache > > Nein. Das Programm ist unmittelbar in Maschinencode geschrieben > und Teil der Software der Test-Steckkarte in Steckplatz 1. Wieso nicht? Das wär doch mal eine Gelegenheit gewesen, die Benutzbarkeit deiner Sprache (den größten Kritikpunkt deiner Gegner hier) zu demonstrieren. Stattdessen giest du das ganze wieder in die Firmware.
Masl schrieb: > den größten Kritikpunkt deiner Gegner hier Wenn das schon der größhte Kritikpunkt wär dann wär das ganze Projekt bereits als Erfolg zu werten.
Lucky schrieb: > als Erfolg ... lässt sich dieses Projekt nun nicht gerade werten. Das ergibt sich aus der einfachen Formel ERFOLG = MÜHE × NUTZEN
Masl schrieb: > Das wär doch mal eine Gelegenheit gewesen, die Benutzbarkeit deiner > Sprache (den größten Kritikpunkt deiner Gegner hier) zu demonstrieren. > Stattdessen giest du das ganze wieder in die Firmware. Eben. So wie ich das sehe gibt es keine richtige Beispielapplikation, die in deiner Sprache verfasst wurde. Wenn sogar der Erfinder der Sprache es einfacher findet, Assembler aufn Papier zu schreiben und direkt Maschinencode einzuhacken, dann spricht das nicht unbedingt für die Sprache. Oder welchen Grund hatte diese Entscheidung?
1 | *PGM ARITH |
2 | *CON INFO -3:ADD..2:SUB..1:MUL..0:DIV..else:END |
3 | MASK -3210:....OPA:...........OPB: |
4 | *AUT AA. /03 BB. /01 SELECT /00 |
5 | *BEGN |
6 | *L.JP |
7 | 1INPUTN /d1 AA. 1INPUTN /e0 BB. 1LFEED |
8 | *CASE /03 SELECT |
9 | 1 oGET AA. oADD BB. oSTO AA. |
10 | *NEXT /02 |
11 | 1 oGET AA. oSUB BB. oSTO AA. |
12 | *NEXT /01 |
13 | 1 oGET AA. oMUL BB. oSTO AA. |
14 | *NEXT /00 |
15 | 1 oGET AA. oDIV BB. oSTO AA. oPUR BB. |
16 | *LAST |
17 | 1PRINTN /d1 AA. |
18 | *IF.Z SELECT |
19 | 1PRINTN /e0 BB. |
20 | *ENDF |
21 | *HERE |
22 | 1LFEED |
23 | 1PRINTS /c4 INFO 1LFEED 1PRINTS /c4 MASK |
24 | 1INPUTN /c9 SELECT 1 oGET /04 oTTL SELECT |
25 | *RP.1 /f0 |
26 | *RETN |
part1.png und part2.png zeigen den per 1.DEMO abrufbaren Quelltext des Beispiel-Programms, darunter steht nochmal der Text im Ganzen. run.png zeigt den Ablauf beim Compilieren und Testen. Kondensator-Paul schrieb: > direkt Maschinencode einzuhacken, dann spricht das nicht unbedingt > für die Sprache. Oder welchen Grund hatte diese Entscheidung? Die Sprache ist nicht dafür gemacht, Assembler-Programmierung oder direkte Hexcode-Programmierung zu ersetzen. Der vom Compiler erzeugte Code ist kein Maschinencode. An der Stelle von zB. 1INPUTN /d1 AA. steht im Compilat die Nummer der Steckkarte, die Nummer des Kommandos INPUTN auf der Steckkarte, das Format der übergebenen Parameter (1 const-Byte, 1 Variable), das const-Byte selber und der Zeiger auf die Variable. Bei Ausführung des Programms durch den Interpreter des Compilats dauert allein das Aufrufen des Kommandos INPUTN 40 Vollzyklen. Hinzu kommt die Ausführungszeit des auf der Steckkarte befindlichen Maschinencodes des Kommandos. Die Sprache ist dazu konzipiert, solche Steckkarten-Kommandos aufzurufen. Dazu stellt sie Variablen und Kontrollstrukturen bereit. Wollte man etwa Game of Life in dieser Spache programmieren, müsste eine Steckkarte Kommandos wie zB. Setzen von Bildpunkten anbieten. Und alles wäre furchtbar langsam. Ausserdem ist die Handhabung von Arrays noch nicht zufriedenstellend gelöst. Die Test-Steckkarte habe ich ursprünglich nur dazu erstellt, die Software der Haupt-Platine testen zu können, insbesondere die Einbindung von Steckkarten durch diese Software der Hauptplatine. Die Test-Steckkarte ist nicht als endgültige Lösung gedacht. > So wie ich das sehe gibt es keine richtige Beispielapplikation, Dazu wäre eine umfangreiche Steckkarten-Sortware erforderlich. Ich hatte mal gehofft, dass andere Leute Steckkarten-Software entwickeln und anbieten. Alle dazu erforderlichen Informationen über Schnittstellen sind auf meiner Website verfügbar.
Josef G. schrieb: > Ich hatte mal gehofft, dass andere Leute Steckkarten-Software > entwickeln und anbieten. Träumer. Immerhin, Du HATTEST mal gehofft.
In der Hochsprache gibt es neue Operationen, welche die Berechnung von komplexen Sprungbedingungen erleichtern. Schaut mal auf die Seite SYS-doku meiner Website.
Josef G. schrieb: > In der Hochsprache gibt es neue Operationen, welche die > Berechnung von komplexen Sprungbedingungen erleichtern. > Schaut mal auf die Seite SYS-doku meiner Website. In der heutigen Zeit ist Konsequenz leider ein seltener Charakterzug, vor allem bei Politikern und Managern. Zumindest Josef G. kann man dies aber nicht vorwerfen. Konsequenz heißt, auch Holzwege zu Ende zu gehen.
Masl schrieb: > Holzwege zu Ende zu gehen Holzwege, die in erster Linie Spaß machen sind keine Holzwege, sondern gehören just gerade zum Sinn des Lebens. Bestes Holz ist allenfalls Josefs Erwartung von der Zweckmäßigkeit und den großen Einsatzmöglichkeiten seiner Technik-Machbarkeitsstudie für andere.
Hm, interessantes Projekt, bin gerade über den Thread gestolpert. Im Gegensatz zu all den du-bist-Scheisse-Sagern muss ich doch zugeben, dass das Ganze ziemlich faszinierend ist, auch wenn ich den praktischen Nutzen nicht ganz sehe. Aber ich finde es schön, wenn sich jemand so etwas erschafft und sich tiefgreifend mit einem Thema beschäftigen kann, und selbstgebaut ist sowieso zehnmal geiler. (Na gut, die Idee mit der Ablösung des Dezimalsystem durch Hex ist dann vielleicht doch etwas lustig^^). Aber wie viele Elektronikbasteleien sind 100% nützlich und bringen die Menschheit weiter? (und sind nicht nur deshalb geil, weil man sie selbst gebastelt hat? ... Lass dich nicht aufhalten ;)
Josef G. schrieb: > Realisierungen des Systems gab es bisher auf folgenden Boards: > Spartan-3A Starter, Spartan-3E Starter, Nexys2, Altera DE1 > > Es gibt nun auch eine Realisierung auf dem Altera DE0 Board. Die Konfiguration für das Spartan-3A Starter Kit funktioniert auch auf dem Spartan-3AN Starter Kit. Beitrag "Re: xilinx xucks!" Andreas S. schrieb: > Du hast eine eher seltene Tastatur mit Power/Sleep/Wakeup-Tasten > verwendet. Ich konnte ... nirgendwo auftreiben und habe auf > meiner Tastatur keine Power/Sleep/Wakeup-Tasten. Watt nu? Die Tastatur-Belegung wurde geändert. Die Tasten Power/Sleep/WakeUp werden nicht mehr verwendet.
Josef G. schrieb: > Zur Schleife mit Hineinsprung und anderen Aspekten der Hochsprache: In dem genannten Thread gibt es neue Beiträge. Beitrag "Re: Gibt es eine Programmiersprache mit diesem Schleifentyp?"
Josef G. schrieb: > In dem genannten Thread gibt es neue Beiträge. Wie schauts mal mit neuen Projekten Deinerseits aus? Wird langsam langweilig. Mußt Du diesen Thread hier nun schon mit Verweisen auf andere oben halten ???
Felix schrieb: > Na gut, die Idee mit der Ablösung des Dezimalsystem > durch Hex ist dann vielleicht doch etwas lustig^^ Sorry wg. OT, aber kann's mir nicht verkneifen, da ich gerade diesen aktuell gesperrten Thread gesehen habe: Beitrag "Re: Algorithmus Pi-Berechnung" >> http://de.wikipedia.org/wiki/Bailey-Borwein-Plouffe-Formel > Ganz nett, hatte ich mal auf nem C64 um π auf 1024 Binärstellen zu > bestimmen. Allerdings bekommt man damit nur die Stellen im 16er-System, > die mühsam ins Dezimalsystem umgerechnet weren müssen.
Josef G. schrieb: > Sorry wg. OT, aber kann's mir nicht verkneifen, da ich > gerade diesen aktuell gesperrten Thread gesehen habe: Und wieder ein weiterer peinlicher Beitrag um den todgeweihten Thread hier ein erneutes Mal zu pushen.
Gerade gefunden: Beitrag "Re: Z80 Einplatinencomputer für Lernzwecke" >> Speicherbanking muß nicht zwangsläufig 64 K sein > Das kann es garnicht, man braucht ja einen Speicherbereich, der > in beiden Bänken gültig ist für das gemeinsame Programm - z.B. > das Programm, das zwischen den Bänken umschaltet. Nur so kann > man Unterprogramme in verschiedenen Bänken aufrufen und so > Programme mit mehr als 64k realisieren. Tja, meine CPU kann das, von einer 64K-Seite in eine andere springen, ohne gemeinsamen Speicherbereich.
Josef G. schrieb: > Tja, meine CPU kann das, von einer 64K-Seite in eine > andere springen, ohne gemeinsamen Speicherbereich. Wahnsinn
Josef G. schrieb: > Tja, meine CPU kann das, von einer 64K-Seite in eine > andere springen, ohne gemeinsamen Speicherbereich. Tja, schade, dass Deine CPU überhaupt nicht praxistauglich und damit nur für den Müll ist.
Frank M. schrieb: > Tja, schade, dass Deine CPU überhaupt nicht praxistauglich Inwiefern ist sie nicht praxistauglich? Sehe ich ganz und gar nicht so.
Josef G. schrieb: > Inwiefern ist sie nicht praxistauglich? > Sehe ich ganz und gar nicht so. Dann nenne bitte die praxisrelevanten Anwendungen, die für Deine CPU existieren - und die Werkzeuge für den Programmierer. Welche Standard-Hochsprachen kann man nutzen?
Josef G. schrieb: > Inwiefern ist sie nicht praxistauglich? Praxistauglich ist etwas subjektiv. Für dich ist mag sie praxistauglich sein, aber andere Leute sehen das anders. Frank M. schrieb: > Welche Standard-Hochsprachen kann man nutzen? Dieses Thema hatten wir in einem anderen Thread: Beitrag "Gibt es eine Programmiersprache mit diesem Schleifentyp?" Auch da gingen die Ansichten deutlich auseinander. Für das, was ihm hoch erscheint, müssen sich andere ziemlich tief bücken. Und für ihn ist das bestimmt die Standardsprache seines Rechners.
:
Bearbeitet durch User
Josef G. schrieb: > Inwiefern ist sie nicht praxistauglich? > Sehe ich ganz und gar nicht so. Du schreibst ja deine eigenen Anwendungen nicht mit deiner Sprache. Vor kurzem hast du doch irgendeine Beispielapplikation vorgestellt. Was war das noch? Game of Life? Hab jetzt nicht gesucht. Das Teil ist auf einer deiner Steckkarten implementiert, allerdings in Maschinencode. Es wird schon einen Grund haben, wenn der Entwickler lieber rohen Maschinencode hakt anstatt seine eigene Sprache zu benutzen. Erklärung kam damals imho keine von dir.
A. K. schrieb: > Und für ihn ist das > bestimmt die Standardsprache seines Rechners. Das ist mir ja klar. Aber "Standard" sieht anders aus. ;-) Was soll ich mit einer Programmiersprache, in der man keine Programme schreiben kann? Mit einer Schleife mit "Hineinsprung" ist es nicht getan. Ausserdem muss man bei dieser "Programmiersprache" Masochist sein, um sie sich anzutun - und zwar einer von der harten Sorte. Solange Josef keine ernstzunehmenden Anwendungen vorweisen kann, ist sein "Rechner" für die Katz. Also nicht praxistauglich.
@ A. K. (prx) >Auch da gingen die Ansichten deutlich auseinander. Für das, was ihm hoch >erscheint, müssen sich andere ziemlich tief bücken. HAHAHA ;-) YMMD! Gab's da nicht mal ne Firma HochTief?
Benjamin schrieb: > Vor kurzem hast du doch irgendeine Beispielapplikation vorgestellt. Was > war das noch? Game of Life? Hab jetzt nicht gesucht. Ja, Game of Life habe ich auch in Erinnerung. Aber soweit ich das noch im Kopf habe, war die Refresh-Rate pro Generation dermaßen tief im Keller, dass ein Z80 (mit dem Josef jetzt hier seinen Rechner vergleicht) wesentlich schneller war. > Erklärung kam damals imho keine von dir. Wenn Josef keine Antwort weiß, dann gibt er das nicht zu, sondern schweigt einfach. Kopf in den Sand...
:
Bearbeitet durch Moderator
Frank M. schrieb: > Aber soweit ich das noch > im Kopf habe, war die Refresh-Rate pro Generation dermaßen tief im > Keller, dass ein Z80 (mit dem Josef jetzt hier seinen Rechner > vergleicht) wesentlich schneller war. Es ist genau umgekehrt. Beitrag "Re: 8bit-Computing mit FPGA" Bei weniger Zellen geht es noch schneller. Beitrag "Re: 8bit-Computing mit FPGA" Beitrag "Re: 8bit-Computing mit FPGA" Frank M. schrieb: > Dann nenne bitte die praxisrelevanten Anwendungen, > die für Deine CPU existieren Abgesehen von Conway's Game of Life und dem in der Hochsprache geschriebenen Demo-Arithmetikprogramm Beitrag "Re: 8bit-Computing mit FPGA" gibt es bisher keine. Aber inwiefern folgt daraus, dass die CPU nichts taugt? > und die Werkzeuge für den Programmierer. > Welche Standard-Hochsprachen kann man nutzen? Die CPU ist so gemacht, dass sie sehr leicht in Assembler zu programmieren ist. Frank M. schrieb: > Solange Josef keine ernstzunehmenden Anwendungen > vorweisen kann, ist sein "Rechner" für die Katz. Mag sein. Aber gerade deshalb werbe ich ja hier dafür, dass Hobbyisten mit dem Rechner experimentieren, damit vielleicht einer eine ernsthafte Anwendung findet.
... vielleicht findet der Josef nun nach jahrelangem Mißerfolg endlich seinen Realitätssinn? Ok, wir leben in einer werbebetonten Zeit. Aber Werbung allein kann doch keine Zweckmäßigkeit erzwingen! Ernsthafte Anwendung ausgeschlossen by Design.
Josef G. schrieb: > Es ist genau umgekehrt. > Beitrag "Re: 8bit-Computing mit FPGA" Unsinn, 1 Sek. für 128x128 ist absolut lachhaft. Das hab ich 1982 mit dem ZX-Spectrum (Z80 bei 3,5MHz) bei 256x192 in Farbe(!) besser hinbekommen. > Bei weniger Zellen geht es noch schneller. Ist ja logisch. Sonst hast Du nichts zu bieten? > Abgesehen von Conway's Game of Life und dem in der > Hochsprache geschriebenen Demo-Arithmetikprogramm > Beitrag "Re: 8bit-Computing mit FPGA" > gibt es bisher keine. Du hast also NICHTS zu bieten. Conways Game of Life habe ich damals in den 70ern schon auf einem TI-59 Taschenrechner programmiert. Jede Generation wurde dann ausgedruckt, weil es sonst ausser der 13-stelligen 7-Segment-Anzeige kein anderes Gerät gab. Das gab ganz lange Papierstreifen... Deine Sprache, die wie Assembler aussieht, ist auch keine Hochsprache. Eine Hochsprache kann mehr als nur Assembler. Eine Schleife mit Hineinsprung macht auch noch lange keine Hochsprache aus. > Aber inwiefern folgt daraus, dass die CPU nichts taugt? Wenn sie etwas taugen würde, gäbe es Anwendungen dafür. Entweder von Dir oder den begeisterten Anhängern - welche es bis heute NICHT gibt. Warum wohl? Weil Deine CPU nichts taugt. In den 60er Jahren hättest Du vielleicht jemanden begeistern können. Aber das ist mittlerweile 55 Jahre her! Das war damals STEINZEIT. Du willst uns wirklich einen Neandertalerknochen als modernstes Essbesteck verkaufen? Sag mal, merkst Du eigentlich noch was? > Die CPU ist so gemacht, dass sie sehr leicht > in Assembler zu programmieren ist. Die Sprache Deines Assemblers ist absolut kryptisch und unverständlich. Ich kene KEINEN Assembler der kryptischer wäre. Und ich kenne eine Menge davon. Und Du verkaufst uns das als "sehr leicht ... zu programmieren"? In welcher Parallel-Welt lebst Du eigentlich? > Mag sein. Aber gerade deshalb werbe ich ja hier dafür, > dass Hobbyisten mit dem Rechner experimentieren, damit > vielleicht einer eine ernsthafte Anwendung findet. Ja, schon seit Jahren. Meinst Du, dass plötzliche Hunderte von Leuten vom Blitz getroffen werden und plötzlich ganz geil auf Deinen Rechner werden? Sorry, Josef. Begrabe das Ding. Das braucht kein Mensch. Noch nichtmals Du.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Unsinn, 1 Sek. für 128x128 ist absolut lachhaft. Das hab ich 1982 mit > dem ZX-Spectrum (Z80 bei 3,5MHz) bei 256x192 in Farbe(!) besser > hinbekommen. Meine Aussage "Es ist genau umgekehrt" bezog sich auf den Vergleich mit der Lösung in dem von mir verlinkten Thread. Nach neuestem Stand sind es nur 0.75 Sekunden Beitrag "Re: 8bit-Computing mit FPGA" Dabei wird jede der 128*128 Zellen mit 2*2 Pixel dargestellt. Mit 1 Pixel pro Zelle ginge es vermutlich schneller. Die Angabe 256*192 bei deiner Lösung: Ist das die Zahl der Zellen, oder lediglich die Zahl der Pixel, wobei jede Zelle mehrere Pixel belegt? Wie lange dauert eine Iteration?
Josef G. schrieb: > Nach neuestem Stand sind es nur 0.75 Sekunden Immer noch zu lahm. > Die Angabe 256*192 bei deiner Lösung: Ist das die Zahl der > Zellen, oder lediglich die Zahl der Pixel, wobei jede Zelle > mehrere Pixel belegt? 1 Pixel = 1 Zelle. > Wie lange dauert eine Iteration? Es muss heissen "dauerte". Das war 1982, meinst Du, ich spiele noch mit solchen Leichen rum? Dein "Rechner" hingegen ist 50 Jahre hinter dem aktuellen Stand und ist ineffizienter als ein Z80 von vor über 30 Jahren. Merkst Du noch irgend etwas? Hör doch auf, hier 50 Jahre alte Technik anzubieten. Und für wen? Für Retro-Fans? Die bauen lieber einen Z80 nach, der ist wenigstens alt. Aber um auf Deine Frage zurückzukommen: Es war weit weniger als eine halbe Sekunde - bei 3,5MHz. Da bist Du noch meilenweit entfernt. Mit wieviel MHz läuft denn Dein "Rechner"? Klasse, wie Du Fragen immer wieder ignorierst und Dir immer das rauspickst, wo Du (fälschlicherweise) meinst, einfach genialisch zu sein....
Frank M. schrieb: > Mit wieviel MHz läuft denn Dein "Rechner"? Ein Vollzyklus dauert 640 ns. CPU-Befehle dauern 1 oder 2 oder 3 Vollzyklen. > wie Du Fragen immer wieder ignorierst Welche sachliche Frage habe ich ignoriert?
Frank M. schrieb: > Das hab ich 1982 mit dem ZX-Spectrum (Z80 bei 3,5MHz) > bei 256x192 in Farbe(!) besser hinbekommen. Frank M. schrieb: > Josef G. schrieb: ... >> Die Angabe 256*192 bei deiner Lösung: Ist das die Zahl der >> Zellen, oder lediglich die Zahl der Pixel, wobei jede Zelle >> mehrere Pixel belegt? > > 1 Pixel = 1 Zelle. Aus dem Wikipedia-Artikel zum ZX-Spectrum: http://de.wikipedia.org/wiki/Sinclair_ZX_Spectrum > Im Gegensatz zum ZX81 übernimmt die ULA sämtliche Aufgaben der > Bilddarstellung, so dass der Prozessor damit nicht belastet wird. Weiss zwar nicht, was das genau bedeutet, aber vielleicht kann es die hohe Geschwindigkeit deiner Lösung teilweise erklären. Weiter heisst es in dem Wikipedia-Artikel: > Die Grafikauflösung beträgt 256 × 192 Bildpunkte (Pixel). > Für die Farbdarstellung werden jeweils 8 × 8 Pixel in Blöcke > zusammengefasst, so dass effektiv nur ein Farbraster von > 32 × 24 Blöcken zur Verfügung steht. Das steht im Widerspruch zu deiner Aussage. Eins von beiden ist falsch.
Frank M. schrieb: > Josef G. schrieb: >> Nach neuestem Stand sind es nur 0.75 Sekunden > > Immer noch zu lahm. > > Es muss heissen "dauerte". > Das war 1982, meinst Du, ich spiele noch mit > solchen Leichen rum? > Dein "Rechner" hingegen ist 50 Jahre hinter dem aktuellen Stand > Merkst Du noch irgend > etwas? Hör doch auf, hier 50 Jahre alte Technik anzubieten. Und für wen? > Für Retro-Fans? Joseph's Rechner lotet mit Hobbymittel die Architektur von 8bit Prozessoren aus. Das hat es vor 50 Jahren sicher nicht gegeben. Ich finde es gut sich unvereingenommen mit Computertechnik zu beschäftigen. Manche wie beispw. der CCC bezeichnen das als Hacker-ethos ( http://en.wikipedia.org/wiki/Hacker_ethic ): Teilen was man hat, respektvoll zu Mitstreitern und im positiven Sinne repektlos vor der Technik. Liegt vielleicht am mittleren Alter, ich mag Retro, ist supergut Hardware von der Pike auf zu lernen und zu verstehen: Retrocomputing auf FPGA Kann man in der Lehre als Beispiel verwenden. Vielleicht hat ja das auch Anteil an der Preizuerkennung. Beleidigende Kommentare wie die da oben gehören sicher nicht zum Hacker-ethos - also lass das bitte. MfG,
Josef hat einen eigenen Rechner entworfen. Sehr viel Arbeit reingesteckt. Er stellt das Konzept hier und auf seiner Webseite allen zur Verfügung. Sehr toll, mein Respekt vor der Arbeit und sehr löblich, dass er es offen legt. Aber er hat die Dokumentation auf seiner Webseite sehr sehr schlecht gestaltet. Anstatt vom Groben in's Detail zu gehen wird man sofort mit Hieroglyphen erschlagen. Mein erster Eindruck war: Man will nicht zeigen wie es geht, sondern beeindrucken, wie komplex das doch ist. Dann ging es aber los, dass die Beiträge zum Thema immer wieder künstlich gepusht werden. Genau wie der Wiki-Artikel. Mir scheint, er will, dass man jeden Tag über sein Projekt redet. Weil es ja das wichtigste von allen hier ist. Und dann fing es an, mich immer mehr zu nerven ....
Tipp an alle Genervten: Einfach den Thread nicht anklicken.
Softworker schrieb: > Dann ging es aber los, dass die Beiträge zum Thema immer wieder > künstlich gepusht werden. Genau wie der Wiki-Artikel. Mir scheint, er > will, dass man jeden Tag über sein Projekt redet. Weil es ja das > wichtigste von allen hier ist. > > Und dann fing es an, mich immer mehr zu nerven .... Das ist menschlich aber kein Grund Umgangsformen zu vergessen. Produktwerbung ist penetrant, Wahlwerbung ist ebenfall penetrant und geht manchen richtig an die Eier. Nachbars Geprotze mit dem Porsche, der laptop des Kollegen, Loddars Frauenverschleiß ... Tägliches Gepushe trifft auch nicht zu, IMHO läuft das projekt seit 4 Jahren und aller paar Monate kommt ein Update. Das ist bei anderen Hobby-projekten auch nicht anders. Wer weis das das seinem Puls nicht gut tut soll sich das auch nicht antun. Das schont die Gesundheit aller Beteiligten. MfG,
Fpga Kuechle schrieb: > Beleidigende Kommentare wie die da oben gehören sicher nicht zum > Hacker-ethos - also lass das bitte. Heute hält sich jeder für einen Hacker, der weiß dass man den Lötkolben nicht vorne anfasst. Du musst nicht glauben, einen irgendwie gearteten Ethos vertreten zu müssen, also lass das bitte. Zum Retro-Computing gibt's genügend Projekte, die vernünftig dokumentiert sind. Insofern ist nicht Retro-Computing an sich zu kritisieren, sondern die äußerst mangelhaften und kryptischen Sourcen, welche dem erklärten Ziel des TS, etwas für eine breite Schicht machen zu wollen, völlig entgegenstehen. Des TSs Penetranz sein verkorkstes Projekt der ungeneigten Leserschaft aufzudrängen und seine eigenen Beiträge mit Banalitäten und weitestgehend sinnfreien Links zu pushen, ist doch das, was ihm negative Reaktionen beschert. Würde das Projekt dem Credo seines Schöpfers entsprechen, dann würde es die Community annehmen und dann entstünde von selbst die vom TS gewünschte Diskussion. Dass dem nicht so ist und der TS selbst pusht, zeigt doch was das für 'ne Krücke ist. Softworker schrieb: > Mir scheint, er will, dass man jeden Tag über sein Projekt redet. Natürlich, sein Projekt hat ihn immense Anstrengungen und Teile seines Lebens gekostet, das wurde zu seinem Leben. Der hält mit Zähnen und Klauen daran fest, egal wie die Wirklichkeit aussieht.
MWS schrieb: > Des TSs Penetranz sein verkorkstes Projekt der ungeneigten Leserschaft > aufzudrängen und seine eigenen Beiträge mit Banalitäten und > weitestgehend sinnfreien Links zu pushen, ist doch das, was ihm negative > Reaktionen beschert. Nö ich seh hier eher die Lust am Beleidigen und Erniedrigen als Ursache mancher Kommantare hier. Auch die Auffassung zu "Penetranz", "Banalität" und "sinnfreien Links" teile ich mit Bezug auf Joseph's Projekt nicht. Bei "ungeneigten Leserschaft" neige ich aber stark zu Zustimmung. Was aber das Problem der Leserschaft ist und nicht Josephs. MfG,
Fpga Kuechle schrieb: > Was aber das Problem der Leserschaft ist und nicht Josephs Doch, das ist sein Problem, denn er erzeugt diese Reaktion. > Nö ich seh hier eher die Lust am Beleidigen und Erniedrigen als Ursache > mancher Kommantare hier. Irgendwann geht's jedem auf den Zeiger, dann wird der Ton schärfer.
Frank M. schrieb: > Josef G. schrieb: ... >> Die CPU ist so gemacht, dass sie sehr leicht >> in Assembler zu programmieren ist. > > Die Sprache Deines Assemblers ist absolut kryptisch und unverständlich. > Ich kene KEINEN Assembler der kryptischer wäre. Und ich kenne eine Menge > davon. Und Du verkaufst uns das als "sehr leicht ... zu programmieren"? Mit "sehr leicht in Assembler zu programmiern" meine ich zB.: Es gibt keine Flags ausser dem Carry-Flag. Der Programmierer muss nicht ständig nachschauen, wie welche Flags beeinflusst werden. Die Adressregister X,Y,Z sind vollständig gleichberechtigt. Es gibt bei den Daten ausser "immediate" nur eine einzige Adressierungsart: Ein Adressregister zeigt auf die Speicherstelle.
:
Bearbeitet durch User
Auch wenn ich zu 100% sicher bin, dass es sinnlos ist, hier mal zum Vergleich, wie eine GESCHEITE Darstellung so eines Projekts aussehen kann, mit der ein normaler Mensch was anfangen kann! Und dort gibt es soger richtig viele, GUTE Demos! https://www.mikrocontroller.net/articles/16/32Bit_Computer/Konsole SO wollen wir das sehen!
Gab ja schon lange nichts Neues mehr. Jetzt ist das sinnlose Projekt wohl doch eingeschlafen?
Keule schrieb: > Gab ja schon lange nichts Neues mehr. Jetzt ist das sinnlose > Projekt wohl doch eingeschlafen? Weck mal hier keine schlafenden Hunde! "Sinn" war ja gerade diesen sinnlosen Thread am Leben zu erhalten.
Weiter oben habe ich ein Format für Gleitpunkt-Zahlen vor- geschlagen, welches für Intervall-Arithmetik geeignet ist. Beitrag "Re: 8bit-Computing mit FPGA" Ich habe diesen Vorschlag nun selber umgesetzt, mit kleinen Änderungen: Das Vorzeichen-Bit steht an anderer Stelle, und im Hex-String wird der Exponent anders dargestellt. Beitrag "Ein Vorschlag zur Intervall-Arithmetik" Ausserdem habe ich meine Website überarbeitet. http://www.bomerenzprojekt.de
Zuverlässig wie ein Hardware-Watchdog hält Josef diesen Thread am Leben.
Kammon schrieb: > Zuverlässig wie ein Hardware-Watchdog hält Josef diesen Thread am Leben. Und das ist auch gut so. Gäbe es es hier die Rubrik 'Psychologie' so wäre dieser Thread da natürlich bestens aufgehoben. Über Sinn und Unsinn des Projektes und der begleitenden Grundüberzeugungen zu diskutieren ist natürlich nur insofern nützlich als das man die Reaktion des Testsubjektes auf äußere Einflussnahme beobachten kann. Ich denke das hier passt ganz gut zum Thema: http://www.spiegel.de/einestages/die-drei-jesusse-von-ypsilanti-a-947782.html
Michael K. schrieb: > die Reaktion des Testsubjektes auf äußere Einflussnahme Ist eine solche hier überhaupt feststellbar?
Michael K. schrieb: > so wäre dieser Thread da natürlich bestens aufgehoben. > Über Sinn und Unsinn des Projektes und der begleitenden > Grundüberzeugungen zu diskutieren ist natürlich nur > insofern nützlich Eine Aussage, welche "natürlich" zutrifft, hat den Vorteil, dass man sie nicht begründen muss.
Josef G. schrieb: > Ausserdem habe ich meine Website überarbeitet. > http://www.bomerenzprojekt.de Immer noch das augenfreundliche gelb...
Josef G. schrieb: > Eine Aussage, welche "natürlich" zutrifft, hat > den Vorteil, dass man sie nicht begründen muss. Ja doch Josef, manches kommentierst Du durchaus plausibel. Nur nicht wieder in die alten Muster a'la "Mein 8-Bit Computing mit FPGA hat praktischen Nutzwert" zurückfallen ;-)
Michael K. schrieb: > Und das ist auch gut so. > Gäbe es es hier die Rubrik 'Psychologie' so wäre dieser Thread da > natürlich bestens aufgehoben. Insbesondere auch deshalb, weil die meisten anderen hier weder ähnliches anzubieten haben noch bereit sind, es auszustellen. Dies hier ist eine Bastelei, die sicher aus der Reihe tanzt und unter modernen Gesichtspunkten unnötig ist, aber das sind LED-Cubes, USB-Kaffewärmer und Drohnenortungsgeräte auch.
T. W. schrieb: > unter modernen > Gesichtspunkten unnötig ist, aber das sind LED-Cubes, USB-Kaffewärmer > und Drohnenortungsgeräte auch Ob der Josef mit dieser Einordnung einverstanden ist?
Susi schrieb: > T. W. schrieb: > Ob der Josef mit dieser Einordnung einverstanden ist? Na jedenfalls ist "Susi" mit dem ersten Teil der Einordnung: T. W. schrieb: > Insbesondere auch deshalb, weil die meisten anderen hier weder ähnliches > anzubieten haben noch bereit sind, es auszustellen. in der richtige Schublade gelandet. MfG,
Fpga K. schrieb: > Susi schrieb: >> T. W. schrieb: >> Ob der Josef mit dieser Einordnung einverstanden ist? > > Na jedenfalls ist "Susi" mit dem ersten Teil der Einordnung: > > T. W. schrieb: >> Insbesondere auch deshalb, weil die meisten anderen hier weder ähnliches >> anzubieten haben noch bereit sind, es auszustellen. > > in der richtige Schublade gelandet. > > MfG, Ob 'äunliches' vielleicht auch wegen erkannter Nutzlosigkeit nicht angeboten, nicht ausgestellt wird ?
Hier eine zusammenfassende Beschreibung der Hardware. Der Punkt in den Mnemonics steht für den auf der Grundlinie liegenden Bindestrich.
1 | Die CPU |
2 | ======= |
3 | |
4 | Der Akku A und das Erweiterungsregister B sind 8-bit. |
5 | Das Doppelregister AB wird abkürzend mit K bezeichnet |
6 | Das Vorzeichenbit A7 wird abkürzend mit U bezeichnet. |
7 | |
8 | Der Programmzähler P und die Adressregister X,Y,Z sind 16-bit. |
9 | Das Register Q erhält bei Sprüngen die Rückkehradresse P+1. |
10 | R ist Schleifen-Startadresse, S ist Schleifenzähler. |
11 | |
12 | Einziges Flag ist der Carry V. Bei bedingten Sprüngen |
13 | kann ausserdem abgefragt werden, ob U/A/K Null sind. |
14 | |
15 | Alle Speicherzugriffe sind 8bit-Zugriffe. GTMX lädt nach A den |
16 | Inhalt der Speicherzelle, auf welche X zeigt. STMX speichert A |
17 | in der Speicherzelle, auf welche X zeigt. |
18 | |
19 | IXE inkrementiert X und tauscht A und B. |
20 | DXE dekrementiert X und tauscht A und B. |
21 | |
22 | Damit lassen sich 2-byte-Speicherzugriffe aufbauen |
23 | nach dem Muster GTMX/IXE/GTMX und STMX/DXE/STMX. |
24 | Es gibt hierfür die Assembler-Makros GTMXI und STMXD. |
25 | |
26 | GTMXI lädt eine Adresse von Position X |
27 | ST.Y überträgt die Adresse nach Y |
28 | |
29 | GTMXI lädt eine Adresse von Position X |
30 | AD.X addiert X |
31 | ST.Y überträgt die zu X relative Adresse nach Y |
32 | |
33 | J.. Sprung zu der Adresse, welche in K steht |
34 | |
35 | GTA 59 lädt den Wert 0059 nach K |
36 | AD. 35 addiert 35 zu A |
37 | J.. Sprung nach 3559 |
38 | |
39 | Das lässt sich kürzer schreiben mit Assembler-Makro |
40 | /GTA 3559 |
41 | J |
42 | |
43 | GTR 59 lädt den Wert P+0059+3 nach K |
44 | AD. 35 addiert 35 zu A |
45 | J.. relativer Sprung nach P+3559+3 |
46 | |
47 | Das lässt sich kürzer schreiben mit Assembler-Makro |
48 | /GTR 3559 |
49 | J |
50 | |
51 | GT.Q lädt Rückkehradresse nach K |
52 | J Rücksprung aus Unterprogramm |
53 | |
54 | Wenn ein Unterprogramm selber J.. ausführen will für andere |
55 | Zwecke als für den Rücksprung, muss es vorher die Rückkehr- |
56 | adresse sichern. Dazu kann es die Rückkehradresse aus Q laden, |
57 | anfangs steht sie aber auch in K und das Laden kann entfallen. |
58 | |
59 | Ausser dem Sprungbefehl J.. gibt es die bedingten Sprünge |
60 | mit 8bit-Sprungdistanz: O.cc nn (Vorwärtssprung falls cc) |
61 | und B.cc nn (Rückwärtssprung falls cc). |
62 | |
63 | Für schnelle Schleifen gibt es die Repeat-Befehle R.cc. |
64 | Repeat-Befehle gibt es kombiniert mit Schleifenzähler- |
65 | Dekrementieren und Adresse-Inkrementieren/Dekrementieren. |
66 | Die Schleifenstartadresse R wird gesetzt am Schleifenanfang |
67 | mittels S.RP oder mittels O.RP nn. Bei letzterem wird |
68 | gleichzeitig ein Vorwärtssprung ausgeführt. Damit sind |
69 | Schleifen mit Hineinsprung (while-Schleifen) realisierbar. |
70 | |
71 | Bei J.. wird die Zieladresse auch nach R übertragen. Das |
72 | garantiert, dass R stets eine Adresse im Nahbereich des |
73 | Programmzählers enthält. Eine Anwendung hiervon ergibt sich |
74 | beim Sprung in eine Tabelle, welche aus O.WY nn - Befehlen |
75 | (Vorwärtssprung always) besteht, wobei die O.WY nn alle zur |
76 | selben Adresse springen. Die dortige Routine kann durch |
77 | Auswertung von R die Nummer des O.WY - Befehls ermitteln. |
78 | |
79 | Zu jeder auf dem Adressbus ausgegebenen Adresse wird auf den |
80 | Steuerleitungen angezeigt, von welchem der Adressregister |
81 | P,X,Y,Z sie kommt. Dadurch kann eine externe Logik jedem der |
82 | Adressregister eine eigene 64K-Speicherseite zuordnen. |
83 | Die CPU kann spezielle Steuersignale ausgeben, welche die |
84 | externe Logik zur Memory-Page-Umschaltung für eines der |
85 | Adressregister veranlassen sollen. |
86 | |
87 | Der Befehl H.. ist der einzige und universell einsetzbare |
88 | IO-Befehl. Es wird K auf dem Adressbus ausgegeben, und der |
89 | Datenbus wird nach A eingelesen. |
90 | |
91 | Wenn auf H.. ein J.. folgt, dann wirkt H.. stattdessen als |
92 | Präfix und bewirkt, dass J.. mit einer Memory-Page-Umschaltung |
93 | kombiniert wird. So kann die CPU von einer 64K-Seite in eine |
94 | andere springen, ohne dass es einen gemeinsamen Speicherbereich |
95 | geben muss. Bei den Adressregistern X,Y,Z gibt es spezielle |
96 | Befehle SW.X, SW.Y, SW.Z für die Memory-Page-Umschaltung. |
97 | |
98 | Die Gesamt-Hardware |
99 | =================== |
100 | |
101 | Es gibt vier Memory-Pages mit je 64KByte: |
102 | Page 0: Aktiver Steckplatz |
103 | Page 1: ROM (32K), Text-RAM (16K), Video-RAM (16K) |
104 | Page 2: Haupt-RAM |
105 | Page 3: Zusatz-RAM |
106 | |
107 | Der aktive Steckplatz in Page 0 wird |
108 | durch ein 3bit-Register SLT ausgewählt. |
109 | |
110 | Es gibt die 2bit-Register MP,MX,MY,MZ. Diese Register legen |
111 | fest, in welche der vier Memory-Pages das betreffende Adress- |
112 | register P,X,Y,Z zeigt. Ausserdem gibt es die Schattenregister |
113 | NP,NX,NY,NZ. Das CPU-Signal zur Memory-Page-Umschaltung für ein |
114 | bestimmtes Adressregister # bewirkt den Austausch von M# und N#, |
115 | wobei # hier für P,X,Y,Z steht. Beim Sprung mit Memory-Page- |
116 | Umschaltung H.. J.. werden also MP und NP getauscht. |
117 | Die Schattenregister NP,NX,NY,NZ können über IO-Befehle H.. |
118 | mit einem Wert 0 bis 3 geladen werden. |
Josef G. schrieb: > Eine Aussage, welche "natürlich" zutrifft, hat > den Vorteil, dass man sie nicht begründen muss. Okay, dann mit Begründung. Wie in dem von mir verlinkten Artkel haben wir es hier mit Glaubensbekundungen von Menschen zu tun die allem Anschein nach garnicht in der Lage sind ihre Überzeugung zu ändern. Das hat nichts mit Logig, Vernunft oder Überzeugungskraft zu tun. Es ist vollkommen unerheblich was da gesagt wird, der Zähler springt einfach auf Null und die ganze Schei**e geht von vorn los. Was da in der Summe an Entwicklungsleistung herausgekommen ist, da ziehe ich den Hut vor Dir Joseph. Was da aber an Überzeugungen herauskommt was den Nutzen dieses Systemes im Jahre 2015 angeht und die kurz bevor stehende weltweite Einführung des Hexadezimalsystemes da spare ich mir jede Diskussion weil ohnehin niemand diesen Wahn durchbrechen kann. Du glaubst was Du glauben willst und anscheind macht es Dir Spaß. Gut so, weiter so, aber trotzdem bleibe ich bei meiner Kernaussage das die nützlichste Information die man aus diesem Thread noch ziehen kann die ist welch verschlungene Pfade das Gehirn gehen kann um eine bereits gefasste Überzeugung nicht mehr revidieren zu müssen. Mal ehrlich, es ist Dir doch vollkommen Wurst ob die große Mehrheit der Menschen Augenkrebs bei Deiner Seite bekommt, oder wie gering das Interesse ist Dein System produktiv einzusetzen oder als wie abwegig die Idee bewertet wird beim discounter CF,A3 Euro zu bezahlen. Nichts davon ändert irgend etwas in Dir und das wird meines erachtens auch so bleiben. Beispiel wie dieses gibt es viele: http://www.golem.de/news/templeos-goettlicher-hardcore-1508-115081.html Deine Verbohrtheit hat Dich weit gebracht mit Deinem System aber da stehst Du nun in der Sackgasse und das Lob all der anderen bleibst aus weil Du etwas gebaut hast was ausser Dir niemand gut findet. Mir ist das egal, auch wenn ich das schade für Dich finde weil da viel Arbeit und Herzblut drinsteckt. Du hättest meiner Meinung nach mehr erreicht wenn Du Deine offensichtliche Intelligenz etwas sozialverträglicher eingesetzt hättest, aber das ist allein Deine Sache.
Leider wirkt die Webseite als wäre es eine Ansammlung persönlicher Notizen. Bestenfalls blickt da der Author durch. Aber für einen Dritten ist das alles völlig undurchsichtig.
Matthias W. schrieb: > Aber für einen Dritten ist das alles völlig undurchsichtig. Kannst du mal eine konkrete Stelle nennen, wo etwas unverständlich ist? Oder besser: Wenn man die Seiten der Reihe nach jeweils von oben nach unten liest, an welcher Stelle setzt die Verstehbarkeit aus?
Josef G. schrieb: > Kannst du mal eine konkrete Stelle nennen, wo etwas unverständlich ist? Beispielsweise das Carry-Flag partout V nennen zu müssen. So ziemlich jeder ausser dir wird darunter Overflow verstehen. Derart aggressiv Platz im Quellcode zu sparen lohnte sich das letzte Mal ungefähr zur jener Zeit, in der ich noch Windeln trug. Seither arbeitet man eher an der Lesbarkeit von Quellcode als an der optischen Verschlüsselung durch kryptische Formulierungen über 1-2 Buchstaben statt lesbarer Abkürzungen. So hat sich auch die noch aus jener Zeit stammende Gewohnheit von IBM, Additionen einfach nur mit "A" abzukürzen, ausserhalb dieser Sphäre nicht durchsetzen können. Praktisch jeder sonst schreibt ADD. Im Zeitalter von Disks mit Terabytes pro Stück und Cross-Assemblern/Compilern, die Quellcode von Megabyte-Grösse in Nullkommanix durchpfeifen, ist diese Kryptik nur noch grotesk. NB: Das schreibt dir jemand, dessen ersten Programmiersprache APL war. Die wohl kryptischste ernst gemeinte Programmiersprache, die je erfunden wurde. Nennt man mit Recht eine "write only language", weil man nicht sicher sein kann, auch nur die eigenen Programme nach ein paar Jahren wieder zu verstehen, wenn man nicht noch alles im Kopf hat. Von den Programmen andere Leute ganz zu schweigen.
:
Bearbeitet durch User
A. K. schrieb: > Derart aggressiv Platz im Quellcode zu sparen Es geht nicht um das Einsparen von Speicherplatz, sondern um das Einsparen von Tipp-Arbeit.
Josef G. schrieb: > Es geht nicht um das Einsparen von Speicherplatz, > sondern um das Einsparen von Tipp-Arbeit. Was du an Tipparbeit im Programm einsparst, das investierst du doppelt und dreifach in Form von Kommentaren. Oder solltest du zumindest, was du aber wahrscheinlich nicht tust. Der Aufwand bei der Programmierung wird nicht durch die Zeit bestimmt, die man benötigt um den Quelltext einzutippen. Ausser vielleicht, wenn du körperlich erheblich behindert bist. Das dürfte sogar auf das äusserst geschwätzige COBOL zutreffen.
:
Bearbeitet durch User
Michael K. schrieb: > Was da aber an Überzeugungen herauskommt was den Nutzen dieses Systemes > im Jahre 2015 angeht und die kurz bevor stehende weltweite Einführung > des Hexadezimalsystemes Wenn man die heutige Situation bei den PCs betrachtet mit der vollständigen Entmündigung der Anwender und der Verseuchung mit Malware: Vielleicht gibt es ja doch eine größer werdende Zahl von Leuten, zunächst im Hobby-Bereich, welche sich nach Alternativen umsehen, zB. nach einem Computer, den die Anwender vollständig durchschauen und selber programmieren, auch in Maschinensprache oder Assembler, der aber einen größeren Adressraum hat als die historischen 8bit-Computer. Und dieselben Leute werden vermutlich auch die Verbreitung des Hexadezimalsystems unterstützen wollen. Argumente zum Hexadezimalsystem habe ich da zusammengestellt: http://www.bomerenzprojekt.de/Website/Hexadezimalsystem.html Ist an diesen Argumenten etwas falsch? Es geht auch nicht um die "kurz bevorstehende weltweite Einführung des Hexadezimalsystems", sondern darum, durch Einführung des hexadezimalen Ziffernsatzes bei Hobby-Computern dessen allmähliche Verbreitung zu fördern.
Josef G. schrieb: > zB. nach einem Computer, den die Anwender vollständig > durchschauen und selber programmieren, auch in Maschinensprache > oder Assembler, der aber einen größeren Adressraum hat als die > historischen 8bit-Computer. Wenn du damit nicht nur abstraktes Verstehen meinst, sondern auch, solche Geräte nicht nur spielerisch sondern real zu nutzen, dann ist diese Zeit vorbei. Ich hatte sie persönlich erlebt (*). Fast alle Menschen wollen Computer heute einfach nur benutzen. Manche wollen sie verstehen. Aber ein real nützliches Gerät selber bauen? Nicht mal Leute, die sich für die konkrete Technik von Autos interessieren, bauen sich die Dinger inklusive Motor, Getriebe und Reifen selber. Obwohl es anfangs welche gab, die es taten (weils nix fertig gab). Fast alle Menschen wollen sich einfach nur reinsetzen und fahren. Auch da ist die Zeit der Pioniere rum, schon etwas länger. > Und dieselben Leute werden vermutlich > auch die Verbreitung des Hexadezimalsystems unterstützen wollen. Während die Amis mit dezimalen Rechnern anfingen nutzte Zuse von Anfang an binäre Darstellung intern und dezimale Darstellung nach aussen. Bereits auf einer derart einfachen Maschine war das also kein ernstes Problem. Case closed, schon damals. Übers Hex-System können wir mal drüber reden, wenn du es geschafft hast, die Briten davon zu überzeugen, rechts zu fahren. Oder den Rest der Welt davon, links zu fahren. Und dabei hat es sehr viel solidere Gründe, sich da irgendwann mal zu einigen, als Hex/Dez. *: Einschliesslich der nicht immer einfach zu beantwortenden Frage "Junge, was kann man damit eigentlich wirklich anfangen?" ;-)
:
Bearbeitet durch User
Josef G. schrieb: > Wenn man die heutige Situation bei den PCs betrachtet mit der > vollständigen Entmündigung der Anwender und der Verseuchung mit > Malware: Da siedelst Du Dein System an ? Dein System sehe ich eher auf der Leistungsebene 'stark kastrierter 8051' mit extrem schlechter Doku und rudimentärster Software. Bei derartigen Systemen hatte ich noch nie Probleme mit Malware. Womit verfasst Du eigentlich Deine Beiträge hier, womit entwickelst Du Dein System ? Ich tippe mal auf einen handelsüblichen und 'unmündigen' PC. Du bist doch nicht mal selber in der Lage Dein System zu etwas anderem zu verwenden als ein paar Register hin und herzuschieben und sich an 'blinky' Programmen zu erfreuen. Das ist zu nichts nütze als zum Spielen und das kann ich mit jeder kleinen MCU für ein paar Cent haben. Die sind dann aber sauber dokumentiert, haben eine funktionierende Community, Compiler, IDEs etc. pp. Eine der Definitionen von Wahnsinn ist, immer wieder das gleiche zu tun und dabei ein anderes Ergebniss zu erwarten. Deswegen höre ich jetzt auch auf.
@A. K. (prx) >Nicht mal Leute, die sich für die konkrete Technik von Autos >interessieren, bauen sich die Dinger inklusive Motor, Getriebe und >Reifen selber. Du hast echt Ausdauer. Immer noch nicht verstanden, wo das Problem von Josef liegt? Kleiner Tip. https://de.wikipedia.org/wiki/Autismus https://de.wikipedia.org/wiki/ELIZA
:
Bearbeitet durch User
Falk B. schrieb: > https://de.wikipedia.org/wiki/ELIZA Kam mir auch schon in den Sinn, aber nicht bei Josef. Da gibts hier im Forum eine andere Person, auf die das weit besser passt.
Michael K. schrieb: > Du bist doch nicht mal selber in der Lage Dein System zu etwas anderem > zu verwenden als ein paar Register hin und herzuschieben und sich an Es müsste in der Tat noch einiges an Steckkarten-Software geschrieben werden. Die von mir erstellte Test-Steckkarte ist nur zur Demonstration der prinzipiellen Funktionsweise einer Steckkarte gedacht. Die Software der Hauptplatine ist fertig, inclusive der Schnittstelle zu Einbindung von Steckkarten-Software. Zur Entwicklung von Steckkarten-Software ist jedermann eingeladen, und er kann diese Software in Eigenregie anbieten. > und das kann ich mit jeder kleinen MCU für ein paar Cent haben. Die ist aber nicht zu einem richtigen Computer ausbaubar.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.