Forum unknown
· Hardware
Memory Expansion
23 messages in this thread
I need a point of clarification here – You were pointing out that the ONEMEG
board in the DL's abuses DTACK*. Could you be a little more specific as to
what the abuse is? I'm also designing a board for my AMIGA. OKI had a
special deal on 256Kx9 RAM Modules a couple of months ago. I got 3 MB for
$280, and they will all fit on a 4"x4"x1" section of board. With all that
memory, The decoding and driving is just a bit trickier than the ONEMEG
board. My two cents on the ONEMEG board is that a wait state is OK, but his
casual mixing of 'LS and 'HC logic is dangerous. With the 68000's two-word
prefetch queue, linear fetches (opcodes, immediate data) will not be slowed,
but program jumps, and other data fetches will be. I got the impression that
you were going to do refresh much more often on your board than necessary
(like every cycle…). I would strongly suggest that you look at the
differences in power consumption between active mode and standby mode on the
DRAM's. An order of Magnitude can seriously affect design decisions. My
refresh scheme is based on an Application Note from Motorola (AN897), though
I've had to do some stretching to make it fit 12 banks of RAM rather than 1
bank, which they had. In essence, a counter divides the 7.16 MHZ clock down
and causes a refresh request every (3.4 mS)/(256 cycles). It then waits for
AS to become inactive, and runs a refresh cycle. Note also that you are
guaranteed 90 nS between asserting DTACK and the requirement that data be
valid. BTW, I'm a part time HW designer for Huge Aircrash in SoCal, but this
is my first experience with DRAMS.
the problem with using DTACK* is that the amiga expansion docs specify that
it is driven by a TTL line in the amiga – not tristate or open collector, so
THOU SHALT NOT DRIVE DTACK*. unless, of course, you also drive OVR*, which
supposedly disables all signal driving in the amiga and essentially takes the
68000 off line. they say to contact them for further info if you wish to use
OVR*. what you should do is use the XRDY line (pull it low within 60 ns
after you see AS*) and logic in the amiga translates that to DTACK*. –Scotty
the problem with using DTACK* is that the amiga expansion docs specify that
it is driven by a TTL line in the amiga – not tristate or open collector, so
THOU SHALT NOT DRIVE DTACK*. unless, of course, you also drive OVR*, which
supposedly disables all signal driving in the amiga and essentially takes the
68000 off line. they say to contact them for further info if you wish to use
OVR*. what you should do is use the XRDY line (pull it low within 60 ns
after you see AS*) and logic in the amiga translates that to DTACK*. –Scotty
Frank, you have raised some good points in your message, and I appreciate the
feedback. I feel that the more ideas kicked around here, the better we can
make this thing work. The comment about DTACK* was because of information
provided by Amiga that states that they pull DTACK* internally unless you
pull XRDY yo tell it you are waiting. They specifically state that DTACK*
should neither be driven nor be used to drive anything. Your other points are
certainly worth noting, and I don't want to answer any of them until I take
another look at your message with the books in hand, so I'll do that and get
back to you. Sure would like to have been aware of that special. It would
save a lot of trouble with space and wiring. Regarding the refresh, we are
currently leaning toward hidden refresh, as it looks like there is enough
time for it. One of the main considerations for this project will be to not
only make a reliable memory, but one that will be such that a hadware hacker
with minimal experience will be able to put one together without having to
get out a scope and twiddle with it. My background is 20 years of fixing
large system CPU's and peripherals, perhaps not the best background for this
project, but I have always had a way with "getting it to work" after the
designers were finished with it.
Thanks for the info, Larry. Do you know the name/number of someone to talk
to at Los Gatos about the hardware specs? (Aside to Don: Thanks for your
reply, also. I did call CBM on Friday, and Bernadette said that they had
just found several of the registration cards from different people, and mine
was one of them, so my manual should be on the way. She claimed to know
nothing, however, about updates to manuals, including the HW manual).
Be careful about hidden refresh, Larry, because it leaves valid data on the
data lines while the refresh is occurring. I'm pretty sure you'll either have
to disable the data buffers while doing so, or delay xrdy. You may want to
look into some other manufacturers DRAMS. I know that the Texas Instruments
DRAMS allow a CAS-Before-RAS refresh mode that may save several chips. (My
OKI DRAMS do not have this option).
One last question. I'm on the final legs of my design here, and I need to
know about XRDY. Is it active high or low, and does it need to be driven
with OC or Tri-state buffers?
Frank, I don't want to go to any special DRAMs, as then the advantage of ease
of parts procurement disappears.
The hidden refresh does leave data valid while it is going on, but from the
figuring we did Friday, it looks like we will be done in time, and that we
can, if worse comes to worst, use tristate buffers on the input and disable
them during S7 – S1.
Can't remember who the lady to talk to at Los Gatos was, I got the name here
from someone else who had already got the package. The number (I think) is
(408) 395-6616
XRDY — "Our internal circuitry will pull DTACK* unless the slave pulls XRDY
low."
Sure wish I had this all in machine readable format so I could get it all to
you, but there is a LOT to put in.
In most of the 256K x 1 DRAMs I've encountered, including the TI and Hitachi
parts, CAS before RAS and Hidden Refresh work very similarly. Both of these
use internal address counters for refresh. I know some other parts, like the
64K x 1 and 64K x 4 don't support CAS before RAS and that their version of
hidden refresh also requires a refresh address. But if you find CAS before
RAS refresh common enough, I'd recommend it and its associated hidden style
— saves lots of part and simplifies fast timing alot.
What's your experience with custom DRAM controller Hazy? We were looking at the
TMS4500 as an example, and though it is for 64K chips, we thought it might be
worth doing with their 256K version.
Most of the DRAM controllers I've used are something very custom, like the
VIC chip. I do know a bit about some of the controllers, at least in
general. They make an effort to give you most of the functionality of static
RAM, doing refreshes whenever the RAM isn't used. The 4500A actually does
your address multiplexing for you as well, and is driven from the system
clock and a chip select. It can be programmed for various refresh rates and
styles, and will hold off the processor if necessary. A 256K version sounds
really nices, especially if it gives you a reasonable amount of time for RAS
or CAS based bank selection. TI also makes some simpler controllers,
74LS600-74LS603, which do very much what the 4500A can do, but require you to
provide your own multiplexed addresses. These are designed for
transparent/burst operation or for a cycle-stealing operation for which the
Amiga might be a bit too fast. These come in 20-pin packages, but again only
manage 64K memories.
Most of the DRAM controllers I've used are something very custom, like the
VIC chip. I do know a bit about some of the controllers, at least in
general. They make an effort to give you most of the functionality of static
RAM, doing refreshes whenever the RAM isn't used. The 4500A actually does
your address multiplexing for you as well, and is driven from the system
clock and a chip select. It can be programmed for various refresh rates and
styles, and will hold off the processor if necessary. A 256K version sounds
really nices, especially if it gives you a reasonable amount of time for RAS
or CAS based bank selection. TI also makes some simpler controllers,
74LS600-74LS603, which do very much what the 4500A can do, but require you to
provide your own multiplexed addresses. These are designed for
transparent/burst operation or for a cycle-stealing operation for which the
Amiga might be a bit too fast. These come in 20-pin packages, but again only
manage 64K memories.
What's your experience with custom DRAM controller Hazy? We were looking at the
TMS4500 as an example, and though it is for 64K chips, we thought it might be
worth doing with their 256K version.
Sorry to tell you this, Hazy, but at least the OKI parts that I have do not
seem to support CAS before RAS refresh. I don't have the data sheet on the
individual RAMs, just a really hokey xerox of a data sheet on the modules.
BTW, TI's DRAM controller for 256K DRAMS is the 4502A, and it *does* seem to
simplify many of the aspects of building this board. I want to tackle mine,
though, as an exercise in stupidity by building it from the ground up myself.
/frank
CAS before RAS is a nice feature, but since I mentioned it I've found a few
more who support it and a few who don't, so if you want to be safe its
probably better not to use it. The DRAM controllers look really nice if you
want a good and fast solution, though you'll learn more doing the refresh
design on your own, and it might turn out to include more readily available
parts. Though I think it would be fun to try and build a board that runs
fast enough to support CAS before RAS or hidden refresh; I may try it this
way if I can get enough time to do a board on my own before someone offers to
sell me a proven PC that I can stuff in a lunch hour and not have to worry
anymore.
Yeah, Dave, I understand the concept of learning more by designing my own
DRAM controller, But I've been at it on and off now for several weeks. I've
gotten to the point several times that I feel I could build it and have it
work, but then I look at the chip requirements and levels of delay and get
kind of discouraged. I have reached the point where I have learned much
about DRAMs now, and am willing to let someone else do the hard work. By the
way, The TI DRAM controllers aren't that hard to get, and believe me, they
greatly simplify the whole process. Part of what Larry and I were trying to
do is design something that was fairly bulletproof and easy to build for the
average knows-what-end-of-the-soldering-iron-to-pick-up type. Thanks for the
help, /frank
I finally found a data sheet on the 4502A controller. It really would
simplify things alot, while keeping the design within the grasp of the
general Amiga community's ability to duplicate. When I first got interested
in doing a board, I imagined I'd use mainly PALs. But that would be very
difficult for some to copy, unless I sold them the PALs. I haven't looked at
it for about two weeks, but I have a controller circuit in about 4 packages
that'll just make the /CAS before /RAS or hidden refresh. If I ever get a
schematic, I'll post it here, though I don't know if I'd be able to provide a
PCB. Though if you guys come up with a board sooner, you just might remove
my interest in this project altogether — the driving force is that I NEED a
few megabytes and I haven't found a commercial unit that I can afford.
Anyway, I'm glad to see the technical level of folks interested in the Amiga.
I finally found a data sheet on the 4502A controller. It really would
simplify things alot, while keeping the design within the grasp of the
general Amiga community's ability to duplicate. When I first got interested
in doing a board, I imagined I'd use mainly PALs. But that would be very
difficult for some to copy, unless I sold them the PALs. I haven't looked at
it for about two weeks, but I have a controller circuit in about 4 packages
that'll just make the /CAS before /RAS or hidden refresh. If I ever get a
schematic, I'll post it here, though I don't know if I'd be able to provide a
PCB. Though if you guys come up with a board sooner, you just might remove
my interest in this project altogether — the driving force is that I NEED a
few megabytes and I haven't found a commercial unit that I can afford.
Anyway, I'm glad to see the technical level of folks interested in the Amiga.
Yeah, Dave, I understand the concept of learning more by designing my own
DRAM controller, But I've been at it on and off now for several weeks. I've
gotten to the point several times that I feel I could build it and have it
work, but then I look at the chip requirements and levels of delay and get
kind of discouraged. I have reached the point where I have learned much
about DRAMs now, and am willing to let someone else do the hard work. By the
way, The TI DRAM controllers aren't that hard to get, and believe me, they
greatly simplify the whole process. Part of what Larry and I were trying to
do is design something that was fairly bulletproof and easy to build for the
average knows-what-end-of-the-soldering-iron-to-pick-up type. Thanks for the
help, /frank
CAS before RAS is a nice feature, but since I mentioned it I've found a few
more who support it and a few who don't, so if you want to be safe its
probably better not to use it. The DRAM controllers look really nice if you
want a good and fast solution, though you'll learn more doing the refresh
design on your own, and it might turn out to include more readily available
parts. Though I think it would be fun to try and build a board that runs
fast enough to support CAS before RAS or hidden refresh; I may try it this
way if I can get enough time to do a board on my own before someone offers to
sell me a proven PC that I can stuff in a lunch hour and not have to worry
anymore.
Sorry to tell you this, Hazy, but at least the OKI parts that I have do not
seem to support CAS before RAS refresh. I don't have the data sheet on the
individual RAMs, just a really hokey xerox of a data sheet on the modules.
BTW, TI's DRAM controller for 256K DRAMS is the 4502A, and it *does* seem to
simplify many of the aspects of building this board. I want to tackle mine,
though, as an exercise in stupidity by building it from the ground up myself.
/frank
In most of the 256K x 1 DRAMs I've encountered, including the TI and Hitachi
parts, CAS before RAS and Hidden Refresh work very similarly. Both of these
use internal address counters for refresh. I know some other parts, like the
64K x 1 and 64K x 4 don't support CAS before RAS and that their version of
hidden refresh also requires a refresh address. But if you find CAS before
RAS refresh common enough, I'd recommend it and its associated hidden style
— saves lots of part and simplifies fast timing alot.
Frank, I don't want to go to any special DRAMs, as then the advantage of ease
of parts procurement disappears.
The hidden refresh does leave data valid while it is going on, but from the
figuring we did Friday, it looks like we will be done in time, and that we
can, if worse comes to worst, use tristate buffers on the input and disable
them during S7 – S1.
Can't remember who the lady to talk to at Los Gatos was, I got the name here
from someone else who had already got the package. The number (I think) is
(408) 395-6616
XRDY — "Our internal circuitry will pull DTACK* unless the slave pulls XRDY
low."
Sure wish I had this all in machine readable format so I could get it all to
you, but there is a LOT to put in.
Thanks for the info, Larry. Do you know the name/number of someone to talk
to at Los Gatos about the hardware specs? (Aside to Don: Thanks for your
reply, also. I did call CBM on Friday, and Bernadette said that they had
just found several of the registration cards from different people, and mine
was one of them, so my manual should be on the way. She claimed to know
nothing, however, about updates to manuals, including the HW manual).
Be careful about hidden refresh, Larry, because it leaves valid data on the
data lines while the refresh is occurring. I'm pretty sure you'll either have
to disable the data buffers while doing so, or delay xrdy. You may want to
look into some other manufacturers DRAMS. I know that the Texas Instruments
DRAMS allow a CAS-Before-RAS refresh mode that may save several chips. (My
OKI DRAMS do not have this option).
One last question. I'm on the final legs of my design here, and I need to
know about XRDY. Is it active high or low, and does it need to be driven
with OC or Tri-state buffers?
Frank, you have raised some good points in your message, and I appreciate the
feedback. I feel that the more ideas kicked around here, the better we can
make this thing work. The comment about DTACK* was because of information
provided by Amiga that states that they pull DTACK* internally unless you
pull XRDY yo tell it you are waiting. They specifically state that DTACK*
should neither be driven nor be used to drive anything. Your other points are
certainly worth noting, and I don't want to answer any of them until I take
another look at your message with the books in hand, so I'll do that and get
back to you. Sure would like to have been aware of that special. It would
save a lot of trouble with space and wiring. Regarding the refresh, we are
currently leaning toward hidden refresh, as it looks like there is enough
time for it. One of the main considerations for this project will be to not
only make a reliable memory, but one that will be such that a hadware hacker
with minimal experience will be able to put one together without having to
get out a scope and twiddle with it. My background is 20 years of fixing
large system CPU's and peripherals, perhaps not the best background for this
project, but I have always had a way with "getting it to work" after the
designers were finished with it.