MNBIOS demo - Opinions and suggestions

As I kinda said already in the reactions to the newspost, I'm quite impressed by the results already. I think we all were a little sceptic at first about it as it came quite out of the blue.

It looks very good, I'm impressed by the speed of the interface. I was used to the speed the MSX writes text on a graphical screen, but I didn't expect the speed of this interface.

It would be nice to see a Basic for this OS and of course more things running under it. A Basic would be a good start for it for beginning developers to use its capabilities. I also read there's a function being made to make other fonts available (like a specific 6x6 font to make that mode more readable).

I'm looking forward to more features and programs for this OS.

The msx4 storage format got changed the followings items...

the name long 12.4 instead 8.3

The attrib byte is moved from offset +0Ch to +10h

The date/time record got moved 2 bits from the "seconds" field to "years" field. And start counting from year 2000... not 1980.

The attrib got on bit 7 (normally unused) the flag "fragment", when that bit is activated, the kernel read the FAT to look for the corrects clusters. If that bit is reset the kernel don't use the FAT because if are reset means that file aren't fragmented, but that need an extra field where the kernel read the quantity of cluster that got the file.

Modify the "FIND_FIRST/NEXT" routines for use shorts name is easy.... but all services routine need the attrib byte on offset +10h, normally on that address MS compatible got the value 00h, that means file not fragment and that need the quantity cluster field else if we write the value 80h here..... but as allway need that convertion, is the same thing make a full convertion..

Allway the MNBIOS, can't access to files with shorts names....
but the MSX-BASIC and DOS1 can access to files with long names, simply it ignore the extra chrs of the name. (if the disk-basic support attributes, make sure the filename not get extension name because the first extension name letter are store on +0Ch normally used by the attrib and a value of &H20 not make any problem).

ahhh don't forgot the INFAT of 32 bits instead 16bits.

ahhh don't forgot the INFAT of 32 bits instead 16bits.
32 bit FAT?

I wonder.. Why use 12.4 filename, in stead of Windows compatible VFAT filenames?
Windows VFAT long filenames may be slower, but also more flexible and most importantly COMPATIBLE.

>>ahhh don't forgot the INFAT of 32 bits instead 16bits.<<
32 bit FAT?

I wonder.. Why use 12.4 filename, in stead of Windows compatible VFAT filenames?
Windows VFAT long filenames may be slower, but also more flexible and most importantly COMPATIBLE.

By 2 reasons:

1. I not know that standard.

2. Looking on directories with longs names, i see that need more memory space... and a more complicated "look up" routine.

Then i decide use the normal size of 32 bytes for each file, but really using that normally wasted bytes on MS... for aceleration access proccess.

The limitations are the chrs that can be used for filenaming...

On the MNBIOS "-" or "/" or """ can't be used for filename, nothing more.. but for MS-DOS compatibility reason i add as forgiven more chrs. But then i will remove that.

Actually on DEMO version you can use

TYPE "A:CONFIGABC.COM"

DIR "....ABC*.*"

DIR "MSX*.*"

you can use the """ symbols for mark the start or the end of the unit+root+filename parametter for allow the posibility of include SPACES chrs.

You can test that on the DEMO...

Other thing the DEMO GOT is the # value... on commands like "COLOR -m#"

You can really use any numeric expresion when replacing the # simbol.

like

&H10
&B01111111.111111
&O777
&D1234.1234
131234.213
213

That is proccessed by the function of the kernel CNV_TXT_BIN (convert TEXT values to BINary values).

And the demo version got a lot more hidden things.....not comments on readme.txt