Es gibt 43 Antworten in diesem Thema, welches 5.279 mal aufgerufen wurde. Der letzte Beitrag (5. April 2024 um 08:58) ist von vossi.

  • Den 6510 bekommt man auch mit ziemlicher Sicherheit mit günstigen RP2040 (entweder mit etwas zusätzlicher Logik oder zwei gekoppelten RP2040 für die GPIOs) nachgebaut (für dann <10€). Ich seh da keinen Grund für Hamsterei oder FPGAs (mehr); ist nur eine Frage der Zeit, bis das mal jemand macht. In Bitte melde dich an, um diesen Link zu sehen. ist das (mit anderem Businterface allerdings) mehr oder weniger drin.

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

  • Den 6510 bekommt man auch mit ziemlicher Sicherheit mit günstigen RP2040 (entweder mit etwas zusätzlicher Logik oder zwei gekoppelten RP2040 für die GPIOs) nachgebaut (für dann <10€). Ich seh da keinen Grund für Hamsterei oder FPGAs (mehr); ist nur eine Frage der Zeit, bis das mal jemand macht. In Bitte melde dich an, um diesen Link zu sehen. ist das (mit anderem Businterface allerdings) mehr oder weniger drin.

    Aus meiner Sicht gibt's zwei "extreme" Randpositionen:

    • Nur Original-Bausteine verwenden (Purist)
    • Alle Bausteine emulieren

    und dann unendlich viele Zwischenstufen dazwischen mit unterschiedlichen Graden des Nachbaus*.

    Zum eigentlichen: Es ist ja schön, wenn Du da keinen Grund für siehst bzw. Dir ein RP2040 reicht.

    Mir persönlich würde es nicht gefallen und so eine Lösung käme mir auch nicht ins Haus (in den Rechner)!

    (Genausowenig wie ich auf die Idee käme mir per DSP einen Röhrenverstärker zu simulieren...)

    Von daher finde ich die Option von vossi (8500) oder toms01 (8501) eine

    zunehmend schlecht verfügbare CPU (oder andere Chips) durch anflanschen der fehlenden Schaltungsteile zu ersetzen,

    eine nette Kompromisslösung, die trotz allem noch recht nah am Original Design ist/bleibt.

    *PS: Die Option alles mit diskreten Bauteilen nachzubauen oder die emulierende CPU (Rotzberry) dann mit einer noch stärkeren

    CPU (Intel Core oder AMD Rotzen) zu emulieren, lass' ich mal außen vor, da beides bisher nicht praxistauglich realisiert wurde.

    Ganz extrem könnte man ja auch irgendwann die SPICE Netzliste des Gesamtsystems auf einem ausreichend schnellen System simulieren.

  • Jup so aus retrotechnischen Erwägungen klar.

    Ich kam aber argumentatorisch aus anderer Richtung, weil in Posting Bitte melde dich an, um diesen Link zu sehen. gerade von FPGA-Lösungen die Rede war und an anderer Stelle hier im Forum auch gerade die J-CPU Thema ist. Da ist dann sowieso nix mehr mit Retro, stattdessen überlegen die Leute offensichtlich, relativ viel Geld für Dinge auszugeben, die es über kurz oder lang mit vergleichbaren Eckdaten auch in günstig geben wird, nur weil eine diffuse (unbegründete) Angst besteht, dass es irgendwann gar keinen Ersatz mehr geben wird.

    (mit dem Nu6510 hat das zugegebenermaßen wenig zu tun ;) )

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

  • Ich habe nun die Tests noch mal in zwei anderen alten PAL-C64 im Originalzustand mit dem Original-6510 und meinem V6510 geprüft.

    Im V6510 hatte ich eine alte Rockwell und eine alte mos CPU.

    Fehler treten ausschließlich bei den instabilen Opcodes ANE und LXA auf.

    Bei einigen Trap-Tests ebenfalls nur mit ANE oder LXA.

    Bei einem 6510 hat sich wieder der CPU-Port nicht wie von Lorenz gewünscht verhalten.

    Bei meinem V6510 ist der CPU-Test natürlich immer fehlerhaft, da bit6+7 kein kapazitives Verhalten haben.

    Die Trap Tests 16+17 prüfen ja Befehle über die 64k-Grenze. Das läuft scheinbar auch auf dem V6510 nicht wie auf einem 6510. Vermutlich da sich bei $0000 der Port befindet und der 6502 den Port selbst ja nicht sieht.

    Kann der 6510 seinen eigenen Port bei $0000/1 als "Befehlteil" lesen?

    Die beiden Opcodes ANE und LXA sind "highly unstable": "The outcome of these competing, noisy conditions depends on the production series of the chip, and maybe even on environmental conditions."

    Das kapazitive Verhalten von bit6+7 des Ports spielt in der Praxis ebenfalls keine Rolle.

    Die 64k-Page Boundary ist ebenfalls in der Praxis nicht relevant.

    Diese "Fehler" hat sicher auch der Monotech-Adapter.

    Nur mit einer FPGA oder einem Emulator kann man das Verhalten genau so realisieren, wie der Lorenz Test das erwartet.

    PS: Warum steht nach den Trap-Tests mit Fehlern eigentlich trotzdem ein - OK ?

    Christian

    C64 Nr. 6xxx:

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

    C64 Nr. 69xxx:

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

    Bitte melde dich an, um diesen Anhang zu sehen.