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.
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.
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'.
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.
Regards,
Adriano
