vgmrips

ctr: in your disassembly, could you find where the UART of the CPU is initialized? The hardware manual (pg 251) suggests BRR (Bit Rate Register) at 0xFFD9 and SMR (Serial Mode Register) at 0xFFD8. It runs at most at 38400 baud, I'd like to increase that as much as possible, to decrease MIDI latency. In fact, I think the baud rate is set by reading the switch at the back of the unit, "HOST SELECT SW 2/2", which connects to pin 54 AN1 (analog input probably). I suspect it might be polling that analog pin occasionally, or perhaps generating an interrupt when its value changes. Either way, the baud rate can be either 31250 or 38400, and I'd like to modify the ROM so that when it's set to 38400, it would be much higher instead.

Edit: it looks like the SCK1 pin is just pulled low with a resistor, and not tied to anything else, so I could use it for synchronous communication, which is faster, though something tells me might have some snags when implementing. Still worth looking into IMO. Even with asynchronous mode, the table at pg 264 suggests it is easily possible to get 312500 baud with the 20MHz clock. That would be fine if it means just altering a couple of bytes in the ROM.

_________________
vampi.tech

Thanks, I think I see what I have to do.

In the meanwhile here's the demo song recorded digitally by intercepting the data sent to the DAC and streaming it through an USB device.



I used one of these cheap $2 blue pill STM32 boards for that:



Well, that and over a year's worth of learning and experience with STM32 and USB coding.

_________________
vampi.tech

I am getting ready to end this project. Researching and emulating the DSP chip will have to be someone else's task. I have gathered some service manuals of Yamaha devices that use it. It seems that the YM3413 "LDSP" usually comes paired with the "GEW8" YMW258-F. There is a serial send and receive signal on the YMW, and some more signals that connect them together. There would be a good start for data capture, an 8 channel logic analyzer would work fine. The LDSP seems to require its own RAM, and somehow the gate array is also involved. I am not sure what is up with that. I am also certain that it is possible to figure out what the CPU is sending in Test 10 mode, DSP test. It is probably sending a reverb program (that's what the test sounds like, especially when starting and stopping) to the LDSP and then playing a sine wave in the GEW8 and passing it through the LDSP.

Edward d-tech's page lists the following Yamaha products, some of which are easy to track down and cheap to get second hand, for anyone willing to get their hands on these chips and reverse engineer them all the way.

For GEW8: MU-5, PSS-51, PSR-200, PSR-210, PSR-215, PSR-300, PSR-310, PSR-400, PSR-410, PSR-500, PSR-510, PSR-600, QR-10, QY-20, TG-100
For LDSP: FX-900, PSR-220, PSR-230, PSR-500, PSR-510, PSR-5700, PSR-6700, R100, TG-33, TQ-5, EW-20, SY-22, SY-35, SY-55, SY-77, TG-100, TQ-5, V-50, YSS-100, YSS-200, CLARION DSP-959

I think someone with a 16 channel logic analyzer will have no trouble reversing these puppies, so good luck.

_________________
vampi.tech

Sorry for thread necromancy, but is there a table with loop points for the samples that vampirefrog uploaded?

I think I explained it on the second page.

_________________
vampi.tech

Hi

The LDSP YM3413 has few pins for the CD (code and commands ?) they are pin no. 36, 37, 38 with input signals CRS, CDI and output
signal CDO ... anyone probed these to check what speed and surely there is some some protocol (format of the command). Most synth
and modules use them in a loop, from the CPU to chip 1 chained to chip 2, etc. returning to CPU. For the LDSP some configuration are
likely sent (maybe DSP code that runs) and for other like DEQ chips, maybe on filter coefficients, etc.

If you are interested please help and contribute.

Brahim

You can get a TG100 for under $100 and do these tests yourself, if you want.

_________________
vampi.tech

I have some more information about the pitch offset.

The two bytes of the pitch offset actually have two separate meanings:

1st byte: Note number offset (range 31-109).
2nd byte: Detune offset (range 0-99). A positive pitch offset in cents.

To get the pitch offset to C-4 in semitones, use the formula 60 - n + c / 100.

The pitch offsets are for the TG100’s 9400000 Hz clock (41964 Hz sample rate).
To convert to a 9878400 Hz clock (44100 Hz sample rate), add 12 * (log2(9400000) - log2(9878400)).


Should use the unshifted value. I’ve attached a dump of the regions in JSON format.


The tg100smpl.bin file in the Git repository is two bytes too long. I’ve recombined the two parts and attached it, it’s exactly 2 MB now.

I’ve also looked at the Yamaha MU5 sample ROM. It seems quite different from the TG100’s (and YRW801’s).

However the program ROM uses the same data structures as the TG100. The region table lives at 0x181ae, the region offsets table lives at 0x19b7c (140 entries). The instruments table is also easy to find.

One interesting finding is that the sample headers start with either 0xC or 0x8 (0b11 or 0b10 in the top two bit positions). The former we’ve seen before in the TG800 ROM and means 12-bit samples, and we know from Sega’s systems that 0x0 means 8-bit. But the latter is new.

After inspection of the data, it turns out that the value 0x8 also means the samples are 8-bit. Therefore the current MultiPCM implementation seems incorrect in stating (and implementing) that the bit-ness is determined by the 23rd bit of the start address.

I’ve left a message to R. Belmont here, hopefully he picks up on it and can fix the MAME implementation:

https://github.com/mamedev/mame/commit/ ... #r73389679



Attached is a test VGM that embeds the MU5 ROM and plays some notes on it to demonstrate the emulation issue. I’ve also added a wav of what it should sound like. Note this is not recorded from a real YMW-258-F but from an emulation based on the openMSX YMF278B core.

thanks, I'll commit it into the repo when I get some time

_________________
vampi.tech

I've updated the repo, thanks!

_________________
vampi.tech