Ich habe FA RC4, aber auch die 0.9 auf einem zweiten FPGASID zeigt das gleiche Verhalten.
Hallo Besucher, der Thread wurde 8k mal aufgerufen und enthält 46 Antworten
letzter Beitrag von C64_80er am
Probleme Zusammenspiel FPGASID und EF3
- knusis
- Erledigt
-
-
Ich habe jetzt den SuperKernal32 eingebaut und der bewirkt keine Änderung. Der Fehler bleibt bestehen solange ich die Leitung an /IO1 anklemme. Wobei der FPGASID auf PseudoMono $D400 konfiguriert ist. Die anderen Leitungen für A5 und A8 sind egal, ob diese angeschlossen oder nicht.
-
Das bestärkt meine Vermutung. Ich habe nämlich ein REX 9565 jetzt mal testweise dazwischengeklemmt. Und siehe da: Dann ist es wie bei Dir, es hängt bei jedem CRT. Und Reset hilft.
Jene Beobachtung hat mich zur Vermutung gebracht, dass das Kabel die Steilheit der Flanke /IO1 beeinflusst - und die beim EF3-Timing dann eventuell zu spät kommt.
Beim Reset sind dann einige Register schon eingestellt, und die Auswirkung ist nicht da...Müsste mal wer nachmessen.
-
So Leute, lese das gerade und versuche mir einen Reim darauf zu machen.
So wie ich es verstehe, taucht das Problem auch auf, wenn der DE00 Bereich im Configuru nicht ausgewählt wird. Das ist merkwürdig, denn in diesem Fall ignoriert der FPGASID die Leitung komplett.
Was die Hardware angeht, so bekommt die Leitung durch den FPGASID einen 10k Pullup nach 3,3V. Das sollte aber kein angeschlossenes Modul verwirren...
Kann irgend jemand rausfinden, was das EF3 bei den entsprechenden Aktionen GENAU macht und was GENAU zum Absturz führt?
-
Sobald ich die Leitung am Expansion-Port entferne geht alles wie immer.
Auf einem echten C64 könntest Du die Leitung mal an pin 10 von U15 (74LS239) klemmen. Dieser Käfer erzeugt das Signal und wenn die Signalflanken das Problem sind, dann könnte es helfen so nah wie möglich an der Quelle abzugreifen.
Spricht etwas dagegen, das Kabel einfach nicht anzuklemmen? Mit EasyFlash kannst Du den DE00 Bereich ohnehin nicht nutzen und es gibt auch sehr wenige tunes, die den zweiten SID dort erwarten.
-
Der Crash vom EF3 mit FPGASID an $D500 könnte vielleicht an dem Kompatibilitätsmodus des EF3 zum C128 liegen.
Ab $D500 sind MMU-Register, mit Hilfe derer der C128 erkannt werden kann . Das EF3 läßt den 128er ja nicht nur im 64er Modus starten,Die MMU-Register sind im C64-Modus nicht ansprechbar, die C128-Erkennung des EF3 verwendet $d030
-
Für Pseudo-Stereo braucht man die fragliche Leitung ja nicht, oder?
-
Für Pseudo-Stereo braucht man die fragliche Leitung ja nicht, oder?
Nein brauchst Du nicht.
-
Kann irgend jemand rausfinden, was das EF3 bei den entsprechenden Aktionen GENAU macht und was GENAU zum Absturz führt?
Tipps, wie man das machen könnte?
Auf einem echten C64 könntest Du die Leitung mal an pin 10 von U15 (74LS239) klemmen. Dieser Käfer erzeugt das Signal und wenn die Signalflanken das Problem sind, dann könnte es helfen so nah wie möglich an der Quelle abzugreifen.
Werde ich mal bei Gelegenheit probieren...
Im IO1-Bereich (wenn die Leitung IO1 den Unterschied macht, ist es sinnvoll, an jenen Bereich zu denken) liegen die wichtigen Register des EF3. Im Hinblick dessen, was beim Test gestartet worden ist, wäre dort insb. zu erwähnen:
* Slot-Auswahl
* Bank Auswahl
* Speicherkonfiguration (im Wesentlichen Stelle man damit die Signale EXROM und GAME ein).Im IO2-Bereich liegt RAM. Ganze 256 Byte.
-
Genau, daher hatte ich ja vorgeschlagen, die Leitung nicht anzuschließen. Denn mit dem EF3 kann man den De00 Bereich sowieso nicht nutzen.
-
Auf einem echten C64 könntest Du die Leitung mal an pin 10 von U15 (74LS239) klemmen. Dieser Käfer erzeugt das Signal und wenn die Signalflanken das Problem sind, dann könnte es helfen so nah wie möglich an der Quelle abzugreifen.
Spricht etwas dagegen, das Kabel einfach nicht anzuklemmen? Mit EasyFlash kannst Du den DE00 Bereich ohnehin nicht nutzen und es gibt auch sehr wenige tunes, die den zweiten SID dort erwarten.Ich habe das mal gestern gemacht. Leitung gekürzt und direkt an Pin 10 U15 (74LS139) angeschlossen. Aber es bringt keinen Unterschied.
Mögliche Lösung ist also Kabel nicht anschließen. Oder einen Reset nach der Menüauswahl.
-
Gerade das Easyflash3-Problem mit dem FPGASID im Ultimate 64 reproduziert. Inkl. Workaround mittels Reset.
-
Gerade das Easyflash3-Problem mit dem FPGASID im Ultimate 64 reproduziert. Inkl. Workaround mittels Reset.
Habe ich heute auch getestet, mit dem selben Resultat.
Da verhält sich das Ultimate 64 wie ein "richtiger" C64. -
Nur dass das "Problem" bei der Ulimate 64 auf jeden Fall lösbar ist, auf dem C64 nur vlelleicht.
Warum: Wenn man überhapt keine andere Idee hat, kann man beim U64 einen separaten FPGA Ausgang spendieren, dann ist die Beeinflussing weg. Gideon hat zwar nicht mehr viele frei, aber noch geht es.
-
Ich bin jetzt noch nicht so ganz dahinter gestiegen bei wem was in welcher Kombination klemmt, hab aber mal paar Sachen auf dem Ultimate64 probiert. Ich verwende meinen 1xFPGASID auf 2 Sockel Adapter, dh, die rote (IO/1) Leitung vom FPGASID hängt an CS von Sockel2 und A5/A8 ist nicht verbunden. Sobald ich im Ultimate64 Menü den zweiten Sockel auf $DE00 konfiguriere sieht das ähnlich aus wie schon hier gepostet, Easyflash bleibt mit bunten Kästchenscreen beim Start einiger CRTs hängen, allerdings nicht bei allen. Stelle ich eine andere Adresse für Sockel 2 ein, funktioniert alles. Es liegt also nicht pauschal am FPGASID, der ist bei mir in diesem Fall auf Stereo $D400 & $DE00 konfiguriert aber eben nicht an IO/1 angeklemmt. Also stört sich das System daran schon mal nicht.
-
Interessantersweise sieht IO/1 absolut identisch aus, egal ob die Leitung vom FPGASID dranhängt oder nicht.
ohne
with io1.jpgden kleinen Überschwinger beim Wechsel von Low auf High kann man ignorieren, der fehlt auch immer mal wenn IO/1 nicht angeschlossen ist.
Auch wenn ich live IO/1 vom FPGASID an Pin 7 halte ändert sich weder der Spannungspegel noch die Flanke.
Unstrittig ist aber, dass das EF3 zickt wenn diese Leitung an Pin 7 hängt. Ich finde halt nur nichts so richtig worauf ich mal triggern könnte. Interrupts kommen auch eher sporadisch aber eben ständig, taugt als Trigger auch nicht. Vielleicht kommt ja wirklich irgend ein Signal ne Mikrosekunde zu spät und das EF3 hängt sich auf. -
Hey, das bestätigt meinen neuen Verdacht: Ich habe gestern mal das CRT, was immer die Probleme hatte, in den Systemslot geflashed. Und siehe da, das CRT rennt.
Was ist dann anders: Die Umschaltung des Slots fällt weg. Ansonsten macht das CRT natürlich die selben Zugriffe.
Du müsstest also irgendwie die Slot-Umschaltung prüfen... Keine Ahnung, vielleicht klappt es, auf der Systempartition etwas zu legen, was die SLotumschaltung in einer Endlosschleife macht - dann könntest Du einfach auf die nächste IO1-Flanke triggern.
-
Es koennte ja sein, dass der FPGASID auf I/O1 reagiert, obwohl I/O1 weg konfiguriert wurde. Das muss ich mal im Code nachschauen. Sollte zwar nicht sein, aber niemand ist unfehlbar.
Wenn der FPGASID bei einem read Zugriff auf DE00 beispielsweise seine Ausgaenge trotzdem aktiviert, dann koennte es so einen solchen Absturz verursachen. -
Ich bin jetzt kein Easyflash 3 Fachmann - aber die Register des Easyflash sind Write only. Beim Easyflash 3 nehme ich an, es ist auch so. Das gilt explizit nicht für IO2, da ist RAM.
Also sollte im IO1-Bereich nur geschrieben werden. Und geschrieben kann auch parallel werden.
Wie auch immer, das Menü-CRT werde ich mal im VICE probieren... Bis auf die Bankumschaltung hoffe ich, dass es klappt. Dann sehe ich ja per Breakpoints, was er im IO1 macht.
-
Also sollte im IO1-Bereich nur geschrieben werden. Und geschrieben kann auch parallel werden.
Das heisst ja nicht, dass der FPGASID da nicht trotzdem was auf den Datenbus wirft. Ich gehe da jetzt einfach mal vom Schlimmsten aus.
Das EF3 muss ja auch irgend welche "Schweinereien" machen, denn es kann ja angeblich Kernel ROMs einblenden mit der gleichen Kompatibilitaet wie ein im Rechner eingebautes Kernel ROM. Und das geht ohne Zugriff auf das Prozessor-Register "eigentlich" gar nicht. Da frage ich mich jetzt, wie genau das EF3 das bewerkstelligt.Je nach dem kann man sich ueberlegen, ob das irgendwie mit dem FPGASID in Konflikt steht.