----- 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 5:31 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.
Right. But I'm sure I can learn many things from MNBIOS and apply them to
enhance UZIX. That's why I keep asking and comparing these two OSs.
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?
I don't know what will come for MSX and I can't guess. But probably it
will not
fit my desire and my code written in UZIX.
But, also, I don't want an OS that could be faster in my TR, but it is not
just
because it's ready for a nevercoming new hardware.
There is a tradeoff between "expansibility" and "benefit".
Use the STACK for share parametter is always more slow than use CPU
registers...
Crap C compilers use stack only. Better compilers, like Hitech-C, pass the
first parameters in registers.
And since MSX registers are limited, even in full ASM you can't pass all
the necessary parameters for a complex function only using CPU registers.
And more: big parameters (like 32 bits sector number) will make you run
out of free registers easily. So you also have to use memory (stack or a
fixed address) to share parameters.
Mnbios not use fixed address, use dinamic structures storaging... for that
exists the structures.... Anyway the aplications not need fill the
structures....only need got a pointer to that structure... and the
aplications can get that asking to the kernel.
You're confusing I/O time with CPU time.
I are talking about speed than can apreciate the user...
In the end, everything the computer does affects the user point of
view. You didn't understand what I was talking about.
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.
You didn't understand. I was talking about 'fast graphic environment',
not about multitask or about foreground/background processes.
MNBIOS support the two things... normally the normals aplications not
need
to use backgrounds...
Of course not, when you have a monotask OS.
That is not true, the BGP are disabled becuase i need create a list of the
allowed or forbidden... and that will come at the end.
anyway background process are disabled on DEMO version
and will be disabled on v1.x.
Too bad, because doing so MNBIOS will become a simple task-switching
system.
Think, what aplication REALLY need BGP to work?
Some applications need background processes to run. Simple applications
probably not, as you already know.
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).
So I think it would better implementing sleeping/suspended processes, not
killing the main reason to call an OS 'multitask', and not
'task-switcher'.
for call a OS "multitask" not need background process.
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.
Writing it this way sounds to me more like the current 'resident' MSXDOSx
programs
than a real background process...
MNBIOS got 6+237 function for MATH/ VIDEO/ SONIDO/ KEYBOARD/ DIRECT
DEVICES
ACCESS AND MEMORY FILE ACESS available for aplications.
That's really a lot... And all of this in just 48KB? Wow...
Just be careful for not inflating the kernel with useless functions or
functions that
could be used as libraries, saving system resources. This is the
philosophy UZIX
uses. 'the bigger the better' is not always true.
NOT! that one only in 32KB of code!!!.... and you delete some lines... some
ones of that are included in that 32KB.
32KB kernel
16KB User Interface "MSXCOMMAND.EXEC"
16KB variable and structures space (for main CPU).
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
