Well... UZIX virtual terminals allow user to switch between up to 3
different and
independent terminals in the same monitor
MNBIOS kernel already is able to switch bettwen 2 or 4 video pages
(depending of the screen mode ofcource) and the windowing system is capable
to host any windows on any page...that is the kernel.... the User interface
in his basic form only use one, but following that concept is possible do up
to 4 desktops if i want to do that, right now? i don't want lose my time in
"make up".
And i are talking of BITMAPS (screen 5, 6, 7 y 8) and not chrs matrix......
ofcourse, is more simply save 1k or 2k of text matrix instead a 32k or 64k.
It's very dangerous talking about "maximum hardware power" on a multitask
system.
I can talk about that because the structure of the kernel allow that.
A computer program can do only two basic things: calculations and I/O.
For calculations,
C has almost the same speed as ASM for general purposes and optimized
code. For I/O,
slow devices (this is the case of MSX I/O devices) will always slowdown
things, and it
doesn't matter if you wrote the code in ASM or C.
You forgot to mention the C framework slowdown all the comunication.
Take a simple example: reading data from disk and printing it to
screen. Writing code in ASM will not make things faster.
Yes, in assembler go faster, if you got a driver in assembler and a printing
functions in assembler,RESULT: speed gain in disk reading + speed gain in
aplication + speed gain in print kernel function = FASTER. Ofcourse is not
the same printing in a BITMAP instead SCREEN 0 ... and i are wondered ....
including that the mnbios listing on bitmap got the same speed than basic or
DOS ...
What you call a graphic environment? Text windows with colors? No, it'
not. It's just nice
text windows with colors.
And what you call a useful graphic environment? MSXView? Easy? No, they
aren't. They
are just nice useless windowed graphics.
A graphical enviroment is that where you got the capability of program
objects like buttons...text box ... and then use it...
on the MNBIOS all objects will come in driver library implement.... the
kernel foresee this way to work for that support functions for calculate
coordiantes inside a window between other things like the windowing instance
support. Now if the MSXCOMMAND.EXEC single user interface don't implement it
is other thing....remember i are talking about O.S. capabilities (kernel),
not final aplications capabilities.
I tried creating a useful graphic environment for UZIX, like X-Windows.
256x192 is crap,
you can't do anything with such resolution. So I chose 512x212 (SCR6). But
V99x8 is
too slow, and the result isn't good. That's why MSXView/Easy/etc are just
curious
programs, not usable graphic environments.
256x192? screen 2 o 4? that is a crap. you will lose much time calculating
the pattern byte of a coordinates. Bad desition.
On MNBIOS the programs will usefull the graphic environments if the
aplication want.
because it's slow (it's slow even using VDP hardware commands for
everything).
And how hell i made a FAST graphic enviroment on v9938????? Just write "FCB"
on DEMO mnbios version for see how fast is.
It's a difficult question... Let me count... UZIX application libraries
have about
400 functions, all UNIX compliant (at least with some UNIX flavor). This
number
also counts TCP/IP functions.
NO NO!!!, count only kernel functions plus I/O native drivers
functions....like COM / DISK / BDOS (BDOS on mnbios is MDOS).
Anyway, before of receive this mail, i send a comparation mail in spanish.
Saludos...
----- Original Message -----
From: "Adriano Camargo Rodrigues da Cunha"
<adriano(_en_)alsoftware(_punto_)com(_punto_)br>
To: <hispamsx(_en_)yahoogroups(_punto_)com>
Sent: Friday, March 26, 2004 1:19 PM
Subject: Re: [hispamsx] Hello World !!!! para MNBIOS
NINGÚN SISTEMA MULTITAREA SALVA LA IMAGEN DE LA VRAM EN ALGÚN OTRO SITIO
PARA LUEGO RESTAURARLA... PORQUE LO IBA A HACER YO?
EN EL MANUAL EN EL SEGUNDO CAPÍTULO SE EXPLICA COMO FUNCIONA...
Well... UZIX virtual terminals allow user to switch between up to 3
different and
independent terminals in the same monitor. All the data displayed in the
video
is saved when user switches from one vt to another. Not even a character
is
lost.
Of course UZIX dual-head implementation is different, but, anyway, all
video
data is preserved in both cases. Using vt and dualhead you can switch
between
6 different terminals on a single MSX.
NO CONOZCO UZIX
Be my guest: uzix.sf.net.
PERO DESDE EL "VAMOS" ESTÁ HECHO EN "C" LO QUE NUNCA LE
PERMITIRÁ UTILIZAR TODA LA POTENCIA DEL HARDWARE Y PRECISAMENTE POR ESO
FUE
HECHO EL MNBIOS.
It's very dangerous talking about "maximum hardware power" on a multitask
system.
A computer program can do only two basic things: calculations and I/O. For
calculations,
C has almost the same speed as ASM for general purposes and optimized
code. For I/O,
slow devices (this is the case of MSX I/O devices) will always slowdown
things, and it
doesn't matter if you wrote the code in ASM or C. Since most operations
done by a program
are I/O (disk, video, keyboard, etc), the speed difference between C and
ASM decreases.
In the end, there will not be too much difference, from the user point of
view, if the program
was made in assembly or C. Take a simple example: reading data from disk
and printing it to
screen. Writing code in ASM will not make things faster, because the
slowdown caused by
acessing the disk or the video will make the speed gain in main code not
noticeable. You
should argue 'my drivers are optimized, so it will be faster'. I reply: C
drivers can also be
optimized. We're not discussing code optimization.
Again, we're talking about a multitask/multiuser system, whose
applications must
conform to many specifications and not bypass the OS when doing I/O or
even reading/writing
memory. If we're talking about a stand-alone program, such as a game, ASM
will be much faster
than C, because the program can do anything it wants with the hardware,
and no one (I mean
another program) will complain about this.
APARTE LOS MSXeros ESTAMOS ACOSTUMBRADOS AL MSX-DOS... ES
POR ESO QUE EL MNBIOS VIENE COMO ANILLO AL DEDO.... APARTE SEGUN ME
DIJERON
UZIX NO ES ENTORNO GRÁFICO.
What you call a graphic environment? Text windows with colors? No, it'
not. It's just nice
text windows with colors.
And what you call a useful graphic environment? MSXView? Easy? No, they
aren't. They
are just nice useless windowed graphics.
I tried creating a useful graphic environment for UZIX, like X-Windows.
256x192 is crap,
you can't do anything with such resolution. So I chose 512x212 (SCR6). But
V99x8 is
too slow, and the result isn't good. That's why MSXView/Easy/etc are just
curious
programs, not usable graphic environments.
A working beta (and forever stalled) version of UZIX graphic environment,
called XWind,
can be found in the download section of UZIX 2.0 at uzix.sf.net. I quit
the idea of finishing
XWind because, in the end, it would become so useless as MSXview/Easy/etc
simply
because it's slow (it's slow even using VDP hardware commands for
everything). Probably
with V9990 things will be different.
BTW, text boxes and etc can be created in UZIX applications using curses
library.
Y DUDO QUE TENGA COMO 350 (+O-) FUNCIONES LISTAS PARA USAR.
It's a difficult question... Let me count... UZIX application libraries
have about
400 functions, all UNIX compliant (at least with some UNIX flavor). This
number
also counts TCP/IP functions.
Regards,
Adriano
*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
