Hello, some conclusions, quotes, ... >Yup, he's completely correct. Just run your machine on 3.5MHz if you want >to hear the music correct that would be a waste of cpupower (7MHz). (for example demo's, games, ... all need cpupower AND music together) >This cartridge contains a 3.5MHz clock chrystal... And in the case of the >MSX-Audio... Another cartridge to send a wait-state to the MSX everytime >I/O-acces is done??? >Anyway, when everyone was really obeying to the standard, I think every >chip like the MSX-Audio would have to send a wait-signal to the CPU >everytime I/O-access was done, so that it will also work on future faster >MSX-computers. This is not necessary because msxcomputers with 'turbo'-features (should) switch back to 3.58MHz. This is easily implemented by checking /IORQ. (Though a wait-construction will do better because you wouldn't need different driverprograms with different delays. This requires a lot of cartridge/hardware-fixes :-C) ] (Even on Turbo-R in R800 mode the CLOCK signal is 3.58MHz, can someone ] confirm this? >Yes, it is 3.58Mhz indeed. >The MSX standard requires "CPU clock, 3.58 MHz." on pin 42 (which >would it be?). Even if the MSX standard is not clear about this, it is a fact that ALL 'official' msxcomputers today have a fixed 3.58MHz clock at pin42. And all cartridges that make use of the CLOCK expect a 3.58MHz clock. (Modems, midi, ...) >:-harddisk-interfaces; will probably have their own clock, >:or don't need one, but maybe....(take your guess) >That would be a **big**problem. ??? The 3.58MHz is right there were it should be, at pin42. (But I think clock is not used in SCSI interfaces; correct me if I'm wrong) Most SCSI interfaces (all??) use I/O ports, so during I/O msx is switched back to 3.58MHz The Sunrise IDE doesn't use a clock (it also uses addressmapping like the SCC, so this has the advantage of no-port-conflicts, more than one IDE in the MSX and data can be transferred at busspeed without I/O delay) >:What's next, is to consider what should be on pin 42: CPU clock, or >:3.58 MHz.? It seems obvious to maintain a fixed 3.58MHz clock at pin42. >:Using one of only 2 reserved pins for a CPU clock or 3.58 MHz. >:signal, sounds more a less like a 'waste' to me. A busclock signal is important enough to spent a pin for! Necessary to connect highspeed devices to a 'turbo' msx (7MHz, Z380, ...) Future enhancements to the MSX standard (DMA, ...) will certainly need a larger bus anyway. >external RESET, NMI, ... Not as important as a BUSCLK signal if you ask me. There is no demand for that, while all 7MHz users will certainly enjoy cool music while looking at fast videoaction. It only takes some easy rewiring to the current 7MHz (and other turbothings). A BUSCLK signal at pin16 should more be seen as a capability of your 'motherboard'. If your 'msx-motherboard' doesn't support it, you won't be able to use memorymappers depending on the busclocksignal. That's the only disadvantage. On the other hand, if it supports it, all your devices will work ok (sounddevices, midi, baudrategenerators, ...) at 7MHz without the need to make any changes to them. State of the hardware proposal: ------------------------------- *A fixed 3.58MHz clock at pin42 *A variable BUSCLK signal at pin 16 which reflects the read/write-cycle timing Modifications needed: -All 'official' MSX computers (MSX1,MSX2,2+,Turbo-R) Make a connection between pin 16 and 42 of the cartridgeconnectors -7MHz computers or other 'turbospeeds' 'Delete' the current connection to pin 42 of the cartridgeconnectors and redirect it to pin 16. Find the original 3.58MHz clock and connect it to pin 42. -Most cartridges (all sounddevices, IDE, ...) No modifications needed! -Memorymappers depending on the read/write-clocksignal (most mappers, except the one mentioned from digital kc that generates its own refreshsignals) 'Delete' the connection to pin 42 and and redirect it to pin 16. Note: perhaps it is possible to use unmodified mappers in 'turbo-msx's' when the turbo is switched off. The mapper will use the fixed clock at pin42, but it might be needed that this clocksignal should be related to the read/write cycles on the bus (for the refresh) and since there is no such relation it may not work. >I only hope, that we can keep some kind of standard on hardware. >We have allready seen what happens, when all computer makers start to >expand their systems in their own style. (PC) That's why I want to discuss it NOW and not when Z380 motherboards are leaving the factory ;-) Jon **** 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/) ****
