Will adding bigger DRAM to a DD-3 increase delay time?

[Processaurus]

I had peaked inside my rev 2 DD-3 delay and saw it uses a 41464 DRAM chip, it is a 64K X 4 bits, this may betray a total lack of understanding of all things digital, but if I were to say, put in a 256K x 4 bits DRAM chip, would that magically quadruple the delay time?

[danngreen]

Probably not. The software will probably only be referencing RAM addresses for the first 64k, so the rest of the 256k will go unused.  Unless they had plans for releasing a longer delay time model and wrote the code to auto-detect the RAM size, you'd have to alter the software, which is more or less impossible...

[oskar]

I doubled the delaytime on an early Yamaha rackmount reverb by changing crystal.
Kind of funny and absolutely low-fi...     

oskar

[tommy.genes]

danngreen is right in thinking that it would be a problem of addressing. Looking at the original DD-2/3 schematic, which is not the same as the DD-3 Rev 2 I am aware, the 4164 DRAM chips were connected to a pin on the controller labeled RAS16. It is interesting to note that there are unused pins on the controller labeled RAS32, RAS48 and RAS64. This implies that the Boss engineers were allowing for the possibility of using at least different, and possibly larger DRAM chips with the same controller. This thinking may have carried over into Rev 2 as well. Have you ever found a DD-3 Rev 2 schematic?

Side Note - RAS = Row Address Strobe. Along with CAS (Column Address Strobe), this allowed the same 8 pins to separately address row and column, thereby avoiding the need for 16 separate address pins. The same applies to the 41464 chips, except that for every one of the 64k (2^16) addresses, there were four bits of data stored as opposed to just one in the 4164.

Another interesting idea is that of piggybacking DRAM chips. Here is an explanation I found on Harmony Central, specifically in reference to an Ibanez DL-5.

Place the second 4164 DRAM right on top of the first and solder all the pins in parallel except the input and output pins. Connect the out pin from the first DRAM to the input of the second dRAM. Connect the out pin of the second dRAM to where the first DRAM's out pin went. You've doubled the echo Delay Time.

As I understand this, when the data would normally be read back into the controller, it is instead re-written into the added DRAM chip where it must wait through a second delay cycle before actually being read back into the controller - effectively doubling the delay time. Kinda like a DRAM-based shift register.

-- T. G. --

[oskar]

Another interesting idea is that of piggybacking DRAM chips. Here is an explanation I found on Harmony Central, specifically in reference to an Ibanez DL-5.

Place the second 4164 DRAM right on top of the first and solder all the pins in parallel except the input and output pins. Connect the out pin from the first DRAM to the input of the second dRAM. Connect the out pin of the second dRAM to where the first DRAM's out pin went. You've doubled the echo Delay Time.

As I understand this, when the data would normally be read back into the controller, it is instead re-written into the added DRAM chip where it must wait through a second delay cycle before actually being read back into the controller - effectively doubling the delay time. Kinda like a DRAM-based shift register.
-- T. G. --

But I don't think anything is shifted... The memmory is just written to and read from. I don't think this will work, at least not for the DD-3.   
Is this verified in any way?     

oskar

[tommy.genes]

I knew that shift-register analogy was a little half-baked.

The way a RAM-based delay works: the most recent sample bit or word is written into RAM at an address called the write vector. After that sample is written, the write vector is incremented by 1 and the next sample is written. This process repeats so that your sample data is arranged in a time-ordered fashion in RAM. The read vector is offset from the write vector by a set number of samples based on the delay time desired. At a sample rate of 44.1kHz, for example, a 100ms delay would equate to an offset of 4425 samples. Now the controller is alternately writing and reading data to/from the RAM, so that if the write and read vectors were equal, there would be nearly zero delay in the signal. Because of the offset between the write and read vectors, however, there is a significant delay between the audio entering and leaving the circuit.

The way a piggyback RAM chip changes things: the most recent sample is written into the original RAM according to the write vector, and it is read from the original RAM according to the read vector just as above. However, because the output of the first RAM is connected to the input of the second RAM, the data that is being read off the first RAM is then re-written into the second RAM instead of going back to the controller as originally designed (this is where I thought the shift-register analogy applied). The difference is, the data has already been delayed once by the write/read offset during its time in the first RAM, but it is written into the 2nd RAM using the current write vector. So, by the time it is read off the 2nd RAM and sent to the controller, it has been delayed by two times the offset.

I haven't done this myself, but I just looked at a schematic for an Ibanez DML, and it uses DRAM chips in just this manner, i.e. controller output connected to input of DRAM #1, output of DRAM #1 connected to input of DRAM #2 and output of DRAM #2 connected to input of controller. So there is precedent of this idea being used in a commercial pedal. Looking at a schem for the original DD-3, there are three 64k x 1 DRAM chips wired in parallel, not series, so to double the delay time for the original you'd have to piggyback all three chips. For the DD-3 Rev 2, I don't have a schematic, so I can't guarantee that this trick would work. I gather from Processaurus' post that it uses a single 64k x 4 DRAM chip. Piggybacking in this case is a little more work since you'd have to connect four outputs of the original DRAM to four inputs of the new DRAM, and the same would apply for the outputs of the 2nd DRAM going back to the controller.

Hopefully Processaurus will post anything he learns about the DD-3 Rev 2.

-- T. G. --

[Processaurus]

Don, many thanks for explaining that.  I'll have to read through it some to get it.  I think I'll bite the bullet and order the schem+service notes from roland for the DD3.  My inspiration for asking was wanting to make a poor man's PDS 8000, its  like the DD3 with the hold, but it has 8 seconds of delay. 

Actually thinking about it, maybe the hold function just ceases the write part of the process to the DRAM, but still allows the reading to go on continually?

[tommy.genes]

Actually thinking about it, maybe the hold function just ceases the write part of the process to the DRAM, but still allows the reading to go on continually?

That would make sense. When you put the pedal in HOLD mode, the write function would continue so you have a "record" of what you played in RAM. When you press the pedal, the writing stops but reading begins so you get the repeats. There must be more going on though, or else the read vector would always scan all of the RAM, and HOLD would only work at the longest delay setting. From earlier posts, I know you've successfully made a mod so that HOLD could also be used on shorter delay times. Perhaps the controller has some additional logic so that it only scans just as much RAM as it needs for a given delay (offset) setting.

Just one other point to clarify: when you choose a given delay range using the MODE switch, you are actually choosing one of three fixed write/read offset values. Once a range is selected, finer control of delay time using the D.TIME knob is achieved by changing clock speed. This is why changing delay times while playing results in a pitch-shift effect.

If you do get the service notes from the DD-3 Rev 2, I'd be interested in trading you the service manual I bought for the Ibanez DML. I actually have a DML-20 on the table in the lab now, and the component numbering and values don't match the older schematic exactly, but its still getting the job done.

-- T. G. --