Hallo Besucher, der Thread wurde 12k mal aufgerufen und enthält 104 Antworten

letzter Beitrag von spider-j am

Neues zum Chamäleon?

  • das bild ist prinzipbedingt *viel* besser als es mit sündhaft teuren svideo->vga konvertern je sein könnte. zuschaltbare PAL emulation wird es auch geben.


    ??? Und das ist dann zu allen Games kompatibel? Auch zu solchen mit schönen Raster-/IRQ-Spielereien? Das wäre in der Tat bemerkenswert!

  • Und warum wird dann nicht gleich irgenson Minimigirgenwas Teil mit samt Userport gemacht? Würden wir uns imho den Brotkasten sparen.


    Vielleicht ist Laptop mit Vice billiger.

  • Hand aufs Hemd - ist da im Hinterkopf der Entwickler eventuell der C65 gewesen?? Mir drängt sich da ganz stark die Vermutung auf, dass das Chamäleon in der Tat ein neuer C64 werden soll....und bedingt durch das Modulkonzept bleibt ja 100%ige Kompatibilität erhalten. Ja oder ja? :D

  • 100% agree! :zustimm:


    Gibts eigentlich Bilder von dem Dingen? Oder auch Screenshots wie ein Cevibild auf 'nem VGA-Moni aussieht? Als Unwissender (!!) stelle ich mir das fürchterlich vor.... :roll:

    Schau doch mal in die aktuelle Lotek64 Ausgabe 28 auf Seite 7. Ist zwar wohl noch ein Prototyp, aber so in etwa wird sie wohl aussehen. :freude

  • Zitat

    How can the VGA display the C64 screen?


    Inside the Chameleon is a replica of the VIC-II chip. All register updates and memory accesses are send to both the original VIC-II chip and the replica.


    Kann mir mal bitte jemand erklären, wie das funktioniert? Lassen sich die die VIC-Register etwa standardmäßig am Expansionport abgreifen? Wenn nicht, wie stellt man sicher, dass keine Software dazwischen funkt?


    CU
    Kratznagel

  • Kann mir mal bitte jemand erklären, wie das funktioniert? Lassen sich die die VIC-Register etwa standardmäßig am Expansionport abgreifen? Wenn nicht, wie stellt man sicher, dass keine Software dazwischen funkt?


    Am Expansionsport ist der komplette Daten+Adressbus der C64-CPU sichtbar, alles was ein Programm macht kann man dort mitlesen.


    Bis auf diese lästige kleine Ausnahme der Adressen 0 und 1, bei Schreibzugriffen darauf lässt sich der 6510 nicht in die Karten schauen - das ist der Grund wieso reine Expansionsport-Kernalkarten ohne Draht in den Computer das Ram unter dem Rom bei $e000-$ffff unzugänglich machen. In der ersten grösseren Chamäleon-Diskussion hat Jens dann irgendwann zugegeben, dass das Modul seine Prozessoremulation nicht nur für die Turbofunktion nutzt sondern ständig aktiv hält, dadurch kennt es auch den Inhalt von $0000/$0001 und weiss, ob Schreibzugriffe bei $dxxx in den I/O-Bereich (und damit zB auf die VIC-Register) oder ins Ram darunter gehen.

  • ... sondern ständig aktiv hält ...


    Dh. man könnte die interne 6510 CPU im Grunde "ausbauen"?



    Eines ist mir auch nicht klar, wie schaltet er die interne CPU aus? Oder läuft die einfach mit? Aber wenn sie mit läuft, wie kann dann der "Turbo" funktionieren?

  • Dh. man könnte die interne 6510 CPU im Grunde "ausbauen"?


    Die wird wahrscheinlich noch kurz zur Initialisierung verwendet, aber das ist blinde Spekulation von mir.


    Zitat

    Eines ist mir auch nicht klar, wie schaltet er die interne CPU aus?


    Genauso wie der VIC oder eine REU es macht, mit /DMA.


    Zitat

    Oder läuft die einfach mit? Aber wenn sie mit läuft, wie kann dann der "Turbo" funktionieren?


    Wenn der Turbo aktiv ist wird die interne CPU definitiv abgeschaltet sein. Ohne Turbo könnte man im Prinzip beide parallel laufenlassen und die externe nur zur Berechnung des $00/01-Inhalts verwenden, aber da könnte man ein paar Situationen konstruieren in denen das nicht 100%ig funktioniert - besonders dann wenn der Benutzer eine Datasette verwenden will, die vom Chamäleon wohl eigentlich nicht unterstützt werden soll (wieder ein $01-Problem, aber Eingabe). Ständig alles auf der externen CPU ablaufen zu lassen ist auf jeden Fall die einfachere Lösung.

  • In der ersten grösseren Chamäleon-Diskussion hat Jens dann irgendwann zugegeben, dass das Modul seine Prozessoremulation nicht nur für die Turbofunktion nutzt sondern ständig aktiv hält, dadurch kennt es auch den Inhalt von $0000/$0001 und weiss, ob Schreibzugriffe bei $dxxx in den I/O-Bereich (und damit zB auf die VIC-Register) oder ins Ram darunter gehen.

    Ah, Danke für die Erklärung. Diese Lösung ist ja wirklich gediegen. :D


    CU
    Kratznagel

  • Ohne Turbo könnte man im Prinzip beide parallel laufenlassen und die externe nur zur Berechnung des $00/01-Inhalts verwenden,


    So einen Modus haben wir auch, damit haben wir die externe CPU debugged. Erst als alle illegalen Opcodes Zyklus für Zyklus identisch mit dem 6510 waren, haben wir überhaupt begonnen, über Turbo nachzudenken.


    aber da könnte man ein paar Situationen konstruieren in denen das nicht 100%ig funktioniert - besonders dann wenn der Benutzer eine Datasette verwenden will, die vom Chamäleon wohl eigentlich nicht unterstützt werden soll


    Stell' die echte Datasette mal nicht als den großen Nachteil hin, schließlich haben wir so jetzt die Möglichkeit, anstelle der Datasette eine *.tap File Emu zu schreiben. Ich rede hier ausdrücklich von einer *Möglichkeit*, das ist noch lange nicht drin. Auch fehlt noch das Devkit zu einem anderen Chip, den ich mit auf die Karte packen will. Weiter fehlt noch die endgültige Entscheidung für einen RTC-Chip (steht für "real-time clock"), denn ich möchte beim Erstellen von Dateien auf MMC-Karte auch das richtige Datum auf die Karte schreiben lassen. Es ist wirklich noch *viel* an dem Cartridge zu tun.


    Was aber drin sein wird, ist extrem schneller Speicher. Heute kam die Bestätigung für 200MHz-Typen, die anstelle des bisher genutzten 166MHz-Typs drin sein werden. Mit der nun höheren Speicherbandbreite werden wir entweder höhere Bildwiederholraten, oder eine schnellere Turbofunktion machen können. Die Lieferzeit dieser Speicherchips ist mit 8-10 Wochen angegeben worden, wovon ich natürlich nicht gerade begeistert bin. Meine Anfrage für die Teile ist nämlich von Mitte Januar, eigentlich hätte der Speicher längst da sein sollen... Samsung halt.


    Jens

  • Stell' die echte Datasette mal nicht als den großen Nachteil hin, schließlich haben wir so jetzt die Möglichkeit, anstelle der Datasette eine *.tap File Emu zu schreiben.


    Ich sehe da keinen Nachteil. =) Die Formulierung sollte eher in die Richtung gehen dass das irgendjemand trotz anderslautender Doku doch ausprobieren wird. Externe Beeinflussung des Inhalts von $01 ist die einzige Situation die mir momentan einfällt, in der man den Zustand des C64-6510 "unbeobachtet" (aus Bus-Sicht) verändern kann und das geht via Datasette nun mal am einfachsten.


    Zitat

    Auch fehlt noch das Devkit zu einem anderen Chip, den ich mit auf die Karte packen will.


    Ein I2S-DAC? ;-)


    Zitat

    Weiter fehlt noch die endgültige Entscheidung für einen RTC-Chip (steht für "real-time clock")


    Erwartest du an dieser Stelle einen Vorschlag? ;-)


    sd2iec kann mit dem PCF8583 umgehen (I2C, DIP8/SO8, 2.5-6V Bus, 1.0-6V Uhrenbetrieb), allerdings hat der leider keinen dedizierten Batteriepin und nur zwei Bit für das Jahr. Letzteres kann man aber mit den 240 Byte Ram gut kompensieren sofern die Software wenigstens einmal alle 3-4 Jahre (je nach Implementation) die Chance bekommt den Überlauf zu erkennen.


    Zitat

    Heute kam die Bestätigung für 200MHz-Typen, die anstelle des bisher genutzten 166MHz-Typs drin sein werden.


    Und ich als Privatbastler mache mir schon Sorgen wenn ich für eine noch weit in der Zukunft liegende Bastelidee 8MB Ram mit 16-Bit-Interface bei gerade mal ~8MHz brauche... (16*512K SRAM verbrauchen zu viel Platz)

  • eine perfekte SID-Emulation, einen SID-Nachbau gibt es mit dem SwineSID,


    perfekte sid emulation? wo was wie?


    der swinsid ist gut, aber bei weitem nicht perfekt! das wird wohl mit eprom auch nie komplett was werden soweit ich das weiß (da fehlen wellenformen oder son blödsinn, hab da keine ahung von :D )


    und nen nachgebauten C64 gibts doch mehr oder weniger... den C-One