Chrisoft

GenAI Statement

No generative AI was used in any way, shape, or form during the composition of this post. See the Site-wide Generative AI Statement for details.

Preamble

Ah yes, the venerable EDIROL SD-90. The legendary (but weird) combo of a ROMpler and an audio interface in a box[1] used by the mastermind behind the Touhou Project.[2] Released more than two decades ago, surely there can’t be anything new to learn about this thing out in the wild, right?

Turns out, that is not the case. I’ve never found an electronic copy of the service manual for this machine online. I’ve had my SD-90 for nearly three years at that point (prior to that I was using my SD-80), but I have still yet to figure out how to boot into its test mode despite having systematically exhausted all possible three-button combinations. So when I saw a listing on ebay for a physical copy earlier this year, I knew I just have to get it.

As soon as the service manual arrived, I was shocked to find out that the correct button combination for booting into test mode is among the first few combinations I tried – I just didn’t wait until the boot animation finished playing because I simply didn’t have the patience for that: there are a lot of three-button combinations to try when you have 19 buttons!

But I didn’t stop there: I flipped through the entire 50 pages of the service manual, making comparisons against its little brother SD-80’s service manual throughout the way. In the process I found a lot of curiosities about the design of this machine that clearly indicates its transitional and experimental nature. And the purpose of this blog post is to share these curiosities (mostly design details of the PCB[3], as well as a few other interesting things) with the world.

And of course just a few months after me paying the ransom, a scanned version of the service manual popped up on archive.org. Sigh.[4] [5]

As usual, this article will be written in a way such that readers with little knowledge in electronics will hopefully not find themselves totally lost. However, please do keep in mind that the author of this article is not a professional either. Corrections are always welcome.

Firmware Revisions

My SD-90 seems to be a pretty early specimen. Its main board was manufactured on 2001-10-27, still fairly early into the product’s life cycle: some official documentation of the SD-90 was dated later than that, e.g. the MIDI Implementation version 1.02 was dated 2001-12-12, and the service manual was dated 2001-11. The MIDI Implementation document shipped in the driver CD of my SD-90 is however version 1.00, and dated 2001-10-11. Earliest snapshot of SD-90’s Japanese product information page on the Wayback Machine is dated 2001-10-31. Mine came to me with firmware version 1.02, which I assume is the version it was shipped with and the previous owner never bothered to apply the 1.03 update which is available on Roland’s website.[6]

However as other people started checking the firmware version of their SD-90, news of units on odd firmware versions started pouring in: A few people’s units are running version 1.05. One even has a unit that’s running 1.06. Unsurprisingly, these units were all manufactured later than mine. But I could find no information on these newer firmware versions online[7], and they apparently do not provide any new functionality. So I’d assume that these are factory firmware versions for later hardware revisions. And as you will see later, there are actual hardware differences between early and late units. So these newer firmware revisions might have been made to accommodate these hardware differences.

Since I updated the firmware of my SD-90 to 1.03 before I knew how to check the build information, I would never know when was version 1.02 built. However archived supported pages for the SD-90 on the Wayback Machine indicates that version 1.02 was made public on 2001-12-10. The same page has a reference to version 1.01 which I have never seen running on an actual unit. The service manual shows version 1.00 in what the version check would look like in test mode, however there is no way for me to tell whether that information is accurate or just a placeholder for demonstration purposes.

If you want to check the firmware version of your SD-90, you might want to try the following button combinations (hold these buttons while powering on the unit):

• inst/drum set + exit + preview
• mic/guitar + inst/drum set + system

All SD-90 firmware versions that I was able to personally confirm are listed below:

Ttl :---- [1655] 1.02
Prog:00FA [00FA] 1.02
Boot:AA1D [AA1D] 1.02
Updt:1284 [1284] 1.01

Ttl :---- [05A5] 1.03
Prog:1F50 [1F50] 1.03
Boot:AA1D [AA1D] 1.02
Updt:4B60 [4B60] 1.03

Ttl :---- [8488] 1.05
Prog:01D2 [01D2] 1.05
Boot:AA1D [AA1D] 1.02
Updt:4B60 [4B60] 1.03

Ttl :---- [11E9] 1.06
Prog:DAD7 [DAD7] 1.06
Boot:A9E6 [A9E6] 1.03
Updt:FAE5 [FAE5] 1.04

PCB Madness

Even before obtaining my copy of the service manual, I was already fairly familiar with the internals of the SD-90: I disassembled mine as soon as it arrived to photograph its internals, noticing striking similarities to the SD-80 in the power supply section, and later performed a partial recap to address its noisy synthesizer output. However, getting my hands on the full schematics and the parts list has definitely revealed a few very interesting things about this machine.

To buffer, or not to buffer

While we were trying to figure out the firmware versions, Palto noticed that there is a chip missing in a PCB photo of my SD-90 while the same position is populated on their board. This got me deeply hooked, because this confirms the existence of different hardware revisions.

Determined to figure out what is going on, I asked for more PCB photos from Palto. Here is a list of differences I spotted:

• IC30, IC31, IC32, IC33, IC34, IC35 and supporting components for these chips (mostly output resistors) are not populated on my board. These are populated on Palto’s board.
• RA41, RA42, RA44, RA46, RA47 are not populated on Palto’s board while these are populated on my board. RA41/IC30, RA44/IC31, RA42/IC32, RA46/IC35, RA47/IC34 have overlapping footprints on the PCB so they cannot be populated at the same time. These are all 0 Ohm resistor arrays (0 Ohm links).

All but one of the chips mentioned above are bus transceiver chips (74LV245). The exception is IC33, which is four 2-input AND gates in a single package (74LV08).

As a bus transceiver, the 245 connects 8 pairs of inputs and outpus together. It allows the signals to flow in a set direction, which can be flipped on demand with the DIR pin. More specifically, it has two “ports” A and B, each with 8 pins A1-A8 and B1-B8. Depending on the setting on the DIR pin, signals are allowed to travel from port A to its corresponding pin on port B or vice versa. It can also “disconnect” the ports altogether. This is controlled by the pin marked /OE. When /OE is set to high, signals are neither allowed to travel from port A to port B, nor from port B to port A regardless of the setting on the DIR pin. This effectively disconnects the ports.

Beside being used as a bus transceiver, some variants of the 245 chip is also often used as a logic level shifter, especially in older electronics that has mixed logic levels[8]. Initially this sounds like a plausible reason why these 245 chips were put there: the XV chip is powered by both 3.3V and 5V, therefore it might have used mixed logical levels; and in the schematics the ports connected to these 245 chips are named WA/3WA (for the wave memory address bus) or WD/3WD (for the wave memory data bus), as if it’s converting between 3V logic and a certain other logical level. However, this is where the variant of the chip comes into play. The “LV” in its part number 74LV245 is the variant. In this case, the LV variant is not suitable for use as a level shifter. This is rendered even less possible by the fact that in earlier production units that lacked these 245 chips, signals that would pass through these 245 chips are connected directly through 0 Ohm links. If logical level shifting is in fact required, that would be a bad design and might even damage the XV and / or the wave memory chips.

Now here is the fun part: 3 of these 5 245 chips have their enable pins and direction pins tied to the ground as well! This means that they are always enabled, and fixed to a specific direction, which means they are connecting each output to its corresponding input all the time, as long as the chips are powered. These chips are all on the wave address bus, which means the two designs are not that different as far as the address bus of the wave bus is concerned[9].

The other two 245 chips are on the wave data bus and have their enable pins connected to the /WOE (likely stands for “wave output enable”) pins of the XV chips. This means that the XV chips in late revision SD-90 units would have the ability to disconnect the data output of the wave ROM chips from them. Why it would need to do that is something I couldn’t answer: the /WOE pins of the XV chips are also connected the the /OE pins of all the wave ROM chips as well, meaning the same signal already have direct control over the output right at the source. Their DIR pins are controlled by the XV chips’ /WWE signal, which means besides receiving data on the wave data bus from the ROM chips, the XV chips would also be able to send data to the wave data bus. This would only make sense if the flash memory (more details later) on the wave bus is used, as that would be the only occasion where the XV chips need to write to the wave bus.

IC33 implements glue logic for these two bus transceiver chips on the wave data bus, as well as the unused flash memory on the wave bus.

The SD-80 doesn’t have design variants when it comes to how the wave ROM chips are attached to the DSP (i.e. its PCB does not have unpopulated positions for alternative designs). It’s consistently using the design of later SD-90 hardware revisions.

Those are all the differences we’ve spotted between our production SD-90 units. Below are a few other interesting components marked “Not In Use” in the schematics, but they were never populated on any production boards that I’ve seen.

IC37 and IC45 are simple OR gates that would allow the SH3 CPU (in addition to the XV chips) to control whether the effect RAM chips’ output are enabled. These seem to be still missing from later units, and are completely absent in XV-5080 and SD-80’s board designs. In those models, only the XV chips control whether the outputs of its effect RAM chip are enabled.

IC38 is an AND gate that connects the WBACK and WBREQ pins of the XV chips together, but exposes one of its inputs as a test point with a pull-up resistor that’s also not installed. If this block is functional, the WBACK and WBREQ pins of the XV chips would be effectively disconnected when the test point is shorted to ground. This is possibly just a leftover for internal testing. In production units, which lack this chip on its board, a 0 Ohm link is installed to connect them directly. In XV-5080 and SD-80’s design, all this extra testing circuitry is completely absent and said pins are linked directly by circuit board traces.

IC19 and CN7 seem to be related to an additional encoder that’s removed in the final design. It was referred to as ENC0 in the design while the 3 encoders that are actually present on the SD-90 are referred to as ENC1 to ENC3.[10] This seem to suggest that the SD-90 was initially designed with a single value knob (like the SC-8850) instead of 3.

Q13 and Q14 (close to the LCD backlight power socket) are used for driving the LCD backlight with a PWM signal from the XV chip. This suggests the SD-90 is designed with adjustable backlight brightness (not just contrast, as available in production units), but was scrapped before it reached production.

Robbed memory

There are footprints (IC42, IC43) for two additional memory chips that are on the wave bus. These two chips are never populated in any of the SD-90 specimens that I’ve seen.

IC42 is just another 128 Mbit Mask ROM chip, very much like the two that are installed on all SD-90 units (IC40 and IC41). This position is not reserved as a simple substitute for either IC40 or IC41, as it has its own, distinct chip select line. Therefore its capacity would be added to the total wave ROM capacity were it installed. The only notable difference is that the part number designated for IC42 is 23C128000LGY, while IC40 and IC41 has the part number 23C128040LGY. The difference between these two parts is that 000LGY does not have the page access mode that 040LGY has.[11] I’ve never seen Roland using the version of this ROM chip that doesn’t have page access mode.

This chip does not have its “mask code”[12] printed in the service manual. This could mean the content of this chip was never finalized and passed on to the mask manufacturing process.

If IC42 was used alongside IC40 and IC41, the SD-90 would have 48 MB of compressed samples (96 MB uncompressed using Roland’s calculus). Roland never released a sample-based synth that came with 48 MB of compressed samples (that I’m aware of) – although they did release ones with 24 MB of compressed samples, which include the SC-8820 and its relatives. In later sound modules with bigger wave ROMs, they jumped straight to 64 MB of compressed samples.

Imagine what they could have done with 16 MB of additional space for samples. They could probably squeeze the entire RD-700 piano in there (equivalent to the piano found in SuperQuartet), alongside possibly not crippling a few sample sets (e.g. keeping all velocity layers of the XV acoustic guitar samples). Oh the missed opportunities!

The specific parts used for IC40 and IC41 had changed throughout the production too. In fact, there are at least 3 equivalent set of ROM chips used seemingly interchangeably through the entire lifespan of the Studio Canvas product line (The R-number is Roland’s internal part number):

… what a mess.

Keep in mind that a different mask code for chips in a slightly different series does not necessarily translate to different data stored. This can be back by the fact that the BLGY-version of the chips and ALGY-version have different mask codes, but identical Roland part numbers, which indicates that Roland saw them as exact equivalents and should therefore have identical data.

It’s plausible that the last line of the engraving on these ROM chips is a date code in the format of <last two digits of year><week> (which seems consistent with other lines of evidence). If that’s the case we can easily reconstruct a time of these parts: they started production using the LGY-version of the chip, switching to the ALGY-version and then the BLGY-version later. But they definitely grabbed whatever was available on their production lines at times too.

If that already sounds wacky, I have more in store for you: the story of IC43 might be way more interesting, because it’s a 32 Mbit (4 MiB) flash memory chip directly connected to the wave bus!

If this sounds crazy, it’s because it is: No other Roland sample-based synth from this era that I’ve seen has a flash memory chip directly hooked up to the main synthesizer DSP chips. All models with sample playback / sampling capability that I’m aware of must first load the samples into some form of RAM first. The flash chip they had chosen however, does seem fast enough to behave like all the other ROM chips on the wave bus. The write enable input of the flash memory chip is connected to the /WWE pin of the XV chips through some trivial logic, so this chip can definitely be written to, making it unlikely that it’s just a factory configuration vessel that is only written once when the product leaves the factory.[13] The same /WWE signal is also used to flip the direction of the transceiver chips on the wave data bus so that the XV chip can send data to the flash chip. In the XV-5080, the /WWE pin of the XV chips are connected to pin 47 (/WE) of the RAM socket, although the way it control the signal direction on its wave data bus is much more complicated. This /WWE pin is completely unused in all other Roland devices that use the XV chip that I’m aware of (XV-5050, SD-80, FA-76 and MV-8x00), with the notable exception of the Fantom-S/S88 and MC-909. In these two models the /WWE signal would go into a 74LV245 chip (used in the same way as those always-enabled unidirectional level shifters in later SD-90 units), and then seemingly vanish right there. Coincidentally both the Fantom-S and the MC-909 do support sampling into a wave RAM, but they use a dedicated “BA” chip as their memory controller.

One plausible explanation of why this existed in the design is Roland wanted to make the SD-90 their response to Yamaha’s MU2000, which also has sampling capabilities, and coincidentally has 4 MiB of temporary sample storage[14]. Despite having multiple audio inputs, the MU2000 does not serve as a USB audio interface. In addition Roland’s design would have made the SD-90 a completely self-contained solution: no additional storage would be required to permanently retain the samples. Sounds like the SD-90 would be a all-around winner if had this chip, right? Unfortunately their design also makes loading samples a pain: it would probably involve some kind of proprietary communication over MIDI or USB. So maybe the MU2000 would still have a chance if the SD-90 was released with sampling capabilities[15].

But at the end of the day this would be pretty useless, just like MU2000’s sampling feature: 4 MiB of storage is not even enough for one minute of 44100 Hz single channel audio.

The way the chip select lines for these wave memory chips are connected is interesting when compared against the XV-5080. In the XV-5080, the two built-in wave ROM chips are selected first as a single entity using /WCS0, then selected between these two using WA23 with a small 2-to-3 line demuxer. In the SD-90, a similar approach is implemented with a 3-to-8 line 74LV138 demuxer. The SD-80 uses yet another different design, but it is basically a simplified version found in the XV-5080. This commonality between these different approaches is that this way the XV chip could treat the two built-in wave ROM chips as one big 32 MiB chip, rather than two individual 16 MiB chips.

This could make sense for the XV-5080, since in a fully expanded XV-5080, it has to be able to address 2 * 16 MiB + 4 * 8 MiB + 4 * 32 MiB = 192 MiB of wave ROM. It could be important to save a few chip select lines, as the XV chip only has 8 of them. But in the SD-90 / SD-80, they might as well treat the built-in wave ROM chips as separate chips to reduce the complexity of the hardware. The only reason that I can think of that explains why they did it this way is to maintain some level of hardware compatibility with the XV-5080 so they can reuse some of the software code written for the XV-5080.

Which port we using again?

The XV chip seems to have 6 output channels and 2 input channels for serial digital audio data. They are marked SDO0, SDO3, SDO4, SDO5, SDO6, SDO7 and SDI1, SDI2 respectively in service manuals for various products[16]. Among these, SDO0 and SDI1 seem to double as part of a 6-bit wide full duplex communication channel (PO5 and PI5 of PO[0..5] and PI[0..5] respectively)[17] between the XV chips when a pair is used in a design[18], and they are always used this way. Even in models where there’s only one lone XV chip, these are never used as audio I/O ports.

The other ports are used in an interesting, consistently inconsistent fashion, summarized in the table below.

Power supply

As already mentioned, the SD-90 has an extremely similar power supply section to the SD-80, even just by looking at the circuit board. In fact they are built around exactly identical core components.

I find the design based around a buck regulator used in the SD-90 and SD-80 much more reliable than the linear regulator design used in, say, the XV-5080.

Display module

When I was looking for display modules for an unrelated project, I realized displays that are almost identical to the one used in the SD-90 are still being manufactured, for example NHD-C12864WO-B1TMI#-M. This particular one seems to be a drop-in replacement. In fact, it seems to be possible to rewire any 128×64 LCD display that can use the parallel 8080 interface into the SD-90.

Although the SD-90 does indeed have a terrible display, I’m not in a rush to buy one of these to replace the factory LCD. Primarily because all drop-in replacements are also STN displays, so it’s likely that they are going to look equally terrible. Replacing it with an OLED module would be an interesting idea and will certainly look much nicer, but would also require rewiring, and right now I simply don’t have time for that.

“Emurator”

There is an unpopulated D-SUB connector[23] near the CPU, which the SD-80 also has. In SD-90’s service manual, it is marked “Emurator”[sic]. Signals connected to this port directly correspond to those used by the Hitachi User-Debugging Interface from the CPU. The datasheet of the CPU describes the Hitachi User-Debugging Interface as a JTAG-compatible interface. The section on the H-UDI does mention an emulator, as well as Advanced User Debugger (AUD), which appears in the names of multiple signals going into the port, confirming this port is used during development of these products. Hitachi’s E10A emulator kit (both the hardware and software) is the official tool used with this port.

Shared lineage with SC-D70

The SD-90 shares two major ICs with the SC-D70, which can be considered a weaker predecessor of the SD-90. They are both sound module / audio interface combo devices. The shared major ICs are all in the USB / Audio interface section.

Note that this USB controller chip runs code stored in its built-in mask ROM, the 106 in its part number being the mask code. This means the USB controller in the SC-D70 and SD-90 are running exactly the same firmware.

The USB audio interface seems an overkill for both. 4 inputs and 4 outputs are simply wasted, making me speculate it might have been used in other Roland products. However I couldn’t find such a product.

The SC-D70 is interesting in its own right. Besides the obvious shared components with the SC-8820 and SC-8850 (as its tone generator section is essentially a SC-8820), it somehow also has an ESP4 chip inside, making it the earliest Roland product to use this chip to my knowledge. This chip is also used as a secondary DSP inside Fantom-S, MC-909, and MV-8800. It’s the primary DSP chip in the V-Synth. As I don’t own one to test how is the ESP4 connected to the other chips, nor do I have access to its service manual, I currently do not have any idea what this chip is used for in the SC-D70.

SC-8850 expansion

Speaking of the SC-8850, here is something I must address despite it being completely off-topic for this post. As soon as I saw the circuit board of SC-8850’s main board, I noticed a big, unpopulated 50-pin header near one of its XP6 chips. It’s only marked as CN8 on the circuit board. But its proximity to the DSP section and one of the wave ROM chips made me speculate that it might be some kind of expansion slot.

Turns out, that is exactly the case. The component is labelled “50P-Header Expansion-Slot (NIU)”, and is a Molex 52411 plug, which is the same series of socket used for the SR-JV80 expansion boards. However SR-JV80 expansion boards use a narrower version of the socket that only has 40 pins.

This got me interested in comparing Roland’s sound expansion formats used over the years …

The theoretical max capacity is calculated using the formula 2^{(# of address signals)}×(# of data signals)×(# of CS lines)÷8. The result is the theoretical max capacity in bytes.

So Roland apparently attempted to develop a new expansion format just for the SC-8850 eh? Seems a weird thing to do for a product category on its way out … Oh that’s probably why it was scrapped.

Again this excellent article from Edward D-tech has more details on the actual content of these expansions.

IC listing

See below for a list of all ICs as installed on the main board (as well as select ICs installed on the analog board) inside my SD-90.

Please note that this information is NOT from the service manual. It’s read off actual PCB of my SD-90. Some remarks contain information derived from my reading of the schematics. If you skipped straight to this section, you may want to refer back to early sections where unpopulated chips are discussed in more detail.

Test Mode

I don’t have much to say about the test mode in the SD-90 except it does what it’s supposed to do and is in many ways extremely similar to the test mode in the SD-80.

If you’re wondering what the key combination to enter test mode is for the SD-90, it’s already referenced at an earlier point in this post.

A repair that nobody wanted to do

I daily drove my SD-90 as my primary soundcard for roughly two years, mainly to combine the sound output of two computers. Later in this period, the synthesizer portion of my SD-90 started generating noise in its output, which sounds quite like what some people have heard from their XV-5080[25]. It was even heard in the USB output, so the fault has to be in the DSPs.

As I didn’t have a oscilloscope, I couldn’t check the ripple on the power rails. I didn’t have a replacement for the regulator used in the SD-90 on hand, but I already had a bunch of capacitors (which were bought for my XV-5080 repair), and fully convinced that SD-90’s voltage regulator design is more reliable than the one in the XV-5080, I decided to try just a partial recap first.

I focused on the main power rails and bypass capacitors close to the DSP chips first. These are the capacitors I replaced:

C1, C3, C4, C139, C150, C173, C205, C232

I didn’t have access to the schematics when I did the recap. But if I did, I’d also have replaced C157, C187, C191, C212, and C219.

The original capacitors taken off the board seem to hold their original capacitance pretty well (all > 60% their designated capability), but some had terrible ESR[26] (almost 100 Ω for 16V 10µF ones).

Most SD-90 units are produced during the height of the infamous capacitor plague. Although all electrolytic capacitors specified in SD-90’s parts list are made by Japanese manufacturers and therefore theoretically weren’t affected by the plague, it’s not guaranteed that they didn’t switch supplier later into the production: Roland is known to switch supplier for non-critical parts like DRAM chips throughout a product’s life time. As an example, my SD-90 (early production, mfg. 2001-10-27) was built with DRAM chips specified in the parts list (Samsung DRAM chips for CPU RAM, ESMT DRAM chips for XV effect buffer). But Palto’s SD-90 (mid-late production, mfg. 2004-12-09) uses Sanyo DRAM chips for the CPU and ICSI DRAM chips for the XV chips. I am however not familiar enough with how surface mount electrolytic capacitors are marked to tell the actual manufacturer of the capacitors installed in my unit. What I can tell is that: a) the markings for capacitors in Palto’s unit seem identical to those in mine, b) I do recognize the markings on the bigger capacitors I swapped out (“SVP”): those are the SVP series of Sanyo’s OS-CON capacitors (as specified in the parts list), and c) of all the capacitors I swapped that had pretty terrible ESR values, they showed no sign of electrolyte leakage.

I haven’t heard noise from the internal synthesizer since the recap. I also ceased daily driving my SD-90 as my main soundcard. Be nice to your obsolete audio equipment, folks!

Driver issues

Starting from a certain insider release of Microslop Windows 11 from late 2024, the Windows 8 driver for the SD-90 would no longer function properly on my computer. All audio recordings produced from the device (regardless of the API used, be it WASAPI, ASIO, or WINMM) were either a choppy mess, or just complete noise.

I tried a bunch of workarounds, the only thing that worked was forcing UA-25EX’s Windows 10 driver onto the SD-90. This however leaves only the primary MIDI port accessible (as the UA-25EX only has one MIDI port), so it’s not a perfect solution.

I’ve asked around when I first saw the issue, and apparently nobody at the time had the same issue as me. I suspect that it might have something to do with me being on the Winblows 11 insider dev channel (now the canary channel). I haven’t asked anybody since, but now that ZUN himself is also experiencing driver issues, I guess this has become a more wide-spread issue.

On Linux, the generic USB Audio/MIDI driver is used just like the audio-less SD-80, even when the USB Driver is set to Vendor on the SD-90. As I’ve also noticed for the SD-80, the MIDI performance on Linux is noticeably worse than on Windows with an official driver. However at least it never produced unusable recordings.

Other random rants

I had much to say about SD-90’s built-in sound module and the differences between it and the SD-80 in my second SD-80 post. Click here to read that rant.

I got my SD-90 for 150 USD, and it arrived with all the original paperwork and software discs, a bargain if I do say so myself.

The built-in audio effects of the SD-90 is not a feature I used very often. In fact I think I might have used it exactly once in production.

If you came here for a generic review of the SD-90, and have been tremendously disappointed to find out it’s anything but: well, first of all I’m surprised that you’re still here reading this. And why don’t check out these other excellent posts?

• Sound On Sound’s original SD-90 review from July 2002
• Gigadenza’s page on the SD-90
• Or even my two original posts on the SD-80 … they’re not excellent but they are something!! (first post, second post)

That’s about it. Phew! That went on for much longer than I thought!

Gallery

All photos in this gallery are taken by me. I offer my apologies in advance for all the shaky and out of focus photos.

“This is peak.”	“XGL.”
Connected to a PowerBook G4 and disguised as XV-5080.	Least buggy MacOS X software.
Accessories.	Disassembled in the first hour?!
Early specimen. Multiple unpopulated components visible.	CPU.
CPU RAM and flash memory.	USB controller and audio interface.
First XV chip.	Second XV chip and one of the two sample ROM chips.
Second sample ROM chip and effect RAM chips.	Power supply section and MR3 DSP chip.
Major chips on the analog board.	Power supply section with new capacitors. Go ahead and roast my terrible solder joints.
Other swapped capacitors. Red capacitors are 100% more powerful when they blow up.	How I did the recap. There’s no flux in sight …
Service manual. Mystical 1.00 firmware. Yes I was reading it on the road.	Version information.

Acknowledgements

Major thanks go to KRPalto47 for the PCB photos and morale support. I’d also like to thank Eason20000 and others in the Touhou Instrument Sources Research server for providing firmware version information of their units.

Special thanks to archive.org’s Wayback Machine for preserving the Internet’s history.