+============================================================================+ | Roland ROM format information | | by FloppyFox | +============================================================================+ Last update: 03/Oct/2020 This document describes in detail the following file formats and ROMs: - Integra-7's internal SD card, - SRX boards for XV and Fantom, - Internal wave ROM of XV series, - Roland Cloud wave ROM format for JV-1080 and SRX plugins, - Pinouts of the SRX, SR-JV80, SO-PCM1 and SO-JD80 boards and cards. It is likely some of this information also applies to the following formats: - SR-JV80 expansion boards, - SO-PCM1 waveform cards, - SO-JD80 waveform cards, - Internal wave ROM of Roland sample-based instruments spanning from the JD/JV series through to the Integra-7, - Internal wave ROM for some (all?) members of the Sound Canvas series, - SVD disk format. This information does not apply to the D-series and U-series instruments. These use a completely different audio compression technique. Their data structures are likely different too. There are likely to be serious errors in this document. No responsibility accepted if you damage your synth etc. You may infringe patents and/or copyrights by using this information, you filthy pirate. Proceed at your own risk. Roland and their product names are trademarks of Roland etc. etc. No internal Roland documentation was used to create this document. It was entirely reverse-engineered through trial and error using Roland products available off the shelf. If you find the information presented here useful, all I ask is to be credited as FloppyFox, and to receive a copy of any software (or hardware design files) you develop from this. Thanks! +----------------------------------------------------------------------------+ | Terminology | +----------------------------------------------------------------------------+ ROM / SRX ROM A complete 32MB SRX ROM, containing all headers, tables and compressed audio. It does not apply to the Integra-7's entire SD card, although the SD card contains several SRX ROMs. Wave ROM The on-board factory sample ROM inside a synthesizer. Sample point A single audio sample value, at whatever bit depth. Sample A complete audio recording, usually of a single note on an instrument. Samples are always mono. Stereo recordings need two separate samples to be stored, one for each channel. Samples are not named in SRX ROMs. They are numbered from 0 in the order they appear in the sample table. Samples are never used directly, they are pointed to by one (or more) multisamples. Multisample A collection of sample numbers with non-overlapping key ranges, usually representing a single instrument. Multisamples are called "wave numbers" or "partials" in Roland terminology, but these terms will not be used here to avoid confusion. Multisamples are always mono. In SRX ROMs, a multisample is usually a single channel of an instrument at one velocity level. Several multisamples are layered together at the patch level to produce stereo and multiple velocity layers. Multisamples are assigned names in SRX ROMs. There are some naming conventions. Often letters are appended to indicate velocity level, such as ff, f, p, mf. A letter may be appended to indicate which channel this multisample is for ("Piano L" for the left channel, "Piano R" for the right channel, etc.) "Menu" is used to describe multisamples containing several unrelated samples (for example a collection of snare drums). You generally won't find a complete drum kit as a single multisample. Tone A tone consists of one or two multisamples (left and right), and parameters for the filter and envelopes. It makes up one of four layered components of a patch. Patch A patch contains four tones, in addition to some patch global settings such as structure, LFO, effects, velocity layering and name. It is the basic complete unit a musician plays. Drum kit A drum kit is a special form of patch, containing a separate patch definition for each key. This allows each key to have its own separate multisample, filter and envelope settings. This would not be possible if Roland had assembled drum kits into a single multisample. Performance A performance is a set of parameters defining a multitimbral setup. One patch for each MIDI channel, key and velocity ranges for each patch, MIDI channel for each patch, effects settings, etc. They can be used to produce layered sounds or split keyboard setups. More usually they are used with a MIDI sequencer to store instrument to channel assignments. ADPCM Adaptive Delta Pulse Code Modulation. A form of lossy audio compression used by Roland instruments from the JD/JV series through to the Integra-7. The difference between adjacent sample points is taken, then divided by an exponent suitable for the maximum value and stored with only 8 bits. A single exponent covers a group of 16 sample points. 0x A hexadecimal number. If not specified, numbers are decimal. % A binary number. If not specified, numbers are decimal. K / KB 1024 bytes exactly. M / MB 1048576 bytes exactly. Big endian Most significant byte comes first (at lowest address), like all good CPUs use. All multi-byte values in an SRX ROM are big endian. Signed A 2s-complement signed integer. For audio data, the DC resting level is encoded as a 0, positive values as positive integers and negative values as negative integers. This contrasts with unsigned audio where the resting DC value is half the unsigned integer's maximum range. Bit 0 The least significant bit of a byte, 16 bit or 32 bit value. Bit 7 The most significant bit of a byte. +----------------------------------------------------------------------------+ | Integra-7 internal SD card structure | +----------------------------------------------------------------------------+ Inside the Integra-7 there is an SD card plugged into the main board containing the expansion data which you can load into the four virtual slots. The SD card does not have a well-known filesystem, so you will need to make a disk image (sector-by-sector raw dump) of the card to access the data structures. The SD card does not include the 192MB of default wave ROM that's always present in the Integra-7 when nothing is loaded into the virtual slots. That data is stored on 3x 64MB NOR flash chips on the main board. The Integra-7 seems to operate fine with the card removed, but you cannot load any expansions. The disk image has the following format: Byte offset: 0x000001C0 ~16 bytes of unknown data. 0x000001FC ~4 bytes of unknown data. 0x00400000 Small FAT32 partition, no files present. 0x00400C00 Another small FAT32 partition, no files present. 0x00B76E00 "SDIF" followed by 12 unknown bytes, a date/time, and another 16 unknown bytes. 0x00B77000 All 24 virtual SRX board ROMs one after another, each one is 32MB exactly. This includes the 12 SRX boards and Integra-7-specific ROMs. Each of the SRX ROM dumps has a human-readable name, although it's quite likely the Integra-7 has more descriptive names built into its firmware. Beware of this if trying to swap out SRX images. IMPORTANT NOTE: The SRX ROMs are encoded with each group of 4 bytes reversed in order. These will need reversing to produce a usable SRX ROM dump from the SD card. Do not confuse this with endian swapping. The conversion must be done on a 4-byte basis throughout the entire ROM. The internal data structures of the SRX ROM are big endian natively, but have varying word lengths. As a result, this byte reversing process does not serve to convert the SRX ROM into little endian format. It just scrambles it and renders it unusable. 0x30B77000 The rest of the card after the 24 SRX images are all 0s. To do: find out where the number of ROMs are specified (either in the SD card or the Integra-7's firmware) and patch it to allow loading more than 24 SRX ROMs onto the SD card for user-supplied samples without sacrificing any of the factory SRX boards. Note: This information is based on looking at a single SD card. It's possible that other revisions of the Integra-7 may have different header information, and the SRX ROMs may start at a different offset on the SD card. It's even possible the SRX ROMs may appear in a different order on some Integra-7s. To avoid this problem, you could instead search the file for all known names of SRX ROMs and find the first instance. Do not search for version or date information, this may differ. +----------------------------------------------------------------------------+ | Integra-7 virtual SRX ROMs | +----------------------------------------------------------------------------+ Here is a list of all the virtual SRX ROMs on the Integra-7's internal SD card in the order they appear: # ROM title ROM code Description ------------------------------------------------------------------------------ 01 RhythmExpVer1_01 DynDr SRX-01 Dynamic Drum Kits 02 PianoExp_Ver1_00 C_Pno SRX-02 Concert Piano 03 MIKYG_Ver_1_02 Stdio SRX-03 Studio 04 SRX-04_Symph_Str Strng SRX-04 Symphonique Strings 05 SRX-05_SupDance SpDnc SRX-05 Supreme Dance 06 Orchestra CpOrc SRX-06 Complete Orchestra 07 Contemporary UlKey SRX-07 Ultimate Keys 08 Dance PlTrx SRX-08 Platinum Trax 09 Ethnic WldCl SRX-09 World Collection 10 SRX-10_BgBrsEns Brass SRX-10 Big Brass Ensemble 11 SRX-11_CompltPno CmPno SRX-11 Complete Piano 12 SRX-12_ClassicEP Cl_EP SRX-12 Classic EPs 13 ITGR7_WRom16v101 ITG16 ExSN6 SFX SuperNATURAL 14 SD-50WRom0_v1_04 SD500 SD-50's wave ROM, for General MIDI 15 TTS_Rom1v100_070 TTSR1 HQ PCM (ExPCM) part 1 16 TTS_Rom2v100_050 TTSR2 HQ PCM (ExPCM) part 2 17 TTS_Rom3v100_040 TTSR3 HQ PCM (ExPCM) part 3 18 TTS_Rom4v100_150 TTSR4 HQ PCM (ExPCM) part 4 19 ITGR7_WRom11v100 ITG11 ExSN1 Ethnic SuperNATURAL 20 ITGR7_WRom12v100 ITG12 ExSN2 Wood Winds SuperNATURAL 21 ITGR7_WRom13v100 ITG13 ExSN3 Session SuperNATURAL 22 ITGR7_WRom14v100 ITG14 ExSN4 A. Guitar SuperNATURAL 23 ITGR7_WRom15v100 ITG15 ExSN5 Brass SuperNATURAL 24 ITGR7CopiedSRX04 SRX4a Modified copy of SRX-04, purpose unknown. Has the same sample data and patch table as SRX-04. +----------------------------------------------------------------------------+ | SRX ROM structure | +----------------------------------------------------------------------------+ An SRX ROM is split into 1MB blocks. Each block consists of, in order: 1) 1024 byte header (only filled in for the first block, all other blocks are all 0s), 2) 31KB (exactly) exponent table for decompressing the sample data, 3) 992KB (exactly) of compressed sample data. A single sample cannot span across blocks, it must be entirely contained within one block. In addition to the normally-formatted blocks, there are tables for the sample definitions, multisample definitions and patch definitions. These tables do not respect block boundaries, and usually appear at the end of the ROM after all the audio data. The header of the first block contains pointers to these tables. Addresses (including sample start/loop/end) are absolute to the entire ROM. If you were to decompress the audio data as one linear file, the sample start/loop/end addresses would need adjusting since the headers are now deleted. However, the audio shouldn't be decompressed as one linear dump anyway, since samples that don't end on a 0 would cause accumulating DC offset problems with the ADPCM decoding. Decompression should be done on a sample-by-sample basis. All multi-byte values in the ROM are stored in big-endian format (most significant byte first). This does not apply to the compressed audio data and the exponent table, which are byte-orientated and do not need converting. +----------------------------------------------------------------------------+ | Structure of a single 1MB block | +----------------------------------------------------------------------------+ 0x00000 Header (1KB exactly, only filled in for the first 1MB block): 0x00000 32 unknown bytes. The values for SRX01 are: "0xA4" "0xEB" {0xA6} {0xA4} "0xE9" "0x29" [0x0C] [0x0E] 0xA4 0x64 [0xE9] [0x2A] "0xE3" "0x1C" [0xAA] [0x21] "0x69" "0x2A" [0x64] [0x4B] 0x08 0xA6 [0x21] [0x6E] 0x08 0x08 [0x6B] [0x6A] "0x64" "0x9B" [0xAC] [0x6B] Some of these may be magic numbers. Values in [square brackets] vary across different ROMs, other values remain constant even in the Integra-7-specific ROMs. Values in {curly brackets} are constant across the first 12 SRX ROMs but the Integra-7-specific ROMs differ. Values in "quotes" are constant across all ROMs, but changing them causes the Roland Cloud plugins to output silence. Non-bracketed bytes seem to be ignored by the Roland Cloud plugins. They don't appear to be checksums, you can change any of the other ROM data and still load the file. The Integra-7 may behave differently when these bytes are modified. 0x00020 16 byte ASCII name of SRX board and other text information such as version. Not null terminated. 0x00030 10 byte ASCII ROM date in yyyy-mm-dd numerical format. Not null terminated. 0x0003a 6 byte ROM codename, something like "Stdio" or "CpOrc". Usually null terminated on the last byte. 0x00040 SRX number (0x0001 for SRX-01, 0x000A for SRX-10, etc.), 16 bit big endian. The Integra-7-specific ROMs have the following values: ROM 13: 0x007E ROM 14: 0x0037 ROM 15: 0x0038 ROM 16: 0x0039 ROM 17: 0x003A ROM 18: 0x003B ROM 19: 0x0079 ROM 20: 0x007A ROM 21: 0x007B ROM 22: 0x007C ROM 23: 0x007D ROM 24: 0x003C 0x00042 Number of table pointers in the pointer area. 16 bit big endian. 0x00044 Only for Integra-7-specific ROMs: Additional text with build information. Continues up to near the table pointer area. All 0s on other SRX ROMs. 0x00080 Table pointer area starts here. Each entry defined as: Repeat for every table { Addresses relative to start of each table entry. +0x00000 Table type, 1 = sample, 2 = multisample, 4 = patch, 5 = drum kit (16 bit big endian.) Other values sometimes appear but the table types are unknown. Performances may be allocated a number too? +0x00002 Table version, possibly indicates target synth? For XV data, the following values are used: 4 = sample, 3 = multisample, 6 = patch, 5 = drum kit. Additional tables found in later SRX boards have other values. There will probably be separate values for the JD990, JV80, JV1080/JV2080/JV1010, XV series and the Fantom X at the very least. Each of these models has a slightly different synth engine. +0x00004 Pointer to table (32 bit big endian.) 0 if none. It may be advisable to ignore the least significant bit of this field and assume 0. Sometimes it seems to point to an odd offset, skipping the first byte of the table it points to. This off-by-one issue isn't reflected in the length field, the length is still the genuine full length of the table as if no bytes had been skipped. +0x00098 Length of table (32 bit big endian.) 0 if none. +0x0009c 4 unknown bytes, usually 0. } The above tables are usually but not always defined in the following order: 1) Sample table, 2) Multisample table, 3) Patch table, 4) Patch definitions for other synths, if present, 5) Drum kits. The maximum observed number of tables in a single SRX ROM is 8. The minimum found on physical SRX boards should be 3. For virtual SRX ROM files, it can be as low as 0. -> 0x003fc 0 byte padding to reach address 0x003fc. 0x003fc Four unknown bytes of data only present on the Integra-7-specific ROMs. 0s on all other ROMs. 0x00400 Exponent table for decompressing wave data (31KB exactly). 0x08000 Compressed wave data (992KB exactly). NOTE: The Integra-7-specific ROMs sometimes lack patch or drum kit tables. Could be one of three possibilities: 1) Another table type (0x20?) stores a special type of table (SuperNATURAL patch table?). 2) Internal wave ROM or firmware stores the patch table. 3) Another virtual ROM file stores the patch table which references waveforms on another virtual ROM. The Roland Cloud SRX-like format lacks the patch table, which is instead provided by another file. The multisample names are stored in another file in the plugin too, but not any other information about the multisamples. Likewise, the wave ROM for the XV series synths have no tables at all which allows all the ROM space to be used for audio. You can find these tables in the firmware for the XV series and put it back into the ROM dump, but you will end up with a file slightly greater than 32MB. +----------------------------------------------------------------------------+ | Audio compression format | +----------------------------------------------------------------------------+ A simple 8 bit ADPCM method is used, with out-of-band exponent signalling. Audio decompresses to 18 bits per sample point. Each sample must be decompressed by itself to prevent DC offset problems, do not decompress the entire ROM as one uninterrupted operation. This is because some samples don't end on a zero value and the DC error will accumulate. The audio data consists of signed 8 bit bytes, one byte per sample point. Each group of 16 sample points is controlled by a single exponent value. The exponent values are stored in a separate exponent table. This contains two exponent values per byte, one nibble each. The least significant value controls the first 16 bytes of audio data, the most significant value controls the next 16 bytes. The audio byte (sample point) should be shifted left by the exponent value and added to a running count (which is the output). The running count starts at 0 for every sample decompressed. The running count never resets during playback of a sample, not even at loop points. Note that when playing back in reverse (due to reverse play or ping-pong loop) the audio bytes are still added to the running count rather than subtracted. Failure to observe this point will cause glitches at loop points. Ping-pong loop mode always plays the first and last sample points on each direction. Therefore on a continuous ping-pong loop, the first and last sample points are repeated twice in a row. For example: 1, 2, 3, 4, 4, 3, 2, 1, 1, 2, 3, 4, etc. This is important to observe to get a glitchless loop. IMPORTANT NOTE: after compressing a sample, there must be no net DC across the loop, all the bytes after shifting by their exponents must add up to 0. This requires extra work on behalf of the encoder to selectively round up or down until this criteria is met. Failure to observe this will cause the DC offset to increase each time the loop repeats, eventually clipping the synth outputs or causing a loud pop when the key is released. The highest observed exponent value is 0xA (10). The lowest is 0. Even after adding to the running total, the magnitude has never been observed to exceed 18 bits. The output is often more like 17 bits, but this may not be a safe assumption. Roland almost exclusively used 18 bit DACs during the 90s, so 18 bit encoding is logical. It is not certain whether the encoder ever exploits wrapping. No evidence of wrapping has been found yet. Note that the sample playback engine will most likely read values before and after the start and end of the sample to perform interpolation. It appears most of the ROMs have at least 3 bytes of 0s before the start of each sample and 8 bytes of 0s after each sample to account for this. It may be safest to include 8 bytes on each side of every sample when creating ROMs. +----------------------------------------------------------------------------+ | Audio decompression example | +----------------------------------------------------------------------------+ /* Public domain C code to decompress a sample to 32 bit signed data. */ #define OUTPUT_BITS 18 #define SAMPLES_PER_EXPONENT 16 #define SAMPLES_PER_EXP_BYTE (SAMPLES_PER_EXPONENT*2) #define SRX_SIZE_MB 32 typedef struct SRX_BLOCK { uint8_t header[1024]; uint8_t exponents[31*1024L]; int8_t sample_data[992*1024L]; } SRX_BLOCK; typedef struct SRX_ROM { SRX_BLOCK blocks[SRX_SIZE_MB]; } SRX_ROM; void decompress_sample(int32_t *output, SRX_ROM *rom, int32_t start_address, int32_t length) { int32_t block, block_base, offset_in_audio, audio_start_in_block; int32_t i, sample, exponent; int32_t output_run = 0; block = start_address / sizeof(SRX_BLOCK); block_base = block * sizeof(SRX_BLOCK); audio_start_in_block = (int32_t) ( (int8_t *) rom->blocks[0].sample_data - (int8_t *) rom->blocks[0].header ); offset_in_audio = start_address - block_base - audio_start_in_block; for( i = 0 ; i < length ; i++ ) { sample = rom->blocks[block].sample_data[ offset_in_audio + i ]; exponent = rom->blocks[block].exponents[ (offset_in_audio + i) / SAMPLES_PER_EXP_BYTE ]; if( (offset_in_audio+i)%SAMPLES_PER_EXP_BYTE >= SAMPLES_PER_EXPONENT ) exponent >>= 4; else exponent &= 0xf; output_run += sample << exponent; output[i] = output_run << (32-OUTPUT_BITS); } } +----------------------------------------------------------------------------+ | Multisample table structure | +----------------------------------------------------------------------------+ Header ------ 0x0000 Number of multisamples (16 bit big endian). 0x0002 2 unknown bytes, usually 0. 0x0004 Offset of pointer table from start of header (32 bit big endian.) Usually 0xC. 0x0008 Length of each entry in the pointer table (32 bit big endian.) Usually 8. [Additional data may appear here if the pointer table offset was greater than 0xC.] Multisample pointer table ------------------------- Repeat for every multisample definition { 0x0000 Offset of multisample definition structure, relative to the start of the header (32 bit big endian.) 0x0004 Length of multisample definition structure (32 bit big endian.) [Additional data may appear here if the length of each entry in the pointer table is specified to be longer than 8.] } +----------------------------------------------------------------------------+ | Multisample definition structure | +----------------------------------------------------------------------------+ Header ------ 0x0000 12 byte ASCII multisample name, padded with spaces. This is not null-terminated. 0x000c 4 unknown bytes, usually 0. Repeat for every key range { 0x0010 Byte, topmost MIDI note of the range that the sample will still play at, before moving onto the next range. 0x0011 1 unknown byte, usually 0. 0x0012 Sample number, 0xFFFF means no sample defined for this range (16 bit big endian.) } The number of ranges in the multisample range table is not encoded in the header. You will have to determine this by taking the size of the whole multisample definition structure, subtracting the header size (16 bytes) and dividing by the size of each entry in the multisample range table (4 bytes). +----------------------------------------------------------------------------+ | Sample table structure | +----------------------------------------------------------------------------+ Header ------ 0x0000 Number of samples (16 bit big endian.) 0x0002 2 unknown bytes, usually 0. 0x0004 Sample definition table offset from start of header. Usually 0xC (32 bit big endian.) 0x0008 Length of each sample definition in bytes. Usually 0x18 (32 bit big endian.) Sample definition table ----------------------- Repeat for every sample { 0x0000 Volume byte, 0x00-0x7F. 0x7F = maximum volume. Upper bit of this byte is ignored but should be 0. A sample point is scaled by this volume byte according to the following formula: sample_point * (volume_byte * volume_byte) / (127 * 127) 0x0001 Loop mode byte, 0 = forward looping, 1 = ping-pong looping, 2 = no loop, 6 = reverse playback with no loop. Note: The JD series instruments do not support reverse playback. It is unknown whether they support ping-pong loops. 0x0002 MIDI root note number byte. 60 (0x3c) = middle C (C4). 0x0003 1 unknown byte, usually 0. 0x0004 2 unknown bytes, often 0x02 0x00. 0x0006 Fine tuning value, in 1/1024ths of a semitone. Higher values play back at higher pitches. Centre is 0x400 (16 bit big endian.) 0x0008 Loop pitch fine tuning value, in 1/1024ths of a semitone. Centre is 0x400. This is relative to the fine tuning above (16 bit big endian.) The pitch is changed by this amount upon jumping back to the loop point for the first time. Used to compensate for pitch shifts caused by very small loops and the limitation of integer values for the loop point. 0x000a Sample rate, expressed in samples per 1/100th of a second, i.e. 320 for 32kHz and 441 for 44.1kHz (16 bit big endian.) 0x0018 Sample start address in bytes, relative to start of entire ROM (32 bit big endian.) If the sample is being played in reverse, this will be the last sample played, and the lowest address. 0x001c Sample loop point in bytes, relative to start of entire ROM (32 bit big endian.) This is the first sample point of the loop which is actually played every time the loop repeats. 0x0020 Sample end address in bytes, relative to start of entire ROM (32 bit big endian.) This is the last sample point which is actually played. Therefore loop length is: sample_end - sample_loop + 1 and sample length is: sample_end - sample_start + 1 } +----------------------------------------------------------------------------+ | Patch table structure | +----------------------------------------------------------------------------+ 0x0000 Number of patches (16 bit big endian.) Warning: Sometimes the patch table pointer points to an odd address. In this case, round it down to an even address to read this value correctly. The rest of the patch table is a tough nut to crack. It appears to be packed. Possibly variable-length parameters. Even the ASCII names of the patches appear to be packed and unreadable. Each patch seems to be about 576 bytes. The Roland SVD disk format (XP series workstations etc.) appear to use a different number of bits for each parameter. 7 for each ASCII character, less for some other parameters. The 7 bit data is unpacked like this: Compressed Uncompressed Byte 0, bit 0 -> Byte 0, bit 0 (least significant bit) Byte 0, bit 1 -> Byte 0, bit 1 Byte 0, bit 2 -> Byte 0, bit 2 Byte 0, bit 3 -> Byte 0, bit 3 Byte 0, bit 4 -> Byte 0, bit 4 Byte 0, bit 5 -> Byte 0, bit 5 Byte 0, bit 6 -> Byte 0, bit 6 (most significant bit of 7 bit value) Byte 0, bit 7 -> Byte 1, bit 0 Byte 1, bit 0 -> Byte 1, bit 1 Byte 1, bit 1 -> Byte 1, bit 2 etc. However this decompression method doesn't work for the SRX patch table, regardless of what bit offset you start decompressing at. It may be packed more aggressively or the bits may be reordered in some other way. +----------------------------------------------------------------------------+ | Limits | +----------------------------------------------------------------------------+ The Roland synths may (unconfirmed) copy some data structures into RAM at boot time or when patches are selected. This would place a limit on how many patches, multisamples, samples and key ranges can be defined. When creating ROMs, avoid exceeding the maximum values found in existing SRX ROMs for compatibility. Largest multisample table on SRX boards: 76808 bytes Largest multisample table on Integra-7-specific ROMs: 41932 bytes Largest sample table on SRX boards: 112572 bytes Largest sample table on Integra-7-specific ROMs: 76620 bytes Maximum number of ranges on SRX boards: 88 Maximum number of ranges on Integra-7-specific ROMs: 106 Maximum number of multisamples on SRX boards: 951 Maximum number of multisamples on Integra-7-specific ROMs: 702 Maximum number of samples on SRX boards: 4690 Maximum number of samples on Integra-7-specific ROMs: 3192 It's reasonable to assume the limits on SR-JV80 boards will be lower because the host synths have less internal working RAM. +----------------------------------------------------------------------------+ | Physical SRX board pinout | +----------------------------------------------------------------------------+ The SRX boards contain 32MB of ROM, 16 bits wide. As the data stored on the board is byte-orientated, the correct endian needs to be used when writing out a ROM dump file. This should be immediately obvious by looking at the ROM title. The ROM may be a 3.3V part, so use 3.3V TTL levels to drive the inputs to the board. The board has two chip select lines, and also 23 address lines (A0-A23). The first 16MB is controlled by /CS0 and the second 16MB by /CS1. Some SRX slots have more chip select lines wired. It may be that Roland at one point considered releasing larger boards which could only be installed in certain slots? XV-5080 slot 1: 8 chip select lines (max 128MB). XV-5080 slot 2: 2 chip select lines (max 32MB). XV-5080 slot 3 and XV-88 slot 1: 4 chip select lines (max 64MB). XV-5080 slot 4 and XV-88 slot 2: 2 chip select lines (max 32MB). The additional chip select lines are shared with the other slots. There is a masking system on the XV-5080 (and maybe other synths) which allows the host to disable the other slots if a larger board were to be inserted in the first slot. There is also a write signal to the SRX boards (XV-5080 only), so Roland may have planned to release flash boards. The /FLASH_WR_PROTECT signal is low to write protect the flash device. The boards also contain provision for an EEPROM, with the appropriate serial bus signals to control it. It is unknown what data this EEPROM contains. Some possibilities might include: 1) Human-readable well-formatted name and/or identifier number for the board (this would allow Roland to decide the name used to market the board after the mask ROM is finalised. The names found in the mask ROM are sometimes development code names rather than the name the board was released under), 2) What type of board (ROM/flash), 3) Size of board (32MB/64MB/128MB), 4) Patch/sample/multisample tables to replace certain tables in the ROM for fixing bugs (without having to make a new mask ROM), 5) The entire patch table, if the patch table is not present in a particular mask ROM, 6) Firmware updates or bug fixes for the host to enable it to read the new board. The SRX boards have the following pinout: SRX pin SRX pin 1 +3.3V 41 GND 2 +3.3V 42 GND 3 +3.3V 43 +3.3V 4 +3.3V 44 GND 5 +3.3V 45 GND 6 A23 46 A22 7 A21 47 A20 8 A19 48 A18 9 A9 49 A8 10 A10 50 A7 11 A11 51 A6 12 A12 52 A5 13 A13 53 A4 14 A14 54 A3 15 A15 55 A2 16 A16 56 A1 17 +3.3V 57 A17 18 /WR for flash boards (+3.3V on XV-88) 58 GND 19 +3.3V 59 /OE 20 D15 60 GND 21 D0 61 D7 22 D8 62 D14 23 D1 63 D6 24 D9 64 D13 25 D2 65 D5 26 D10 66 D12 27 D3 67 D4 28 D11 68 /CS0 29 /CS1 69 /CS2 ** 30 /CS3 ** 70 /CS4 *** 31 /CS5 *** 71 /CS6 *** 32 /CS7 *** 72 Unknown output 2 (n/c on XV-88) 33 +5V * 73 /FLASH_WR_PROTECT (GND on XV-88) 34 Unknown output 1 (n/c on XV-88) 74 GND 35 +5V * 75 Detect input (is board present?) 36 /RESET 76 GND 37 +5V 77 EEPROM serial data in 38 EEPROM serial clock 78 GND 39 +5V 79 EEPROM /CS 40 EEPROM serial data out 80 GND IMPORTANT: The above layout does NOT imply the physical layout of pins on the SRX board connector. The unknown outputs are outputs from the SRX board and inputs to the host. Their purpose is unknown, but it may be related to whether flash memory is busy or ready. It might also be used to detect a flash board. Unknown output 1 is wired separately for each slot, while unknown output 2 is wired in common to all slots. * These pins are supplied through a 0 ohm resistor, which may not be installed in some situations. ** These pins are only present on XV-5080 slots 1 and 3 and XV-88 slot 1. They are pulled high on the other slots. *** These pins are only present on XV-5080 slot 1. They are pulled high on the other slots. This information is based on both the XV-88 and XV-5080 circuitry. Other XV series synths may or may not include the extra chip select pins and flash control pins. Model Synth chip Number of chips Sample mixing rate XV-5080 XV 2 (128 poly) 44.1kHz XV-5050 XV 1 (64 poly) 44.1kHz XV-3080 JV (yes really) 2 (128 poly) 32kHz XV-88 JV (yes really) 2 (128 poly) 32kHz Address space Address pins ROM /CS pins DRAM /CS pins XV chip 512MB + DRAM* 25 8 1 JV chip 128MB 23 8 0 * DRAM is addressed separately. Upper size limit unknown. 128MB in XV-5080, chip may be capable of addressing much more through RAS/CAS multiplexing. IMPORTANT NOTE: Do not assume a standard arrangement of address and data lines based on the ROM chip's pinout on the card! Remember that when the datasheet labels a pin "D0" or "A0", this is merely a suggestion. As long as the same line is used during writing the ROM and reading it back, it does not matter which bit numbers you assign to which pin. Instead it is common practice to choose the pin assignment to make board layout easier. If you read back what looks like "corrupted" data, you may have the assignments wrong. +----------------------------------------------------------------------------+ | Physical SR-JV80 board pinout | +----------------------------------------------------------------------------+ The SR-JV80 boards contain 8MB of ROM, 8 bits wide. There are 21 address lines and 4 chip select lines. The first 2MB is controlled by /CS0, the next 2MB by /CS1, etc. The ROM is a 5V part and should be able to accept 5V TTL levels. The SR-JV80 boards have the following pinout: 1 +5V 21 A11 2 GND 22 A10 3 A12 23 A9 4 A13 24 A18 5 D6 25 A8 6 D7 26 A7 7 A0 27 A6 8 A17 28 A5 9 A16 29 D5 10 A15 30 D4 11 A14 31 D3 12 /OE 32 D2 13 +5V 33 A4 14 /CS0 34 A3 15 /CS1 35 A2 16 /CS2 36 A1 17 /CS3 37 D1 18 Detect input (is board present?) 38 D0 19 +5V 39 A19 20 GND 40 A20 IMPORTANT: The above layout does NOT imply the physical layout of pins on the SR-JV80 board connector. The detect pin is pulled down in the host by a 10k resistor. Pulling this pin high will cause the host to detect the board at startup. The XV series do not use the detect pin, presumably they read the ROM header to determine whether a board is present. The firmware for the XV series contain references to SR-JV80-01, SR-JV80-02 and SR-JV80-03. Perhaps these boards predate a detectable ROM header. The JV series do use the detect pin. IMPORTANT NOTE: Do not assume a standard arrangement of address and data lines based on the ROM chip's pinout on the card! Remember that when the datasheet labels a pin "D0" or "A0", this is merely a suggestion. As long as the same line is used during writing the ROM and reading it back, it does not matter which bit numbers you assign to which pin. Instead it is common practice to choose the pin assignment to make board layout easier. If you read back what looks like "corrupted" data, you may have the assignments wrong. +----------------------------------------------------------------------------+ | Physical SO-PCM1 / SO-JD80 card pinout | +----------------------------------------------------------------------------+ The "credit card" style PCM cards for the JD/JV series contain 1MB or 2MB of ROM, 8 bits wide. There are 21 address lines and a single chip select. The JD990 and JV series can address 2MB. The JD800 can only address 1MB and A20 is left floating on the card socket. 1 Detect input (is card present?) 21 A6 2 GND 22 A7 3 +5V 23 A8 4 A20 (n/c on JD800) 24 A18 5 A19 25 A9 6 /CS 26 A10 7 D0 27 A11 8 D1 28 A12 9 /OE 29 A13 10 n/c 30 D6 11 A1 31 D7 12 A2 32 A0 13 A3 33 n/c 14 A4 34 A17 15 D2 35 A16 16 D3 36 A15 17 n/c 37 A14 18 D4 38 +5V 19 D5 39 GND 20 A5 40 Connected to +5V via 0 - 4.7k ohm resistor in host. Card connects this pin to pin 1. IMPORTANT: The above layout does NOT imply the physical layout of pins on the PCM card connector. PCM card pins are arranged in a single line numbered from 1 to 40. The detect pin is pulled down in the host by a 1k-47k resistor. Pulling this pin high by connecting it to pin 40 will cause the host to detect the card. The input is a CMOS level input (HC rather than HCT). Unlike the SR-JV80 and SRX boards, pulling the detect pin high will trigger a CPU interrupt allowing the card to be hot swapped. Pin 1 and pin 40 are at opposite ends, so these pins becoming connected will signal the card has been fully inserted. Note the SO-PCM1 cards contain both patches and sample data, while the SO-JD80 cards contain only waveforms. The data structures on the SO-JD80 cards may differ as a result. The pullup and pulldown values for pins 1 and 40 are shown below: Pullup Pulldown Addr/Dat series resistors Data bus pullup/down JD800 470 4.7k N/A 10k pullups JD990 220 1k N/A ? JV880 0 10k 470 ? JV1080 4.7k 47k N/A Mix of 10k pullups and pulldowns on every other bit. The /OE signal is wired as follows: JD800 Common to all ROM, driven by synth IC. JD990 Common to all ROM, driven by synth IC. JV880 Wired directly to ground. JV1080 Common to all ROM, driven by synth IC. +----------------------------------------------------------------------------+ | Version history | +----------------------------------------------------------------------------+ 03/Oct/2020 Minor revisions. 16/Sep/2020 Initial version. +----------------------------------------------------------------------------+ | End of file | +----------------------------------------------------------------------------+