----- Original Message -----
From: "Adriano Camargo Rodrigues da Cunha"
<adriano(_en_)alsoftware(_punto_)com(_punto_)br>
To: <hispamsx(_en_)yahoogroups(_punto_)com>
Sent: Sunday, March 28, 2004 12:15 AM
Subject: Re: [hispamsx] Hello World !!!! para MNBIOS
a lot of GOTO and in a OS like MNBIOS, programming in that way will
be a
lot of problem.
So what do you propose to solve this issue? I think it`s a very hard
issue
to solve since we`re talking about ASM programming.
Here You are thinking in independents routines with locals variables, or
things like that.
No, it`s a general programming consideration.
Here I are thinking in structure all in subroutines and then CALL to
that...
as it generally not is usefulled in msx-basic programming.
Just creating subroutines doesn`t make your program better structured.
Even
with subroutines, sometimes you need some jumps. A simple example is a
comparison operation: you must do a jump.
Anyway MNBIOS programming enviroment allow module variables and global
variables. The local variables are just the CPU registers.
CPU registers should be used as work area, not as local variables. Surely
you will
run out of registers on subroutines that are bigger than just a few bytes.
A window manager do not does what virtual screens do.
Without virtual screens, how can you maintain the current display
state of
background appllications? Forcing them to redraw themselves?
Redraw instance... is faster... because that i are talking about the
programming structure is diferent on MNBIOS...
I can`t see your point. Redrawing is not faster due to a programming
structure.
It depends on how the redrawing is done, how the video processor handles
the calls, if you have virtual screens or not, if you are using
double-buffer or
not...
NOW I SEE YOUR QUESTION.... MNBIOS MASKED THE SCREEN ON REDRAWING PROCESS
FOR CHRS OUTPUTING. That allow to print chrs on a window that is partial
covered by other windows.
NOT BUFFERING (that is slow).
NOT VIRTUAL SCREEN (that is slow).
is an attempt to say : No, for run background process, but YES for
do
the interrupt BIOS things like READ the KEYBOARD.
Ok. But, anyway, my question still applies to this topic.
? i loose the topic
The topic is:
You may get reentrant BIOS calls and even corrupt
current processing of a BIOS call if it`s interrupted by a user request...
do my MNBIOS better is my goal...
but if do better for allow to the BGP to use screen outputing or thinks
like
that, mean more code (slow to run) then i will not do that...
If you`re not adding more code to MNBIOS, then it`s doomed to be
stalled...
Sure, i will add code and link libraries for other things.
MNBIOS every grow.
If for save CPU time that mean to restrict to the BGP to only data
aplication processing... i will do that..
If in the future the MSX got fast hardware, sure i will add
functionality on
BGP.
Anyway, if you don`t want background processes to output to video, they
become almost useless in MNBIOS (except for pure data-processing). I
can think of uses like a network/dialup module, but probably you`ll prefer
putting this sort of module in the kernel for speedup purposes. So
probably
background processes will become totally useless in MNBIOS.
FIRST SPEED
SECOND to move away to the applications from the chips
THIRD EXPANDABILITY
FOURTH FUNCTIONALITY
FIVETH MULTI-SWITCHING (as you say)
I thought multitasking was already implemented and running in MNBIOS...
???? now i are crazy...
PLEASE NO MORE ENGLISH E-MAIL... FOR THIS DISCUSSIONS.
Anyway you're wellcome for start others discussions
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
