> >> Nah, correct SOFTWARE problems using hardware is BAD.
> >Still it is done so the programmers only have to insert 2 NOPs or an LD
> >A,n-instruction. Doing more is just a stupid waste of time.
> >And I think software problems should definately be corrected with
hardware
> >in cases like this. I think even on MSX2 the MSX-Engine should already
have
> >inserted wait-states when accessing the VDP too fast... It can easily be
> >done.
>
> Well, once you'll correct hardware to adapt it to software, do it right,
at least.
> Do not insert wait states, enhance the video processor so it can be
faster! (-:
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...
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!
> >No, I think not. I have never had any timing-problems using the VDP.
>
> Well, some games that do not wait a big time makes, on some MSXs -
> at least old brazilian ones - some strange dots appear ramdomly on the
> screen. And this is a side effect.
Yes, but they probably wait less than 7 T-states.
> >And by the way, you say correcting software problems using hardware is
bad.
> >However, if you insert 2x EX (SP),HL then do you think that's enough for
a
> >Z380? Eh? Not. So your solution isn't good either.
>
> Maybe. The good solution must be a routine that detects the speed and
then
> calculates how many times is needed to loop the 2x EX(SP),HL... (-: Just
> kidding. Use Z380 with V9958 is almost stupidity. Sorry. You have TWO
choices:
> remake V9958 (and this is something already being done) or you use OTHER
> faster VDP. On Z380 you must put dozens of Waits to work with V9958, which
is,
> as I said before, very bizarre.
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.
> >Anyways, 2x EX (SP),HL is just an unnessacary delay since the hardware
> >already keeps the delay in mind. So you can just use the 2xNOP or LD A,n
as
> >a wait.
>
> Nobody can be condemned by being careful. But if you use risky, without
> the specs, techniques, you can! (-: Just kidding. This is just a BIG error
on
> the MSX hardware. The program should never have to wait anything.
Yes I fully agree with that.
> >Access of VDP has no problems on any MSX as long as you keep 7 T-states
> >between 2 OUTs.
>
> Good luck. I explain what is the problem. Do not admit that all VDPs are
working
> at the same speed.
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).
> >You're right indeed about FM and MSX Audio. On 7MHz it doesn't work
correct.
> >On MSX turboR however it does... But does the MSX Music have a BIOS??? I
> >don't remember... And if they have, this BIOS then it will probably a
little
> >too slow to use on the interrupt on a 3.5MHz machine (stand-alone maybe
not
> >but in combination with other devices like 2xMSX-Audio or so it surely
is).
>
> Well, I think OPL driver has some info about acess it, because some
games
> work GREAT on 7Mhz (see Fray or Valis II). And games like Aleste2, AFAIK,
> work very bad (the sound) on MSX TR on R800 DRAM Mode.
Well, actually my FM-pac has never had any problems on 7MHz. 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...
> >You know what the problem is with the OPL4??? When playing a music using
all
> >channels on a 3.5MHz Z80 you hardly have time left to do other things. So
24
> >channels is actually too much already for a 3.5MHz MSX... MSX-Music +
> >MSX-Audio is 18 channels... Can you imagine you need all the time you can
> >get?
>
> I know. But if you uses standard acesses for them, on 7Mhz it would be
possible
> to work. Otherway, you only can use it on 3.57Mhz, and will be limited by
speed.
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...
> >I never (and nobody should) access disk directly. Just too damn
> >incompatible, and too difficult to do too. Only the program FASTCOPY
> >directly accesses the diskdrive. Advantages of this are that it is the
> >fastest copy-program for MSX and that it can't accidentally overwrite the
> >harddisk or so. Disadvantages are that it isn't compatible with all
> >diskcontrollers, and that new drivers have to be written for new
> >controllers. However, this is a choice Alex has made. Speed is sometimes
> >just too important.
>
> 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).
> >I usually program very hardware-compatible. I only heard about the
> >timing-problems with the mouse shortly ago (although I could have
predicted
> >it).
>
> Ademir Carchano had reported it some time ago... When developing
> AdMouse.
Well I didn't hear about it then (I don't know if I was a member of this
list already).
> > I'll have to test my mouseroutines on a turboR to see if I have enough
> >waitstates inbetween... Maybe the docs I read about the mouse already
kept
> >account on delay for turboR-computers. Anyway, I can easily slowdown the
> >mouseroutines by increasing one single value.
>
> 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...
> >Correction: directly accessing the VDP IS part of the standard. Why do
you
> >think the read/write base port of the VDP could be read from the BIOS?
> >Because it was allowed!
>
> No, because you may need. For what? Make a line using the V9938/58,
> that is not on the BIOS. The standard says to use BIOS always the BIOS
> do what you want (no mention about time you want... :-)
>
> >Well if I used the BIOS I would not be able to realize Strategic Army.
>
> Well, this is a time critical, right? I'm talking about ZX Spectrum game
convertions.
> There is no time critical there. It's just lazy.
Hmmm... okay. Perhaps. But they used two OUTs behind eachother. That's not
lazy, that's BAD PROGRAMMING.
> >Since the standard states that the VDP and the PSG have to be upwards
> >compatible you can assume the I/O ports to be the same. The delay of the
VDP
> >is taken into account on faster MSX computers so you just need 7T-states.
> >The delay for other devices (like MSX Music, MSX Audio) have also been
taken
> >into account on the turboR.
>
> Nice. It'll work on Z380 too?
Ofcourse the Z380 will work about the same way as the turboR (with the
MSX-Engine inserting delays). Otherwise ALL apps using direct VDP access
wouldn't work (and those are a lot! Even 2x EX (SP),HL isn't slow enough for
the Z380).
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).
> >If everybody should use the BIOS then that would result in a PC-alike
> >development, with hardware varying from eachother more and more, needing
> >more processorspeed because the BIOS gets more enhanced, etc...
>
> No! PC programs DO NOT use BIOS. BIOS PC is not updated in a LONG time.
> MSX BIOS was updated more recently than PC BIOS! (-:
> I'm not talking about those news BIOS with dozens of switchs to do the
same
> as the previous jumpers. I'm talking about Keyboard routines, Video
Routines...
> Those routines that no one uses... (-:
Well okay not the standard BIOS. The BIOS of Windows.
> >Well this is very contradictionary. Dos2 Management is NOT weird!!! You
are
> >pledging to use BIOS as much as possible and you don't use Dos2
> >MemoryManagement routines when available??? Your programs will certainly
not
> >work in Dos2 environment.
>
> Work, because I do not use Mapper changes. It's weird because DOS2 do
not
> generate ANY table of processes running and where. THIS is weird. You can
> know what is free, but what is filled with what, you cannot know.
- Ofcourse, if you do not use mapper changes then you don't need the
mapperroutines either.
- Why need a table of processes running and where??? What does your program
have to do with the other programs???
> >Sorry but this really damages your credibility. Be consequent.
Okay okay this sounds a little too picky. But I still think you should be
consequent.
> Think what you want. I'm not to prove anything. I'm just here to talk.
And if you
> think DOS2 memory management is good, look at HOW Linux and OS/2
> do the tasks. Of course MSX has not the power to do such thing at it's
full
> utility, BUT something can be copied.
> 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.
Could indeed have been done better. Now, future mappers which can handle
more than 4MB per (sub)slot indeed aren't supported. However, they might
have done this to keep it as fast as possible (otherwise some programmers
wouldn't use it because it was too slow, an argument I indeed also use in
some other cases like VDP and Mouse, etc).
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).
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.
> Who wants to prove anything is you, trying to prove that acess hardware
> directly is standard.
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!)...
> >> Hehehe... Yes, a lot of waitstates... This is weird.
> >Those 'lot of waitstates' are 1. less than the BIOS has, and 2. it only
> >waits the minimum required time.
>
> 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!!!
> >> ...Have you crashed your Windows today?
> >No... think not. No glass on the floor...
>
> Heheh (-:
Well it was supposed to be a joke...
~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/)
****
