MNBIOS demo3 - Opinions and suggestions

Pagina 5/10
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

Van ro

Scribe (4698)

afbeelding van ro

03-10-2004, 16:39

yes, it is. No multi-tasking, only interrupts. You see it is more like a Programmers OS. It doesn't use a (G)UI to interact with user input (unless you use the command line console which holds some basic functions more like to debug your (re)sources)

The programmer may use it's functions and build a program around it; like a (G)UI for example. It's a BASIC platform for other programs to function on a uniform level. Also it has some functions build in which were initially designed to give a game-programmer some advanced options (like the File Retrieval System for example) But due the strenght of these modules we decided to make them permanent.

Have you ever noticed how flexible the whole Muzax series is for example? It's build on Midas. Music files are pre-loaded depending on how much RAM is free (when using 256 k. you can have all files loaded in at once) Also the Samples (MSX Audio) are checked on previous load. Sometimes it'll just load a fragment.
And since it runs in RAM mode (page 0); it's speed is optimal and so is the extra free RAM at that same page (for high speed routines this is somewhat a must)

And yup, it has an TSR service module (add-on). This service module also takes care of Music Drivers; loaded on demand. (so it is possible to switch from different Music formats in just a flick of a second)

For more detailed info I'd recomment the doc that's downloadable at ww.wthefuzz.nl.

Van flyguille

Prophet (3028)

afbeelding van flyguille

03-10-2004, 16:47

And since it runs in RAM mode (page 0); it's speed is optimal and so is the extra free RAM at that same page (for high speed routines this is somewhat a must)

you are talking abut Turbo R? so, it is for TR?

Van ro

Scribe (4698)

afbeelding van ro

03-10-2004, 16:52

no. The extra speed comes from the fact that it doens't use the ROM (remember it's a replacement for the existing BIOS). so, it's nested in RAM @ page 0. Here you also have the interrupt routines which are handled at a much higher speed than in ROM (no overhead for example)
No SLOT switching is done; more speed is gained. Ints will be timed better and so on.

It runs on every machine with atleast 128 KB of RAM mounted.

Van flyguille

Prophet (3028)

afbeelding van flyguille

03-10-2004, 17:58

well, a good kernel like the MNBIOS, hasn't overhead @ $38.

(remember it's a replacement for the existing BIOS). .

Yeah, a lot of programs swap the page 0 like nestor basic , KUM-BASIC iirc.

MNBIOS currently doesn't support SLOTING for RAM switching, because that is fasts, but i m planning to do a full slotting routine of "12" nothing more assembler commands!!!.. REMEMBER 12 , without LOOPS!, FOR SUPPOR multiple mappers.

there is nothing to be jealous.... that is other thing made with other goals, made in other level (layer), made in other time, made with other purpose..

maintain the good job ro, and back to ON TOPIC

Van ro

Scribe (4698)

afbeelding van ro

03-10-2004, 18:13

fly said: "there is nothing to be jealous.... that is other thing made with other goals, made in other level (layer), made in other time, made with other purpose.."

Hey that might be a good question: WHAT was your purpose (and maybe inspiration) to code MNBIOS, fly? What exactly did you have in mind, what goal?

Midas was created during the development of the (never finished) "Nosferatu" project where we thought the MSX lacked good OS props (memory and file management for example) So we started coding the kernel parallel with Nosferatu (although we spend more time on the kernel than the actual game project) to have that as our basic platform. (I told you before that some routs were coded for game purposes) But eventually had bigger plans with the new born kernel, the rest is history.

How about your objectives fly?

Van flyguille

Prophet (3028)

afbeelding van flyguille

03-10-2004, 19:19

fly said: "there is nothing to be jealous.... that is other thing made with other goals, made in other level (layer), made in other time, made with other purpose.."

Hey that might be a good question: WHAT was your purpose (and maybe inspiration) to code MNBIOS, fly? What exactly did you have in mind, what goal?

How about your objectives fly?

How born MNBIOS?, ok maybe not all ppl knows the history...

I'm a programmer since 1986, (11 years old), but far of all about MSX... untill 1990 the only book that i gets was a "assembler programming for dummies for msx" based on msx1 ofcourse. Here in argentina to buy something original (softwares / cartridges) was impossible, simply they doesn't exists inside argentina, so this is a country of pirates, all pirates, including the big stores with bigs names too. Imagine, about docs/ programming manuals, no one!, except ofcourse BASIC programming, of that is a lot.

Starting with a assembler book, a book that not said nothing about the BIOS services, only direct I/O to tms9918 / PSG / PPI, nothing about hooks, except interrupts ones (and in an example), nothing about system variables... imagine what shit... but it said all about assembler z80 pure assembler!.

And with that i learn..... so, as programmer that love MSX, i starts dissasembling the MSX-BIOS, first as i have in that time a MSX1 i dissasembly it.....

and see all about BIOS services, just dissasembling, then i make a system variable map, a hook map, a services map.... in that stage i learn a lot about MSX. surely i not figure out somethings, and only 10 years before with internet i downloads a lot of docs, that match a lot with that i made ...

imagines, scanning the behavior of my v9938 bit per bit (in 1992 i bought an msx2 by 30$), dissasembling the SCREEN function of the bios, dissasembling the new (for me) extended BIOS.

back in time, that was done until like 1993, parallely i programmed those games that i makes public, some others that are private (unfinisheD), and some utilities.

so, What i feels about the MSX-BIOS?, (pardon to all msx lovers), that the MSX-BIOS was a shit slower!, loads of full of crap...mixed with the interpreter, a lot of grph functions needs to switch to slot 3/0 more slow!... when really it doesn't needs that.

as i was a game's programmer, i love to do games ( but now are 12 years without do one ). I starts programming MNBIOS as a full feature library for game programming, with the fasters routines. But with a GFX ALU PSG routines sets, it is not enought, because my games will needs to load files, and the BDOS service can't be used.... because MNBIOS starts as other enviroment for msx hardware.

Anyway i have a MSX-DISK BASIC 1.x that doesn't support subdirs.... the perfect excuse to do my own filesystem enviroment... then come the question, if i will to do one, why not to do the BEST?

but, what is the BEST?, overall it needs to share the volume format to share the same medias as MSX-DISKBASIC / MSXDOS.

the answers come out fasts....

more bigger filenames using the same 32 bytes of each dir entry.

Why this improvement?... because as programmer of gwbasic, when i progammed some databases of multiples files, where the name of each file has a meaning like

DATxxxnn.Syy

i found that 8x3 is not enought. And as the new extensions names have 4 chrs like HTML i feels the needs to improve here.
improving the limit of file dating. If i do something for the next generation, why to use the same limit of 2079 year bug?

And thinking in the next generation, the best filesystem needs a support to FAT 32... surely yes!!. thinking in BIG goals.
But, better, why not to use FAT at all? , a lot of time is wasted in treating the FAT!... is the best method the FAT?....
another big improvement, speeding up!. But ofcourse we needs backward compatibility...
So, i developed a mix method, when it can it doesn't use the FAT at all.

What more?.... ahhh.... you see how in MSX-DOS it opens files?
what slow method!!!!!....

IN MSX-DOS
OPENFILE"A:\xxx\yyy\file1"
OPENFILE"A:\xxx\yyy\file2"
OPENFILE"A:\xxx\yyy\file3" (untill i know)

IN MNBIOS
SELDIR"A:\xxx\yyy\" as TEMP
OPENFILE"file1" of TEMP dir selection
OPENFILE"file2" of TEMP dir selection
OPENFILE"file3" of TEMP dir selection

The advantage is clear, in mnbios only treats with the path one time...

But that is not all, a good filesystem is based always in drivers to do the hardware I/O level, i takes the example of MS-DOS, what fullshit was that of MSCDDEX.EXE irrc , you know the 2 thinks that you needs to support a CD-ROM drive. Why that? because the filesystem of ms-dos not foresee that a device is not ramdom access. so, can't to use SECTORS drivers, finally they implement the thing doing a Character driver as first level plus another driver to be capable of GET a unit letter. a mess idd

in order to foresee a lot of new unknow new devices, i support 4 levels of hungs in the filesystem, and 1 level for code libs.

So, what WONDERFULL filesystem.... it is amazing, ofcourse, the speeds ups gained in improvements were neutralized a bit by its mayor complexitivity, but that will change in the final version with the new service manager.

what wonderfull, why i not convert it in a OS adding a shell GUI?

And in this step really born MNBIOS as we knows it.

This proyect was stopped 2 or 3 years (i lose the count) because my attemption as programmer where spotted in VB5 / VB6 , in that i do some IRC bots, FSERVERS, no the shitty like mIRC scripts.

I resume it in NOV / 2003, because if not was a lot of time wasted, and my msx in the closet. Indeed i resume it because i shown it in an meeting and get the attention of argentinian msx users.

i found the msx argentinian list, and the MRC, as hispamsx in that time.... and in a jump of suicide i submit the first news here, without having nothing complete, when i gets the attention here, i starts resumming the develop what headache, because in that time i not understand by where to resume, because i didn't know what i was dev when i left it.

But , you see now, atleast the shell is completed, surelly it needs more features, but those can wait...

In all the stages i had different goals....

first, a game's programming enviroment...
then, a OS.
then, a OS multitasking, using the method of drop the control to the next aplication. ( DEMO'S)
now, a OS multitasking full, multiprocess. natural programming (FINAL).

Since the begin i learn a lot, i meets ppl, i appers from the nothing, to be somebody.

In this develop, the one that i handles seriously i bet a lot of free time.... and in my adolescence atleast 10/12 hours per day. up to 2 , 3 , 4 am! really sick behavior, you know.... freaks.

well, now i have a work, a cyber-cafes, and use a lot of time on it, programming in the control PC. Because that i goes fast with the develop, in other case it is impossible to be fast.... atleast no with a life where you needs to work to get money to eat and pay taxes....

Flyguille

Van wolf_

Ambassador_ (9956)

afbeelding van wolf_

03-10-2004, 19:32

"assembler programming for dummies for msx"

o_O .. is that from the well-known "..For Dummies" range (the yellow books) we know nowadays?

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

03-10-2004, 19:40

Thanks for sharing that history, flyguille!

Van flyguille

Prophet (3028)

afbeelding van flyguille

03-10-2004, 23:40

no problem!.

o_O .. is that from the well-known "..For Dummies" range (the yellow books) we know nowadays?

yes, it is yellow but not all

Van flyguille

Prophet (3028)

afbeelding van flyguille

04-10-2004, 01:37

i just adds another library on my website www.mnbios.com.ar called EnShell.asm / EsShell.asm (english / spanish) , this one is a layer to use all the functions of the SHELL from an aplication...

THERE IS NO MORE ANY EXCUSE TO STARTS!!!

Pagina 5/10
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10