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

letzter Beitrag von GMP am

FPGASID Featurediskussion

    Von Diskette flashen würde ich nicht explizit empfehlen und unterstützen, wegen den erwähnten möglichen Problemen durch Lesefehler etc. Wenn, dann nach zwischenpuffern auf REU oder GEORAM/NEORAM bzw. deren Emulationen. Vielleicht wären auch fertige Flashimages für die beliebten Flashmodule Easyflash und Tapecart möglich.

    Das Betriebssystem des 1541U2 unterstützt D71/D81, die emulierten 1541 Laufwerken nicht.


    Dies ist nützlich, wenn mann ein D71-Image herunterladet auf USB-schlussel und auf eine echte Diskette schreiben möchten; via die Ultimate Command Interface ist zugriff möglich auf das Image. Mit das richtigen Programm kann dies nach eine 1571 geschrieben werden. Sehe:


    https://devdef.blogspot.nl/201…-guide-6-d71-and-d81.html

    Respekt daß du dir wieder soviel arbeit gemacht hast andi. Klasse! Hätte nicht erwartet daß es zumindest so machbar ist wie du es umgesetzt hast. Solange die usb-blaster flash möglichkeit weiterhin gegeben ist finde ich das, so wie du es jetzt umsetzen konntest, alles verkraftbar. Aber, wenn der platz im fpga vielleicht zukünftig für andere dinge sinnvoller wäre, wäre es wohl besser den platz frei zu lassen.


    Wie erwähnt, vielleicht kann man das auch als easyflash image und reu emulation der ultimate umsetzen.


    Der punkt was shops angeht betüglich rückversand leuchtet auch ein, am besten entsprechend erläutern und usb-blaster gleich mit anbieten. Kostet ja fast nix das teil :)

    Zitat von dmantione

    Das Betriebssystem des 1541U2 unterstützt D71/D81, die emulierten 1541 Laufwerken nicht.

    Man kann eine Datei aus einem D71-/D81-Image in's RAM des C64 laden, mehr nicht. Das ist aber nicht das, was man in diesem Fall bräuchte.


    Yes, actually you can load single files from a D71/D81 image into the C64's RAM. But this is not what's needed here.

    Vom USB-Blaster will ich aus folg. Gründen eher weg kommen:
    1. Die Software hierfür verschlingt viel zu viel Festplattenplatz (für diese Pupsfunktion!) und braucht ewig zur Installation. Ausserdem braucht man dazu einen Windows oder auch Linux PC - die Mac-User bleiben außen vor.
    2. Langfristig könnte man dann den JTAG-Anschluss nicht mehr so fett auf der Platine anbringen, sondern nur noch einen kleinen Steckverbinder bzw. nur Lötpads vorsehen für den JTAG. (Keine Angst: Grundsätzlich wird es IMMER einen Weg geben, den FPGASID per USB-Blaster zu programmieren. Schon weil die Erstbetankung des nackten FPGA gar nicht anders geht.)
    3. USB-Blaster kosten zwar wenig, aber nur, wenn man sie in China ordert. Was geliefert wird ist dann vermutlich kein offiziell von Intel/Altera lizensiertes Produkt. Wie lange das noch so weiter geht (seit Intel Altera gekauft hat) ist die Frage.


    --- --- ---


    Dass die Module mit D81 und D71 Images nicht so gut klar kommen schockiert mich jetzt ein bisschen. Aber die Idee zwei D64 auf zwei emulierte Laufwerke zu verteilen ist ja auch ein gangbarer Weg.
    Die REU+sonstige RAM Erweiterungen zu verwenden ist prinzipiell ein guter Gedanke, aber das ist dann wieder sehr spezifisch, denn nicht jeder hat ein solches Modul. Im Prinzip wird man nicht darum herumkommen, dass es mit einer nackten 1541 auch funktionieren muss. Vermutlich sollte das Flashprogramm bei D64 images also vor dem Flashen erst mal alle Disketten anfordern und die Dateien darauf checken. Erst wenn alles vorliegt, dürfen die kritischen Schritte durchgeführt werden.


    Zitat von katarakt

    Aber, wenn der platz im fpga vielleicht zukünftig für andere dinge sinnvoller wäre, wäre es wohl besser den platz frei zu lassen.

    Wenn im Flash noch Platz ist bedeutet das nicht, dass auch im FPGA noch Platz ist. Das Flash muss ja den worst-case Fall bei besonders ungünstig geschriebenen Code auch abdecken und ist daher eher großzügig dimensioniert.
    Ich habe inzwischen gecheckt, dass die freien Bereiche am Ende der Konfigurationsdaten durchaus für andere Zwecke genutzt werden können: Die Lademechanik des FPGA berechnet zwar eine CRC-Checksumme über den Flashinhalt und wenn ich dann leere Bereiche plötzlich mit etwas fülle, das dort nicht erwartet wird, dann könnte es ja sein, dass dieser Check das merkt und das Laden verweigert. Aber in der Realität wird der CRC-check nur für die tatsächlich geladenen Daten ausgeführt und nicht über die leeren Bereiche am Ende des Speichers. Dort habe ich also jetzt ein bisschen Platz um beispielsweise Konfigurationsdaten zu speichern.

    Zitat von -trb-

    Man kann eine Datei aus einem D71-/D81-Image in's RAM des C64 laden, mehr nicht.

    Doch, eigentlich schon:
    1. Das Flashprogramm laden.
    2. RUN tippen
    3. Das Flashprogramm lädt dann (mit den ganz normalen Laderoutinen) weitere Dateien (10 Stück a 32kBytes) jeweils ins RAM und von dort in den FPGASID.
    Mehr wird nicht benötigt.

    Zitat von andi6510

    3. USB-Blaster kosten zwar wenig, aber nur, wenn man sie in China ordert. Was geliefert wird ist dann vermutlich kein offiziell von Intel/Altera lizensiertes Produkt. Wie lange das noch so weiter geht (seit Intel Altera gekauft hat) ist die Frage.


    Ich habe hatte* inzw. 2 USB-Blaster Clones hier, die nicht mit der neuesten Version der Software funktionierten.


    Schlimmer noch: Wenige Sekunden nach anstecken lösten diese einen BSOD/Kerneldump aus... und ungesicherte Dateien waren natürlich weg.



    * Sowas entsorge ich zur Sicherheit sofort!

    Zitat von andi6510

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


    (Habe mir gerade mal so ein "Update-ZIP-Archiv" angeschaut)


    Doch, die passt noch auf eine Diskettenseite (behaupte ich einfach mal so...)!


    Die 300kByte sind im entpackten Zustand, gezippt sind das im ZIP-Archiv ungefähr 145kByte. Wenn man jetzt das Update-Programm separat ausliefert und das FPGA-Updatefile gepackt trackweise ab Track 1 aufwärts auf eine Diskette speichert (zur Not bis Track 40), könnte das klappen.


    Es wäre dann "nur" etwas Programmieraufwand nötig: Disk-Routinen zum Liefern des ersten/nächsten Sektors sowie eine Entpack-Routine im C64...


    Nur meine kleine Idee dazu...


    Gruß,
    Thomas

    Zitat von andi6510

    1. Die Software hierfür verschlingt viel zu viel Festplattenplatz (für diese Pupsfunktion!) und braucht ewig zur Installation. Ausserdem braucht man dazu einen Windows oder auch Linux PC - die Mac-User bleiben außen vor.

    Ich habe es nicht probiert, sondern nur leicht überflogen: Mittels "OpenOCD" sollte auf allen Plattformen ein Flashen ohne Installieren von riesengroßen Programmpaketen möglich sein. "OpenOCD" ist eine schlanke Kommandozeilenanwendung, die mit vielen JTAG-Adaptern zurecht kommt und mit den richtigen Parametern bestimmt auch den FPGASID beschicken könnte.


    Ich habe mich damit aber nicht ausführlich beschäftigt und sehe jetzt auch keine Notwendigkeit mehr...


    Gruß,
    Thomas

    Zitat von Freak

    Die 300kByte sind im entpackten Zustand, gezippt sind das im ZIP-Archiv ungefähr 145kByte. Wenn man jetzt das Update-Programm separat ausliefert und das FPGA-Updatefile gepackt trackweise ab Track 1 aufwärts auf eine Diskette speichert (zur Not bis Track 40), könnte das klappen.

    Ja klar, in den Images ist viel Luft mit eingepackt. Komprimieren wird sicher einiges bringen. Das FPGA kann sogar selbststaendig ein gepacktes Image beim Hochlaufen entpacken. Damit waere dann das image auch mindestens 30% kleiner als im Moment und im Flash waere noch viel mehr Speicher frei... . Nebeneffekt waere dann allerdings, das das Hochlaufen laenger dauert (momentan unter einer Millisekunde, dann bis zu 10 Millisekunden).


    Allerdings: Wenn man jetzt anfaengt ein Image auf eine Diskettenseite zu quetschen und die Diskette womoeglich noch ueberformatiert, so dass der Normalanwender mit nackter 1541 schon Probleme bekommt, die ueberhaupt aus einem D64 image zu erzeugen, dann kann es ja trotzdem noch sein, dass die uebernaechte Firmware doch nicht mehr drauf passt und alles war vergebliche Liebesmuehe.


    Ich denke D64 images sind der groesstmoegliche gemeinsame Teiler. Und mit UII oder Chamaeleon lassen sich locker 2 D64 images entweder schnell umschalten oder auf verschiedenen Laufwerken mounten. Nur der Anwender mit der echten 1541 hat dann das Problem, dass er zwischendrin die Diskette wenden muss. So what.



    Zitat von Freak

    Ich habe es nicht probiert, sondern nur leicht überflogen: Mittels "OpenOCD" sollte auf allen Plattformen ein Flashen ohne Installieren von riesengroßen Programmpaketen möglich sein. "OpenOCD" ist eine schlanke Kommandozeilenanwendung, die mit vielen JTAG-Adaptern zurecht kommt und mit den richtigen Parametern bestimmt auch den FPGASID beschicken könnte.

    Spannendes Tool. Kannte ich noch nicht. Ist leider nicht trivial handzuhaben so dass man schnell mal was probieren koennte. Aber die listen einige Altera FPGAs auf, die damit schon geflasht wurden. Auch ein MAX10 Typ ist mit dabei.


    Meine Voruntersuchungen zielten ja auch in Richtung JTAG Update. Altera bietet C-Code fuer einen JTAG Bytestream Player an, den ich dann auf den C64 portiert haette. Alle JTAG-basierten Loesungen haben aber den gemeinsamen Nachteil, dass noch zusaetzliche Programmierhardware noetig ist. Auch fuer die C64 JTAG-Loesung ware ein Kabel z.B. vom Userport zum FPGASID zu stecken (bzw intern zu verdrahten).



    Aber der Leidensdruck, die bisherige JTAG-Loesung zu optimieren ist ja jetzt zum Glueck nicht mehr so hoch.

    OK, neue Featureidee die es zu diskutieren gibt:


    viele hätten ja gerne, dass sich das Grundsetting permanent abspeichern lässt. Jetzt habe ich das Flash geknackt und prinzipiell steht diesem feature nichts mehr im Wege.


    Folgende Idee hätte ich:
    1. Man konfiguriert sich den FPGASID auf seine Wunschkonfiguration A
    2. Man speichert diese Konfiguration per Spezialfunktion im Flash. Fortan wird immer Konfiguration A beim Einschalten aktiviert.
    3. Man konfiguriert sich den FPGASID auf seine Wunschkonfiguration B
    4. Man speichert auch diese Konfiguration im Flash. Fortan wird immer Konfiguration B beim Einschalten aktiviert.


    und jetzt das Killerfeature (falls ich es hinbekomme):
    5. Mit einem der Debugpads am FPGASID kann man nun noch zwischen den letzten beiden Konfigurationen hin und her schalten. Das bedeutet, man kann einen Schalter an so ein Debugpad anschließen und nachträglich auf die vorletzte Konfiguration (A) auswählen.
    6. Wenn man nun noch eine dritte Konfiguration C abspeichert, kann man mit dem Schalter zwischen Konfiguration B und C umschalten, Konfiguration A ist damit weg (überschrieben).


    Es gibt da noch ein paar Unwägbarkeiten, die das ganze (vor allem das Killerfeature) noch ein bisschen fraglich erscheinen lassen. Aber trotzdem möchte ich gerne mal Eure Meinung hierzu hören.

    Zitat von andi6510

    Jetzt habe ich das Flash geknackt

    Immer diese Jugendsprache... Das heißt was genau? :)



    Klingt sehr gut. Alternativ könnte man ja auch die Konfiguration in der Bank speichern, die (durch den DebugPin-Schalter) gerade angewählt ist.


    Wobei die Debug-Pins ja SEHR klein sind und dieses Feature nicht für große Lötkolben geeignet ist. Auch sollte der offene Debug-Eingang (mit dem Schalterkabel dran) relativ niederohmig gegen VCC gezogen werden, damit das Schalterkabel nicht als Antenne fungieren kann und dann sporadisch die Konfig umschaltet...


    Gruß,
    Thomas

    "Flash geknackt" = Ich habe aus der Userlogik heraus nun Lese- und Schreibzugriff auf das vollständige Flash. Also auch auf den Bereich, der eigentlich nur für den Bitstream gedacht ist. Zusätzlich habe ich eine Verbindung zum Registerblock hergestellt, die ebenfalls nötig ist um die Konfiguration beim Hochlaufen zu setzen.


    Die Speicherlogik wie oben beschrieben kommt daher, dass ich plane die Konfigurationen in einer Liste ins Flash zu schreiben wobei immer nur die zuletzt hinzugefuegte (und ggf die vorletzte) aktiv ist. Die ganze Liste wird erst dann gelöscht, wenn sie voll ist und es geht von vorne los. Damit umgehe ich das Problem, dass sich jemand das Flash kaputt schreiben kann, weil er standardmässig fünfmal am Tag nach jeder Konfigurationsänderungen das Zeug ins Flash schreibt und das dann immer in der gleichen Speicherzelle landet.


    Und ja, der Anschluss ans Debugpad ist der Schwachpunkt. Kommt hinzu, dass dort 3V Logik vorliegt und man sich mit 5V den FPGASID killt (oder mindestens den debug pin). Daher bin ich mir noch nicht sicher, ob ich das supporten will... @c0zmo hatte vorgeschlagen einen der JTAG pins dafür zu verwenden, was evtl technisch möglich sein könnte. Das 3V Problem bleibt da aber.

    Zitat von andi6510

    OK, neue Featureidee die es zu diskutieren gibt:


    viele hätten ja gerne, dass sich das Grundsetting permanent abspeichern lässt. Jetzt habe ich das Flash geknackt und prinzipiell steht diesem feature nichts mehr im Wege.


    Es gibt da noch ein paar Unwägbarkeiten, die das ganze (vor allem das Killerfeature) noch ein bisschen fraglich erscheinen lassen. Aber trotzdem möchte ich gerne mal Eure Meinung hierzu hören.

    Sensationell !! :verehr::dance