Hallo Besucher, der Thread wurde 17k mal aufgerufen und enthält 88 Antworten

letzter Beitrag von GMP am

FPGASID Featurediskussion

    Hallo!


    Hab mal eine hoffentlich nicht zu dumme Frage. Auf dem Board sind 3 LEDs, die Aktivität der jeweiligen Stimme anzeigen. Wie ist denn die Logik? Wird ab einem bestimmten Amplitudenwert (50%?) die LED eingeschaltet?
    Warum blinken die LEDs schon wenn man den Cevi einschaltet und die SID ja noch gar nichts tun muß?
    @andi6510 : Für die "Serie" fände ich Lötaugen/Header ganz nett, dann könnte man sich die LEDs dahin legen, wo man will. Bei nicht transparenten Gehäuse hat man ja gar nichts von der Blinkerei.


    Gruß
    Stephan

    Die LEDs erfreuen sich wirklich unerwarteter Beliebtheit. Eigentlich wollte ich die zunächst gar nicht aktivieren, sondern nur zum Debuggen verwenden. Aber ich vermute die sind jetzt schon ein Feature geworden, dass ich nicht mehr weglassen kann ;-)


    Die Funktionalität der LEDs ist wie folgt:
    Wenn Volume von SID1 == 0:
    LEDs zeigen den Heartbeat der von den diversen Systemclocks abgeleitet wird.
    LED1: Frei laufende interne clock abgeleitet vom 16 MHZ Quarzgenerator
    LED2: 6502-Bus clock von ca 1MHz
    LED3: Enable Takt in der internen Clock domain aber synchronisiert auf die 1MHz 6502-Bus clock
    Daher blinken LED2 und LED3 synchron, LED1 blinkt asynchron zu den anderen LEDs


    Wenn Volume von SID1 > 0:
    LED1: gate bit von voice 1 von SID1 verodert mit gate bit von voice 1 von SID2
    LED2: gate bit von voice 2 von SID1 verodert mit gate bit von voice 2 von SID2
    LED3: gate bit von voice 3 von SID1 verodert mit gate bit von voice 3 von SID2


    Spezielle Header für die LEDs finde ich aus verschiedenen Gründen nicht so prickelnd:

    • Die LEDs werden ohne Buffer direkt aus dem FPGA getrieben. Wer da einen Kurzschluss baut, oder versehentlich mal +5V statt der 3,3V Versorgungsspannung des FPGAs anlegt, der kann ganz schnell das FPGA ins Nirvana befördern.
    • Der Strom pro LED ist recht gering nämlich knapp 2mA. Die LEDs sind absichtlich hoch effiziente Typen, die daher trotzdem noch gut sichtbar leuchten. Wenn man dann andere LEDs anschliesst, sind diese viel zu dunkel.
    • Ein Header würde die Platine ein gutes Stück größer machen. Ich willl aber dass sie noch kleiner wird.

    Wer die LEDs unbedingt versetzen will, kann theoretisch die vorhandenen LEDs auslöten und die Signale mit Fädeldraht abgreifen. Dann sollte aber noch ein LED-Treiber dazwischen geschaltet werden, damit man mehr Strom bekommt. Ich würde aber wegen des Risikos eines FPGA-Schadens davon abraten sowas zu tun.

    Zitat von andi6510

    Die LEDs erfreuen sich wirklich unerwarteter Beliebtheit.

    Bei der Menge an transparenten Gehäusen die im Umlauf sind, wundert mich das nicht. Die sind alle WOPR geschädigt. :D

    Zitat von andi6510

    verodert

    Ich hab lange gebraucht bis ich es kapiert habe. Lustiges Wort.
    Danke für die Erläuterungen.
    Ich finde, daß die LEDs ein nicht zwingend nötiges aber durchaus ein nettes Feature sind (und Alleinstellungsmerkmal. Das kann schließlich eine echte SID nicht). Die FPGA-Kill-Gefahr habe ich nicht bedacht. Die Platine größer und aufwändiger machen muß natürlich abgewogen werden (Im Falle von zusätzlich implementierten Headern, sollten natürlich auch Schutzschaltung für den FPGA gegen Kurzschluß respektive Treiber dazukommen.)

    Ich fände die externe Anschlussmöglichkeit der LED auch sehr gut, die sind nämlich durchaus nützlich. Ich fände es sogar noch besser wenn man den passenden SID Kanal zur LED getrennt auf einen physischen Audioausgang legen könnte. Wenn man professionell mit dem Teil Musik machen möchte und schließt den SID in einem Tonstudio an, dann ist die Kanaltrennung ein langjähriger Wunschtraum.


    So wäre es möglich jeden SID Kanal einzeln nochmal in einen Mischpultkanal einzuspielen und dort dann noch mit anderen Geräten nachzufiltern oder eben echte aufgetrennte Sequenzen zu erstellen. Für das Mastering ein enormer Vorteil.


    Für die Welle Erdball Produktionen wäre es ebenfalls ein enormer Vorteil wenn man die Signale einzeln rausführen könnte und am besten noch mit der passenden LED als Kanalmonitor ob etwas am jeweiligen Kanal anliegt. Andere Musiker dürften sich darüber wohl auch sehr freuen.


    Gruß
    Tom

    @Pentagon, deine Ideen sind für Musiker sicherlich sehr relevant. Allerdings würde dadurch die Hardware ziemlich aufgeblasen werden, was nicht mehr im Sinne der restlichen Anwender wäre. Ein Problem wäre auch, dass die Filter ja für alle drei Stimmen gleichzeitig vorhanden sind und man nach dem Filter die Stimmen nicht mehr getrennt vorliegen hat. Man müsste die Filter also separat pro Stimme vorhalten, also insgesamt sechsmal einbauen. Momentan ist die Rechenkapazität aber auf zwei Filter beschränkt. Also ein dickeres FPGA und das führt unweigerlich zu deutlich mehr $$$...


    Ich denke eine solche Entwicklung muss man dann eher separat von der jetzigen sehen. Ist eben ein ganz anderer Anwendungsfall.

    ich denke auch, wir sollten unsere Kräfte momentan darauf konzentrieren, die Funktion und Kompatibilität der Alpha Version in jedem erdenklichen Teil zu testen und zu verbessern.


    Neue Features können wir diskutieren, wenn die nächste Auflage der Hardware ansteht.

    Wie wäre es denn mit so einem Baustein wie


    Microchip 47L04


    als externer kleiner Speicher für die Config?


    Vorteil: Interner Flash wird nicht weiter belastet.
    Nachteil: Platz und Kosten!




    http://www.microchip.com/wwwproducts/en/47L04


    • Automatic Store to EEPROM upon power-down (using optional external capacitor)
    • Automatic Recall to SRAM Array upon power-up
    • Infinite Read and Write Cycles to SRAM Array
    • More than 1 Million Store Cycles to EEPROM
    • Reliable Data Storage during Power Loss

    Das waere dann meine Backup-Loesung. Die Kosten- und Platzeinsparung halte ich fuer wichtiger, so dass ich es erst mal mit dem internen Flash probieren will.

    Zusätzliche Features hören sich immer gut an, aber dann ist es eben kein echter C64 mehr und Software die sie nutzt läuft dann nur auf aufgerüsteten Geräten. Der Vorteil (und Fluch) des C64 war ja, daß alle Geräte gleich waren, also einmal geschriebene Software überall läuft.


    Auch sollte man sich über neue Features erst Gedanken machen wenn die neue Hardware wirklich 100% kompatibel zum Original ist, auch im Bezug auf undokumentiertes.

    Zitat von WalkThatWay

    Kann ich als Programmierer den Speicher auch anderweitig benutzen? Z.B. als schnellen zwischenspeicher für den VIC, wenn Sound nicht gebraucht wird? Oder ist nur zugriff für SID angedacht?

    Definitiv nein. Der Konfigurationsspeicher wird nur intern im FPGASID verwaltet und ist vom C64 aus nicht erreichbar. Es handelt sich ohnehin nur um 1-2 kBytes, die ich im internen Speicher frei machen kann. Und schnell wird es dann auch nicht. Wirklich Sinnvolles laesst sich damit also nicht anstellen.


    Ein externer Speicher waere sinnvoll, wenn man verschiedene SID-Profile, die von real existierenden Chips abgleitet wurden, abspeichern will. Das braucht viel Speicher. Aber soweit ist die Entwicklung noch nicht... bis dahin versuche ich den internen Speicher anzuzapfen.

    So, jetzt muss ich nach längerer Pause, die ich mehr oder weniger im Verborgenen gewurschtelt habe, auch mal wieder eine Featurefrage zur Diskussion stellen:


    Ein Ergebnis der Umfrage unter den Alphatestern war ja, dass es wünschenswert wäre, den FPGASID auch ohne USBBlaster zu flashen. Eine weitere Forderung war ja seit Anfang an, dass man die Konfiguration auch dauerhaft setzen können sollte und somit frisch nach dem Einschalten des Rechners seine Lieblingskonfiguration hat.


    Diese beiden Themen bedingen, dass ich das im FPGA eingebaute Flash auch zur Laufzeit beschreiben können muss und dass dort genug Platz für solche Dinge ist. Jetzt habe ich nach einem ziemlichen Kraftakt dieses Wochenende eine brauchbare Lösung entwickelt, die es erlaubt den FPGASID direkt vom C64 aus mit neuer Firmware zu füttern. Dabei habe ich im Flash einiges an ungenutzten Bereichen ausgemacht, die sich zumindest prinzipiell zum Speichern einer Konfiguration eignen würden. Letzteres gilt es aber noch zu überprüfen.


    Das Speichern der Konfiguration muss ich noch genauer untersuchen. Daher Erst mal nur zum Firmware Update.
    Die Methode hat einige Einschränkungen:

    • Es lässt sich nur das FPGA updaten. Das CPLD bleibt so wie es ist.
    • Der Update vom C64 aus dauert recht lange (10 Minuten oder so, habs noch nicht gestoppt).
    • Wenn während des Updates der Strom ausfällt, ist der FPGASID sofort dysfunktional und kann nur noch per USBBlaster wiederbelebt werden.
    • Die Firmware is ca 300kBytes gross und passt somit nicht mehr auf ein D64 image bzw auf eine 1541 Diskette.

    Meine Meinung hierzu:
    zu 1: Das CPLD ist seit längerem stabil. Vermultich wird es so bleiben können, wie es jetzt ist.
    zu 2: Macht man ja nicht täglich. Wäre also zu tolerieren
    zu 3: Das könnte ein Problem werden, wenn ich den FPGASID über einen Webshop verkaufe und nach dem ersten Firmware Update 20% der Teile zerflasht zurück geschickt werden.
    zu 4: Mein Ansatz wäre ein D81 oder D71 image zu erzeugen. Mein SD2IEC verdaut diese images jedenfalls und sie bieten genug Speicherplatz. Allerdings frage ich mich, was eine Ultimate II+ oder ein Chamaeleon damit macht. Ein Diskettenwechsel mitten im Flashen ist wegen Punkt 3 eher kritisch zu sehen.


    Und jetzt schreibt bitte eure Meinung dazu! :-)

    Bin zwar keiner der Tester, aber potentieller künftiger Besitzer. Da kann ich ja jetzt schon mal was dazu schreiben. :D


    Zitat von andi6510

    Jetzt habe ich nach einem ziemlichen Kraftakt dieses Wochenende eine brauchbare Lösung entwickelt, die es erlaubt den FPGASID direkt vom C64 aus mit neuer Firmware zu füttern.

    :thumbsup:



    Zitat von andi6510

    Update vom C64 aus dauert recht lange (10 Minuten oder so, habs noch nicht gestoppt).

    Das ist m.E. im Rahmen. Schließlich spart man sich ja so das Aufschrauben des C64 (sofern man da kein Kabel oder einen Anschluss für den USBBlaster am C64 hängen haben will).



    Zitat von andi6510

    Wenn während des Updates der Strom ausfällt, ist der FPGASID sofort dysfunktional und kann nur noch per USBBlaster wiederbelebt werden.

    Das ist verschmerzbar.



    Zitat von andi6510

    Das könnte ein Problem werden, wenn ich den FPGASID über einen Webshop verkaufe und nach dem ersten Firmware Update 20% der Teile zerflasht zurück geschickt werden.

    Wenn darauf deutlich hingewiesen wird, sollte das ausreichen. Am besten gleich einen Link zu einer Einkaufsquelle für den USBBlaster in die Beschreibung setzen. :)



    Zitat von andi6510

    Die Firmware is ca 300kBytes gross und passt somit nicht mehr auf ein D64 image bzw auf eine 1541 Diskette.

    Zitat von andi6510

    Mein Ansatz wäre ein D81 oder D71 image zu erzeugen. Mein SD2IEC verdaut diese images jedenfalls und sie bieten genug Speicherplatz. Allerdings frage ich mich, was eine Ultimate II+ oder ein Chamaeleon damit macht.

    SD2IEC, arm2iec u.ä. sind doch recht weit verbreitet. Manch einer hat auch 'ne 1571 oder gar 1581. Ist doch okay, wenn die 1541 da rausfällt. Ultimate und Chameleon bieten beide keinen wirklichen Zugriff auf ein D71 oder D81, wie man ihn hier bräuchte. Bei der Ultimate könnte man aber evtl. den Direktzugriff auf das Dateisystem der Karte/des Sticks nutzen. Nur weiß ich gerade nicht, wie da momentan der Stand ist.

    Zitat von andi6510

    Allerdings frage ich mich, was eine Ultimate II+ oder ein Chamaeleon damit macht. Ein Diskettenwechsel mitten im Flashen ist wegen Punkt 3 eher kritisch zu sehen.

    Diese Module können weder d71 noch d81. Dafür können sie aber zwei Laufwerke emulieren. Ein unterbrechungsfreies Laden von zwei d64-Dateien ist also grundsätzlich möglich. Alternativ verfügen auch beide Module über eine REU-Emualtion, die es ermöglicht, die ganzen 300 kB im Voraus zu laden.
    Wegen der kritischen Ausfallgefahr, sollte man ohnehin vom Flashprogramm die Datenintegrität prüfen, um die Gefahr von Leseproblemen zu minimieren. Eine REU wäre dabei eine gute Unterstützung, weil man den Integritätstest dann durchführen kann, nachdem der Ladevorgang abgeschlossen ist.


    Zitat von andi6510

    Die Firmware is ca 300kBytes gross und passt somit nicht mehr auf ein D64 image bzw auf eine 1541 Diskette.

    Passt schon auf eine 1541-Diskette. Die hat schließlich zwei Seiten. ;)

    Die Frage ist doch, wie oft später geflasht werden muss. Wenn der FPGASID bei den meisten gut funktioniert, erübrigt sich ein Update. So ein USBBlaster kostet auch nicht die Welt. Den muß ja nicht jeder haben. Einer im Bekanntenkreis reicht aus.