Hello, Guest the thread was viewed6k times and contains 95 replies

last post from uwe1972 at the

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

    Wie im Thread "News zur Ultimate 1541 II+ und Geos" angedeutet hab ich vor eine kleine Assembler-Bibliothek zu schreiben mit der man das Ultimate-DOS ansteuern kann.


    Um mich zuerst mal mit den wichtigsten Routinen vertraut zu machen hab ich die Aufgabe von hier mal als Demo umgesetzt. Also ein DeskAccessory welches das Ultimate-Menü startet.


    Ich hab das jetzt nur kurz unter GDOS64 getestet... da startet das Menü ganz zuverlässig.

    GEOS128 kann ich nicht testen, da die Hardware fehlt. Daher hab ich keine Ahnung was unter GEOS128 passiert ;)

    Es wird aber InitForIO verwendet, das setzt den 1MHz-Modus, zumindest auf realen Laufwerken. Allerdings nicht bei einer RAMDisk, daher muss hier CLKRATE zur Sicherheit immer auf $00 gesetzt werden. Da gäbe es noch Potential für Optimierungen.


    Hier im Anhang das erste D64 zum testen...


    Wenn das so vom Grundsatz her funktioniert würde ich die geoULib anfangen und die wichtigsten Befehle zur Ansteuerung der Ultimate integrieren.

    Quote from darkvision

    Also ein DeskAccessory welches das Ultimate-Menü startet.

    Das Prg würde jeweils von B:RAM gestartet.


    Geos 64 V2.x - A:1581 (SD2IEC) B:RAM1581 funktioniert

    Geos128 V2.x - A:1581 (SD2IEC) B:RAM1581 Absturz

    (zur Erklärung: Geos128 friert ein, wenn man auf 40-Zeichen umschaltet, ist das Ultimate-Menü da und arbeitet. Nach dem Beenden des Ultimate-Menüs erscheint auf dem 80-Zeichen-Bildschirm ein buntes Durcheinander. Einzige Lösung: RESET am C128DCR auslösen, dann rebootet Geos 128)


    MP3-64 - A:1581 (SD2IEC) B:RAM1581 funktioniert

    MP3-128 - A:1581 (SD2IEC) B:RAM1581 funktioniert


    MP3-64 - A:Native (SD2IEC) B:RAM1581 funktioniert

    MP3-128 - A:Native (SD2IEC) B:RAMNative funktioniert


    Gruß

    Werner

    Quote from wweicht

    Das Prg würde jeweils von B:RAM gestartet.


    Geos 64 V2.x - A:1581 (SD2IEC) B:RAM1581 funktioniert

    Geos128 V2.x - A:1581 (SD2IEC) B:RAM1581 Absturz

    (zur Erklärung: Geos128 friert ein, wenn man auf 40-Zeichen umschaltet, ist das Ultimate-Menü da und arbeitet. Nach dem Beenden des Ultimate-Menüs erscheint auf dem 80-Zeichen-Bildschirm ein buntes Durcheinander. Einzige Lösung: RESET am C128DCR auslösen, dann rebootet Geos 128)

    Ei der daus, bei mir ist unter Geos 128 2.0 Laufwerk A eine 1571. Laufwerk B eine RAMDISK. Da hat es wie gewünscht funktioniert. Sowohl im 40 als auch im 80 Zeichenmodus. Alles bedienbar, TUI der Ultimate korrekt dargestellt. Alles gut.

    Ich kann ja mal per Konfigurieren, was ich vorher auf die RAMDISK kopiere, den Typ von Laufwerk A änedrn (im 40 Zeichen Modus bekomme ich ja parallel den emulierten Laufwerkstyp mit geändert).


    Ach ja, auch wenn einige das bereits wissen bzw. erraten haben: Ich habe Firmware 3.10f (nightly snapshot).



    Edit: Auch dann geht es. Startdiskette war eine nicht modifizierte Geos 128 2.0 (natürlich installiert) - also so wie in der Wolke und so, wie original ausgeliefert.


    Edit 2: Firmware 3.10f hat einige Timinganpassungen, speziell für den C128. Weiß nicht, ob es da einen Zusammenhang gibt, wäre aber möglich.

    Quote from darkvision

    Danke fürs testen.

    Kein Problem ;-) .


    Aber es gibt eine kleine Korrektur meinerseits:


    Geos 128 im 1. Versuch war mit dem letztem TopDesk (V3.irgendwas) für Geos128. Habe das jetzt nochmal wiederholt mit dem originalen 128 DESKTOP in gleicher Konfiguration. Da funktioniert es auch mit Geos 128 deutsch ohne Absturz. Also wohl ein TD-Problem.


    Quote from darkvision

    D.h. man muss trotzdem auf 40Z umschalten um das Ultimate-Menü zu sehen

    Ja, das gibt es nur auf 40 Zeichen. Hier bei mir muß ich so oder so den Monitor umstellen, sonst sehe ich das nur eingefrorene 80-Zeichen-Bild ;-) ....


    Quote from markusC64

    Startdiskette war eine nicht modifizierte Geos 128 2.0 (natürlich installiert)

    Wie gesagt, wird irgendwie an 128 TopDesk V3 liegen ...


    Gruß

    Werner

    Quote from wweicht

    Ja, das gibt es nur auf 40 Zeichen. Hier bei mir muß ich so oder so den Monitor umstellen, sonst sehe ich das nur eingefrorene 80-Zeichen-Bild ;-) ....

    OK... dann wäre es evtl. hilfreich ich blende eine Dialogbox ein "Bitte auf 40Z-Monitor wechseln um das Ultimate-Menü zu bedienen"... dann weiß man wenigstens das der Rechner nicht abgestürzt ist.


    Das sollte noch machbar sein.


    Dann scheint das UCI-Handling ja zu funktionieren. Da war ja schon die U-Erkennung enthalten, UCI_ABORT, UCI_WAIT_IDLE usw... ich schaue da nochmal auf den Code, evtl. ersetze ich InitForIO doch durch was eigenes.


    Aber dann kann ich ja mit der Bibliothek anfangen und die Befehle nach und nach einbauen. Unter BASIC hab ich schon die meisten Befehle getestet, inkl. LOAD_TO_REU. Das sollte dann alles kein Problem mehr sein.

    Quote from wweicht

    ... und wieder ein Klick mehr nötig ;-) .

    Ich meine ich hab schon Dialogboxen programmiert die sich selbst beendet haben :gruebel


    Ah jaa.... bei geoHDscsi z.B. wenn die SCSI-Geräte gesucht werden... oder wenn die SCSI-ID gewechselt wird. Da verschwindet die Dialogbox von selbst nachdem die eigentliche Aufgabe beendet wurde.


    Aber wenn es nicht nötig ist... spart mir einiges an Arbeit ;)

    Tach,


    Ich habe das DeskAccessory heute getestet, ich bin Begeistert :thumbsup:

    Ist Eigentlich genau das richtige, den armen Resettaster meiner Ultimate

    zu schonen..............


    Es Funktioniert & macht genau, was es soll, keine Hänger oä. :ilikeit:


    Falls es von Interesse sein sollte,, ich hab mal einige Icons für das DeskAccessory gezeichnet, ich hänge das D81 mal dran, Evl. gefällt ja das eine oder andere.......:?:


    Programmiertechnisch kann ich leider Nix dazu beitragen.............


    Viel Spaß

    Nicht das der Eindruck entsteht hier würde sich nichts mehr tun... ist halt nur Fleißarbeit die Routinen des UCI in die ULib zu integrieren. Und da ich zu jeder Routine auch für Programmierer ein kleines Assembler-Beispiel als App schreibe dauert das halt... ;)


    Heute kam die erste der "höheren" Routinen dran... DOS_CMD_LOAD_REU. Damit kann man den Inhalt einer Datei in die REU laden. Als kleine Demo-App hab ich ein AutoExec geschrieben, das ein DiskImage vom USB-Stick beim booten von GEOS in eine RAMDisk lädt. Nichts weltbewegendes, aber hat (bis auf ein paar dämliche Typos) sofort funktioniert. Kann ich natürlich nur mit D64 testen, sollte aber auch mit D71/D81/DNP funktionieren. GEOS-Laufwerk und Pfad zum DiskImage werden im Infoblock definiert, kein Komfort mit Dateiauswahl... ist ja nur eine Demo für Programmierer wie man die ULib benutzt.


    Geht aber nur mit REU, nicht mit GeoRAM. Wie markusC64 in einem anderen Thread erwähnt hat evtl. wegen der nicht linearen Speicherung im GeoRAM. Allerdings ist die GeoRAM unter GDOS64 auch spürbar langsamer... wer nutzt das freiwillig? ;) Auf weitere Tests hab ich daher verzichtet...


    Alles in allem scheinen die Kern-Funktionen stabil zu funktionieren. Das einfügen der weiteren UCI-Befehle dürfte weniger ein Problem sein, eher die fehlende Doku. Einige Informationen musste ich mir aus dem SourceCode der Firmware herauslesen, und ich kann kein C :(

    Bei einigen Angaben konnte ich aber zum Glück auf das Wissen aus GeoDOS64 von vor 25Jahren zurückgreifen als ich die DOS-Treiber entwickelt habe. Hätte nicht gedacht das ich das Grundlagenwissen von damals nochmals brauchen werde, einiges konnte ich sogar per Copy'n'Paste übernehmen :D


    Was sicherlich mehr Zeit in Anspruch nimmt sind die Demo-Anwendungen. Die meisten sind für Anwender Sinnlos... aber geoUFreeze, geoUReboot, geoUGetTime und geoULoadREU sind jetzt schon funktional und, wenn es keine Fehler gibt, können auch genutzt werden. geoUFileInfo, geoUDiskMnt und geoUDiskUMnt sind als Beispiel vorhanden, verwenden aber als Demo ein fixes Laufwerk bzw. Dateiname für den Vorgang, also nur in einen bestimmten Szenario nutzbar. Aber es sind und bleiben alles Demo-Anwendungen, die nur als Beispiel für Programmierer dienen sollen.


    Als nächstes kommt vermutlich DOS_CMD_SAVE_REU dran. Dann reicht ein Mausklick um den Inhalt eines RAM-Laufwerks in einem bestimmten DiskImage zu speichern. Wenn mir die alte Firmware da keinen Strich durch die Rechnung macht...


    Bis die ULib fertig ist wird es aber trotzdem noch etwas dauern... nutzen wird das vermutlich niemand, evtl. landen ein paar Testroutinen in GDOS64... vollständiger Support wie beim SD2IEC ist aber ausgeschlossen. Dafür gibt es bereits andere Programme...

    Quote from darkvision

    Geht aber nur mit REU, nicht mit GeoRAM. Wie markusC64 in einem anderen Thread erwähnt hat evtl. wegen der nicht linearen Speicherung im GeoRAM. Allerdings ist die GeoRAM unter GDOS64 auch spürbar langsamer... wer nutzt das freiwillig? ;) Auf weitere Tests hab ich daher verzichtet...

    Du sagst es, mit GeoRAM sehe ich deswegen auch nicht als so wichtig an. Aber mit einem GeoRAM, welches höchstens 4 MB groß ist, könnte es dennoch gehen. Zumindest bei Deiner alten Firmware.

    Die aktuelel Firmware hat ein Problem, dass UCI und GeoRAM fälschlicherweise in Konflikt stehen. Ich hoffe, dass ich das diese Woche korrigiert bekomme.

    Quote from darkvision

    Als nächstes kommt vermutlich DOS_CMD_SAVE_REU dran. Dann reicht ein Mausklick um den Inhalt eines RAM-Laufwerks in einem bestimmten DiskImage zu speichern.

    Ja, wenn man das so Lowlevel macht, dass der C64 Code alle REU-Adressberechnungen macht, dann sollte sogar die alte Firmware reichen. Man verliert dafür, dass eine zentrale Stelle (Firmware) gleich alle Anwendungen zu einer weiteren GEOS-Version kompatibel macht - falls notwendig.

    Quote from markusC64

    Aber mit einem GeoRAM, welches höchstens 4 MB groß ist, könnte es dennoch gehen. Zumindest bei Deiner alten Firmware.

    Ja, ich hatte 16Mb eingestellt. Du hattest ja geschrieben das eine kleine Größe funktionieren könnte. Aber das ist so schnarchlangsam... da hab ich auf den 4Mb-Test verzichtet...


    Quote from markusC64

    Ja, wenn man das so Lowlevel macht, dass der C64 Code alle REU-Adressberechnungen macht, dann sollte sogar die alte Firmware reichen. Man verliert dafür, dass eine zentrale Stelle (Firmware) gleich alle Anwendungen zu einer weiteren GEOS-Version kompatibel macht - falls notwendig.

    Sorry... da hab ich meine eigene, völlig andere Meinung dazu... ist hier aber OffTopic.


    Nein... ich werde garantiert keine höhere Firmware-Version voraussetzen. Was nicht geht, geht halt nicht... es hindert aber keinen Programmierer daran die neueren Funktionen zu nutzen. Die ULib hat dann soviel Code als Beispiel das man das leicht für weitere UCI-Befehle anpassen kann.

    Quote from darkvision

    Allerdings ist die GeoRAM unter GDOS64 auch spürbar langsamer... wer nutzt das freiwillig?

    Nicht nur in GDOS64 ;-) . Gilt auch schon in Geos. Denke da z.B. an Sachen wie RamProzess ...


    Meine erste RAM-Erweiterung Anfang der 1990er war eine 512 kB GeoRAM (damals war die CBM-REU nicht mehr lieferbar). Als dann später doch wieder CBM-REUs zur Verfügung standen, habe ich mir eine (ebenfalls 512 kB) gekauft und doch gestaunt wie viel schneller sie im direkten Vergleich zur GeoRAM war.

    Das nur, weil es immer mal wieder Leute gibt die diesen Fakt anzweifeln ;-) .

    Aus Anwender-Sicht 100% Unterstützung!


    Aber für Tester wie mich ist sie schon "notwendig" um z.B. Sachen wie MP3-64/128 auch auf GeoRAM zu testen (z.B. den GeoRAM Native RAM-Treiber) ;-) .


    Quote from markusC64

    Problem, dass UCI und GeoRAM fälschlicherweise in Konflikt stehen. Ich hoffe, dass ich das diese Woche korrigiert bekomme

    Das hellt meine momentane Stimmung in Bezug auf 1541UII+ schon ein wenig auf. Hoffe nur, daß das dann auch zeitnah irgendwie veröffentlicht wird ;-) .



    Ja, ich halte schon die Klappe ;-) , gehört nicht zum Thema hier ...


    Gruß

    Werner

    Quote from wweicht

    Das hellt meine momentane Stimmung in Bezug auf 1541UII+ schon ein wenig auf. Hoffe nur, daß das dann auch zeitnah irgendwie veröffentlicht wird ;-) .

    Fehler bereits gefunden - und habe auf dem U64 eine korrigierte Version am Laufen (gehabt). Musste aber zurückflashen, weil ich von Gideons Build noch den FPGA auslesen muss.

    Nach ein paar Wochen Arbeit ist die geoULib jetzt fast fertig.



    Ich hab mich jetzt intensiv mit dem UCI beschäftigt. Die UCI-Doku scheint unvollständig bis stellenweise fehlerhaft, Designfehler hier und da und evtl. Fehler in der Firmware (zumindest in v3.6a). Mit den Demo-Apps könnte man testen ob die Fehler in der aktuellen Firmware beseitigt wurden, aber das ist nicht mein Ziel. Ich hab mir nicht mal alle Probleme gemerkt, sondern einfach die geoUlib so entwickelt das alle Routinen mit v3.6a funktionieren. MOUNT/FILE_STAT/RENAME/COPY waren die größten Baustellen.


    Gibt aber auch positives (für Programmierer): Es gibt ein undokumentiertes Feature im UCI. Ist zwar kein "Ding"... aber in der dürftigen Doku nicht beschrieben, aber dennoch vorhanden...


    Ich muss den Code noch etwas aufräumen und dokumentieren, dann schiebe ich das Update auf die Area6510... beim C128 kann es noch zu Problemen kommen da ich die IO-Routine angepasst habe.

    Ich hab heute die geoUlib auf die AREA6510 hochgeladen und eben noch aus gegebenem Anlass die Funktion "DOS_CMD_SET_TIME" in die geoUlib integriert. Damit kann man die Zeit im Ultimate setzen, das hat aber nichts mit NTP zu tun ;) Das Testprogramm kopiert die GEOS-Zeit auf die Ultimate und gibt einen Fehler aus wenn die erforderliche Option dafür im Ultimate-Menü nicht aktiv ist.


    Ich hänge mal das D64 mit allen Demo-Tools an. Wie oben geschrieben hab ich die I/O-Routinen und die Timeout-Routinen angepasst. Es kann daher sein das die Demos am C128 oder an einem Ultimate64 mit Turbofunktion nicht funktionieren. Und die Demo-Tools sollen Programmierern nur helfen zu verstehen wie man die geoULib in eigene Programme einbindet bzw. man kann damit die UCI-Befehle testen.


    Einige der Testprogramme muss man vorher konfigurieren (Alles unterhalb von "EXTENDED" auf der Disk), die anderen kann man starten und bekommt das Ergebnis der UCI-Funktion angezeigt. Wie die Extended-Demos zu konfigurieren sind kann man dem Infotext entnehmen (dort muss man auch die Konfiguration eintragen) oder hier nachlesen.


    Für Anwender ist da nicht viel dabei, außer geoUFreeze , geoRBoot (Neustart), geoULoadREU (AutoExec um beim booten eine RAMDisk mit einem DiskImage zu befüllen wenn im Infotext eine gültige Konfiguration vorliegt. Nur mit D64 getestet, D71/81/DNP könnte aber auch klappen... kann man auch vom DeskTop starten. Achtung! Unbedingt Daten sichern ;) ). geoUGetTime ist zwar auch ein AutoExec, aber es gibt da ja bereits geoCham64RTC+.


    Was mich am meisten interessieren würde (falls sich freiwillige Tester für die Demos finden): Funktioniert das schreiben von Daten in eine Datei und das anschließende Auslesen mit der aktuellen Firmware?


    Dazu gibts es die vier Testprogramme "geoUDWrite2/5/8" und "geoUDRead". In allen vier Programmen muss man im Infotext ganz am Anfang den Pfad zu einer Testdatei angeben, die für den Test verwendet werden kann (z.B. /Usb0/testfile - Wird überschrieben!).

    Danach startet man geoUWrite2, dann wird ein Testmuster auf dem 40Z-Bildschirm (ja, nur 40Z-Modus!) gezeichnet und eine Statusmeldung angezeigt. Da muss in jedem Fall "00,OK" angezeigt werden. Wird gar nichts angezeigt wäre das ein Anzeichen dafür das mein Timeout zu schnell reagiert. Hier am C64 mit U64 ohne Turbo-Firmware kommt das OK.

    Danach startet man "geoUDRead". Das Programm ließt das Ergebnis aus der Testdatei auf dem 40Z-Bildschirm ein, es sollte also das gleiche Muster wieder angezeigt werden wie beim speichern.


    Von den drei Write-Programmen DWrite2, DWrite5 und DWrite8 klappt das nur bei 2 und 8... 5 liefert hier nur Grafikmüll. Ich gehe mal davon aus das auf der aktuellen Firmware alle drei funktionieren. Da ich einen Verdacht habe warum das bei mir so ist kann ich in eigenen Projekten ggf. auf geoUDWrite2 zurückgreifen. Ist ggf. etwas langsamer aber Rückwärts- und Vorwärtskompatibel.


    Es gibt aber noch ein paar andere Sachen die mir aufgefallen, dazu später mehr...

    Sehr interessant!


    Ich war schon ein paar Mal versucht, die Kernfunktionen der C Ultimate Lib in Assembler zu erstellen, weil ich finde, dass diese Lib in dieser Form sehr viel Speicherplatz benötigt und nicht immer stabil ist. Aber ich hatte noch nicht genug Vertrauen in meine Fähigkeiten in Assembler-Code, um damit anzufangen.


    Wie es aussieht, ist das jetzt nicht mehr nötig, du bist mir zuvorgekommen und glaubst auch, dass du es unendlich viel besser kannst als ich.


    Ist dieser Code stabil genug, um zu sehen, ob er z.B. als Grundlage für GeoUMount verwendet werden kann?


    Und wird das Netzwerkziel auch Teil dieser Lib sein?

    Quote from xahmol

    Ist dieser Code stabil genug, um zu sehen, ob er z.B. als Grundlage für GeoUMount verwendet werden kann?

    Nein, da es jetzt gerade mal die erste Version ist und es noch kein Feedback dazu gibt, z.B. ob die Testprogramme unter GEOS128 funktionieren und das tun was sie sollen. Auch Tests auf einer Turbo-Firmware werde ich selbst nicht ausführen...


    Außerdem gibt es noch "Ungereimtheiten" beim UCI und in dessen Beschreibung. Und es fehlen noch einige Befehle (z.B. DEVINFO).


    Ich werde aber ein paar Funktionen in GDOS64 einbauen, dann sieht man wie praktikabel die geoULib ist und ob da ggf. noch was grundsätzliches geändert werden muss...


    Ich würde auch sagen geoUMount funktioniert wie es ist. Alles auf Assembler umzuschreiben wäre ein enormer Aufwand und bringt wieder neue Fehler mit...


    Quote from xahmol

    Und wird das Netzwerkziel auch Teil dieser Lib sein?

    Ich hab bisher keine Doku zum Netzwerk-Target (und CONTROL-Target) gefunden. Das was ich bisher weiß ist aus Beispielprogrammen und der Firmware. Allerdings scheint auch der Netzwerkteil über DATA/STATUS zu arbeiten, also sollte das grundsätzlich möglich sein und lässt sich sicherlich über den vorhandenen Code erzeugen...


    So hab ich das mit einigen der CONTROL-Befehle gemacht: eine Code-Datei dupliziert, den Befehl geändert. DATA/STATUS sind ja als Routinen definiert, da muss an der Funktion dann nichts angepasst werden (es sei den es werden Register zur Parameterübergabe benötigt). Dann nur die Beschreibung korrigieren, Fertig.


    Nur für die Demoprogramme muss ich dann wissen was über GET_DATA empfangen wurde, das musste ich jetzt häufig über den Firmware-SourceCode rauslesen...