I imagine it is a matter of a sysex or some special (N)RPN setting to trigger playback. The IO and LCD pins on TC6116AF are still operational and maybe the firmware still listens to some of them.

Bulk of the firmware is inside the CPU's internal ROM too, has it been figured out how to get access to it ?

Tiido wrote on 2023-12-03, 14:46:

I imagine it is a matter of a sysex or some special (N)RPN setting to trigger playback. The IO and LCD pins on TC6116AF are still operational and maybe the firmware still listens to some of them.

whatever it is, the 55st user-manual says nothing (at least I was not able to spot there anything about Demo Song). so, it seems to me it's intended as some kind of (secret, i.e. not publicly announced) testing mode during the manufacturing process.

Tiido wrote on 2023-12-03, 14:46:

Bulk of the firmware is inside the CPU's internal ROM too, has it been figured out how to get access to it ?

nope, but IMHO, it's not needed, the key to all algorithms are in SCVA DLL, because it uses real WaveROM and not like VSC 8-bit degraded samples:

Re: About Roland Virtual Sound Canvas 3

thus it has to process them in the same way as a real device. so, I am still waiting someone to show me in that DLL the assembler code that for example is doing "RIAA IIR filtering" (and doing it twice one after another), because that is what the community somehow took for a fact and what projects like 'emusc' are utilizing, even one of the latest updates was about that (supposedly 'improving it'):

https://github.com/skjelten/emusc/commit/0d3f … 213d7d589dee503

when at least I have 0 evidence such thing is correct and most likely the need of it comes from something else that is wrong - essentially, if it's not in SCVA DLL, then you can be sure it's not right. of course, I welcome everyone to prove me wrong and I will be even happy to be wrong, because it will mean - real progress and not some guesses bordering fantasies.

It is 100% certain there's 1 step of that "RIAA filter" (very close approximation of the same curve used on vinyl records) done on the output of the DAC of every SC55 flavor hardware, with the most probable intent of reducing the high amplitude low freq content in samples so that so that one can get away with narrower buses in the DSP sections of the hardware and reduce aliasing noise and quantisation noise of both DAC and the narrower signal path (and possibly improve dynamic range of the ADPCM compression used in the ROM samples). The double aspect seems to come from the fact that if you play a decompressed sample from the ROM with only applying the filter curve done after the DAC, the sample freq spectrum won't match the actual hardware output, it is still too bright and doesn't have the bass end. But when doing the curve at double level/twice it will match real hardware output. It isn't something I have personally tested, I don't have decompressed samples at hand to do any verification but you can easily simulate the filter after the DAC in LTspice etc. and see it follows nearly exactly the RIAA curve (within passive electronic part tolerances) and this same filter curve is done by filter after the DAC in every SC55 flavor hardware. Even Yamaha hardware does a similar LF boost and HF cut in the analog stages right after DAC outputs but not to the extent seen in SC55 hardware.

It is quite likely there is a digital filter step baked into the effect processing step and not something separate, since every digital delayline also doubles as a digital filter (and if its is IIR or FIR depends on if the final output goes back into the delay line) and freq response depends on the coeffs used on every tap into that delay line, and you can easily combine various things into those coeffs. I'm not yet sure how far the research is with reverse engineering the silicon of the main chip in SC55mk1 is (I provided a slightly damaged chip for decapping not so long ago) but I am certain the answers will be found in the section that handles the coeffs used in the delay line part of the chip (that is what the 32KB PSRAM is for that is attached to it). If you want to explore, here's the silicon : https://siliconpr0n.org/map/roland/r15239148/ … ter_mz_mit20x2/

That SCVA DLL likely combines all of it in the place where it does the reverb and other effect processing, since it is computationally more efficient to do it that way instead of adding yet another dedicated block. Unlike hardware, it is easy to add more bits of precision to the calculations or even use floating point formats instead, the tradeoffs, if needed, are quite different from hardware.

Tiido wrote on 2023-12-03, 19:04:

That SCVA DLL likely combines all of it in the place where it does the reverb and other effect processing

thank you for all the information! I really appreciate it. I think it has to be much easiest demonstrating what calculations are done pointing out at portions of SCVA DLL assembler code than understanding that from pictures of the die of de-capped chip. after all SCVA DLL with using the same WaveROM then it needs to unpack those samples in memory in the same way - otherwise they will not sound right. in any way, IMHO, anything that SC55 emulator does - needs to be supported either by the die of de-capped chip or code in SCVA DLL.

On software end, this stuff is likely in the place where you see bunch of MMX, SSE or other SIMD instructions, since these instructions exist very much for these sort of tasks. The core operation is multiplication (with the magic coefficients) + accumulation (mixing into the output).

Surely SCVA isn't a SC-55 though? It just has a SC-55 mode but it's actually based on the SC-8820? So it would not necessarily code-wise faithful to the hardware.

Additionally, I don't own it, and there doesn't appear to be service manuals online to confirm this, but Japanese sites claim the SC-55ST uses a different DAC from the mkII.

Spikey wrote on 2023-12-04, 06:53:

Surely SCVA isn't a SC-55 though? It just has a SC-55 mode but it's actually based on the SC-8820? So it would not necessarily code-wise faithful to the hardware.

all correct, but WaveROM format/encoding is the same, i.e. that is what we're discussing - what processing is done on the WaveROM data when they are unpacked/uncompressed from the WaveROM data and loaded into the RAM memory. VSC was useless for that, because it's not using WaveROM data from a real GS hardware, but SCVA is proven to be using real WaveROM data from a real GS device, i.e. their 'encoding', so-to-say, is the same and thus their processing.

Spikey wrote on 2023-12-04, 06:53:

Additionally, I don't own it, and there doesn't appear to be service manuals online to confirm this, but Japanese sites claim the SC-55ST uses a different DAC from the mkII.

maybe so, but again - irrelevant, because we're interested in the digital domain, i.e. before the data even reach the DAC.

DAC itself can be different, but the analog filter after it has still the same curve. I have a SC55ST around, I don't recall it using a different DAC but it has been a while since I looked inside.

Tiido wrote on 2023-12-04, 07:31:

I have a SC55ST around, I don't recall it using a different DAC but it has been a while since I looked inside.

give me a second to go to the next room and look at the 55ST main-board and I will update this post with the exact DAC inside 55ST.

[EDIT] correct, it's different DAC than SC-55MKII, because SC-55MKII Service Manual states the DAC is "PD63200GS-E2" in 55mkII - I cannot ID such chip in 55ST, but I cannot ID any chip that is DAC in 55ST - that's strange?!

[EDIT2] I really cannot ID which chip on the 55st main-board is the DAC - unbelievable and now I am even staring at a picture of SC-55MKII main-board. So, that whole section is different.

[EDIT3] the DAC in 55ST is very small and tiny chip marked as "6379" - it's SOP8 package looks exactly like OpAmp - that's why it was so hard to spot it and ID it - I was thinking it's just an OpAmp in the amplification section, now after some Google search for that chip "6379" marking - that is "NEC uPD6379" DAC.

[EDIT4] so, that same "NEC uPD6379" is used in SC-55. in other words, if we need to describe SC-55ST better, it's SC-55mkII without display and with SC-55 DAC/analog section.

So, SC55ST has a µPD6379 DAC (SC55mk1 uses it too), which is same family as µPD63200 in SC55mk1, but the difference is 6379 is 16bit while 63200 is 18bit. But they have otherwise same output characteristics and are interchangeable f input format is taken into account (63200 also has 16bit mode while 6379 cannot accept 18bit input).

Tiido wrote on 2023-12-04, 08:22:

are interchangeable

in theory as characteristics maybe interchangeable, but in practice - not really, because 63200 is big 16-pin chip - you can spot it immediately, I recently repaired one "Yamaha MU-80" unit - it's using that same 63200 DAC and I know well how it looks like, while that "6379"DAC is real small and tiny 8-pin chip - what I thought it will be seconds and one look at the 55st main-board, took me many minutes and magnifying glass looking at the board to spot and ID it. so, at least visually, the difference between those two DACs is night and day.

[EDIT] BTW, when it comes to SC-55, my current favorite are those "RLP-3037" and "RLP-3170" boards:

How Roland CM-300 works: no Control ROM and no SoundBank ROM?

because they are self-contained units (when it comes to the digital synth part). I already IDed all their pins: basically they have Power (Vcc and GND), MIDI IN/OUT (TX, RX pin) and I2S interface and you can took them and hook them to any DAC you want or to S/PDIF using that I2S interface.

There are several chips in that DAC family, the 8pin ones are lowest cost versions without proper external VREF bypass capability so they have a bit inferior THD and noise performance, but the DAC architecture is still same internally. They're non-oversampling resistor string types that take either RJ16 or RJ18 format (but not I2S or LJ formats). This makes them low noise and very tolerant of various input formats, but they do have higher THD than modern oversampling sigma-delta DACs.

I'm intimately familiar with these modules on hardware level, due to having to deal with them as part of one project. The digital output is "dirty" for lack of better word, the Roland chips have an average sample rate output because one sample lasts different amount of clocks than the next sample, with roughly 65kHz average rate. This makes the chip output incompatible with many DACs etc. out there but for a logic analyzer etc. it will not be a problem to decode. Many non-oversampling DACs will work but modern oversampling ones will not, nor will any of the SPDIF transmitter chips since they require samples to last equal amount of time and take fixed amount of clocks in relation to their "master clock" signal, usually a power of two factor, which also is missing on the Roland chips and also stuff like Gravis GF1 and earlier Yamaha chips (although later chips embraced 44100Hz with standard CD timings so they have modern stuff compatibility without any conversions etc.).

Tiido wrote on 2023-12-04, 09:41:

for a logic analyzer etc. it will not be a problem to decode

thanks for the info and it's good to know that, because my main reason to look at digital output options for SC-55 was verification of future emulator, exactly with logic analyzer. for example, I've already hooked one of those cheap USB logic analyzers to I2S signals on my XR385 card, because MAME project believes their emulator of MU-50, if not at the moment, at some point, will pass such test for sure, i.e. output the exact same, as digital bytes, as the real hardware.

SCVA is proven to be using real WaveROM data from a real GS device, i.e. their 'encoding', so-to-say, is the same and thus their processing.

Right. I don't know much about this side of things, but if the WaveROM data is different, then couldn't the encoding and processing be different? I guess I'm confused how a SC-8820 is representative of a SC-55 in terms of ROM or anything else.

As for DAC's go, thanks guys for confirming it's a 6379! Some Japanese site claimed this but I wondered if it was correct.

As for sound, the SC-55mkII (63200) definitely sounds better than the 55 (6379), and the 63200 is also used in the JV-1080 (and JV-35/50 keyboard whch is a SC-50 keyboard). Most SC-55 variants use 6376 or 6379.
The one I'm curious about is the CM-300, which uses a PCM61, but that's another story.

Spikey wrote on 2023-12-05, 07:46:

but if the WaveROM data is different, then couldn't the encoding and processing be different?

you can think of it as ZIP archive, as far as it's ZIP compressed, always the uncompression/unpacking is done in the same way, even if the sounds (data) inside are not the same.

Spikey wrote on 2023-12-05, 07:46:

I guess I'm confused how a SC-8820 is representative of a SC-55 in terms of ROM or anything else.

it's representative of how the WaveROMs are packed/compressed, as the old thread I pointed out:

Re: About Roland Virtual Sound Canvas 3

shows all WaveROMs we inspected: SC-55 (and variants), SC-88 (and variants) and SC-8820 use the same packing format to store the data in the WaveROM. also, you can extract and compare sounds between those ROMs - if something doesn't look right between such comparisons you can account for potential differences. so, you can do it in fact-based way, not in guess-based way, as it was my initial point.

please, also note that SC-8820 has separate SC-88 WaveROM inside it! in fact if you look at SC-8820 Service Manual PDF, you will see it has insane amount of ROMs inside it (IC5, IC6, IC7, IC8, IC39) - those I guess are just ROMs from different older devices, between which SC-8820 is capable to switch as its current working mode, that in fact explains why:

Re: About Roland Virtual Sound Canvas 3

I also found several such ROMs in the SCVA DLLs, for example the aforementioned separate SC-88 ROM. I won't be surprised, if SC-8820 has even SC-55 ROM, it's just no one found its location - either in the DLLs or on its mainboard, because I doubt anyone knows, what those ROMs in IC5, IC6, IC7, IC8 and IC39 on the SC-8820 mainboard represent - at least I don't know, what I know is for sure one of those chips is the SC-88 ROM I found in the SCVA DLLs.

Spikey wrote on 2023-12-05, 07:46:

The one I'm curious about is the CM-300, which uses a PCM61, but that's another story.

I think in general Burr-Brown, i.e. PCM61 are much more reputable DAC maker than NEC (6379 and 63200), but that doesn't mean PCM61 sounds better, I don't know, which sounds better and personally I don't even care, because as I mentioned to me, IMHO, the biggest advantage of CM-300 is those "RLP-3037" (early CM-300 units, circa 1991 ) and "RLP-3170"(later CM-300 units, circa 1992) boards inside it, because they are self-contained Synth modules with MIDI In/Out and I2S Digital Audio Out, i.e. you can hook them easily to logic analyzer as discussed earlier here and make digital captures - then that capture you can play on any DAC you like. So, really "RLP-3037" and "RLP-3170" inside CM-300 have no substitution in such functionality. other modular board like for example SCB-55 has no digital, but analog output , plus it's not even SC-55, but SC-55mkII based.

mattw wrote on 2023-12-03, 15:22:

is doing "RIAA IIR filtering" (and doing it twice one after another), because that is what the community somehow took for a fact and what projects like 'emusc' are utilizing....
...when at least I have 0 evidence such thing is correct...

I want to update this thread, because after I don't know for how many years now, during which I was raising the "RIAA IIR filtering" question occasionally in many different forum posts here, it's finally solved:

https://github.com/skjelten/emusc/issues/39

and indeed, as I was suspecting all that time, it was wrong.

I am very glad that now progress is made on two different fronts: "Nuked-SC55" and "emusc".

and best of all, those 2 projects do not exclude each other, because even "Nuked-SC55" is going to be highly accurate (if not even exact, i.e. bit-perfect) it depends on firmware dumps that are very hard to be obtained (and currently made only for SC-55mkII), while "emusc" uses ROM dumps that are very easy to be obtained.

🤣, so part of it is actual result of the sample decompression process, interesting.

I am fond of the Nuked-x projects, silicon based reverse engineering has the protential for completely accurate behaviour although (not necessarily computationally efficient but that won't matter if it goes into a PLD anyway in the end).

Tiido wrote on 2024-03-18, 02:22:

I am fond of the Nuked-x projects, silicon based reverse engineering has the protential for completely accurate behaviour although

I believe we all are - it's simply incredible and fascinating work by @nukeykt ! I hope he gets his hands on few more SC-55 units, because the MCU firmware dump only he can make:

https://twitter.com/nukeykt/status/1752965047179981212

and currently only SC-55mkII is actually dumped in such a way. As I mentioned in the other thread I have SC-55mkI (with ROM version 2.00, which ROM version AFAIK no dump is available online), but i guess it will be mostly useless the type of dump I can make of that unit, i.e. dump only the ROM chips.