Welcome, Guest. Please login or register.


Author Topic: Philips Music-Module MSX cartridge test (Read 523 times)

Online gflorez

  • EP addict
  • *
  • Posts: 2329
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 52.0 Firefox 52.0
    • View Profile
Philips Music-Module MSX cartridge test
« on: 2018.September.04. 21:11:35 »
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:
« Last Edit: 2018.September.05. 01:45:41 by gflorez »

Offline pear

  • EP lover
  • *
  • Posts: 672
  • Country: pl
  • Z80 only
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Firefox 61.0 Firefox 61.0
    • View Profile
Re: Philips Music-Module MSX cartridge test
« Reply #1 on: 2018.September.05. 06:24:06 »
In the future, you would have to add port address translation to the M-slot (?)
Redirect the ports used in EP to other unused.
The software for EP does not exist anyway, so need to change addresses when rewrite the software.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 12969
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 61.0 Firefox 61.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Philips Music-Module MSX cartridge test
« Reply #2 on: 2018.September.05. 08:40:26 »
Good idea!

Online gflorez

  • EP addict
  • *
  • Posts: 2329
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 52.0 Firefox 52.0
    • View Profile
Re: Philips Music-Module MSX cartridge test
« Reply #3 on: 2018.September.05. 10:37:24 »
Yes, it is a good idea, but we are not in a hurry. The intention with the low cost M-Slot adapter is to benefit from new and reachable MSX hardware development, not from obsolete and hard to find cartridges like the present one. I am trying it as an exercise, not  as a real option for the Enterprise. Apart from the excitement of making it work on my computer, MIDI is the only function on it that really interest me.

We have the luck that the effective EP I/O port area(00-FF) is still almost unused, so better we will face the problem when it appears. But at that moment the best option always will be to create a tailored Enterprise-only card if its use is highly demanded by the owners.

Offline Tutus

  • EP user
  • *
  • Posts: 360
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 61.0 Firefox 61.0
    • View Profile
    • Enterpress News
Re: Philips Music-Module MSX cartridge test
« Reply #4 on: 2018.September.05. 11:33:28 »
Yeeeeaaahhh! This is my dream :)
 
"MIDI interface (with IN/OUT/THRU connectors)"

Online lgb

  • EP addict
  • *
  • Posts: 3491
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 61.0 Firefox 61.0
    • View Profile
    • http://lgb.hu/
Re: Philips Music-Module MSX cartridge test
« Reply #5 on: 2018.September.05. 11:43:03 »
The lamest solution for I/O address "translation" (though, the great value that some does not need a complex "mapping device" there too much):

Use 16 bit I/O addresses on the EP side to address hardware, and the low byte of that should be more or less fixed, not to collide with EP specific things.

Since, Dave in EP has the habit to also "mess up" the 2 upper bits of the address bus even if it's an I/O (and not memory) address, it cannot be used. But surely, we can say, the 16 bit I/O address is divided like this, for example (16 bits from bit 15 down to bit 0, bytes are separated with the pipe sign):

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

"M" is the "MSX I/O" (8 bit) port encoded, "E" is some fixed value choosen, not so collide with any EP128 port/port ranges. So basically if the bridge sees I/O request, with all the "E"-s set to a specific value (always the same) it considers the "M" bits to form the "MSX I/O address" from that as a simple 00-FF range. Otherwise, it shouldn't even bother to "route" the IOREQ for the MSX card. Surely the above "picture" can be written with Es and Ms exchanged in the low byte, but I feel, it's more "nice" to have a the used EP port range in once piece ...

Surely, it's highly ugly, and I/O accesses are a bit more complicated because of the need to take care 16 bit addresses for I/O instead of 8. But it can easily guarantees not to collide with any EP port then. Also, I am even not sure, if MSX cards does not use 16 bit addressing as well, then my idea is simple stupid :)

Online gflorez

  • EP addict
  • *
  • Posts: 2329
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 52.0 Firefox 52.0
    • View Profile
Re: Philips Music-Module MSX cartridge test
« Reply #6 on: 2018.September.05. 12:16:17 »
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.

Online lgb

  • EP addict
  • *
  • Posts: 3491
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 61.0 Firefox 61.0
    • View Profile
    • http://lgb.hu/
Re: Philips Music-Module MSX cartridge test
« Reply #7 on: 2018.September.05. 14:04:56 »
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.

Yes, the MSX card as I've written would only get a 8 bit I/O address, constructed from the 'M' bits, which is 8 bit only. What I wrote, is only at the EP128 side, with EP128 software to avoid possible any future collision as well. I left out to use bits 15 and 14, exactly because Dave will mess those up. The value here, that since the 'E' bits would be selected to a fixed value not to collide any EP port even if 8 bit only decoding on the EP side, so just using regular 8 bit I/O for EP hardware (like Nick, Dave, EXDOS card, whatever) would put something on the high 8 bit of the address bus too (Z80 always use 16 bit addresses even with I/O just it's sometimes tricky to figure out what the high byte is exactly) but it wouldn't cause problem, since the lower byte would not match the 'E' bits that the MSX I/O address "translation" catch it up to construct a 8 bit I/O addresses from the 'M' bits then. So I think, this solution is perfect and collision proof, though it's lame because of one reason: the need to use 16 bit I/O addressing to access an MSX hardware (which will get only 8 bit address though ...).

Online gflorez

  • EP addict
  • *
  • Posts: 2329
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 52.0 Firefox 52.0
    • View Profile
Re: Philips Music-Module MSX cartridge test
« Reply #8 on: 2018.September.05. 15:41:57 »
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.
« Last Edit: 2018.September.05. 15:48:24 by gflorez »

Offline pear

  • EP lover
  • *
  • Posts: 672
  • Country: pl
  • Z80 only
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 61.0 Firefox 61.0
    • View Profile
Re: Philips Music-Module MSX cartridge test
« Reply #9 on: 2018.September.05. 18:27:45 »
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).

Online lgb

  • EP addict
  • *
  • Posts: 3491
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 61.0 Firefox 61.0
    • View Profile
    • http://lgb.hu/
Re: Philips Music-Module MSX cartridge test
« Reply #10 on: 2018.September.05. 20:20:27 »
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 ...

Online gflorez

  • EP addict
  • *
  • Posts: 2329
  • Country: es
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 52.0 Firefox 52.0
    • View Profile
Re: Philips Music-Module MSX cartridge test
« Reply #11 on: 2018.September.06. 10:56:59 »
Sorry LGB, I have to read more. Now I understand that you offered a way to pass an 8 bit number to an hypothetical "port translator". Very clever...

About reading MSX memory(Ram or Rom), it has a very different pagination system, so on the CPC and Enterprise MSX adapters, the memory access has been de-activated.

----------------

21812-0

21814-1
(Sorry for the low quality)

I have made work the Basic listing. I have disabled options 1 and 9, Rom checksum and launch the Rom program. All the rest of the options work, but without sound, because I don't know the command to initialise the amplifier.

Surprisingly the test on the MIDI ports was also successful, but is only a very simple test with a Midi cable connected between IN and OUT. The program makes a reset of the serial chip, sets the protocol as 8 bit+1 stop bit, and sends(MIDI OUT) bytes 0-255. At receiving(MIDI IN), checks if it is the same number.

Code: [Select]
450 REM aciatest
  470 PRINT AT 8,6:"Testing ACIA"
  480 OUT 0,3:OUT 0,21                   ! 00000011=reset, 00010101=8 bits+1 stop bit, -16(?)
  490 FOR N=0 TO 255
  495   OUT 1,N                          ! MIDI OUT
  500   LET RD=IN(5)                     ! MIDI IN
  510   IF RD<>N THEN PRINT AT 11,6:"ACIA ERROR":GOTO 220
  520 NEXT
  530 PRINT AT 11,6:"ACIA ok"

Probably the Midi Baud-rate is fixed, I have to test the ports with real MIDI gear....
« Last Edit: 2018.September.06. 11:04:52 by gflorez »