I have been struggling to get Moonblaster working from DOS2, and I finally did by using Meits method of using a folder on drive B and switching to it before loading the program. This worked well so far, but if I put way too much files in the folder (let's say about 300), it looks like Moonblaster cannot handle that directory size and freezes. If I put about 50 files, then Moonblaster works perfectly.
I don't know whatever this is a Moonblaster or DOS1 limitation, but it would be nice to know from the DOS1 point of view, what is the maximum number of files that a drive is able to hold.
Для того, чтобы оставить комментарий, необходимо регистрация или !login
A standard 2DD floppy disk can hold 112 files in the root directory. Since DOS1 can't handle subdirectories, that's the maximum number of files you can handle per disk in this OS.
If you devide your MBM files by category/creator/product you keep things tidy and will most likely not exceed the dos1/Moonblaster boundry. Too many files in one dir will ruin a good overview.
I can imagine I look at it in a different way than most people since I create with it and like to keep things together while listeners might want to have everything in one dir and do a play all.
Moonblaster has very low tolerance for any abnormal situations... Practically you will end up to memory overflow if the number of files exceed what fits to one screen. First you will lose colors from function selection bar and if you save even more files the program will crash. If you download the updated "Project hmm"-version, you can use all the drives you have (not only A/B)
A standard 2DD floppy disk can hold 112 files in the root directory. Since DOS1 can't handle subdirectories, that's the maximum number of files you can handle per disk in this OS.
Hello konamiman,
I have done a little BASIC program to test files system limit. It stops at file 112.
10 FOR X=1 TO 9
20 A$="FILE"
30 B$=STR$(X)
40 C$=RIGHT$(B$,1)
50 D$=A$+C$
60 E$=D$+".TXT"
70 OPENE$ FOR OUTPUT AS #1
80 PRINT#1,"Hello worl!"
90 PRINT E$
100 CLOSE
110 FOR X=10 TO 99
120 A$="FILE"
130 B$=STR$(X)
140 C$=RIGHT$(B$,1)
150 D$=A$+C$
160 E$=D$+".TXT"
170 OPENE$ FOR OUTPUT AS #1
180 PRINT#1,"Hello worl!"
190 PRINT E$
200 CLOSE
210 FOR X=100 TO 150
220 A$="FILE"
230 B$=STR$(X)
240 C$=RIGHT$(B$,1)
250 D$=A$+C$
260 E$=D$+".TXT"
270 OPENE$ FOR OUTPUT AS #1
280 PRINT#1,"Hello worl!"
290 PRINT E$
300 CLOSE
Then I have conducted a search and found that an entry in the FAT wikipedia explanation.
I found it in the Exceptions section: Root directory entries
(BPB offset 0x06). That 112 and the BPB is the cause of the 112 file limitation, right?
Thanks!
It took a while to realize what you mean, but yes... On this part of boot sector FAT lists the number of reserved clusters and where they are used. The thing is that when you store the first file or directory to disk, it will be stored to next cluster right after the root directory. This causes the problem that when the root directory gets full it would need to reserve another cluster, but since in FAT-table it is already using "reserved" entry (unlike other directories), it has no mechanism to fragment it self like other files/directories do when they run out of space. This is why root directory always has fixed size.
It took a while to realize what you mean, but yes... On this part of boot sector FAT lists the number of reserved clusters and where they are used. The thing is that when you store the first file or directory to disk, it will be stored to next cluster right after the root directory. This causes the problem that when the root directory gets full it would need to reserve another cluster, but since in FAT-table it is already using "reserved" entry (unlike other directories), it has no mechanism to fragment it self like other files/directories do when they run out of space. This is why root directory always has fixed size.
