Posts by 0xdeadbeef

  • Heute so gebastelt ...

    Nachdem ich die V1.2 meines 250466+-Boards nach wochenlangen zwangsneurotischen Detailverbesserungen gestern endlich eingespielt habe, konnte ich mir wieder meinen lange zurückgestellten NeoGeo-Miniprojekten zuwenden.


    Beim Aushilfs-Mini-Gamepad habe ich die Buttons besser angeordnet und die meisten der Widerstände entfernt, weil das mit einem echten AES mit 1k-Pullups sonst nicht so richtig funktioniert hätte.

    Ich habe nur für die (Open Collector) Ausgänge OUT1/2/3, die für Superguns usw. teils für weitere Buttons benutzt werden, 330Ohm-Widerstände dringelassen und den Jumper geändert, um Out3 bei Bedarf über 330Ohm mit Button D kurzzuschließen, was bei echten AES-Joysticks wohl zur Identifizierung der Joysticks benutzt wird.

    Außerdem habe ich mich überzeugen lassen, das Design komplett auf THT umzustellen.




    Bei meinem Adapter USB -> DB15 hat sich auf den ersten Blick nicht viel geändert, aber ich habe den Prozessor komplett ausgetauscht.

    Statt eines STM32G0B0CET6 (Cortex M0+) werde ich jetzt einen STM32H503CBT6 (Cortex M33) benutzen, der überraschenderweise deutlich günstiger ist und USB ohne externen Quarz kann.

    Mir ist nämlich leider irgendwann aufgefallen, daß das beim STM32G0B0CET6 nicht der Fall ist. Natürlich ist das jetzt wie Wühlmäuse mit Wasserstoffbomben zu jagen, aber hey, der kostet 50Cent weniger als der Cortex M0+.

    Die Platine ist außerdem ein paar Millimeter kürzer geworden, weil ich wie beim Joypad die meisten Widerstände bis auf die 330Ohm-Widerstände für die Ausgänge (AES) rausgeschmissen und die Funktion von J2 angepaßt habe.




    Leider hat mich in den letzten Wochen schon wieder ein neuer Wahn gepackt, nachdem ich mich in letzter Zeit mit "Superguns" für NeoGeo Arcade-Boards beschäftigt habe, hat sich bei mir der Wunsch eingenistet, selber eine optimierte Supergun für NeoGeo 2-Slot-Boards (MV2) zu basteln. Das ist aber noch ein weiter Weg und keine Ahnung, ob das jemals was wird. Habe ja auch noch gar kein solches Board und eigentlich habe ich eh keinen Platz und keine Zeit ;)

  • 250466+ oder der Versuch ein klassisches Board etwas zu optimieren

    Ich habe heute eine V1.2 eingespielt.


    https://bitbucket.org/fade0ff/c64-250466/downloads/


  • Heute so gebastelt ...

    Quote from Matula

    Der müsste nicht weiter links, sondern einfach kleiner sein.

    Die Größe stimmt tatsächlich ebenfalls nicht so ganz, aber er wurde auch nach rechts geschoben, damit seine linke Seite bündig mit der linken Seite des "R" ist - was in der Realität allerdings nicht der Fall ist.

    Zusätzlich wurde er aber in der Tat auch noch etwas vergrößert, wodurch er leicht mit dem "E" überlappt, was nicht sein kann. Zumal es ein e Überlappung im Subpixelbereich ist, was schon gar nicht sein kann.


     

  • C64C an HDMI

    Quote from stones73

    Oh ja das würde mich auch interessieren.. im git sehe ich ja nur die Platine an der die 2 Kabel angeschlossen werden, die gehen dann an den Antennenausgang der wohl vorher abgeknippst wird. von da gehe ich dann auch eien RaspberryPi? und nutze den RGBtoHDMI Kernel?

    Mein Verständnis ist, daß auf einem der Kabel (das andere ist Masse) ein binäres Signal ausgeben wird, das pro "Halb-Pixel" vier Helligkeitswerte kodiert, was dann zu 16 verschiedenen Werten pro Pixel führt.

    In der Beschreibung des "VIC II dizers" ist zwar die Rede davon, dieses Signal könnte dann unter anderem mit einem RGBtoHDMI weiterverarbeiter werden ("RGBtoHDMI device or something with equal capabilities"), aber das halte ich ehrlich gesagt für eine ziemlich irreführende Aussage. Es existiert ja kein RBG-Signal, also kann man auch nicht irgendein "RGB to HDMI"-Gerät benutzen.

    Um Farben aus diesen 16 Helligkeitskombinationen zu rekonstruieren, muß dieses sehr spezielle Signal ja erstmal wieder in Farben umgewandelt werden.

    Anscheinend ist nicht mal die Aussage richtig, daß das Signal mit einem "normalen" RGBtoHDMI verarbeitet werden kann, denn der Link geht zu einem "RGBtoHDMI Mono", das sich von einem normalen RGBtoHDMI unterscheidet:

    Code
    1. This board combines a basic RGBtoHDMI board with the features of the analog add-on that are relevant for monochrome input.

    Wie genau die Farben aus den Helligkeitsstufen rekonstruiert werden, ist mir noch nicht so ganz klar. Eigentlich hätte ich erwartet, daß das in der Software des RasPi passiert, aber ich habe auf die Schnelle keine spezielle Software für dieses "RGBtoHDMI Mono" gesehen. Im Repository der offiziellen RGBtoHDMI-Software findet sich allerdings ein Änderungskommentar "Add 8 level mono palette". Vermutlich ist das eine Konfigurationsoption der RasPi-Software.