On Fri, 26 Mar 2004 17:12:22 -0300, Flyguille wrote:
I are NOT recreating the same tiny MSX-BIOS because is well-know that got
several limitations and slowdowns...
Well, this is not an issue. There is the C-BIOS project (the BIOS
which is used on OpenMSX). This is an "open-sourced" BIOS and if you
think its code is "non-optimized", just optimize it. (^=
i do a complete new software standard
with enormous possibilities but capable to run in a normal MSX2 hardware or
in a future msx4 hardware without recompilation without lose speed. And that
is already done.
"Support every possible configuration from past to future" usually is in
the opposite side of "efficiency". Anyway, it's a project decision.
[Limitations of a "Common BIOS"]
Write an example ..... if we are talking about storage format.... the only
one limitation is the filename up to 12x4 no exist another limitation.
Simple. If you create a set of functions to cope with different hardwares,
you will limit them to the most basical features. Of course this will not
happen with file systems or harddrives, since they follow a clear standard.
Lets say about graphic display. V99x8 has a common set of instructions. A
"common BIOS" should be able to create a layer so in the future we could
simple switch our VDP and the programs continue to work.
If our program is aware of "Screen 5, 6, 7..." or whatever, then in the
future the BIOS will must add a "compatibility" set of functions that will
mimic the old functions in the new hardware (possibly doing the action
by software). This is very similar to what happens on DirectX. Anyway, this
is a bad decision on MSX scene, because MSX are slow computers, and I do not
think they'll become much faster and accomplish asm-code-compatibility in
every CI it has inside.
There is no way to provide both methods. You must choose. AFAIK, you had
choosen the latest. I would choose the first (even if this seems a little
weird)... but this is the meaning of a GDI (Graphical Display Interface).
- An Operating System is something that runs on the system and manages
(...)
environment" to the program and the programmer.
Yes that MNBIOS does.
(...)
I think that is a back-ground process , not resource sharing... anyway the
drivers got his buffers... and the MNBIOS got resource sharing system.
(...)
Not, virtual screen is not the best way in MSX, anyway MS-WINDOWS not use
that.
In other words, MNBIOS is a BIOS, an Operating System and an Windowed
Interface. Gee... you will build Word Processors, Calc applications and
so on? q^= Bill Gates soon will buy your business. q^=
Yup. Windows had not Presentation Spaces.
A graphic user interface is that when, you got windows, and objects on
windows.... pffffffffffff
Yes, but this kind of thing is somewhat useless if the programmer
have to do ALL the steps to draw every button, control the "trash table",
control the button animation, control the animation of check-boxes...
Well, anyway, good luck.
Check the ENGLISH programmer manual.
You cannot say it in a few words?
UZIX was develop thinking in "C" programming and UNIX compatibility.... UZIX
not got the GOAL be fast and powerfull.
My friend, to be fast and powerfull is ignore the operating system
and programming everything from the raw hardware. This is the fastest
and powerful a program could be.
UZIX surelly is great in his market...
UZIX is great, MNBIOS also. But none of them are "the answer for
a future MSX" because we do not even know what a future MSX could
be!
[]'s
Daniel Caetano
daniel(_en_)caetano(_punto_)eng(_punto_)br - http://www.caetano.eng.br/
..."A necessidade de criatividade e' o que contribui para a
mudanca. A criatividade mantem o criador vivo." (Frank Herbert)
