GoodByteXL hat geschrieben:Bitte differenzieren. SpartaDOS 1.x, 2.x 3.x als diskbasierte DOS können das nicht. Für SD 3.2G war das angekündigt, wurde aber nicht umgesetzt. SD 3.3 kann's nicht und RealDOPS auch nicht.

Stimmt, ich hab's gerade mit Sparta 3.2f ausprobiert.

Nicht so schlimm, jetzt weiß ich auch wieder warum ich das damals so in der cc65 Runtime-Lib implementiert habe

Die cc65 Runtime, wenn beim "open()" ein Name wie "D:FILENAME" angegeben ist (oder auch nur "FILENAME"), macht daraus ein "Dn:FILENAME", bevor sie es ans DOS weiterleitet. "n" = aktuelles Laufwerk.

So kann man im C Programm mit "D:FILENAME" oder "FILENAME" auf das aktuelle Laufwerk zugreifen.

(Das ist abschaltbar, dazu muß man aber die Runtime-Lib neu übersetzen.)

XDOS soll möglichst kompatibel zu DOS 2.5 sein. Und da bei DOS 2.5 stets D: gleich D1: ist, ist das bei XDOS auch so. Außerdem behandelt das ATARI-OS in seiner CIO-Routine jedes Gerät X: immer wie X1:.

In XDOS kann man aber ähnlich wie in Turbo-DOS den logischen Laufwerken D1:-D9: beliebige physische Laufwerke und RAM-Disks zuordnen, siehe Tabelle XDRV ab $711. D: ist dann aber immer noch gleich D1:.

cpg hat geschrieben:Das aktuelle Drive steht anscheinend an Adresse $816. Ich werde mal Stefan fragen, ob man sich darauf verlassen kann.

Es ist keine gute Idee, undokumentierte Speicherstellen abzufragen. Gerade bastle ich an XDOS 2.5 herum - und da wird das DUP-Default-Laufwerk sicherlich woanders im Speicher liegen.
Aber mit XDOS 2.4 gibt es eine saubere Möglichkeit, das DUP-Default-Laufwerk herauszubekommen:

Code: Alles auswählen

; Vorher checken, das mind. XDOS 2.4 geladen ist, siehe Doku.
lda #155
sta xline=$880      ; DUP-Eingabepuffer xline leeren
jsr xmove=$877      ; DUP-Dateiangabe ab xline in xfile fürs FMS aufbereiten
lda xfile+1=$87d+1  ; ab xfile steht nun "Dn:", n ist das Default-Laufwerk

GoodByteXL hat geschrieben:Einzig SpartaDOS X ist dazu in der Lage, vmtl. weil es einen eigenen Kernel hat, der parallel zur CIO arbeitet.

Ne ne, das wäre ganz einfach in ein DOS einzubauen, für XDOS würde das gerade mal 20 Byte Code kosten. Aber wie oben gesagt, das verstößt gegen den ATARI-CIO-Standard. Daher würde ich das höchstens als zuschaltbare Option in XDOS vorsehen.

Dietrich hat geschrieben: Gerade bastle ich an XDOS 2.5 herum...

Hi Stefan,
wird es dann ein Update von XDOS für alle Abbucianer geben (oder ein Release/Upload via Atari Age) ?!?

CharlieChaplin hat geschrieben:

Dietrich hat geschrieben: Gerade bastle ich an XDOS 2.5 herum...

Hi Stefan,
wird es dann ein Update von XDOS für alle Abbucianer geben (oder ein Release/Upload via Atari Age) ?!?

Nix XDOS 2.5, ich warte auf das YDOS als Ersatz für das fehlerhafte MyDos. Was hat mich MyDos an Zeit bei der Entwicklung gekostet nur um die Fehler in meiner Software abzufangen. YDOS ist viel Schlanker in der Speicherverwurstung, kommt mit Top Geschwindigkeit daher, ist 100% kompatibel zu MyDos kompatibel und kann dafür noch mehr Dateien und Verzeichnisse schlucken als alle anderen. Ist noch nicht zu spät Stefan, da gehen noch ein Paar Assembler Zeilen

Wir sehen uns in drei Wochen,
Bernd

PS: Bring belegte Brötchen zum Frühstück mit. Spiele auch gerne den Beta-Tester für dein Dos.

Gemach gemach, erstmal kommt XDOS 2.5, dann sehen wir weiter. Freu mich auch auf die Classic Computing

Hallo Bernd

Bernd hat geschrieben:... das fehlerhafte MyDos.

Kannst Du die Fehler mal beschreiben?

Tschüß

Mathy

Mathy hat geschrieben:Hallo Bernd

Bernd hat geschrieben:... das fehlerhafte MyDos.

Kannst Du die Fehler mal beschreiben?

Tschüß

Mathy

Gehört zwar nicht zum XDOS, machen wir mal eine Ausnahme.

Tritt nur bei extrem großen Files auf. Inhaltsverzeichnis über MyDos lesen, die Übergabe ab 5 stelligen Ziffern für die Filelänge ist Schrott, der Frame ist nur für 4 Stellen gedacht und macht mächtig Mist dabei. Musste dafür eine Korrekturroutine schreiben.

Die Beschränkung auf 64 Files oder Verzeichnisse in einer Root wird beim Versuch den 65zigsten dort abzulegen mit einem wunderbaren Fehler beendet. Anfangs habe ich gedacht selber diesen zu verursachen, kam aber aus den Tiefen von MyDos.

Tschau,
Bernd

PS: Wenn mir noch mehr einfällt, schreibe ich es hier.

Hallo Bernd

Bernd hat geschrieben:... der Frame ist nur für 4 Stellen gedacht und macht mächtig Mist dabei.

Was genau meinst Du mit "der Frame"?

Bernd hat geschrieben:Die Beschränkung auf 64 Files oder Verzeichnisse in einer Root wird beim Versuch den 65zigsten dort abzulegen mit einem wunderbaren Fehler beendet.

Kannst Du denn Fehler beschreiben? Kann auch per Mail.

Bernd hat geschrieben:PS: Wenn mir noch mehr einfällt, schreibe ich es hier.

Danke!

Tschüß

Mathy

Bernd hat geschrieben:.
.. und kann dafür noch mehr Dateien und Verzeichnisse schlucken als alle anderen. .

Muss es hier nicht heißen "als alle anderen DOS-2.5-Derivate"?
Oder gibt es neue Fakten?

Hmmm,

MyDOS Bugs, die mir gerade eben einfallen:

1) mit dem letzten Update von MyDOS (4.55 Beta 4 oder so) läuft bei mir der Ramdisktreiber MyRD2 oder MyRamd2 nicht mehr (als *.AR0), dadurch ist das Update für mich uninteressant...

2) manche ML-Programme ließen sich mit L-binary load laden, nicht jedoch als Autorun bzw. *.ARx Datei (dieselben Programme ließen sich jedoch mit DOS 2.5 oder TurboDOS problemlos als Autorun starten)

3) es gibt scheinbar Überschneidungen oder Konflikte zwischen der Subdir :Ramdisk und mehreren Autoruns - hat man mehrere Autoruns, so werden Programme in der Subdir :Ramdisk nicht mehr vollständig in die Ramdisk kopiert, sondern stattdessen die weiteren Autoruns ausgeführt

Es gibt bestimmt noch ein Dutzend weitere Bugs, die ich bemerkt habe, die mir jedoch gerade nicht einfallen (und Bugs, die ich gar nicht bemerke, weil ich z.B. bestimmte Sachen wie Festplatten-Partitionen, Subdirs, etc. kaum bis gar nicht nutze)...

Von daher würde ich die Entwicklung des YDOS sehr begrüßen, ebenso wie ich die Weiterentwicklung von XDOS sehr begrüße.

Wenn XDOS 2.5 fertig ist, werde ich es natürlich veröffentlichen - hier oder auf AtariAge.

Bernd hat geschrieben:Tritt nur bei extrem großen Files auf. Inhaltsverzeichnis über MyDos lesen, die Übergabe ab 5 stelligen Ziffern für die Filelänge ist Schrott, der Frame ist nur für 4 Stellen gedacht

Ja, die DIR-Zeilen sind nur für Dateien mit max. 9999 Sektoren gedacht. Es gibt aber meines Wissens auch ein MyDOS mit 5 Stellen für die Dateigröße im Directory. In YDOS hab ich das so gelöst, dass zwar nur 4 Stellen vorgesehen sind, aber für die ggf. 5. Stelle das Leerzeichen davor benutzt wird. Aber mal ehrlich, wer nutzt schon 2,5 MB große ATARI-Dateien ...

Bernd hat geschrieben:Die Beschränkung auf 64 Files oder Verzeichnisse in einer Root wird beim Versuch den 65zigsten dort abzulegen mit einem wunderbaren Fehler beendet.

Ähm, wenn du das 65. File speichern willst, gibt es natürlich einen Error 169 - Directory full. Oder meinst du einen Absturz?

Charlie hat geschrieben:... mit dem letzten Update von MyDOS (4.55 Beta 4 oder so) ...

Oh oh, mit diesen "Beta-Updates" würde ich seeeehr vorsichtig sein, der Autor "Lee ???" hat eine recht seltsame Vorstellung vom korrekten VTOC-Header (da gab es mal hier einen Thread dazu) - wenn er da was verändert hat, kann das dicke Probleme geben.

Charlie hat geschrieben:... Ramdisktreiber MyRD2 ...

Gehört der offiziell zu MyDOS? Wenn nicht, ist das wohl ein Patch von MyDOS und sowas verträgt sich schlecht mit anderen Patches wie den "Beta"-Versionen - vielleicht wurden die gleichen Stellen gepatcht ...

Charlie hat geschrieben:... manche ML-Programme ließen sich mit L-binary load laden, nicht jedoch als Autorun ...

Wirklich? Hast du ein konkretes Beispiel für so ein nicht AUTORUN.SYS-fähiges Programm?

Charlie hat geschrieben:... es gibt scheinbar Überschneidungen oder Konflikte zwischen der Subdir :Ramdisk und mehreren Autoruns ...

Ist das Ausführen von mehreren Autoruns eine offizielle Funktion von MyDOS - oder nur eine Erweiterung, die jemand mal programmiert hat? Gleiche Frage gilt für die Kopierfunktion aller Dateien in die Ramdisk. Wenn das beides Erweiterungen anderer Leute sind, ist es nicht sehr verwunderlich, dass diese nicht zusammen
funktionieren (z.B. wenn beide die gleichen I/O-Kanäle benutzen). MyDOS selbst kann man das dann aber nicht anlasten.

Bernd hat geschrieben: ... und kann dafür noch mehr Dateien und Verzeichnisse schlucken als alle anderen ...

GoodByteXL hat geschrieben:Muss es hier nicht heißen "als alle anderen DOS-2.5-Derivate"?

Natürlich, SpartaDOS spielt in einer anderen Liga

Hallo Stefan

Alle Beta's stammen von Lee Barnes. Auch MyRD(2) stammt von ihm. Im original RAMdisktreiber von MyDOS sind einige Fehler, die hat Lee beseitigt.

MyDOS benutzt schon lange 5 Stellen, wenn es 5 Stellen benötigt.

Was genau stimmt an den VTOC headern nicht?

Ja, das ausführen mehrerer Autoruns ist eine offizielle Funktion MyDOS. Wenn ich mich nicht irre, war das ab 4.53. Ab dann läuft AUTORUN.SYS nicht mehr automatisch, sondern FILENAME.ARx. Wobei das erste .AR0 sein sollte, maximal 9 Dateien automatisch gestartet werden und keine Nummer überschlagen werden sollte.

Dateien die sich auf der Boot-Disk im Verzeichnis "RAMDISK:" befinden, werden vom RAMdisktreiber automatisch in die RAMdisk geladen. Ist auch 'ne offizielle Funktion MyDOS.

Tschüß

Mathy

Danke Mathy, für die Infos. Die Sache mit den Autoruns *.ARn und das RAMDISK-Verzeichnis kannte ich noch nicht. Und die 5stellige Sektoranzeige für die Filegröße funktioniert in MyDOS tatsächlich - und zwar genauso, wie ich das in YDOS vorgesehen habe

Der VTOC-Header (Byte 0) ist völlig OK. Aber Lee ist (oder war) der Meinung, dass Byte 0 in bestimmten Fällen nicht richtig ist, und wollte das "korrigieren". Wenn er das tatsächlich gemacht hat (keine Ahnung ob das so ist), sind seine MyDOS-Versionen nicht mehr kompatibel zum Standard-MyDOS-Format. Darüber gab es mal eine Diskussion hier im Forum, ist aber schon lange her.

Dietrich hat geschrieben:Aber mit XDOS 2.4 gibt es eine saubere Möglichkeit, das DUP-Default-Laufwerk herauszubekommen:

Code: Alles auswählen

; Vorher checken, das mind. XDOS 2.4 geladen ist, siehe Doku.
lda #155
sta xline=$880      ; DUP-Eingabepuffer xline leeren
jsr xmove=$877      ; DUP-Dateiangabe ab xline in xfile fürs FMS aufbereiten
lda xfile+1=$87d+1  ; ab xfile steht nun "Dn:", n ist das Default-Laufwerk

Ahh, super!

Dann werd' ich mal schauen ob ich das einbauen kann...

cpg hat geschrieben:Dann werd' ich mal schauen ob ich das einbauen kann...

Noch eine kurze Frage. Also, das geht nicht mit XDOS < 2.4? Wenn doch, ab welcher Version geht es?

Das geht wie gesagt erst ab XDOS 2.4 - da habe ich die Parameter-Unterstützung für COM-Programme eingebaut. In XDOS 2.5 wird es wohl eine feste Speicherstelle für das Default-Laufwerk im Konfig-Bereich geben.

Dietrich hat geschrieben:In XDOS 2.5 wird es wohl eine feste Speicherstelle für das Default-Laufwerk im Konfig-Bereich geben.

Klingt gut.

Hast Du denn eine Liste der Erweiterungen etc. die Du für die 2.5 Version planst?

Dietrich hat geschrieben:

Code: Alles auswählen

; Vorher checken, das mind. XDOS 2.4 geladen ist, siehe Doku.
lda #155
sta xline=$880      ; DUP-Eingabepuffer xline leeren
jsr xmove=$877      ; DUP-Dateiangabe ab xline in xfile fürs FMS aufbereiten
lda xfile+1=$87d+1  ; ab xfile steht nun "Dn:", n ist das Default-Laufwerk

Sollte da lt. Doku nicht Y auf 0 gesetzt werden vor dem 'xmove' Aufruf?

Stimmt, das habe ich im Codeschnipsel vergessen. Sehr gut bemerkt!

Im wesentlichen wird es in XDOS 2.5 eine bessere Unterstützung des H:-Geräts in Emulatoren, ein flexibles XDOS-Treibermodell und einen internen MAP-Befehl geben. Dafür entfallen (neben ein paar Kleinigkeiten) die XF551-Unterstützung und die 14K-Ramdisk unter dem OS - beides lässt sich aber per XDOS-Treiber in DOS.SYS "nachrüsten" (auf Kosten eines höheren LOMEM). Das trägt dem Trend "weg von Disklaufwerken - hin zu SIO2XX-Geräten und Emulatoren" Rechnung.