News zur Ultimate 1541 II+ und Geos

Interessant dass das Programm so unterschiedlich reagiert.

Wenn steht: Traget is drive § weiss das Programm nicht welches Laufwerk gemeint ist.

Ich hab ja zwei emulierte Laufwerke, A: U-81 und C: U-41.

Muss nach dem Start des Programm sagen auf welches Laufwerk es zugreifen soll und je nachdem ändert sich die Ansicht des Sticks.

Wähle ich Laufwerk A, werden mir nur "DIR" und D81 angezeigt.

Wähle ich Laufwerk C, werden mir nur "DIR" und D64 angezeigt.

Öffne ich einen Ordner welche die falschen Dxx enthält wird "no data" angezeigt.

Wie gesagt erst unter MP3 128 getestet.

In der Zwischenzeit neuste Version inkl. neustem TopDesk 128.

MP3 64 und GDOS folgen später.

Gruss C=Mac.

Quote from C=Mac

Wie gesagt erst unter MP3 128 getestet.

In der Zwischenzeit neuste Version inkl. neustem TopDesk 128.

Im Source-Code mount.c findet sich dieser Hinweis:

Quote

- Tested using real hardware (C128D, C128DCR, Ultimate 64) using GEOS128 2.0, GEOS64 2.0 and Megapatch3 128.

Also scheint da schon MP3-Support enthalten zu sein.

Was ich so aus dem Quelltext herauslesen kann gibt es da keine UCI-Abfrage vorhanden/nicht vorhanden. Das würde erklären warum es ohne UII+/U64 zu verschiedenen Fehlern kommt.

Wenn UCI abgeschaltet ist, dann dürfte in GDOS64 z.B. die Ultimate nicht als RTC-Gerät angezeigt werden. Wenn das fehlt dann dürfte auch das Tool hier Probleme haben. Also UCI einschalten, in GDOS64 testen ob die Ultimate-Uhr auswählbar ist. Wenn ja dann dürfte auch das Tool funktionieren.

Ich müsste zum testen mal mein U64 oder die Ultimate raussuchen. Aber ich sehe da jetzt kein grundsätzliches Problem mit MP3/GDOS64, wenn schon der Entwickler mit MP3-128 testet...

So stabil ist die Sache noch nicht, ja ich weiss Alpha-Version.

Heute mehrmals Programm gestartet, kein Mauszeiger da, somit blieb nur noch Ausschalten.

Einmal Absturz nahe $B784 (wenn ich es richtig notiert habe).

Danach wieder einwandfreie Funktion.

Kleiner Kurztest mit MP3 64 3.3R9 und GeoDesk:

Programm startet normal und es kann auch problemlos das gewünschte Dxx ausgewählt werden.

Nur die Ultimate führt es nicht aus, es bleibt im aktiven Dxx.

Ist beim C64 bzw. C64-Modus aber kein Problem, einfach den Knopf der Ultimate betätigen und auswählen

Beim C128 ist die Sache mühsamer und das Programm eine gute Alternative.

Gruss C=Mac.

Hallo Werner,

Hab das Menü grad überprüft,

"Command Interface" steht bei mir auf "Enabled"......................

Grüße

Quote from C=Mac

Nur die Ultimate führt es nicht aus, es bleibt im aktiven Dxx.

Bei Dir auch - ich kann das bestätigen, dass das Image leider nicht eingelegt wird.

Jetzt fragt man sich natürlich unwillkürlich: Firmwarebug oder Applikationsbug?

Gibt ja so wenige C64 Programme, die Dxx Dateien in die Laufwerke der Ultimate einlegen, dass man da keien Referenz hat.

Die FW ist bei mir die selbe, die 3.10a...............

Könnte es Evl. doch etwas mit dem Topdesk zu tuen haben ??

schließlich ist Geodesk was ganz anderes als Desktop/Topdesk...............

Na, Egal, warten wir mal auf ein Update, es wird schon werden................

Quote from wweicht

Kannst Du das mal mit Topdesk64 probieren?

Habs probiert, aktuelle MP3 und TopDesk 64 Version.

Selber Effekt, Dxx wird nicht gewechselt.

Wobei beim C64 ist es nicht wirklich schlimm, ein Griff zur Ultimate geht schneller als das Programm zu starten

Beim C128 sieht es anders aus und im Moment kann ich machen was ich will, es funktioniert dort einfach.

Quote from markusC64

Bei Dir auch - ich kann das bestätigen, dass das Image leider nicht eingelegt wird.

Ja ist so (MP3 64), man hört es auch bzw. man hört eben nix.

Quote from markusC64

Jetzt fragt man sich natürlich unwillkürlich: Firmwarebug oder Applikationsbug?

Da fragst Du einen bekloppten Anwender, welcher von nix eine Ahnung hat.

Einfacher gesagt, wo ist der Unterschied?

Gruss C=Mac.

Quote from C=Mac

Einfacher gesagt, wo ist der Unterschied?

In einem Fall muss man GeoUMount korrigieren, im anderen die Ultimate 64 Firmware / 1541 Ultimate II+ Firmware.

Macht also einen großen Unterschied.

Danke markusC64 für die Erklärung.

Nur der vollständigkeitshalber.

Hab es noch unter der aktuellen GDOS 64 Version getestet.

GeoUMont kann gestartet werden, es ist aber nicht möglich irgendetwas anzuklicken.

Gruss C=Mac.

Ich mermag auf die Schnelle nicht zu sagen, wie gravierend die Fehler sind. Aber ich habe mal im Quelltext von GeoUMount reingeschaut und auf den ersten Blick gleich direkt Fehler bei der UCI Behandlung gesehen - das was da steht, mag unter Best-Case-Annahmen wohl laufen, unter anderen Annahmen aber nicht.

Und die Fehler sind von der Sorte: Führ es langsamer aus, dann geht es. Sprich: Schalt Debugausgaben an, die unter Geos ja auf den Grafikbildschirm landen und deswegen schon langsamer sind - dann mag es auf einmal besser ausgehen.

Von daher glaube ich erst mal, dass GeoUMount die Korrekturen braucht... sollte da am Ende übrigbleiben, dass die Ultimate 64 auch Korrekturen braucht, dann schadet es zumindest nicht, wenn man erst GeoUMount korrigiert hat - erleichtert aber jede Diagnose.

Ich hab rein aus Interesse das Programm mal durch den Input-ReAss gejagt. Ich hab ja schon viel fremden Code gesehen, aber so ein Cross-Assembler-Ergebnis, das ist nochmal 'ne ganz andere Liga... Spannend, aber nichts für mich.

Wenn ich Lust und Zeit habe schau ich mir das mal an, aber nur in Bezug auf die GEOS-Programmierung... Forken würde ich das Ergebnis auch nicht, da wäre neu schreiben wesentlich effektiver. Allerdings ist UCI für mich nach wie vor ein Buch mit sieben Siegeln und daher lasse ich das lieber.

Aber den Code zu dokumentieren, wenn auch nur als Beispiel... mal sehn. Evtl. etwas für langweilige Fernsehabende...

Auch wenn es da neue Versionen geben sollte spielt das für mich keine Rolle, da geht es nur um das "Verstehen wollen"...

Quote from C=Mac

GeoUMont kann gestartet werden, es ist aber nicht möglich irgendetwas anzuklicken.

Doch, anklicken kann man die Icons, die blinken auch kurz auf und die entsprechende Routine wird ausgeführt. Also vom Grundsatz her scheint das Programm zu reagieren. Aber wenn das so ist wie markusC64 schreibt, das es schon beim UCI-Zugriff Probleme gibt, dann hängt die Reaktion evtl. von den Ergebnissen ab und bei falschen Werten passiert halt nichts. Mehr kann man hier nicht sagen...

Noch schlimmer. Es gibt ja Routinen, die das UCI Ergebnis abholen. Also zum Beispiel ein Directorylisting.

Und die Routinen haben einen Schutz vor einem Bufferoverflow drin, die können also prinzipiell den halben Speicher überschreiben (inkl. Programmcode). Und ich denke, ohne entsprechende Hardware hast Du, darkvision , das auch im Emulator beobachtet.

In den Fällen, wo es komplett schief geht, mag am Ende so was passieren...

Das in C zu machen und zu compillieren statt zu assemblieren mag per se nicht schlecht sein. Aber man muss den Code dann schon so machen, dass er sich nicht selbst überschreibt, nur weil bei den Daten was nicht passt. So kann das ja keiner debuggen.

UCI Fehler kann man sich in Assembler mindestens genau so gut einhandeln - falsche Wartebedingungen können natürlich in jeder Sprache passieren.

PS: Mein altes Linux will den Code nicht compillieren...

Quote from darkvision

Forken würde ich das Ergebnis auch nicht, da wäre neu schreiben wesentlich effektiver.

Ich muss mal schauen, ob man in Github das kommentieren kann - also das, was direkt auffällt. Denn für den C128 gefällt das mir eigentlich, weil da das Einfrieren mittels Ultimate im 2 MHz Modus nicht klappt. Da ist man dann für den Wechsel mit solch einen Tool eigentlich gut bedient.

Quote from darkvision

Allerdings ist UCI für mich nach wie vor ein Buch mit sieben Siegeln und daher lasse ich das lieber.

Okay, aber für die Uhrzeitabfrage hast Du das doch im Programmcode drin...

Ich muss jedenfalls meine Notizen wiederfinden, wie das Warten im Detail auszusehen hat - wie das halt so ist: Falsches kann leichter erkennbar sein als das richtig zu machen. Zum Beispiel weiß ich, dass man die Reset-Kondigition beim warten berücksichtigen muss (was nicht der Fall ist im Code) - aber auswendig weiß ich gerade nicht wie.

Mal ein kleines Leckerli zum Schmunzeln...

Es geht gar nicht darum was die Routine macht... nur wie Sie es macht. Evtl. ist es am C64 mit nur 1MHz einfach zu umständlich und zu langsam als das es funktioniert.... ich hab mir nur eine Routine mal rausgesucht... wenn das alles so vom Cross-Assembler erzeugt wurde dann wundert es einen schon das hier das Programm überhaupt in den Speicher passt...

UCI macht ein sehr langsames Timing nichts aus, selbst Basic V2 oder das noch langsamere basic V7 des C128 reichen.

Ein "int" auf CC65 dürfte 16 bit sein - damit kann, weil kein Bufferüberlauf kontrolliert wird, der gesamte Speicher durch die While-Schleife überschrieben werden. Okay, natürlich nur, bis das Überschreiben den Programmcode überschreibt.

So viele Daten sollten zwar eigentlich nicht anliegen, aber "sollte" ist immer so eine Sache - Fehelr in den Wartebedingungen sorgen dafür, dass es schwer ist, das auszuschließen. Von dem Fall, dass die Ultimate gar nicht da ist, reden wir an der Stelle besser nicht. Selbst mit Erkennung kann man noch immer ein Modul haben, das an der Erkennungsdresse RAM hat, wo der passende Wert drinsteht - sprich: Man möchte eigentlich, dass dann nicht alles crashed.

So muss das sein (aus der Easyflash EAPI einer älteren 1541 Ultimate Version):

ultimateWait4idle LDA $DE1C

AND #$35

BNE ultimateWait4idle

RTS

Und so ist es:

while ( !(((*statusreg & 32) == 0) && ((*statusreg & 16) == 0))) {

uii_logtext("\nwaiting...");

uii_logstatusreg();

};

[mal abgesehen davon, dass ein & 48 auf 0 testen performanter gewesen wäre :-(, korrekt wäre aber & 53. Und warum erst auf == 0 testen, und dann das Ergebnis negieren? Warum nicht gleich der passende Vergleich?

Man sieht also: Manches wurde bereits in C umständlich gemacht. Dann ist kein Wunder, dass da auch umständliches Assembler rauskommt]

Man sieht im direkten Vergleich, dass es passieren kann, dass zu kurz gewartet wird. Weil gewartet wird, bis zu wenig Bits auf 0 stehen.

Ich habe da mal einen Bugreport gemacht: https://github.com/xahmol/GeoUTools/issues/1