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