Hello, Guest the thread was called223 times and contains 10 replays

last post from Pusti64 at the

Neue Laufwerktypen unter MP V3.xx

  • Hallo Darkvision,

    Ich bin auf der Suche nach einem weiteren RealDrvType für mein CMD-MO Laufwerk.

    Die HD-Laufwerktreiber können so bleiben wie sie sind. Es müsste halt zusätzlich auf die aktuelle SCSI-ID und SCSI-Gerätetyp (für HD = 0 und MO = 6) getestet und dann entsprechend RealDrvType vom Typ $21,22,23,24 nach eventuell Typ $51,52,53,54 geändert werden.

    Ich weiß ja, MegaPatch ist OpenSource. Aber darin rumpfuschen möchte ich auch nicht. Könntest Du mich dabei eventuell unterstützen oder gar einen anderen Lösungsansatz?


    Pusti64

  • Wozu braucht es einen neuen RealDrvType? Es ist doch eine CMD-HD?


    Ich kenne das MO nicht. Ist das an einer HD angeschlossen? Kann man dann zwei Laufwerke nutzen? Haben die dann in BASIC auch getrennte Laufwerksadressen? Wie wird Dein Treiber installiert?


    Warum muss eine Anwendung über RealDrvType das Laufwerk unterscheiden können? GeoDesk64 macht das ja auch nicht. Wichtiger ist RealDrvMode. Dort unterscheidet man auch zwischen 1541 und SD2IEC-41.

  • Mein MO-Laufwerk hängt mit der SCSI-ID 4 neben der Festplatte an meinem CMD-Controler dran. Nun braucht man nur ein kleines Programm, welches quasi den Controler von ID0 auf ID4 umstellt und schon kann man das MO-Laufwerk statt der Festplatte ansprechen.


    In RealDrvMode ist ja "nur" noch bit 1 frei und weiß nicht, ob Du das schon eventuell für andere Sachen vorgesehen hast.


    Pusti64

  • Nun braucht man nur ein kleines Programm, welches quasi den Controler von ID0 auf ID4 umstellt und schon kann man das MO-Laufwerk statt der Festplatte ansprechen.

    Dann wird die HD aber permanent auf das MO umgestellt? D.h. ein HD-Treiber (der ja keine IDs umstellt) würde dann ebenfalls auf das MO zugreifen? Da müsste ja der MO-Treiber bei jedem Zugriff die ID wechseln und danach wieder zurückstellen. Oder verstehe ich das falsch? Oder geht es nur darum CMD-HD als CMD-MO zu nutzen? Da würde ja ein externes Programm reichen das die Adressen umstellt.


    In RealDrvMode ist ja "nur" noch bit 1 frei und weiß nicht, ob Du das schon eventuell für andere Sachen vorgesehen hast.

    Ja, ich hab da an künftige Hardware (evtl. MEGA65) gedacht... aber da es unwahrscheinlich ist das ich da nach dem Final Release nochmal was mache... wäre das eine Option. Aktuell ist das Bit ja ungenutzt, es sollte daher nicht zu Problemen führen.


    Unterstützt das MO dann auch Partitionen? Müssen Programme überhaupt wissen ob es ein MO ist?


    Wenn Sich das MO wie eine HD verhält müsstest Du ja den Treiber nur installieren, evtl. über ein AutoExec das nach dem Editor oder Manuell gestartet wird. Da wird dann der Treiber ausgetauscht und ggf. das RealDrvMode-Bit gesetzt, wenn es MO-spezifische Funktionen zur Verfügung stellt.


    Wenn das MO sich wie eine HD verhält, dann reicht es den an das MO angepasste Treiber zu installieren. Dann braucht es auch keine Anpassungen von RealDrvMode und RealDrvType.


    Wenn man ein Programm entwickeln will das bestimmte Funktionen für das MO bereitstellt, dann kann man auch im Treiber eine Kennung einbauen. Die MP3-Treiber haben bereits so eine Kennung (MP3DD). Das Programm müsste dann nur alle vier Treiber testen um das MO-Laufwerk zu finden.

    Oder Du nimmst Bit#0 mit der geringen Wahrschenlichkeit das es in zukünftigen Versionen nochmal geändert wird.


    Ich weiß gerade nicht ob der Installer der Laufwerkstreiber prüft ob das CMD-HD-Laufwerk schon installiert ist, ich erinnere mich da dunkel an die Suchroutine die alle Geräteadressen prüft. Wen dem so ist kann das der Editor nicht ohne Anpassungen die CMD-HD ein zweites mal als CMD-MO einrichten. Ist aber nur ein Verdacht... ist schon eine Weile her...


    Da wäre ein AutoExec ein Workaround.

  • Darkvision schrieb:

    Dann wird die HD aber permanent auf das MO umgestellt? D.h. ein HD-Treiber (der ja keine IDs umstellt) würde dann ebenfalls auf das MO zugreifen? Da müsste ja der MO-Treiber bei jedem Zugriff die ID wechseln und danach wieder zurückstellen.


    Genau so ist es. Einen separaten MO-Treiber braucht man aber nicht.


    Mal schauen wie ich es machen werde. Denn in Desktop128 gibt es bei $04bf 4 Bytes welche Auskunft über ein angeschlossenes CMD- RL,RD,HD,FD2000,FD4000 bzw. 64net pro Lfw. geben.

    Leider benötigt man zum auslesen der SCS-ID und des SCSI-Typ relativ viel Speicherplatz.


    Pusti64

  • Dann verstehe ich aber Deinen Eingangspost nicht:


    *Für das CMD-MO wird der HD-Treiber verwendet.

    *Das CMD-MO verhält sich wie eine HD

    *Es können nicht beide gleichzeitig genutzt werden


    Warum dann ein eigener RealDrvType? Warum muss das überhaupt irgendwo vermerkt werden?


    Geht es Dir darum in TopDesk das umstellen der ID zu ermöglichen und Du willst dabei auf Infos in RealDrvType/RealDrvMode zurückgreifen um das nicht jedesmal überprüfen zu müssen ob es ein MO ist? Dann müsste das ja von MegaPatch/GEOS.Editor bei der Installation des HD-Treibers gesetzt werden.


    Also da fände ich es wesentlich sinnvoller wenn die Anwendung selber prüft ob es a) eine HD ist (das geht über RealDrvType) und ob es b) mehrere gültige IDs gibt (eigene Routine, kann man das Abfragen?). Im letzteren Fall dann die Auswahl anbieten auf welches ID man wechseln will. Ich denke mal die Anzahl der Anwender mit einem MO die GEOS128/MegaPatch128 und TopDesk128 nutzen dürfte überschaubar sein. Dazu MegaPatch anzupassen halte ich für etwas übertrieben.


    GeoDos64 nutzt ja keine MegaPatch64-Informationen und erkennt auch ob es ein SD2IEC ist oder nicht. Dazu wird am Anfang die Hardware abgefragt und dann intern vermerkt was es für ein Laufwerk ist und was es kann.


    Wenn Du das in das "Partition wechseln" in TopDesk einbauen willst, dann würde ich dort auf eine HD prüfen, und ggf. dann die ID auslesen und eine Auswahl zwischenschalten. Dann wählt man zuerst die ID und kehrt dann zur Partitionsauswahl zurück. Das würde dann auch für Anwender ohne HD/MO keinen Nachteil haben. Nur bei HD-ohne-MO-Anwender, bei denen würde es ggf. eine kleine Verzögerung geben wenn die IDs ausgelesen werden und festgestellt wird das es kein MO gibt.


    Man könnte so eine MO-Erkennung in den HD-Treiber-Installer packen, der prüft ja auch auf ein Parallel-Kabel und installiert dann ggf. den PP-Treiber den er "Huckepack" mitschleppt.

    Hier könnte man auch auf ein MO testen und dann ggf. RealDrvMode setzen. Allerdings ist es auf Grund des Huckepack-Treibers gerade für den HD-Treiber hier auch schon knapp:

    Der Installier liegt im Editor bei $APP_MAIN=$0400, der Editor lässt hier $1000 Bytes für den Installer frei, davon entfallen beim HD-Installer $0D80 Bytes auf den Huckepack-PP-Treiber. Bleiben für den Installer noch $0280 Bytes übrig. Wenn ich mir den Code in "-DD_InitHD.s" von GEOS/Megapatch auf der 4er-Disk/Treiber anschaue, dann wird das knapp. Viel Platz dürfte da nicht mehr übrig sein.


    Die Partitionsauswahl liegt doch im Modul "L" von TopDesk? Ist da der 64erNet Code noch enthalten oder hast Du den Platz schon recycled? Sonst könnte man hier ja die Erkennung mit reinpacken. Aber das weißt Du sicherlich besser ;)

  • Mir geht es darum, dass man zur Zeit im Desktop auf Anhieb nicht erkennen kann, ob ich nun mit der CMD-HD oder CMD-MO arbeite.

    Ein vom Editor oder MP V3.xx gesetztes RealDrvType/RealDrvMode wäre da sehr hilfreich. Damit kann das dann jedes Programm schnell auswerten und entsprechend anzeigen.

    Weisst du unter was für einem SCSI-Typ eine SCSI2SD läuft bzw. wie lautet die Einschaltmeldung dieser? Etwa CMD-2SD oder ist es beim CMD-HD geblieben?


    Pusti64

  • Das ist doch das gleiche Problem wie bei der Erkennung ob ein SD2IEC innerhalb eines DiskImages oder im SD-Verzeichnis ist. Das testet GeoDesk64 bei einem Fehler und reagiert dann entsprechend.

    Hier in RealDrvMode ein Bit zu setzen wäre zwar denkbar, aber wer soll das Bit setzen? Der GEOS.Editor? Laufwerkstreiber? Das müsste ja permanent überwacht werden. Für mich war damals klar das da eine Abfrage in GeoDesk64 rein muss.


    RealDrvType on-the-fly zu ändern oder auch RealDrvMode war ja nie geplant. Die Werte werden beim Systemstart durch den GEOS.Editor bzw. den Laufwerkstreiber gesetzt, nicht durch Funktionen im laufenden MegaPatch-System. Meines Wissens nach gibt es keine Routine welche die Werte RealDrvType/RealDrvMode aktualisiert.


    Das geht sogar so weit das der Laufwerkstreiber RealDrvType/RealDrvMode zurücksetzt, für den Fall das eine Anwendung die Treiber getauscht hat ohne RealDrvType/RealDrvMode anzupassen.


    TopDesk müsste das also bei der Rückkehr zum DeskTop ermitteln und intern speichern, so wie es das GeoDesk64 mit dem SD2IEC-Modus macht.

    Weisst du unter was für einem SCSI-Typ eine SCSI2SD läuft bzw. wie lautet die Einschaltmeldung dieser? Etwa CMD-2SD oder ist es beim CMD-HD geblieben?

    Bei SCSI2SD wird die Festplatte ausgetauscht, kein Controller oder ROM. Daher dürfte sich da an der Einschaltmeldung nichts geändert haben. Testen kann ich das nicht mehr, die HD ist nur noch ein Briefbeschwerer.

  • Okay, dann wird mein MP3-Programm zum ändern der SCSI-ID DriveModeFlags mit bit 1 also Flag_MO setzen, was Desktop dann wiederum auswerten kann.

    Du meinst das ungenutzte erste Bit#0?


    Dann nicht vergessen: Laufwerk aktivieren, Bit ändern, Treiber zurück in die REU speichern. Dann könnte das funktionieren.

    Schöner wäre natürlich so was wie ein ScsiTypFlag, weil es ja neben dem MO noch andere Medien wie z.B. CD, ZIP und SD gibt.

    Stimmt... also ein zweites RealDrvMode... aber das sind so viele Baustellen die man anfassen müsste... und man müsste eine Stelle finden die beim 128er und 64er gleich ist für die 4Byte. Und ich glaube die Variablen am C64 gehen schon bis $9FFF. Also geht die Suche bei $C000 los...


    Oder man packt es nur in den HD-Treiber, dort wo die Laufwerksdaten (auch DriveModeFlags) liegen ab $9050 oder so... letzteres kann ich mir ja nochmal anschauen. Ein Byte zu reservieren, das immer an der gleichen Stelle liegt, "reserved for future use" ;)


    Dann müsste man nur prüfen ob der HD-Treiber das Byte unterstützt, z.B. mit einer Kennung wie "DDX" (DiskDriver Xtended) gefolgt von dem SCSI-Byte. Dann braucht Dein Programm aber immer auch das aktuelle MegaPatch, alte Treiber haben das Byte ja dann nicht.