Machbarkeitsfrage: Drop-In-Ersatz für 6510 auf FPGA-Basis?

Es gibt 95 Antworten in diesem Thema, welches 17.163 mal aufgerufen wurde. Der letzte Beitrag (20. September 2015 um 14:29) ist von Jotta.

  • Kann man dem "ich nehme schonmal mindestens 2" entnehmen, dass du zwar die Idee in den Raum stellst, aber die Arbeit auf andere Leute abwälzen willst?

    Es war mir nicht bewusst, dass ich mit einer Idee bereits anderen die Arbeit auflade. :smile: Aber Spaß beiseite - ich bin zwar Softwareentwickler, aber hardwaretechnisch absoluter Laie. Ich würde mich an einem solchen Projekt sofort beteiligen - sei es Software dafür anzupassen oder zu testen. Aber um so etwas von Grund auf hochzuziehen fehlt mir zuviel Know-How.

    Ich habe die nächsten Wochen ein bisschen Zeit und werde dem VICE mal ein 6510-Drop-In-Replacement mit 16 MB Speicher und zusätzlichen Opcodes verpassen.

  • Was spricht gegen ein LDA $1A2B3C? Neue Opcodes werden 2 Bytes schlucken und in diesem Fall noch 3 für die Adressierung. 5-6 Taktzyklen sind da weg, aber in der Adressierung sehe ich kein Problem.


    Im Prinzip geht das, siehe Z80 (gegenüber 8080), 6809 (gegenüber 6800) und 65816 (gegenüber 6502). Dummerweise frißt der Overhead sämtlichen theoretischen Leistungsvorsprung auf, umd am Ende ist die Kiste womöglich sogar langsamer als der ursprüngliche 8-bitter. Lösung wäre z.B. ein 16-bit-breiter Datenbus mit kleinem Cache, aber dann kannst du an das Thema 'Kompatibilität' direkt einen Haken machen.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Es reicht nicht, einfach sta, stx, sty, lda, ldx, ldy auch noch in einer Variante mit einem 24-bit immediate bereitzustellen, es gibt ja auch noch andere nützliche Adressarten. Auch soll der Prozessor ja auch Code jenseits der 64k ausführen können, also muss auch der program counter erweitert werden. Das hat aber auch Einfluss auf jsr, rts und rti. Ein erweitertes jmp will man wohl auch. Auch wäre es seltsam, die Vektoren für Interrupt und Reset dort zu lassen, wo sie beim 6502/6510 sind.

    Kurzum: Einfach aufgebohrt geht da nichts, was nicht eine Krücke ist. Ordentlich aufgebohrt und man landet bei etwas, was ähnlich zum 65816 ist.

  • Kann man sowas nicht "einfach" umschaltbar machen, dass der Prozessor wahlweise im 6510-Modus arbeitet, in dem er nur auf ein 64k-Segment adressieren kann, und einem echten 16-Bit-Modus mit höherem Takt usw. Im 8-Bit-Modus kann er dann die ganzen illegalen Opcodes und im 16-Bit-Modus kann er dann einen ganz anderen Befehlssatz haben. Das Hin und her schalten zwischen den beiden Modis müsste dann über ein Bit erfolgen, welches in dem 64k-Adressraum des 8-Bitters erreichbar ist. Oder wenn das nicht geht, weil im C64-Modus jedes Bit früher oder später von Legacy-Software beschrieben wird und damit der 8-Bit-Modus unbeabsichtigt verlassen würde, könnte man über normalerweise unübliche Speicherzugriffsmodis machen, dass wenn z.B. drei Mal innerhalb von n Taktzyklen eine bestimmte Speicheradressse drei Mal gelesen wird, dass dann in 16 Bit zurück geschaltet wird. Oder der 16-Bit-Kern läuft parallel und kann den 8-Bit-Kern anhalten. Wenn man dann beim Wechsel zwischen 8 und 16 Bit den Status der 8-Bit-Maschine (Register, PC, usw.) auf einen Stack oder eine Liste legen und von dort wieder restaurieren könnte, könnte man auch mehrere solche 64k-Segmente (plus Bankswitching ROM/RAM/IO) parallel halten und dazwischen umschalten...

    Mal hier, mal da, mal dort. Aber auf jeden Fall auf der Bitte melde dich an, um diesen Link zu sehen.! Und hier Bitte melde dich an, um diesen Link zu sehen.!

  • Kann man sowas nicht "einfach" umschaltbar machen

    Kann man. Tatsächlich macht es der 65816 genau so (der Befehl heißt dort XCE, "Exchange Carry and Emulation bit"), auch wenn der nicht die Illegals hat.
    Wenn man eh schon so weit gehen will, kann man natürlich auch einfach einen ARM nehmen, darauf einen 6510-Emu laufen lassen und mit dem 6510-Opcode 0x02 die Emulation abschalten. Oh, hat da jemand Jehova gesagt? :anonym

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Oder jemand entwickelt mal einen gescheiten 65816 Core :whistling:

  • Oder einfach TC64 nehmen. im realen Cevi ersetzt er eh schon die CPU und RAM und bei Nutzung des VGA-Ausganges sogar den VIC-II. Über kurz oder lang wird der Standalonemode so ziemlich 99,9999% kompatibel sein, er ist ja jetzt schon extrem gut. Dann haben wir einen komplette C64+Zubehör im FPGA, der dem originalen in nichts nachsteht. Das in ein orginales Gehäuse mit Tastatur einbauen und fertig ist der Cevi für die Ewigkeit und die MOS-ICs können mir dann gestohlen bleiben.

  • ... :(

    Oder einfach TC64 nehmen. im realen Cevi ersetzt er eh schon die CPU und RAM und bei Nutzung des VGA-Ausganges sogar den VIC-II. Über kurz oder lang wird der Standalonemode so ziemlich 99,9999% kompatibel sein, er ist ja jetzt schon extrem gut. Dann haben wir einen komplette C64+Zubehör im FPGA, der dem originalen in nichts nachsteht. Das in ein orginales Gehäuse mit Tastatur einbauen und fertig ist der Cevi für die Ewigkeit und die MOS-ICs können mir dann gestohlen bleiben.

  • Ja stimmt, wenn du da welche brauchst die du nicht mit dem TC64 nutzen kannst, dann ist das ein Problem.

  • Ah ja ok. Was kann man denn mit dem Epromm-Brenner machen was man nicht auch als Rom mit dem TC64 starten kann?

  • Bitte melde dich an, um dieses Medienelement zu sehen.

    Der alleinige Zweck dieses Beitrags ist es meinen Counter zu inkrementieren. Jeglicher Sachbezug dient ausschließlich der Dekoration.

    Bitte melde dich an, um diesen Link zu sehen.    Bitte melde dich an, um diesen Link zu sehen.    Bitte melde dich an, um diesen Link zu sehen.

  • Ok für was?

    @Bitte melde dich an, um diesen Link zu sehen.: :thumbsup:

  • Ja ok, an so was habe ich gar nicht gedacht.

  • Oder einfach TC64 nehmen. im realen Cevi ersetzt er eh schon die CPU und RAM und bei Nutzung des VGA-Ausganges sogar den VIC-II. Über kurz oder lang wird der Standalonemode so ziemlich 99,9999% kompatibel sein, er ist ja jetzt schon extrem gut. Dann haben wir einen komplette C64+Zubehör im FPGA, der dem originalen in nichts nachsteht. Das in ein orginales Gehäuse mit Tastatur einbauen und fertig ist der Cevi für die Ewigkeit und die MOS-ICs können mir dann gestohlen bleiben.

    Funktioniert ein C64 mit TC auch noch, wenn der 6510 im C64 komplett defekt ist oder sogar fehlt? Dass man mit einem TC defekte EPROMs kompensieren kann, kann ich mir ja noch gut vorstellen, aber kommt ohne funktionierende CPU der C64 überhaupt soweit, das TC zu starten?

  • Gute Frage, ich habe nur zwei Brotkästen(einen zum Arbeiten und einen Ersatz) und bei keinem ist die CPU gesockelt. Ich kann es also nicht so ohne weiteres ausprobieren.

  • Funktioniert ein C64 mit TC auch noch, wenn der 6510 im C64 komplett defekt ist oder sogar fehlt?


    Nein, denn der 6510 generiert den Phi2-Takt, an dem praktisch "alles" im C64 hängt: CIAs, SID, VIC und das Chameleon brauchen diesen Takt.

    Außerdem ist es IMMER eine ganz schlechte Idee, ein Chameleon in einen known-bad-Computer zu stecken.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Zitat

    Außerdem ist es IMMER eine ganz schlechte Idee, ein Chameleon in einen known-bad-Computer zu stecken.


    Natürlich, meine Frage war auch eher theoretischer Natur :)

    Danke für die Antwort!