Und gcc 6502?
Posts by daybyter
-
-
Ich hatte früher dieses ganz kleine Internet Paket, was heute wohl 1 gb für 3,99 ist. Hat sich aber nicht gelohnt, und ich hab es schon lange nicht mehr. Wenn ich heute mal unterwegs was googlen muss, zahl ich das 1 mb halt so. Geh aber vielleicht 2x pro Jahr ins Internet und Telefon ist auch immer so < 1,- pro Monat. Ändert sich nur, wenn ich z. B. mal im Krankenhaus lieg, oder so. Dann mach ich halt für 4 Wochen so ein 6,99 Paket.
-
Ein Kollege in der ProProgrammer WhatsApp Gruppe hat ein Spiel Brick Royale programmiert, dass ich ganz gerne mal spiele.
-
Ich hab auch Aldi Talk, weil ich so wenig Telefonieren. Ich würde mehr telefonieren, aber Odo hat ja kein WhatsApp...
Ich hab mir vor einer Weile ein Huawei Honor 8a für knapp 100,- gehol. Bisher laufen alle Apps darauf. Es ist wohl nicht besonders schnell, aber spielen tu ich eh fast nicht, also kann ich damit leben.
-
Aber kannst Du die alten Platten so falsch konfigurieren, dass der Motor nicht anläuft? Kann mich nicht entsinnen so etwas gesehen zu haben...
-
Früher haben manche Leute so ein Problem mit einem kleinen Schlag auf die Platte beheben können...
-
Bisserl Verilog geschrieben für den Versuch einer HDMI Anzeige.
-
Schwer fand ich das...
-
-
Cobol und Fortran Buch steht immer noch im Regal.
Ein Bekannter stellt wohl immer noch Cobol Systeme auf Java um. Und ihm fehlen wohl auch Cobol Programmierer.
-
Im gcc 6502 Thread hab ich eine 3d Kurve in C angezeigt. Könnte man sicher nach Basic portieren, aber das wird wohl zu langsam.
-
-
Stimmt - deswegen musst du dein Schieberegister auch nur alle 10 Schiebevorgänge mit den Daten eines neuen Pixels füllen, also effektiv 25MHz. Den Zähler zum Neubefüllen baut man bei dem Takt am besten als Ringzähler mit einem 1-Bit und 9 0-Bits, das wird dann wieder zu einem Schieberegister statt aufwendige Addierer-Hardware zu benötigen.
Eigentlich könnte man ihn ja sogar quasi als 5 Bit Zähler bauen, weil ja beide 5-Bit-Register eben nur 5x geschoben werden?
Ich beschreibe das immer gerne als "Ich weiss mehr Details über diverse Videostandards als ich jemals wissen wollte."
Ja, das ist ja eben das Tollste an der FPGA-Bastelei: man lernt unheimlich viel über die Details der Grafik-Signal Erzeugung, Bus-Auslastung, Cache-Design usw usw. Aber eben daran scheint vielen ja nicht zu liegen. Sie wollen lieber Plug-N-Play...
-
Ich würde mich wundren, wenn das bei Altera/Intel nicht klappt. Der XC3S200A hier ist ein >10 Jahre alter Low-End-Chip und der bekommt kleine Schieberegister mit 270MHz hin.
Das wäre ganz toll, wenn das so einfach geht. Muss man halt mal schauen, was Quartus weiter so spricht, wenn der Code mehr wird.
Also ein Pixeltakt von 250MHz und damit eine Auflösung höher als [email protected]?
Nein, der minimale Pixeltakt ist doch anscheinend 25 MHz und Du musst 10 Bit pro Pixel rauschieben? Oder hab ich da was falsch verstanden?
Du kannst ja mal dem "GCVideo"-Link in meiner Signatur folgen.
Wow! Dann hast Du ja schon richtig Ahnung vom Thema!
-
Du meinst für DVI/HDMI? Das braucht ein (eigentlich drei oder vier) Schieberegister mit zehnfachem Pixeltakt, aber alles andere kann mit dem regulären Pixeltakt laufen. Wenn der FPGA geeignete Output-Peripherie hat reicht evtl. auch weniger Takt (zB ODDR2 beim Spartan 3A um mit Pixeltakt * 5 auszukommen oder OSERDES2 beim Spartan 6 zur... äh, kompliziert, aber doppelter Pixeltakt sollte reichen). GCVideo verwendet die ODDR2-Methode und eine Testversion lief hier mal mit 54MHz Pixeltakt (540MBit pro TMDS-Lane, 270MHz interner Shiftregister-Takt) bei 720x960p60.
Ja, eben. Diese 4 Schieberegister geben die ganz billigen FPGA-Boards gar nicht und die mittel-billigen Boards (de0 nano und Co) eigentlich schlecht bis gar nicht her. Die Idee ist also, 1 10 Bit Schieberegister mit 250 MHz durch 2 5-Bit Schieberegister mit 125 MHz zu ersetzen. Hinter den 2 Schieberegistern sitzt ein Multiplexer, der bei jeder Flanke des 125 MHz Takts zwischen den 2 5-Bit Schieberegistern hin und her schaltet.
Nur dieser Umschalter müsste dann mit 250 MHz umschalten. Alles davor würde nur mit 125 MHz laufen, was anscheinend auch schon mit billigeren Boards geht. Diese Register müssten halt mit 125 MHz mit neuen Pixeln befüllt werden (eigentlich wird also 1 Pixelfarbe auf 2 Register verteilt. Jeweils gerade und ungerade Bits auf 1 Schieberegister). Keine Ahnung, ob das wirklich so klappt, aber anscheinend haben das schon Leute so bisserl ans Laufen gebracht. Hab mir mal ein super-billig HDMI Kabel zum Zerschneiden in China bestellt...
Ja, hoch getaktetes Zeugs sollte möglichst wenig Logik zwischen den Registern haben. Teilweise hilft es auch, am Ende ein paar Registerstufen zusätzlich dranzuhängen und der Synthesesoftware zu erlauben, Register innerhalb der Logik zu verschieben um das Timing zu entzerren.
Ich befürchte halt, dass ein Register schon zuviel für den Takt ist. Müsste man halt mal versuchen.
Arbeitest Du auch mit FPGA Boards?
-
370MHz sind mehr als das doppelte was du für [email protected] brauchst. Wenn du zudem ein niedriger aufgelöstes internes Bild mit Nearest-Neighbour-Skalierung ausgeben willst, muss nur ein einziges externes Signal wirklich mit der hohen Zielfrequenz laufen: Der Pixel-Takt-Ausgang für den externen DAC oder DVI-Transmitter. Alle Farbsignale sind mehrere Takte lang konstant und können entweder mit niedrigerem internen Takt laufen oder man sagt der Synthesesoftware mittels Multicycle-Constraint, dass das Timing nicht so knapp ist wie der Takt vorgibt.
Ich hab mir das mal angesehen. Die besseren FPGA Boards (> 250 MHz Takt) haben vorgefertigte Module für den Bitstrom. Da schreibt man wohl nur die 8 Bit rein und die erzeugen Start- und Stop-Bit selbst automatisch. Meine Idee war ja, ob man das mit so nem super-billig Board auch von Hand hinbekommt. Dann muss man Start- und Stoppbit auch per Hand erzeugen und an dieser Stelle sind wir dann wieder bei 250 MHz.
Wäre aber cool, wenn man das nur auf eben diesen Multiplexer begrenzen könnte, und der ganze Rest mit niedrigerem Takt laufen könnte. Dann hätte man eine Chance... -
Stimmt, aber das will ja hier im Thread niemand - die Rede war von kleinen Auflösungen und wenig Farbtiefe im Rechner, lediglich für die Ausgabe war der Wunsch da, die interne Auflösung zwecks besserer Displaykompatibilität und schärferer Darstellung möglichst auf 1920x1080 aufzublasen. Das geht aber auch ohne das fertige Bild nochmal durchs RAM zu schleusen.
Das hast Du irgendwie recht. Aber sogar dann musst Du ja irgendwie eine Zeile z.B. zwischenspeichern, um sie 2x auszugeben? Sogar fürs Blockram ist dieses Tempo heftig!
Ich hab mal angefangen ganz einfachen Code zu schreiben um die Bits an 3 Ausgänge rauszuschieben und Quartus sagt, dass das noch mit so 370 MHz geht. Aber danach muss ich ja irgendwoher das nächste Byte für jede Farbe holen. Da werden die Probleme anfangen.
-
Nur mal kurz zur Einnordung:
Wenn ich eine Full-HD Grafik habe mit
1920 x 1080 Pixel x 3 Byte rgb Farbe x 60 Hz Bildfrequenz,
dann muss ich knapp 356 MB / s aus dem Bildschirmspeicher lesen. Das ist weit jenseits der gängigen Rams auf den günstigen FPGA Boards, und da ist ja noch keine Bandbreite für die CPU reserviert, die ja irgendwie/irgendwann in den Bildschirmspeicher schreiben muss, um eine Animation zu erreichen.
So geht es also nicht...
-
Aber noch was anderes: in der damaligen goldenen Zeit der Computer-Anfänge (Apple2, c64 usw) war das docj auch kein Wunschkonzert der Software-Entwickler. Die konnten auch nicht so einfach entscheiden, ob sie nun lieber 16 oder 32 Sprites haben wollen. Die Hardware Entwickler haben entschieden, dass 8 Sprites in den VIC passen und de Software-Entwickler hatten damit gefälligst klar zu kommen! Dann war es deren Aufgabe mit der existierenden Hardware halt das Maximum aus dem Rechner zu holen.
Also: wenn M. J. eine tolle VGA Grafik aus dem kleinen FPGA Boardlein holt, warum kann man sich nicht einfach freuen und schauen, was man aus dieser Hardware herausholen könnte? Die Programmierer damals haben doch auch die Auflösung benutzt, welche die Rechner damals boten und ihre Spiele entsprechend angepasst, dass es gut aussah?
-
Display MoreBzgl. bezahlbarer Hardware mit HDMI ist mir auch noch ein weitere Option eingefallen, die hier wohl noch nicht in Betracht gezogen wurde:
Arduino MKR Vidor 4000
Der hat einen kleinen ARM, einen MAX10 FPGA mit 16000 Logik Elementen und scheint sehr ähnlich zum Cyclone3 und er hat Mikro-HDMI Ausgang.
Gibt es so ab 65€.
Muss mir die Details anschauen, vor allem was der mit den mitgelieferten Arduino Grafik-Bibliotheken für Auflösungen macht.
Das sieht wirklich interessant aus! Ich würde jetzt nicht meine Hoffnung auf die Arduino Libs legen, aber wenn man nur mal die Hardware an sich nimmt, dann find ich das Preis/Leistungsverhältnis interessant.
Zum FPGA Bastel-Einstieg find ich es bisserl teuer, aber man könnte es ja als Ziel für eine Portierung nutzen. Dann könnten ein Endanwender, der bereit ist Geld zu investieren, gleich in dieser Klasse einsteigen.
