dram schematic showing banks

Did you google the part number of the DRAM chip ??

I bet the data sheet will tell you all you need to know.

donald

Sure did Don. And it came up empty.

014400MT1D 70 8186186 IBM 14 70 P19W08JY PQ

is the label.

I can find similar datasheets for similar equivalents, and I've reviewed them. There are no application diagrams, and no discussion whatsoever of using multiple memory chips in banks.

Unless the information is hidden in the timing diagrams, what I can find is coming up short.

Thanks

Keith

You need to look at data sheets for DRAM controllers.

You will need to warm up the time machine a little bit and set it for

20 years ago.

Keep in mind that many machines of the era used either off the shelf DRAM controllers, or used their own ASICs for the job. The Commodore

64 used the video chip as the DRAM controller. In the Amiga, wasn't it AGNUS' job? In other words, you won't be able to trace out the logic because it's all in a chip somewhere. Reverse engineering a board will just show you that the meat of the job was done in the computer.

I think the Z80 had built-in DRAM control as well. The original PC had an entire chipset to support the 8080, there must have been a DRAM controller in there somewhere too.

Also, you can just walk in to your local university and talk to a librarian and ask where the EE section is; they can also help you locate textbooks and reference materials. I do it all the time when tootling around inside my 40-50 year old electronics. Old data books and textbooks from the era help a lot.

Look up old DRAM controller data sheets.

Draw two rows of eight memory chips.

Tie RAS of the first row together (RAS0). Tie RAS of the second row together (RAS1).

Tie CAS of the first pair of chips in both rows together (CAS0). Tie CAS of the second pair of chips in both rows together (CAS1). Tie CAS of the third pair of chips in both rows together (CAS2). Tie CAS of the fourth pair of chips in both rows together (CAS3).

It's funny that you sent me to QuickLogic. It just so happens that the RAM board I'm using has a QuickLogic controller on it. I think technically it's a pASIC1, which was/is an FPGA, I'm guessing loaded with some DRAM controller configuration. Off the shelf or custom, I don't know.

Right. Well I'm just poking around at the feasibility of replacing the DRAM controller or making a small RAM board to interface to the controller. I honestly think it's over my head and a time/money sink, but it's the journey and not necessarily the destination that I'm interested in. The correct chips needed for the upgrade are pretty rare, so I'm sort of changing gears.

I'm contemplating replacing the suggested (8) 1M x 4-bit chips with a single 1M x 32-bit module. And maybe using SRAM instead of DRAM. If you get rid of the refresh junk, then I think the task of the memory controller gets much simpler:

Just translate the incoming CPU memory-mapped address range into addresses that the memory chips use. No RAS/CAS to worry about. No rows and columns.

I need two of those 1M x 32-bit modules --- so use the MSB of the incoming address or something to define which module we communicate with.

Reversing the layout of the chips tells me how to interface to the existing controller, if that's the plan. It tells me there are (2) OE busses, 2 RAS busses, a common address bus, and that for whatever reason, the 16 chips are paired up two by two with a separate CAS line for each of the two chips. The pairing seems illogical -- about the only things I can deduce are that the CAS pair partner is always on the same RAS bus, and that the CAS pair partner is always in the same bank. Oh, and that half of bank 1 is on one RAS bus, and half of bank 2 is on the other.

Thanks for the helpful response.

Keith

If anyone is interested, here's my rough (very rough) schematic of the RAM board I've been playing with.

The chip numbers are completely arbitrary --- I tried numbering them in "order" but the layout of the board is a little goofy.

The CP X numbers on the bottom indicate the "CAS Partner" which means that the CAS pin on that chip is connected to the CAS pin on the partner chip. They both would be connected to a pin on the dram controller.

Last but not least disclaimer, the actual data bits that leave the memory chip on a read, and head towards the '030, are probably not correct as listed. I simply started at chip 1, and assigned databits 0 through 3, chip 3 gets databits 4-7, and so on.

I think that if I renumber some of these chips, their layout may approach Andy's above.

Thanks

Keith

I played around with renumbering the chips, and all makes sense now.

If you'd see how the chips were actually numbered vs their layout on the board, it was pretty crazy. One row of chips were numbered in order, one row skipped two numbers, and the third row is mixed up.

So I ended up with all (16) chips sharing Vcc, Vss, 9-bit address bus, and the write pin. Two banks total, each with their own OutputEnable bus. There were two RAS busses, with half of each bank on each RAS bus. Last but not least, two pairs of two chips on the same bank on the same RAS bus are paired together for CAS. So there are 8 separate CAS busses.

This stuff is neat. :)

Thanks

Keith

None of the ones i used ever did. Nor did the other early uPs.

On the original IBM PC and XT the DRAM controller was discrete logic. They also used the Intel 8088 and its support chips, a DMA controller an interrupt controller, a timer/counter chip, an 8048 preprogrammed to interface to the keyboard, a serial port chip and a parallel port chip. They provided the schematics back in the day. You could find them with a search engine.

Naw, you could do it with a couple of 22V10's

It was about the early to mid 1990's that they moved the refresh logic onto the DRAM chips themselves. Now all you need is an address mux, a delay, and a couple gates to generate RAS/CAS.

That is a pretty standard organization for the day. It was mostly a matter of fanout leveling.

No, it wasn't. The DMA controller was used as the DRAM controller. It was set up to read sequential memory locations, which guaranteed refresh at the cost in memory performance.

Not then. ;-)

--
Keith