bin mal gespannt ob das noch was wird - habe da ja meine Zweifel
Ist ja jetzt gerade mal 8Monate drüber... bei den KeyCaps sollte es 5 Monate dauern... zum Schluss waren es 3,5Jahre? OK, da war Corona dazwischen... trotzdem.
Also alles noch ganz entspannt 
Versteh ich das richtig, das GEOSCONF64 support für die CMD HD hat?
Im nächsten Release, Ja... was das einrichten angeht. Aber Partitionen wechseln musst Du wie beim Original-Configure von CMD auch selbst.
Erst mit Updates wie MP3/TopDesk und GDOS64 geht das dann innerhalb der grafischen Oberfläche ohne zusätzliche Programme. Für GEOS 2.0 gibt es aber auch andere Programme, die Partitionen wechseln können (z.B. geoDOS64 V2.9).
Ich habe mich die letzten Tage mit der CMD HD befasst, im Vice. Aber auf der Utility-Disk der HD ist nichts für Geos drauf.
Könntest du bitte das Configure_R für die CMD HD hier zur Verfügung stellen?
Es gibt hier eine CMD-HD-GEOS-Diskette... oder der Link zum D64: klick! Dort ist dann auch ein Programm zum wechseln der Partitionen drauf.
In GEOSCONF64 funktioniert das bereits, aber ich brauch da noch mehr Zeit zum testen. Dafür ist der Shadow-Modus jetzt Standardmäßig nicht enthalten, man kann aber einen "Schalter" umlegen und neu assemblieren. Dann hat man Shadow-Dir aber kein CMD-Support mehr.
Fehler auf meinen D81 kann ich nicht feststellen !!
Das ist kein Beweis... Wenn Du zwischenzeitlich Fonts in der Vorschau betrachtest und der Font selbst fehlerhaft ist, dann können da lustige Sachen passieren.
Kopiert man Fonts von d64 auf d81 hat man am Ende sicher viele Fonts Doppelt, mit DNP kann das nicht passieren,
Was ist denn das für eine Aussage?
Wenn ich mir Fonts von D64 auf D81 kopiere, dann hat man mit DNP das gleiche Problem. Beim simplen kopieren werden ja (bis auf den Dateinamen) keine doppelten Fonts erkannt. Das erfordert ein Tool was die VLIR-Datensätze aller Fonts (alle Font-Größen) miteinander vergleicht.
Sowas halte ich für... naja... Zeitvertreib... ich meine es gibt Font(größen) in einem Font, welche der gleichen Größe in einem anderen Font entsprechen. Also kann ich den Font nicht weglassen, dann würden auch die anderen Punktgrößen wegfallen.
Ich hab damalstm alle Fonts auf ein D81 kopiert... selbst wenn einige Punktgrößen doppelt in verschiedenen Fonts vorhanden waren.
Das löst jetzt nicht das Problem... nur die Aufgabe halte ich für fragwürdig...
nur zu diesem Zweck nutze ich DNP, denn D81 sind mir Eigentlich lieber, weil Fehlerfrei..........
Sofern der Code selbst keine Fehler enthält ist DNP genauso Fehlerfrei wie D81... DNP entspricht FDNative, HDNative oder RAMLinkNative. Wenn der NativceCode fehlerhaft wäre, dann wären es alle NativeTreiber. Auch RAMNative unter VICE.
Der einzige bekannte Nachteil von DNP ist: Er ist sau langsam wenn die Diskette "geöffnet" wird. Dann berechnet der Treiber die Anzahl der freien Blocks, und das dauert bei >65000Blks etwas (bei 1MHz). Ansonsten entspricht meiner Meinung nach DNP allen anderen Formaten was die Stabilität angeht.
P.S. Eine kleine Ergänzung:
Sollte es ein Fehler im Native-Code geben, dann ist ggf. nach dem kopieren die Ziel-Diskette fehlerhaft. Durch das Verzeichnis-Handling kann es z.B. sein, das Track/Sektor für das Ziel-Verzeichnis nicht korrekt gesetzt werden, was dann zu fehlerhaften Dateien auf der Ziel-Disk führt. Das verursacht dann aber keine Mausprobleme, zumindest nicht bis evtl. die Ziel-Diskette geöffnet wird. Dann müsste aber auch Validate nach einem Reboot einen Fehler liefern.
Von daher ist es um so wichtiger zu wissen welche Schritte zuletzt ausgeführt wurden...
Auch ich kann das hier nicht reproduzieren... wenn es aber an GDOS64 liegen sollte (was ich nicht ausschließen kann...), dann müsste das ja auch in VICE auf einem NativeLaufwerk wie REUNative oder RAMNative auftreten. Die darunterliegende Hardware UII+ oder VICE/REU spielt für GDOS64 ja keine Rolle...
Wenn man also das gleiche Boot-Image und Quell-/Ziel-Image wie an realer Hardware verwendet, dann müsste der Fehler ja auch unter VICE reproduzierbar sein.
-Der fehler tritt auf wenn ich mir viele Fonts über den GD-Viewer ansehe
Davon stand im ersten Beitrag zum Fehler nichts... auch nicht ob der Fehler auch mit der vorherigen Version (0.83) reproduzierbar ist...
Wichtig ist bei solchen "Fehlern" das man alle Schritte, egal wie un-bedeutsam die erscheinen mögen, beschreibt. Allerdings hab ich mehrere Fonts in der Vorschau betrachtet... und am ende die markierten Dateien auf ein RAMNative kopiert. Keine Fehler...
-> Laufwerk B:RAM81 mit den Fonts
-> Laufwerk A:RAMNM als Ziel-Laufwerk
Auf B: ein paar Fonts über rechtsklick/DateiVorschau geöffnet und mit C+Y das Fenster geschlossen. Danach den nächsten Font betrachtet usw...
Am Ende sind ja die Dateien auf dem Quell-Laufwerk noch markiert (das ist also ein Usecase wo das Sinnvoll ist...) und mit Drag'n'Drop die Dateien auf das Ziel-Laufwerk (RAMNative) kopiert... keine Probleme.
Was das mit den Tracks angeht... GDOS64 zeigt in GD.CONFIG die Image-Größe in Kb und in Tracks an... die angezeigt Größe ist die Laufwerksgröße, ein paar Kb gehen dann für das Directory und die BAM verloren... Daher wäre es sinnvoller anzugeben was in GD.CONFIG (10048Kb / 157T) angezeigt wird (inkl. Screenshot), anstatt irgendwelche Zahlen in den Raum zu werfen...
Wie gesagt kann ich einen Fehler nicht ausschließen. uwe1972 hatte schon öfters "Probleme", die ich dann erst nach langer Suche oder rein zufällig beheben konnte.
Hier braucht es aber mehr Informationen bzw. einen reproduzierbaren Vorgang damit ich mich da auf die Suche machen kann.
Wenn Das Dir-Shadow aber sowieso nur eine Dummy-Auswahlmöglichkeit ist, das braucht doch dann auch keiner?
Im Configure_R auf der CMD-HD-Diskette ist es ein "Dummy" (eher vergessen rauszunehmen)... in GEOSCONF64 ist es aktuell funktionstüchtig und stammt aus der BBGRAM-Version von Configure_R.
Beim DesKTop 2.0 werden da z.B. nur die Verzeichnis-Einträge im Shadow gehalten, schon die Datei-Icons werden von Diskette gelesen. Das heißt ein Sektor wird vom Shadow gelesen, aber bis zu acht von Diskette. Da merkt man kaum einen Unterschied.
Auf der anderen Seite bietet der Support für FD/HD zwei weitere Laufwerke als Ziel-Laufwerk an. Ich hab z.B. keine 1581, aber 2x FD und 1x HD. Und VICE unterstützt FD/HD ja schon länger...
Allerdings unterstützt GEOSCONF ja auch SD2IEC (passendes aktives DiskImage vorausgesetzt, die MR-Emulation übernimmt das Programm).
Der Vorteil eines vollständigen Cache für die 1581 dürfte evtl. größer sein als bei 1541, bei Configure_R merkt man aber schon bei der 1541 wenn der Cache initialisiert wird, das kann dann (gefühlt) 1-2sek. dauern. Das halte ich für wenig pragmatisch wenn das bei einer 1581 4x so lange dauert. Je nach Anwendung kann das auch öfters der Fall sein als nur beim Einlegen einer neuen Disk.
Außerdem muss man bedenken das beim schreiben zuerst ein Verify mit dem RAM stattfindet, und im Fehlerfall wird auf Disk geschrieben und neu im Cache gespeichert. Damit geht zwar das lesen schneller, das schreiben dafür aber langsamer. Hat man also viele veränderliche Daten bringt der Cache eher wenig.
Ja, bei der 1541 bringt der Cache schon mehr, aber die ist ja sowieso schon langsamer als die 1581. Daher meine Tendenz eher zu mehr Hardware-Support statt einem geringen Mehrnutzen eines Dir-Shadow.
Zum Thema Support für CMD-FD/HD in GEOSCONF64:
Ich hab mir den Treiber von CMD angeschaut. Hier erstmal ein Screenshot vom Configure_r von der CMD-GD-GEOS-Disk:
Dort gibt es für 1581 auch einen "DirShadow"-Mode nur für das Verzeichnis, das hab ich so auch in GEOSCONF64 übernommen (und funktioniert da auch). Aber:
CMD stand wohl vor der Wahl den Shadow-Modus in den Treiber einzubauen, oder den Support für CMD-FD/HD. Da letzteres wohl wichtiger war ist der Shadow-Code aus dem Treiber entfernt worden. D.h. man kann hier in Configure_r zwar den Modus aktivieren... es passiert dabei aber rein gar nichts.
Ich stehe also vor dem gleichen Problem: Entweder den Shadow-Mode belassen und nur 1581 unterstützen, oder Shadow-Mode entfernen (dann aber auch aus dem GEOSCONF64-Menü) und dafür auch CMD-FD/HD unterstützen. Für beides ist da leider kein Platz.
Ich meine ja der Shadow-Dir-Cache bringt sowieso nicht so viel, und ganz dunkel meine ich mich zu erinnern, das die 1581 sowieso immer einen ganzen Track in das Floppy-RAM lädt. Da wären die Lesezugriffe sowieso schon optimiert. Je nachdem was da gelesen wird.
Eigentlich wollte ich ja nur ein "Configure" zum Download über das WiC64 bereitstellen, damit man von einem Original GEOS 2.x mit 512K bei einer REU/GeoRAM mit mehr als 2Mb ein RAM81 einrichten kann um dann direkt GDOS64 herunterzuladen. Dafür bräuchte es den FD/HD-Support nicht, allerdings auch nicht den DirShadow-Modus. D.h. für den Zweck wäre es im Prinzip egal, da man danach über GDOS64 Zugriff auf FD/HD hat (und nein, DirShadow geht auch nicht in den GDOS64-Treibern, das hatte ich schon vor einiger Zeit getestet...)
Natürlich könnte ich beide Treiber in GEOSCONF64 integrieren, wäre dann aber inkompatibel zu DeskTopV2 oder InstallDriveD.
Ich tendiere eher den Shadow-Mode rauszuwerfen... (bzw. via Build-Flag über den MegaAssembler Optional zwischen Shadow und CMD-Support zu wählen)
die Version 2.2 von InstallDrive
Habe sie jetzt hier in VICE und am C128DCR ausprobiert, allerdings nur die 80-Zeichen-Version. 40 Zeichen brauche ich nicht, da in Geos64 das neue GEOSCONF64+ das mit übernimmt und dort hervorragend funktioniert.
Hier bei mir funktioniert "InstallDriveD80+" auf beiden Geos128-Systemen (VICE und C128DCR) absolut problemlos. Danke an darkvision .
OK, die 40Z-Variante hat aber noch ihre Daseinsberechtigung, zumindest für die Anwender die beim alten Configure bleiben wollen (z.B. wegen RAMLink). Für GEOSCONF64 teste ich noch ob man die FD/HD mit ergänzen kann... viel mehr (abseits des SD-Anzeige-Bugs) wird da aber dann nicht mehr geändert.
Danke fürs Feedback... ich hab eben auch noch 128RBOOT getestet, danach war Laufwerk D: auch wieder eingerichtet, d.h. das speichern der GEOS-Variablen funktioniert jetzt auch...
Solange in meiner vice.ini der HD-Eintrag vorhanden ist (Drive11Type=4844), ist es egal, was ich in VICE im Betrieb in der Lfw.-Konfiguration einstelle, es gibt die beschriebenen Probleme. Vielleicht auch deshalb, auf meiner HD gibt es nur Native-Partitionen. Egal.
Kleiner Nachtrag: Die Partitionen sind GEOSCONF64 egal, aber die Treiber in GEOSCONF64 dürften nicht Kompatibel zur CMD-HD sein (es wird der 1581-Treiber verwendet).
Für die CMD-FD und die CMD-HD sendet der Treiber aus dem Configure der CMD-Diskette nur das Wort "GEOS" an das Laufwerk, um das TurboDOS im Laufwerk zu aktivieren. Und ich würde jetzt mal sagen das der Code ein anderer ist als der im 1581-Treiber (hab ich im VICE-Monitor mit dev 11: und einem d-Befehl verglichen).
Das bedeutet das GEOSCONF64 nur auf die 1541/71/81-Laufwerke angewendet werden kann. Für die HD bräuchte es einen anderen Treiber bzw. ich müsste es wie der CMD-Treiber machen und auf eine HD testen und das Laufwerk danach wie eine 1581 oder eine HD behandeln... setze ich mal auf die TODO-Liste...
Seit wann kann man Geos von 11 starten? Ich wußte bisher 8 oder 9....
Man kann mit TopDesk 3.5 oder dualTop das Programm von 11 starten, ja, das hab ich getestet 
Da es nur um den Start als Anwendung geht und nicht um den Start des Systems selbst, hab ich auch nur das speichern unterbunden, an statt das Konzept, wie das Programm die Einstellungen speichert, zu verändern.
Ich werde mir die neue Version aber nur unter Geos 128 mal ansehen, kann aber ein paar Tage dauern ....
Reicht ja... ich hab das zwar auch unter VICE128 getestet (da gab es auch ein paar UI-Problemchen...), da es der gleiche Code wie bei der 40Z-Variante ist sollten Probleme, sofern vorhanden, in beiden Versionen auftreten. Hier Screenshots der 80Z-Version (die 40Z-Version schaltet automatisch auf den 40Z-Bildschirm):
Im ersten Screenshot sieht man einen kleinen "Darstellungsfehler", verursacht durch DOUBLE_W. Das wäre nicht passiert wenn man in der Version einfach die Koordinaten mit x2 multipliziert hätte, es gibt ja keinen 40Z-Support. So aber fehlt links und rechts der Füllung bis zum Rahmen eine vertikale Linie der Füllung. Ein ADD1_W für die linke Seite des Rahmens und für den rechten Rand der Füllung, und das Problem ist beseitigt.
Warum aber mind. eine RAMDisk in A-C enthalten sein muss? Keine Ahnung 
Ich hab das so belassen...
(ich nutze hier jetzt ausschließlich "GEOSCONF64+", der Sinn der der Version ohne + erschließt sich mir nicht wirklich
Die ist 1Block kleiner ... und für GEOS mit DeskTop2 reicht die Version ohne +, da sind die RAM-Optionen dann auch direkt auf dem Bildschirm und nicht im Menü versteckt. Und man läuft nicht Gefahr ein Laufwerk D einzurichten und hat dann Probleme mit DeskTop V2 (ja, da steht ein Hinweis, den ließt ja bestimmt keiner )
P.S. Hat man in GEOSCONF64 kein Laufwerk D: konfiguriert, startet dann aber von einem System mit einem Laufwerk 11, dann wird das Laufwerk von der Version mit + *AUTOMATISCH* eingerichtet. D.h. auch wenn man es eigentlich nicht will hat man dann ein Laufwerk D: und kann mit DeskTop2 keine Laufwerke mehr tauschen. Mit der Version ohne + kann das nicht passieren.
Das ist nichts was ich in GEOSCONF64 so eingebaut hab, das ist auch schon bei CONFIGURE so der Fall (z.B. für Laufwerk C, eben nochmal getestet).
Ich hänge mal die Version 2.2 von InstallDriveD hier an... bevor das noch in Arbeit ausartet
Ich mach jetzt keinen neuen Thread auf, da die Fehler hier diskutiert wurden.
- RBOOT-Kernal-Fehler beseitigt
- Kleinere Menü- und UI-Fehler beseitigt.
- Zusätzliche Sicherheitsabfragen (Startet nur noch mit GEOS 2.0)
- Speichern der Konfig wird bei Start von Laufwerk 11 nicht mehr erlaubt. Bei einem geänderten Laufwerk wird die Konfig evtl. auf der falschen Diskette gespeichert.
- Version für 40Z (GEOS64 und GEOS128/40Z) und 80Z (nur GEOS128) erstellt.
- Diverse Code-Optimierungen, z.B. wurde bei der 128er-Version fast alles gedoppelt, auch bei Standard-Dialogboxen. Dabei ist das hier nicht notwendig (macht der Kernal automatisch).
- Minimal schnellerer Systemstart, da nicht mehr alle Treiber geladen werden... das war auch der Fall wenn "Kein Laufwerk" eingestellt ist. Es wird nur der benötigte Treiber geladen.
Bestimmt sind da neue Fehler eingebaut... wobei das Programm eigentlich relativ einfach ist. Das es keine RAMDisks erlaubt liegt an der Einrichtung, dazu müsste das Programm dann zusätzlich die freien Speicherbänke prüfen, was das Programm dann größer machen würde.
Die 80Z-Version kann man übrigens auch für den 40Z+80Z-Modus assemblieren, ist nur ein Schalter im SourceCode "src.InstDrvD80Z" -> MODE_80_ONLY=FALSE, dann neu assemblieren. Das braucht es aber eigentlich nicht, da die 40Z-Version auch unter GEOS128 startet, DeskTop 2.0 schaltet dann auf den 40Z-Bildschirm um.
Eine Version für GEOS64 und GEOS128 im 40Z+80Z-Modus wäre möglich, das würde aber erfordern alle Grafik-Koordinaten je nach System vor dem Start anzupassen, wie es auch der MegaAssembler macht. Das würde das Programm aber ebenfalls deutlich größer werden lassen.
Falls keiner neue Fehler findet, dann ist das Thema erledigt... und es kann mit GEOSCONF64 weitergehen 
Bisher hatte ich in der ini die HD festgelegt, aber wenn ich die im laufenden VICE nur deaktiviere und dafür eine 1541 oder 1581 einrichte, dann funktioniert es wohl nicht....
Hilft es wenn Du nach dem ändern der HD in eine 1541 noch einen Laufwerk-Reset ausführst?
Ich hab das hier mal nachgestellt, mit einer HD als 11. Dann unter GEOSCONF abgemeldet, in VICE durch eine 1541 ersetzt, und dann in GEOSCONF als 1541 eingerichtet. Geht. Ich würde das auch eher auf die VICE-Konfiguration schieben... denn im Programm werden alle Laufwerke "gleich behandelt".
immer wieder Abstürze.
Innerhalb GEOS? Oder friert VICE komplett ein? Falls letzteres, kannst Du mal in den Monitor gehen und die Adresse der CPU auslesen, wo der Kernal gerade steht?
Probleme habe ich allerdings in Vice (Windows 64bit, GTK, V2.9 vom 24.12.2024), sobald ein 4. Laufwerk konfiguriert ist. Mit 3 Laufwerken scheint es zu gehen. Mal sehen, ob ich dahinter komme, wer oder was da Schuld ist ...
Du kannst ja mal Deine Konfiguration beschreiben, dann kann ich versuchen das nachzustellen.
Aufpassen muss man unter VICE wenn man was an den Laufwerken 8/9 (einschalten, ausschalten oder Typ ändern): Da kann sich VICE dann irgendwann aufhängen weil es Probleme mit der Kommunikation auf dem ser.Bus hat. Ich hatte dazu schon 2020 einen Bugreport veröffentlicht, der das ganze sogar unter BASIC demonstriert... aber da hat sich seither nichts getan. Bei 10/11 ist das kein Problem.
Ich hänge beide TD-Versionen hier mal mit an ...
Danke... auf den ersten Blick fehlt bei beiden Versionen das setzen von r3L beim speichern der GEOS-Variablen im DACC.
Außerdem wurde der 40Z-Modus entfernt, die 64er-Variante lief vorher auch unter GEOS128 im 40Z-Modus (und suchte dabei auch nach einem Configure für GEOS128).
Ich hab jetzt eine gemeinsame Code-Basis für InstallDriveD 64 und 128, für ein Update fehlt da nicht mehr viel.
Falls das in der V2 nicht schon behoben ist...
Ist es nicht...
Die Version 2.1 stammt von W.G. / MegaCom. Der fehlerhafte Code wurde 1:1 übernommen:
Hab das jetzt aber nicht weiter getestet ob und welche Fehler das ggf. erzeugt. Ohne r3L landet der Speicher aber auch hier ggf. an der falschen Stelle im DACC.
Es gibt sogar noch eine weitere Situation wo der Fehler auftritt: Wenn im Infoblock keine gültige Konfiguration für das Laufwerk D: gespeichert ist (Offset $86 im Block). Zumindest theoretisch, meine beiden Versionen haben dort Werte eingetragen. Kann sein das ich die schon mal gestartet und die Konfiguration gespeichert hatte oder das die so bereits ausgeliefert wurden.
Der Fehler tritt aber auch auf wenn man "Kein Laufwerk" einstellt. Allerdings ist r3L dann mit anderen Werten gefüllt, hier aktuell $42 was dann bei DoRAMOp zum Abbruch führt (>4Mb max. DACC).
Abhilfe (bis zu einem Patch/Fix) wäre auch RAM-Reboot in CONFIGURE zu deaktivieren.
InstallDriveD-64 hab ich komplett rekonstruiert... ich schau mir jetzt noch die 128er-Version genauer an und bastele davon ggf. auch einen SourceCode... da es GEOSCONF nicht für den 128er gibt könnte es durchaus noch Bedarf an einer fehlerfreien Version von InstallDriveD128 geben.
Nun ja, zumindest bei mir funktioniert es (möglicherweise liegts an eine bestimmten Konfiguration). Zum Beweis: nochmal meine Geos64 V2.0 Bootdisk ( Konfiguration: A: 1581 (SD2IEC) , B:RAM1581 (16 MB CBM REU von 1541UII+) , C:1571 , D: 1581 (von 1541UII+) ).
Ja, damit funktioniert es, da beim speichern der GEOS-Variablen r3L den Wert $00 hat. Es wurde zuvor ja ein Laufwerk D: installiert und der StashRAM-Befehl speichert mit korrekt gesetztem r3L den neuen Laufwerkstreiber in Bank#0. Dann ist r3L=0 gesetzt wenn zum Schluss die GEOS-Variablen gesichert werden sollen.
Startet man danach aber vom DeskTop aus InstallDriveD: und beendet es direkt wieder, dann wird obige Routine mit fehlerhaftem Wert in r3L ausgeführt und die RAMDisk beschädigt. Ob da eine Datei beschädigt wird oder nicht, hängt davon ab was in den ersten Tracks der RAMDisk gespeichert ist. Scheinbar hat r3L hier (bei mir) immer den Wert $01, damit wären immer nur die Tracks 1-7 betroffen.
Kann auch sein das es da noch andere Fehler gibt, aber damit kann man sich auf jeden Fall sein GEOS zerschießen. Wenn man aber das Laufwerk D: damit beim booten einrichtet und danach nicht mehr verändert, dann dürfte das Problemlos funktionieren. Eben mit Deiner "normal"-Disk getestet:
GEOSCONF "Erase RAMDisk on boot" deaktiviert, über InstallDriveD D: als 1581 konfiguriert, RAMDisk B: gelöscht und die gleichen Dateien wie zuvor drauf kopiert. Dann GEOS neu gestartet, Laufwerk B: hat die gleichen Dateien auf der RAMDisk und VALIDATE liefert keinen Fehler.
Als Gegenprobe dann InstallDriveD gestartet und sofort beendet... Validate liefert auf meiner RAMDisk wieder BADBAM.
Eigentlich kann das Ganze nur irgendwie mit der 4 MB RAM zu tun haben. Unter Geos mit normalen Konfigurieren V2.1 (von 1993) hatte das damals (lang lang ist es her
Nein, hat es nicht... ich hab hier einen Fehler in InstallDriveD gefunden... bei mir reicht es nämlich schon aus das Programm zu starten und direkt zu beenden. Danach ist die RAMDisk beschädigt. Und warum? Weil der Programmierer etwas vergessen hat...
Frage an die GEOS-Programmierer: Was ist hier falsch?
Ich hab die Routine im VICE-Monitor "on-the-fly" angepasst... und schon wird die RAMDisk nicht mehr beschädigt.
Da sollte sich bei Bedarf ein Patchfile für schreiben lassen... oder ich vervollständige den reassemblierten SourceCode für ein Update. Falls das in der V2 nicht schon behoben ist...
Ja, aber man sollte tunlichst vermeiden hier (wie bei normalen Geos) mit InstallDrvD (TopDesk) ein 4. Lfw. einzurichten. Ein Absturz ist die Folge, sobald ein Drive D damit eingerichtet wird...
Also installieren konnte ich Drive D mit InstallDriveD und Deiner "normal"-Diskette...
Ich hatte A:1581 und B:RAM1581, und auf B: den DESKTOP, GEOSCONF und InstallDriveD kopiert. In A: eine Diskette ohne DeskTop eingelegt, dann D als 1581 eingerichtet. Nach beenden sucht GEOS nach dem DeskTop, auf B: ist er ja vorhanden, jetzt allerdings beschädigt!
Ich hab dann in A: wieder Deine "normal"-Disk eingelegt und dann wird der DeskTop von A: geladen. Validate auf B: -> BADBAM.
Also scheint InstallDriveD: da irgendwas falsch zu machen. Das Programm ist ja nicht sonderlich groß, schau ich mir mal an. Aber eigentlich ist es ja mit V2.4 überflüssig, vor allem da InstallDriveD scheinbar keine RAMDisk einrichten kann.
P.S. Damit wir von der gleichen Version sprechen: Ich hab hier ein InstallDriveD/64 V1.2
2. "Konfigurieren" auf den Border verschieben.
3. "Konfigurieren" löschen, von dort erlaubt Geos 2.0 das Löschen.
Ah, Danke für den Hinweis. Ich hatte es nur direkt versucht. Der Umweg über den Border macht es damit etwas einfacher CONFIGURE auszutauschen... 
Ich besitze vom Konfig wenigstens 10 ( oder mehr ) Versionen !
Ich komme aktuell auf 24...
Und ja... da gibt es immer kleine, feine Unterschiede. Die CMD-Versionen z.B. haben das Standard-Laufwerk von 1541 auf 1581 geändert. Das bedeutet das man damit und einem SD2IEC ohne MR-Emulation das SD2IEC als 1581 nutzen kann. Die Original-Versionen haben ein unbekanntes Laufwerk immer als 1541 behandelt.
Dann gibt es Versionen die nur 512K, 2Mb oder 4Mb unterstützen. Mehr macht für GEOS 2.0 kaum sinn, da selbst mit 4xRAM1581 die 4Mb nicht voll genutzt werden.
Trotzdem, Absolut Genial, von dir, die ollen Programme zu Überarbeiten und Fehler zu Bereinigen
Was nicht bedeutet das ich keine neuen Fehler einbaue: Die SD-Erkennung und der kleine Hinweis links/oben im Menüfeld wird aktuell nicht korrekt aktualisiert. Ist aktuell aber nur ein "optisches" Problem und ist in 2.31/2.41 hier schon beseitigt. Ich werde das aber vor einem Update erst noch weiter testen...
