Jetzt hab ich ja auch Deinen Bug-Report gelesen, das man beim Start ein ABORT senden sollte. Ich hab jetzt einfach mal vor die Routinen für den HOME- und ROOT-Button ein uii_abort eingefügt... und schon klappt es!
Das ist eigentlich ein Zeichen dafür, dass mit der UCI Ansteuerung doch was nicht passt - und untzer MP3 nur Glück gehabt... Nun gut, sind die Ansteuerungen alle nochmal zu prüfen.
Das ist eigentlich ein Zeichen dafür, dass mit der UCI Ansteuerung doch was nicht passt - und untzer MP3 nur Glück gehabt... Nun gut, sind die Ansteuerungen alle nochmal zu prüfen.
Ich glaub ich hätte da was:
und
Wenn ich den Code oben richtig verstehe ist I/O abgeschaltet (restoreIO), dann kommt die while-Loop und fragt uii_isdataavailable ab. Das Liest das Status-Register aus. Aber der I/O-Bereich ist am C64 aus... Dann geht das klar unter GEOS128 (I/O immer an), aber logischerweise nicht unter GEOS64. Das erklärt dann den "Fix" im Code:
Das es unter MP3-64 geht liegt evtl. an statusreg unter GDOS64, hier finde ich in $df1c Wert $10 und unter MP3-64 den Wert $de im RAM. Unter MP3-64 würde damit Bit%7 = DATA_AV gesetzt sein, unter GDOS64 ist Bit%7 = 0 = Keine Daten.
Wenn das alles logisch klingt würde ich einen Bugreport aufmachen...
Oh, ja. Das ist ein Bug.
Ich wollte da auch drauf schauen - habe aber gestern feststellen müssen, dass die Zeitplanung über den Huafen geworfen wurde und ich so jetzt erst an der Firmwareanpassung für die Ultimate Hardware sitze - wer den Github Issue gelesen hat, müsste wissen, über welche Firmwareanpassung ich rede.
Oh, ja. Das ist ein Bug.
Ich hab eben als Test nur uii_isdataavailable durch eine korrekte Assembler-Routine ersetzt. Dann klappt das mit der Verzeichnisanzeige und auch die Buttons Home/Root/Back funktionieren. Das bestätigt den Verdacht das die Freezes nur ein Symptom eines anderen Problems waren...
Na gut, dann schreib ich mal einen Bugreport...
Ja, die Wahrheit war zwischen unseren Annahmen - es war tatsächlich so, dass die IO Area nicht eingeblendet war. Aber nicht, weil GDOS die abgeschaltet hatte, sondern weil das Programm fehlerhaft ist.
Es gibt eine neue Version (GeoUTools-v01-20230407-2252.zip) wo der Fehler jetzt behoben sein sollte. Damit dürfte das dann auch unter GDOS64 funktionieren. Ich kann die Version selbst nicht mehr testen, da ältere Firmware nicht mehr unterstützt wird. Freiwillige vor 
Die Version geht jetzt unter GDOS64 einwandfrei.
Was hatten wir da insgeamt für Bugs?
Falsche Wartebedingung, kein RESET des UCI vor dem Anfang, IO nicht passend eingeblendet. Falsche Parameter bei Geos-Routinen, so dass was überschrieben worden ist.
In Summe also nichts, was in Assembler nicht genau so passieren kann... Hmm, die anfängliche Behauptung, dass die Toolchain das fördern würde, ist nicht wirklich zu halten.
Hmm, die anfängliche Behauptung, dass die Toolchain das fördern würde, ist nicht wirklich zu halten.
Das sicherlich nicht... aber es macht ein Programm *deutlich* größer als mit purem Assembler und erschwert die Fehlersuche erheblich. Dem Anwender kann das Egal sein, aber wenn man den Assembler-Code liest dann wird einem ganz schwindlig. Aber besser so ein Programm als gar kein Programm
Die Version geht jetzt unter GDOS64 einwandfrei.
Danke fürs testen... 
Das stimmt. Anderseits ist der Ansatz für mich neu (bzgl. C64 und GEOS) - und wenn man mal schnell zum Testen was braucht, kann es ja durchaus hilfreich sein, wenn man Formatierungen von Zahlen und parsen derselben einfach in C hinschreiben kann... Am Ende des Tages geht es ja auch darum, den Pool der verschiedenen Mittel zu erweitern, damit man das am besten passende finden kann.
naja, von gebrauchen können ist das aber noch einiges entfernt. MP3-64 aktuell, das Prg von D81 gestartet, läuft. in den Unterordner Temp gewechslt, funktioniert, <- (Parent Dir) angeklickt, nichts passiert, <- nochmal angeklickt : Programm stürzt ab. (Maus bewegt sich nicht mehr) 
.
Gruß
Werner
Was ist das denn schon wieder - naja, am besten man schaut mit den RAMDISK Sachen da drauf, ein Abwasch.
Wobei ich da zuletzt mehrere Verzeichniswechsel hintereinander machen konnte und dann mounten.
Mal sehen ob ich morgen zum testen komme.
Eines muss man dem Programmierer lassen, er bessert schnell nach. 
Gruss C=Mac.
So bin zum ausprobieren gekommen.
Es ist jetzt bei allen drei Systeme gleich:
- MP3 128 mit TopDesk
- MP3 64 mit GeoDesk
- Gdos
Das Wechseln der Image funktioniert, egal ob D81 oder D64.
Erwische ich den Ordner Flash passiert nichts ich kann den Ordner wieder verlassen.
Anders beim Ordner Temp, egal was ich anklicke (Pfeil, / oder Haus), das Programm friert ein.
Einziger Unterschied beim MP3 128 verschwindet auch der Mauspfeil, bei den Anderen bleibt er.
Ach ja das Datum ist noch krumm.
Gruss C=Mac.
Anders beim Ordner Temp, egal was ich anklicke (Pfeil, / oder Haus), das Programm friert ein.
Einziger Unterschied beim MP3 128 verschwindet auch der Mauspfeil, bei den Anderen bleibt er.
Hattest Du da was bestimmtes im /Temp drin?
Anderseits habe ich eine Ahnung, wo was schiefgehen könnte... es gibt da einen Vergleich der Endung - man nehme die Länge und gehe ein paar Zeichen zurück, beispielsweise 3 Zeichen. Dumm nur, wenn der Dateiname gar nicht so lang ist
Ob das jetzt einen Crash verursachen kann, vermag ich gerade nicht zu sagen, deswegen frage ich ja, ob im /temp was bestimmtes drin war.
Am Ende wird es vermutlich so was sein, denn das meiste andere haben wir ja bereits geprüft.
Xander war fleißig und hat eine neue Version fertig, die theoretisch auch ein Image in eine RAMDISK laden kann. Dafür wird jedoch passende Unterstützung der Firmware der 1541 Ultimate / Ultimate 64 benötigt, so dass das Feature noch nicht voll genutzt werden kann.
Pro funktioniert jetzt unter Gdos
Aber wie zum Geier muß ich was in der Ultimate einstellen??
-Ich habe LW B als 11 in der Ultimate aktiviert.
Aber das Pro will nun immer auf LW 9 eine Disk mounten
Wieso eigentlich?? hab doch die 11 als LW-Nr eingestellt.
Muß ich da noch was ativieren/Umstellen??
Irgendwie komme ich nicht weiter................
Ich möchte die Disk unter Geos in LW 11 mounten
Gute Frage - dass das bei eingen (inkl. mir) im Test geklappt hat, muss ja nichts für jede Konfiguration bedeuten.
Laufwerk 11 ist doch Laufwerk D unter Geos, oder? Hast Du in dem Programm Laufwerk D ausgewählt?
Ist doch AFAIK so:
A = 8, B = 9, C = 10, D = 11, weitere kann Geos nicht. Wobei RAM-Laufwerke natürlich keine Geräte-ID auf dem IEC Bus haben, den Buchstaben aber trotzdem.
Ich habe nur zugriff auf LW B und das ist ein SD-LW bei mir,
bei den anderen 3 LW (B-D) steht No Taget
LW 11 ist mein RamLW.............
Geos-Konfig:
A,B SD-LW
C FD 2000
D-RamLW
Laufwerk 11 ist doch Laufwerk D unter Geos, oder?
Nicht immer... ich befürchte das GeoUMount nicht damit klar kommt das MP3/GDOS/GEOS die Adresse eines Laufwerks ändern kann.
Was liefert DEVINFO zurück wenn man ein Ultimate-Laufwerk mit ID:8 unter GEOS auf Laufwerk D:(=11) ändert? Erkennt die U-Firmware die neue Adresse oder liefert der Befehl nach wie vor die Einstellung aus dem Ultimate-Menü zurück?
hatten wir so was nicht schon?
News zur Ultimate 1541 II+ und Geos
ich befürchte das GeoUMount nicht damit klar kommt das MP3/GDOS/GEOS die Adresse eines Laufwerks ändern kann.
Oh, das ist wirklich zu befürchten... zumindest habe ich ja im Quelltext bisher keine Abfrage der Gerätenummer gesehen, die Geos für die Laufwerke nimmt.
Also bräuchte man erst mal eine Serie von Schritten, wie man das mit möglichst wenig Hardware (also am besten nur das, was die Ultimate emulieren kann) nachstellen kann, dass die ID von der Durchnumerierung abweicht.
