vgmrips

The forum about vgm files
It is currently 2020-07-07, 0:52:59

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 81 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
 Post subject:
PostPosted: 2017-07-24, 12:51:33 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 708
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.

_________________
vampi.tech


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-24, 17:19:17 

Contributors Contributors
Staff Staff
Reverse engineers Reverse engineers
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 430
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.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-25, 22:37:30 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 142
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.

Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-26, 1:22:43 

Contributors Contributors
Staff Staff
Reverse engineers Reverse engineers
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 430
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.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-26, 8:16:48 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 708
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

_________________
vampi.tech


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-26, 19:17:09 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 142
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.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-26, 20:24:12 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 708
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.

_________________
vampi.tech


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-26, 21:18:33 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 708
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 98 times
samples.ods [75.34 KiB]
Downloaded 125 times

_________________
vampi.tech
Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-26, 23:10:31 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 708
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.

_________________
vampi.tech


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-27, 21:36:36 

Contributors Contributors
Staff Staff
Reverse engineers Reverse engineers
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 430
It looks like R.Belmont from MAMEdev took a look at the pinouts and confirmed that the YMW258 is the same as the MultiPCM.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-28, 11:45:55 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 708
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.

_________________
vampi.tech


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-28, 13:59:18 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 708
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

_________________
vampi.tech


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-28, 14:10:02 

Contributors Contributors
Staff Staff
Reverse engineers Reverse engineers
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 430
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:
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)


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-28, 17:24:31 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 708
I've setup a git. Please request access if you want to add something. https://github.com/vampirefrog/tg100

_________________
vampi.tech


Top
 Profile  
 
 Post subject:
PostPosted: 2017-07-28, 18:51:43 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 142
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.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 81 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
[ Time : 0.227s | 17 Queries | GZIP : On ]