Ist denn in den FDx000 genau so ein Ding verbaut?
Soweit ich weiß ja, DS1216E... VICE hat sogar eine Emulation dieser RTC im Emulator für die FD2/4.
Ich hatte vor ein paar Monaten mal selbst danach gesucht und einen bebilderten Umbau auf ext.AKKU dafür gefunden. Habs dann aber bleiben lassen und jetzt finde ich die Seite nicht mehr 
Zur Info / Hinweis:
Ich hab beim testen der neuen Laufwerkstreiber ein Problem unter VICE mit einer 1571 als Laufwerk #8 oder #9 gefunden: Die Installation auf eine 1571-Disk funktioniert hier nur sehr selten. Schon beim entpacken bleibt der C64/VICE hier ab&zu hängen. Nichts geht mehr.
Das Problem lässt sich auch mit GEOS 2.x als BASIS-System nachvollziehen, also ist es kein Problem der neuen Laufwerkstreiber. Auch eine 1581 oder xscpu64 scheint zu funktionieren.
Es funktioniert auch wenn die 1571 unter VICE als -drive10type=1571 eingerichtet wird und mit dem GEOS.Editor auf #8 unter GEOS eingerichtet wird (Dazu wird @"u0>"+chr$(x) verwendet...). Zumindest hat die Installation damit mehrfach funktioniert.
Ich hab dazu einen Bug-Report geschrieben. Es ist aber ein sehr spezielles Problem, daher glaube ich nicht an eine Lösung dafür. Als Alternative bleibt unter VICE nach Möglichkeit nicht auf eine 1571-Disk als Laufwerk #8/#9 zu installieren.
An einem echten C64 hat es funktioniert, auch wenn es da noch Probleme mit dem 1571-Modus gibt: Das Laufwerk wechselt irgendwann in den 1541-Modus und erkennt dann die doppelseitigen Disketten nicht mehr. Das ist aber ein anderes Problem. Auch der GeoDesk64-Support für doppelseitige Disks ist nicht ganz perfekt. Da werde ich noch ein paar Anpassungen vornehmen müssen.
Das Teil hast Du gesehen? Sind zwar nicht alle - aber schon viele...
Das hast Du aber auch gesehen und gelesen?
Ich hatte gehofft, dass ich die Vorteile der REUs auch unter SuperCPU-Verhältnissen mit GoDot nutzen kann.
Ich schalte in VICE/x64 den WARP-Modus an. Hab meine Version auch so gepatched das ich auch 1000% angeben kann. Dann steigt zwar reSID aus, aber ab&zu sehe ich dann da auch %-Werte von um die 6000-7000%. Da braucht es keine SCPU mehr. Ja, dann geht die Uhr falsch... aber das nehm ich in Kauf.
Mit der VICE/SuperCPU-Version teste ich nur noch ganz selten.
Und eine echte SCPU kann sich ja kein Mensch leisten...
Das muss man heute ja auch nicht mehr, gibt ja Alternativen...
Ist glaube ich ein bekanntes Problem... hat mich bei MegaPatch am Anfang auch gewundert. Wenn ich das teste nehme ich SCPU+RAMCard+GeoRAM... sonst C64+GeoRAM+REU.
Ideen/Wünsche: Bei mehreren Zwischenspeicherungen, verschiedener Datum/Uhrzeit Blöcke mit CONTROL + 1-5, wäre eine Anzeigemöglichkeit des Inhaltes der 5 Speicherstellen, doch sehr hilfreich. Vielleicht lässt sich das ja noch irgendwie integrieren. Wie immer, nur "Nice To Have"
Hilfe Seite #3...
Danke für den Test. Ich entnehme dem Ergebnis das bis auf den FileType-Bug alles funktioniert. Dann aktualisiere ich das bei Gelegenheit. 
Sehe ich anders: Die Diskussion könnte eventuell dazu beitragen, sich als Käufer zu entscheiden, ob man sich ein SD2IEC mit oder ohne LCD kaufen möchte.
Na dann... ohne LCD reicht vollkommen. Auch zu DOS-Zeiten hat man mittels CD das Verzeichnis gewechselt. Und nicht immer war das aktuelle Verzeichnis im DOS-PROMPT erkennbar.
Das stimmt zwar aber ich geben mal vorsichtig eine Schätzung ab das 95% der SD2IEC keinen Display haben
das ist vielleicht ein nice to have aber mehr auch nicht. Ich hätte es definitiv noch nie gebraucht.
+1 !!!! 
Aber wer soll denn "blind" z.B. aus 754 Images genau das richtige mit "Ikari Warriors" finden? Dazu braucht es entweder ein LCD oder den oben erwähnten Filebrowser, um sich keinen Wolf suchen zu müssen.
Nein, Du hast das System noch nicht verstanden.
Normalerweise wechselt man das DiskImage nicht mit den Buttons, die sind nur für eine SwapList gedacht. Keiner kommt auf die Idee 754 DiskImages in so eine Liste zu packen und dann blind zu wechseln.
Der normale Weg ist:
@cd:diskimage oder open15,8,15,"cd:diskimage":close15
Oder eben ein Dateimanager/FileBrowser wie NAV96.
Das ist doch ein Unterschied zu einer Diskette oder max. 10 Partitionen. Die kann ich man doch noch gut im Kopf überblicken.
Auf die CMD-HD passen 254 Partitionen. Ich hatte vor 20 Jahren damit kein Problem...
P.S. Vielleicht kann ein Mod diese Diskussion um Sinn oder Unsinn von LCD in einen eigenen Thread auslagern, das hat mir der Frage des TO nichts mehr zu tun... 
Deshalb wundert es mich ja, dass hier einige meinen, das wäre gar nicht nötig. Ich kann mir ehrlich gesagt nicht vorstellen, wie man das halbwegs sinnvoll ohne LCD machen soll.
Es ist auch nicht nötig. Es ist "Nice to have", aber hat Deine CMD-HD oder CMD-FD oder CMD-RL ein LCD-Display das Dir ständig anzeigt welche Partition aktiv ist? Nö? Dann ist das wohl kein muss...
Wenn Du mit dem TC64 oder mit der Ultimate DiskImage in die interne 1541 einbindest siehst Du ja auch von "aussen" nicht welches DiskImage gerade im Laufwerk liegt.
Nach einem POKE 828, 183 verhalten sich die F-Tasten des C128 (sowie HELP und Shift-STOP) wie im 64er-Modus. POKE 828, 173 macht das wieder rückgängig.
Danke für den Tipp... bei anderen Programmen hab ich die F-Tasten-Belegung im 128er-Modus zur Laufzeit geändert... das hier scheint ja um ein vielfaches einfacher. 
Ich möchte Programme von der 1541 auf die SD2IEC ziehen auf der SD Karte möchte ich Ordner anlegen z.B. Ordner "Kopierprogramme" nächster Ordner "Spiele" usw.
Das geht bei onefilern mit cbmcommand. Das ist ein Dateimanager der über zwei Panels Quelle und Ziel anzeigen kann. Programme die Dateien von einer 1541 nachladen wollen werden so evtl. nicht funktionieren. Da musst Du schon mehrere D64 auf dem SD2IEC anlegen. Für einzelne Programme kannst Du mit cbmcommand aber Verzeichnisse anlegen und Dateien kopieren.
Ich habe kein SD2IEC, deshalb frage ich mal nach: Wie kann man ohne LCD sehen, welches Discimage gerade aktiv ist?
Das geht technisch gar nicht, man kann nicht abfragen welches DiskImage gerade aktiv ist.
Was geht ist ein LCD-Display, das kann einen Teil des letzten DiskImage-Namens im Display anzeigen.
Ich stelle mir das "ewig nervig" vor, wenn ich mit zwei Knöpfen "blind" ein Discimages auswähle und dann jeweils das Directory anzeigen lassen, damit ich weiß, welches Image gerade aktiv ist.
Das wechseln per Knopf macht nur Sinn bei MultiDisk Games oder Demos. Dann erzeugt man eine SwapList in der die Namen der DiskImages enthalten sind die man wechseln will. Ohne SwapList brauchst Du die Buttons nicht zu drücken... Für mein CMD-HD-Backup hab ich mir eine SwapList mit allen Partitionen erstellt. Der ImageName hat dann jeweils die Partitionsnummer im Namen, dann kann ich im DIsplay sehen welche "Partition" aktiv ist.
Und abgesehen davon kann man mit NAV96 bequem DiskImages wechseln oder mit GEOS sogar DiskImages erzeugen und wechseln. Das hat schon CMD-HD-Komfort.
Dark Blizzard : Ich hab auch noch so ein SD2IEC. Das steckt mit Gehäuse hinten C64 am seriellen Port. Von da an Kabel zur 1541.
Ich verstehe das alles leider nicht so ganz, aber wird damit dann eine Geos "HDD" möglich sein, so wie bei SD2IEC?
Ja, das Thema ist etwas abgedriftet. Aber im Prinzip kann man aktuell im Ultimate-Menü ein D81 auswählen und dann innerhalb von GEOS einblenden. D.h. aber Du kannst nicht wie bei einer CMD-HD oder SD2IEC unter GEOS das DiskImage wechseln. Du musst den Umweg über das Ultimate-Menü gehen.
Weitere Frage: Welchen Treiber braucht die Ultimat64-REU? Native? Commodore?
Die REU selbst braucht nicht wirklich einen Treiber. Du musst die im Ultimate-Menü aktivieren, Größe mind. 1024Kb. Wenn Du GEOS 2.x startest und im CONFIGURE-Programm die REU erkannt wird dann ist alles richtig.
Dann erkennt auch MegaPatch die REU.
Nur Laufwerke (egal ob echte Laufwerke oder RAM-Laufwerk) benötigen einen Treiber. Die wählt man aber entweder über CONFIGURE (GEOS 2.x) oder GEOS.Editor (MegaPatch) aus.
Gibt es ein Tiutorial, wie ich Megapatch 3 mit Ultimate 64 und emulierter REU installieren kann am besten? Irgendwie bekomme ich es nicht hin leider.
Du benötigst erstmal ein laufendes GEOS 2.x-System. Hast Du das bereits installiert?
Ein spezielles Tutorial für die Ultimate braucht es glaub ich nicht. Die Installation läuft ja immer gleich ab, egal ob an einem echten C64 oder Ultimate oder VICE.
Die größte Schwierigkeit ist wenn man unter GEOS 2.x nur 1541-Laufwerke hat. Mit einem x81-Laufwerk (egal ob 1581 oder CMD HD/FD/RL mit 1581-Partition) tut man sich wesentlich leichter.
Es wird Zeit das ich mir einen SD2IEC zulege, es gibt ja viele zur Auswahl. Ich würde mir den gerne zulegen der von Gehäuse her zum c64er passt 59 € .. aber 15€ Versand ist ein bischen krass. Habe schon geschaut finde aber keinen aus Deutschland hat da jemand einen Tipp?
Das ist das von ncsystempl... das hab ich auch. Ohne LCD 3x bei AMAZON bestellt. Aktuell aber deutlich teurer. Das mit LCD hab ich via EBAY bestellt.
Das LCD halte ich aber für überbewertet weil nicht der gesamte Dateiname angezeigt wird...
Keine Ahnung, ich hab keinen Plan vom Protokoll. Nur mit "Bit setzen" wird das glaube ich nichts, der Bus wird ja softwaremäßig kontrolliert. Was ich noch im Hinterkopf habe ist, dass wenn ATN aktiv wird alle Geräte sofort aufhören müssen zu übertragen. Aber da bin ich wirklich keine Hilfe.
Nuja... das wäre nochmal ein Ansatz... vorher immer ein ATN zu senden...
Ach ja, die Signale sind low-aktiv, WIMRE. Aber auch das wirst du in dem Fall schon wissen. Sorry, wollte dich nicht langweilen.
Nein, kein Problem. Damit hab ich bei meiner Code-Doku nach 20Jahren noch immer ein Problem. LOW=1 und HIGH=0 das muss ich grundsätzlich mal in meinen Quelltexten richtigstellen... da steht "waitDataIn_LOW" und dabei wird darauf gewartet das jenes DATA-IN-Bit=0 also HIGH ist... Also ja, das weis ich... aber ab&zu braucht man da einen Tritt... 
Aber Danke für Deine Hinweise... das mit ATN teste ich mal...
Bei der F5 Taste komme ich nicht ganz mit..........
Hierzu die Bilder im Anhang.
Bild 1 zeigt das DIR Verzeichnis der Partition. Jetzt drücke ich F5. Es erscheint Bild 2.
Müssten jetzt nicht alle Directorys der Partition im Fenster angezeigt werden, um mit CRSR UP/DN ausgewählt zu werden.
Nein... Es werden die Verzeichnisse an der aktuellen Position angezeigt. Du willst bestimmt nicht das cbmDirEdit64 alle Verzeichnisse sucht. Da könntest Du F5 drücken und dann nächste Woche dann das Verzeichnis wählen
Und "<- DONE" heißt: Du hast das richtige Verzeichnis gewählt und willst hier die Dateien sehen. Wenn Du nur mit den CRSR-Tasten das Verzeichnis auswählst, dann ist das Verzeichnis noch nicht aktiv. Zumindest ist das aktuell so. F1 bedeutet "Öffnen". Das ist ja noch nicht passiert... also landest Du im zuletzt geöffneten Verzeichnis.
Übrigens, das Programm startet auch im 128/80 Modus und wird korrekt eingelesen. Allerdings reagieren die "F" Tasten nicht richtig und auch die CRSR Tasten wollen nicht so......
Daher cbmDirEdit64... in dem Fall würde ich das auch nicht ändern. Das lohnt den Aufwand nicht.
Das würde der C64-Schaltplan verraten:
Welche BITs dafür zuständig sind ist mir schon klar, das steht auch im WIKI.
Aber wie bekomme ich einen definierten RESET-Zustand sowohl im Laufwerk (Register $1800?) als auch am C64 hin ($dd00)? Es scheint für mich so als könnte das ein ziemlich Zeit-kritisches Timing-Problem sein.
Ich vermute das die dritte Abfrage nach DATA-IN=LOW zu schnell erfolgt wenn es um das erste Laufwerk am Bus geht. Um auszuschließen das die Leitungen evtl. falsche Werte beinhalten würde ich die gerne auf einen definierten Zustand zurücksetzen bevor ich LISTEN aufrufe.
Mein "letzter" Versuch wäre quasi vor jedem LISTEN die Register im Laufwerk und im C64 auf "Standard" zu setzen. Wenn das nichts hilft... Bug-Report und evtl. damit leben.
Hi...
Ich steh hier auf dem Schlauch, vermute mal ein Problem in VICE...
Seit ich mit VICE / x64 versuche GEOS/MP3 auf einer 1571 als Laufwerk #8/A: zu installieren und sich das System dabei aufhängt, hab ich den Fehler bisher immer in den Laufwerkstreibern gesucht.
Das System hängt sich dabei aber nicht im Code der GEOS-Treiber auf, sondern hängt im C64-ROM in der LISTEN-Routine fest. Genauer bei $ED5A wo auf DATA-IN=LOW gewartet wird. Ganz sporadisch, bei evtl. 1 von 1000 Aufrufen...
Das seltsame ist das die Routine 3x auf die DATA-IN-Leitung testet... der erste Aufruf DATA-IN=LOW funktioniert, danach wartet der C64 auf DATA-IN=HIGH... das geht auch noch... das letzte DATA-IN=LOW kommt nicht mehr an.
Da ich das bisher nicht 100%ig reproduzieren kann (das System friert immer an anderer Stelle bei der Installation ein, aber immer an obiger ROM-Routine...) hab ich versucht vor den LISTEN-Routinen eine Pause von 1-2/10sek oder ein UNLSN zu setzen. Quasi als Verzögerung... Das ändert aber nichts.
Dann hab ich versucht das ganze auf Laufwerk #10/C: zu testen. Da geht es ohne Probleme.
Ich hatte auch den Verdacht das es evtl. das TurboDOS von GEOS ist, aber auch mit meinen neuen Standard-FloppyDOS-Treibern (die nur OPEN/CLOSE usw verwenden) hängt sich der Kernal bei Laufwerk #8 auf, bei Laufwerk #10 alles OK.
Jetzt würde ich ja gerne einen Bug-Report schreiben. Aktuell kann ich aber nur sagen das in seltenen Fällen ein LISTEN dazu führt das der C64-Kernal hängt und das Laufwerk #8 nicht geht und #10 funktioniert. Nicht sehr hilfreich und nur schwer reproduzierbar.
C64- oder JiffyDOS-ROM machen auch keinen Unterschied. Und am echten C64 mit echter 1571 ist das auch kein Problem. Getestet hab ich Vice 3.1 mit x64/x64sc und Vice 3.4 x64/sc.
Kennt sich evtl. jemand besser mit dem IEC-Protokoll aus und könnte mir ein paar Tipps geben um das Problem weiter einzugrenzen? Z.B. gibt es eine Möglichkeit die Leitungen CLK/DATA/ATN zurückzusetzen? Welche Werte sind da notwendig für $dd00? Gibt es dazu ein Standard-Vorgehen? Ich kann in die GEOS-Treiber ja Debug-Code einbauen, alles kein Problem. Aber ich hab vom ser.Bus-Protokoll nur wenig Ahnung.
Ansonsten schreib ich einen Bug-Report, man kann es nicht reproduzieren, und am Ende findet sich im Handbuch zu GEOS/MP3 der Hinweis nicht auf VICE und Laufwerk #8:1571 zu installieren
Markus
