letzter Beitrag von wweicht am
Hi...
es gibt eine neue GeoDOS-Version:
Die einzige Änderung betrifft das aufräumen auf NativeMode-Partitionen abseits der CMD-Laufwerke, hier werden jetzt auch Unterverzeichnisse unterstützt.
UV anlegen/wechseln funktioniert noch nicht, wird aber an Hand der Testprogramme aus dem GEOS-MegaPatch-Thread demnächst ergänzt.
Download hier oder hier (v2.963).
Probleme oder Fragen mit der neuen Version bitte künftig hier posten.
Finde ich gut 
So hab mal die V 2.963 ausprobiert.
Aufräumen:
- Auf der CMD-HD (Native-Partitionen) klappt ohne Fehlermeldung, die Grösse der UV's wird angepasst.
- SD2IEC DNP's scheint vom Images abhängig zu sein.
Ein DNP bei welchem der TD diverse Probleme hatte (Filehaeder nicht gefunden, Ungültiger Track, zerstörte Icons), scheint jetzt zu funktionieren.
Bei einem anderen DNP wird mit Diskettenfehler ungültiger Sektor abgebrochen, vermute mal das dieses Image korrupt ist.
Bei einem weiteren war komischerweise kein Diskname vorhanden, nach dem aufräumen schon.
Im Moment versuche ich eine Native-Partition in ein DNP zu kopieren (gleiche Grösse), mal sehen wie lange es dauert und ob's funktioniert.
Frage:
Gibt es eine Möglichkeit das GeoDOS auch die Images auf dem SD2IEC wechseln kann, evt. mit den Routinen aus Werner's uIEC-Manager?
Gruss C=Mac.
Gibt es eine Möglichkeit das GeoDOS auch die Images auf dem SD2IEC wechseln kann, evt. mit den Routinen aus Werner's uIEC-Manager?
Machbar ist (fast) alles... bei CMD-Laufwerken gibt es eine System-Partition die man abfragen kann wie ein Laufwerks-Verzeichnis. Ich glaub das gibt es so beim SD2IEC nicht. Aber wenn ich weiß wie der uIEC-Manager die Images abfrägt (z.B. über den $-Befehl?) lässt sich da mit etwas Aufwand schon etwas basteln... wenn ich dazu Zeit hab...
Im Moment versuche ich eine Native-Partition in ein DNP zu kopieren (gleiche Grösse), mal sehen wie lange es dauert und ob's funktioniert.
So Kopie ist durch: 1 Std. 10 min. 
Scheint zu funktionieren, jedenfalls bewehrt sich TD nicht.
Hab noch kein Fehler gefunden, UV's können ohne Probleme geöffnet werden.
Würde eigentlich mehr Kopier-RAM das kopieren merklich beschleunigen?
Ich glaub das gibt es so beim SD2IEC nicht. Aber wenn ich weiß wie der uIEC-Manager die Images abfrägt (z.B. über den $-Befehl?) lässt sich da mit etwas Aufwand schon etwas basteln... wenn ich dazu Zeit hab...
Da ist Werner der richtige Ansprechpartner.
Vor allem, keine Hektik.
Gruss C=Mac.
Würde eigentlich mehr Kopier-RAM das kopieren merklich beschleunigen?
Nur unmerklich. Dauert dann vielleicht 1h5min da nur ein paar zusätzliche SetDevice/EnterTurbo-Befehle wegfallen. Ich hab da schon ein Testprogramm geschrieben das etwas mehr Speicher im C64 nutzen kann. Ist kaum schneller als GeoDOS... lohnt also den Aufwand nicht über die REU einen größeren Copy-Puffer zu nutzen...
Danke für die Erklärung.
Wenn nicht wirklich was rausgeholt werden kann, ist es den Aufwand wirklich nicht wert.
Gruss C=Mac.
Aber wenn ich weiß wie der uIEC-Manager die Images abfrägt (z.B. über den $-Befehl?)
Genau so: Mit "cd:<-" (<- ist de Pfeil nach links) aus dem Image rauswechseln und dann mit das ganz nomale Inhaltsvezeichnis ("$") abholen. Wobei die Images in Untevezeichnissen liegen können. Kannst Du in Basic einfach Dir ansehen.
Wobei die Images in Untevezeichnissen liegen können.
Bein uIEC-Man müssen. Da ist eine feste Verzeichnisstruktur vorgegeben (für jeden Image-Type). Entsprechend des Drive-Types, den das SD2IEC hat (1541, 1571, 1581 und DNP) wird in das entsprechende Verzeichnis gesprungen. Dort wird per $ das Inhaltverzeichnis gelesen und angezeigt.
So kann man für jeden Image-Type 255 Dateien anzeigen und öffnen. Wenn alles in einem Verzeichnis liegen würde, könnte man insgesamt nur 255 Dateien sehen. Und wenn man dann ein falsches Image zum Drive-Type öffnet, gibt es Probleme........
Das Ding ist 2011 entstanden und sollte von anfang an in Geos, MP3 und Wheels laufen. Deshalb werden nur Geos V2-Routinen verwendet..... Der uIEC-Man baut im Prinzip die Befehle zusammen, die dann an das entsprechende SD2IEC (bis zu 4 sind möglich (A: - D:) )gesendet werden....
Gruß
Werner
@markusC64 @wweicht: Danke für die Infos... hört sich ja gar nicht so kompliziert an... ich denke mal drüber nach.
Es gibt aber derzeit ein anderes Problem mit dem SD2IEC im 1581-Modus:
GeoDOS geht bei einer 1581 davon aus das man damit DOS-formatierte Disketten lesen kann. Daher wird bei solchen Laufwerken nicht mit der üblichen Methode geprüft ob eine Disk im Laufwerk liegt (Lesen eines Datensektors von Disk) da dies bei DOS-formatierten Disketten mit den GEOS-Routinen nicht funktioniert. Daher sendet das Programm Befehle an das 1581-Laufwerk um mit Hilfe der Job-Queues zu prüfen ob eine Disk im Laufwerk liegt. Das scheint das SD2IEC im TurboDOS-Modus nicht zu mögen 
Ich hab testweise mal die 1581 als "nicht-DOS-kompatibel" markiert und das Problem war hier danach behoben. Ich muss also beim Hardware-Test am Anfang prüfen ob da ein SD2IEC hinter der "1581" steckt.
Aus dem MegaPatch-Thread gab es dazu schon mal den Tipp mit dem @"X?"-Befehl und der Rückmeldung mit xx,SD2IEC... Das würde ich jetzt so einbauen und ggf. das das DOS-Flag löschen. Nachteil wäre das man dann mit dem SD2IEC keine DOS-formatierten Disketten mehr lesen/schreiben kann 
Melden sich alle SD2IEC mit dem "Typ" ? Gibt es andere Möglichkeiten ein D81 am C64 zu "mounten", was ist mit diesem neumodischen Kram wie Ultimate&Co? Die müsste ich ja ggf. auch ausschließen.
Mir ist das bei der BACKUP-Funktion (C=-64/128, 1:1 Backup) von 1581/SD2IEC nach RAM1581 aufgefallen.
Melden sich alle SD2IEC mit dem "Typ" ? Gibt es andere Möglichkeiten ein D81 am C64 zu "mounten", was ist mit diesem neumodischen Kram wie Ultimate&Co? Die müsste ich ja ggf. auch ausschließen.
Eine Ultimate kann das schon mal nicht mounten - was aber nicht heißt, dass man keinen Treiber für die Ultimate entwickeln könnte. Das auszuführen würde hier aber arg offtopic. TC64 weiß ich nicht.
Melden sich alle SD2IEC mit dem "Typ" ? Gibt es andere Möglichkeiten ein D81 am C64 zu "mounten", was ist mit diesem neumodischen Kram wie Ultimate&Co? Die müsste ich ja ggf. auch ausschließen.
Inspiriert durch unsere Arbeiten am SD2IEC Treiber hätte ich da noch eine andere Art & Weise, ein SD2IEC zu erkennen: Da wir festgestellt haben, dass das SD2IEC den TurboDOS Code nicht abspeichert beim M-W, könnte man jenen Bereich per M-R lesend überprüfen. Passt das Geschriebene nicht zum Gelesenen, hat man eine funktional beschnittene D81 Emulation und muss ohne Jobcodes auskommen.
Nachteil wäre das man dann mit dem SD2IEC keine DOS-formatierten Disketten mehr lesen/schreiben kann
Habe ich was verpasst ? Das kann doch das SD2IEC sowieso nicht .....
Meines Wissens geht unter Geos & Co nur D64, D71, D81 und DNP.
Melden sich alle SD2IEC mit dem "Typ" ?
wie ich an besgater Stelle schon schrub leider nein. Es gibt eins, das meldet sich da mit xx,NODISKEMU (PetSD+) Hier ist aber unklar, ob das mit Geos überhaupt schon richtig funktioniert ......
Wie sich die xxx verschiedenen Varianten und teilweise mit eigener Firmware melden, keine Ahnung.
Gruß
Werner
Passt das Geschriebene nicht zum Gelesenen, hat man eine funktional beschnittene D81 Emulation und muss ohne Jobcodes auskommen.
Auch nicht schlecht. Nur müsste dann eine Anwendung Kenntnisse über die Daten des TurboDOS-Codes haben. Da würde ich gerne darauf verzichten wollen. Es sei denn es kommen da beim M-R nur $00-Bytes rüber. Dann wäre es eindeutig.
P.S. Nach @wweichts Rückmeldung versuche ich das mal mit dem M-R... das wäre dann evtl. zuverlässiger.
Wenn ich weis das es ein SD2IEC ist wird das DOS-Flag für das Laufwerk gelöscht und dann geht alles weitere wie bei einer 1541/71... Die Rückmeldung über X? würde also reichen.
Gibt im übrigen noch einen Job-Code: $b6 -> WRT_PROT_ON, also Schreibschutz-Erkennung. Wer sich fragt das das bedeutet, z.B. CMD-FD-Handbuch, Seite 79 Job-Queue/-Codes.
Bei einem anderen DNP wird mit Diskettenfehler ungültiger Sektor abgebrochen, vermute mal das dieses Image korrupt ist.
Hab dieses DNP noch einmal mit GD kopiert (erste Kopie stammt von Wheels), kann keine Probleme mehr feststellen. 
Bei einem weiteren war komischerweise kein Diskname vorhanden, nach dem aufräumen schon.
Dies betrifft nicht nur GD, siehe anderen Thread.
Gruss C=Mac.
Frage:
GeoDOS kann ja alle CMD-Uhren auf einmal stellen (wird am Wochenende wieder aktuell).
Ist es möglich die Uhr der Ultimate auch zu integrieren (lesen/setzen)?
Das lesen wäre auch für MP3 interessant.
Es gibt zwar ein Programm von Werner, aber wenn man es integrieren könnte.
Gruss C=Mac.
Da ich keine Ultimate habe müsste ich schon wissen wie man die Uhr programmiert bzw erkennt... allerdings wird das eh nix bis zum Wochenende
Forum64_Wolke\Software\Geos\Apps+Tools\1541U RTCV1.02.7z beinhaltet einen kompletten Assemblersource zur Detektion und Abfragen der Uhrzeit.
Weitere Infos dazu - und Fragen dazu auch bitte dort: Zugriff auf RTC / Uhrzeit / Datum / TOD - das schließt das Setzen der Uhrzeit ein.
Danke. Ich lege das mal auf die ToDo Liste... gerade stelle ich die Version 2.964 zusammen, ist entweder heute oder morgen online.
Damit wird jetzt ein SD2IEC im 1541/71/81-Modus als 15x1-SD erkannt. Wobei nur bei der 1581-SD dann das DOS-Flag gelöscht wird. Damit müsste jetzt alles auch mit dem SD2IEC funktionieren (bis auf DOS-Disketten...). Backup funktioniert damit wieder.
Die Erkennung des SD2IEC basiert auf dem Tipp von markusC64 
und setzt nicht unbedingt den Text "SD2IEC" im Befehl "X?" voraus, ist aber derzeit nur auf meinem SD2IEC, das ich über den großen Fluss geordert hab, getestet. Wäre also gut wenn ich da etwas Feedback bekomme ob andere SD2IECs korrekt erkannt werden... Falls nein wäre gut auch mal die Antwort auf den "X?"-Floppy-Befehl zu posten.
Denn für weitere Funktionen wie ImageWechsel braucht es ja die Erkennung. Das ist also nicht nur ein Fix sondern Grundlagenforschung
allerdings wird das eh nix bis zum Wochenende
Wie, nicht ... aber was ist den das jetzt wieder?
Spass beiseite, eilt überhaupt nicht, wenn's dieses Jahr was wird, dann wird es was und wenn nicht, dann nicht.
Ist ja ein Hobby und das soll Spass machen und nicht in Arbeit und Hektik ausarten.
gerade stelle ich die Version 2.964 zusammen
Damit wird jetzt ein SD2IEC im 1541/71/81-Modus als 15x1-SD erkannt. Wobei nur bei der 1581-SD dann das DOS-Flag gelöscht wird. Damit müsste jetzt alles auch mit dem SD2IEC funktionieren (bis auf DOS-Disketten...).
Wenn ich es richtig interpretiere sind für die 15xx-Images nicht mehr die entsprechende 15xx-Treiber von Nöten, sondern es wird alles mit dem SD2IEC-Treiber erledigt?
Somit braucht es auch für die 15xx-Images keine .BIN-Datei mehr?
Das betrifft aber nur GeoDOS oder auch MP3?
Gruss C=Mac.
Wenn ich es richtig interpretiere sind für die 15xx-Images nicht mehr die entsprechende 15xx-Treiber von Nöten, sondern es wird alles mit dem SD2IEC-Treiber erledigt?
GeoDOS v2.x hat nichts mit den Laufwerkstreibern zu tun. Du brauchst nach wie vor die DOS.BIN-Dateien. Ich glaub auch nicht das sich das mit GeoDOS V3 ändern wird... Aktuell: GEOS-Kernal->Laufwerkstreiber->GeoDOS(oder TopDesk, oder geoWrite).
Da GeoDOS aber für die DOS-Funktionen spezifische Systemaufrufe und Laufwerksinterne Funktionen verwendet muss GeoDOS wissen ob das Laufwerk das überhaupt kann. Daher zum Start immer der Hardware-Test.
Und hier wird jetzt nur erkannt ob das ein 3,5"-Disk-Laufwerk ist oder so 'n neumodischer KrimsKrams mit SD-Speicherkarten. Da es schwer werden dürfte in den kleinen Schlitz der SD eine 3,5"-Diskette reinzuquetschen muss ich da sicher sein das ich keine Funktionen verwende die das SD2IEC nicht beherrscht oder GeoDOS 
ab...
Es gab da sowieso nur zwei Stellen wo das bis jetzt vorkam: Prüfen ob Disk im Laufwerk und prüfen ob Disk schreibgeschützt ist. Da wird jetzt eben bei einem SD2IEC der Code wie beim 64Net ausgeführt. Für reine 1581-Laufwerke gibts da immer andere Wege. Aber die 1581 kann ja auch DOS-Disketten lesen und daher hat das Laufwerk gesonderte Routinen verwendet die das SD2IEC eben nicht versteht (muss es ja auch nicht...), die aber auch bei einer DOS-Disk funktionieren müssen.
Wer des Programmierens mächtig ist kann ja mal versuchen mit den GEOS-Routinen "GetBlock" & Co zu prüfen ob da eine Disk im Laufwerk liegt. GEOS wird da bei einer DOS-Disk immer eine Fehlermeldung ausgeben. Und Schreibschutz durch lesen/schreiben eines Blocks geht logischerweise auch nicht um den Schreibschutz zu erkennen.
