Forum unknown
· Hardware
#Memory Expansion
11 messages in this thread
Right Scotty, that'll be no problem, as is all goes well, we will be sure to
be ready, so we'll just do nothing. (XRDY being pulled causes a wait)
Let me get this straight. If I guarantee that my board is fast enough, I
have to assert neither dtack* or Xrdy, and the Amiga will run at full speed.
If I am, for example, in the middle of a refresh cycle, I should pull XRDY to
ground until I am ready to deal with the addressing… But when should I let
loose of XRDY? /frank
look in the 68000 book. XRDY is basically an inverted DTACK*. i think you
should let go of XRDY once you have begun your memory cycle (ie, RAS* has
gone to the RAMs). –Scotty
I would think that if you are in the middle of a refresh cycle, and the CPU
has asserted AS*, then you must do a little more than just allow things to
"just happen". The problem is that by the time you are done your refresh, the
CPU is liable to be in "wait" clock cycles. As soon as you let go of XRDY,
the CPU will proceed to S6, and at the falling edge of S6, will expect data
to be valid. I think, therefore, you will have to "fake" a full cycle, gating
the address lines, etc, and let go of XRDY at the appropriate time (as if it
was never asserted, but giving the data time to be there.).
We are currently looking at the feasibility/cost of a DRAM controller.
Simplifies things a LOT! There is a TI chip for 64K memories available for
about $15.00 US, and I know there is a 256K equivalent, so we are checking
that angle out. In the 64K implementation, it is possible to get by with the
RAMs and the controller only. The example in the data book shows a 256K
memory organized as two banks of 128K * 16.
If XRDY is just dtack* inverted, then I think I can deal with it properly.
If XRDY is just dtack* inverted, then I think I can deal with it properly.
well, i think i've come up with a circuit that will allow hidden refresh
after any AS* cycle, and will do it's own refreshing when the bus is
inactive, but will only "manually" refresh those addresses which haven't been
hit by the automatic refresh in the last 4 ms. according to the databooks i
have here, i'm doing everything the way a 150ns RAM would want to see it plus
about 20 ns. read-modify-write handling is what i'm working on now. the
timing generator for this thing (the part i'm real proud of, being a software
type) takes the 14M line and synchronizes it to the falling edge of AS* so
that we will drop RAS* on the RAMs (if we're not doing a "manual" refresh)
within 35ns of AS* going active. the other timing is generated by shifting a
gated version of AS* through a bunch of 74S175 quad-d flip flops, two of the
chips clocked with one edge of my synched 14M, two clocked with the other, so
i get an effective switching rate of 28MHz for timing signals, even though no
given line is going faster than 14Mhz. once i'm happy with it on paper, i'm
gonna start scrounging around for connectors and boards and stuff so i can
wirewrap parts of the timing logic and see how it behaves on the bus. gotta
borrow a scope from someone!!! –Scotty
well, i think i've come up with a circuit that will allow hidden refresh
after any AS* cycle, and will do it's own refreshing when the bus is
inactive, but will only "manually" refresh those addresses which haven't been
hit by the automatic refresh in the last 4 ms. according to the databooks i
have here, i'm doing everything the way a 150ns RAM would want to see it plus
about 20 ns. read-modify-write handling is what i'm working on now. the
timing generator for this thing (the part i'm real proud of, being a software
type) takes the 14M line and synchronizes it to the falling edge of AS* so
that we will drop RAS* on the RAMs (if we're not doing a "manual" refresh)
within 35ns of AS* going active. the other timing is generated by shifting a
gated version of AS* through a bunch of 74S175 quad-d flip flops, two of the
chips clocked with one edge of my synched 14M, two clocked with the other, so
i get an effective switching rate of 28MHz for timing signals, even though no
given line is going faster than 14Mhz. once i'm happy with it on paper, i'm
gonna start scrounging around for connectors and boards and stuff so i can
wirewrap parts of the timing logic and see how it behaves on the bus. gotta
borrow a scope from someone!!! –Scotty
I would think that if you are in the middle of a refresh cycle, and the CPU
has asserted AS*, then you must do a little more than just allow things to
"just happen". The problem is that by the time you are done your refresh, the
CPU is liable to be in "wait" clock cycles. As soon as you let go of XRDY,
the CPU will proceed to S6, and at the falling edge of S6, will expect data
to be valid. I think, therefore, you will have to "fake" a full cycle, gating
the address lines, etc, and let go of XRDY at the appropriate time (as if it
was never asserted, but giving the data time to be there.).
We are currently looking at the feasibility/cost of a DRAM controller.
Simplifies things a LOT! There is a TI chip for 64K memories available for
about $15.00 US, and I know there is a 256K equivalent, so we are checking
that angle out. In the 64K implementation, it is possible to get by with the
RAMs and the controller only. The example in the data book shows a 256K
memory organized as two banks of 128K * 16.
look in the 68000 book. XRDY is basically an inverted DTACK*. i think you
should let go of XRDY once you have begun your memory cycle (ie, RAS* has
gone to the RAMs). –Scotty
Let me get this straight. If I guarantee that my board is fast enough, I
have to assert neither dtack* or Xrdy, and the Amiga will run at full speed.
If I am, for example, in the middle of a refresh cycle, I should pull XRDY to
ground until I am ready to deal with the addressing… But when should I let
loose of XRDY? /frank