Hi, ich sehe mir gerade MYDOS genauer an:

1) Mit Pick Directory kann man ein Standard-Laufwerk+Pfad wählen, auf das man dann mit "D:" zugreifen kann. Wenn man in ein Unterverzeichnis geht und dann die Disk wechselt, sieht es aber so aus, als ob MYDOS das nicht bemerkt und weiter direkt auf die Sektoren des (auf der gewechselten Disk) nicht vorhandenen Unterverzeichnisses zugreift. D.h. MYDOS bemerkt Diskwechsel offenbar gar nicht, oder?

2) Auf einer 16MB-Disk/Partition gibt es 33 VTOC-Sektoren. Wenn man nun ein File speichert, liest MYDOS dann immer die ganze VTOC, um freie Sektoren zu suchen, oder merkt sich MYDOS irgendwo (wo?) auf der Disk/Partition den ersten nicht voll belegten VTOC-Sektor, um die VTOC-Suche abzukürzen?

3) Die VTOC-Bytes 6-9 in Sektor 360 sind auf DOS 2.x-Disks frei. Gilt das auch für MYDOS-Disks/Partitionen? (es sieht ganz so aus)

4) Wenn man mit Pick-Directory einen Standard-Pfad auf D1: einstellt und dann auf D2:, ist der Pfad für D1: wieder weg. Ist das Absicht oder nur aus Platzgründen so (man müsste dafür ja pro Laufwerk einen Pfad im RAM halten)?

Gruß Dietrich

Hallo Stefan

Letzteres ist Absicht. Ich habe aber den Eindruck, dieses könnte sich demnächst ändern.

Der Diskwechselfehler ist mir auch schon aufgefallen. Kann mich aber nicht mehr erinnern ob der jetzt gekillt worden ist, oder nicht. Ich mach im Moment mit dem Atari bitter wenig und die Mappe mit den gedruckten Emails von Lee ist schon mehrere cm dick.
Ich werde deine Fragen weiterleiten an Lee, der im Moment an MyDOS rumbastelt. Hast Du schon die letzte Version von MyDOS (4.55 beta 4)? Du findest sie auf meiner MyDOS Seite.

Tschüß

Mathy

Ähem,

auf atari-age hat man sich kürzlich auch ein wenig zu MyDOS ausgetauscht und Fragen+Wünsche geäußert. Wenn ich mich nicht gänzlich irre, hat sich Lee Barnes (der immer wieder mal an MyDOS herumdoktert und Bugs entfernt) dort unter dem Pseudonym 1050 gemeldet... muss aber zugeben, dass ich nicht alle Fragen der Spartaner bzw. SDX-Fraktion verstanden habe.

Der interessante Teil beginnt ab ca. Post #15 ff.:
http://www.atariage.com/forums/topic/17 ... ard-disks/

Ggf. kannst du ja auch dort mal nachfragen. Es gab auch schon weitere Topics bei atari-age zum Thema MyDOS (mal die Suchfunktion aufrufen und MYDOS eingeben)... Gruß, Andreas Koch.

Dietrich hat geschrieben:"D:" zugreifen kann. Wenn man in ein Unterverzeichnis geht und dann die Disk wechselt, sieht es aber so aus, als ob MYDOS das nicht bemerkt und weiter direkt auf die Sektoren des (auf der gewechselten Disk) nicht vorhandenen Unterverzeichnisses zugreift. D.h. MYDOS bemerkt Diskwechsel offenbar gar nicht, oder?

Da triffst du den Nagel auf den Kopf, genauso verhält es sich. MyDos prüft nicht nach, ob es sich bei einem Wechsel um die gleiche Diskette handelt.

Dietrich hat geschrieben: Wenn man mit Pick-Directory einen Standard-Pfad auf D1: einstellt und dann auf D2:, ist der Pfad für D1: wieder weg. Ist das Absicht oder nur aus Platzgründen so (man müsste dafür ja pro Laufwerk einen Pfad im RAM halten)?

Ich denke mal es war der Einstieg des Programmieres in die Unterverzeichnissstruktur und ist bis heute so geblieben.

Bei den anderen Fragen kann ich dir leider keine Anwort dazu geben. Auf Mathy´s Webseite findest du auch den Quelltext von MyDos , vielleicht hilft dir dieser weiter.

Viele Grüße,
Bernd

Hallo Stefan

Beim Übersetzen der ersten Frage hab' ich mich vertan. Da ist das word "not" irgendwie rausgerutscht. Ich glaube aber, Lee gibt trotzdem die richtige Antwort in der letzte Zeile unter Punkt 1). Ich werd da nachher noch mal nachhaken.

Mathy,
Hi.

Stefan Dorndorf has a couple of questions about MyDOS, maybe you can answer them:

Yeah - maybe!!

1) Will MyDOS check if we changed disks when we are using the default directory?
No, it does not use the unique disk number systems that Sparta does to verify that the disk mounted is the
same one it accessed the last time it accessed it. So it can not know if the disk is the same or not.
This will usually not be a problem since most subdirectory work is NOT done on floppies, which is the only
place where this can really be a common problem? A solution doesn't seem to be worth the trouble of
pursuit? At least currently, no one has this problem enough to mention it so far.
What MyDOS will do is check that the full path statement is a valid one. And if there is a defect along
these lines, the default drive path is set to the root of the drive being used. IIRC.

2) Does MyDOS always read the complete VTOC (even on a 16MB disk) if you want to save a file or does MyDOS
remember somehow, where the first VTOC-sector is that has an empty sector entry in it?
It reads the complete VTOC string of sectors, starting from the first VTOC sector 360 until it hits a
sector that isn't being used represented by a set bit. It has no way to 'remember' which VTOC sector to
start looking at first, so it must start at the first one and proceed downwards from there.

3) VTOC bytes 6-9 in sector 360 are free on DOS 2.x disks. Is this true for MyDOS too?
Yes, I've always thought Atari/OSS and MyDOS should have used another pair of bytes here to hold the full
size of the disk as formatted, but they didn't ask me what I thought. MyDOS's only modification to the
standard VTOC bytes is the 'Type' byte at offset zero - 2 for DOS 2.0s compatible floppy disks and 3 or
more for disks that have 1040 or more sector capacity. This Type byte value should be the count of VTOC
sectors used plus one, but can not be such for the single exception of a DSDD floppy which must have a type
byte of 3 even though it only has one VTOC sector. Currently MyDOS uses a mugged number which is often one
or more above the system I've outlined above and it causes ramdisks in particular to be fouled such that
troubles ensue if one reserves a critical amount of ram for another use such as FlashJazzCat's
wordprocessor before MyDOS formats the ramdisk at it's now custom reduced size. This defect must be
corrected and it results in a 'one less' number being used which is actually more in line with the original
concept of what the value should be. Marslett likely just let it be bloated by one or more in order to
cover the DSDD disk exception without doing the extra work it takes to allow for that one exception. He
didn't check for problems with custom sized ramdisks or he would have seen that the munge solution can't
work as is. I call this use of a wrongly derived number a 'munge' but others will have a different take on
the word to be sure. And I don't care, it's wrong, and it needs to be changed especially if we go to mixed
density ramdisks of huge and floppy sizes. And I want to go there.

I feel there is no need to offer support for disk formats that can only exist in an emulator or a butchered
disk drive - so use either at your own risk and peril. I speak of double sided ED disks, and other bizarre
creatures that can only exist because someone hacked a 5.25 drive to do 3.5 disks using the same 5.25 OS
and didn't allow for the fact that there doesn't exist otherwise a double sided single density disk!!! To
write support for it into the current MyDOS code is too much work, costs too much in memlo, and Sparta does
not cover these oddballs either, so I say to hell with all of them. Once you get to true Double Density,
you should not be able to use any sector size smaller than 256 bytes again. And you must use Double
Density with Double Sidedness only. Just my opinion on that matter, I can't force anyone to comply.

4) If I set a default directory for D1: and then do the same for D2:, the default dir for D1: is gone. Is
this intended or just done to save memory.
A little bit of both? As Draco pointed out in Atari Age, MyDOS is not subdirectory friendly or at least
doesn't seem to be built to use them easily. The addition of a single 40 character buffer to hold the
default directory string was probably thought to be extravagant at the time way back when - now it needs
eight more of those to hold the default strings for all drives so they don't disappear when changed as you
just pointed out. I consider the use of subdirectories in MyDOS to be more of a hack job than anything
else, and the miracle is they made it work as well as it does!! Now to make it work like SDX and MS-DOS is
the real trick, but we will try very hard to do so. By adding xio 44 and xio 48 support that is comparable
to SDX at least. And finding room for the eight more buffers or other means to hold paths for all drives
possible. And other goodies.

Much respect Stefan, any more questions please feel free to ask. We take opinions too!!
Lee

Tschüß

Mathy

Ups, der MYDOS-Sourcecode ist öffentlich - stimmt, da war doch was, ist mir entfallen. Da hätte ich mir diesen Thread auch sparen können

Danke, Mathy, für Deine Übersetzungskünste Dann versuch ich mich mal in Englisch:


Background of my questions: I want to expand XDOS with MYDOS compatible subir and large disk support and therefore I need to know exactly the specs of the MYDOS file system.

Lee hat geschrieben:This will usually not be a problem since most subdirectory work is NOT done on floppies, which is the only place where this can really be a common problem?

Nowadays there exist SIO2XX devices where large images with subdirs may be swapped more often ...
For XDOS, I plan to add a random disk id stored in the VTOC bytes 6 and 7, similiar to SpartaDOS: Byte 6 is non zero (to identify normal MYDOS and ATARI DOS images), Byte 7 is incremented on every VTOC change (to check for copied images).

Lee hat geschrieben:It reads the complete VTOC string of sectors, starting from the first VTOC sector 360 until it hits a sector that isn't being used represented by a set bit. It has no way to 'remember' which VTOC sector to start looking at first ...

So MYDOS doesn't support this. Maybe XDOS will do by using byte 8 of the VTOC ...

Lee hat geschrieben:This Type byte value should be the count of VTOC sectors used plus one ...

Sure? I figured out that the type byte is the number of VTOC blocks plus 2. A block is always 256 Byte, i.e. 1 DD sector or 2 SD sectors. E.g. a 16 MB image has 33 VTOC blocks (33 sectors with 256 bytes each) and thus the type byte is 35. A 130 KB image has 1 VTOC block (2 sectors with 128 bytes each), thus the type byte is 3. See also the routines ALLOC (MAPBUF-CURMP-3 >= 0) and RWBMAP (if SD read/write 2 secs instead of 1) in the MYDOS sources.

Lee hat geschrieben:.. but can not be such for the single exception of a DSDD floppy which must have a type byte of 3 even though it only has one VTOC sector.

A DSDD floppy has 360 KB = 1440 sectors and therefore needs 1 VTOC block. Thus the type byte is 1+2 = 3. The exact formula for the type byte is: (s+80)/2048+2 rounded up, where s is the number of sectors. Some more examples: A 2 MB DD image has 8192 sectors, 5 VTOC blocks and a type byte of 7. A 2 MB SD image has 16384 sectors, 9 VTOC blocks (2 sectors each) and a type byte of 11.

Lee hat geschrieben:.. and it causes ramdisks in particular to be fouled such that troubles ensue if one reserves a critical amount of ram for another use such as FlashJazzCat's wordprocessor before MyDOS formats the ramdisk at it's now custom reduced size.

I don't understand this. If a program uses RAM banks for itself, the RAM disk must be configured appropriately - otherwise there will be problems obviously.

Lee hat geschrieben:I feel there is no need to offer support for disk formats that can only exist in an emulator or a butchered disk drive - so use either at your own risk and peril.

As I understood MYDOS, all possible SD and DD formats are supported: The menu command O allows an arbitrary number of sectors. I tried some image sizes and MYDOS put a correct VTOC on every image.

Hallo Stefan

Ich habe 'ne Antwort bekommen von Lee. Wenn ich die aber ausdrucke (und schrumpfe auf 96%), dann sind's drei Seite A4 Format. Soll ich die Antwort hier reinkopieren, oder sie dir als Mail schicken. Falls letzteres bevorzugt wird, brauche ich noch diene Mailadresse.

Tschüß

Mathy

Hi Mathy,

kannst Du das nicht anhängen? Natürlich nur wenn es für Andere auch interessant ist!

Nö, das ist nicht soooo interessant. Lee ist fest davon überzeugt, dass MyDOS Byte 0 in Sektor 360 in einigen Fällen falsch schreibt, und versucht mich davon zu überzeugen. Hier die interessanten Stellen:

Lee hat geschrieben:Or to put it more accurately, the type byte value should be the count of extra VTOC sectors used plus 2. With an exception made for the DSDD disk. All in a vain attempt to maintain a 'status quo' that is simply WRONG - it will be corrected in future versions - this is NOT negotiable - it's a bug that must be eradicated and it will be. Even if the existing formula makes sense to you, ramdisks often have the wrong VTOC, why is this acceptable to anyone?

No, the VTOC of ramdisks is also correct. I tested some ramdisks including 1024K and 1008K. I tested also 360K-DD, 720K-DD, 2MB-SD, 2MB-DD and 16MD-DD ATR images and in all cases the type byte is the number of VTOC blocks + 2 (remember: a VTOC block has 256 bytes, i.e. 1 DD sector resp. 2 SD sectors).

If you set the type byte to the number of extra VTOC sectors + 2, your MyDOS version will be incompatible to MyDOS 4.53, since MyDOS uses the type byte to determine the number of VTOC sectors! For XDOS 3.0 I will follow the MyDOS 4.53 rules for the type byte, since I do not want to lose compatibility with MyDOS 4.53 disks.

Lee hat geschrieben:Fill the ramdisk up and look at it again, with normal MyDOS often there will be a wasted sector - how is an exact 720 sector disk supposed to exist starting with the wrong VTOC data? Short answer is, it can't. So the current situation is untenable.

Yes, 1 VTOC sector is wasted on SD disks/ramdisks if (#sectors+80) mod 2048 < 1024 (explanation see below), but this is intended and not a bug! Whether 1 SD sector is wasted or not, is of course no problem since there are lots of free sectors on a disk.

Dietrich hat geschrieben:A DSDD floppy has 360 KB = 1440 sectors and therefore needs 1 VTOC block. Thus the type byte is 1+2 = 3.

Lee hat geschrieben:But current MyDOS gives it a 4 type byte, because of the munge.

No, MyDOS 4.53/4 puts definitely a 3 type byte in sector 360 of a DSDD disk. I just verified it with a 360KB-DD-ATR! Perhaps you don't mean DSDD (double sided double density = 360K with 1440 DD sectors) but some other format!? Or you use another MyDOS version (there exist definitely too many).

Lee hat geschrieben:In the source it says that 'all large disks are assumed to be DD' which can be taken to mean 'we do not support SD disks of large sizes because it costs too much in code space to insure that it happens right for
those, so we are going to write code to do DD ONLY'.

No, MyDOS formats all large ramdisks in SD, not DD, so SD support for large disks is essentially! And it is built in MyDOS.

Lee hat geschrieben:A Ramdisk with $40 banks has nine sectors allocated for the extra VTOC sectors but only needs 8, the sector starting at 6f80h will never be used. It has a type byte of 7 but ten or more accurately, $A should be the value, again three short.

A Ramdisk with $40 16K banks (i.e. 1024K) has 8192 "sectors" with 128 bytes each. Every VTOC block (256 byte) holds the bits for 2048 sectors, thus 5 VTOC blocks are needed (including the 10 bytes for the header). Add 2 to get the type byte 7, which MyDOS correctly writes into the VTOC. This is not a bug.
Remark: You are right: 9 VTOC sectors are really needed, the 10th is unused. The reason is, that (on disks with more than 1024 sectors) MyDOS counts the VTOC length in blocks of 256 bytes, not in sectors. So on SD disks/ramdisks the number of VTOC sectors is even and thus sometimes 1 VTOC sector is wasted.

Lee hat geschrieben:A Ramdisk with $3f banks has seven 'extra' VTOC sectors reserved which is exactly right. The type byte is 6 but should be 9 which means by rights, 16 banks are not going to be ever used since MyDOS will run out of VTOCs to look at 2 VTOC sectors too soon?

A Ramdisk with $3f banks has 16 KB = 128 SD sectors less than a $40-Ramdisk, i.e. 8192-128 = 8064 sectors. So there are only 4 VTOC blocks needed, giving a type byte of 4+2=6. Furthermore, MyDOS does not run out of VTOC sectors while filling the ramdisk, I just tested it by completely filling the ramdisk. So the type byte and the MyDOS VTOC is OK.

Dietrich hat geschrieben:As I understood MYDOS, all possible SD and DD formats are supported: The menu command O allows an arbitrary number of sectors. I tried some image sizes and MYDOS put a correct VTOC on every image.

Lee hat geschrieben:You obviously have not used MyDOS long enough then if you really believe that first statement. Try copying a pretty full ED disk with J Duplicate Disk without using the sector numbers input option.

This is no VTOC bug. J fails, because it formats the destination disk incorrectly in single density instead of enhanced density - thus there are missing sectors on the destination disk. In other words, J doesn't detect the density of the source disk correctly. In general, the density management in MyDOS is really a mess.

Nächste Runde (ist auch diesmal nur ein Auszug):

Lee hat geschrieben:Or to put it more accurately, the type byte value should be the count of extra VTOC sectors used plus 2. With an exception made for the DSDD disk. All in a vain attempt to maintain a 'status quo' that is simply WRONG - it will be corrected in future versions - this is NOT negotiable - it's a bug that must be eradicated and it will be. Even if the existing formula makes sense to you, ramdisks often have the wrong VTOC, why is this acceptable to anyone?

Dietrich hat geschrieben:No, the VTOC of ramdisks is also correct. I tested some ramdisks including 1024K and 1008K. I tested also 360K-DD, 720K-DD, 2MB-SD, 2MB-DD and 16MD-DD ATR images and in all cases the type byte is the number of VTOC blocks + 2 (remember: a VTOC block has 256 bytes, i.e. 1 DD sector resp. 2 SD sectors).

Lee hat geschrieben:According only to your formula - but I don't care the slightest bit about that. I only care about stopping unpredictable overallocation of sectors that will cause problems with exact floppy disk size emulated ramdisks for the moment. Other huge ramdisks of the future will require exact allocations as well.

Hrm, the "overallocation" is precisely predictable: In SD one VTOC sector is unused if and only if #sectors+81 > 2048 and (#sectors+81) mod 2048 < 1024. So on SD disks/ramdisks smaller than 1968 sectors there is no wasted VTOC sector. Where is the problem with exact floppy disk size emulated ramdisks? Please provide a reproducable step by step example, where MyDOS fails due to a "wrong" type byte! Then I'll examine it.
Remark: The "overallocation" of course does not change the total size of disks/ramdisks, i.e. a disk/ramdisk defined with 720 sectors is always 720 sectors, not 719 or 721 or something else.

Lee hat geschrieben:Fill the ramdisk up and look at it again, with normal MyDOS often there will be a wasted sector - how is an exact 720 sector disk supposed to exist starting with the wrong VTOC data? Short answer is, it can't. So the current situation is untenable.

Dietrich hat geschrieben:Yes, 1 VTOC sector is wasted on SD disks/ramdisks if (#sectors+80) mod 2048 < 1024 (explanation see below), but this is intended and not a bug! Whether 1 SD sector is wasted or not, is of course no problem since there are lots of free sectors on a disk.

Lee hat geschrieben:I could care less about the ramdisk space lost - I care only because my 90K emulated floppy ramdisk won't behave as a real one if it's only got 719 sectors. Or worse 721 sectors or sometimes 722. It must run out at 720 EXACTLY.

It IS exactly 720 sectors, I tested it with custom Ramdisks. So where is the problem/bug? Do you have a reproducable example where this is not the case? Or are you only assuming that there is a bug?

Lee hat geschrieben:The munge provides for the 360K disk to work correctly - that's it's original purpose and it works, of course. And to your exact formula - but that doesn't mean it's right. The concept doesn't fit the formula, but the 360K disk does.

Look at the code of MyDOS and you'll find that my formula fits to the code. And forget the comments, there is a lot of nonsense in there, see the examples below. Where do you have the idea from that the type byte must be the number of extra VTOC sectors plus two?

Lee hat geschrieben:I have to make an exception for it in beta5 because otherwise MyDOS wants to allocate two VTOC sectors as being used when there is only the one. Marslett had the same problem until the put the munge into the wrong place and got all DD VTOCs with one extra digit for a type byte. The purpose of the munge is so that Marslett didn't have to write in an exception into the source code like I had to for it to allocate only one extra VTOC sector instead of two extra.

There is "no munge in the wrong place", the code is OK. According to the current MyDOS code, Marslett counts VTOC usage in blocks of 256 bytes, not sectors. This is no bug!

Lee hat geschrieben:It doesn't matter to him if all DD VTOCs are overcounted by one because of it since he is reading/writing VTOCs in pairs anyway - and then this is also the source of overallocation of only some SD ramdisks at unpredicable places as we reserve more and more banks for other purposes. But this is total ruination for my emulated floppy ramdisk(s). MyDOS deserves to have one or as many as wanted. With mixed densities and sizes as well.

No, DD VTOCs aren't overcounted by one. They have the correct size and correct type byte! And VTOCs are read/written in pairs only in SD, not in DD. And every ramdisk has exact the size it is defined, MyDOS doesn't access RAM outside the ramdisk! I wonder if you really tested your statements?

Lee hat geschrieben:... with one glaring exception, the 360K DSDD disk, it has one VTOC but still is a type 3 disk because it's 1,440 sector count is higher than 10 bits can convey which is 1,023 sectors. And that just doesn't fit a simple formula. Even if you've got one pretty darn close.

OK, this might be interesting for others: MyDOS operates on disks/ramdisks in two modes:

a) ATARI mode: If a disk/ramdisk has less than 1024 sectors and needs only one VTOC sector (SD: less than 944 secs, DD: less then 1024 secs), MyDOS uses ATARI mode: There is only one VTOC sector and MyDOS stores files with filenumbers and 10 bit sector links in the data sectors as DOS 2.x does. These files can be accessed by DOS 2.x. The VTOC type byte of such disks/ramdisks is always 2. Examples: 90K-SD, 180K-DD

b) MyDOS mode: Otherwise MyDOS uses MyDOS mode: There may be more than 1 VTOC sector and MyDOS stores files without filenumbers in its data sectors and uses 16 bit sector links. To distinguish these files from DOS 2.x files, MyDOS sets bit 2 in the file type byte. The VTOC type byte is the number of VTOC blocks (256 byte each) plus 2 - thus at least 3. All VTOC blocks are allocated from sector 360 downwards. Examples:
- 130K-SD (=ED) has 1 VTOC block, i.e. 2 VTOC sectors
- 360K-DD has 1 VTOC block, i.e. 1 VTOC sector
- 1024K-SD (1MB-Ramdisk) has 5 VTOC blocks, i.e. 10 VTOC sectors (one is unused)

Lee hat geschrieben:A Ramdisk with $3f banks has seven 'extra' VTOC sectors reserved which is exactly right. The type byte is 6 but should be 9 which means by rights, 16 banks are not going to be ever used since MyDOS will run out of VTOCs to look at 2 VTOC sectors too soon?

Dietrich hat geschrieben:A Ramdisk with $3f banks has 16 KB = 128 SD sectors less than a $40-Ramdisk, i.e. 8192-128 = 8064 sectors. So there are only 4 VTOC blocks needed, giving a type byte of 4+2=6. Furthermore, MyDOS does not run out of VTOC sectors while filling the ramdisk, I just tested it by completely filling the ramdisk. So the type byte and the MyDOS VTOC is OK.

Lee hat geschrieben:But I haven't tested to the depth that I'd like, so I can't say it does or doesn't just yet - either the old math or the new math version. Does MyDOS use the last data sector before the VTOC string and start flipping bits in the file data sectors? Can we make it do that? Scary stuff if it did. Did you look specifically for that? I never have.

No, MyDOS does not use the data sectors before the VTOC sectors, I tested it. There is really no bug in MyDOS concerning the type byte. Or did you find one? If yes, please provide a reproducable example, where MyDOS fails due to the type byte!

Lee hat geschrieben:For my needs, the VTOC overallocation of large SD disks is a bug that needs fixing and it will destroy your formula and it's workings - sorry. But not really, if it gets me a better MyDOS. Granted one that I can NOT mix hard drives with older versions at all, perhaps only in read only mode if that's possible?

As I already said, there is no bug with the type byte. See also my comments in the source below. But if you really want to change the type byte, you can set it e.g. to 128+x, which is currently not used by any MyDOS disk/ramdisk. Thus a check would be very easy.

Lee hat geschrieben:current mydos source
MAPBUF has already been loaded with the default value of 2 for a DOS 2.0s type byte starting value

SHORTS
JSR FNDBIT ; FIND LAST BIT MAP SECTOR
LDA TMP2
BNE GT246 ; IF PAST 256TH MAP BYTE
BIT DLINK ; SINGLE DENSITY?
BMI FDBDEN
CPY #0
BPL FDBDEN
The 'munge' is this part:
GT246
STA MAP2
CLC
ADC #3
STA MAPBUF
FDBDEN
which is setting up the wrong type byte

The comments here are very misleading. Here are my corrections:

SHORTS
JSR FNDBIT ; get index of last sector in the VTOC into y/tmp2 (low/high)
LDA TMP2 ; high byte
BNE GT246 ; not zero, i.e. VTOC is longer than 256 byte (incl. header)
; zero, i.e. VTOC has max. 256 bytes
BIT DLINK ; 125=SD, 253=DD
BMI FDBDEN ; Double density -> 1 VTOC sector needed -> use DOS 2.0 mode
CPY #0 ; low byte
BPL FDBDEN ; SD and VTOC is max. 127 bytes -> 1 VTOC sector needed -> use DOS 2.0 mode
GT246 ; more than 1 VTOC sector needed
STA MAP2 ; high byte of index of last sector in the VTOC = number of VTOC pages above one
CLC
ADC #3 ; +3
STA MAPBUF ; = number of VTOC pages plus 2 (fits again to my formula)
FDBDEN

Lee hat geschrieben:combined with this part:
LDA MAPBUF
SEC
SBC #2 ; GET NUMBER OF SECTORS
BIT DLINK ; (SINGLE DENSITY?)
BMI MPNSD ; IF NOT, M-3
ASL A ; IF SO, M*2-5
MPNSD
which is preparing to over allocate (some) SD VTOC sectors
Where is the minus 5 BTW? Or is that minus 2 times 2 then minus some x amount of change in your pocket? It seems to be minus 3 in the real world only for large SD but I've not checked every possible set up or size to verify that. I don't see where your formula fits M*2-5 but it's not a sticking point for me anyway.

In this case, the comments are simply nonsense. Here are my corrections:

LDA MAPBUF ; number of VTOC pages plus 2
SEC
SBC #2 ; number of VTOC pages
BIT DLINK ; 125=SD, 253=DD
BMI MPNSD ; Double density -> number of VTOC sectors (256 bytes each) = number of VTOC pages
ASL A ; Single density -> number of VTOC sectors (128 bytes each) = number of VTOC pages * 2
MPNSD

With these comments the code fits perfectly in my formula. In all cases the type byte is number of VTOC pages + 2 (for MyDOS type disks). There is no "munge in the wrong place".

OK, in some cases on SD disks the VTOC is one sector longer than really needed, but this happens only if you have at least 1968 SD sectors. So why do you bother if you have e.g. 1951 free sectors or 1950 free sectors? Yes, it's not perfect, but it really doesn't matter! If you change the type byte your new MyDOS will be incompatible to the 20 years used MyDOS 4.53 and thus later problems are predictable. Is an extra free sector (in some cases) worth this trouble?

I suppose, the comments in the current MyDOS source were added later by someone who tried to understand the code, but he failed obviously. Forget the comments (or take mine), look only at the code without using any assumptions about the type byte!

Addendum:

I now have looked through the VTOC building code of the MyDOS formatting routine. It's written complicated, but I now understand the comments before label MPNSD. They are correct, but misleading, because they are misplaced. The comments belong to the x register after the DEX before label ALCMPL. At this point, the x register contains the number of VTOC sectors - 1 = number of extra VTOC sectors. This is calculated from the type byte (named M in the comments) as follows:
The type byte is the number of VTOC blocks plus 2, i.e. the number of VTOC blocks is M-2. Thus the number of extra VTOC sectors is:
- in DD: (M-2)-1 = M-3
- in SD: (M-2)*2-1 = M*2-5 (remember: 1 VTOC block has 2 SD sectors, thus M-2 is doubled)
I don't see any bug here. The VTOC building code is fussy and the comments aren't very helpful, but it works correctly.

Mein Traum wäre eine Ausgabe - MyDos intern und was dein "YDos" alles besser machen wird.
Danke für den Schriftverkehr mit Lee Stefan, man lernt nie aus.

Viele Grüße,
Bernd

Hi Bernd,

eigentlich wollte ich mir den MyDOS-Code nicht so genau angucken, aber ich versuche gerade, Lee davon zu überzeugen, dass seine geplante Änderung des MyDOS-Filesystems keine gute Idee ist, da er damit unnötigerweise die Kompatibilität zu MyDOS 4.53 verliert.

YDOS macht gute Fortschritte: Der alte XDOS-Code ist (fast) fertig umgebaut und kommentiert, inkl. genauer Ein-/Ausgabebedingungen jeder Routine. Der Pseudocode für die Erweiterungen ist auch fertig und ich habe gerade angefangen, daraus Assembler zu machen.

Folgende FMS-Erweiterungen gegenüber MyDOS und XDOS sind geplant (wenn der Platz reicht):
- pro Laufwerk D1-D9 ein mit CD setzbarer und abfragbarer Default-Pfad
- Dir-Navigation auch mit < (Parent-Dir)
- Check auf Diskwechsel (wg. Nutzung von Default-Pfaden)
- Check auf Löschung eines Dir, das in einem Default-Pfad liegt
- reservierter Platz hinter dem Haupt-Dir, um die Dir-Sektoren dicht beieinander zu halten
- Speichern der Nr. des VTOC-Blocks mit dem 1. freien Sektor, um das Durchsuchen der VTOC abzukürzen

Im DUP werde ich keine Platzprobleme kriegen, inklusive Fehlertexte sind es derzeit nur 2,3 KB.

Hi Stefan,
wenn du das KMK2 Interface noch nicht bekommen hast, kann ich dir meines zum Testen von YDos leihen.
Kannst du ein Tool erstellen mit dem man eine Übersicht der Unterverzeichnisse erhält und dabei eines auch
anwählen kann? Was auch nicht schlecht ist - im Dos Fenster unter Windows bekommt man durch ein/mehrmaliges
drücken der Tab-Taste alle Einträge der momentanen Root in die Befehlszeile eingeblendet, ESC schmeisst den
Eintrag wieder heraus. Für die faulen Tastendrücker wie mich ist es eine große Hilfe....
Wer noch Ideen hat immer heraus damit....

Viele Grüße,
Bernd

Bernd hat geschrieben:Hi Stefan,
wenn du das KMK2 Interface noch nicht bekommen hast, kann ich dir meines zum Testen von YDos leihen.

Ich habe 2 KMK2 und würde Stefan auch eines davon zur Verfügung stellen. Dann muss Bernd nicht ganz verzichten.

Das IDE+ hab ich noch nicht gekriegt, scheint noch zu dauern. Andererseits brauche ich es zur Zeit nicht, da ich nur auf dem PC teste, das geht sehr viel schneller und einfacher. Ein 16MB-ATR ist ruck zuck angelegt

Die TAB-Taste im DUP ist wohl keine gute Idee, da ich die nicht per Editor abfangen kann und dabei auch Disk-Zugriffe fällig würden. Aber es gibt ja die Yes/No-Abfrage, die ähnliches bietet. Ein DUP-Befehl zur einfachen Verzeichnisauswahl mit Cursortasten und Return wäre schon möglich, mal sehen. Aber da bin ich noch lange nicht. Erstmal muss das FMS fertig werden, das wird nicht einfach.

Hi Stefan,
sind ja auch nur Vorschläge gewesen, wenn es klappt, siehst du mich so durch die Gegend laufen...

Bernd