32 MB Partitions for MyDos (in theory!)

[+Larry]

Just out of curiosity...

At one time, Bob Puff mentioned that MyDos 4.60 was going to have 32 MB partitions rather than 16 MB present in 4.5X versions. While I don't find 16 MB limiting in the least, I'm curious how it was going to be done. You'd have to "steal" a bit from somewhere else in the 16-byte file entry, wouldn't you (for starting sectors > 65535)? Anyone familiar with how it might have been done? Personally, I find the 64-file directory restriction to be much more of a serious limitation than the partition size -- especially in the main/root directory.

 

And a question for drac030. As an extremely dos-savvy guy, if you were going to improve MyDos, what are some things would you change (while still keeping its "look and feel?")

 

-Larry

[Mathy]

Hello Larry

 

I once called Bob and asked about this. This is what I remember:

 

Since a sector in MyDOS contains a maximum of 253 bytes, the "number of bytes in this sector" byte never accedes 253. So "254" and "255" are never used. Bob wanted to use 253 to say "This is a sector from the first 16MB", "254" would be "This is a sector from the second block of 16MB" and "255" would mean "This is a sector from the third block of 16MB", thus creating three blocks of 16MB or 48MB partitions.

 

That's what Bob said IIRC.

 

This is where I start to ramble (read: Not what Bob said!). If we also use "0" to mean "This is a sector from the fourth block of 16MB", that would make for 64MB partitions. Since the sector link would not be zero (end of file), MyDOS, if worked over, would not think that this sector is empty (as it would when the sector link is empty).

 

greetings

 

Mathy

 

PS the BlackBox can handle 64MB partitions hardware wise. And loads of partition lists.

Edited November 26, 2009 by Mathy

[drac030]

But if you set the "number of bytes in this sector" to 255, then you don't know, how many bytes the sector contains. In other words, such a sector cannot contain data. Instead it can be considered a "jump instruction" for DOS, which could, in its data area, contain information in which "16 MB segment" of the entire disk the file is continued. This enables you to have a nearly infinite number of such 16 MB segments per partition, as the data area contains 2024 free bits of information.

 

Obviously, such DOS functions as NOTE or POINT would not work anymore, e.g. you couldn't do a thing like that:

 

1) call NOTE to remember the current position in the file

 

2) read 256 bytes

 

3) call POINT to restore the position recorded by 1)

 

4) read the same 256 bytes again

 

because you'd never know if the phase "2)" hasn't implicitly crossed a 16 MB segment boundary.

 

@Larry: I would drop that inefficient filesystem. Just create a 8 MB file, then see how long it takes to delete it, or how efficiently a program can do that:

 

1) open the file

 

2) read 256 bytes

 

3) seek to the last KB of the file

 

4) read 256 bytes

 

5) seek back 1 MB

 

6) read 256 bytes....

 

In SDX such operation takes only few seconds, mainly thanks to the better filesystem structure. In MyDOS each "seek" step would probably require re-reading the file from the beginning to the required position.

Edited November 26, 2009 by drac030

[Mathy]

Hello Drac030

 

In MyDOS all sectors are full except (in most cases) the last one.

 

greetings

 

Mathy

[candle]

Mathy: but what this should have to the test Drac030 mentioned? In my understanding non linear data access will result in great increase of time that whole operation takes

[flashjazzcat]

True, only the last sector of a MyDOS file will not be completely filled. But if this partially filled sector resides in the third 16MB volume area, how to we use the value to denote both the number of used bytes and the location of the sector? I think that's the point Draco's making. You'd have to have a spare bit or two reserved purely for the purpose of 16MB indexes.

 

The sector link file structure is - in my view - fundamentally unsuited to extremely large volumes. There's no quick way to do random seeks using this system.

Edited November 26, 2009 by flashjazzcat

[Mathy]

Hello Jon

 

Why don't you guys ask Bob?

 

greetings

 

Mathy

[atariksi]

True, only the last sector of a MyDOS file will not be completely filled. But if this partially filled sector resides in the third 16MB volume area, how to we use the value to denote both the number of used bytes and the location of the sector? I think that's the point Draco's making. You'd have to have a spare bit or two reserved purely for the purpose of 16MB indexes.

 

The sector link file structure is - in my view - fundamentally unsuited to extremely large volumes. There's no quick way to do random seeks using this system.

 

I think it makes sense. If the last sector is partially filled, then you have more bytes free in that sector so you could use the 2nd to last byte to denote the partition.

[drac030]

@Mathy: you're right, but my idea is anyway better than the one you have mentioned. As I understood you, if fill_byte $FF, then next_sector is in "16 MB segment", say, A, and if it is $FE, then the next_sector is in segment, say, B. This way you have three segments i.e. 48 MB. With my idea, you loose 1 sector (i.e. use it for "jump instruction", not for data), but instead you get 253 free bytes (2024 bits) of the sector's data area to encode the segment number.