Hallo Besucher, der Thread wurde 7,6k mal aufgerufen und enthält 95 Antworten

letzter Beitrag von uwe1972 am

WIP: geoULib - Assembler-Bibliothek für Ultimate-Programme

    Zitat von darkvision

    Der Pfad ist auch unabhängig vom FileBrowser in der Ultimate.

    Darauf wollte ich eigentlich nur hinweisen .

    Mach das mal am SD2IEC ;-) ...


    Zitat von darkvision

    wird man sehen wenn Du die Extended-Tools testest

    Ich hoffe, Du machst mich darauf aufmerksam, wenn ich mal wieder den Wald vor lauter Bäumen nicht sehe ... ;-) .


    Die nächsten 4 Demos:


    geoUMakeDir, geoUChDir, geoUPathUsb0 funktionieren.


    Bei geoUPathUsb1 bin ich nicht sicher ob das so gedacht ist. Das Prg meldet mir: "/Usb0/ 00,OK" . Müßte das nicht "/Usb1/ Fehler...!" sein, da Usb1 bei mir nicht belegt ist?


    Gruß

    Werner

    Zitat von wweicht

    Bei geoUPathUsb1 bin ich nicht sicher ob das so gedacht ist. Das Prg meldet mir: "/Usb0/ 00,OK" . Müßte das nicht "/Usb1/ Fehler...!" sein, da Usb1 bei mir nicht belegt ist?

    Ich hab im Demo keine Fehlerabfrage nach CD Usb1 drin... der CD-Befehl liefert aber einen Fehler wenn das Verzeichnis nicht existiert. Du kannst das mit geoUChDir testen wenn Du da als Ziel /Usb1 angibst. Ich werde für das Usb0/1-Demo die gleiche Statusbox einbauen, dann ist es klarer... Danke.

    Zitat von wweicht

    Ich hoffe, Du machst mich darauf aufmerksam, wenn ich mal wieder den Wald vor lauter Bäumen nicht sehe ... ;-) .

    Die zwei "Problemchen" die es gibt haben mit geoUFileStat und geoUDWrite5 zu tun. Wenn alles wie zu erwarten funktioniert oder wenn es anders läuft als gedacht, dann nicht weitersuchen ;)

    So... jetzt hab ich das geoUTestERAM-Tool fertig (läuft auch ohne Ultimate und erkennt auch CREU/GRAM gleichzeitig). Ein passendes Demo zum speichern hab ich auch geschrieben und das nächste "Problemchen" im UCI gefunden. Der DOS-Befehl kann keine 16Mb sichern, sondern nur 16Mb - 1Byte, weil man max. $FF:FFFF Bytes schreiben kann. Für 16Mb bräuchte es aber $0100:0000 und Laut UCI/DOS-Handbuch wird das höchste Byte ignoriert. Aus $0100:0000 wird also $00:0000 und dann speichert der Befehl gar nichts... (0-Byte-Datei).

    Das letzte Byte dürfte aktuell kein Problem sein... und man müsste mal testen ob man das letzte Byte nicht händisch noch anhängen kann. Noch ist das aber nicht nötig, zumindest MP3/GDOS64 hat in der letzten Bank noch ein paar freie Bytes am Ende...


    P.S. Kann natürlich sein das es nur bei V3.6 ein Problem ist. Hab da aber eine Sonderbehandlung drin das nur 16Mb -1Byte gespeichert werden, bei allen anderen Größen wird die vollständige Größe gespeichert (also wirklich die kompletten 8Mb oder 4Mb...)

    darkvision Das nehme ich mal als potentiellen Bugreport... Potentiell deswegen, weil noch incht verifiziert ist, ob der Bug in aktuellen Versionen noch drin ist.

    Zitat von markusC64

    darkvision Das nehme ich mal als potentiellen Bugreport... Potentiell deswegen, weil noch incht verifiziert ist, ob der Bug in aktuellen Versionen noch drin ist.

    Hilft das (filmanager/dos.cc) ?

    Code
    1. case DOS_CMD_SAVE_REU:
    2. ...
    3. addr = (((uint32_t) command->message[5]) << 24)
    4. | (((uint32_t) command->message[4]) << 16)
    5. | (((uint32_t) command->message[3]) << 8) | command->message[2];
    6. len = (((uint32_t) command->message[9]) << 24)
    7. | (((uint32_t) command->message[8]) << 16)
    8. | (((uint32_t) command->message[7]) << 8) | command->message[6];
    9. addr &= 0x00FFFFFF;
    10. len &= 0x00FFFFFF;

    Aus dem master-Branch... der letzte GIT-Download ist aber ein paar Tage her...

    Das sieht stark nach einem AND-Befehl aus.


    Aus dem Handbuch:

    Zitat

    The upper bytes of both the address as well as the length are masked out, thus effectively these bytes are dummy bytes.

    Also eigentlich so geplant...

    Zitat von darkvision

    len &= 0x00FFFFFF

    Kacke, das ist der Fehler. Als Workaround bietet es sich an, zwei Aufrufe der Funktion zu machen... Aber richtig gut ist das nicht, das sollte in der Firmware korrigiert werden. Ich nehme an, Du hast es eh bemerkt: Das ist ein AND auf der Länge...


    Wobei mich eigentlich noch was stört: Warum kann man nicht einfach befehlen: Bis zum Ende der REU?! Ja genau, das wäre doch was, was für die Praxis wirklich gut wäre.


    PS: Wenn Du noch was hast, was eindeutig ist - also mutmaßlich ohne Diskussion mit Gideon auskommt - dann kannst Du das gerne mitteilen. Man kann dann versuchen, das in der 3.10... (Buchstabe unbekannt) noch reinzubekommen.


    Edit: Ja, so geplant. Aber halt zu viel maskiert, wenn eine komplette REU speichern nicht mehr geht...

    Zitat von markusC64

    Wobei mich eigentlich noch was stört: Warum kann man nicht einfach befehlen: Bis zum Ende der REU?! Ja genau, das wäre doch was, was für die Praxis wirklich gut wäre.

    Man hätte den Befehl auch mit 24Bit schreiben können, erstes und letztes Byte das gespeichert werden soll (von-bis). Dann hätte $FF.FFFF gereicht.

    Oder mit $00:0000 die ganze REU schreiben, anstatt gar nichts zu schreiben... schon vor dem schreiben des Save-Tools hatte ich da bedenken, die Hoffnung das $00:0000 evtl. doch 16Mb speichert war dann aber schnell dahin.

    Wie oben geschrieben könnte man das fehlende Byte in einem zweiten Step noch anhängen. Vermutlich ist es aber einfacher zuerst das erste Byte zu senden, und dann grundsätzlich $xx:FFFF - $FF:FFFF Bytes zu schreiben.


    Gibt noch zwei Bugs... zumindest hier bei meiner Firmware, warten wir mal ab ob die Tester das mit 3.10 nachvollziehen können...


    P.S. Den "SAVE_REU"-Bug gibt es in der Form auch als LOAD_REU-"Bug"...

    Code
    1. case DOS_CMD_LOAD_REU:
    2. ...
    3. addr = (((uint32_t) command->message[5]) << 24)
    4. | (((uint32_t) command->message[4]) << 16)
    5. | (((uint32_t) command->message[3]) << 8) | command->message[2];
    6. len = (((uint32_t) command->message[9]) << 24)
    7. | (((uint32_t) command->message[8]) << 16)
    8. | (((uint32_t) command->message[7]) << 8) | command->message[6];
    9. addr &= 0x00FFFFFF;
    10. len &= 0x00FFFFFF;

    Nur der Vollständigkeit halber... man kann also auch gar keine 16Mb laden.

    Zitat von darkvision

    Man hätte den Befehl auch mit 24Bit schreiben können, erstes und letztes Byte das gespeichert werden soll (von-bis). Dann hätte $FF.FFFF gereicht.

    Yepp. Da aber 32 bit übergeben werden und dann ausmaskiert wird, bringt das keinen echten Vorteil. Ein Switch würde aber alle Programme brechen, die das benutzen...



    Man könnte sich aber vom Veralten von Perl's substr (substring) inspieren lassen, wobei man besser die kenntlich gemachte Änderung machen wollte...


    substr EXPR,OFFSET,LENGTH

    substr EXPR,OFFSET

    Extracts a substring out of EXPR and returns it. First character is at offset zero. If OFFSET is negative, starts that far back from the end of the string. If LENGTH is omitted, returns everything through the end of the string. If LENGTH is negative, leaves that [one less] many characters off the end of the string.


    Das hat den großen Vorteil, dass es nur sowieso nutzlose (weil ungültige) Werte mit einer sinnvollen Bedeutung belegt. "-1" als Länge heißt nach der modifizierten Bedeutung: Bis zum Ende der REU. -65537 64k weniger, dann sinnvoll, wenn man weiß, dass die REU ausschließlich das größtmögliche DNP beinhaltet.

    Zitat von markusC64

    Ein Switch würde aber alle Programme brechen, die das benutzen...

    Davon redet ja keiner... das hätte man von Anfang an Bedenken müssen. Jaja... ich weiß, Hätte Hätte Fahrradkette...... :Peace

    Zitat von markusC64

    -65537 64k weniger, dann sinnvoll, wenn man weiß, dass die REU ausschließlich das größtmögliche DNP beinhaltet.

    ? In der letzten Speicherbank liegen Systemdaten vom erweiterten GEOS-Kernal. Daher spielt der Bug momentan auch keine Rolle und keiner muss deswegen updaten: Wenn das letzte Byte fehlt hat das aktuell keinerlei Auswirkungen, könnte sich aber ändern.


    P.S. Das gilt natürlich nicht für andere Programme welche die REU evtl. zu 100% nutzen...

    Genau. Vorher machen ist nicht mehr möglich... allenfalls kann man noch jetzt nicht möglichen Werten eine sinnvolle Semantik geben.

    Zitat von darkvision

    ? In der letzten Speicherbank liegen Systemdaten vom erweiterten GEOS-Kernal. Daher spielt der Bug momentan auch keine Rolle und keiner muss deswegen updaten: Wenn das letzte Byte fehlt hat das aktuell keinerlei Auswirkungen, könnte sich aber ändern.


    P.S. Das gilt natürlich nicht für andere Programme welche die REU evtl. zu 100% nutzen...

    Ja, für Geos... Wobei ich mit dem Gedanken spiele, dass man eventuell einen GeoRAM Modus schaffen kann für GeoRAMs bus zu 1 MB, der parallel zur REU möglich ist. An der Stelle wäre es technisch möglich, den für andere Module vorgehaltenen Speicher zu nutzen - wenn man etwas Platz im FPGA dafür "opfern" will...


    UCI Planungen sollte man aber nicht nur für Geos machen, versteh das also als alternativen Anwendungsfall...

    Hat schon einer Deine Demo mit .d71 getestet?


    Ich habe gerade in dem Quelltext "src.geoULoadREU.s" geschaut und denke, der .d71 Fall ist da nicht passend drin:


    Code
    1. ldx geosDriveAdr ;Erste 64K-Speicherbank ist
    2. lda ramBase -8,x ;Startadresse RAMDisk.
    3. sta r1L
    5. jsr _UCID_LOAD_REU ;REU laden.

    Die d71 ist aber leider in der REU nicht ganz zusammenhängend gespeichert, was die Ultimate Firmware so behandelt:


    Zitat von markusC64

    Hat schon einer Deine Demo mit .d71 getestet?


    Ich habe gerade in dem Quelltext "src.geoULoadREU.s" geschaut und denke, der .d71 Fall ist da nicht passend drin:

    Ich selbst werde die Firmware nicht mehr updaten, kann das daher nur mit D64 testen. Aber jetzt wo Du es sagst:

    Die RAMLink verwendet den Offset 683, nur RAM71 nicht wegen GEOSV2. Das lässt sich anpassen... Danke.


    Zitat von markusC64

    UCI Planungen sollte man aber nicht nur für Geos machen, versteh das also als alternativen Anwendungsfall...

    Für mich ist da schon zu viel GEOS-spezifisches in der Firmware, aber das ist ein anderes Thema.

    Zitat von darkvision

    Ich selbst werde die Firmware nicht mehr updaten, kann das daher nur mit D64 testen.

    Das kann ich nur bedingt nachvollziehen. Wenn man das mit UCI über Datei öffnen, in die REU laden und Datei schloeßen macht, ist die Endung doch etwas, was nicht beachtet wird von der Firmware, außer zum Datei auffinden als Teil des Dateinamens.

    Ja es stimmt, die D71 gegenzutesten, das kann die Ultimate dann nicht bei alter Firmware. Aber das kann man am PC / am SD2IEC oder anders machen. In der Tat habe ich in der Ultimate durchaus schon einen SD-Kartenleser gesteckt, damit ich die SD-Karte dann problemlos zwischen SD2IEC und Ultimate umstecken kann.

    Zitat von markusC64

    Das kann ich nur bedingt nachvollziehen. Wenn man das mit UCI über Datei öffnen, in die REU laden und Datei schloeßen macht, ist die Endung doch etwas, was nicht beachtet wird von der Firmware, außer zum Datei auffinden als Teil des Dateinamens.

    Stimmt eigentlich... :platsch:

    Ich teste ja auch nur nach dem öffnen der Datei ob die Dateigröße passt... hab das wohl mit MOUNT verwechselt...


    Ich hab eben den Workaround für 1571 eingebaut, werde das morgen mal mit D71/D81 testen.

    Wieder zu den geoULib-Demo's ;-) :


    geoUReadDir funktioniert, die DB ist für 80-Zeichen nur zu schmal ;-) (man sieht aber, was gemeint ist)


    geoUFileInfo funktioniert


    geoUFileStat funktioniert (Firmware 3.10f) überhaupt nicht. Fehler: 82, FILE NOT FOUND

    Dabei ist es egal, ob das Image (hier MP3.D81) gemountet ist oder nicht.


    Gruß

    Werner


    Ergänzung: geoUFileSeek kann ich im Moment nicht testen (habe den Hinweis in der readme zu spät entdeckt ;-) ) . Habe hier nur D81 auf der 1541UII+ .

    Zitat von wweicht

    geoUFileStat funktioniert (Firmware 3.10f) überhaupt nicht. Fehler: 82, FILE NOT FOUND

    Dabei ist es egal, ob das Image (hier MP3.D81) gemountet ist oder nicht.

    Das ist nicht die Schuld von geoUFileStat, da ist ganz alleine die Firmware schuld ;)

    Für die beiden Befehle muss auch kein DiskImage gemounted sein, es muss nur eine gültige Datei sein.


    Danke, damit hast du den nächsten Bug in der Firmware bestätigt :thumbsup:


    Das Programm funktioniert nämlich sehr wohl. Wenn ich mein U64+GEOS neu starte und direkt geoUFileStat aufrufe, dann zeigt es mir die richtigen Informationen an. Nur wenn ich davor andere Demos ausführe die einen Pfad an das UCI senden (z.B. geoUDiskMnt oder geoUDWrite) dann funktioniert danach gar nichts mehr. Das UCI findet die Datei nicht mehr. Und wie Du bestätigt hast funktioniert geoUFileInfo dann sehr wohl noch, das die gleiche Datei ja über den gleichen Pfad öffnet.


    Eigentlich ist der Unterschied nur das FILE_INFO die Datei öffnet und von der geöffneten Datei die Infos anzeigt während FILE_STAT den Dateinamen verwendet um von der gewünschten Datei die Infos anzuzeigen.


    Es muss was mit dem übermitteln einen vollständigen Pfad zu tun haben, denn wenn ich z.B. nach einem Neustart geoUChDir und geoUDiskMnt verwende (ChDir wechselt nach /Usb0/ULIB) und im Mount-Demo keinen Pfad angebe (nur test.d64), dann tritt der Fehler nicht auf. Danach funktioniert FILE_STAT ohne Probleme... verwende ich in geoUDiskMnt wieder einen absoluten Pfad (/Usb0/ULIB/test.d64), dann findet FILE_STAT die Datei nicht mehr.


    Das hat mich einige Tage gekostet... Eigentlich kann ich auf FILE_STAT verzichten, allerdings kann man über FILE_INFO keine Verzeichnis-Informationen einlesen, der Befehl funktioniert nur bei Dateien.

    Zitat von darkvision

    denn wenn ich z.B. nach einem Neustart geoUChDir und geoUDiskMnt verwende (ChDir wechselt nach /Usb0/ULIB) und im Mount-Demo keinen Pfad angebe (nur test.d64), dann tritt der Fehler nicht auf.

    Das Ganze scheint aber irgendwie D64 only zu sein (UDiskMnt).

    Habe jetzt neu gestartet, mit UChDir (/usb0/d81) eingestellt, mit UDiskMnt (11:A:mp3.d81) ausgeführt und bekomme: FF,WRONG DISK FORMAT. Mit UDiskMnt habe ich mich noch nicht näher beschäftigt ....


    Gruß

    Werner

    Zitat von wweicht

    Das Ganze scheint aber irgendwie D64 only zu sein (UDiskMnt).

    Habe jetzt neu gestartet, mit UChDir (/usb0/d81) eingestellt, mit UDiskMnt (11:A:mp3.d81) ausgeführt und bekomme: FF,WRONG DISK FORMAT.

    Eigentlich nicht... ich teste aber die von FILE_INFO gemeldete Extension und die Dateigröße. Beides muss passen, sonst gebe ich den Fehler FF zurück. Kannst Du bitte mal geoUFileInfo mit dem Pfad /Usb0/d81/mp3.d81 aufrufen und einen Screenshot machen? Das sind die Daten die ich für den Vergleich verwende...

    Also die Extension passt und die Größe auch.... muss ich mal sehn was da schief läuft.


    Hattest Du die geoUDWrite-Demos schon getestet? Ja, ich weiß, 40Z... aber den Grafikbildschirm für den Write-Test zu verwenden hat bei geoUDRead dann den Vorteil das man gleich sieht ob alles funktioniert hat.