making a delay unit out of RAM chips...

[O'malley's Alley]

So, I bought this old computer at a garage sale for $3.00, and I stole out like 6 RAM chips, each about 8mb.  I've heard of people making digital delay units using these, but is there any good tutorials out there on how?  Not just a thing with theories, but like an actual tutorial maybe?

Has anyone done this and made a successful delay unit?  I am a delay nut, and I would love to do this as a project.  Is it a very hard thing to accomplish?

[toneman]

computer rams are *dynamic*--
i.e. U need to refresh.
there *are* dedicated refresh chips. but ??more expense?
SRAM, StaticRAMs don't need refresh.
Wasn't there *just* a thread on an "all in one" delay chip??
The EV 16second delay did it with DRAMS.
DRAMS were uses cause of the (then) hi price of SRAMS.
used a bunch of counters 2 do the refresh.
look at that circuit and see if U *still* want to build your own delay/

afn
tone

[Ansil]

Peter Snowberg and i were talking about this about a year ago or so and brought it up again later.  i have all of his info printed out but not near me.

[niftydog]

I know a guy who did it, but don't know any particulars. Perhaps using a large FIFO buffer?!

In fact, I might try to get some info out of one of my lecturers, he supervised this guy when he built his (tech college project).

[R.G.]

Using the RAM isn't difficult at all.

What is hard is doing the analog ->digital -> analog conversion at the front and back end.

[brett]

A soundcard or similar could do the A/D/A.  
But don't overestimating the value of a $3 PT2399, with RAM, A/D/A, clock, etc built in.
good luck

[Mark Hammer]

As noted, the hard and costly part is the A-D and D-A conversion.  The PT239x series incorporate 10-bit A-D and D-A in addition to RAM.  Take a peek through any major industrial (Mouser, Digikey, Jameco, etc.) catalog at the price of 10-bit conversion chips and you'll find that they will cost you several times more than a PT239x chip.....each.

Add to this the fact that you'd either have to make your own PC board or go nuts with the wire-wrap tool and a kluge board (geez, does ANYONE remember those days?).  Even if you have a cousin who can score you free 16-bit conversion chips in DIP form, unless you're highly skilled, the layout issues will send you to an early grave.

Nah.  As tempting as it is, go for premade stuff.

[Peter Snowberg]

I have a little different take on this stuff....

I see the hard parts as building good, steep filters to avoid aliasing noise and the DRAM controller. Most A/D and D/A chips are about as hard to use as a common opamp, but that filtering requirement is a killer.

Any time you go A/D, you need to sample at a frequency that is at least 2X the highest frequency you want to capture in the sample. Simple filters just are not sharp enough so you often see 5th order and deeper filter structures. These are called anti-aliasing filters. To make the filter requirement less strict for covering the audio range, you need to raise the sample frequency. This is what the term "oversampling" is all about. Google "Nyquist theorem" for lots more on the topic.

The really big issue is control of DRAM. This stuff is a bit of a pain because instead of one big happy linear address space, DRAM is organized into rows and columns. You have to feed the address to the chips in two parts and the timing here is fairly critical. Next you have to deal with "refresh". If you don't access every row in the memory array at least every couple of milliseconds, the memory will forget. Many DRAMs have a feature that allows a special sequence of the column address strobe and the row address strobe to make use of a refresh address generator in the memory chip. If your RAM doesn't support that then you'll need to add additional counters and multiplexers to the controller. Yuck.

The PT239X chips don't use typical A/D and D/A converters. Instead they use a 1 bit converter and they raise the sample frequency VERY high. This structure is called DM or "Delta Modulation" and it makes filtering very easy in comparison to more traditional A/D. Instead of a string of numbers for a sample weight, DM outputs a PWM (Pulse Width Modulated) signal where the ratio of high to low time represents the analog voltage. I don't know about the 2399, but the 2395 goes one step past delta modulation by "adapting" to the amount of input/output voltage shift that 1 bit represents. That technique is called ADM or Adaptive Delta Modulation.

Nah. As tempting as it is, go for premade stuff.

I agree 100%.


Mark, I do remember those days well and look back on them somewhat longingly (although not from a debugging standpoint). I still have a whole bunch of "level 3" sockets and several thousand pieces of pre-stripped #30 kynar.

[puretube]

Peter: do you have the 4-page datasheet or the large one for PT2395?
:wink:

[R.G.]

The really big issue is control of DRAM. This stuff is a bit of a pain because instead of one big happy linear address space, DRAM is organized into rows and columns.

Actually, that's not an issue. Here's why:

RAM stands for "Random Access Memory". And it means just that. There is no particular need for you to use an external address counter that really puts word 1 next to word 2 inside the memory as long as the external address counter reliably goes from wherever word 1 is to word 2 every time. It does not matter to the RAM at all that they're not sequential internally, or not any order at all. Random access really means random.

As for refresh, refresh just needs to be thought about, not necessarily supplied with special logic. In common with display memory, all delay line uses of RAM involve cycling through some amount of the RAM over and over in succession. Both of them are natural applications for DRAM because if you are reasonably careful about how you do the cycling (like, for instance, CAS bits as the lower order bits) then simply running through the read/write loops on the application refreshes the memory more often that it needs. Usually DRAM has a smallish number of refresh cycles to run, maybe CAS lines only, and this is smaller than the smallest delay time, and so refresh is inherent in the application itself.

[R.G.]

I should add that if I had found a cheap, easy to use sigma/delta ADA or a simple serial output/input ADA, or a simple, fast way to get the address counting done in a PIC, we'd already have delays made from a PIC, an ADA and a single-bit memory chip running out our ears. It's not because I haven't looked.

[puretube]

let`s google...  

[Peter Snowberg]

The really big issue is control of DRAM. This stuff is a bit of a pain because instead of one big happy linear address space, DRAM is organized into rows and columns.

Actually, that's not an issue. Here's why:

RAM stands for "Random Access Memory".

The sequential or non-sequential access is not the issue in the slightest. The type of counter used really doesn't matter. It's the fact that you have to first supply a stable row address to the chip, then bring /RAS low, then after a pre-determined number of nanoseconds switch the row address for the column address, then after that stabilizes you bring /CAS low, then you bring /OE low and after another pre-determined number of nanoseconds you can finally latch the data from the RAM and then to complete you bring /CAS and /RAS high again and wait for another pre-determined number of nanoseconds. Now that's only for the read operation. If you want to write data too you have to make a longer sequencer that adds a write cycle to the above events or you have to repeat the whole CAS/RAS cycle over again.

That's a big pain in the butt in comparison to using static RAM where all you need is a basic single phase clock to keep it all going.

I've written a number of PIC and Ubicom based DRAM controllers for use in data loggers & embedded control systems. It's not that difficult. Microchip had an app note over 10 years ago that demonstrated using a 4164 and a PIC16C57 together.

It's not hard to make a DRAM controller in software if your CPU is fast enough, but it's a pain in hardware.

Don't look to PICs as being fast enough to do everything on their own, but with a counter to sequence things and pair of shift registers to deal with the data bits it's really a piece of cake. The Ubicom SX chips are a different animal even though they speak an almost identical language to the 16C5x series. They have speed to burn. I wrote a 230.4KHz DPLL / HDLC decoder / Bi-Phase decode / AppleTalk DDP protocol driver on an SX50 that emulated half of a Zilog Z8530. That used up just about every cycle available running at 50 MIPS, but it demonstrated the power of software to emulate hardware to me in a big way. The solution was also a heap cheaper and smaller than using the 8530 not to mention that 8530s were very often on allocation.

As a long time embedded systems person, I think the only reason you don't see lots of PIC based delays is that they are not that many PIC programmers that are into effects. If you don't have the hardware to burn chips and develop code efficiently it's not going to happen.

Back in 1994 my first PIC projects were all done using a pile of UV erasable PICs. I would assemble, burn, plug into the circuit (ZIF socket installed), test, unplug, drop the chip in the eraser, and go back to the screen. It was not practical. Buying a hardware emulator based on a "bond-out" PIC made weeks of work turn into hours. These days I wouldn't dream of developing without JTAG unless I was under duress.

[Peter Snowberg]

Here's a good example of using a PIC and a 30 pin SIMM to record up to 4 megs of 8 bits at 250KHz.

http://home.kabelfoon.nl/~bertrik/bat/timexp.htm
http://home.kabelfoon.nl/~bertrik/bat/dram.txt

Code Select Expand


INT:save STATUS and W, select RP0
INTT0:  BCF     _T0IF           ;TIMER 0 INTERRUPT
       MOVLW   D'32'           ;Performes the CAS before RAS refresh, 256
cycles every 4 ms
       MOVWF   RASCNT
I2:     BCF     _CAS            ;of course this can be shortened
       BCF     _RAS            ;and initial RASCNT value increased,
       BSF     _RAS            ;but I still have plenty of EPROM left
       BCF     _RAS
       BSF     _RAS
       BCF     _RAS
       BSF     _RAS
       BCF     _RAS
       BSF     _RAS
       BCF     _RAS
       BSF     _RAS
       BCF     _RAS
       BSF     _RAS
       BCF     _RAS
       BSF     _RAS
       BCF     _RAS
       BSF     _RAS
       BSF     _CAS
       DECFSZ  RASCNT,F
       GOTO    I2
   restore STATUS and W
       RETFIE

       ;WRITE SIMM
       ;ADDRESS IN SIMM0-2
       ;DATA IN W
       ;assumes RP0 is selected
SIMMWR: MOVWF   TEMP            ;store data in temporary location
       BCF     _T0IE           ;disable TMR0 interrupt, so that the
       MOVLW   TRISB           ;refresh does not interfere with write
       MOVWF   FSR             ;make FSR to point to TRISB, avoid bank
switching
       MOVF    SIMM2,W         ;latch lowest address byte in HC573
       MOVWF   PORTD
       BSF     _LE
       BCF     _LE
SW0:    MOVF    SIMM0,W         ;isolate bit 16 of the address
       ANDLW   0x01
       MOVWF   PORTD           ;output it on port D
       BCF     _RAS            ;activate RAS
       MOVF    SIMM1,W         ;latch middle address byte in HC573
       MOVWF   PORTD
       BSF     _LE
       BCF     _LE
SW1:    RRF     SIMM0,W         ;isolate bit 17 of the address
       ANDLW   0x01
       MOVWF   PORTD           ;output it on port D
       BCF     _W              ;activate W
       CLRF    INDF            ;make PORTB output
       MOVF    TEMP,W          ;output data on PORTB
       MOVWF   PORTB
       BCF     _CAS            ;cycle CAS - performs write operation
       BSF     _CAS
       COMF    INDF,F          ;make PORTB input
       BSF     _W              ;deactivate W
       BSF     _RAS            ;deactivate RAS
       BSF     _T0IE           ;enable refresh
       RETURN
       DW      0x3FFF

       ;READ SIMM
       ;ADDRESS IN SIMM0-2
       ;OUTPUT DATA IN W
       ;assumes RP0 is selected
SIMMRD: BCF     _T0IE           ;disable TMR0 interrupt, so that the
                               ;refresh does not interfere with read
       MOVF    SIMM2,W         ;latch lowest address byte in HC573
       MOVWF   PORTD
       BSF     _LE
       BCF     _LE
SR0:    MOVF    SIMM0,W         ;isolate bit 16 of the address
       ANDLW   0x01
       MOVWF   PORTD
       BCF     _RAS            ;activate RAS
       MOVF    SIMM1,W         ;latch middle address byte in HC573
       MOVWF   PORTD
       BSF     _LE
       BCF     _LE
SR1:    RRF     SIMM0,W         ;isolate bit 17 of the address
       ANDLW   0x01
       MOVWF   PORTD
       BCF     _CAS            ;activate CAS
       GOTO    $+1             ;wait for the data to be valid
       MOVF    PORTB,W         ;read data
       BSF     _RAS            ;deactivate RAS
       BSF     _CAS            ;deactivate CAS
       BSF     _T0IE           ;enable refresh
       RETURN
       DW      0x3FFF

The modification for 1M or 4M SIMM involves change in treatment of SIMM0.
The code should be changed as follows (not tested):

1M SIMM, SW0 and SR0:
       MOVF    SIMM0,W
       ANDLW   0x03
       MOVWF   PORTD

1M SIMM, SW1 and SR1:
       RRF     SIMM0,W
       ANDLW   0x06
       MOVWF   PORTD
       RRF     PORTD,F

4M SIMM, SW0 and SR0:
       MOVF    SIMM0,W
       ANDLW   0x07
       MOVWF   PORTD

4M SIMM, SW1 and SR1:
       RLF     SIMM0,W
       ANDLW   0x70
       MOVWF   PORTD
       SWAPF   PORTD,F



I think I may even have some AD7821s around for the asking.

The Atmel chips are IMHO much nicer devices to play with. Here's a circuit building block and software for an AVR based delay. Just expand the diagram shown to use as many bits in parallel as you need. Software is included.

http://www.uni-bonn.de/~uzs159/ddl.html

Recently, Puretube posted a link to a Japanese site that showed using an AVR to do delay and pitch shifting too.

Here's another example of using an AVR with DRAM:
http://www.myplace.nu/avr/dram/

More info still:
http://www.pjrc.com/tech/mp3/simm/simm.html

Here's an update to the app note I mentioned above from Microchip.:
http://www.tech-tools.com/files/picapp.pdf  -  Look at page 68

These are all from the first 20 Google results for the search term: pic delay dram

For anybody that wants... see pages 9-14 of this datasheet to see what DRAM access requires. http://www.oki.com/semi/datadocs/doc-eng/msm514256c.pdf

You'll quickly see why most DRAM controllers are done with FPGAs if they're not done in software.

I have fourty Signetics 74F1762 DRAM controllers here in PLCC44 packages, also free for the asking, for anybody who wants to make something out of them. I had a hard time finding a datasheet.

The hardest part for me by far is the anti-aliasing filter design.

[R.G.]

The hardest part for me by far is the anti-aliasing filter design.

We all have our own highest hills, I guess.

The statement stands - if I had found a cheap, easy to use sigma/delta ADA or a simple serial output/input ADA, or a simple, fast way to get the address counting done in a PIC, we'd already have delays made from a PIC, an ADA and a single-bit memory chip running out our ears.

The notes on DRAM and PICs (or other uCs) only reinforce it. When I find a cheap S/D converter with serial output, we'll have simple DIY delays of arbitrary length.

[Peter Snowberg]

The hardest part for me by far is the anti-aliasing filter design.

We all have our own highest hills, I guess.

The whole time I was typing I was thinking, "Shoot... I wouldn't be surprised if R.G. could put together an 11th order Butterworth or Bessel with one hand tied behind his back."

When I find a cheap S/D converter with serial output, we'll have simple DIY delays of arbitrary length.

OK, so to make the transition quickly and easily from cheap delta-sigma A/D to parallel and back to serial for the D/A, I would suggest the 74HCT299 universal shift register because it has a 3-state output and can do the job of SIPO or PISO.

Otherwise... the 74HCT164 would do for the input, a 74HCT244 or HTC245 or better yet a HCT373/HCT573 would be needed for 3-state control, and finally a 74HCT165 would convert things back to serial. All chips mentioned above are in current production. For 16 bits it's just a matter of using two shift registers on either end and for 24 bits it just means using three shift registers.

For cheap delta-sigma chips I would suggest the Wavefront AL1101 & AL1201, however there are zillions to choose from these days.

For timing with the Wavefront chips, a bit clock is needed which runs at the sample rate X64. A simple counter made from a 4040 or other counter with a 12.288MHz oscillator driving it would do fine. Clock the shift registers with the bit clock, connect the parallel "load" lines to the bitclock/64, and there you go.

At this point we've reduced the demand on the PIC considerably. We have a converted value at whatever resolution you want to deal with from 8 to 16 to 24 bits long, and the PIC doesn't even see or care about the data. That ADA won't do 24 bits, but with careful layout you can squeeze at least 19 bits out of it... maybe more.

This topology is good for straight delays, but not so good for reverse delays or pitch shifting because with those effects you really need to average the "seam" between ends of the buffer data.

I think we'll be seeing more and more of this type of stuff... and soon.

There is also the PT2395.... that digitizes with 1 bit resolution at either a 250 or 500KHz sample rate. The same S/P/S conversion would allow for the use of old SIMMs or DIMMs with some additional fuss but there is an easier way.

A good DIY delay with a long buffer is one of the final frontiers that I haven't seen tackled yet.


Ton, I have the 11 page datasheet for the 2395. I'm guessing that this would be the "large" one.

[puretube]

Peter: right!....

btw.: thanx for all that info.... will get me busy - hope to get the Princeton samples soon (asked for PT2361, too - be they out of production or not -).

:wink:  

but now on with my loving wife Gerti`s birthday party/celebration....

[R.G.]

to make the transition quickly and easily from cheap delta-sigma A/D to parallel and back to serial for the D/A,

No need to do that at all. Since we're practically drowning in RAM these days, either use a Nx1 DRAM, or only use one bit of a wider RAM. That's the point of using serial in/out ADAs - it makes the delay easy, and gets the controller and any glue logic out of the signal path entirely. That's one good reason for using sigma/delta - it's inherently a serial conversion technology.

[R.G.]

OK, so it may have changed since I looked last time.:?

The TLV320AIC23 might well do what we need. It takes audio in from a line input, filters it, does sigma/delta A-D, outputs the signal to a serial digital output, reads the input from a serial digital input, and then reconverts to analog, filters, and outputs to line or headphone amp.

It's about $3 in 1K, probably $6 in units if units can be bought anywhere.

The key here is that the output mode looks like it is possible to spit it into a single bit RAM, delay it, and read it back in, no funny mode, channel, or addressing bits to mess with.

A theoretical block diagram is TLV320AIC23 => 1M DRAM => TLV320AIC23, with programming generated by a PIC. It looks like it might need a FPLA to do the addressing at speed though, as it's inherently 16 bit, so your delay memory is 1M/32 = 32K locations. Bigger memories are entirely feasible, as well. Static memory might work, at higher cost and get past the RAS/CAS stuff so you could just use programmable dividers and let the PIC set the size of the delay loop automagically.

Lotta design hacking to go from there, but it's possible.

[puretube]

what would you prefer for reading (delaying) backwards purposes:

serial or parallell data?