>Well that's one thing indeed :)
>However some programs who don't time using the interrupt but depend on the
>speed of the videoprocessor will work too fast then...
Well... The old modes work slowly, newer modes works faster! (-:
>I always keep faster MSX-computers in account in these cases (Strategic Army
>has a test in it: if a scroll takes less than 3 interrupts, it waits. So it
>will go faster on a futere (?) faster videochip but never too fast. Nice
>example of this is Warcraft II for the PC. The scrolling goes so fast on my
>PC (in the slowest scrollmode!) that I can hardly play it anymore!
Yeah, I know.... I used to play Warcraft II... (-:
>Yes, but they probably wait less than 7 T-states.
Actualy, I think yes.
>No, no... not at all! Strategic Army will work faster on a Z380. Ofcourse
>not in full speed but surely faster. Just because the COPY-commands will be
>executed sooner after eachother a quite noticable gain in speed is made.
>Example of this is Fray, turboR version compared to MSX2 version.
Fray TR x Fray on 7Mhz is almost the same (of course, without the
PCM things). I really understand, but faster CPUs can also has faster
BIOS acess... (-:
>All VDPs DO work at the same speed. The I/O-speed though isn't the same
>everywhere. This because of larger datalines, slower controllers, etc.
>But indeed, on some VDPs waiting 4 T-states or even 0 T-states will work,
>but not on other VDPs. However, waiting 7 T-states has proven to be long
>enough for EVERY MSX2 and 2+ model (dunno about MSX1).
No. As was discussed sometime ago on MSXBR-L, there is minor
timing differences between VDPs, that makes those strange dots
appear on some of them, and not on others.
>Well, actually my FM-pac has never had any problems on 7MHz.
Here I have one (with FMPac only, not with the internal FM): When the
7Mhz is turned on and teh FMPac cart is inserted, if I go to basic, when
I return (_SYSTEM), the system hangs... /-: Weird. BUT, there are other
problems, like Aleste2 music completly crazy.
> My MSX-Audio has, though.
>And maybe the developers of Fray just inserted an extra wait between 2 I/Os.
>But I don't know. They will have probably done the same in Fray as in
>Illusion City... I'll check out the FM-pac driver...
The question will be always "how much wait is really needed"?
>Well now you indeed have to choose one of the three drivers, depending on
>the speed of your computer (3.5MHz, 7MHz, turboR)... I think they should
>have added wait states on the MoonSound already... If an IOREQ happens too
>soon after the previous one it signals the Z80 WAIT pin...
>But they didn't do that... probably has something to do with the price or
>so...
Maybe. Or maybe they just have not find it would be a problem... (-;
>> I agree. When talking about "time critical apps", yes.
>A lot of games are time critical apps (or at least, I think they should be.
>Use your MSX 'till the bottom).
MSX2 games, with FM, PSG, Moonsound, etc. of course. ZX Spectrum,
PSG and Screen1 no.
>> There is really a Mouse specification for MSX? I look for it, but the
>> info was very poor.
>There can be found some very complete info on MiLC. Also, I have written an
>article about it on Track. However, it's all Dutch...
I really need to learn dutch! ((((-:
>Hmmm... okay. Perhaps. But they used two OUTs behind eachother. That's not
>lazy, that's BAD PROGRAMMING.
Hehehe... (-:
>By the way, the Z380 engine should also delay the MoonSound ports... (since
>the developers of the MoonSound haven't included a 'wait-engine', or
>whatever it's called).
I really hate waits... Everything could works without them, MSX would be a
paradise, today... (-: Unfortunately, we NEED waits... /-:
>- Ofcourse, if you do not use mapper changes then you don't need the
>mapperroutines either.
Hehe.
>- 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... (-:
>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".
>> 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.
OR
MSDOS cannot go further than 640Kb. MSX can't go further than 64Kb. (-:
>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.
>It isn't perfect for the current system either. They could for example have
>included support for multiple mappers too. (well, in fact it is there, but
>you'll have to do the slotswitching yourself).
It's very difficult to do in the perfect timing when during a heavy program
(such a heavy game).
>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... (-:
>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.
>> 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-:
[]'s Daniel Caetano ([EMAIL PROTECTED])
...Have you turned on your MSX today?
OS/2 Sites: http://www.os2brasil.com.br/novidades/
http://www.os2brasil.com.br/novidades/drivers.shtml
http://www.geocities.com/SiliconValley/8752/os2hp/index.html
MSX Sites: http://www.fudeba.cjb.net/ e http://www.msxnews.cjb.net/
MSX Phoenix: http://www.msxphoenix.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/)
****
