vgmrips

All I want is to decipher the bit fields in that element table at 0x176ab in the program ROM.

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

Okay so here's how it works.

- The instrument table at 0x10410 has the following data (this is what I've figured out so far):
- Instrument uses two elements (bool)
- Level (volume) for element 1 and 2
- Detune for element 1 and 2
- Pan for element 1 and 2
- Name (8 chars, space padded)
- Region group ID for both elements

Each entry in the table starts with 16 bytes that hold Level, Detune, two elements bool, and other stuff I haven't figured out yet.
Next 8 bytes is the name
Next comes a pair of 36 bytes, one for each element
First two bytes use only the lower 4 bits to select the region group
Within these 36 byte chunks are also Pan bytes (pan goes from L7 to R7)

The Region group ID is an index into the table at 0x1841C (I might be off by a couple of bytes). That table has the start index into the region table at 0x176ab. The next index in the same table is the next start index, you can use that to compute the number of entries used.

So to view the samples used by an instrument, go to the instrument table at 0x10410, go to bytes 24 and 25 for element 1, and 60 and 61 for element 2 (if the first byte of the entry is 1, which means it uses the second element). Put those bytes together and you have an index into the table at 0x1841C. Read the value there (let's call it N) and count N entries, or N*9 bytes from the start of the region table at 0x176ab. You select the region you're interested in, depending on which key you're playing, and you have the sample number, which is an index into the sample rom table, which is at its beginning.

See this spreadsheet for more details.

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

Here is a capture from the chip:

sync word is 0xeeee, every 9 words
data is samples (1/44100 of a second) then D0-D7 and A0-A3

It goes out of sync sometimes, so I'm not sure what's up. I'm still trying to figure it out. Capture was made with a 3000000 baud rate and a FT232 board. I am not sure what the results should look like, so can someone check if the data is good?

I've logged since turn on of the device up to playing the demo song until the end.

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

Not sure if I can make much sense of this unless /CS (/GEW8) and /WR is logged as well. I see there is 32 bytes of data between each 0xEE,0xEE sequence.

An example sequence looks like this (there are 8 four byte sequences per sync word and not 9):


So the "ff,f8" part in the first line is the data present on the bus?. I think that you could actually get rid of the "samples" part, as timing is not something we're too concerned about now, just the data instead.

Here are the connections:
/WR - PD15
/CS - PE1
D0-D7 - PD0-PD7
A0-A3 - PD8-PD11
NC - PD13,PD14
/RD - PD12

I am triggering on /WR, and checking if /CS is low in the interrupt handler. Here is the ISR:

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

Ok here's another capture, this time in binary and with a marker for every write. you'll notice that the second byte of data always has the 0x80 bit set, that's because it's /RD.

At the beginning it goes out of sync at some point then it seems to be ok.



Edit: I've fixed the timing code. I was counting up to 3773 at the mcu's clock, which is 168MHz in this case. I've changed it to prescale by 3810 and count up to 65535. This way the timing should be for real. 168000000 / 3810 = 44094.5. Reattached another log. I've noticed that when I hit play on the demo song, it freezes up a bit, I assume the CPU is doing some intensive work and not sending any data to the YM chippo.
Edit 2: Perhaps if we can figure out which messages to ignore, I can reduce the log's size.
Edit 3: I can also log VGM data directly, not sure which commands though.

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

Perhaps we can ask that R. Belmont fella why MAME uses only 3 of the 4 address lines

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

It's actually emulating 3 of the 16 possible addresses.

I looked at your captured data and made a list of commands and how often they occoured:
The first byte is A0-A3/RD/WR, the second byte is D0-D7. The last column is how many times the commands were captured. (in decimal)
It doesn't make sense to be, though. I think there should be a more commands.

I think it might be a good idea to enter the TG100 test program and do a capture while executing test #10. It will play a tone on all 28 channels sequentially.

And, yes, I made a similar program to analyze the log and get pretty much the same results as Valley Bell. It seems like there are only 26 unique commands in the log.

Okay, so I thought that 0x80 bit being set was a little weird, since the code was meant to read it while it was low. It's actually /CS, not /RD. The ISR is a bit slow and reads just after the /CS and /WR lines have gone back to high state, so all that data was bogus. I'll make it so it uses a DMA to read the GPIO port instead, perhaps that'll make it more responsive. This is on an STM32F4 board, here's what it looks like: http://www.ebay.com/itm/STM32F4Discover ... SwOyJX-NcZ

If you look on the scope, you'll see the top signal, yellow, comes a bit after the middle one (cyan). Top is an output pin from the micro, middle is /CS and bottom is /WR.

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

So I made a small breakthrough in reversing the program ROM.

Looking at the MAME source, I found out that the YMW258/MultiPCM maps channels in a slightly unusual way. In MAME the channel map table looks like this


i found an equivalent table in the program rom at 0x14e10 to used to convert logical channel numbers to physical (how the chip recognizes them).


This led me to find the write to chip function

(There are also variations of this function to only set the channel and to write data to a register.)

Just like the MAME MultiPCM core, this only uses three addresses to set the channel number, register number and to write the data.

Okay, thanks for the tip. I've managed to enter that menu, it only works with the midi cable connected from in to out.

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

Okay, I've managed to configure the DMA controller, here's the code for anyone curious, and a new capture. Unfortunately I'm still struggling to get timing information in there (trying to configure a second DMA stream triggered by the same signal to read a timer counter), but I think the data is probably less bogus this time. It starts before the demo song and ends after it.

The capture file format is now: 0xeeee, then 16 words of data. The wiring is now, from LSB to MSB: D0-D7, A0-A3, /RD, /CS, NC, NC. To read the file, ignore words with /CS high. These are captured by DMA, so they should be closer to the truth. I have no way of checking currently, would need a 16 channel logic analyzer.

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

Here are some more captures, this time with timing. I am using one DMA transfer, without much buffering, but it seems to work well. I was hoping to use DMA entirely but I couldn't figure it out.

Included are test mode 10, startup, idle state and demo song.

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.

Here is another capture. It is a few midi notes. See if you can recognize the song.

With this one I've cleared the top bits of the second byte, so it's purely D0-D7 and A0-A3

_________________
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.