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
