While I wait for the GFX-NINE graphics cartridge I have got another I/O MSX cartridge to play with.(only to demonstrate how well the M-Slot adapter works...)



As you can read on the MSX.org web page, this was an all-in-one music cartridge released for all the MSX computers.

Its features are :


 -   32KB of sampleRAM for the ADPCM unit
 -   MIDI interface (with IN/OUT/THRU connectors)
 -   Proprietary connector for music keyboard (NMS-1160)
 -   2 RCA mono Audio-out connectors
 -   built-in microphone (mono)
 -   1 RCA external microphone connector (mono)
 -   volume adjuster (sample volume)
 -   1 audio-in RCA connector (mono, to sample from a "line"-source)
 -   built in software (Music-BOX, CALL MUSICBOX)

Impressive, isn't it? but its main drawback is that it only outputs mono sound. Inside, it has the Yamaha Y8950,  sound processor installed. Here follow  the main specs:

-Realistic FM sound generator compatible with YM3526(OPL)
-Simultaneous play of 9 tones or 6 melodies
-AM vibrato
-4-bit ADPCM voice analysis/synthesis circuits(on other descriptions they say it is an 8 bit ADPCM)
-AD/DA converters
-Up to 256KB of Ram can be attached for ADPCM data storage(only 32KB installed on this cartridge)
-8 bit input/output ports for simple piano keyboard scanning.

Philips used to subcontract its products, and on its MSX range this module wasn't an exception. It was created by  Richard Watts Computers LTD(Music Sales LTD), who, commissioned by Commodore, also made a similar product for the C64.

It was sold only in Europe, but it  had great success.(Appears now and then on Ebay.)

Often it was offered in a bundle with a passive 61 keys piano keyboard(hollow, without added electronics). I have used a cheap Chinese toy piano to replicate its functions...  

It is a very big cartridge, the SE-ONE and GFX-NINE ones are only a little higher than the black zone in the case...

At the end of its Service Manual there is a MSX Basic listing to test its features. Is this program what I will translate to IS Basic to try its features more easily.

It uses ports 00, 01, 05, 10, C0 and C1.  00 and 01 can collide with the 'Meszaros' Serial card, scarce today. But 10 is a problem when the EXDOS interface is connected. 05, C0 and C1 are still unused.

Here is the MSX Basic listing as it comes in the manual:

Good idea!

Yeeeeaaahhh! This is my dream
 
"MIDI interface (with IN/OUT/THRU connectors)"

Leaving the MSX cartridges to use the EP port has been a meditated action. First, MSX cartridges only use the lower byte ports, second the alluded two higher bits messed up by Dave, and the Enterprise tradition of only use 8 bit decoding on ports, and third, the fact that the more interesting MSX cartridges(GFX-9000 and Sunrise MP3) don't collide with existing Enterprise expansions.

On the CPC MSX adaptation, Hans(TMILogic) and Prodatron have opted to move all the 256 MSX ports to FFXX, because on the CPC computers there where a lot of port collisions, and the fact that a 16 bit port is decoded as only the lower byte on the MSX computers, so the same  code can work on CPC and MSX(SymbOS). But the Enterprise would use some of the higher bit of the port, so that method will not work on our computers. Then better to use only 8 bit ports and act like a MSX computer.

The idea of Prodatron was to benefit of the MSX short range of ports to write only one version of the SymbOS code(common for CPC and MSX) with all 16 bit port addressing. Then the same code can work on the two systems. This could have also work on the Enterprise, but the range selected, FFXX, is not possible due to Dave messing up the higher bits of the address.

So 16 bit addressing is not the problem, the problem is that the Enterprise Z80 can't be sure of the address if, let's say, the port FFC0 is accessed.

On the other side, but Zozo can explain it better than me, there is the erroneous "8 bit port tradition" on the Enterprise. Only the unused ports on the 0-255 range can be used for 16 bit addressing, because the used ports have been unsafely implemented and have mirrors on all the 16 bit range. It seems to me like space trash....


Edit:
Pear's idea is better, if the control port of a valuable function on a MSX cartridge collides with one Enterprise port, the best is to redirect it to an unused port.

If the existing software uses the instruction OUT (n), A with 8-bit addressing, then there may be problems when decoding the full 16-bit address.
It's because OUT (n),A exhibits the value of n on the bits A0..A7 and the content of A on the bits A8..A15 of the address bus (after which the contents of A is exposed to the data bus).
Hardly anyone knows about it and rather does not care about the content of A before performing OUT.
The same applies to the command IN A,(n).
The problem of the highest two bits masked by Dave, is a small problem with its (it can be mask the addresses used by Dave).

Yes, exactly this is the reason I proposed a low byte with 'E' bits set to a fixed "pattern" to activate the translation (so the "activator" is in the low byte, accidents cannot happen ...): no regular 8 bit I/O would trigger it.

Again:

- - M M M M M M | E E E E E E M M

From the 16 bit I/O address on EP128. High 2 bits are not used, since Dave masses them up. 'M' bits forms a 8 bit I/O address at the "MSX side", but only, ie 'E' bits matches our well-selected constant value. 'E' bits should be chosen to be some fixed value which triggers the I/O for the MSX card, when the result address will be only 8 bits, formed from 'M' bits. Regular 8 bit I/O at EP side wouldn't trigger this by mistake or so (what you write about) since it would require the 'E' bits match the "Key" constant value.

I'm not sure, but if it's not planned to do anything with MSX card just I/O (I am not sure if it's planned to use cards using also memory access not only I/O space ...), then maybe it can be even "hard-wired" the address bus that way, but "gating" the I/O request also with an additional signal, when 'E' bits matches our "magical" constant.

But again, it's only an idea from me, quite generic which can solve the I/O port collision program with a future-proof approach, though it has its price, for sure ...

I have found my old midi keyboard. It has toy keys, but also has IN and OUT connectors to try the cartridge.



I have modified the Basic lines to read and save the incoming key presses on a matrix variable. Then after a key press, the saved notes are returned to the cartridge:

  100 TEXT 40
  110 DIM SONG(1 TO 1000)
  120 OUT 0,3:OUT 0,21
  130 FOR N=1 TO 1000
  140   LET SONG(N)=IN(5)
  150 NEXT
  160 PRINT "Press a key"
  170 LET A$=INKEY$
  180 IF A$="" THEN GOTO 170
  190 FOR N=1 TO 1000
  200   OUT 1,SONG(N)
  210 NEXT
Well... it seems to take some key presses, because I hear some notes on the second part... but Basic is very slow, so I have to repeat this on machine code.