Posts by maik

    Beim Wechsel des Mainboards würde ich auch zur AMD-Plattform raten. Wenn Du da jetzt einen Ryzen 3600 (sehr gutes Verhältnis von Preis und Leistung) reinpackst, dann kannst Du später mindestens bis zur Ryzen 5000-Serie aufrüsten.


    Intel führt für den Socket 1200 zwar noch Rocket Lake S ein (ein letztes Hurra auf 14nm), da ist derzeit aber noch unklar, ob der tatsächlich ein lohnend besseres Bild abgibt als das, was man von Intel jetzt schon kaufen kann. Der Nachfolger Alder Lake scheint dann gleich auf den Sockel 1700 zu wollen, ist also kein Upgrade-Pfad.


    Aber vielleicht denkst Du in ein paar Jahren gar nicht an "Aufrüsten durch nur CPU-Wechsel" und machst eh wieder einen Reset.

    Nicht unbedingt super-duper, aber manchmal nütztlich: In den Laufwerkseigenschaften die Komprimierung einschalten.


    Also Häkchen bei "Laufwerk komprimieren, um Speicherplatz zu sparen". Gerne vorher ein Backup machen.

    Seit fast 20 Jahren daheim Linuxer, davon vermutlich so um die 12 Jahre mit Ubuntu Linux. Auf der Arbeit (Bildungseinrichtung) auf Windows 10, aber immer mit einer Linux-VM im Hintergrund.


    • Pro Windows: Im Team wird langweiliges Zeugs halt mit Microsoft Office geschrieben. Exchange-Kalender sind das Lebensblut für Abstimmungen. Studierende können auf viele Weisen gelangweilt werden, aber häufig ist es halt ein PowerPoint-Foliensatz, insbesondere wenn sich unter Lehrenden austauscht. Nichts davon ginge nicht prinzipiell auch unter Linux (und man könnte prinzipiell umsatteln), aber für normales Bürozeugs läuft halt auch Windows.
    • Contra Windows: Das ganze Thema Softwareinstallation und -update fühlt sich sehr holperig an, wenn man es gewohnt ist, normalerweise mit "apt get install" bzw. "apt get update && apt get upgrade" alles in einem Rutsch zu erledigen. Wenn ich die Kiste hochfahre, möchte ich nicht auf Updates warten, ich habe in drei Minuten Vorlesung. Wenn die Kiste runterfahren soll, will ich keine Updates, ich muss das Notebook gleich in die Tasche packen. Ich möchte kein Popup, welches androht, die Kiste runterzufahren, wenn ich nicht bald reagiere. Warum haben Chrome/Firefox/Notepad++/IDEs eigene Updater, die auf kreative Weise nerven? Warum muss ich einen fünf Jahre alten Herstellertreiber für einen USB-UART-Konverter eines Entwicklerboards installieren, wenn Linux das Gerät direkt nach dem Einstecken einbindet? Warum findet die Suchfunktion im Startmenü regelmäßig alles - nur genau das nicht, was gesucht wird? Warum ist die Systemsteuerung in Win10 so verdammt unübersichtlich? Warum scheint so einiges an Datenübermittlung erstmal "opt-out" zu sein, statt "opt-in"?


    Vermutlich lässt sich beim "contra" noch was besser einstellen - aber wenn ich "frickeln" muss, dann ist ja ein Hauptverkaufspunkt von Windows ("alles läuft, und zwar sofort") für mich ein bisschen entwertet.


    So, das nochmal für Linux:

    • Pro Linux: Softwareinstallation und -update über einen zentralen Mechanismus. Passend gewählte Hardware wird erkannt und funktioniert (wenn es nicht klappt sind wir aber beim Contra). Hardware, die läuft, läuft in der Regel auch über viele Jahre, selbst
      wenn der Hersteller keinen Bock mehr auf Pflege der eigenen Treiber hat. Egal ob Softwareentwicklung oder Hardwareentwicklung: Die allermeisten von mir benötigten Tools sind nur wenige Tastenanschläge entfernt. Ich habe eine Wahl bei den Desktopumgebungen (ich setze GNOME ein und auf schwächeren Rechnern XFCE). Ich kann ohne Lizenzierungshampelei mal eben einen weiteren Rechner installieren oder updaten. Es gibt vom Start weg Kommandozeilentools, die leistungsfähig sind und skriptbar. Sollte der Hersteller meiner Distribution versuchen, mir irgendeinen Kack anzudrehen, den ich nicht will, dann wechsle ich halt zu einer anderen Distribution und kann i.d.R. dieselbe Software weiterverwenden. Ich kann entfernte (Server)Rechner praktisch ab Installation über ssh steuern, was auch mit einer schäbigen Internet-Leitung funktioniert. Ich hatte in der Regel keine Schwierigkeiten, irgendwelche obskuren Dateisysteme lesen zu können (ja, selbst Amiga-Dateisysteme sind noch drin).
    • Contra Linux: Wenn Hardware nicht nach dem Einstecken funktioniert, dann hat man schonmal eine aufregende Reise vor sich. Für manche Anwendungszwecke sind die Standardtools nur für Windows verfügbar - entweder man findet passenden Ersatz, oder Wine funktioniert - oder Pech gehabt. Viele AAA-Spiele erscheinen nur für Windows - wer für sowas Zeit hat, wird bestimmt unter Linux was vermissen. Manche finden die Auswahl an Distributionen erschlagend oder stolpern über die Unterschiede zwischen Distributionen oder Desktop-Umgebungen (aber Leute wechseln ja auch nicht dauernd die Windows-Distribution, also warum sollten sie sich um andere Linux-Distributionen bzw. Oberflächen scheren?).


    Unterm Strich: Hat beides eine Vorzüge und Nachteile. Manchen Vorzug habe ich bestimmt jeweils jetzt vergessen, manchen Nachteil auch. Die Nachteile lassen sich bestimmt auch durch etwas Einarbeitung und Cleverness jeweils abmildern oder lösen sich in Luft auf. Rein persönlich: Ich fühle mich mit Linux wohl und vermisse Windows nicht. Bei anderen Anforderungen oder anderem Geschmack kann man aber auch mit Fug und Recht sagen "Ich fühle mich mit Windows wohl und vermisse Linux nicht". In Zeiten von Virtualisierung finde ich ein absolutes "Entweder - Oder" eh nicht zwingend notwendig.

    Hallo,


    klar kann ich in die Konversation mal reingucke, wenn Du mich hinufügen magst :-)


    Nur zwei Befehlslängen machen die Sache natürlich deutlich handhabbarer! Wäre gut, wenn alle Befehle, die 5 Byte sind, "zufällig" immer dasselbe Bit gesetzt haben, während alle anderen Befehle "zufällig" dieses Bit nicht gesetzt haben ;-)



    Maik

    Hi daybyter :-)


    Na, bin nur Hobby-CPUler, der hin und wieder etwas herumbastelt. Mir ist keine "mini dev Board Konversation" bekannt... gibt es da einen Link?


    Wenn Du variable Instruktionslänge haben möchtest, dann sind ja auch Deine 32-bit immediates kein unmittelbares Problem. Allerdings machen variable Befehlslängen das Dekodieren nicht unbedingt kompakter ;-)


    8-Bit-Befehle klingen natürlich toll und kompakt und wir alle mögen ja auch den 6502 - aber man müsste sich genau angucken, ob man durch das kleine Register-Set nicht viele load/store-Ops benötigt, die in die Kompaktheit wieder reinfressen.


    Zum Thema "kopieren in die ALU": In den meisten Designs hängen die Ausgänge der Register (über Muxer) an den Operanden-Eingängen der ALU (wie z.B. im beigefügten Diagramm, welches für einen älteren meiner RISC-V Designs gilt - ich erkläre das Ding einem älteren mäßig guten und viel zu langen Talk - bei https://media.ccc.de mal nach "CPU-Design für Einsteiger" suchen, ab Minute 65). Die Register haben also zwei Ausgänge, die fest den Operanden-Eingängen der ALU zugeordnet sind. Da muss nichts kopiert werden, die Daten "fließen" von den Registern in die ALU (sofern die Muxer passend gesetzt wurden). Woher weiss die Register-Einheit, welche Daten sie an den Ausgängen präsentieren soll? Klar, der Decoder liefert die "Registeraddresse" (bei RISC-V sind die Bits für die Registerwahl sogar *immer* an derselben Stelle, so dass der Decoder einfach nur die entsprechenden Bits durchreicht - die Instruktion steuert also "direkt" die Registerwahl). Dann ist es halt auch "egal", wie viele Register man hat, sofern man die nötigen Bits in der Instruktion unterbringen kann.


    Es hat einigen Reiz, wenn man die ALU-Operation direkt in den Opcode backen kann.



    Viel Spass beim Knobeln! Manchmal muss man auch mal Spaghetti an die Wand werfen, um zu gucken, was für schöne Muster enstehen - insofern viel Mut zur Kreativität!



    Maik

    Für den Fall, dass Du doch lieber einen eigenen Befehlssatz machen möchtest (weil das macht Spass und ist lehrreich!), hier mal ein bisschen Feedback von mir:



    Die Register möchtest Du vermutlich im BRAM des FPGAs realisieren und nicht aus dem Fabric heraus synthetisieren, da es dann deine LUTs frisst. Gute Nachrichten: Dann kannst Du auch mehr Register haben, schließlich ist mindestens ein Block BRAM eh verwendet - den würde ich dann auch versuchen, besser zu nutzen.


    Ich würde also darüber nachdenken, diesen BRAM-Block nicht mit zu wenigen Registern "zu verschwenden", also ein paar Register mehr vorzusehen:
    - mindestens 8 Universalregister, das wären "nur" 256 Bits. Mal zum Vergleich beim Asbach-Uralt Cyclone ist jeder BRAM-Block 4096 Bit gross.
    - ich würde keinen eigenen Stackpointer vorsehen, sondern schlicht ein Universalregister dafür verwenden. Flexibler und und Du brauchst ja eh load/store in die Universalregister.
    - In RISC-V verzichtet man auf das Statusregister. Wen Over- bzw. Underflow interessieren, der macht ensprechende Checks in Software (bei C kommt man ja eh nicht an die entsprechenden Flags). Es gibt Sprünge für größer/unsigned größer/kleiner/unsigned kleiner/gleich - jeweils wird explizit verglichen, ohne ein Statusregister zu konsultierien. Vereinfacht das Pipelining. Wenn Du kein Pipelining machen willst (Du brauchst die Performance nicht), dann spricht nichts gegen ein Statusregister.






    Auf die inc und dec-Instruktionen würde ich verzichten, Du hast ja Reg-Reg Instruktionen und kannst ja eine Konstante in ein Register packen (Du hast ja jetzt mehr Register, da gratis per BRAM). Ist flexibler.


    Möglicherweise willst Du shiften zu einer Reg-Reg Op machen, damit Du auch mehr als ein Bit pro Instruktion shiften kannst. RISC-V sieht kein rotieren vor, da gängiger Code das sehr selten einsetzt und man das mit Shiften, Verundung und Veroderung hinbekommt. Wenn Du weisst, das das eine häufige Operation ist: Kann nicht schaden, das drinzulassen - möglicherweise aber als Reg-Reg, um mehr als ein Bit zu rotieren.


    Rechts-Shiften sollte es in einer logischen und arithmetischen Variante geben (0 bzw. Vorzeichen reinschiften).



    Dein load und store sehen so aus, als würdest Du da ein 32-Bit immediate voraussetzen. Damit könnten load und store ja natürlich als Instruktion nicht weniger als 32 Bit haben. Das würde ich versuchen, zu vermeiden, sondern alle Instruktionen entweder feste 16 oder 32 Bit lang sein lassen. RISC-V kennt 20-Bit und 12-Bit immediates. Man kann auch einfach ein Instruktionsformat mit einem 16-Bit immediate wählen.


    Ich schlage vor: load <reg>, <reg-basis>, <imm-offset>, wobei die Speicheraddresse dann die Summe aus Basisregister und immediate wäre. Immediate als Vorzeichenbehaftet annehmen, dann kann man mit dem offset in "beide" Richtungen greifen.



    Bei 16-Bit immediates würde ich die set-Operation in ein "seth" und "set" aufsplitten (also "set high" und "set"). Um die ganzen 32 Bit zu laden bräuchte man zwei Instruktionen - aber man braucht "selten" "große" Zahlenwerte. Wenn dein Decoder Dein 16-Bit immediate mit Vorzeichen auf 32-Bit aufpustet, dann kann man die meisten benötigten Werte (-32768 bis 32767) mit einem einzigen "set" abhandeln und braucht "set high" nur, wenn man in den obigen 16 Bit noch andere Werte braucht.



    Passt. Je nach Instruktionsencoding kannst Du natürlich auch mit nicht-implizitem Zielregister arbeiten, also <Operation> <Zielregister> <Operand1> <Operand2>. Bei 32-Bit Instruktionen passt das "immer" und ist "gratis", bei 16-Bit Instruktionen nutzt man i.d.R. ein implizites Zielregister (also Ziel = Operand1).




    Auch hier: Die 32-Bit immediates, die Du hier brauchst, sprengen Dein Instruktionsencoding. Zur Inspiration:


    - jmp <16 bit offset>: Springen zu PC + offset (immediate wieder vorzeichenbehaftet, damit Du vor- und zurückspringen kannst)
    - jmpr <Register>: Springen zur 32-Bit Adresse im Register. Mit dieser Operation kannst Du auch auf "jmp" verzichten, wenn Du die Sprungaddresse mit normalen Register-Ops berechnest.


    Ähnlich die anderen Ops. Insgesamt braucht "man" wohl Sprung-{kleiner, unsigned kleiner, größer, unsigned größer, gleich}.


    edit: Vermutlich möchtest Du auch ein "jump and link": Also ein Sprung, der die Rücksprungaddresse in ein Register schreibt. Sonst werden Funktionsaufrufe schwer, da Dein "ret" nicht weiss, wohin. Ret brauchst Du übrigens nicht, wenn Du ein "jmpr" hast.



    Sonstiges
    =========
    brk Stoppe cpu
    ==============================


    Endlosschleife mit jmp ;-)




    Maik

    Shameless Plug: https://github.com/maikmerten/spu32 <-- vielleicht kannst Du da was verwenden. Bisher einfach meine kleine Spielwiese, läuft aber. Führt den 32-bit RISC-V Basisbefehlssatz aus, d.h. Du hast sofort vernünftige Assembler und Compiler startbereit. Alternativ wird gerne https://github.com/cliffordwolf/picorv32 eingesetzt. Beide CPUs liegen irgendwo im Bereich von ca. 1000 LUT4s auf iCE40 FPGAs, synthetisieren aber natürlich auch in anderen FPGAs, da stinknormales Verilog.



    (Ich sage ja schonmal scherzhaft, dass es einfacher ist, eine funktionierende CPU zu basteln, als den ganzen Toolstack drum herum)

    Hallo allerseits,


    ich habe mir mal ein Mister mit Speicher und IO-Erweiterung gegönnt.


    Für Windows gibt es Progrämmchen, welches die notwendige SD-Karte erstellt (also partitioniert, formatiert, die notwendigen Dateien extrahiert) und das jeweilige Release draufpackt. Nur liegt hier nirgendwo Windows rum.


    Gibt es irgendwo ein Skript für Linux, welches eine Image für die SD-Karte vorbereitet (oder sich direkt die Karte vorknöpft)? Ich habe bisher nur


    https://github.com/MiSTer-devel/Linux_Image_creator_MiSTer


    gefunden, das erzeugt aber wohl nur ein Abbild der Linux-Partition für die SD-Karte (250 MB), nicht ein fertig partitioniertes Image für die ganze Karte...


    edit: https://github.com/alanswx/SD-installer_MiSTer sieht vielversprechend aus...

    Hallo,


    ich habe mal in ein externes Laufwerksgehäuse ein Gotek mit FlashFloppy gepackt. Da die Stiftleiste des Gotek nicht genau an der Position des alten Laufwerks sitzt, musste ich da ein bisschen herumkabeln, was ich mit Stiftleiste/Buchse aber schön reversibel hinbekommen habe. Laufwerk ist auf S0 gejumpert.


    Scheint auch wunderbar zu funktionieren - doch wenn ich am Gotek ein anderes Image auswähle, dann bekommt das der Amiga nicht mit. Erst nach einem Neustart wird der neue Inhalt gesehen.


    Eine Idee, was da im Argen liegt?

    Ich glaube der einfachste und billigste Weg, Internet an einen FPGA zu bekommen, ist einen ESP8266 per UART (also RX, TX, GND) dranzudengeln.


    Dem ep2c5t44 dev-Board (das wie ich im Profilbild habe?) tatsächlich natives Fast-Ethernet anzuschwurbeln stelle ich mir anstrengend vor. 50 MHz über solche Pinleisten zu führen ist grenzwertig.


    edit: Übrigens: falls Du noch eine PLL unbenutzt hast, kannst Du doch die 20 MHz für 10BASE-T erzeugen lassen?

    Wild geraten, würde ich folgendes prüfen:


    * char-ROM (edit: würde aber die fehlerhaft eingefärbten Zeichen nicht erklären)
    * PLA (hast Du noch einen anderen Ersatz zur Hand?)
    * VIC-II


    edit: Oh, und ich glaube, einer der CIAs ist für die Auswahl der VIC-II-Bank zuständig. Ändert sich was, wenn du die beiden CIAs miteinander tauschst?

    Mit Win32s konnte man Win3.11 tatsächlich schon vor Windows 95 auf 32 Bit aufrüsten. Dafür kompilierte Software läuft natürlich noch, sofern sie sauber programmiert wurde. Das ganze Inkompatibilitätenchaos ging erst mit DirectX los, wo MS immer wieder mal dran rum bastelt. Ansonsten hat man bei Windows 7 ja noch den XP-Mode. Der ist immer 32-Bit und kann von daher auch 16-Bit-Software ausführen.

    Hmm... ich dachte immer, dass unter 64-bittigem Windows inzwischen der ganze 16-bit-Kram nicht mehr geht.


    Nur mal aus Spass: Hier mal Netscape 3.04 für Windows 3.1 unter Wine unter einem AMD64-Linux - natürlich ohne Anspruch auf Nützlichkeit.



    Und ja, es wird darauf geachtet, dass der Kernel auch solche esoterischen Geschichten weiter unterstützt... https://lkml.org/lkml/2014/4/29/626


    edit: Aber hier geht es ja um BSD - ich würde sagen, das dürfte da keinen Deut schlechter aussehen ;-)

    Habe seit ein paar Wochen einen Ryzen 7 2700. Dieser schlägt sich sehr gut unter Linux auf einem Asrock AB350M. Sehr unauffällig (im guten Sinne) und beim Kompilieren größerer Projekte (z.B. dem GCC) fliegen die Ausgaben praktisch über die Konsole. Die 2000er-Serie hat bei mir auch nicht mit dem Speicher rumgezickt - zu Anfang der AM4-Plattform gab es da wohl Kinderkrankheiten, weshalb ich gerne auf einen Refresh warte (hier: 2000er-Serie).