Hi folks!
thank you for replying my question about the 7MHz musicreplay. Some
months ago I did some tests: I connected some internal 3.58MHz signal
directly to the SCC and to the MSX-Audio. The SCC did work fine. But the
Audio sometimes skipped a note like Laurens described. I thought this
was due to the fact that the read/writecycles (@7MHz) to the audio were
not synchronized to its clock (3.58MHz). Now I looked it up in the Y8950
manual and there is nothing said about sync. between the
read/writecycles and the clock. So the 'skips' are probably caused by
the too fast I/O in the moonblaster replayerroutine (probably Laurens
used this too).
All this confirms wat Laurens has written.
Conclusion:
-----------
*Moonsound: has its own clock; no problem at any busspeed with the right
I/O driver
*SCC: ok if provided with a (not-syncronized) 3.58MHz clock at any
busspeed with the right I/O driver. (no need to make changes to the
driver below x MHz with x>=7.16MHz)
*MSX-Music: ok if provided with a (not-syncronized) 3.58MHz clock at any
busspeed with the right I/O driver. (no need to make changes to the
driver below x MHz with x>=7.16MHz)
*MSX-Audio: ok if provided with a (not-syncronized) 3.58MHz clock at any
busspeed with the right I/O driver. (extra waits are needed in the
driver for 7.16MHz)
HARDWARE PROPOSAL:
------------------
In stead of building an internal 3.58MHz clock in all SCC's, Audio's and
Musics it would be convenient to have a fixed 3.58MHz clocksignal
available on the cartridgeconnector and also a 'BUSCLOCK' which reflects
the processor's speed. My proposal is to use pin16 for this (currently
'Reserved')
Officially there is the CLOCK signal (pin42) and it should be 3.58MHz.
(Even on Turbo-R in R800 mode the CLOCK signal is 3.58MHz, can someone
confirm this? What about the read/write cycles, are these at 3.58MHz
too? then R800 has no use when programcode is running in an external
mapper?!)
Nevertheless there is one negative point about this: memorymappers and
other 'plugins' which are able to work at higher speeds are not used at
full capacity.
Most 7MHz kits do alter pin42 to 7.16MHz and memorymappers etc. do work
at this high speed which is good. But it is not according to the MSX
standard.
So I would use the current CLOCK signal (pin42) as '3.58MHzCLOCK' and
pin16 (Reserved) as a 'BUSCLOCK'. In this situation there is no need to
make any changes to our sounddevices and all we have to do with our
memorymappers is to change their clockinput to pin16. Using pin16 and
not pin5 which is also 'Reserved' has the advantage that pin16 and pin42
are on the same side of the connector. This makes the modification
somewhat easier. People who don't want to mess up with their mapper can
also make an 'in-between-connector'. Future slotexpanders can also be
provided with a jumper to select between 'BUSCLOCK' or 'CLOCK' for each
device.
Of course you'll also need to provide the processor's clock to pin16. So
your MSX will need an update too:
standard 3.58MHz MSX (and turbo-R?) : just make a connection between pin
16 and pin 42
7 MHz MSX: redirect pin 42 to pin 16 and connect the original 3.58MHz
clock to pin42
Z180/Z380/???: cpuclock to pin16 (18MHz or something) and a 3.58MHzclock
to pin42.
It's not only useful for 7MHz users but also for future MSX computers.
****
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/)
****
