----- Original Message -----
From: "Daniel Caetano" <daniel(_en_)caetano(_punto_)eng(_punto_)br>
To: <hispamsx(_en_)yahoogroups(_punto_)com>
Sent: Saturday, March 27, 2004 9:58 PM
Subject: Re: [hispamsx] comparaciones...
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.
Sure, a 32bit based addressing use more code, but as allways the speed of
I/O accessing is slowdown by the RPM disk, then you not got a slow service
only because was designed for future hardware.
[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.
THAT IS JUST THAN MNBIOS DO.
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.
Sure, you need a video chip than can be easy adapted.... because that MNBIOS
not support TEXT screens or pattern screens.... if a program want to use
this... surelly will exist a driver... like in PC world was made "SIMCGA" or
some name like that.... do you remember?.
The v9990 is the best option here, because the coding of the same set of
routine is include faster than the v9938 set.
Chips like SVGA is more hard to adapt because that not support sprites...
and then you need to emulated that on a front bitmap and left the bitmap
screen in a second plane.
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).
What you mean... allways.. never mind.
- 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^=
I not think so... no market...
Yup. Windows had not Presentation Spaces.
jajajaja
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.
For that will exists the MNBIOS libraries.
Check the ENGLISH programmer manual.
You cannot say it in a few words?
I not want... for that exist the fucking manual.
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.
Sure,,, if you want to do "long time developing" and chips based
aplications.
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!
Offcially MSX is dead, and the FANS will to decide what will be the MSX
future...I thinks if I put in his hands a easy to program, fast, stable, and
nice enviroment... they will adopt that.
[]'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)
*HispaMSX. La mailing-list de MSX en castellano*
Para cualquier duda: hispamsx-owner(_en_)yahoogroups(_punto_)com
Web de lista: http://www.hispamsx.org
Enlaces a Yahoo! Grupos
Para visitar tu grupo en la web, accede a:
http://es.groups.yahoo.com/group/hispamsx/
Para cancelar tu suscripción en este grupo, envía
un mensaje en blanco a:
hispamsx-unsubscribe(_en_)yahoogroups(_punto_)com
El uso que hagas de Yahoo! Grupos está sujeto a
las Condiciones del servicio de Yahoo!:
http://es.docs.yahoo.com/info/utos.html
