> >> 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
>
> This is weird. VDP needs RAM information to put a single sprite on the
> screen?
??? WHAT are you talking about???
> >> 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).
>
> I'm talking DOS with Himem.Sys. Sorry. I did not specified correctly.
With Himem.sys DOS can't go further than 640kB either. Only some TSRs like
mousdriver, CDROM driver can be loaded into the "upper" memory, that is the
memory between the 640kB and the 1MB barrier. And this 'gap' between 640kB
and 1MB can be even smaller because some old (very old) videocards use some
memory inbetween too.
By the way, it was DOS4GW.EXE I think...
> >And btw, MSX can handle more then 4MB, but only 4MB PER SLOT.
>
> Yes, but it's extremely boring.
? Boring?
Well it's not very handy (???) indeed.
> >> 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.
>
> Again, when you use Himem.Sys, memory page swap on PC acts
> exactly like MSX. And you can use up to 16Mb for code. Talking about
> asm programing.
>
> (it's not right, RicBit? This info I received from a guy called "Paulo
Mario"... On
> that time he sent me a lot of technical info, but I just have not enough
time to
> verify his words...).
You call me RicBit? (turning into the Hulk)
Hmm... I think it's not entirely correct.
> >> 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.
>
> Yep. This is "almost" the idea. New programs would use the first 4Mb
too.
> Including to to a taskswitch environment.
Multitasking?
> >> 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).
>
> as fas as possible when controling the pages free. If DOS
> is single task OS, soh you do not need DOS to control mapper.
> Just use direct acess. Oh, but and my TSRs? Well, TSRs are
> some kind of taskswitch. So, DOS2 is not a single task environment..
> So, it's memory management is crapy, because it doesn't return
> info that MemMan returns... (-:
Well okay. But I still think you don't need Dos to return the info about
other tasks...
> >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...
>
> Right. But DOS2 memory routines do slot switch, or not? They're not on
> the ROM? And when running DOS2 program, the DOS2 ROM is almost never
> alocated in one of the four pages. Or this is a routine that stays on the
upper
> memory?
> If there is slot switching, there is lost of time.
No they don't do slotswitching.
The routine stays in the upper memory (somewhere at #EF00 or so...).
> >I think a new MSX should have them or at least emulate them in a good way
> >(on hardware level).
>
> On the way the software was done, I fear yes, you are right.
Once again :)...
> >> 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?
>
> Yes! Z380 HAVE Z80 mode. In fact, is starts on Z80 mode.
> You have to change it do Z380 mode. The bad thing is, once in
> the Z380 mode, you cannot back to Z80 mode without a hardware
> reset. )-:
I thought only Z80 instruction emulation, not Z80 timing emulation. But that
is great indeed. It solves a lot of problems... The (virtual)
processorswitching doesn't have to be done by the MSX-Engine, moving all
register-values from Z80 to Z380 etc... And no extra processor (the Z80) is
needed.
~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/)
****
