A Possible Eureka Moment

Big Indian Little Indian – Why slap my Papoose!

I think I have an answer to the Dynamic RAM write problem. This is going to get complicated and it hasn’t been verified yet. But, it looks to be a very curious and possible solution.

Let me first explain the problem. The driver that I’m using for the DRAM was written by another. The data transferred is in 32 bit wide segments. To discriminate the data into an 8 byte data segment I used address lines 15-2 for the DRAM address and A1-A0 to pull out the 8 bit data (4 8 bit blocks in a 32 bit data word). This is simple enough and assuming the driver works as I thought, all would be well.

But, what I was getting was data coming in in places where it shouldn’t be in th 32 bit field. For instance trying to read data bits 16-23 would read back on bits 8-15. Things weren’t coming back correctly. I thought I found a solution on the read function by re-sequencing the data read in a case statement. This worked fine but I still couldn’t explain it. When I got to the write function, things really got strange. I was reading data that wasn’t even in the blocks I was reading in. Then when I wrote the data out, it was in the wrong locations. Arrrg.

RTFM – Read the F’ing Manual

I had some free time today so I glanced at the datasheets for the Dynamic RAM on the DE-1 board. I found that the original author was using a 2 word data burst mode. This means that 2 16 bit data words will appear on the bus in a 2 clock sequence. Now here’s the kicker. In 2 word burst mode the A0 bit determines the order in which the data comes in sequentially. Since I’ve been sending A1 from the CPU as A0 to the RAM, the burst would change the order of the data every other word.

OK, I know this is complicated but now that I see this, it makes sense. This also explains why in the original authors test code he/she increases the address by 2. This forces the A0 to always be at zero (reset starts the address at 0) – All even addresses.

The fix would be to fix A0 to 0 in my address pass to the driver. This needs to be tested but we’ll see. If this doesn’t work, I’m going to change the driver initialization to use Burst mode 1 which sends one 16 bit word at a time.

..and away we go --- TESTING!!!! Wooo Hoo

Sunday, August 11, 2013

"DRAM DRAM - Oh Tatoo, you're so funny"

The SOCoCo-80 Project

The SOCoCo-80 Project

DRAM is a Tough Nut to Crack

Dram operation

Well, it’s been a few weeks since my last post. I haven’t forgotten about the project. I had a few life bumps to deal with. That being said (or typed in this case), I have made some strides with the project. As I mentioned before, this project is going to happen in phases. Phase one was to develop a working SOC using a 6809 model as it’s CPU template. Phase two will be a hardware component for the Color Computer. I’m still on phase one.

The video uses the SDRAM of the DE-1 board. Dealing with the timing between the CPU and the video is not for the faint at heart. I decided to use the Dynamic RAM (DRAM) for the CPU. DRAM unlike SRAM has to be processed by a procedure sequence. This process includes initialization, read access, write access and refresh. There’s also burst functionality and bus width problems to deal with.

In my search for an easy solution nothing I tried fit until I came across a small test module by someone named lsilvest. He/She wrote a three part module that tests the DRAM on the de-1 board. I used one of his/her modules as a driver base. Then I wrote my own interface core. This core seems to work except I’m having some issues with the write cycle. I hope to have those issues cleared up soon.

One thing about using DRAM is that because it’s a “procedural” device, I have to slow the CPU way down to allow the RAM to go through its motions. The DRAM root frequency is 133.3MHz. The controller has to allow for clock cycles to complete tasks. The interface controller is then running at 50MHz to allow the DRAM controller to do it’s thing. Now, to interface with the CPU, I have to run the CPU even slower to allow the interface module to do its thing. I haven’t determined what speed I can run the CPU at yet but it looks like it’s going to be around 12MHz or so. We’ll see. Once I get the CPU running fully with DRAM and after I get the video linked to the CPU, I will return to the DRAM driver and make it work more efficiently. This, hopefully, will allow the CPU to run faster.