Hello, Guest the thread was viewed14k times and contains 77 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.

    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.

  • Also ich frage dann jetzt mal hier (anstatt im MEGA65-Ketzer-Thread):


    Was ich mit Audio-Latenz meinte, ist, dass man z.B. auf einem Betriebssystem mit Audio-Treiber usw immer einen Sound-Buffer hat, den man fuellen muss, bevor ein Ton ausgegeben wird (z.B. 20 ms). Je groesser dieser Buffer, desto groesser die Latenz (z.B. wenn man bei Giana springt, dann kommt der Sprungsound etwas spaeter). Bei einem Software-Emulator auf dem PC kann man das also schon wahrnehmen (ob es fuer einen persoenlich ins Gewicht faellt, ist eine andere Frage).


    Mich wuerde interessieren, ob hier die Buffer super-klein sind oder ob es hier den Buffer in der Form generell nicht gibt, weil Audio z.B. irgendwie direkt an den DAC geschickt wird.


    Disclaimer: Ich hab uebrigens von Hardware/Mikrocontroller und auch FPGA nicht wirklich viel Ahnung. Daher waren auch meine FPGA-Aussagen im anderen Thread vielleicht etwas arg laienhaft. Dennoch muesste das, was ich gesagt habe, nach meinem Verstaendnis zumindest fuer einen ueblichen Software-Emulator gelten. Natuerlich werden Latenzen und Ungenauigkeiten immer kleiner, je weniger Betriebssystem im Hintergrund werkelt und je kleiner die Buffer sind. Beim "Connomore" ist das ganze natuerlich auf die Spitze getrieben, aber das ist fuer mich auch kein "normaler" Software-Emulator. Interessant waere z.B. auch der Vergleich zwischen Connomore und sowas wie BMC64 (was zumindest bare-metal auf einem Raspi laeuft).

  • Was ich mit Audio-Latenz meinte, ist, dass man z.B. auf einem Betriebssystem mit Audio-Treiber usw immer einen Sound-Buffer hat, den man fuellen muss, bevor ein Ton ausgegeben wird (z.B. 20 ms). Je groesser dieser Buffer, desto groesser die Latenz (z.B. wenn man bei Giana springt, dann kommt der Sprungsound etwas spaeter). Bei einem Software-Emulator auf dem PC kann man das also schon wahrnehmen (ob es fuer einen persoenlich ins Gewicht faellt, ist eine andere Frage).

    Mich wuerde interessieren, ob hier die Buffer super-klein sind oder ob es hier den Buffer in der Form generell nicht gibt, weil Audio z.B. irgendwie direkt an den DAC geschickt wird.

    Buffer wie die Audiobuffer sorgen ja nur dafür, dass die Ausgabe auch bei schlechten Randbedingungen (unterdimensionierte Hardware, nicht echtzeitfähiges Betriebssystem, unkooperative Treiber) noch störungsfrei funktioniert.

    Bei entsprechender Konfiguration des Betriebssystems und entsprechender Qualität der Treiber kann man mit winzigen Buffern arbeiten. Bei z.B. VICE lassen sich die Buffergrößen für Audio per -soundbufsize einstellen, und z.B. bei Linux kann man die Buffer für das allgemeine Audio-System auch einstellen (bis runter zu 64 Samples meine ich, also 1,4ms bei 44,1kHz). Da kann man einfach so weit runtergehen, wie es keine Knackser gibt, wenn einen das Thema bewegt.


    Was Audio beim Connomore angeht, verweise ich auf SIDKick pico, dort gibt es einen Main Loop, der mit dem Bustakt läuft (also eine Million Mal pro Sekunde durchläuft), und wenn reSID ein neues Sample produziert hat, wird das eben direkt der PWM-Hardware übergeben: https://github.com/frntc/SIDKi…1e8/Source/SKpico.c#L1061 (mit DAC wird wohl ein 256-Sample-Buffer benutzt, siehe SAMPLES_PER_BUFFER).


    Was Video angeht, gibt es beim Connomore (potenziell) nur einen Zeilenbuffer in der libdvi (eine Zeile bei 50 Hz und 300 Zeilen = 1/15000stel Sekunde), in der Praxis wird aber zur Zeit ein Framebuffer benutzt, weil noch nicht alles exakt synchron läuft, aber das Ding ist ja auch nicht fertig. ;)


    Kurz, wenn man da Latenzen mitbekommt, kommen die woanders her.

  • Das C64-Symposium in Bonn war großer Spaß. Der Connomore64 lief direkt neben der Kaffeeecke; Sonntag habe ich im Emulator-Workshop auch noch kurz was dazu erzählt (Dank an Michael Engel für den Slot).

    Als in einem Talk Turrican vorkam und ich das mal auf dem Connomore gestartet habe, habe ich etwas geschwitzt (hatte es darauf noch gar nicht getestet), lief aber einwandfrei. :)

    Ein paar schöne Ideen für weitere Projekte kamen auch auf, dazu aber mehr, wenn's weiter vorangeschritten ist.


    Der Connomore hat inzwischen CIA2-Timer inkl. NMIs (das war auch wieder etwas Timing-Gebastel), und ich habe eine Idee, wie man noch die Time of Day-Timer implementieren kann, ohne dass das Zyklen-Budget ausgeht. Danach ist das alles glaube ich soweit Feature Complete. :)


    Im Moment bin ich am Layers-Demo dran, da zappeln irgendwie die beiden Charset-Layer noch (ab der dritten Bildschirmzeile...).

  • Eine grundlegende Time of Day-Timer-Implementierung gibt's jetzt, die sollte für sowas wie Up'n Down, Beach Head und Raid Over Moscow reichen.


    An die CIA-Implementierung muss ich nochmal ran, aber nach ein paar kleineren Fixes daran sieht auch die Layers-Demo schon ganz gut aus...

    Layers_Demo.gif

  • 1570
    Sieht ja schon mal cool aus, Deine "breadbox v0"... ;)
    Würde es mit Deinem Ansatz auch funktionieren, die einzelnen Funktionseinheiten (CIA, VIC, ..), die auf der RP2040/RP2350 laufen auch alleine - ähnlich dem SIDKick zu benutzen, also als Plugin-Alternative zu den Originalchips im C64? Oder funktionieren sie nur untereinander über den Bus aus Deinem Design?

  • Tengri Das Thema hatten wir in #26 schon (und #36).

    Original-Chip-Replacements für 6510 und CIA könnte man auf Basis des RP2040/2350 wohl hinbekommen, VIC-II ziemlich sicher nicht.

    Ist aber in diesem Thread nicht die Baustelle, das hier soll eher so eine Art Devblog zum Connomore64 bleiben. Dort sind die Funktionen zwar wie beim C64 grundsätzlich implementiert, aber häufig leicht anders umgesetzt (z.B. ist der Adressbus des VIC-II im Connomore 16-bittig, und der VIC macht keine eigenen Speicherzugriffe, sondern hat eigenes gespiegeltes RAM), teilweise aus Performance-Gründen, teilweise für übersichtlicheres Design.


    Beim Connomore gibt's auch einige Neuigkeiten, aber dazu demnächst mehr. :)

  • Bevor das nächste Posting hier noch länger dauert:


    Im Herbst habe ich eine Platine erstellt, die genug Platz für einen Haufen Picos bietet, die die ganzen wesentlichen Anschlüsse hat, die in ein C64-Gehäuse passt und mit der sich angenehmer entwickeln lässt als mit dem Pico-Türmchen; außerdem lassen sich die einzelnen Picos später durch Pico2 mit RP2350 ersetzen. Funktioniert!


    Neu ist auch der Userport, der ist mit einem WiC64 getestet.

    Expansionsport funktioniert noch nicht (und kann auch gar nicht 100%ig kompatibel werden mit der begrenzten Rechenleistung der RPs), aber vielleicht ist es möglich, wenigstens einige Modultypen daran lauffähig zu bekommen - das kommt aber deutlich später.


    Mit echten C1541 wurde inzwischen auch getestet, mittlerweile läuft sogar Transwarp und 13:37 (letzteres nur teilweise, gibt noch Probleme mit der VIC-Emulation) drauf.


    Im Moment bastele ich daran, den rp2040js-Emulator für die Picos für den RP2350 zu erweitern https://github.com/c1570/rp2040js/ , das ist inzwischen soweit gediehen, dass die "CPU" des Connomore darauf läuft (auf echter Hardware geht das inzwischen auch!).

    Auf Seite von rp2350js musste die ganze CPU-Emulation umgebaut werden (von ARM M0+ auf RISC-V; die Unterstützung des ARM M33 im RP2350 wäre noch deutlich aufwendiger gewesen und hat mich nicht so interessiert).

    Auf Seite des Connomore währenddessen waren fast gar keine Code-Änderungen beim Wechsel von RP2040 zu RP2350 (und von ARM auf RISC-V) nötig.


    Der RP2350 bietet etwa 150% der CPU-Leistung des RP2040, was an etlichen Stellen hier das Entwickeln deutlich entspannen sollte, mit dem RP2040 ist das doch alles sehr eng.


    Ende 2024 war ich mit dem Connomore beim 38C3 (kein Talk, aber "Live-Demo"). War toll! Schöne Grüße an alle, die dabeiwaren, hat großen Spaß gemacht. :)