Das war mir so nicht klar, dass der C128 durch Reset am Userport nicht alles zurücksetzt. D.h. Du hast einen Draht vom Prozessor aus dem C128 raus geführt und klemmst den dann auf den Jumper. Damit kannst Du dann aber nicht mehr so einfach den Adapter aufstecken und abziehen. Da sind dann immer noch extra Handgriffe nötig...
Wäre hier eventuell eine Softwarelösung besser? Wahrscheinlich aber nicht, da dies einen angesteuerten Kernal voraussetzt. Und das ist ja bei eigenen (abgestürzten) Routinen nicht gewährleistet. Oder den C128 so modifizieren, so dass Pin 3 am Userport alles zurücksetzt...
Ja, bei dem C128, auf dem ich getestet habe, habe ich tatsächlich ein Kabel aus dem Gehäuse hängen lassen, das ich dann an den oberen Jumper-PIN hänge. Ob eine interne Lösung möglich ist weiß ich nicht, da ich mich mit dem C128 nicht wirklich auskenne. Ich würde vielleicht einfach stumpf die vom RESET-PIN des Userports abgehende Leiterbah unterbrechen und da das "echte" Reset-Signal anhängen, wenn mir ein Kabel zu doof wäre. Ob es allerdings andere Userport-Module für den C128 gibt, die auf das Standard-Verhalten des Reset-Pins setzen, weiß ich nicht. Ich bin selbst kein C128 Nutzer und habe die C128 Unterstützung auf Anfrage von Thom Braxton eingebaut, der mir auch einen C128 bereitgestellt hat. Da wollte ich dann doch keine potentiell "breaking changes" an der Hardware machen...
Mit Jumper hat der Anwender zumindest alle Optionen offen. Entweder Kabel anbinden oder Jumper schließen und den C128 intern entsprechend modifizieren.
Und deswegen wird die "Revision A" auch eine Verbindung vom Userport PC2 (Pin
zur Atmel-CPU (PB0, Pin 14) haben. Da man sowieso die Servant64-Firmware für die andere Hardware anpassen müsste, hab ich den am besten zugänglichen Pin an der Atmel-CPU gewählt.
Solange die Hardware kompatibel zu meiner bleibt sehe ich da kein Problem. Am at90usb sind ja noch einige Leitungen frei... das in später in eine Revision meiner Hardware zu übernehmen ist sicher auch möglich.
Nur für mein Verständnis: Du hast XLink auf die Servant64-Hardware angepaßt? Sehe ich das so richtig? So dass Du im C64 den XLink-Kernal laufen hast und auf dem PC mit "xlink ..." Kontakt zum C64 aufnehmen kannst? Und dazwischen ist die Servant64-Hardware?
Genau. Der "Stack" sieht so aus: Anwendung -> xlink.dll -> ( Treiber <--> Firmware) -> CIA2 PORT B -> C64 Server (kernal/prg). Für die Unterstützung eines anderen Übertragungsweges braucht es nur einen neuen Treiber und u.U. eine Firmware. (Im Falle des Parallelport-Kabels entfällt z.B. auch die Firmware).
Ich habe also die Servant-Hardware mit einem neuen Treiber/Firmware Paar xlink-kombatibel gemacht. Du möchtest jetzt den umgekehrten Weg gehen und die xlink-Hardware für die Servant-Software anpassen. In diesem Fall müsste die xlink-Hardware halt eine Firmware kriegen, die das Servant64-Protokoll implementiert, sowie die zusätzliche Leitung nach PC2. Ich sehe keinen Grund, warum das nicht gehen sollte. Natürlich würde eine solche Firmware dann auch in Zukunft kompatibel zur Servant-Firmware bleiben müssen.
Gern geschehen. Ich will auch gar nicht irgenwie als Konkurrenz angesehen werden. Das Teil zu löten, dauert schon etwas und ist inklusive der folgenden Reinigung vom Flußmittel nicht ohne. Für den Hobbybastler würde ich in jedem Fall Deine bedrahtete Version empfehlen.
Konkurrenz? Im Gegenteil... die Software ist ja gerade daraufhin konzipiert, dass der konkrete Übertragungsweg vom PC zum C64 transparent ist und durch das Implementieren eines weiteren Treibers andere Hardwarelösungen angebunden werden können, ohne das die anderen Komponenten des stacks (dll, C64-Server) angepasst werden müssen. Wenn jemand lieber deine Version bauen möchte habe ich da überhaupt nichts gegen.
Und außerdem: die xlink-Lizenz erlaubt dir sowieso alles damit zu tun, was du willst, solange deine Änderungen ebenso frei bleiben... Ich bin aber auch immer bereit, neue Möglichkeiten in das vorhandene Projekt zu übernehmen, vorausgesetzt, sie sprengen das Grundkonzept nicht.
)
