Skip to content

TG100 sample ROMS

Technical discussion which is not directly related to VGM files. Talk about Hardware and Software.

Moderator: Staff

Post by vampirefrog »

ctr wrote:hat would make reverse engineering the program ROM much easier.
Wouldn't a disassembler do the same job? The instruction set is quite simple. There's a byte selecting the addressing mode, it can have some arguments, and then there is the instruction byte.

Edit: it seems GNU binutils have some support for h8/500. It seems there is better support for H8/300, and support for H8/500 has been dropped a while ago, so I suppose using an older binutils would do the trick. It is not clear when the support was removed, though. Either way, as long as it disassembles, it should be good.
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

Oh, I'm disassembling it too. IDA supports the H8/500 series. But it would help with the effort if I knew where the addresses actually go to. The gate array decodes addresses and generates the CE signals for each device. Since MAME does not emulate the H8/500, I can't mess with emulation either.
  • User avatar
  • grauw Offline
  • Posts: 150
  • Joined: 2015-02-22, 3:40:22

Post by grauw »

Linux OPL4 driver, GM patch table

If the TG100 ROM is similar to the YRW801 ROM, might be useful.
Last edited by grauw on 2017-07-26, 19:09:20, edited 1 time in total.
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

Actually, nice of you to mention that. I compared the TG100 sample ROM and the YRW801 and the samples appear to be identical. (there are only a few single byte differences) The sample headers are different though, the TG100 uses most of the 512 sample slots (there are a few duplicate sample entries, but with different envelopes), while the YRW801 has a Yamaha copyright and some extra random data at 0x1240 (appears to be used to generate noise). The first few entries of the sample headers are identical though so that could probably be used to decode the instrument definitions in the program ROM.

Post by vampirefrog »

perhaps look for consecutive values that are 15 bytes apart, since opl4_region is 16 bytes long afaics

Edit: At offset 0x176ad, 9 bytes each record
Edit 2: It seems to start 2 bytes before that, at 0x176ab, with the sample number. The first sample 0x1ee sounds like a low piano note, so that's probably it. So far it seems:
- Starts at 0x176ab
- 2 bytes: sample number
- 1 byte: key min
- 1 byte: key max
- 2 bytes: pitch offset
- 1 byte: tone_attenuate
- 1 byte: reg_attack_decay1
- 1 byte: reg_release_correction
- Total: 9 bytes
- Not sure what they mean though
  • User avatar
  • grauw Offline
  • Posts: 150
  • Joined: 2015-02-22, 3:40:22

Post by grauw »

vampirefrog wrote:- Not sure what they mean though
Not sure if this is the part you were unclear about, but it defines which sample to use for which key ranges, with a few modifiers. So that you don’t get strange-sounding timbres when playing at a pitch too far from the sample’s original frequency, and to reuse samples as well. E.g. the bright piano is using the same samples as the grand piano, but played at a higher pitch, so their timbre is different.

Post by vampirefrog »

grauw wrote:
vampirefrog wrote:- Not sure what they mean though
Not sure if this is the part you were unclear about, but it defines which sample to use for which key ranges, with a few modifiers. So that you don’t get strange-sounding timbres when playing at a pitch too far from the sample’s original frequency, and to reuse samples as well. E.g. the bright piano is using the same samples as the grand piano, but played at a higher pitch, so their timbre is different.
I mean mostly:

- 2 bytes: pitch offset
- 1 byte: tone_attenuate
- 1 byte: reg_attack_decay1
- 1 byte: reg_release_correction

Also, It became apparent to me that the YM envelopes are not compatible with the SF2 envelopes, so making a 1:1 sound font might not be possible.

Post by vampirefrog »

Here is current and previous research.

Edit: added Instruments sheet with hex data for easier reversing of the engineerings.
Attachments
TG100 tables.ods
(28.23 KiB) Downloaded 284 times
samples.ods
(75.34 KiB) Downloaded 292 times

Post by vampirefrog »

I believe I've found something at 0x1841c: it is a list of monotonously increasing 16 bit ints, that stop below 0x17e (382), which is the number of regions. Looks like 140 entries, which is smaller than the instrument table length at 0x10410 (192 entries).

Edit: they match up. See samples.ods above. I've also shifted the pitch_offset value 2 bits to the right, it seems that particular structure is made from bit fields, not just bytes. The struct in the opl4 driver code was expanded to bytes cause it's easier to use that way.
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

It looks like R.Belmont from MAMEdev took a look at the pinouts and confirmed that the YMW258 is the same as the MultiPCM.

Post by vampirefrog »

I've done a few corrections to the TG100 Tables spreadsheet (see above). Also, the first column in the samples spreadsheet has 2 values: 00 = 1 element, 01 = 2 elements.

Post by vampirefrog »

ctr can you link to:

- R. Belmont discussion
- YRW801 manual/source where you got the info above

grauw, do you know where the GM patch table comes from? perhaps it comes from a binary and it uses bit fields instead of bytes
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

vampirefrog wrote:- R. Belmont discussion
forums.bannister.org shoutbox. It's not logged so much of the discussion is gone by now.
vampirefrog wrote:- YRW801 manual/source where you got the info above
I just compared the rom contents. See output below.

Code: Select all

1) 0=0x0 to 0=0x0 (1 bytes)
2) 12=0xC to 12=0xC (1 bytes)
3) 24=0x18 to 24=0x18 (1 bytes)
....
785) 4608=0x1200 to 4725=0x1275 (118 bytes)
786) 4727=0x1277 to 5128=0x1408 (402 bytes)
787) 5130=0x140A to 5942=0x1736 (813 bytes)
788) 5944=0x1738 to 6139=0x17FB (196 bytes)
789) 6141=0x17FD to 6142=0x17FE (2 bytes)
790) 524287=0x7FFFF to 524287=0x7FFFF (1 bytes)
791) 1572872=0x180008 to 1572872=0x180008 (1 bytes)
792) 2097148=0x1FFFFC to 2097148=0x1FFFFC (1 bytes)
793) 2097150=0x1FFFFE to 2097151=0x1FFFFF (2 bytes)

Post by vampirefrog »

I've setup a git. Please request access if you want to add something. https://github.com/vampirefrog/tg100
  • User avatar
  • grauw Offline
  • Posts: 150
  • Joined: 2015-02-22, 3:40:22

Post by grauw »

Vampirefrog, it’s the OPL4 linux driver, it’s existing for ages. Not sure if it came from an official vendor, or some Linux dev who got provided the official data, or retrieved the table data from the SoundEdge software or by disassembling the SoundEdge drivers, or just manually build a table, could be anything. Though I’d assume they put at least some effort into getting the official tables. Could try to find and disassemble the SoundEdge Windows driver if you want a second data point.
Last edited by grauw on 2017-07-28, 18:58:42, edited 2 times in total.
Post Reply