HispaMSX

Re: [hispamsx] Hello World !!!! para MNBIOS

2004-03-26 20:27:29

----- 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 3:00 PM
Subject: Re: [hispamsx] Hello World !!!! para MNBIOS

Adriano Camargo Rodrigues da Cunha, as we acept, this two OS got diferent
GOALS... can't be compared... sure this two developments are the greates for
MSX in his respectives GOAL.



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.

Of course.

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.

It allows that, but not really uses that. UZIX could allow 64 concurrent
access to
IDE/SCSI devices, but nobody in the earth will do this. So, why spending
time
in creating things that nobody will use? It's a case of saving development
time.

For future fast hardware ofcource.... see the future... or you want to MSX
norm dead with a MSX turbo R?


You forgot to mention the C framework slowdown all the comunication.

If you're a bad C programmer, yes.

Use the STACK for share parametter is always more slow than use CPU
registers...


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

You're confusing I/O time with CPU time.

I are talking about speed than can apreciate the user...ofcourse a floppy
driver every will be slow limited by RPM.


I tried creating a useful graphic environment for UZIX, like
X-Windows.
256x192? screen 2 o 4?  that is a crap. you will lose much time
calculating
the pattern byte of a coordinates. Bad desition.

Read my text again. I was talking about SCR6.

I was confused about that, first i was thinking than you first do it on
screen 2, then as goes slow you change to screen 6.


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?????

I'm sorry, but it's not enough fast for a useful multiwindow environment.
It's fast for only one window and only one process, and not full screen.
V99x8 is slow. I'm sorry if I disappointed you, but it's a fact.

We are thinking in diferents things when we say MULTITASKING... for me the
multitasking is the capability of run several aplication, availables at same
time. Then the user will to select the active aplication.

Now, other thing are the "back-ground" process... that are you thinking...

Now i say, sure back-ground process need CPU time all the time. ----> that
is good on fast hardware with or without CPU architecture help.

MNBIOS support the two things... normally the normals aplications not need
to use backgrounds... anyway background process are disabled on DEMO version
and will be disabled on v1.x.

Think, what aplication REALLY need BGP to work?

Really nothing... but the user will got the issue that if he selected
another aplication by example an internet aplication will PING TIME OUT if
the user left it.

Think, what aplication REALLY need BGP to work for allow to the user to
change to another aplication?

Players of any kind....
All internet aplications like IRC / MSN / EXPLORER / FTP

On MNBIOS kernel exist a player inside with linking capability. Also exist
special interrupts hooks. And in the future will be enable the BGP
optionally (i really not want lose speed if that already are not used).

Remember, on MNBIOS one thing is back-ground process (BTASK programming
instance, interrupt hooks or music player), and other thing is aplications
available in memory and already started.

Conclusions the final speed with many aplications started is that you see
with only one aplication.

The MNBIOS

Just write "FCB"
on DEMO mnbios version for see how fast is.

I already tried MNBIOS demo and could check the results.

400 functions
NO NO!!!, count only kernel functions plus I/O native drivers
functions....like COM / DISK / BDOS (BDOS on mnbios is MDOS).

Different things to compare. The public kernel functions are just a
few (about 20), but they are unique: all devices share the same
function for similar operations. So, "read" can be used for many
devices, like disk, memory, etc. The good thing (as in any UNIX
system) is that applications can use new devices for I/O without
even know this and without need to be recompiled or rewritten or
updated.
There are a lot of internal kernel functions, but I don't know how many.
However, they are, as I said, internals, and not available for user
applications.
How many unique functions MNBIOS has?

I will take a look to the spanish manual for reply this.

MNBIOS got 6+237 function for MATH/ VIDEO/ SONIDO/ KEYBOARD/ DIRECT DEVICES
ACCESS AND MEMORY FILE ACESS available for aplications.

To that you need plus the following:

Almost 35 +o- unique functions for access to all I/O devices linked,
available for aplications.
Almost another 20 functions of the native ADM driver, available for
aplications but are already linked to I/O.
Almost another 18 functions of the natives CON and PRN drivers, available
for aplications but are already linked to I/O.
.
then... 6+237+35+20+18=316 indeed, That all basic function plus native
drivers functions. Without count drivers libraries.

greetings Adriano.


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




<Anterior en la conversación] Conversación actual [Siguiente en la conversación>