> >> No. In some situations you need to wait a long time (imagine the wait
of
> >> 2 NOPs on a 7Mhz cpu or on TR). We ALWAYS want speed but 100%
> >> compatible.
> >No. On EVERY 7MHz board the processor switches back to 3.5MHz when
accessing
> >the VDP. SO that's compatible.
>
> You forgot that NOP is not an VDP Acess, so it will happen at 7Mhz in
the time of 1 NOP
> at 3.57Mhz.
I don't know what it does exactly but I do know that it slows down the
processor and it >>ALWAYS works<<. As long as those 7T-states delay are
inbetween.
> > On the turboR, an auto-delay is inserted by
> >the MSX Engine. So there even two OUT-instructions behind eachother
works!!!
> >The processor will automatically wait the nessacary time.
>
> 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.
> >So inserting two EX (SP),HLs is just a big, unnessacary waste of time, as
> >well on 3.5MHz, 7MHz and turboR MSX computers.
>
> Ok. This type of programing give us A LOT of trouble correcting programs
> and trying to find out 'why it's not working while all other programs work
well?'
No, I think not. I have never had any timing-problems using the VDP.
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.
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.
> >> FAST almost always means incompatible.
> >What should I use the BIOS for?
>
> Acess VDP, there is problems and diferences of timing when using VDP1 or
> VDP2 or VDP3, use the mouse. Use OPL driver to Acess FM (acessing it
> directly causes almost all games have a BAD sound under 7Mhz), use
> BDOS to acess disk (or you'll have problems with port based or memory
> based interfaces (it will depends on how have you done the direct acess).
Access of VDP has no problems on any MSX as long as you keep 7 T-states
between 2 OUTs.
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).
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 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.
> > The only incompatible thing for which I
> >should actually use the BIOS is the mouse... but reading the mouse is a
> >really speed-sensitive thing (readout is done every interrupt)... So I
don't
> >use that BIOS-routine.
>
> Hehehe... Ok. That will be your problem if the program work only in your
> hardware.
I usually program very hardware-compatible. I only heard about the
timing-problems with the mouse shortly ago (although I could have predicted
it). 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.
> If you NOT use BIOS, you are NOT programming for MSX standard. You
> are programming for a computer using, Z80, V99xx, PSG, YM2413,
etc,etc,etc.,
> on the same ports/addresses than a MSX.
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!
> Why? Because the standart says to use the BIOS... Even if it is slow.
And
> if someone do a NEW MSX and DO NOT reprogram the BIOS, than it will
> not be a good MSX. There is the need of a new BIOS. And you'll see
something
> about it in the future.
Well if I used the BIOS I would not be able to realize Strategic Army.
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.
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...
> >About other things... I only use the (Disk-)BIOS for disk I/O. The BIOS
is
> >really useless, the most needed BIOS function is not even available (only
in
> >MSXDOS2)... Can you guess what I'm talking about? Right! Memorymapper
> >management routines!!!
> (-: This is right... But this is THE ONLY thing I do not want to use,
because the
> DOS2 memory management is really weird.
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.
Sorry but this really damages your credibility. Be consequent.
> >If they had included these... That would be another story.
>
> Why not WE include?
Yes but they are already in Dos2 now. So it has already been done.
> >Please name some other thing which could be incompatible when not using
the
> >BIOS...
> >- Mouse? Indeed a problem because of timing, but the BIOS routines are
way
> >too slow (I can program it at least 6 times faster). Aargh!
>
> Yeah, but it will work everywhere? If it's 60 times faster but runs only
on my
> system, it's useless.
Well as I said it indeed is a problem... one has to make choices...
> >- VDP? Timing is indeed quite strict, however the speed is much too
> >nessacary to keep account with that. Therefor the faster MSX computers
have
> >adaptions to slow down VDP access.
>
> 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.
> >- Disk? Is definately incompatible using direct I/O. Is too difficult to
> >program though so everybody uses the (Disk-)BIOS anyways.
>
> (-: This is the worst point of direct acess!
Indeed.
> []'s Daniel Caetano ([EMAIL PROTECTED])
>
> ...Have you crashed your Windows today?
No... think not. No glass on the floor...
~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/)
****
