I agree on everything you wrote before...
> >- Why need a table of processes running and where??? What does your
program
> >have to do with the other programs???
>
> A lot. A process manager. An graphic environment that can manage
> processes. This will not be possible on Breeze due to use of DOS2
> managemente. Maybe someday I remake the management (only
> for Breeze based programs, for DOS programs everything will stay
> unchanged), or I will port Breeze to Uzix, that has a better Memory
> Management System... (-:
Remember Dos is no multitasking system. You would only be able to see some
TSRs. But you probably already know which ones you loaded.
MemMan is the right program to write TSRs for... With it also is TV.COM
which views the currently running (TSR-)processes.
> >Okay okay this sounds a little too picky. But I still think you should be
> >consequent.
>
> I think in two ways: The easiest and compatible, and the difficult and
> more difficult to be compatible... You can acess everything directly,
> but you can have a lot of problems so the program may works everywhere.
> It's possible, but it takes a lot of time. Time that I usually have not.
>
> If I simply cannot understand WHY a routine works perfectly when
> run under BASIC and do not work under DOS, even it the conditions are
> the same, "houston, we have a problem".
I think when running under Dos the upper two segments are taken by Dos
itself
> >> DOS2 Memory Management is the same stupid XMS method that
> >> exists on MSDOS.
> >MSDOS can't go further than 640kB. MSX can't go further than 4096kB.
>
> No. MSDOS cannot go further than 16Mb. MSX can't go further than 4096Kb.
Oh? Then what was the 640kB problem??? Things with upper memory etc.??? Only
the memory below 640kB barrier could be used for code. Everything else was
data only... unless you loaded some driver (GM4WS or something like that...
don't remember what it was called anymore).
And btw, MSX can handle more then 4MB, but only 4MB PER SLOT.
> OR
>
> MSDOS cannot go further than 640Kb. MSX can't go further than 64Kb.
(-:
No. On MSX the memory >64kB barrier can also be used for code.
> >Could indeed have been done better. Now, future mappers which can handle
> >more than 4MB per (sub)slot indeed aren't supported.
>
> I'm talking with Ademir about a 4Gb MegaMapper for MSX. When it's more
> "studied", I'll put under Phoenix discussion. But it'll be backward
compatible
> even if direct acessed.
Probably like: the first 4MB can be used by 'old' software and the other
memory only by new or adapted software.
> >If you really want perfect mapperroutines then use MemMan. But I don't
like
> >the way it works, switching to Basic and back to Dos using the
> >keyboardbuffer, etc. I just want to load it in my loader, nice and
quietly.
> >And besides, MemMan has a downside: the mapperroutines are way not as
fast
> >as Dos2's mapperroutines.
>
> And DOS2 are not "that fast" too, as all BIOS... (-:
Dos2 mapperroutines are AS FAST AS POSSIBLE!!!
(well maybe not alloc and free routines but the other are).
The only loss in speed is because it uses a jumptable.
And by the way, the segmentnr. corresponds with the mappernr. send to port
#FC-#FF, so you can also use direct INs and OUTs... You'll have to set them
right using the Dos2-routines before doing any BDOS-call though...
> >No. I didn't say that. But since everybody (okay okay exaggerated) use
some
> >direct I/O for certain devices future hardware will adapt to it. So you
can
> >do it as if it were standard. At least with VDP and printer, PSG, etc.
> >Example: what about directly accessing the PSG for JoyNet? The transfer
rate
> >would have been 10 times as low (at least!) when using the BIOS... And
since
> >it can be done without any complications (a faster machine will even be
an
> >advantage: transfer rates will increase!)...
>
> The problem is exactly that now we have to use the same hardware to do
> a new MSX. If everything were made acessing throught BIOS (of course,
> the BIOS should have acess for every peripheral, which is NOT truth),
> a new MSX do not even have to use PSG or V99xx. Direct acess had this
> backdrop.
I think a new MSX should have them or at least emulate them in a good way
(on hardware level).
> >> You are talking about Z80 3.57Mhz? When I saw the MSX running with
> >> Z380 made by Ademir, the whole thing only works with the Z380 using
> >> 5 or MORE waitstates on any task. (Z380 has option to turn up to 12
> >> waitstates, with lets it be slower than a Z80).
> >Has it this option built-in the Z380??? Cwl!!!
>
> Yes... I do not remember, but ther is commands to do that. It's nice.
> Z380 also have a Z80 mode, when it turn on a number of waitstates and
> disable some registers so it works perfectly like a Z80... in a sigle
processor,
> without S1999... qqq-:
Oh??? So the same timing as a Z80?
~Grauw
--
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<
email me: [EMAIL PROTECTED] or ICQ: 10196372
visit the Datax homepage at http://datax.cjb.net/
MSX fair Bussum / MSX Marathon homepage: http://msxfair.cjb.net/
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
