MNBIOS demo - Opinions and suggestions

By snout

Ascended (15187)

snout's picture

18-03-2004, 16:58

So, now that the first MNBIOS demo is out there: Have you tried it? Did you get it running? What do you think of it so far? What do you think should be added, or removed, or changed? Were you impressed, or slightly disappointed?

In other words: this topic is about the MNBIOS demo that has been released yesterday an anything there is to discuss about it!

Login or register to post comments

By BiFi

Enlighted (4348)

BiFi's picture

18-03-2004, 19:19

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.

By anonymous

incognito ergo sum (109)

anonymous's picture

18-03-2004, 20:42

Yep, same here...
With the exception of 'insert mode', the scrolling and display is smooth and fast.
The additional pro's a graphical screen offers, like the ability to use more colors and drawing will make this a great environment to work in.

It would be cool if MNBIOS could read/open standard MSX-DOS formatted files too, without having to convert them to 12.4 format.

By flyguille

Prophet (3029)

flyguille's picture

18-03-2004, 22:54

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.

By flyguille

Prophet (3029)

flyguille's picture

19-03-2004, 20:10

Anyway i will make a shell command for quick convertion without need to run any program.

Like

EXTEND game.exe game.EXEC

or simply without renaming

EXTEND game.exe

By anonymous

incognito ergo sum (109)

anonymous's picture

19-03-2004, 21:38

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 Sonic_aka_T

Enlighted (4130)

Sonic_aka_T's picture

20-03-2004, 01:55

I think the 'beep' needs to be spiced up Tongue

By flyguille

Prophet (3029)

flyguille's picture

20-03-2004, 02:13

>>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

By snout

Ascended (15187)

snout's picture

24-08-2004, 21:50

The second MNBIOS demo has been released a while back, the third one is coming up. Have you had a look at this new OS for MSX already? What did you think of it?