N64RGB Familie von borti - Infos, Support, etc. pp

    • Nintendo 64

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • N64RGB Familie von borti - Infos, Support, etc. pp

      Hallo Community,

      das N64RGB hat in den letzten Wochen und Monaten relativ große Ausmaße angenommen. Gerade mit dem N64 Advanced Projekt stiegen die Anzahl der News und Supportanfragen imens. Und nun ist es endlich soweit - der 'offizielle' Thread dafür :)


      Hier einmal, worum es geht





      Das Projekt ist auf GitHub gehostet und für Jedermann frei verfügbar. Dort sind auch alle Informationen; dennoch hier nochmal die wichtigsten Eigenschaften:

      • N64RGBv2.1:
        • MaxII / Max V CPLD basierend mit ADV7125 als DAC
        • RGB Ausgang mit CSync (LV-TTL und 75ohm), optional Sync-on-Green
        • VI-Deblur für 240p (per Controllerkombo an und aus) oder Schalter
        • 16bit Modus (Reduzierung der Farbtiefe pro Kanal auf 5bit (R & B) bzw. 6bit (G)) per Comtrollerkombi oder Schalter
        • Reset per Controller
      • N64Advanced:
        • Cyclone IV E bzw. Cyclone 10 LP FPGA basierend mit ADV7125 als DAC
        • RGB Ausgang, optional Sync-on-Green oder auch Componenten Ausgabe (YPbPr)
          • CSync (TTL und 75ohm)
          • HSync und VSync als TTL (für VGA)
        • Linedoubling optional (240p -> 480p / 288p -> 576p; optional auch de-interlace: 480i -> 480p / 576i -> 576p)
        • Gamma-Korrektur (kommt mit Menüsteuerung)
        • VI-Deblur für 240p (automatisch bzw. per Controllerkombo an und aus)
        • 16bit Modus (Reduzierung der Farbtiefe pro Kanal auf 5bit (R & B) bzw. 6bit (G)) per Comtrollerkombi
        • Reset per Controller
        • Menüsteuerung (aktuell in Arbeit; derzeit noch per Lötjumper)


      Spoiler zeigt ältere Versionen:
      Spoiler anzeigen



      • N64RGBv1:
        • MaxII / MaxV CPLD basierend mit Widerstandsnetzwerk als DAC mit THS7374
        • RGB Ausgang mit CSync (LV-TTL und 75ohm)
        • VI-Deblur für 240p (automatisch bzw. per Controllerkombo an und aus)
        • 15bit Modus (Reduzierung der Farbtiefe pro Kanal auf 5bit) per Comtrollerkombi
        • Reset per Controller
      • N64RGBv2:
        • MaxII / Max V CPLD basierend mit ADV7125 als DAC
        • RGB Ausgang mit CSync (LV-TTL und 75ohm), optional Sync-on-Green
        • VI-Deblur für 240p (automatisch bzw. per Controllerkombo an und aus)
        • 15bit Modus (Reduzierung der Farbtiefe pro Kanal auf 5bit) per Comtrollerkombi
        • Reset per Controller




      Ich möchte auch nochmal erwähnen, dass @F_L_a_S_H ein sehr ähnliches Projekt hat: [Projekt] N64 RGB Platinen-Design und Code von F_L_a_S_H
      Er verwendet einen kleineren CPLD. Wer Featrues wie den VI-Deblur Schätzalgorithmus und Reset per Controller nicht benötigt, sollte dort mal ein Auge rauf werfen :)

      Wer eine Platine von Viletim hat (Link) kann auch mal einen Blick in meinen GitHub-Repository werfen. Dort liegen alternative Programmingfiles, um Features wie VI-Deblur Schätzalgorithmus und Reset per Controller dort nachzurüsten.


      Wofür ist dieser Thread?


      Ich möchte diesen Thread nutzen, um in Zukunft hier Updates zu posten sowie Supportanfragen zu beantworten. Gerne können hier auch Ideen und Anregungen für Verbesserungen mitgeteilt sowie gefundene Fehler gepostet werden. Auch Fragen zum Featureset können hier sehr gerne gestellt werden.

      Auf Fragen kann natürlich auch jeder Antworten.

      Wofür ist dieser Thread nicht?

      Eigentlich möchte ich nicht, dass es hier generelle in der Art: "Mein Mod geht nicht?", "Welche Litze geht nun wohin?", etc. pp gestellt werden. Dafür gibt es das Unterforum Hilfe - Probleme bei Mods & Technik

      Also dann - viel Spaß mit dem Thread :)


      Eine kleine Danksagung

      (auf Mitglieder des Forums beschränkt - mehr bei GitHub)

      @ikari_01: Implementierung der VI-Deblur Austastung und Phasenerkennung für PAL und NTSC
      @Xenogears: Unterstützung beim N64Advanced
      @ArcadeTV: Erstellen des Header-Logos für das N64Advanced (später im Menü)

      Vielen Dank Euch dreien!!!


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von borti4938 ()

    • Letztes Update N64RGBv1 / N64RGBv2


      • PCBs wurde aus dem GitHub Repository entfernt
      • Timingconstraints wurde angepasst, sodass jetzt alle Pfade definiert sind. Dies sollte "zufällige" Bildprobleme beseitigen (z.B. Gradientenfehler, die bei einem auftreten, bei dem anderen nicht)
      • Wenn das Flex-Kabel am RCP-NUS verwendet wird, empfehle ich nun, dass die Eingangswiderstände auf der Modding-PCB durch Ferritkerne ausgetauscht werden! (siehe jeweilige BOM)

      Letztes Update N64RGBv2.1

      • Neueres Design des N64RGBv2
      • Gleiche Features mit geringen hardwaretechnischen Verbesserung
      • Verwendung der gleichen Flex-Kabel zur Installation wie das N64Adv möglich


      Letztes Update N64Adv


      • Kleinere Bugfixes in der Firmware
      • Timingconstraints wurde angepasst, sodass jetzt alle Pfade definiert sind. Dies sollte "zufällige" Bildprobleme beseitigen (z.B. Gradientenfehler, die bei einem auftreten, bei dem anderen nicht)
      • LineX2 von 480i auf 480p habe ich in vertikaler Richtung stabilisiert.
        Bisher hat sich das Bild in 480i auf 480p nach dem einfachen de-interlacen um eine Zeile nach oben und runter bewegt von Frame zu Frame. Das Bild wirkte unruhig. Dies ist jetzt entfernt und das Bild wirkt deutlichst ruhiger. Scanlines habe ich testweise für diesen Modi auch aktiviert.
        • Update: Bugfix für LineX2 bei einigen PAL Games in 288p
      • Scanlines haben jetzt eine alternative Berechnung - die kann man im LineX2 Menü für 240p unter dem Punkt "Scanline Method" einstellen.
        Die alternative Berechnung nimmt jetzt nicht mehr nur die aktuell ausgelesene Zeile zur Berechnung der Scanline. Es wird die vorherige (bei "Even") bzw. die folgende (bei "Odd") Zeile mit berücksichtigt und ein Mittelwert gebildet.
        Diese Art der Bereichung ist (derzeit) nicht für 480i->480p verfügbar
      • Neues Menü für Linedoubling - man kann progressive und interlaced Eingang unabhängig voneinander konfigurieren (SL Optionen können verbunden werden)
      • Um die o.g. Features umzusetzen, habe ich den Buffer von zwei auf fünf Zeilen (vier hätten auch gereicht) erhöht. Das Processing-Delay beträgt jetzt zwei Zeilen (vorher war es eine halbe), was immer noch nicht spürbar ist.





      RCP-NUS Breakout PCBs und Flex-Kabel


      • Es gibt universelle Breakout PCBs, die an den RCP-NUS Videochip-Ausgang gelötet wird. Auf der PCB sind Line-Buffer für Daten und Videotakt vorhanden, die die Signalintegrität am Moddingboard verbessern.



      Eine Anpassung der Readmes und des Guides habe ich noch nicht vorgenommen.

      Updates sind auf GitHub verfügbar. Download wieder in den jeweiligen firmware-Ordner unter outputs. Da ich momentan wenig Zeit habe zum selber testen, bin ich auf Feedback angewiesen! Leider habe ich letztes Mal kein Feedback aus der Community bekommen.


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

      Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von borti4938 ()

    • Einmal ein Paar Q&As (aus dem N64A Sammelbestellthread)



      USB Blaster
      Spoiler anzeigen

      Neocrypton schrieb:

      eine frage zum blaster. ist der speziel für den cyclone? oder könnte cih damit theoretisch auch einen Xilinx XC9536XL beschreiben der shcon auf einer RGB platine bestückt ist?
      Nur Altera / Intel CPLDs und FPGAs.
      Auf dem Board wird übrigens ein Cyclone 10 LP sein.

      Antwort von Unregistered dazu:

      Unregistered schrieb:

      Man kann verschiedenes mit so einem USB-Blaster brutzeln, aber für die Xilinxe brauchst du was anderes. Entweder die USB Box, einen Klon davon oder einen Parallel Port am PC und nen herkömmlichen JTAG Adapter.
      Oder nen USB2LPT Adapter + JTAG
      Oder, oder, oder... gibt scheinbar noch einige Lösungen mehr, wie den Bus Piraten oder eine Lösung mit dem gutem alten FT232 etc...

      Haben sich andere Leute auch schon gefragt...
      eevblog.com/forum/microcontrol…with-alterra-usb-blaster/

      Womi schrieb:

      Könntest du einen geeigneten USB Blaster zum Updaten der Firmware verlinken (am besten bei AliExpress)?
      Aliexpress
      eBay



      Componenten Kabel
      Spoiler anzeigen

      Oelii schrieb:

      Ist die Platine mit den einfachen Wii Component Kabeln kompatibel?
      Wenn man den entsprechenden Ausgang sich an das N64 baut, dann ja.
      Man könnte sich auch ein solches Kabel (oder anderes beliebiges Componentenkabel kaufen und an ein Ende n MultiAV löten.
      Ansonsten nein.

      Ich selber habe ein SCART zu Cinch Adapter mir gebaut; bastel mir aber demnächst n eigenes Kabel. Dann mache ich mal n Bild und füge das hier mit an.

      Edit zu der Frage: im Spoiler die versprochenen Bilder:
      Spoiler anzeigen

      Adaper - die einzelnen Leitungen zu den Cinch-Steckern sind einzelgeschirmt.
      Scart_zu_Cinch.JPG

      Und das Kabel:
      Hier einmal der Übergang vom fünf-Adrigen Ende zu den einzelnen Leitungen. Alles mit Einzelschirmung. Am anderen Ende hängt der MultiAV ;)
      Cinchkabel.JPG






      Funktionalität
      Spoiler anzeigen

      cyrex schrieb:

      Ich frag noch Mal für Doofe wie mich (auch wenn ich schon bestellt habe :P)... ich lese immer 31KHz RGB. Ich kann damit auch ein sauberes Component via 5 Stecker auf meine LCD Glotze zaubern, oder?
      Ja


      captain-graubart schrieb:

      De-Blur ist beim Upscaling nicht verfügbar?
      Die Funktionen sind unabhängig voneinander. Geht also beides zusammen.


      captain-graubart schrieb:

      Gibt es wohl schon Bildchen von 480p Output mit De-Blur und Scanlines an? :)
      Ja, gibt es. Ich habe Bilder mit der Elgato Game Capture HD aufgenommen. Als Eingang habe ich den Komponenten-Eingang verwendet.
      Allerdings sind die Bilder komprimiert und reine Bitmaps kann ich leider nicht aufnehmen. Deswegen nicht wundern, dass das Bild mit steigender Scanline-Stärke blasser wird bzw. Schwarz-Weiß ist bei 100% Scanlies-Stärke :s000:

      Bilder habe ich hier hochgeladen: dropbox.com/sh/ous4834bui8bqym…lXcTO6YWb-kRLpRMJ_Ha?dl=0

      De-Blur ist bei Mario 64 an. Der Dateiname ist zu lesen:
      "sl" mit anschließender Zahl = Scanline-Stäke in Prozent.
      "ga" mit anschließender Zahl = Gammawert für Gammakorrektur in x,y (also ga11 = gamma 1,1 angewendet)

      Das Video für ScoreMaster Okt. '17: Diddy Kong Racing (N64) ist auch an der Elgato entstanden; nur habe ich hier den OSSC noch dazwischen gehabt. Auch hier habe ich mit der Komprimierung zu kämpfen.


      Come2Fabi schrieb:

      lohnt sich das denn auch für die mit 480i Röhren und bisher kein RGB mod?
      Jein; es kommt halt darauf an.
      'Einfache' RGB Mods mit nem kleinen CPLD bieten solche Sachen wie DeBlur auch. Auch IGR-Geschichten habe ich in meine Version mit CPLD mit integriert.
      Was man nicht nutzen kann, ist das Linedoubling. Das muss aus.
      Die CPLD-Variante ist auch günstiger als der Mod mit dem FPGA.

      Dafür kriegt man mit dieser FPGA-Version in naher Zukunft ein Menü zum Einstellen und braucht keine Jumper / Schalter / etc. mehr (hoffentlich; ich arbeite daran. Ist kein Versprechen).

      Ob die Gründe Pro oder Contra überwiegen, muss jeder für sich selber wissen.

      Kloks schrieb:

      Generell wäre ich schon interessiert, aber gibt es irgendwo Bilder oder Videos wo man sehen kann, wie das ganze in Aktion aussieht? Liest sich zumindest nicht so, als ob man da einfach nur das einfache Bild per 31khz auf RGB/Component ausgibt, sondern auch ein paar Zusatz Optionen hat.

      Ist es z.B. mit dem Features eines Ultra HDMI Mods zu vergleichen, bei der Bildausgabe oder wie kann ich mir das vorstellen?

      Ich werde mal versuchen, ein Video zu machen. Noch habe ich ja die Capture Card von @GaiaGensouki ausgeliehen.
      (Ich merke gerade, schon recht lange... *Upps* - wie die Zeit rinnt.)

      Die Optionen sind nur teilweise mit dem UltraHDMI vergleichbar, da für einige Geschichten ein Framebuffer notwendig ist. Bei mir wird gerade Mal eine Zeile zwischengespeichert.
      Was so vergleichbar ist, sind Geschichten wie De-Blur, Scanlines, Reset per Controller. Derzeit ist alles per Lötjumper einzustellen; ein Menü ist in Planung. Mit dem Menü kommt dann auch n Art Gamma-Boost, den man einstellen kann. Eine lauffähige Implementierung zum Gamma habe ich bereits.


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von borti4938 ()

    • Ist schon "lange" Korrigiert :P


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    • ikari_01 schrieb:

      Ich habe gestern abend mal das aktuelle fertige dev_tests-Binary aufgespielt und mich am Menü erfreut :) Allerdings bildet sich das Ding manchmal Controllereingaben ein, die nicht da sind. Wenn ich eine Option ändere, springt es manchmal plötzlich eine Zeile hoch und ändert die Option dort.
      Danach habe ich noch ein bisschen Doom 64 angespielt und bei manchen Manövern hat das gute Stück zwischen YPbPr und RGB hin- und hergeschaltet :D
      Hat das noch jemand?

      borti4938 schrieb:

      Ja, dass mit dem Controller ist mir bekannt und da muss ich definitiv nochmal ran. Der PIF-NUS geht ohne Probleme, aber je nach Controller jittert das Signal ordentlich!

      Eigentlich sollte umstellen an der Config nur möglich sein, wenn das OSD auf ist. Ich muss dann wohl mal Doom anmachen und schauen, ob ich den Fehler reproduziert bekomme

      Ist wohl doch n Bug. Habe ich nicht richtig abgefangen und man kann durch das Menü gehen, ohne dass es auf ist. Update ich beizeiten - Commit habe ich gestern nicht mehr geschafft.

      Auch habe ich ein wenig am Controller gearbeitet, dass die Glitche wenige auftreten. Vielleicht kann ja mal @jago85 preisgeben, wie seine Implementierung im [WIP] UltraPIF - Multi Region N64 PIF Replacement aussieht ;) Gerne auch per PN.


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    • Ich habe gerade mal einen oberflächlichen Blick auf deinen Code geworfen. Leider bin ich in Verilog nicht so fit und mir fällt es echt schwer, diese Sprache zu lesen. Ich musste z.B. erstmal rausfinden, was das & bei "if (&wait_cnt)" macht. Das ist aber auch echt tricky und man muss genau hinsehen ^^

      Mir ist allerdings aufgefallen, dass du das Signal CTRL_i vom top-Modul intern direkt verwendest. Wenn ich das richtig sehe, handelt es sich dabei um die Empfangsleitung des Controllers am PIF. Das ist ein asynchrones Signal und darf in einem synchronen Design nicht ohne vorheriges Einsynchronisieren verwendet werden.

      Mehr Infos und eine gute Erläuterung gibts z.B. hier: lothar-miller.de/s9y/categories/35-Einsynchronisieren

      Wenn du also dein CTRL_i über zwei Flipflops jagst, solltest du CTRL_i und das erste FF an keiner anderen Stelle verwenden. Das zweite FF ist dann das aktuelle Signal. Du könntest in igr dem Eingang CTRL in CTRL_async umbenennen. CTRL_ff und CTRL als reg anlegen.

      Dann unter always @(posedge CLK_4M) begin

      CTRL_ff <= CTRL_async;
      CTRL <= CTRL_ff;

      Mir ist auch nicht ganz klar, warum sampling_point_n64 und sampling_point_ctrl ihre Werte ändern. Ich hätte einen Zähler beim Empfang der ersten 0 gestartet (was bei dir wohl auch so ist) und den Samplepoint genau auf 2 us nach der fallenden Flanke gelegt. Dann etwa 3,5 us nach der fallenden Flanke, wenn das Signal sicher wieder 1 ist, wird wieder mit dem Warten auf die nächste 0 begonnen. Aber das kann ja auch anders gehen. Ich müsste dein Modul mal simulieren, um es besser zu verstehen.

      Meinen Code könnte ich schon bereitstellen. Der ist allerdings in VHDL und realisiert auch das Senden zum Controller. Zusätzlich verbindet der noch zwei Clock Domains. Da ist also viel Zeug drin, was du nicht brauchst.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von jago85 ()

    • @jago85

      Ich habe gerade mal oberflächlich einen Blick auf Deinen Beitrag geworfen. Leider bin ich ich völlig überfordert dem Inhalt mangels umfangreicher Programmierkenntnisse zu folgen. Gleiches gilt für @borti4938 und viele andere hier, die mal eben so auf dem Ohrschmalz einen funktionierenden Code herunterschreiben.

      Also stellvertretend - und bestimmt auch für viele andere hier im Forum - H E R Z L I C H E N D A N K für Euer unermüdliches Engagement und schön, dass es Euch gibt.

      P.S.:

      jago85 schrieb:

      genau auf 2 us nach der fallenden Flanke
      Davon verstehe ich auch nichts - hat mit Fußball zu tun, vermute ich :)
      Wenn man mit 4 Tasten am Pad mehr Spaß hat, als mit 12 ist es Retro, dass man fühlen kann... :love:

    • @jago85: Danke für dein Feedback :)


      jago85 schrieb:

      Mir ist allerdings aufgefallen, dass du das Signal CTRL_i vom top-Modul intern direkt verwendest. Wenn ich das richtig sehe, handelt es sich dabei um die Empfangsleitung des Controllers am PIF. Das ist ein asynchrones Signal und darf in einem synchronen Design nicht ohne vorheriges Einsynchronisieren verwendet werden.
      Das habe ich in der Tat nicht beachtet - ich werde dies ändern!!! :thumbsup:


      jago85 schrieb:

      Mir ist auch nicht ganz klar, warum sampling_point_n64 und sampling_point_ctrl ihre Werte ändern. Ich hätte einen Zähler beim Empfang der ersten 0 gestartet (was bei dir wohl auch so ist) und den Samplepoint genau auf 2 us nach der fallenden Flanke gelegt. Dann etwa 3,5 us nach der fallenden Flanke, wenn das Signal sicher wieder 1 ist, wird wieder mit dem Warten auf die nächste 0 begonnen.
      Das mit den Abtastzeitpunkten kommt historisch eher von der CPLD-Version, wo ich keinen separaten Takt und keine PLL zur Verfügung habe.

      Dort muss ich mit dem Video-clock und Registern einen Abtasttakt generieren. Da schon alleine der VCLK von PAL zu NTSC sich "stark" unterscheidet, habe ich hier eine dynamische Schätzung eingebaut. Des Weiteren gehe ich davon aus, dass je nach Controller und Konsole 4us nicht gleich 4us sind. Dazu kommt noch Jitter, der beim Controller doch sehr sehr hoch ist.

      Deswegen wird separat für Controller und N64 geschätzt. Im Ergebnis kommt aber was bei 2us als Abtastpunkt raus.

      Die Situation auf dem N64Advanced ist sicherlich entschärft, da ich hier extra einen Quarzoszillator für systeminterne Aufgaben (wie dem Controllerabtasten) habe. Drinnen lassen werde ich es wahrscheinlich dennoch.


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    • Ach ja noch was: Mit der PLL altpll_1 sys_pll(...) schaffst du in deinem Design drei Clock Domains. Auch hier kann es passieren, dass Signale, die in der einen Clock Domain synchron sind, für eine andere Clock Domain asynchon werden und dort nicht mehr direkt ohne Einsynchronisieren verwendet werden dürfen. Wenn es nur darum geht, SYS_CLK runter zu teilen, wäre ein Counter, die sicherere Lösung und dann einfach alles in der SYS_CLK-Domain machen.

    • Die Übergabewerte werden so lange gehalten, bis die auf die andere Domain übernommen sind. Getriggert wird nicht von den Signalen selbst, sondern erst nachdem neue gültige Signale da sind. Aber dennoch danke für den Hinweis.


      borti4938 schrieb:


      jago85 schrieb:

      Mir ist allerdings aufgefallen, dass du das Signal CTRL_i vom top-Modul intern direkt verwendest. Wenn ich das richtig sehe, handelt es sich dabei um die Empfangsleitung des Controllers am PIF. Das ist ein asynchrones Signal und darf in einem synchronen Design nicht ohne vorheriges Einsynchronisieren verwendet werden.
      Das habe ich in der Tat nicht beachtet - ich werde dies ändern!!! :thumbsup:

      WOW - Tag - Nacht - Unterschied. Habe es gerade reingehauen und bin begeistert!!!


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    • borti4938 schrieb:

      WOW - Tag - Nacht - Unterschied. Habe es gerade reingehauen und bin begeistert!!!
      Das freut mich. Ich hatte mit dem Synchronisieren mal ein ähnliches Erlebnis. Da ging einfach gar nichts. Seitdem achte ich mehr darauf.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von jago85 ()

    • Erst mal WOW!
      Danke für die viele Arbeit, die in den Platinen und der Programmierung steckt.

      Ich kenne mich mit Video Processing jetzt überhaupt nicht aus und deswegen verstehe ich die Vor- und Nachteile der beiden Varianten N64RGBv1/N64RGBv2 nicht.
      Liefert die eine ein besseres Bild oder gibt es andere Vorteile?

    • seewood schrieb:

      Wenn Ihr euch den Code anschaut, sieht das eigentlich für euch so aus ?
      @seewood - Dein Beitrag war absolut nicht hilfreich. :-). Jeder weiss doch, das der Code so aussieht...




      Der Code stammt übrigens aus dem Kochbuch der Frau des japanischen Designers - ein Sushi-Rezept. Was das nun wieder bedeutet für den Code, den @borti da geschrieben hat, kann uns wohl nur das Orakel sagen. Was ich aber sicher weiss - das Board hätte das Orakel nicht besser machen können. So klar habe ich N64 zuvor noch nie gesehen - und da meine ich nicht die Umrisse der Konsole, sondern das Ergebnis auf dem Screen
      Wenn man mit 4 Tasten am Pad mehr Spaß hat, als mit 12 ist es Retro, dass man fühlen kann... :love:

    • mc.zwerg schrieb:

      Ich kenne mich mit Video Processing jetzt überhaupt nicht aus und deswegen verstehe ich die Vor- und Nachteile der beiden Varianten N64RGBv1/N64RGBv2 nicht.
      Auf der v1 ist ein Widerstandsnetzwerk als Digital-zu-Analog-Wandlung mit anschließendem Videoverstärker.
      Auf der v2 ist hier ein spezieller Video-DAC Chip.

      Salop gesagt hat man durch den spezialisiertem DAC-IC eine bessere Trennung zwischen digitalem Teil und analogem Teil.

      Folgendes Problem habe ich beispielsweise gar nicht / deutlichst schwächer, wenn ich den Video DAC an 5V habe: Video von leonk (YouTube)
      Wenn ich den Video-DAC an 3.3V hänge, habe ich das auch.
      (3.3V - Versorgungsspannung des digitalen Teils auf dem N64; 5V - Versorgungsspannung analoger Teil)

      In der v1 kommt man da (noch) nicht so wirklich um das Problem herum.

      Nachteil: der Video-DAC kostet ein wenig mehr als die Paar Widerstände.

      Achja: auf der N64Advanced nehme ich auch den Video-DAC.

      @seewood, @Xenogears
      Naja, der Code ist oftmals doch mit deutlich mehr Fragezeichen als ihr denkt. Mit der Zeit wächst sowas halt und man vergisst auch einiges. Auch nimmt die Motivation, den Code gut zu kommentieren, irgendwie mit der Zeit ab.

      Beispiel:

      borti4938 @ N64A firmware schrieb:

      if (&{nHS_i_buf,~nHS_i,~line_overflow,valid_line})
      Frage mich mal spontan, was ich mir dabei gedacht hatte (line_overflow und valid_line) sind auch nochmal andere Ausdrücke :s000:


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    • Stell dich mal nicht in den Schatten deines eigenen Codes. Sicher gibt es Höhen und tiefen. Und auch wenn der Xeno und ich auf deinen kosten rumspaßen hab ich bis jetzt mehr valid_content von dir gesehen als von mir in diesem Thread! Bleib dran, du machst n guten job :thumbsup:
      mfg seeWood

      <>=G - KunaiGC - github.com/KunaiGC/KunaiGC
      [328] - XenoGC328 - github.com/seewood/XenoGC328

      - I would love to change the world, but they won’t give me the source code -

    • Habe zwei Netzteile getestet (Elkos neu) sowie ein Labornetzteil. War unabhängig davon. Im Spektralbereich der 3.3V Versorgungsspannung sieht man Peaks bei Vielfachen von 12.5MHz, was eher auf das #DSYNC als Übeltäter deutet. Sicher bin ich mir aber nicht und ich lasse mich auch eines besseren belehren :)


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    • Separater 3.3V Spannungsregler an 12V hilft:

      Spoiler anzeigen


      So zumindest eine noch nicht spruchreife Lösung.


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    • Ich fühl mich zwar geehrt über die Nennung auf dem Board, aber auch das Design geht zu 100% auf deine Kappe :spitze:
      Hoffe aber, dass das Addon der mühsamen Raterei bezüglich Netzteile, Kondensatoren und Filter ein Ende setzt.

    • Und wisst Ihr was das beste an der RGBv2 Platine ist ? :)

      Das Sie bei mir bereits verbaut ist :spitze: THX an @borti4938 für das Platinendesign !
      Einbau ging (mit etwas Hilfe) ganz gut von der Hand - bisher mein bestes Lötergebnis wie ich finde...

      - RGBv2 Rainbow Edition -
      Spoiler anzeigen








      Hab den Mod auch direkt auf meinem MX6000 getestet:
      B&O:
      Spoiler anzeigen

      Ich weiß der Vergleich ist unfair:



      mfg seeWood

      <>=G - KunaiGC - github.com/KunaiGC/KunaiGC
      [328] - XenoGC328 - github.com/seewood/XenoGC328

      - I would love to change the world, but they won’t give me the source code -

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von seewood ()

    • Ist noch ungetestet. Warte noch auf PCBs, um die Wärme bei einem längeren Test auch etwas abzuführen ;)

      Kleines Update zu den Projekten:
      • Alle CPLD und FPGA haben Updates bzgl. VI-DeBlur Schätzung und Timing Verbesserungen erhalten
      • Im dev_tests Zweig ist jetzt ein Firmware-Build, mit dem man seine Config speichern kann. Diese wird auch bei Neustart geladen.
      Hier ist einmal der Link zum Menü-Test: github.com/borti4938/n64rgb/tr…mod/firmware/output_files

      Ich denke da gerade speziell an @charlie, der das durch seinen defekten Resetknopf gebrauchen kann ;)

      Ich will aber dazu sagen: fertig ist es noch nicht und die Config wird weg sein, sobald das nächste Update kommt, weil ich einiges Umstrukturieren möchte.


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    • Einmal n kleines Update:

      Nachdem lange Zeit nichts mehr passiert ist - zwei Wochen oder so :s000: - habe ich die letzten Entwicklungen bzgl. Scanlines am OSSC einmal für dieses Projekt adaptiert.

      Also: Hybride Scanlines sind verfügbar sowie einmal die Option, die Scanlines für das Menüfenster auszuschalten.

      Und jetzt: Urlaub :)

      Danach: Support vom Hori-Pad. Dickes Dank an @captain-graubart hier schon mal, der sich für eine Ausleihe schon bereit erklärt hat. Ich komme auf dich zu ;)
      Interessiert sicherlich auch @jago85 für sein PIF-Projekt: das Hori-Pad hat n anderes Timing als die Originalen ;)


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub

    Inhaltsverzeichnis

    1. Hier einmal, worum es geht
    2. Wofür ist dieser Thread?
    3. Wofür ist dieser Thread nicht?
    4. Eine kleine Danksagung
    5. Letztes Update N64RGBv1 / N64RGBv2
    6. Letztes Update N64RGBv2.1
    7. Letztes Update N64Adv
    8. RCP-NUS Breakout PCBs und Flex-Kabel
    9. Einmal ein Paar Q&As (aus dem N64A Sammelbestellthread)