Hello, Guest the thread was viewed35k times and contains 557 replies

last post from wweicht at the

News zur Ultimate 1541 II+ und Geos

    Quote from C=Mac

    GDos:

    Programm lässt sich starten, klick ich irgendetwas an friert das Programm ein.

    Kann ich bestätigen... heute den ersten neuen Testbuild zu GDOS64 auf dem U64 getestet... Freeze wenn ich auf Home oder Root klicke...

    Quote from C=Mac

    Beim ersten Öffnen ist das Programm auch nicht im "Root" sondern irgendwo.

    Ich war zuerst auf / ... dann hab ich im Ultimate /usb0 als "Home" gesetzt und neu gestartet, dann startet geoUMount in /Usb0. Also das funktioniert hier.

    Quote from markusC64

    Oh nö...

    Ähm doch ;) Ich hab das Programm mal unter VICE laufen lassen, SetValidDrives und die beiden Fehlerabfragen ignoriert. Klicke ich dann auf Home kann ich den Ablauf bis zurück zur Mainloop verfolgen. Also Grundsätzlich scheint es auch unter GDOS zu funktionieren. Es kann aber sein das entweder bei SetValidDrives oder ReadDir/PrintDir irgendwo wieder ein Speicherüberlauf auftritt oder irgendwo Anwendungsspeicher überschrieben wird, genauso wie bei den bisherigen "Fehlerbildern" auch.

    Quote from markusC64

    Das muss von der seltsamen Cross Compiling Toolchain kommen, die ich noch immer nicht zum Laufen bekommen habe.

    Ich finde den Ansatz mit cc65 sowieso fragwürdig. Extrem aufgebläht... durch den internen Stack (Heap?) auch deutlich langsamer als notwendig, und im cc65-Ergebniss sehr umständlich in Assembler umgesetzt. Das alles macht dann die Fehlersuche (für mich) auch nicht gerade einfach.

    Vielleicht fällt mir noch was ein, aber irgendwann muss man da halt einfach die Reisleine ziehen, dann läuft das Programm halt nicht unter GDOS64. Soweit ich das verstanden habe braucht man es da auch gar nicht.

    Quote from uwe1972

    Scheinbar gibt es aber nur die Möglichkeit A oder B zu Mounten

    Echt? Dann muss ich als nächsten Test mal eine emulierte Floppy auf C oder D konfigurieren - mal sehen, was er genau macht.

    Habe gerade von Laufwerk C gemounted.


    uwe1972 Da muss ein anderes interssantes Problem vorliegen. Details zur Installation?


    Ich bin aber gerade über ein anderes Problem gestolpert: Zum Test habe ich auf C eine 1571 konfiguriert - per Ultimate 64 geht das ja einfach. Und in der konnte ich dann mit GeoUmount nur .d71 Dateien einlegen, ich hätte aber gerne eine .d64 eingelegt. :-(


    Und .g64 btw. .g71 gehen gar nicht,m egal welches Laufwerk. Ich glaube, ich muss im Github das noch schreiben.

    Na, Gut, also genau:


    C64 mit Ultimate (D:-Ram 1581) MP3 mit Desk Top

    A/B 1581 SD-LW (A:Boot-LW)

    C: FD 1581

    D: Ram Ultimate 1581


    ergibt sich bei meiner Konfiguration also nur die Möglichkeit D zu Mounten.

    aber das geht nicht, bei C & D steht "No Target" ich kann zwar auf D klicken,

    aber bekomme keine Reaktion..............

    FD is klar, aber D ist ja eine D81Ram, scheint als würde sie nicht erkannt.........


    Programm von A/B gestartet, selbiges Ergebnis

    Mache ich was falsch??


    PS. Unter GeoDos ----- geht GarNix=Absturz

    Da mir nicht klar ist, was bei Dir C ist, käme allenfalls C in Frage, oder gar keins.


    Denn mounten kann man nur in die Laufwerke, die die Ultimate bereitstellt, also emulierte 1541, 1571 oder 1581. Und da gibt der Text nicht her, ob C eine echte 1581 oder eine von der Ultimate emulierte ist (von anderen Geräten emulierte 1581 sind hier wie echte 1581 zu behandeln).


    Ja, wegen GDOS, das habe ich hier bereits mehrfach gelesen - muss ich selbst ausprobieren. Sollten wir im github reporten.

    Jedoch reporte ich selten etwas, was ich nicht selber ausprobiert habe... daher habe ich dazu im github nichts geschrieben.

    Nein, RAMDISKs gehen derzeit nicht. Ein Update, welches aber auch eine aktualisierte Ultimate 64 / 1541 Ultimate II(+) Firmware benötigen wird, ist zwar eingeplant, aber von eingeplant hat man nichts.


    Muss schone ine echte emulierte Floppy sein, also eine solche, die auch außerhalb von Geos verfügbar ist - und eine echte Gerätenummer am IEC Bus hat. Also auch nicht das IEC Device, welches die Ultiamte emulierren kann, denn die ist keine Floppy, sondern eher was in Richtung SD2IEC...

    In der Tat, GDOS stürzt mit GeoUMount ab. Nach dem Laden istz es noch bedienbar, findet aber keine Dateien. Und sobald man das Verzeichnis bspw. auf die Root wechseln will, crashed alles.


    Ich habe die Ultimate 64 einfach mal den Speicherinhalt des C64 direkt nach dem Laden von GeoUmount speichern lassen und dann nochmal nach dem Crash.


    Interesaant wäre jetzt mal die Frage, ob man mit wenig Aufwand feststellen kann, ob da irgendwas überschrieben ist...


    Edit: Macht das eigentlich was aus, dass die Endadresse im Infoblock als $03FF angegeben ist, und die Startadresse = $0400? Also Endadresse < Startadresse, was an sich merkwürdig ist.


    Edit 2: Ich gebe mir die Antwort vorläufig selbst: Anscheinend nicht, der Bereich ab $0400 ist identisch mit dem, den ich beim Speichern des C64 RAMs aus MP3 heraus bekomme... erst bei den ersten Variablen unterscheidet es sich.

    Quote from uwe1972

    Scheinbar gibt es aber nur die Möglichkeit A oder B zu Mounten

    Bei mir gehen A und C.

    A= U-81

    C= U-41


    Quote from markusC64

    Und in der konnte ich dann mit GeoUmount nur .d71 Dateien einlegen, ich hätte aber gerne eine .d64 eingelegt.

    Naja eine 1571 ist keine 1541 :D

    Wahrscheinlich ist die Filterfunktion ganz einfach gestricht: 1571 = D71, 1581 = D81 und 1541 = D64.

    Das 1541 Disketten (D64) auch in der 1571 (D71) laufen, hat man vergessen.


    Quote from uwe1972

    C64 mit Ultimate (D:-Ram 1581) MP3 mit Desk Top

    A/B 1581 SD-LW (A:Boot-LW)

    C: FD 1581

    D: Ram Ultimate 1581

    Lese ich jetzt falsch?

    Hier wird ja kein LfW durch die Ultimate emuliert.

    GeoUMount ist dafür gedacht die "Disketten" bei emulierten LfW der Ultimate zu wechseln.


    Bei SD2IEC's können die "Disketten" von TopDesk, GeoDesk und GDos selber gewechselt werden, da braucht es GeoUMount nicht.


    Quote from darkvision

    Vielleicht fällt mir noch was ein, aber irgendwann muss man da halt einfach die Reisleine ziehen, dann läuft das Programm halt nicht unter GDOS64. Soweit ich das verstanden habe braucht man es da auch gar nicht.

    Naja wäre wohl eher die Aufgabe des Programmierer von GeoUMount und ja ich bin der Ansicht beim C64 braucht es das Programm nicht, da ist der Griff zum Taster der Ultimate schneller.


    Gruss C=Mac.

    Quote from C=Mac

    Naja eine 1571 ist keine 1541 :D

    Wahrscheinlich ist die Filterfunktion ganz einfach gestricht: 1571 = D71, 1581 = D81 und 1541 = D64.

    Das 1541 Disketten (D64) auch in der 1571 (D71) laufen, hat man vergessen.

    Er hat versprochen, nachzubessern:


    Quote

    Good one.

    Always only considered .d71s for a 1571. And never thought of .g64s. Good news is that it should be an easy fix, just expand the filter criteria.

    Thanks for pointing it out, will be tomorrow though before I have time for a fix.

    Ist es möglich, was etwas durcheinander ist?


    Die Ultimate II+ kann die Commodore LfW 1541, 1571 und 1581 emulieren, davon zwei Stück gleichzeitig.

    Will man die "Diskette" bzw. das Image wechseln, muss man die mittlere Taste der Ultimate drücken und mit dem Cursor das gewünschte Image auswählen und bestätigen.

    GeoUMount macht diesen Prozess per Programm, man muss die Taste nicht benutzen.


    GeoUMount macht nichts mit dem SD2IEC, RAM-LfW oder echten LfW.


    Gruss C=Mac.

    Quote from markusC64

    Ich habe die Ultimate 64 einfach mal den Speicherinhalt des C64 direkt nach dem Laden von GeoUmount speichern lassen und dann nochmal nach dem Crash.

    Direkt nachdem GEOS geoUMount ab $0400 gestartet hat? Es wäre wichtig zu wissen wie der Speicher direkt nach dem laden aussieht, *bevor* irgendwelcher Code ausgeführt wird. Es müssen danach mind. 2 Bytes ab ~$1b80 verändert sein, da hier CPU_DATA und Prozessorstatus von enableIO gespeichert werden.

    Quote from uwe1972

    Aber was für ein LW-Typ muß ich nun einstellen, damit es über das Pro klappt ??

    Unter GEOS als 1541/71/81-Laufwerk, damit Du auch das interne Laufwerk der Ultimate ansprechen kannst.


    Die Laufwerke der Ultimate emulieren ein echtes 1541/71/81-Laufwerk, d.h. wenn Du z.B. im SETUP der Ultimate ein Laufwerk A als 1541/Device11 (oder so ähnlich...) anmeldest, dann kannst Du das Laufwerk auch unter BASIC mit LOAD"$",11 ansprechen, auch wenn an Deinem seriellen Bus kein echtes Laufwerk#11 hängt (darf es auch nicht, weil es sonst zwei Geräte mit gleicher ID gäbe).

    Quote from darkvision

    Direkt nachdem GEOS geoUMount ab $0400 gestartet hat?

    Natürlich nicht, ich schaffe es per Hand nicht, Mikrosekundengenau die U64 manuell anzuhalten - automatisch ist da nichts.

    Und zum Debugstream auswerten gibt es genau 0 Programme...

    Quote from markusC64

    Natürlich nicht, ich schaffe es per Hand nicht, Mikrosekundengenau die U64 manuell anzuhalten - automatisch ist da nichts.

    Und zum Debugstream auswerten gibt es genau 0 Programme...

    OK... aber beim ScreenSize-Bug wurde das RAM ja schon beim Bildaufbau überschrieben, und wenn Du keine Unterschiede zwischen vor- und nach dem Klick festgestellt hast, dann könnte es schon zu spät gewesen sein (wie gesagt, einige Routinen schreiben auch nach $0400-~$3xxx).


    Ich schau am WE mal ob ich den Fehler auch mit einer älteren Version nachstellen kann. In der kann ich nämlich im AssemblerCode ein paar Haltepunkte setzen, weil ich das ja direkt unter GEOS wieder assemblieren kann. Allerdings hat das bei mir zwischenzeitlich eine geringere Priorität...


    P.S. Ich will nicht ausschließen das es ein gänzlich anderes Problem ist. Aber so ein Freeze nachdem man ein Icon angeklickt hat ist schon merkwürdig, wenn das gleiche Programm unter MP64 läuft.

    Ich habe da noch eine Idee - vorausgesetzt, man bekommt die Toolchain am Laufen, so könnte man die UCI Operationen durch Dummies ersetzen und hoffen, dass das Problem noch immer auftritt.


    Wenn ja, dann hätte man den Jackpot: Man kann den VICE Monitor nehmen zum Anschauen.



    Quote from darkvision

    und wenn Du keine Unterschiede zwischen vor- und nach dem Klick festgestellt hast, dann könnte es schon zu spät gewesen sein (wie gesagt, einige Routinen schreiben auch nach $0400-~$3xxx).

    Ja richtig, aber wenn man dann noch eine Referenz von dem Programm unter MP3 hinzunimmt... kann natürlich den Teil, der Variablen zu sein scheint falsch eingeschätzt haben... aber ein Vergleich mit MP3, wo es funktioniert, ist zumindest geeignet, ein Überschreiben aufzudecken.



    Quote from darkvision

    Aber so ein Freeze nachdem man ein Icon angeklickt hat ist schon merkwürdig, wenn das gleiche Programm unter MP64 läuft.

    Eben. Könnte natürlich was überschreiben. Ich frage mich, können wir ausschließen, dass eine GDOS-Funktion das Einblenden von I/O wieder rücknimmt, während MP3 das nicht macht?


    Wenn ja, müsste man mal prüfen, ob IO immer so kurz wie möglich eingeblendet wird oder ob da mehr drunter gemacht wird mit MP3/GDOS Funktionen.

    Wenn IO nämlich nicht eingeblendet ist, kann das RAM darunter ja überschrieben werden... wierder ein Kandidat, der überschrieben werden kann.

    Quote from markusC64

    Ich frage mich, können wir ausschließen, dass eine GDOS-Funktion das Einblenden von I/O wieder rücknimmt, während MP3 das nicht macht?

    Es werden ja so gut wie keine GEOS-Routinen aufgerufen, und die paar Routinen sind da eher unkritisch. Es werden z.B. keine DIsk-Routinen aufgerufen. Lediglich diese hier:

    Davon ruft keine Routine InitForIO auf. Die MainLoop aktiviert zwar kurz den IO-Bereich, da ist aber geoUMount inaktiv und wartet auf Mauseingaben. Das ist bei MP3 aber auch so. Wenn GeoUMount den IRQ sperrt greift auch GEOS nicht mehr auf den I/O-Bereich zu.


    Ich vermute nach ein paar Stunden Suche das Problem an anderer Stelle, was die Sache nicht klarer werden lässt.


    Ich hab mir am U64 einen Freezer eingerichtet und nachdem GDOS64 hängt das Freezer-Menü/Monitor gestartet. Über die letzten Bytes auf dem Stack hab ich die letzte Hauptroutine gesucht, in meinem Fall hier uii_sendcommand. Das Programm scheint auf eine Rückmeldung zu warten die nicht kommt und hängt dann in einer Endlosschleife (Wie war das mit der Abbruch-Funktion in Warteschleifen? :thumbup: )


    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!


    Da muss aber noch was anderes mitspielen. Bei mir erscheint unter GDOS immer "No data". Wenn ich unter MP3 starte kommt im /-Verzeichnis "Usb0" und ich kann navigieren. Unter GDOS wird mir nie etwas angezeigt, auch wenn d64/D64 enthalten sind.


    Ich müsste jetzt weitersuchen wann ReadDir abbricht, da scheint es ja nur zwei Bedingungen zu geben Keine Daten oder Speicher voll. Aber für heute reicht es...


    P.S. Kleiner Nachtrag: Die ID (DOS-Version) und der aktuelle HOME-Pfad werden noch korrekt angezeigt. Wenn ich über das Ultimate-Menü einen anderen HOME-Pfad setze und im Programm "Home" klicke wird der korrekt angezeigt. Aber selbst in ROOT wird mir nicht das usb0-Verzeichnis angezeigt, nur "No data". Vermutlich sind die Freezes in GDOS64 bei HOME/ROOT nur Symptome, die Ursache liegt ganz woanders...