Um es mal mit (wie) 0xdeadbeef zu sagen: Dat tut et tuen tun.
Sowas soll ich gesagt haben tun? Das tut gar nicht nach mir klingen.
You are about to leave Forum64 to get redirected to the following address:
Please note, that the target website is not operated by us. We are not responsible for it's content nor does our privacy policy apply there.
Um es mal mit (wie) 0xdeadbeef zu sagen: Dat tut et tuen tun.
Sowas soll ich gesagt haben tun? Das tut gar nicht nach mir klingen.
Eine Game-Engine ist lange noch kein Spiel, aber auf den ersten Blick scheinen zumindest die technischen Hürden weitestgehend überwunden zu sein.
In einem der Kommentare zu "Mythos" ist ein Link auf eine entsprechende Game-Engine:
https://github.com/leissa/c64engine
Die letzten Änderungen sind immerhin erst 7 Monate alt.
Daß der VC-20 "noch über für viele Jahre lang produziert wird" und es "nicht zu Abänderungen kommen wird", war dann halt auch eine eher schlechte Vorhersage. Zwei Jahre nach dem Artikel wurde die Produktion eingestellt.
Auch wenn ich den C64 gar nicht verwende, sry 0xdeadbeef
Frevel!
der LumaFix von ADAC (wieder sry 0xdeadbeef)
Steinigt ihn!
Bei Fanatical gibt es "Crumble"
https://www.fanatical.com/en/game/crumble
Vermutlich muß man wie üblich seinen Steam-Account verbunden haben.
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
Ich habe heute eine V1.2 eingespielt.
QuoteDisplay MoreV1.2
Changes compared to V1.1
# Moved the fuse F2 to avoid mechanical issues or even a short circuit when the expansion port bracket is installed (already done in V1.1b)
# Unified placement of diode networks to make replacements easier (i.e. swapped 5 pin type to reflect the placement of 9 pin types)
# Changed DPA5/DPC5 from 5 pin types to 9 pin types to also protect FLAG2 and INTRST and to move CNT1/SP1 from control port networks (too far away)
# Added SMD ESD protection diodes (ESDA5V3SC5) on the bottom of the PCB as alternative placement option for the THT diode networks DPA/DPC which are increasingly difficult to get
# Changed the Polyfuse F1 for the 9VAC creation from 200mA to 300mA since 200mA are probably a bit conservative
# Bypassed the ferrite bead for the AEC connection from VIC to Lumafix/Stripefix (new net AEC_RAW) hoping to improve stripe fix behavior
# Changed the R values for the Lumafix/Stripefix from 2k/200R (range: 2k..2.2k) to 1k/1k (range: 1k..2k) to allow stronger compensation where needed
# Added header J50 to allow access to IO1/IO2 for external SID extensions without soldering
# Fixed shifted silkscreen pin names for J41 and aligned pins names better for J36
# Further improved ground plane
# Added alternative WinCupl project DUALSID_PATCHED where the 2nd SID will react to 0xD420, 0xD500 and 0xD520 when configured to 0xD520
https://bitbucket.org/fade0ff/c64-250466/downloads/
Ist auch so. Man muß die Cookies löschen.
Das Spiel ist in Deutschland nicht erhältlich
Faszinierenderweise bei Steam aber schon.
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.
Und wieder Prime:
Für mich ein Volltreffer. Das Genre, mit dem ich am allerwenigsten anfangen kann und dann noch bei Epic, die ich aus Prinzip boykottiere.
Hat er natürlich nicht, weil eine Ultimate 64 eine solche Einstellung gar nicht hat.
Oops. Die Dokumentation ist aber auch etwas verwirrend.
Mal am Cartridge-Timing (Phi1/2) gedreht?
Wobei das anscheinend nachbearbeitet wurde. Der Cursor müßte eigentlich etwas weiter links sein.
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:
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.