Die Clock Pulsbreite sollte so etwa 50% betragen. Der FPGASID vermisst die Clockperiode und positioniert dann den Zeitpunkt, wann Daten übernommen werden etwa in die Mitte der High-Phase der Clock. Wenn jetzt das Pulsverhältnis stark von 50% abweicht, dann funktioniert das nicht mehr zuverlässig.
Posts by andi6510
-
-
So, seit einer Stunde teste ich das Flashen...
Also erst mal funktioniert Schritt 1 beim Flashen schon mal nicht. In Schritt 1 werden der Reihe nach alle 8 Firmware-Files eingelesen und auf Integrität überprüft. Das klappt nur für die ersten 4. Dann steht ein Diskettenwechsel an. Wenn ich den mache, dann findet er die 5. Datei nicht mehr. Irgendwie wird also die zweite Diskette nicht erkannt.
Gegenprobe: Vor dem Starten des Vorgangs habe ich das Lesen der Register deaktiviert. Dann liest er beide Disketten fehlerfrei ein.
Nun wurde ich mutig: Nachdem beide Disketten durch waren, kann man das eigentliche Flashen starten. Also habe ich das Registerlesen wieder eingeschaltet und die Flashprozedur gestartet. Die erste Datei wurde auch in ein paar Minuten geflasht. Gefühlt deutlich langsamer als normal, aber immerhin schien es zu klappen. Dann hat er die zweite Datei eingelesen und sich daran dann leider verschluckt. Irgendwas passiert noch, aber es sieht so aus, als würde er nur alle paar Sekunden ein Byte schreiben. Keine Ahnung, ob das jemals fertig wird, aber wie es aussieht, passiert da in absehbarer Zeit nichts mehr.
Fazit: Flashen geht immer noch nicht!
Ich habe mal über den Vorschlag von Natas und -micky nachgedacht, an die 2 Byte Leseantwort vom PIC noch 60 Dummybytes anzuhängen. Das würde dann tatsächlich den RX Buffer füllen und somit dafür sorgen, dass nicht erst der 2ms timeout abgewartet werden muss. Dafür hat man den Nachteil, dass die 60 Leerbytes natürlich auch Zeit kosten. Momentan liegt (glaube ich) die serielle Baudrate bei 500kBit. Ein Byte mit Start/Stoppbit braucht dann ca 20us. 60 Bytes als 1.2ms. Man würde es damit also gegenüber den 2ms fast doppelt so schnell machen. Das wäre ja schon was, aber ich fürchte das reicht immer noch nicht. Es gibt Pläne die Baudrate auf 2MBit anzuheben. In diesem Fall würde es nur noch 300us dauern, bis der Buffer voll ist. Man wäre gegenüber den 2ms also 6-7 mal schneller. Noch schneller wäre dann natürlich der Handshake, der aber eine zusätzliche Leitung in der Hardware benötigt.
-
Das klingt sehr gut!
Heute Abend teste ich das nochmal ausführlich.
Gilt das für alle Übertragungsmodi oder nur für den UART Modus, den wir nutzen?
So wie ich die appnote verstehe, ist das eine Eigenschaft von USB. Ich erinnere mich auch daran, dass wir bei dem Problem mit einem anderen Chip, welches ich oben in #41 geschildert hatte, genau das selbe Problem hatten. Auch hatten wir dann erstmal den timeout auf 2ms eingestellt um dann später die Handshake-Leitung nachzurüsten. Damit lief es dann ausreichend schnell.
-
ja, es pollt staendig und ja, das koennte man bis zu einem gewissen Grad aendern. Allerdings ist das Pollen durchaus erwünscht, weil man da auch in live die Änderungen an/in der Hardware sehen soll, z.B. wenn jemand den externen Schalter am FPGASID umlegt. Man wird also niemals vollstaendig auf das Pollen verzichten koennen.
Leider ist das alles auch ziemlich monolithisch mit dem Bildschirm-refresh verknüpft und da alles in Spaghetti-Assembler programmiert ist, ist das keine so leichte Aufgabe das entsprechend umzubauen. Das Schlimmste dabei ist der Testaufwand. Es handelt sich ja immerhin um eine im produktiven Einsatz befindliche Software. Wenn die nicht verlässlich ist, hab ich hier keine Ruhe mehr...
Ich habe angefangen die von mir oben verlinkte FTDI AppNote zu studieren. Erste Erkenntnis: USB sendet in Paketen von 62+2=64 Byte. Wenn das Paket nicht voll ist, dauert es 16ms bis es auf den Weg geschickt wird. Ich glaube das sehen wir hier. Der PC schickt das Lesekommando, welches (weil der PC ja auf das Ergebnis wartet) erst mal 1 ms wartet, bevor es abgeschickt wird. Dann schickt der SidBlaster die Antwort, welche auch zu wenig Bytes enthält, um sofort verschickt zu werden. Also dauert es diesmal 16ms, bis die Antwort ihren Rückweg antritt. Damit dauert ein Lesezugriff 17ms(!).
Man kann laut der App-Note ein bisschen an den Parametern drehen (Paketgröße, timeout etc), was aber nicht das grundsätzliche Problem behebt. Um das Problem tatsächlich zu beheben, muss man die Hardware-Handshake Leitungen aktivieren. Also z.B. DTR . Damit kann der PIC dann mitteilen, dass die Ergebnisdaten geschickt wurden. Nach Wackeln an DTR gehen die Daten dann sofort auf die Reise und die 16ms timeout werden abgekürzt. Das dürfte alles sehr beschleunigen. Allerdings: Die Handshake-Leitungen sind in der Hardware gar nicht angeschlossen. Muss man also noch nachrüsten.
Kapitel 3.1 und 4.2 in der AppNote enthalten die wichtigsten Infos zu diesem Thema.
-
Nachtrag: Ich habe hierzu eine sehr spannende Appnote von FTDI gefunden:
https://www.ftdichip.com/Suppo…2B-04_DataLatencyFlow.pdf
Ich glaube, das hat damals sehr geholfen unser Problem zu verstehen. -
Also, ich konnte jetzt kurz mal was testen: Ich komme jetzt auch über den FPGASID-check am Anfang und der Demomodus wird nicht aktiviert. Soweit so gut.
Allerdings ist Configuru nicht wirklich bedienbar, weil alles so extrem langsam vonstatten geht. Wenn man das Lesen zwischendrin ausschaltet, dann kann man zwar was bedienen und die Konfiguration wird wohl auch geschrieben (?), aber auf dem Bildschirm werden die Änderungen nicht angezeigt, weil hierzu wieder der Zustand zurück gelesen wird, was dann natürlich nicht funktioniert.
Im Moment würde ich davon abraten damit den FPGASID zu flashen. Das wäre mir zu heiß.
Wenn da irgendwas sinnvoll funktionieren soll, dann muss das Lesen um Faktoren schneller werden. gh0st ist ja dran, mit neuer PIC Firmware und neuem Protokoll. Aber ich glaube die Verbesserungen müssen da wirklich grundlegend sein. Sonst wird das nichts.
Diese FTDI chips haben so ihre Tücken. Ich erinnere mich an ein ähnliches Problem (mit einem chip von FTDI mit parallelinterface), dass der Treiber immer erst Daten im internen Buffer gesammelt hat, um diese dann blockweise raus zu senden. Wenn man dann immer nur ein paar Bytes geschickt hatte, dann hat er jedes mal auf einen timeout von ein paar Millisekunden gewartet, bevor der Buffer losgeschickt wurde. Irgendwo konnte man aber eine Handshake-Leitung aktivieren (die wir erst in der Hardware nachrüsten mussten) dann wurde dieser Zustand erkannt und die Daten wurden per hardware-Handshake angefordert, auch wenn der Buffer noch nicht voll war. Aber da das jetzt ein komplett anderer Chip war, kann man diese Erkenntnis womöglich nicht direkt auf unsere Situation hier übertragen.
-
Display MoreUnd jetzt kommen noch weitere Ideen
Wenn ich vor dem Spielen einen Musikstückes dem fpgasid mitteile welchen chip typ ich brauche und welche stereo Adresse und welchen mode, dann klingen alle gespielten Stücke wie sie sollten, ausser 3-SID.
Gienge das und muß dafür Lesen vom Chip wirklich an sein?
Ach herrlich, ich kriege schon wieder lust z arbeiten.
Ich kann sid writes übrigens auch direkt vom Handy per USBc Adapter an den sid schicken
Damit geht's sogar ohne PC.
Nur lesen gienge hier garnicht, da der Emulator auf dem server läuft und nur sid writes dafür liefern kann.
Das ginge schon. Um den FPGASID zu detektieren musst du lesen können. Ansonsten sollte er sich komplett mit Schreibzugriffen konfigurieren lassen.
-
Also bei mir kommt die Meldung am Anfang noch, scheinbar habe ich aber Version 1, sollte also normal sein.
andi6510 flashen sollte man aber besser noch nicht probieren?
Flashen sollte ich erst Mal testen. Ich habe zur Not die Mittel einen zerflashten (geiles Wort!) FPGASID wieder zu beleben.
-
Klappt auch die Erkennung am Anfang?
Ich kann gerade nicht testen aber ich probiere es so schnell wie möglich aus!
-
Die Frage ist, ob immer die gleichen Register nicht gelesen werden, also ob es an der gelesenen Adresse liegt, oder ob das nur eine Frage der Wahrscheinlichkeit ist, dass manchmal ein paar Register falsch gelesen werden.
Das Bus-Timing, das durch den PIC generiert wird, ist sicherlich nicht ganz exakt so wie am 6510. Evtl entsteht das Problem ja dadurch. Das erklärt aber nicht die Adressabhängigkeit. Muss ich mir mal genauer anschauen.
-
Original-SID Register lassen sich ja normalerweise nicht zurücklesen. Bzw man liest für eine gewisse Zeit immer den zuletzt geschrieben wert aus, egal auf welchem Adresse der ging. Natürlich repliziert der FPGASID auch dieses Verhalten. Damit sind @kenichis Beobachtungen vermutlich erklärbar.
Damit man *wirklich* was lesen kann, muss man vorab ein Magic value schreiben. Ich empfehle hier das für den diag Modus:
D419 --> $EE
D41A --> $AB
Danach sollte man Folgendes lesen können:
D400: 1D
D401: F5
Das wäre die FPGASID-Erkennung.
Für weitere lesbare Register in diesem Mode: HTTPS://drive.giggle.com/open?…U_88RSJesKMCmRgJImMBY99ur. --> Register description --> Seite 7 grüne Spalte.
(Die URL muss von Hand editiert werden, da Google als externer Bildhoster nicht erlaubt ist - also giggle durch Google ersetzen)
-
Ich habe noch ein kleines Problem mit JSIDPlay2: Ich wollte ein kurzes BASIC-Programm eintippen, um die SID-Erkennung zu testen. Dabei ist es mir nicht gelungen ein = Zeichen zu tippen. Ich benutze eine deutsche Tastatur und ich habe die Vermutung, dass es daran liegt. Jetzt habe ich aber kein setting gefunden, mit dem ich das Tastaturmapping umschalten kann. Was mache ich falsch?
-
Nachtrag: Das Lesen schein nicht wirklich immer zu klappen.
Die Hwid im Diag screen sollte mi 8089 anfangen, fängt aber immer mit FF an. Danach sind die Werte richtig.
Die Hwid steht in den Registern ab D404. also kann er von Adresse D404 und D405 nicht richtig lesen, ab D406 - D40B scheint es zu funktionieren.
Bei der FPGASID Detektion versucht er die Register D400 und D401 auszulesen...
-
So, ich habe jetzt mal einen FPGASID getestet.
Was ich vergessen hatte zu erwähnen: Du brauchst 2 Zwischensockel, damit der FPGASID sicher über den Jumpern landet und keine Kurzschlüsse produziert.
Mein Testergebnis:
1. Extrem Langsam
2. Lesen scheint wohl zu funktionieren, allerdings schlägt die FPGASID-Erkennung am Anfang immer noch fehl. Was komisch ist, denn später scheint das Lesen zu funktionieren.
3. Sagte ich schon, dass es extrem langsam ist?
-
Aktuelles Verhalten bei nicht funktionierendem Lesezugriff:
Configuru startet und blendet eine rote Warnmeldung ein, die besagt, dass kein FPGASID gefunden wurden und das Programm daher im Demo-Modus laeuft.
Erwartetes Verhalten bei funktionierendem Lesezugriff:
Configuru startet und blendet KEINE rote Warnmeldung ein.
Das waere dann der schnelle Test)
Hintergrundinfo fuers Debuggen: Am Anfang checkt configuru wie folgt, ob es ein FPGASID ist. In die Paddle-Register wird ein "magic value" geschrieben und danach werden ein paar andere Register ausgelesen, die dann eine spezielle ID enthalten muessen. Dann werden noch Firmware-Versionen ausgelesen und wenn die passen, wird davon ausgegangen, dass ein FPGASID da ist.
Man muss also definitiv in die Paddle und auch OSC3 und ENV3 Register schreiben und von allen SID Registern lesen koennen. Und das im vollen SID-Adressbereich also von $D400 bis hoch zu $D41F.
Beim FPGASID im SidBlaster-USB (Tic Tack) kann man die Jumper ignorieren. Er laeuft mit 12V oder 9V und ignoriert die Filter Caps. Einzig die Paddles haben leicht andere Werte, je nach Jumperstellung, aber das ist zu verschmerzen. Irgendwelche weiteren Kabel brauchst Du erst mal nicht anschliessen. Die zusaetzlichen Adressleitungen gibts im SidBlaster momentan eh nicht. Und Configuru kommt damit klar, was das Wichtigste ist.
Wenn der FPGASID dann erkannt wird, koenntest Du in den diag-screen gehen (D druecken) und dort muss dann eine Firmware-Version stehen, eine HWID und FPGASID-ID (F51D). Nur die Adressen sollten bis auf D400 rot sein, weil ja keine chipselect-Kabel angeschlossen sind.
Du kannst im Basic Screen dann auch mal beide SIDs auf 6581 stellen und mit SAVE A das setting permanent machen. Dann ein tune abspielen mit viel Filtereinsatz. Es sollte nach 6581 klingen. DAnn das ganze nochmal mit 8580 (SAVE A nicht vergessen!) und das ganze klingt nach 8580.
Ohne das SAVE A bleibt das Setting nur bis zum naechsten Powercycle des FPGASID.
Ich werde natuerlich auch intensiv Testen. Mal schauen, wann ich dazu komme... -
Nebenbei: Ich glaube, du hast einen externen Bildhoster genommen. Das ist hier nicht so gern gesehen, weil solche Bilder dazu tendieren nach einer Weile plötzlich zu verschwinden. Evtl lädst du die Bilder also nochmal als Anhang hoch. Dann bleiben sie dauerhaft erhalten.
-
ich melde mich hiermit freiwillig
Vor Zeugen!
Danke!!!Das klingt natürlich extrem spannend, was Du da schreibst! Die Performance-Einbussen beim Read sind mir mittlerweile auch klar. Muss ja alles durch eine serielle Verbindung und der round trip dauert da einfach. Für configuru ist das natürlich mehr oder weniger egal, denn da wird nichts Zeitkritisches gemacht. Allerdings liest ConfiGuru vor allem in Diagnostic-Screen schon wirklich sehr oft irgendwelche Register. Das wird die Emulation sicherlich ausbremsen. Ob das fuer den Anwender irgendwie bemerkbar wird, muss sich dann noch herausstellen. Sobald Register gelesen werden koennen, sollte eigentlich alles in Configuru funktionieren. Inklusive Software-Update.
160 MB sind doch heutzutage Peanuts... Aber eine abgespeckte Version, die nur fuer diesen Zweck benutzt wird, wäre natürlich noch praktischer. Wenn das einmal funktioniert, muss ja auch keine grossartige Weiterentwicklung erfolgen. Alles, was sich dann noch ändert wäre ggf. die ConfiGuru-Version.
Welche Datenträger werden von JSIDPlay2 unterstützt? Am besten läuft ConfiGuru mit einem mindestens 350kB grossen Speicher (z.B. D71 oder D81), dann spart man (virtuelle) Diskettenwechsel beim Firmware-Update. Und am allerbesten natürlich mit Floppyspeeder. Naja, das können wir besprechen, wenn überhaupt schon mal was funktioniert. -
Klar, ein neues Konfigurationsprogramm native z.B. in Java zu schreiben, waere auch moeglich. Ist aber sehr viel mehr Arbeit und vor allem vom Support her aufwaendiger. Das ganze fuer eine doch ueberschaubare Anzahl von Kunden, die das betrifft...
-
Es geht hier nicht nur um die einfache Laufzeitkonfiguration, sondern auch um das Flashen einer Power-Up Konfiguration und auch z.B. um Firmware upgrade etc. Das sind leider nicht mehr ein paar einfache Pokes.
Inzwischen habe ich Anzeichen dafuer, dass evtl auch auf der Treiberseite was fehlt. Das versuche ich gerade zu klaeren. -
OK, hab das gestern Abend noch ausprobiert. Leider ohne Erfolg.
hardsid.c Zeilen 102-104 auskommentiert. --> Keine Veraenderung.
sid.c Zeile 150 und 180 das HAVE_MOUSE zu einem xxxHAVE_MOUSE gemacht, so dass in jedem Fall der Mous-Support inaktiv ist. --> Keine Veraenderung
Aber ich bin angefixt. Mal schauen, ob ich noch was raus finde.
