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

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

  • Schade, dass diese Diskussion nicht die Aufmerksamkeit findet, die sie verdient.

    Ein Drop-In-Ersatz für den 6510 hätte den Vorteil, dass man die ungenutzten Opcodes verwenden um neue Befehle einzubauen. Zudem könnte man den Ersatz gleich mit 16 MB internem Speicher ausstatten. Was damit plötzlich alles möglich wird - und das mit 100%iger Kompatibilität ohne eine einzige Schnittstelle zu belegen.

    Ich könnte mir vorstellen, dass so etwas auf großes Interesse stößt. Entsprechende Software wird dann schnell entstehen. Also ich nehme schomal mindestens 2. :smile:

  • 16MB interner Speicher will adressiert werden. Sehr sportlich mit 8Bit-Registern. Es würde auf Segmentierung a la 8088 rauslaufen und die macht einfach keinen Spass.

  • Entsprechende Software gibt's ja auch für's TC64, SCPU & REU zuhauf [/ironie]

    Solang die 6510er nicht massenhaft sterben, seh ich nicht wie sich jemand die Mühe macht das Rad neu zu erfinden.

  • ich warte auf den mega65. hab denen auch 5€ fürs projekt gespendet :thumbsup:

  • 16MB interner Speicher will adressiert werden. Sehr sportlich mit 8Bit-Registern. Es würde auf Segmentierung a la 8088 rauslaufen und die macht einfach keinen Spass.


    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.

  • ich warte auf den mega65. hab denen auch 5€ fürs projekt gespendet :thumbsup:

    Der Erfolg hängt von der Kompatiblität zum C64 ab. Ist die nicht gegeben, ist das Softwareangebot 0 und das Interesse ziemlich schnell auf gleichem Level. :smile: Für mich ist der Mega65 nicht wirklich interessant. Und auf den Preis bin ich sehr gespannt. Sind da schonmal Zahlen gefallen?

  • Ein Drop-In-Ersatz für den 6510 hätte den Vorteil, dass man die ungenutzten Opcodes...

    Auch wenn einige Opcodes illegal sind werden viele davon dennoch genutzt. Die Anzahl an Instruktionen die einen JAM verursacht ist sehr gering, von daher wäre es kaum möglich einen sinnvollen erweiterten Befehlssatz zu basteln. Zudem ginge das deutlich zu Lasten der Kompatibilität, zumindest wenn man alle illegalen OpCodes ersetzen würde.
    Ich könnte mir zwar vorstellen einen einzelnen der JAM-Codes als Index für: Folgendes gefetchtes Byte ist Befehl aus erweitertem Satz zu nehmen und damit einen erweiterten Satz reinzubasteln, aber es stellt sich mir weiter die Frage nach der Sinnhaftigkeit. Alle Software die das nutzen soll müsste von Grund auf neu- oder umgeschrieben werden, und da erwarte ich nur eine marginale Response.
    Andererseits: Go for it, entwickle genaue Specs und dann kann man ja weitersehen ob sich wer beteiligen will...

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • 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.


    Technisch zwar möglich, würde aber kaum Sinn machen. Wenn du alle (legalen) Opcodes auf 24 Bit Adressierung umstellen willst, geht dir jegliche Kompatibilität vorhandener Software flöten. Es sei denn du ersetzt eine Hand voll illegale Opcodes durch 24 Bit fähige LDA/STA Befehle, da wäre man aber deutlich eingeschränkt was die lineare Nutzung des erweiterten RAM angeht. Paging so wie es der DTV mit seinen 2MB RAM macht, ist da die bessere Wahl.

  • Ich könnte mir vorstellen, dass so etwas auf großes Interesse stößt. Entsprechende Software wird dann schnell entstehen.

    Die Vergangenheit hat gezeigt, dass man getrost dagegen wetten kann.

    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..

  • Es sei denn du ersetzt eine Hand voll illegale Opcodes durch 24 Bit fähige LDA/STA Befehle, da wäre man aber deutlich eingeschränkt was die lineare Nutzung des erweiterten RAM angeht. Paging so wie es der DTV mit seinen 2MB RAM macht, ist da die bessere Wahl.

    So war es gedacht, wobei ich gar nicht die illegalen, sondern nur die ungenutzten verwenden würde. Und Paging kann man ja durch neue interne
    Register zusätzlich möglich machen.

  • Welche OpCodes sind deiner Meinung nach denn 'ungenutzt'?

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Die Vergangenheit hat gezeigt, dass man getrost dagegen wetten kann.

    Auf welche Hardware spielst du an? Die SuperCPU? :smile: Ich glaube da waren das Problem der Preis und die Verfügbarkeit. Heute wäre der blockierte Expansionsport ein zusätzlicher Nachteil. Mit einem Drop-In-Ersatz hätte man keines dieser Probleme.

  • Ich würde eher für einen (robusteren?) Drop-In-Ersatz des CIA 6526(A) plädieren... denn
    die sind anfälliger und inzwischen doch deutlich schwerer zu bekommen als 6510/8500!

    Auch dürfte die Machbarkeit (im Sinne von möglichst kompatibel) für einen 6526 höher liegen.

  • Ich finde die Unterscheidung in illegal und ungenutzt halt irreführend. Alle Opcodes die einen JAM verursachen sind sicher obsolet, klar. Aber sie sind halt ebenso illegal. Reine Definitionssache ;)
    Wie schon erwähnt: Machbar sicher, also setz dich dran. Dann sehen wir ja ob viel Software dafür entsteht.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • 0x02, 0x12, 0x22, 0x32, 0x42, 0x52, 0x62, 0x72, 0x92, 0xB2, 0xD2, 0xF2

    Soweit ich weiß benutzt auch das DTV ein paar davon.


    Es sollten eigentlich alle illegalen Opcodes bis auf 0x0b und 0x2b vom DTV unterstützt werden.

  • Auf welche Hardware spielst du an?

    Auf jede. Der 2-MHz-Modus des 128ers, die REU, die GeoRAM, Flash-8, SuperCPU, DTV, TC64-Turbomodus - nichts davon wird auf breiter Basis unterstützt. Daher scheinen mir die Aussagen "großes Interesse" und "Software wird dann schnell entstehen" bestenfalls naives Wunschdenken. Ich meine, schön wärs schon, aber wahrscheinlich? Nee.


    Es sollten eigentlich alle illegalen Opcodes bis auf 0x0b und 0x2b vom DTV unterstützt werden.

    Woher hast Du diese Info? An harten Fakten bin ich sehr interessiert, um den DTV2-Modus von ACME entsprechend anpassen zu können. 0x0b und 0x2b sind dort nach peiselullis Hinweis bereits entfernt worden.

    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..

  • Woher hast Du diese Info? An harten Fakten bin ich sehr interessiert, um den DTV2-Modus von ACME entsprechend anpassen zu können. 0x0b und 0x2b sind dort nach peiselullis Hinweis bereits entfernt worden.


    Ich bezog mich da auf peiselulli's Aussage welche illegalen Opcodes _nicht_ auf dem DTV funktionieren, harte Fakten gibt's erst wenn ich dazu komme jeden einzelnen der 256 Opcodes auf meinem DTV3 durchzutesten :)

  • Ich könnte mir vorstellen, dass so etwas auf großes Interesse stößt. Entsprechende Software wird dann schnell entstehen. Also ich nehme schomal mindestens 2. :smile:


    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?

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    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.