>> 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! (-:
>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.
>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.
>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.
>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.
>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.
>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.
>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.
>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.
> 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.
>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.
>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?
>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 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.
>Sorry but this really damages your credibility. 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.
Who wants to prove anything is you, trying to prove that acess hardware
directly is standard.
>> 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).
>> ...Have you crashed your Windows today?
>No... think not. No glass on the floor...
Heheh (-:
[]'s Daniel Caetano ([EMAIL PROTECTED])
...When you open WINDOWS, you let BUGS in!
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/)
****
