Hi,

da ich nun einige Verbesserungswünsche zum XDOS bekommen habe, mache ich eine neue XDOS-Version. Hier könnt Ihr Wünsche eintragen und Kommentare zu den Wünschen loswerden. Ich liste mal die auf, die ich bisher bekommen habe:

* Syntaxfehler bei Formatierbefehlen sollen zu einer Fehlermeldung führen
Gibt man derzeit in XDOS z.B. "FD# 2" (das Semikolon fehlt), führt das derzeit dazu, dass das Standardlaufwerk formatiert wird. Kein Problem, die Korrektur kostet nur 8 Byte Platz in XDOS

* Echte Quad Density (360KB-Format) statt dem F2#-Format (2x180KB)
Hab ich mir auch überlegt - gerade beim Programmieren ist man doch recht schnell bei 180KB angelangt. Und mit den SIO2X-Geräten kann jeder auch ohne XF551 Quad benutzen. Leider kostet Quad etwa 100 Byte Platz, die ich zumindest zum Teil an anderer Stelle wieder einsparen muss (Vorschläge siehe unten) - XDOS soll ja nicht zu groß werden. Ich würde das MyDOS-360KB-Format nehmen und nicht das Turbo- oder Bibo-DOS-Format. Der Befehl F2# würde durch FQ# ersetzt.
Problem: Die Anzeige der freien Sektoren im Directory ist nur 3stellig, aber es wird über 1400 freie Sektoren geben ...


Was könnte wegfallen?

* Die XDOS-Info-Zeile (mit LOMEM und den ersten 8 Byte der Konfiguration)
Wird bisher von 2 Usern als zu "kryptisch" empfunden. Einer wollte sogar eine Möglichkeit, die Infozeile abzuschalten (habe ich auch eingebaut). Ein Wegfall der Infozeile würde 50 Byte Platz bringen

* Atari DOS 1-Unterstützung
Das ist eigentlich nur noch aus historischen Gründen drin. DOS 1-Dateien gibt es praktisch nicht, das Lesen von solchen Dateien muss also eigentlich auch nicht mehr unterstützt werden. Bringt etwa 20 Byte Platz.

* Adresse $15C8
Eigentlich ein illegaler Einsprung in DOS 2.5, der aber von AUTORUN.SYS-Progs gerne benutzt wird, um BASIC-Programme zu starten. Außerdem gibt es ein paar BASIC-Programme, die $15C8 benutzen, um COM-Dateien zu laden. Sogar ein kommerzielles Programm (Startexter) benutzt $15C8. Bringt auch nur 12 Byte Platz.

* Letzte Dir-Zeile immer in der Form "xxx FREE #yy <z>"
Außerhalb des DUP ist derzeit die letzte DIR-Zeile "xxx FREE SECTORS" (genau wie bei DOS 2.5). Das könnte ich in "xxx FREE #yy <z>" ändern - wie im DUP. Allerdings gibt es ein paar BASIC-Programme, die DIR-Zeilen mit "FREE SECTORS" vergleichen, um das Ende des Directory zu erkennen. Diese Programme würden dann nicht mehr mit XDOS laufen - dazu gehören z.B. ZONG-Disks. Würde aber immerhin 23 Byte Platz bringen.

* Text-Hintergrundfarbe ändern (in der XDOS-Konfiguration)
Ein Wegfall würde 14 Byte Platz bringen.

* Shift-Return (als Kürzel für "DIR 8;")
Ein Wegfall würde 10 Byte Platz bringen. Dieses Kürzel benutze ich selbst allerdings recht oft.

* Befehl AUT (um AUTORUN.SYS zu starten)
Ein Wegfall bringt nur 5 Byte Platz (die 3 Buchstaben AUT und die Adresse der AUTORUN.SYS-Laderoutine)

* CAR-Adresse (Back-Adresse)
Ein Wegfall würde 8 Byte Platz bringen.

Was meint Ihr dazu?

Hallo Dietrich,

ich fände es klasse, wenn XDOS (evtl. optional per "Treiber" und dann mit bewusstem Verzicht auf einige KB RAM) auf SpartaDOS/BeWeDos-kompatible große Diskformate/Images zugreifen könnte. Gerade heutzutage, wo es SIO2USB etc gibt, wäre dieses Feature extrem nützlich. Dies dürfte aber vermutlich eine größere "Operation" werden und evtl. den von Dir geplanten Rahmen sprengen...

Beste Grüße,

Michael

Hi,
meine Kommentare direkt unter deinem Text...

* Syntaxfehler bei Formatierbefehlen sollen zu einer Fehlermeldung führen
Gibt man derzeit in XDOS z.B. "FD# 2" (das Semikolon fehlt), führt das derzeit dazu, dass das Standardlaufwerk formatiert wird. Kein Problem, die Korrektur kostet nur 8 Byte Platz in XDOS

Ja, das muss dringend korrigiert werden, denn keiner formatiert sich gerne die falsche Disk...

* Echte Quad Density (360KB-Format) statt dem F2#-Format (2x180KB)
Hab ich mir auch überlegt - gerade beim Programmieren ist man doch recht schnell bei 180KB angelangt. Und mit den SIO2X-Geräten kann jeder auch ohne XF551 Quad benutzen. Leider kostet Quad etwa 100 Byte Platz, die ich zumindest zum Teil an anderer Stelle wieder einsparen muss (Vorschläge siehe unten) - XDOS soll ja nicht zu groß werden. Ich würde das MyDOS-360KB-Format nehmen und nicht das Turbo- oder Bibo-DOS-Format. Der Befehl F2# würde durch FQ# ersetzt.
Problem: Die Anzeige der freien Sektoren im Directory ist nur 3stellig, aber es wird über 1400 freie Sektoren geben ...

Tja, ich nutze 360k nur selten aber gerade die kleinen Kompatibilitätsunterschiede sind nervig. Das F2# Format scheint es ja nur bei dir zu geben, also wäre ein Wegfall vielleicht gar nicht so schlecht. Ansonsten würde ich auch das MyDOS 360k Format bevorzugen. Was ist da eigentlich anders als beim BiboDOS 360k Format ?!? Beide nutzen doch keine Sektor/Filelinks, sollten also bei 360k kompatibel sein (oder geht es nur um die Anzahl der DIR-Einträge 64 bei MyDOS vs. 128 bei BiboDOS)...?? Nunja, man könnte bei den free sectors ja wie beim DOS 2.5 wieder 999+ sectors anzeigen, auch wenn das nicht gerade schön aussieht (oder man macht es wie bei MyDOS 4.53, d.h. bis 999 sectors immer dreistellig, darüber bis 9999 sectors vierstellig - kostet aber bestimmt auch wieder Speicher)...

Was könnte wegfallen?

* Die XDOS-Info-Zeile (mit LOMEM und den ersten 8 Byte der Konfiguration)
Wird bisher von 2 Usern als zu "kryptisch" empfunden. Einer wollte sogar eine Möglichkeit, die Infozeile abzuschalten (habe ich auch eingebaut). Ein Wegfall der Infozeile würde 50 Byte Platz bringen

Ich bin einer der zwei und sage JA WEG DAMIT ! Es reicht doch völlig aus, wenn man sowas im Setup / Konfig. Programm einstellen kann (oder bei Bedarf die Einstellung dort nachschauen kann)... bei DOS II+D Version 6.1 gab es ja auch von den Polen ein ext. Setup Programm (in ML !) zu diesem Zweck, da konnte man alles bequem einstellen, ohne dass das DOS dazu mehr Speicher verbrauchte...

* Atari DOS 1-Unterstützung
Das ist eigentlich nur noch aus historischen Gründen drin. DOS 1-Dateien gibt es praktisch nicht, das Lesen von solchen Dateien muss also eigentlich auch nicht mehr unterstützt werden. Bringt etwa 20 Byte Platz.

Hä ?!? Gibt wohl absolut niemanden der sowas noch braucht - und auch niemanden, der DOS 1 nutzt oder jemals länger benutzt hat. Also WEG DAMIT !

* Adresse $15C8
Eigentlich ein illegaler Einsprung in DOS 2.5, der aber von AUTORUN.SYS-Progs gerne benutzt wird, um BASIC-Programme zu starten. Außerdem gibt es ein paar BASIC-Programme, die $15C8 benutzen, um COM-Dateien zu laden. Sogar ein kommerzielles Programm (Startexter) benutzt $15C8. Bringt auch nur 12 Byte Platz.

Würde ich so lassen, denn ich fände es nervig, wenn ich jedesmal im Autorun.SYS (oder im Basic-Programm) nachschauen müsste, warum es nicht mehr läuft oder selber Änderungen daran vornehmen müsste (zumeist würde ich dann einfach ein anderes DOS anstelle von XDOS nehmen und das ist sicher nicht im Sinne des Erfinders)...

* Letzte Dir-Zeile immer in der Form "xxx FREE #yy <z>"
Außerhalb des DUP ist derzeit die letzte DIR-Zeile "xxx FREE SECTORS" (genau wie bei DOS 2.5). Das könnte ich in "xxx FREE #yy <z>" ändern - wie im DUP. Allerdings gibt es ein paar BASIC-Programme, die DIR-Zeilen mit "FREE SECTORS" vergleichen, um das Ende des Directory zu erkennen. Diese Programme würden dann nicht mehr mit XDOS laufen - dazu gehören z.B. ZONG-Disks. Würde aber immerhin 23 Byte Platz bringen.

Hmm, ein paar Basic-Programme ?!? So ziemlich alle, die bei mir nach der DIR schauen suchen dann auch nach "FREE SECTORS" (und nicht nur nach "free" oder nur nach "sectors"), das ist vor allem bei engl.+amerikan. Programmen sehr verbreitet (da dort im DOS 2.0/2.5 ja FREE SECTORS drinsteht, während in der deutschen Variante glaube ich FREIE SEKTOREN oder so drinsteht). Es dürfte sich bei den Basic Programmen überwiegend um Anwendungen handeln (auch Auswahlmenüs), sowie um Spiele, bei denen Levels o.ä. (nach)geladen werden können... Naja, wenn es anders nicht geht, kann man darauf halt verzichten (vermutlich wird man eh nicht alle DOS 2.x Programme auf XDOS tunen können, ein paar werden wohl immer auf DOS 2.0 oder DOS 2.5 oder MYDOS oder sonstwas festgelegt sein)...

* Text-Hintergrundfarbe ändern (in der XDOS-Konfiguration)
Ein Wegfall würde 14 Byte Platz bringen.

Könnte ich mit leben ! Standardeinstellung vielleicht schwarzer Hintergrund mit weißer Schrift oder meeresblauer / marineblauer (Comode-Door blauer) Hintergrund mit weißer Schrift. Wer braucht schon 128 Farbmöglichkeiten (mit so "schönen" Farben wie braun, lila/violett, grün, etc.) für den DOS Hintergrund ?!? Also WEG DAMIT !

* Shift-Return (als Kürzel für "DIR 8;")
Ein Wegfall würde 10 Byte Platz bringen. Dieses Kürzel benutze ich selbst allerdings recht oft.

Oh, wußte ich gar nicht mehr, dass es das gibt. Im Turbo-DOS ist diese Kombo ein binary load für *.COM files (den ich in TD ständig benutze). Könnte ich durchaus drauf verzichten im XDOS...

* Befehl AUT (um AUTORUN.SYS zu starten)
Ein Wegfall bringt nur 5 Byte Platz (die 3 Buchstaben AUT und die Adresse der AUTORUN.SYS-Laderoutine)

Finde ich gut, bitte so lassen...

* CAR-Adresse (Back-Adresse)
Ein Wegfall würde 8 Byte Platz bringen.

Naja, wirklich nutzen tue ich die back adress nie - aber vielleicht ja andere ???

Was meint Ihr dazu?

Oh, ich habe nun genug gemeint... -Andreas Koch.

P.S.: Eine Lese-Möglichkeit von Bewe/Sparta Disks würde ich allenfalls als externes Programm (ein ML-File) vorsehen, das bei Bedarf eingeladen werden kann. XDOS muss und sollte das nicht ständig mit sich rumschleppen müssen... Noch besser wäre ein universeller DOS-Reader für DOS 3, DOS 4, DOS XE und Bewe-DOS (und somit auch Sparta und Sparta-DOS X und Real-DOS) Disks, wie gesagt, extern ladbar wie ein gewöhnliches ML-Programm...

Hallo,

meine Meinung:

* Syntaxfehler bei Formatierbefehlen sollen zu einer Fehlermeldung führen
Gibt man derzeit in XDOS z.B. "FD# 2" (das Semikolon fehlt), führt das derzeit dazu, dass das Standardlaufwerk formatiert wird. Kein Problem, die Korrektur kostet nur 8 Byte Platz in XDOS
-das ist gefährlich, daher lieber beheben

* Echte Quad Density (360KB-Format) statt dem F2#-Format (2x180KB)
Hab ich mir auch überlegt - gerade beim Programmieren ist man doch recht schnell bei 180KB angelangt. Und mit den SIO2X-Geräten kann jeder auch ohne XF551 Quad benutzen. Leider kostet Quad etwa 100 Byte Platz, die ich zumindest zum Teil an anderer Stelle wieder einsparen muss (Vorschläge siehe unten) - XDOS soll ja nicht zu groß werden. Ich würde das MyDOS-360KB-Format nehmen und nicht das Turbo- oder Bibo-DOS-Format. Der Befehl F2# würde durch FQ# ersetzt.
Problem: Die Anzeige der freien Sektoren im Directory ist nur 3stellig, aber es wird über 1400 freie Sektoren geben ...
-hm, wie kompatibel ist das dann? nutze ich nicht wirklich, daher mir eher egal.


Was könnte wegfallen?

* Die XDOS-Info-Zeile (mit LOMEM und den ersten 8 Byte der Konfiguration)
Wird bisher von 2 Usern als zu "kryptisch" empfunden. Einer wollte sogar eine Möglichkeit, die Infozeile abzuschalten (habe ich auch eingebaut). Ein Wegfall der Infozeile würde 50 Byte Platz bringen
-kann weg, nutze ich fast gar nicht. Dann ist aber ein Konfig-prg nötig

* Atari DOS 1-Unterstützung
Das ist eigentlich nur noch aus historischen Gründen drin. DOS 1-Dateien gibt es praktisch nicht, das Lesen von solchen Dateien muss also eigentlich auch nicht mehr unterstützt werden. Bringt etwa 20 Byte Platz.
-raus! DOS 1 benutzt doch nun wirklich keiner, oder?

* Adresse $15C8
Eigentlich ein illegaler Einsprung in DOS 2.5, der aber von AUTORUN.SYS-Progs gerne benutzt wird, um BASIC-Programme zu starten. Außerdem gibt es ein paar BASIC-Programme, die $15C8 benutzen, um COM-Dateien zu laden. Sogar ein kommerzielles Programm (Startexter) benutzt $15C8. Bringt auch nur 12 Byte Platz.
-keine Meinung, da ich es nicht ganz verstehe

* Letzte Dir-Zeile immer in der Form "xxx FREE #yy <z>"
Außerhalb des DUP ist derzeit die letzte DIR-Zeile "xxx FREE SECTORS" (genau wie bei DOS 2.5). Das könnte ich in "xxx FREE #yy <z>" ändern - wie im DUP. Allerdings gibt es ein paar BASIC-Programme, die DIR-Zeilen mit "FREE SECTORS" vergleichen, um das Ende des Directory zu erkennen. Diese Programme würden dann nicht mehr mit XDOS laufen - dazu gehören z.B. ZONG-Disks. Würde aber immerhin 23 Byte Platz bringen.
-eigentlich kanns raus. Ende des DIR macht man über eine Fehlerabfrage, nicht per Textvergleich. Andererseits, wenn "viele" das so gemacht haben, aus Kompatibilitätsgründen lassen

* Text-Hintergrundfarbe ändern (in der XDOS-Konfiguration)
Ein Wegfall würde 14 Byte Platz bringen.
-das geht doch zur Not auch indem man die Farbe ändert, dann die Adresse mit Append ans Dos anhängt, oder?

* Shift-Return (als Kürzel für "DIR 8;")
Ein Wegfall würde 10 Byte Platz bringen. Dieses Kürzel benutze ich selbst allerdings recht oft.
-drinlassen

* Befehl AUT (um AUTORUN.SYS zu starten)
Ein Wegfall bringt nur 5 Byte Platz (die 3 Buchstaben AUT und die Adresse der AUTORUN.SYS-Laderoutine)
-kann raus, kann man ja auch "AUT-" tippen und dann starten

* CAR-Adresse (Back-Adresse)
Ein Wegfall würde 8 Byte Platz bringen.
-behalten!

Moin,

Dietrich hat geschrieben:Hi,

da ich nun einige Verbesserungswünsche zum XDOS bekommen habe, mache ich eine neue XDOS-Version. Hier könnt Ihr Wünsche eintragen und Kommentare zu den Wünschen loswerden. Ich liste mal die auf, die ich bisher bekommen habe:
[...]
Was meint Ihr dazu?

Zu den einzelnen Punkten kann/mag ich noch nichts sagen, da ich mich noch nicht lange mit XDOS (oder überhaupt irgendeinem alternativem DOS als DOS 2.5) beschäftigt habe.

Generell mein Statement:

- Entferne nichts, was die Kompatibilität zu Atari-DOS & Co. erhöht. Nichts ist ärgerlicher, als wenn für eine Handvoll Programm wegen 20 eingesparter Bytes dann eine extra Systemdisk mit extra DOS gebastelt werden muß

- Eher "freakige" Sachen wie F2# usw. als externe Tools á la Sparta-DOS zur Verfügung stellen.

Um letzteres bereit zu stellen, kannst Du ja XDOS (falls das schon nicht der Fall ist...) so umbauen, daß "Befehle" zum Laden von Programmen erst auf dem aktuellen Laufwerk, dann auf D8: gesucht werden. Oder einen MS-DOS like "PATH" Befehl einbauen, wobei das vermutlich viel mehr Code erfordert als bei aktivierter RAM-Disk auch auf dieser zu schauen.

So kann man sich mittels Batch etc. eine Systemdisk etc. zusammenbauen, auf der die wichtigsten externen Kommandos (wie MAP.COM usw.) einfach in die RAM-Disk kopiert werden und dort zur Verfügung stehen.

Gruß, Jürgen

Hmmm,
ich vermute mal XDOS lädt standardmäßig *.COM Files, d.h. es wird beim teilweise eintippen des (ML) Namens der Rest des Namens und der Extender .COM angehängt...

Dadurch dürfte ein AUT- (ohne die AUT Funktion) nicht funktionieren, denn das XDOS würde dann vermutlich versuchen ein AUT*.COM zu laden, anstelle eines AUT*.SYS...

Und damit dann doch das Autorun.SYS File geladen wird, müsste wahrscheinlich wieder die AUT Routine her die die 5 Bytes Platz extra beansprucht - oder nicht Stefan ?!?

Gruß, Andreas Koch.

Die Idee mit der externen Konfiguration der Infozeile klingt nicht schlecht. Dann könnte man von dort auch die Farbe einstellen.

Was sicherlich auch nicht schlecht wäre, ist eine Masterdisc, mit der man sich sein DOS so erstellt, wie man es benötigt. Also ähnlich dem TurboDOS.

Dann kann man entscheiden, was das FD# bewirkt, ob und wie man eine Infozeile (z.B. oben oder unten) braucht, welche Farbe man haben möchte und eventuell auch, welche Sicherheiten man will.

Man könnte so vielleicht ein XDOS generieren, das erheblich weniger Platz braucht, wenn man quasi ein light konfiguriert, oder man hat eine Version mit maximalem Komfort, die auch mehr Speicher frißt.

Hallo @ All

hallo Dietrich,

auch wenn ich gleich Haue bekomme, bitte NICHT sowiel ändern. Wer ein anderes DOS möchte, kann ein anderes Dos laden. Eine "Eierlegende Wollmilschsau" wird es sowieso nie geben. Klein, alles drin, 100 % kompatibel, was vergessen ??

FD# mit Bestätigung/ Fehlermeldung ist sicher gut.
Quad ist gut, aber nur Mydos ODER Sparta ODER BiBoDos
nachladen von Befehlen von mir aus.

Bytes sparen:

Bringt es was bei den RD Verwaltung(en) zu sparen, RD hinter dem ROM wird es wirklich benötig? Oder RD Treiber nachladen?

F2# kann raus

Du hast nach Wünschen gefrag..
RD (bis 256k reicht) konfiguration wie im MyDos via Pagesequenz und
(unwichtig) evtl. mehrfaches Laden zulassen für mehr als 256k Erweiterungsspeicher.

Es ist jetzt schon ein prima DOS!!
Nicht vergessen wir haben ja auch noch Qmeg... ein starkes Team

Schönen Sonntag

CharlieChaplin hat geschrieben:Hmmm,
ich vermute mal XDOS lädt standardmäßig *.COM Files, d.h. es wird beim teilweise eintippen des (ML) Namens der Rest des Namens und der Extender .COM angehängt...

Dadurch dürfte ein AUT- (ohne die AUT Funktion) nicht funktionieren, denn das XDOS würde dann vermutlich versuchen ein AUT*.COM zu laden, anstelle eines AUT*.SYS...

Und damit dann doch das Autorun.SYS File geladen wird, müsste wahrscheinlich wieder die AUT Routine her die die 5 Bytes Platz extra beansprucht - oder nicht Stefan ?!?

Gruß, Andreas Koch.

ich gehe mal davon aus, dass aus
AUT-
AUT*.* wird was wiederum zu
AUT?????.??? wird
und das erste File das darauf passt wird geladen, wenn es ein ML File ist, was man am Header des Files erkennt und nicht an der Endung.

Kurzer Test bestätigt das. MAP.COM erst umbenannt in MAP.CON, laden geht. Dann MAP.CON in AUTORUN.SYS umbenennt. Geht auch mit AUT- zu laden, fragt halt nochmal nach mit LOAD AUTORUN.SYS (Y)

Wow,

danke für das schnelle und umfangreiche Feedback - damit lässt sich was anfangen . Ich fasse mal zusammen:
- Umfassende DOS 2.5-Kompatabilität soll gewährleistet bleiben, $15C8 und "FREE SECTORS" bleibt also drin
- Die Infozeile und DOS 1-Unterstützung kommt raus - das bringt 70-80 Byte Platz.
- F2#: Werde ich wohl entfernen - dieses Format ist ja eigentlich nur eine Verlegenheitslösung wegen der fehlenden Quad Density.
- Quad 360KB: Habe ich nun untersucht - das kostet 130 Byte Platz, wenn ich nichts übersehen habe. Ärgerlich ist, dass ich dafür 40 Byte eigentlich unnötigen Extracode brauche, um Schwachstellen der XF551 und der Happy/Speedy auszubügeln Ich werde LOMEM also leicht anheben müssen, wenn ich das einbaue - weiß noch nicht, ob ich das wirklich mache.
- Externes Konfigprogramm: OK, werd ich dann mal machen.

dl7ukk hat geschrieben:RD (bis 256k reicht) konfiguration wie im MyDos via Pagesequenz und (unwichtig) evtl. mehrfaches Laden zulassen für mehr als 256k Erweiterungsspeicher.

Eine Pagesequenztabelle gibt es auch in XDOS - allerdings werden hier immer 4 16KB-Bänke zu einem 64KB-Block zusammengefasst. Die 4 Byte große Tabelle findet sich ab $71C. RAM-Disks bis zu 256KB Größe sind möglich.

dl7ukk hat geschrieben:Bringt es was bei den RD Verwaltung(en) zu sparen, RD hinter dem ROM wird es wirklich benötig? Oder RD Treiber nachladen?

Das ist z.B. für XL-User ohne Speichererweiterung interessant, die dort einen Assembler reinkopieren können, um diesen abwechselnd mit BASIC zu nutzen. Aber immerhin - das Weglassen der 14KB-Ramdisk würde über 30 Byte Platz bringen Was meint Ihr?

pps hat geschrieben:Die Idee mit der externen Konfiguration der Infozeile klingt nicht schlecht. Dann könnte man von dort auch die Farbe einstellen.

Klar - aber nach einem Reset wäre die Farbe ja wieder weg. Daher muss - wenn es möglich sein soll, die Farbe im XDOS einstellbar sein. Werd ich wohl drinlassen - auch ich benutze das ab und zu.

CharlieChaplin hat geschrieben:Ansonsten würde ich auch das MyDOS 360k Format bevorzugen. Was ist da eigentlich anders als beim BiboDOS 360k Format ?!? Beide nutzen doch keine Sektor/Filelinks, sollten also bei 360k kompatibel sein (oder geht es nur um die Anzahl der DIR-Einträge 64 bei MyDOS vs. 128 bei BiboDOS)...??

Es geht um zweierlei: Einerseits die 128er DIRs und die veränderte Sector-Link-Methode. Beides ist blöd, weil sie sich im Gegensatz zu MyDOS beim Lesen des Dirs nicht erkennen lassen - man muss jedes mal beim Fileöffnen die VTOC lesen. Außerdem ist das MyDOS-Format flexibler, weil nicht auf 360KB beschränkt.

tfhh hat geschrieben:Um letzteres bereit zu stellen, kannst Du ja XDOS (falls das schon nicht der Fall ist...) so umbauen, daß "Befehle" zum Laden von Programmen erst auf dem aktuellen Laufwerk, dann auf D8: gesucht werden.

Wäre möglich, kostet aber wahrscheinlich um die 50 Byte Platz. Legt sonst jemand Wert darauf (im Vergleich mit Quad)?

Dietrich hat geschrieben:

pps hat geschrieben:Die Idee mit der externen Konfiguration der Infozeile klingt nicht schlecht. Dann könnte man von dort auch die Farbe einstellen.

Klar - aber nach einem Reset wäre die Farbe ja wieder weg. Daher muss - wenn es möglich sein soll, die Farbe im XDOS einstellbar sein. Werd ich wohl drinlassen - auch ich benutze das ab und zu.

Wenn man direkt das DOS.SYS verändert, wo der lda #xx sta 710 (werden wohl eher die passenden Schattenregister sein) etc. kommt, bleibt doch auch beim Reset die Farbe erhalten.

pps hat geschrieben:

Dietrich hat geschrieben:

pps hat geschrieben:Die Idee mit der externen Konfiguration der Infozeile klingt nicht schlecht. Dann könnte man von dort auch die Farbe einstellen.

Klar - aber nach einem Reset wäre die Farbe ja wieder weg. Daher muss - wenn es möglich sein soll, die Farbe im XDOS einstellbar sein. Werd ich wohl drinlassen - auch ich benutze das ab und zu.

Wenn man direkt das DOS.SYS verändert, wo der lda #xx sta 710 (werden wohl eher die passenden Schattenregister sein) etc. kommt, bleibt doch auch beim Reset die Farbe erhalten.

So wie ich das verstehe ist das ja bisher im XDOS so, und die Frage ist ob dieser lda #xx sta 710 eingespart werden kann.

Dietrich hat geschrieben:...
Ich werde LOMEM also leicht anheben müssen, wenn ich das einbaue - weiß noch nicht, ob ich das wirklich mache.
...

Wenn Du wirklich mit Speicherplatz knausern möchtest und bestimmte Programmteile nie gleichzeitig gebraucht werden, kann man diese ja auch packen und 'on demand' entpacken/anspringen. Ich habe das mal vor Urzeiten gemacht und gerade bei den Opcodes kann man gut ein Verhältnis von 1:2 erreichen was die Entpackroutine schnell wieder amortisiert...

Gruß
Irgendwer

Also,
ehrlich gesagt könnte ich auf das 360k Format in XDOS 2.5 auch verzichten. In 98% der Fälle nutze ich eh nur 90k/130k/180k...

Wenn du erst einmal das 360k Format unterstützt musst du dir, wie schon gesagt, Gedanken wegen der DIR-Einträge (64 oder 128), wegen der Free Sector Anzeige (3 oder 4 stellig), wegen XF551 und Happy/Speedy Bugs (z.B. Umschaltung von DSDD auf SSSD) und was weiß ich noch alles machen.

Vermutlich kommt dann auch sofort jemand der 720k und 1440k haben will und dazu auch Subdirs (und Harddisk-Partitionen bis 16MB, sprich ein MyDOS ohne all dessen Bugs und halt Kommandozeilen-orientiert)...

Vielleicht machst du ja einfach auch zwei Versionen von XDOS, eine kleine+schlanke Version (nur DOS.SYS bzw. XDOS 2.5) die max. 180k unterstützt und eine "große" + umfangreichere Version (mit DUP.SYS), die das MyDOS übertrumpft. Hattest du sowas nicht eh mal vorgehabt ?!?

Gruß, Andreas Koch.

Hi Charlie,

hmm, ich glaube Du hast recht. Quad lohnt sich nicht so recht - der Platzbedarf ist doch recht groß. Aber immerhin weiß ich jetzt, was ich aus XDOS rauswerfen könnte, um noch andere Sachen unterzubringen: Infozeile, DOS 1-Unterstützung, F2#, XL-Ramdisk (immer noch möglich mit Konfigprogramm - so wie bei TurboDOS). Macht insgesamt knapp 140 Byte Platz - das ist echt eine Menge

Ich werde also erstmal nur ein kleines Update auf XDOS 2.43 machen.