Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 74 Antworten

letzter Beitrag von stynx am

FPGASID Register Map

    Zitat von Freak

    Aufteilen des Resets in zwei Prioritäten:


    Einschaltreset: Setzt alle SID-Register auf $00 und initialisiert die drei letzten Register (Reg 29 bis Reg 31) mit sinnvollen Werten.


    Reset auf der Resetleitung: Setzt alle SID-Register auf $00 und lässt Reg 29 bis Reg 31 unangetastet.

    Das scheitert ganz grundsätzlich daran, dass die Reset-Leitung ebenfalls die Rekonfiguration des FPGAs triggert. Daher ist es unmöglich irgendwelche Registerwerte über den Reset zu retten (ohne Hardwareänderung). Wenn man die FPGA-Konfiguration vom Reset entkoppeln will, muss man auf der Platine ein eigenes Reset-Signal erzeugen, welches unabhängig vom C64-Reset wäre. Das ist im Moment nicht vorgesehen.


    Ich habe schon angedacht, was zu tun wäre, um Registerwerte ins Flash abzuspeichern. Die MAX10 FPGAs besitzen 32kB User-Flash, welches ich direkt verwenden kann. Das Problem ist, dass ich es schon komplett verwende, nämlich als wavetables für die mixed waveforms. Da müsste ich mir also erst mal überlegen, wie ich die mixed waveforms algorithmisch abbilden kann und das ganze dann noch mit möglichst wenig Logik. Wenn ich die Tabellen so wie sie sind als Logik generieren lasse, dann sprengen sie die zur Verfügung stehenden Ressourcen.

    Zitat von andi6510

    Das scheitert ganz grundsätzlich daran, dass die Reset-Leitung ebenfalls die Rekonfiguration des FPGAs triggert. Daher ist es unmöglich irgendwelche Registerwerte über den Reset zu retten (ohne Hardwareänderung).

    :cry:


    Zitat von Freak

    Wie verträgt sich das mit Erweiterungen am Expansionsport (speziell die 1541U2)? Die bedient doch auch die Resetleitung, oder? (<-- werde ich mal am Wochenende checken...)


    Hatte keine Geduld bis zu Wochenende zu warten und habe vorhin mal ein Scope an den Pin 3 vom Userport gehängt (<-- Resetleitung) und eine 1541 Ultimate II (ohne Pluszeichen) eingestöpselt.


    Testszenario war einfach das Laden von verschiedenen Disk-Demos (wie z.B. Deux Ex Machina).


    Das Ergebnis ist recht eindeutig: Jedes Mal nach Auswahl des Disk-Image mittels "Run Disk" wird durch die Ultimate ein Resetsignal von ca. 16 ms erzeugt, dann kommt auf dem Monitor das bekannte LOAD "*",8,1 und der C64 lädt das erste File auf der gemounteten Disk. :(


    Vielleicht kann das jemand nochmal verifizieren...


    Hmmm, jetzt bräuchten wir 24 nichtflüchtige Bits irgendwoher. :search:


    Gruß,
    Thomas

    oh, das ist ja unangenehm... :Klo:


    ich benutze ein SD2IEC und kenne solche Probleme nicht.
    Gibt es eine Möglichkeit der Ultimate das abzugewöhnen?


    Wie sieht es dann wohl mit den diversen anderen Cartidges aus? Chameleon etc...


    Wie ich schon sagte, ohne Hardwareänderung sehe ich im Moment keinen schnellen Fix.
    Evtl noch was mit Fädeldraht (CPLD erzeugt den extra Reset) oder so...


    Trotzdem: So eine halb-Reset / ganz-Reset Lösung, wie von Dir vorgeschlagen schmeckt mir aber irgendwie auch nicht. Reset ist Reset. Daher lieber das interne Flash benutzen finde ich...


    Naja, der Alphatest läuft noch gar nicht richtig und wirft schon jede Menge Ergebnisse ab. :strom:


    Da muss ich jetzt mal grübeln...

    Vielleicht hilft Dir diese Erkenntnis: http://ploguechipsounds.blogsp…id-waveform-captures.html
    Er ist zum Schluß gekommen, daß die kombinierten Wellenformen keineswegs stabil sind.
    Wenn es nur ein paar Bytes sind, die Du noch benötigst, würde es demnach überhaupt nicht auffallen, wenn man da einfach ein paar ausgewählte Stellen in den Wellenformtabellen für missbraucht.
    Für die generelle Konfiguration wären das Register 29-31, und das pro SID, also 6 Bytes. Dazu würden wohl noch die Parameter für das Filterprofil kommen. Das ist hoffentlich nicht all zu groß.

    Danke fuer den Link @LogicDeLuxe.


    Es ist eher so, dass sich das Flash nur in Bloecken aufteilen laesst. Wenn ich Glueck habe, dann sind das genau 4KBytes pro block und ich kann die Wavetable von genau einer Kombination dort rausloesen und durch Logik ersetzen. Den frei werdenden 4K-Block koennte man dann als NVM fuer die Registerwerte nehmen.


    Da das Flash natuerlich empfindlich gegen zu viele Schreibzugriffe ist, muesste man im rollierenden Verfahren immer die 4K komplett voll schreiben um dann den Block am Stueck zu loeschen und wieder von vorne anzufangen. Sowas macht man jetzt nicht in ner halben Stunde.


    Was @Freak vorgeschlagen hatte mit den zwei Reset-Sorten geht mir auch noch durch den Kopf. Ich muss schauen, ob sich da eine Moeglichkeit im CPLD findet.


    Gibt es bei der Ultimate und dem Chameleon eigentlich keinen anderen Weg Diskimages zu mounten? Kann man nicht zunaechst ein Programm fuer die Settings starten und dann das neue Image mounten und von Hand Load"*",8,1 eintippen? Ich frage wirklich so doof, weil ich bislang ohne sowas ganz gut ausgekommen bin. Mir reicht die Kombination aus SD2IEC und JiffyDos. Damit gehen zugegebenermassen allerdings die wenigsten Disk-Image basierten Demos.

    Zitat von andi6510


    Da das Flash natuerlich empfindlich gegen zu viele Schreibzugriffe ist, muesste man im rollierenden Verfahren immer die 4K komplett voll schreiben um dann den Block am Stueck zu loeschen und wieder von vorne anzufangen. Sowas macht man jetzt nicht in ner halben Stunde.


    Das Flash ist mit 10000 Zyklen spezifiziert... Wenn man das flashen nicht mit jeder Konfigurationsänderung, sondern nur "on demand"
    machen würden, bräuchte man wohl kein wear-leveling.

    ich finde 10000 Zyklen jetzt nicht sooo viel. Wenn mann einen 4k Block per wear leveling beschreibt (mit 32 bit pro Schreibvorgang, denn so ist das Flash organisiert), dann werden aus den 10000 Zyklen gleich mal 10000000. Das sollte dann reichen, finde ich.


    Man bedenke, es gibt immer Heinis, die sagen sich "mal schauen, ob ich das Ding kaputt bekomme", schaffen es dann auch und schwupps haste nen Garantiefall... :abgelehnt
    Das muss schon robust sein, sonst kommt mir das nicht ins Produkt ;)

    Zitat von andi6510

    ich finde 10000 Zyklen jetzt nicht sooo viel. Wenn mann einen 4k Block per wear leveling beschreibt (mit 32 bit pro Schreibvorgang, denn so ist das Flash organisiert), dann werden aus den 10000 Zyklen gleich mal 10000000. Das sollte dann reichen, finde ich.


    Man bedenke, es gibt immer Heinis, die sagen sich "mal schauen, ob ich das Ding kaputt bekomme", schaffen es dann auch und schwupps haste nen Garantiefall... :abgelehnt
    Das muss schon robust sein, sonst kommt mir das nicht ins Produkt ;)


    Ich neige für meine ganz eigenen Projekte auch eher zur (möglichst) perfekten Lösung... insofern finde ich diese Einstellung gut.


    Aber um es RICHTIG robust zu machen, bräöuchtest dann auch 2 Pages, die unabhängig voneinander löschbar sind,
    damit zu jedem Zeitpunkt eine gültige Config existiert.
    Ich persönlich halte es in diesem Projekt für Over-Engineering! Aber bitte nicht davon abhalten lassen! :D


    Abgesehen davon: 10.000.000 Schreibzyklen bekommt ein "Heini" auch hin - wenn er es drauf anlegt.

    Zitat von andi6510

    Es ist eher so, dass sich das Flash nur in Bloecken aufteilen laesst. Wenn ich Glueck habe, dann sind das genau 4KBytes pro block und ich kann die Wavetable von genau einer Kombination dort rausloesen und durch Logik ersetzen. Den frei werdenden 4K-Block koennte man dann als NVM fuer die Registerwerte nehmen.

    Hast Du schon die Symmetrie der Wellenformen berücksichtigt? Einige bräuchte man ja nur zur Hälfte abzuspeichern, und per Ping-Pong- oder Vorwärts-Loop zu lesen.


    Wirken sich eigentlich die Pulsverhältnisregister auf kombinierte Wellenformen mit Rechteck aus? Falls ja, wäre so eine Tabelle wohl nicht ausreichend. Dazu ist mir jetzt aber keine Untersuchung bekannt.


    Und ließe sich die Logik kombinierter Wellenformen nicht aus den Die-Shots ablesen?
    Arbeiten die aktuellen Emulatoren auch noch mit Tabellen, oder gibt es da bereits Logikumsetzungen?


    Zitat von andi6510

    Da das Flash natuerlich empfindlich gegen zu viele Schreibzugriffe ist, muesste man im rollierenden Verfahren immer die 4K komplett voll schreiben um dann den Block am Stueck zu loeschen und wieder von vorne anzufangen. Sowas macht man jetzt nicht in ner halben Stunde.

    Wegen der Abnutzung, sollte man evtl. eine spezielle Bitkombination verwenden, die das Schreiben der aktuellen Konfiguration veranlasst. Z.B. ein Magicword in den Registern 27 und 28.
    Das würde man dann wohl auch nicht dauernd machen. Die meiste Zeit würde man ohnehin sein ausgewähltes Lieblingsprofil nutzen. Es wären doch eher die Ausnahmen, wo man mal ein anderes Profil läd.

    Zitat von LogicDeLuxe

    Wirken sich eigentlich die Pulsverhältnisregister auf kombinierte Wellenformen mit Rechteck aus? Falls ja, wäre so eine Tabelle wohl nicht ausreichend. Dazu ist mir jetzt aber keine Untersuchung bekannt.


    Nein.. Wirkt sich nicht aus.


    Zitat von LogicDeLuxe

    Und ließe sich die Logik kombinierter Wellenformen nicht aus den Die-Shots ablesen?


    Doch... lässt sich aus dem Die erkennen: Da steckt eine definierte Logik dahinter gepaart mit analogen Seiteneffekten.
    Daher ist es auch nicht bei jedem SID gleich - wie plogue schon bemerkte.


    Um es vereinfacht zu erklären: Kombinierte Waveforms führen zu Kurzschlüssen zw. manchen Zählerbits des NCOs.
    Und da die Leitungen größtenteils einen gewissen Eigenwiderstand haben (zum Teil Polysilizium, zum Teil Metall)
    "gewinnt" mal das eine oder andere Bit, wenn da ein Low- und High-Pegel gegeneinander arbeiten.
    Das ganze hängt dann auch noch von Fertigungstoleranzen ab.

    Zitat von androSID

    Abgesehen davon: 10.000.000 Schreibzyklen bekommt ein "Heini" auch hin - wenn er es drauf anlegt.

    OK, wenn man also das Abspeichern einer Config getriggert hat, wird das naechste Speichern einer Config fuer 30 Sekunden gesperrt.
    Das duerfte dann ueberschlagsmaessig fuer 10 Jahre staendiges Abspeichern reichen (alle 30 Sekunden). Bekommts der Heini jetzt auch hin? :baeh:


    Schlimm, dass man sich um sowas ueberhaupt ernsthaft Gedanken machen muss...

    Zitat von andi6510

    Gibt es bei der Ultimate und dem Chameleon eigentlich keinen anderen Weg Diskimages zu mounten? Kann man nicht zunaechst ein Programm fuer die Settings starten und dann das neue Image mounten und von Hand Load"*",8,1 eintippen? Ich frage wirklich so doof, weil ich bislang ohne sowas ganz gut ausgekommen bin. Mir reicht die Kombination aus SD2IEC und JiffyDos. Damit gehen zugegebenermassen allerdings die wenigsten Disk-Image basierten Demos.


    Es gibt zwei Wege bei der 1541U2:


    Einmal den oben von mir beschriebenen "Run Disk"-Modus, wo die Disk gemountet wird, ein Reset erfolgt und dann ein LOAD "*",8,1 das erste File von der Disk lädt und danach startet. Alles automatisch.


    Dann gibt es auch ein einfaches "Mount Disk", welches nichts anderes macht als die Disk zu mounten. Das ist sinnvoll z.B. bei Demos über mehrere Disketten. Wäre ja blöd, wenn die mittendrin ein Reset erfahren würden.


    Ich habe gerade nochmal ein Scope drangehängt und die zweite Variante durchgespielt. Wenn man nur die Disk mounted und dann alles von Hand macht, also manuell LOAD und RUN eingibt, dann funkt kein Reset dazwischen.


    Das wäre doch zumindest für den Alpha-Test ein gangbarer Weg.


    A little bit offtopic:
    Idee: Für die nächste Version wäre vielleicht ein 93LC56A im SOT23-Gehäuse eine Möglichkeit, den müsste man dann allerdings über eine entsprechende State-Machine im FPGA auslesen und beschreiben. Billig, langlebig und viel Platz (auch für mehrere (umschaltbare) Konfigurationen)...


    Gruß,
    Thomas

    OK, ein bisschen bin ich beruhigt was die U2 angeht. Vermute mit dem Chamäleon ist es ähnlich.


    Der von @Freak vorgeschlagene Baustein könnte helfen, die 3 Konfigurationsregister permanent zu machen. Aber ehrlich gesagt würde ich es dann doch erst mal mit dem internen Flash probieren.


    Aber das reicht bei Weitem nicht für die SID-Profile:
    Was diese, so wird dort deutlich mehr Speicher benötigt. Ein kompletter Satz lookup-Tabellen belegt in meiner Implementierung etwas mehr als 80kB pro SID-Profil. Das geht momentan genau in den Konfigurationsspeicher und wird beim Hochlaufen des FPGAs einfach als feste Vorbelegung in die Blockrams geladen. Wenn man das ändern will, muss man also jedes mal 80kB an Daten rüber schaufeln. Entweder zur Laufzeit ins RAM, oder per JTAG ins Flash. Ich überlege ernsthaft das Ganze ausschliesslich per JTAG zu ermöglichen. Zumindest im ersten Schritt.


    Aber das Umschalten der SID-Profile liegt eher noch in der ferneren Zukunft. Erst mal die Basics klar machen :)



    Was anderes:
    Gestern habe ich noch ein bisschen mit dem bitrot gespielt und meine vorhanden SIDs durchgecheckt, wie lange jeweils ein geschriebener Wert wieder auslesbar ist. für die beiden 8580 die ich besitze liegen die Zeiten relativ nahe beieinander. Was die 6581 aber angeht, so sind dort die Streuungen enorm, selbst von Messung zu Messung auf dem gleichen Chip ist es auch schon mal ein Faktor 10 unterschiedlich. Ich werde jetzt einfach mal "typische" Werte einprogrammieren. Glaube aber ehrlicherweise nicht, dass man im echten Leben damit die SID-Typen zuverlässig auseinander halten kann.


    Die etablierte Methode den 6581 vom 8580 zu unterscheiden liegt ja im Auslesen des OSC3 Registers. Der 8580 hat hier eine um einen Clockzyklus höhere Latenz. Dies ist momentan noch nicht korrekt implementiert. Ist ein bisschen fummelig, weil genau an dieser Stelle eine clock rate Transistion dazwischen kommt. Da brauche ich mal ein bisschen Ruhe und einen freien Kopf um das sauber zu machen.

    Zitat von andi6510

    Das geht momentan genau in den Konfigurationsspeicher und wird beim Hochlaufen des FPGAs einfach als feste Vorbelegung in die Blockrams geladen.

    Kann der von dir verwendete FPGA-Typ keine Blockram-Vorbelegung aus dem Bitstream lesen? Ich hielt das bisher für ein Standardfeature, zB um Block-RAMs ohne Zusatzlogik auch als ROM verwenden zu können.

    Zitat von Unseen

    Kann der von dir verwendete FPGA-Typ keine Blockram-Vorbelegung aus dem Bitstream lesen? Ich hielt das bisher für ein Standardfeature, zB um Block-RAMs ohne Zusatzlogik auch als ROM verwenden zu können.


    Äh, genau diesen Vorgang habe ich doch beschrieben: Ersetze Konfigurationsspeicher durch Bitstream und Du bist da :)
    Es gibt keine Zusatzlogik. Erst, wenn ich das zur Laufzeit vom C64 aus überschreiben will, wird es jede Menge Zusatzlogik geben ;)

    Zitat von andi6510

    Was die 6581 aber angeht, so sind dort die Streuungen enorm, selbst von Messung zu Messung auf dem gleichen Chip ist es auch schon mal ein Faktor 10 unterschiedlich. Ich

    Das ist da doch auch noch temperaturabhängig. Musst Du noch einen Temperatursensor integrieren ;)

    Zitat von LogicDeLuxe

    Gibt es überhaupt ein Programm (ausgenommen für Forschungszwecke), welches die Schreibregister liest? Ich glaube nicht, daß man sich mit solchen Nebeneffekten lange rumschlagen sollte.

    andi6510 zeigt alle symptome eines perfektionisten. ich fuerchte das laesst sich nicht so leicht abstellen! ;-):doc:

    nee nee, das mit dem Register auslesen habe ich eingesehen - da werde ich meine Aktivitaeten zurueckfahren. Evtl klaue ich sogar der entsprechenden Konfigration noch ein bit. Dann waere es: Register immer lesbar/Register nur kurze Zeit lesbar. Eine Umschaltung zw. 6581 und 8580 halte ich mittlerweile nicht mehr fuer sinnvoll.


    Interessanter finde ich die Problematik die Register irgendwie persistent zu machen. Da gbit es einige Optionen die ich mir genauer anschauen will.


    Aber in wenigen Tagen kommen ohnehin die Platinen vom Bestuecker und dann verschiebt sich der Fokus vom FPGA wieder auf die Hardware.