VOGONS


About Roland Virtual Sound Canvas 3

Topic actions

Reply 121 of 321, by mattw

User metadata
Rank Member
Rank
Member

I am not sure to what extent such idea could work for SC55 Waverom, but I did "byte occurrence statistics" for both SC55 Waverom and decrypted VSC bank:

SC55 Waverom:

#occurrences  byte
25542 251
26618 4
32228 255
50220 0

VSC bank:

#occurrences  byte
21942 254
22006 1
27340 255
36324 0

So, based on the above statistics it looks like that bit-0 and bit-2 are swapped, that way 1 becomes 4 and vice-versa 4 becomes 1. It's hard to make any conclusion for the other bits, but bit-0 and bit-2 swap just stands out, if such statistical analysis is applied.

[EDIT] maybe, as next step is to swap bit-o and bit-2 and rerun the statistical analysis and see if some other bit swaps will stand out - maybe that's feasible idea...

Reply 122 of 321, by appiah4

User metadata
Rank l33t++
Rank
l33t++

I guess this means somone should get off their asses and make 100% authentic SC-55 SF2 and DLS sound fonts?

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 123 of 321, by mattw

User metadata
Rank Member
Rank
Member
appiah4 wrote on 2020-10-22, 13:47:

I guess this means somone should get off their asses and make 100% authentic SC-55 SF2 and DLS sound fonts?

It depends what you understand by "authentic SC-55", because there are 2 devices actually: the original SC-55 and SC-55MKII with not only significant differences in the Soundbank between the 2, but they use 2 different processors, which makes their ROM firmware code absolutely different in terms of assembler and its structure and thus different from reverse-engineering point of view.

So, for me it's very debatable, which is the "authentic SC-55" - I am not an expert on the subject and I have no idea if most games were designed for SC-55 or for SC-55MKII. In any way, there are no any ROM dumps of SC-55MKII available, but there are ROM dump of SC-55, including its Waverom, which unfortunately is heavily scrambled and its scrambling algorithm is still unknown.

Currently, after my success yesterday:

Re: About Roland Virtual Sound Canvas 3

we can decrypt and extract the sounds from any VSC Soundbank - they are still high quality sounds (12-bit contrary for example to 8-bit sounds Roland licenses to 3rd parties), but (supposedly) not as high-quality as the sounds inside Hardware SC-55 Waverom. So, currently you can make SF2 and DLS based on any VSC soundbank - I guess it's still much better than what is available as SF2 and DLS regarding SC-55 at the moment.

Also, it's very long forum thread and so let me try to summarize other important points:

* there are 3 major versions of "Virtual Sound Canvas" software synthesizer for Windows (and Mac): VSC-55 (or 1.x), VSC-88 (or 2.x) and VSC 3.x
* while all of them emulate SC-55 (and later versions SC-88 and SC-88Pro as well), they don't emulate the same SC-55 version: VSC 1.x/2.x are emulating the original SC-55, while VSC 3.x is emulating SC-55MKII, as I mentioned here:

Re: About Roland Virtual Sound Canvas 3

* which SC-55 is emulated entirely depends on the Soundbank in use
* VSC 1.x /2.x/3.x soundbanks are not interchangeable for only one reason - they are encrypted with different keys and their header looks a little bit different.
* now with all the encryption algorithms figured out, I guess it would be trivial to make tool that converts for example VSC 1.x Soundbank to VSC 3.x Soundbank and vice-verse that way allows to use either SC-55 or SC-55MKII bank in either WinXP or Win9x. Until now Win9x was limited to SC-55 emulation, while WinXP limited to SC-55MKII emulation. So, that's another currently possible application.

The best would be SC-55 Waverom scrambling be figured out and then VSC soundbank be created based on those sounds. That's where now I shifted my attention, but one main problem is that it's not clear where descrambling is done in IC30 or in IC23 - there are no dumps of IC30, which is another potential huge obstacle.

Reply 124 of 321, by yawetaG

User metadata
Rank Oldbie
Rank
Oldbie
mattw wrote on 2020-10-22, 14:22:
appiah4 wrote on 2020-10-22, 13:47:

I guess this means somone should get off their asses and make 100% authentic SC-55 SF2 and DLS sound fonts?

It depends what you understand by "authentic SC-55", because there are 2 devices actually: the original SC-55 and SC-55MKII with not only significant differences in the Soundbank between the 2, but they use 2 different processors, which makes their ROM firmware code absolutely different in terms of assembler and its structure and thus different from reverse-engineering point of view.

So, for me it's very debatable, which is the "authentic SC-55" - I am not an expert on the subject and I have no idea if most games were designed for SC-55 or for SC-55MKII. In any way, there are no any ROM dumps of SC-55MKII available, but there are ROM dump of SC-55, including its Waverom, which unfortunately is heavily scrambled and its scrambling algorithm is still unknown.

I think it depends on whether appiah4 means 100% authentic soundbank or 100% authentic SC-55 listening experience. The first probably is possible, the second likely isn't, because the sound of a synthesizer depends on more than its ROM contents:
- Available parameters. Not all sound cards/modules offer the full GM set of parameters.
- Implementation of those parameters in the firmware. Not all General MIDI synths are equal here; some merely translate the General MIDI instructions into their own native MIDI implementation, which may include extensions that are not actually compatible with General MIDI (i.e. there often is another way of accessing it that offers more options). Furthermore, the actual synthesis engine may use a specific type of synthesis. Roland Sound Canvasses are rather standard there, but some other manufacturers are not (e.g. Kawai's more high-end GM modules are basically GM-ified additive synthesizers).
- Hardware components, like the quality of the output stages, included effect processors (some modules have a distinct chip for the effects, which usually results in better quality), filter, etc.

Probably, as long as only the stock sounds are used, it's possible to get pretty close, but emulating the more specific behaviour that appears when you push certain parameters to unusual values will be more complex and likely impossible outside of an actual softsynth.

As an aside, is the filter on the VSC actually resonant, like on the real thing? I.e. is it possible to get fairly earsplitting sounds by pushing up the resonance parameter and then opening up the filter?
(I write "fairly" because on the real hardware it's quite pronounced, but not as strong as on Roland's more professional other romplers...JV-80 is much stronger, and D70 might actually an accurate representation of the sound of hell... 😜 )

Reply 125 of 321, by appiah4

User metadata
Rank l33t++
Rank
l33t++

What I meant is a soundfont that more or less mimics the VSC sound, which is close enough to an authentic SC-55 as I care to get. I'm sure that is doable with all the PCMs becoming available. If I knew how I would do an SF2 and a DLS for this. Unfortunately, I do not..

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 126 of 321, by kitrinx

User metadata
Rank Newbie
Rank
Newbie

I have been working on picking apart the decoded control rom and wave data a bit. It's pretty easy to extract a set of samples from the newly decoded VSC dat, but a bit more info is needed on the 92 bytes of "part" data in the instruments. The table for breakpoints and sample indexes is strait forward, and this is what I have gotten out of the sample table:

??   Address          Size    Loop    Bk   Key  ??      ??
54 07 B9 03 34 35 41 5C 07 8F 00 28 03 D9 03 F1
52 00 F3 20 4D 3E 6A AE 14 4C 00 2A 04 26 03 F1
4B 05 C2 21 44 AE 4F 2A 0A 3B 00 2D 04 00 04 09

The bank field in VSC only seems to be 2 once in a while , I am not sure if it is vestigial or has any meaning in that context. In VSC the address is simply an offset, in SC55 control rom it seems to have two extra bytes for a total of 40 bytes, perhaps related to the byte scrambling (the address bus is 20 bits). Loop field is where the sample loops to sustain the note, and it is an offset from the *end* of the file, so size - loop = point where you repeat at. Key is just the root key for the sample. I don't know what the last two fields are, but maybe sample rate related? It's important to note that in the SC-55 control rom, all muti-byte values are big-endian, while in the VCS data they are little endian. This is helpful for determining the boundaries for fields.

I haven't had much luck figuring out the values in the part data at all. I am sure they contain some mix of attack, decay, etc, but it's difficult to find a pattern to identify what they are. If anyone has any thoughts it would be helpful.

I noticed that unfortunately, on VSC in some instruments the second part was disabled, like in Honkey tonk for instance. In SC-55 it uses two parts, but in VSC it only uses one part, and the second part has been changed to 0xFFFF.

Attachments

  • Filename
    tree.txt
    File size
    173.68 KiB
    Downloads
    20 downloads
    File license
    Public domain

Reply 127 of 321, by bnz99

User metadata
Rank Newbie
Rank
Newbie

Just wanted to check in after some break. Great work!
I'm currently messing around with the JV cards. I have a programmer for them and am thus able to dump, alter and load my altered dumps back into a JV device. Those cards seem to have some structural similarities to the SC-55 wave rom. I have found a few things that are possibly interesting about the way they shuffle things around, but again it may not be similar at all and from what I have gathered, it's really not as simple as the mt-32 scrambling with its 8-bit bit-wise transposition. Let me know if you are interested in some preliminary things I found out.

Reply 128 of 321, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

kitrinx and I made some substantial progress on the SC-55 wave ROM front. We have successfully understood the process of address scrambling.

kitrinx connected a logic analyzer to log the address fetch patterns when playing a single piano note. It looked like this (identation mine):

60455
70B20
70B24
70B24
60455
70B20
70B24
70B22
60455
70B20
70B24
70B22
60455
70B24
70B22
70B26
60455
70B22
70B26
70B28
60455
70B22
70B26
70B28
60455
70B26
70B28
70B2C
60455
70B28
70B2C
70B2A
60455
70B28
70B2C
70B2A
60455
70B2C
70B2A
70B2E
60455
70B2A
70B2E
70B30
60455
70B2E
70B30
70B34
60455
70B2E
70B30
70B34
60455
70B30
70B34
70B32
60455
70B34
70B32
70B36
Show last 61 lines
60455
70B34
70B32
70B36
60455
70B32
70B36
70B38
60455
70B36
70B38
70B3C
60455
70B36
70B38
70B3C
60455
70B38
70B3C
70B3A
60455
70B3C
70B3A
70B3E
60455
70B3A
70B3E
70B21
60455
70B3A
70B3E
70B21
60455
70B3E
70B21
70B25
60453
70B21
70B25
70B23
60453
70B21
70B25
70B23
60453
70B25
70B23
70B27
60453
70B23
70B27
70B29
60453
70B27
70B29
70B2D
60453
70B27
70B29
70B2D

As you can see, even though only a single instrument is playing, there are two fetch sequences interleaved by a factor of 1:3. The first sequence fetches from the same address at least 32 times before changing, while the second sequence changes between each fetch, with the first two fetches of each triplet being the last two fetches of the previous triplet, and the last fetch being an entirely new address. Some of the time, a triplet will be identical to the previous triplet.

I proceeded to observe each fetch sequence separately. I assume that the triplet-like pattern of the second sequence is the result of a three-point interpolator, and discard repeated fetches from a previously-seen address to observe how the fetch address changes on each new fetch. I further assumed, separately for each of the two fetch sequences, that after removing repeated fetches from previously seen addresses due to interpolation and looping, the device would linearly go from the start to the end of the waveform, byte after byte in terms of the unscrambled address, and that by observing the change pattern of the scrambled address bits, I could deduce the scrambling pattern of the fetch address. That turned out to be the case! By reordering the address bits, I observed an entirely linear monotic fetch sequence from the unscrambled address that started at exactly the address denoted in the control ROM for the particular sample, and lasted for exactly the number of bytes indicated in the length field of the control ROM.

For example, the second piano sample, described in the control ROM at address $1DED0 with the bytes 52 00 F3 20 4D 3E 6A AE, begins fetching in wave ROM at (unscrambled) address $0F320 for 27310 (decimal) or $6AAE, fetches (first: scrambled address, second: unscrambled address):

70B20->0F320
70B24->0F321
70B21->0F322
70B25->0F323
70B28->0F324
70B2C->0F325
70B29->0F326
70B2D->0F327
70B30->0F328
70B34->0F329
70B31->0F32A
70B35->0F32B
70B38->0F32C
70B3C->0F32D
70B39->0F32E
(...)
4BD58->15DCC
4BD5C->15DCD
4BD59->15DCE

Bits D5-D6 of the address MSB in the control ROM selects the wave ROM number, so 0x xx xx selects the wave ROM A, 2x xx xx wave ROM B, and 4x xx xx wave ROM C.

This only explains the second fetch sequence, the one fetched in triplets. The first fetch sequence is always from an address that is not directly denoted in the control ROM. After descrambling that address using the same pattern as the second fetch sequence, I noticed that the address of the first sequence is always the address of the second sequence shifted to the right by five bits. As a result, the same byte fetched in the first sequence is somehow combined by the device together with 32 non-repeated bytes of the second sequence. I suspect that this is somehow related to a waveform compression algorithm, in which the first sequence fetches some kind of "lead" byte that is used for exactly 32 non-repeated bytes of the second sequence. This means that for 1 MiB of wave ROM, there would need to be 1 MiB/32=32768 bytes of "lead" bytes. And indeed, if you sort the address field in the "samples" sheet of the Excel spreadsheet that Cloudschatze posted, the first sample in each wave ROM begins at address $08000! After descrambling the addresses of the three wave ROMs, the structure became apparent: the first 0x00400 bytes (0x10000 >>5 >>5) contain no meaningful data at all, then $08000-0x00400 bytes of lead bytes for the remaining $F8000 sample bytes.

Attached please find a small C++ program that writes an address-descrambled version of each of the three SC-55 wave ROMs. The C++ program source also will tell you the address scrambling pattern. Playing the address-descrambled wave ROMs in Audacity still sounds mostly like noise, but unlike before, I can faintly make out something that seems to resemble instrument sounds. Full logic analyzer logs available upon request.

Of course, this was only the easy part, because the data bytes will likely be scrambled as well, and then they will still need to be decompressed. I speculate that the "lead" byte is some kind of multiplicator for each for 32 sample bytes. But that will be for another day. 😀

Attachments

Reply 129 of 321, by yawetaG

User metadata
Rank Oldbie
Rank
Oldbie
bnz99 wrote on 2020-10-26, 22:12:

Just wanted to check in after some break. Great work!
I'm currently messing around with the JV cards. I have a programmer for them and am thus able to dump, alter and load my altered dumps back into a JV device.

You are aware of these projects?

https://www.gearslutz.com/board/electronic-mu … rd-waverex.html
https://www.yamahamusicians.com/forum/viewtop … hp?f=16&t=16319

I mean, there's no reason to go the whole ten miles if someone already did some of the job...

And this thread probably also is interesting to you: https://www.gearslutz.com/board/electronic-mu … d-jd-990-a.html

Those cards seem to have some structural similarities to the SC-55 wave rom. I have found a few things that are possibly interesting about the way they shuffle things around, but again it may not be similar at all and from what I have gathered, it's really not as simple as the mt-32 scrambling with its 8-bit bit-wise transposition. Let me know if you are interested in some preliminary things I found out.

Any structural similarities are not too surprising, since later SC modules also share a lot of their hardware architecture with the JV-series. They probably were designed by the same people.
In the case of the JV35/50/90/1000 and a few other related keyboards, there exist expansion boards that basically add a whole new synthesizer engine + sound ROM. The CPU and most other chips are shared between the integrated synth engine/sound ROM and the expansion board. I would expect that such an ability put some constraints on the ROM structure (especially in the early 1990s).

Reply 130 of 321, by bnz99

User metadata
Rank Newbie
Rank
Newbie

yaweta, thanks for the pointer, but yes, I'm aware of all this already, the second link is the programmer I'm playing with. Actually, I'm much more interested in the reversing process than the actual result. If I was, I could probably just buy an XV5080 which comes with sample playback.

But to be honest, the latest post by NewRisingSun is probably a much more effective and efficient way to approach the descrambling than the way I have tried it as the whole roundtrip change->program card->try in synth takes something like 5-10 minutes. Given that most of the times, I try to isolate specific area of the dump from hunches, it is an insane amount of work. Although I am actually able to change patch names in specific sections. I have tried the sc-55 address descrambler code to decode a JV dump, but I think it's not the same for the JV cards despite the similarities. But I still have to check that in more detail.

Reply 131 of 321, by kitrinx

User metadata
Rank Newbie
Rank
Newbie

One thing that would be helpful is if anyone has information about the format of the 92 byte "part" segments in each instrument. Each instrument has two parts and a short header. They don't appear to be obfuscated in any way and correspond (in some way) to the parameters listed at the end of the SC-55 owners manual. Having that mapped out is probably a much easier task and quite valuable for any kind of programmatic conversion.

Additionally the first byte of each 16 byte "sample" entry and the last two 16-bit words have unknown uses too. The first byte might be volume or speed. Last two words I have no idea.

FWIW, the "variation" tables are also present in the control rom at 0x30000 in the 1.21 control rom. They are each a series of 128 16-bit big-endian values that correspond to the instrument table, and there are 128 of them total. Each table is a variation, each element is an instrument, and they correspond to the midi standard instrument numbers/table in the back of the sc-55 mk1 owners manual.

Reply 132 of 321, by Alex-aut

User metadata
Rank Newbie
Rank
Newbie
bnz99 wrote on 2020-10-06, 19:17:

Usually, each sample comes along with a root key and a range around that root key for which the sample is mapped to specific notes. The list of samples then make up the complete keyboard mapping. The range can be expressed in different ways, like lower and upper key or really a range around a note (left and right). Multi-samples are typically used for more natural sounding instruments rather than synthetic ones as they tend to sound strange and artificial when they are played too far away from their root key.

If the chunks are the the same instrument at different pitches, for example spaced at different octaves, you'll need all of them as well as the metadata that maps those ten samples to the keyboard in order to do something useful with them.

Yes, notes between root-keys are (linear) interpolated, where interpolating-point is a multiplier from twelfted root of desiered tone

Last edited by Stiletto on 2020-11-26, 08:02. Edited 1 time in total.

Reply 133 of 321, by Alex-aut

User metadata
Rank Newbie
Rank
Newbie
mattw wrote on 2020-10-08, 13:06:
I really don't know with VSC the "pcm data address map" is so obvious: […]
Show full quote

I really don't know with VSC the "pcm data address map" is so obvious:

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
-------------------------------------------------------------------------------
0x78 0x00 0x00 0x00 0x00 0x00 0x67 0x35 0x92 0x06 0x00 0x24 0xDC 0x03 0x00 0x04
0x7B 0x7A 0x35 0x00 0x00 0x00 0x2E 0x33 0xE0 0x08 0x00 0x29 0xFA 0x03 0x00 0x04
0x78 0xBB 0x68 0x00 0x00 0x00 0x9F 0x2B 0x3E 0x07 0x00 0x30 0x00 0x04 0x00 0x04
.....
0x7F 0x5F 0x0D 0x12 0x00 0x00 0x0F 0x1C 0x00 0x1C 0x00 0x50 0x3D 0x04 0x00 0x04
0x7F 0x81 0x29 0x12 0x00 0x00 0xEC 0x05 0xE1 0x05 0x00 0x42 0x4B 0x05 0x00 0x04

that the addressing is:

(offset_07 << 0x08) | offset_06 + 0x13 +  {(offset_03 << 16) | (offset_02 << 0x08) | offset_01} = next_index{ (offset_03 << 16) | (offset_02 << 0x08) | offset_01 }

and with SC55ROM, nothing stands up:

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
-------------------------------------------------------------------------------
0x54 0x07 0xB9 0x03 0x34 0x35 0x41 0x5C 0x07 0x8F 0x00 0x28 0x03 0xD9 0x03 0xF1
0x52 0x00 0xF3 0x20 0x4D 0x3E 0x6A 0xAE 0x14 0x4C 0x00 0x2A 0x04 0x26 0x03 0xF1
0x4B 0x05 0xC2 0x21 0x44 0xAE 0x4F 0x2A 0x0A 0x3B 0x00 0x2D 0x04 0x00 0x04 0x09
.....
0x7F 0x2B 0x93 0x20 0x08 0xD0 0x09 0x46 0x00 0x5E 0x00 0x40 0x02 0x0A 0x04 0x7D
0x7F 0x2D 0xFC 0xC0 0x04 0x5C 0x05 0x74 0x00 0x2C 0x00 0x4D 0x02 0x66 0x04 0x61

So, without first we figure our how the PCM data are addressed in SC55ROM, it will be kind of impossible to figure out how they are encoded in SC55ROM Waverom.

Unfortunatly you are right. If we take a look on schematic, every IC (IC26/7/8) has his own CE (chip enabled line). The waveform roms are 8 bit. So even if SC55 uses 12 bit of sample, the additional 4 bits (to 12 bits) doesn't come from the same rom chip. With focus on performance issues, it could be possible, that at every sample 2 CE-lines are enabled. To save time in such an old embedded system, the additional 4 bits should be in a different rom at the same adress as the 8 bits from a given sample, because changing adress lines costs a few micro seconds.

Reply 134 of 321, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

The SC-55 wave ROM uses 8.25 bits per sample: 8 bits of mantissa for every sample, plus 4 bits of base 2 exponent (i.e. left-shift count) for every 16 samples. The encountered maximum shift count is ten, making the decompressed wave ROM samples 18 bits wide, even in the original SC-55. Mantissa and exponent are in the same ROM chip.

Reply 135 of 321, by Alex-aut

User metadata
Rank Newbie
Rank
Newbie
NewRisingSun wrote on 2020-10-28, 19:31:
kitrinx and I made some substantial progress on the SC-55 wave ROM front. We have successfully understood the process of address […]
Show full quote

kitrinx and I made some substantial progress on the SC-55 wave ROM front. We have successfully understood the process of address scrambling.

kitrinx connected a logic analyzer to log the address fetch patterns when playing a single piano note. It looked like this (identation mine):

60455
70B20
70B24
70B24
60455
70B20
70B24
70B22
60455
70B20
70B24
70B22
60455
70B24
70B22
70B26
60455
70B22
70B26
70B28
60455
70B22
70B26
70B28
60455
70B26
70B28
70B2C
60455
70B28
70B2C
70B2A
60455
70B28
70B2C
70B2A
60455
70B2C
70B2A
70B2E
60455
70B2A
70B2E
70B30
60455
70B2E
70B30
70B34
60455
70B2E
70B30
70B34
60455
70B30
70B34
70B32
60455
70B34
70B32
70B36
Show last 61 lines
60455
70B34
70B32
70B36
60455
70B32
70B36
70B38
60455
70B36
70B38
70B3C
60455
70B36
70B38
70B3C
60455
70B38
70B3C
70B3A
60455
70B3C
70B3A
70B3E
60455
70B3A
70B3E
70B21
60455
70B3A
70B3E
70B21
60455
70B3E
70B21
70B25
60453
70B21
70B25
70B23
60453
70B21
70B25
70B23
60453
70B25
70B23
70B27
60453
70B23
70B27
70B29
60453
70B27
70B29
70B2D
60453
70B27
70B29
70B2D

As you can see, even though only a single instrument is playing, there are two fetch sequences interleaved by a factor of 1:3. The first sequence fetches from the same address at least 32 times before changing, while the second sequence changes between each fetch, with the first two fetches of each triplet being the last two fetches of the previous triplet, and the last fetch being an entirely new address. Some of the time, a triplet will be identical to the previous triplet.

I proceeded to observe each fetch sequence separately. I assume that the triplet-like pattern of the second sequence is the result of a three-point interpolator, and discard repeated fetches from a previously-seen address to observe how the fetch address changes on each new fetch. I further assumed, separately for each of the two fetch sequences, that after removing repeated fetches from previously seen addresses due to interpolation and looping, the device would linearly go from the start to the end of the waveform, byte after byte in terms of the unscrambled address, and that by observing the change pattern of the scrambled address bits, I could deduce the scrambling pattern of the fetch address. That turned out to be the case! By reordering the address bits, I observed an entirely linear monotic fetch sequence from the unscrambled address that started at exactly the address denoted in the control ROM for the particular sample, and lasted for exactly the number of bytes indicated in the length field of the control ROM.

For example, the second piano sample, described in the control ROM at address $1DED0 with the bytes 52 00 F3 20 4D 3E 6A AE, begins fetching in wave ROM at (unscrambled) address $0F320 for 27310 (decimal) or $6AAE, fetches (first: scrambled address, second: unscrambled address):

70B20->0F320
70B24->0F321
70B21->0F322
70B25->0F323
70B28->0F324
70B2C->0F325
70B29->0F326
70B2D->0F327
70B30->0F328
70B34->0F329
70B31->0F32A
70B35->0F32B
70B38->0F32C
70B3C->0F32D
70B39->0F32E
(...)
4BD58->15DCC
4BD5C->15DCD
4BD59->15DCE

Bits D5-D6 of the address MSB in the control ROM selects the wave ROM number, so 0x xx xx selects the wave ROM A, 2x xx xx wave ROM B, and 4x xx xx wave ROM C.

This only explains the second fetch sequence, the one fetched in triplets. The first fetch sequence is always from an address that is not directly denoted in the control ROM. After descrambling that address using the same pattern as the second fetch sequence, I noticed that the address of the first sequence is always the address of the second sequence shifted to the right by five bits. As a result, the same byte fetched in the first sequence is somehow combined by the device together with 32 non-repeated bytes of the second sequence. I suspect that this is somehow related to a waveform compression algorithm, in which the first sequence fetches some kind of "lead" byte that is used for exactly 32 non-repeated bytes of the second sequence. This means that for 1 MiB of wave ROM, there would need to be 1 MiB/32=32768 bytes of "lead" bytes. And indeed, if you sort the address field in the "samples" sheet of the Excel spreadsheet that Cloudschatze posted, the first sample in each wave ROM begins at address $08000! After descrambling the addresses of the three wave ROMs, the structure became apparent: the first 0x00400 bytes (0x10000 >>5 >>5) contain no meaningful data at all, then $08000-0x00400 bytes of lead bytes for the remaining $F8000 sample bytes.

Attached please find a small C++ program that writes an address-descrambled version of each of the three SC-55 wave ROMs. The C++ program source also will tell you the address scrambling pattern. Playing the address-descrambled wave ROMs in Audacity still sounds mostly like noise, but unlike before, I can faintly make out something that seems to resemble instrument sounds. Full logic analyzer logs available upon request.

Of course, this was only the easy part, because the data bytes will likely be scrambled as well, and then they will still need to be decompressed. I speculate that the "lead" byte is some kind of multiplicator for each for 32 sample bytes. But that will be for another day. 😀

Hi NewRisingSun, very well done work, great!!! I would ask you for some help:
I verified the address in Control rom at $1DED0 as you measured in your post, and indeed the values at this address are 52 00 F3 20 4D 3E 6A AE. My question would be, from where did you jump to address $1DED0 ? From where did you know, that in your given example the parameter address of the second piano 1 sample is $1DED0? I would be thankful for this hint. Thank you so much for your great work.

Last edited by Stiletto on 2020-11-26, 08:03. Edited 1 time in total.

Reply 136 of 321, by Alex-aut

User metadata
Rank Newbie
Rank
Newbie
mattw wrote on 2020-09-22, 13:28:

Big news (at least to me, maybe it was done in the past, but I am not aware of it - if you know, let me know, to prevent me reinventing the wheel):

So, I was able to decrypt small portion of the Sound bank from ROM dump from real SC-55 hardware device! Yes, only "small portion" for the moment, because I still cannot figure out how the whole thing is encrypted, i.e. the bigger picture. It looks like small portions ("blocks") of the ROM are encrypted with different key and if that's true, then it will require many many keys to be calculated. In any way, at these point Hardware SC55 to Virtual SC55 looks like more than real possibility. Especially, if someone smarter than me gets involved! Probably, same applies for SC88 and SC88Pro - but I cannot find full ROM dumps of those devices (i.e. Sound bank included in the dump and not only the firmware itself).

[EDIT] or I am totally wrong and I just hit some lucky byte sequence, that looks like something decrypted...

Hi mattw, here are some files.

Attachments

  • Filename
    SC88CONT.zip
    File size
    164.58 KiB
    Downloads
    16 downloads
    File comment
    Control
    File license
    Fair use/fair dealing exception
  • Filename
    SC88327328.zip
    File size
    3.82 MiB
    Downloads
    18 downloads
    File comment
    W-Forms
    File license
    Fair use/fair dealing exception
  • Filename
    SC88IC325326.zip
    File size
    3.81 MiB
    Downloads
    15 downloads
    File comment
    W-Forms
    File license
    Fair use/fair dealing exception

Reply 137 of 321, by Alex-aut

User metadata
Rank Newbie
Rank
Newbie

Unfortunately NewRisingSun adress-decryption works perfectly on SC55 SF rom-chips but doesnt't work on SC88 soundfont. One of the the reason would be, if we take a look on both service-notes schematics (SC55 & SC88), that in schematic of SC88 the adress lines are mixed up per se. My SC88 is in thousand pieces, roms are soldered on self made pcb's for read-out, so logic analyzer adress-descrambling is not possible.
It would be nice, if NewRisingSun hase some ideas.

Attachments

  • SN_SC88.jpg
    Filename
    SN_SC88.jpg
    File size
    194.55 KiB
    Views
    448 views
    File license
    Fair use/fair dealing exception
  • SN_SC55.jpg
    Filename
    SN_SC55.jpg
    File size
    224.7 KiB
    Views
    448 views
    File license
    Fair use/fair dealing exception

Reply 138 of 321, by yawetaG

User metadata
Rank Oldbie
Rank
Oldbie

The SC88 also has other IC differences from the SC55, such as a different CPU (incidentally the same as used in the JV1080), so different addressing might not be too much of a surprise.

Reply 139 of 321, by mattw

User metadata
Rank Member
Rank
Member

Hi All, sorry, I was totally absent here, I got very sick with some bacterial infection, still not fully recovered, but a little better. Anyway, it's very nice to see other people have joined the effort - I need to go through all the new posts to get better understanding what others did. Also, I have myself to share some new (small) findings - if someone else didn't already shared the same in those new posts. In any way it's really great to see more people involved 😀