Hello, Guest the thread was viewed9.9k times and contains 67 replies

last post from 1570 at the

C64-Rebuild auf 3,3V-Basis mit X uCs möglich?

  • Mach statt VIC-II doch den VDC vom 128er. Der hat keine Sprites :-)

    Und da gibt es auch so einen Haufen Software dafür am C64.

    "Wenn du überredet, ermahnt, unter Druck gesetzt, belogen, durch Anreize gelockt, gezwungen, gemobbt, bloßgestellt, beschuldigt, bedroht, bestraft und kriminalisiert werden musst. Wenn all dies als notwendig erachtet wird, um deine Zustimmung zu erlangen, dann kannst du absolut sicher sein, dass das, was angepriesen wird, nicht zu deinem Besten ist." - Quelle unbekannt.


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


  • Mach statt VIC-II doch den VDC vom 128er. Der hat keine Sprites :-)

    Und da gibt es auch so einen Haufen Software dafür am C64.

    Der c64 muss natürlich dann zum c128 werden :-D

  • Vielleicht Sprites nacheinander in einen separaten Zeilenbuffer mit Hilfe einer PIO dekodieren und den dann mit den restlichen Grafikdaten zusammenwerfen, evtl. auch wieder mit Hilfe einer PIO. Dann kommt man mit einer Sprite Unit (statt acht parallelen) aus, hat aber nicht mehr das exakte Timing des VIC-II (setzt man z.B. die Sprite-Farbe einen Takt vor dem Anzeigen des Sprites um, hat das beim Ansatz hier keinen Effekt mehr, auf dem echten VIC-II aber schon. Ich hoffe, dass das in der Praxis keine Rolle spielt). Ich teste mal etwas mit der nicht timingkritischen PC-Version des Emulators, nicht dass ich nachher viel Arbeit in einen Ansatz stecke, der mit den typischen Sachen gar nicht funktioniert.


    Testfall siehe unten (ohne Sprites bisher), wer erkennt's?

  • Die neue Sprite-Logik tut grundsätzlich, sogar schon in rp2040js (und damit vermutlich auch auf echter Hardware, hab's noch nicht ausprobiert), allerdings im Moment noch weit von den rund 400 maximal erlaubten ARM-Taktzyklen pro 6510-Takt entfernt. Der rote Pixelschnee im Bild ist unsauberes Timing beim Transfer zum PicoDVI-RP2040, das wird noch behoben.


    Sprites werden z.Zt. jeweils in den p-Accesses des VIC-II geholt und in einen internen Zeilenbuffer gezeichnet. Wenigstens bei Armalyte scheint das so zu funktionieren. Horizontale Hyperscreens oder Programme mit wackeligeren Multiplexern werden das allerdings vermutlich nicht mögen (ich muss Katakis ausprobieren...). Der Buffer wird am Ende jeder Zeile per RP2040-DMA gelöscht.


    Der ganze Code lässt sich dank einer Flut von IFDEFs schon seit Anbeginn auch als PC-Executable übersetzen. Damit ließ sich die neue Sprite-Logik recht fix bauen und debuggen. Bisher wurde das Bild des VIC einfach alle paar Sekunden in ein GIF geschrieben, aber jetzt habe ich noch SDL angebaut und Joystick-Input implementiert, damit kann man Armalyte jetzt in der PC-Emu-Variante sogar ziemlich gut spielen. ;)

  • Sprites! Das war richtig viel Gebastel; von der ursprünglichen VIC-II-Implementierung musste ich einen Großteil komplett umschreiben, damit Bus+State Machine vom Timing her auf den einen Core und das ganze Rendering auf den zweiten Core passt, und lange den von GCC generierten Assembler anstarren. Nur um zu illustrieren, wie knapp das alles von der Rechenleistung ist: An einer Stelle hat das Wegverlagern eines einzelnen var++ den Unterschied zwischen "crashed/stalled" und "läuft" gemacht.


    Die Sprites werden jetzt im nicht sichtbaren Teil des Bildschirmrands/beim Strahlenrücklauf gerendert.


    Sprite-Kollisionen fehlen noch, außerdem sind die Taktzyklen, in denen die CPU auf den VIC-II zugreift, etwas verlängert (Schnelllader funktionieren trotzdem, weil die ja kein LDA $DD00 STA $D000 machen oder sowas).


    Das sieht jetzt eigentlich alles schon ganz brauchbar aus, auch Armalyte sieht prima aus.


    Ich habe mir noch Babylon Four als VSP/Linecrunch-Beispiel ausgesucht, das sieht bis auf einen kleinen Fehler im Border-Scroller gut aus.


    Mayhem in Monsterland läuft, die Grafik ist aber zappelig/flimmerig. Da sind noch ein paar TODOs im CPU/VIC-Timing, insbesondere was Badlines angeht.

  • Hab mich doch schon an den "SID" gemacht, es war frustrierend, die ganzen alten Sachen ohne Musik zu sehen.

    Und nach nur einem relativ kurzen Abend läuft's! Es mussten nur die Busroutinen von SKpico angepasst werden. Open Source FTW! Dank an Frenetic für das Projekt, supercool!


    Auch wieder alles mit rp2040js entwickelt, lief auf Hardware auf Anhieb (erstmal mit PWM-Audio-Ausgang; Audio über HDMI kommt später irgendwann).

    Noch ein Pico-Platinchen mehr im Bunde. :)


    Das Gesamtprojekt heißt jetzt übrigens Connomore64 auf GitHub.