I read on the website of UZIX that (max 48kb by process)... i are checking
now...
COPY/PASTED "Applications occupies a minimum of 16K and a maximum of 48K
address space (depending of their size)."
Correct.
Well, a EXEC file is multipage capable, you can write a CALL or JP
instruction to any other page... Each page is one module with his local
module variables (window size for code program is 16k at same time "for
aplications" plus 32k for window data "sharing 16k").
So, all MNBIOS applications can be seem like a MegaROM?
How you handle CALLs/JPs to other pages? Calling a MNBIOS function, I suppose...
2) How can you handle a 2048GB partition with current mass storage devices
for MSX?
Is this the limit for IDE or SCSI devices?
MNBIOS not use any firmware...mnbios core functions got all addressing of
32bit for sector number, then (2^32)*512.... all uppers structures are
32bits based. Now, if the harddisk got a limit or his protocol comunication
got that... sure... MNBIOS will acept that limit...
I understand. Sounds a bit wasteful for nowadays hardware, but fine for
future expansion.
3) About new hardwares in UZIX: they can be added in the same way they can
be added
into MNBIOS. Please, don't confuse 'access mode' (character/sector) with
'hardware access'.
I not understand what you mean here... on mnbios one driver is written chrs
based or sectors based or structures based or file based... that is because
that all kind of driver are linked in a diferent level on main functions...
that is possible because the mnbios got a resources administrator.
Same goes for UZIX, in some way. 'structure based' and 'file based' is just
a matter of abstracting a character or sector (don't confuse 'sector' with
'disk-sector').
4) Graphic mode support in UZIX is an application issue, as in all UNIX
systems.
Application issue? .... MNBIOS help to the aplication in that work
supporting diferent programming instances.
It's an architecture decision.
That is a bad way for do the thinks on MSX... sure on higher hardware can be
great... but not for msx....
No, it's the best way to do things on MSX: KISS (Keep It Simple, Stupid). I
don't
want to inflate and slowdown the kernel with things that most user applications
will not use.
That's right. But you can always learn something from others work. :)
Sure all we can learn on other works... not was the case of MNBIOS...
Too bad if you can't learn from others work. MNBIOS could be improved a lot,
just by learning how Nestor, Robsy and many other great Spanish programmers
do things. For example, INS and its memory manager are great sources of
ideas for a nice memory management for MNBIOS.
noooo !.. your'e right... i learn disambling all the ROMS on my msx
hardware. including BASIC/ BIOS/ DISK-BASIC/ EXTENDED BIOS because in that
time i not got internet, not msx books... only one book about Z80
programming...
That's very good if you can learn things by yourself. But when working on a big
project by yourself only, your project will be limited to yourself (I'm not
talking
about releasing it; I'm talking about how far the project can go).
Regards,
Adriano
