"It's a Lattice PLD. It performs a bunch of simple glue logic/muxing, and is primarily there to latch/increment the SRAM address. It needs to perform operations at single clock cycle speeds, so a propeller would have been too slow, more expensive, and would have had insufficient I/O"
@Praxis
David,
I envisage a write cycle something like so.
Write_long mov outa,adr 'Write ADR, and latch.Propogation delay allows data to settle
muxz outa, clr_adr_le 'Set gates
mov outa, data 'Write low order word
muxz outa, clr_low_le 'Set gates
shr data, #16
mov outa, how 'write high order word not latched, gates are open
ret
Now I really am shooting from the hip. I got a few hours again today to look at the gating, its far for sorted. Hopefully if I don't get bogged down
with boat stuff I will get a few hours tomorrow and we might have something to look at.
But its tight. The read cycle adds to extra instuctions because we need to toggle DIRA (aka muxnz dira, low_mask)
I have provided a Layout·for the latches, the layout shows only the 16 Bus Pins and 4 other control lines to Prop. a total of 20 lines used.
Other·gating logic is derived from the four control lines.
The four ctrl lines plus·the not latched·Ram paging lines attach to Prop. During·a write the 16 bus pins are·obviously outputs. During read·after the adr lines have been latched the 16 pins are set to inputs to read the long in two fetches. The 16 pins then revert to outputs before commencing a new read or write.
I hope that it makes sense to those interested. I should get the other logic done·today.
Yikes its 2am. Maybe I am not making any sense, just think I am!
How do you get more address bits? I have several paragraphs of ideas on how to optimize
the hardware/software for your 16 bit method, but I only see 16 address bits. At this point
it seems you need 2 more instructions for another latch (or d-flip-flop).
Steve you can add however many paging pins you like. They dont need to be latched. There is nothing else going on lines above 0..15. Only 16 are muxed because·they are bi-directional·and carry data too. ·We can move the control lines anywhere they do not have to follow the 16 bit wide bus, if you want to run other Ram paging pins along side. the exit latched bus thas fine.·Further down the track I will make provison for that and move the ctrl up a few pins.
Ron
Post Edited (Ron Sutcliffe) : 6/3/2009 6:50:53 PM GMT
Ok, I think I have a method that will require 18 propeller pins and two 16 bit latches for the same amount of memory. It will require a d-flip-flop, a 10MHz crystal and buffer though. Should deliver 13MB/s write and 10MB/s read. Using 2 more propeller pins gets you 1MB SRAM. I'll post it later. Go get some sleep Ron.
I was thinking about building on your previous design. Consider these routines:
Write_long
mov outa, adr ' Write ADR (also ALE* and WE* to 0) ... assuming 16 bits for now
or dira, data_adr_ale ' Now latch with ALE* and set DLE* "always @(posedge _10MHz) DLE* = #1 ALE*;"
mov outa, data ' Write low order word
or dira, we ' now DLE* goes low SRAM OE* asserts ... assert WEN that has 1.2K pull-up
shr outa, #16 ' set rest of 16 bit data
andn dira, we_ale ' write data, then release WE and ALE*
ret ' 11MB/s
Read_long
mov outa, adr ' Write ADR (also ALE* and WE* to 0) ... assuming 16 bits for now
or dira, data_adr_ale ' Now latch with ALE* and set DLE* "always @(clk5MHz) DLE* = #1 ALE*;"
and dira, kffff ' set bus for read
mov data, ina ' now DLE* goes low SRAM OE* asserts
shl data, #16 ' shift first data to make room for rest
or data, ina ' get rest of data
andn dira, ale ' release ALE*
ret ' 10MB/s
Most of this should be clear. I hope the schematic pops out at you. Some notes incase.
Address bits A[noparse][[/noparse]15:0] are latched. Data D[noparse][[/noparse]15:0] are latched. ALE* and WE* + 16 = 18 bits.
ALE* and WE* are both pulled up with 1.2K resistors.
One problem I see that also hit me is the need to disable the SRAM output during the address cycle.
I thought I could get away with using series resistors, but that introduced too many "analog" dependencies.
A delayed ALE* by on 5MHz buffered crystal clock any edge (or DLE* data latch enable) can double as an
output enable for read and your data latch. SRAM OE* does not need to be disasserted during writes.
Need to check timing of clock in relation to 2 executing PASM instructions. 10MHz posedge would be
required for non-CPLD glue. Please check all this!
A method for setting the latch bit(s) in the first place is also necessary. This can be done at the end of
read/write (init sets ALE* the first time). You need one more instruction before ret on write anyway to
terminate the write strobe (that could be started with the data latch).
Steve
Thanks I will have to digest your last post after a long walk.
Feel free the push it along. Just to make sure we are thinking about the same sort of latch, see layout.
Hoping there is enough delay across the ALE inverter for the data to have settled when ...mov outa outa, adr+the ALE bit, otherwise the fix just adds more complexity.
Ron
@Steve
Given that we need to have at least one unlatched address line and a move up the 128K. I think we have to assign ctrl lines differently. W/R (Read or write), A/D (address or Data) and EO Expanded we now have 8 ctrls for the gating. A little more complex but if a CPLD was to be used its probably the way to go.
I agree that the sram OE will come into play hence the need for access to 8 CTRL functions, I can see at least five being required. ADR, RLO, WLO, RHO, WHO (LO, low order word and HO high order word).
Three is a comfortable reserve at this stage of the game. I sure don’t like the using resistors that way but it does raise the··need to protect the 16 I/O pins, Open collector output latches will be required. Faulty code would be catastrophic.
David, I confess have not given your idea much thought.
We should look at all the options, before anything is set concrete, but how much time have all got to play Prop.
It would be great to see something from you.
The latch schematic you show looks like a D-flip-flop ... I could be mistaken. I'm thinking about the '73 variation ... 74*16373 for example. Even the '73 variety needs a 1ns setup before the latch enable falls though. I believe there is 50ns of setup time in what I described though.
As far as byte lane selects go this is a case where trying to generalize a solution gets in the way of optimization.
For XMM/LMM applications, byte lane steering bits have no value ... if someone needs to write a byte a read/modify/write can be done [noparse]:)[/noparse]
It would be fairly easy to make this feature optional though. For XMM/LMM applications all byte lane bits would be asserted ... pulled low perhaps.
David,
Performance and density are the most important factors to me. Anything over 250ns just to set an address is a non-starter. At least 19 bits are needed for 512KB. I think the sweet spot for C programs will be 2M though.
@ Steve, Whaaaat?
SN74AUC163733 this is really a very low voltage low power job, not suitable but was used in the mix for starters.
Ron
Disregard above.
Sorry Steve I mis read your post, we are both thinking the same chip. Yep I saw the inverter· on·LE and thought·the progation delay might have been enough for the data to be·stable by the time it got the CLK and·I think I did mention the possibility in an earlier post. I was going to fix·but you have done it in the code. Good Job.
This is getting close.
Post Edited (Ron Sutcliffe) : 6/4/2009 3:22:35 PM GMT
Steve, or anyone else for the matter, who has followed this thread, I've been looking at this for two hours now, and its driving me nuts.
If you can see a way I can strobe the ram wrte line with the three available prop pins, Pin Data, Pin Adr, Pin Ram,(PD,PA,PR) you
are welcome to put me out of my misery [noparse]:([/noparse]
Ron
Back after some fresh air, what about a·mono stable between PR and·bar WR to allow the data to time settle?
The·extra gates·in the hex inverter are availble to generate the small·delay.
Time·to revisit your code now.
Post Edited (Ron Sutcliffe) : 6/5/2009 10:29:16 AM GMT
Ron, I'm afraid another pin will be needed for WE*. Now if you had a packet decoding CPLD, you could do more with less ... more or less.
I have a provision on the first PropXMM-D40 prototypes for using gate delay to latch addresses, but decided the idea is too unreliable.
Yep, hit the wall at 512k with 20 pins, but still not a bad result. Maybe someone will take it on and produce it.
Its provides plenty of headroom for people who want get up and running with C using VGA and serial keyboard.
Finding the extra pins for SDcard, is a problem but for those interested in Zilog and CPM a serial terminal it should be
fine (I think heater?)
Power users like yourself may decided to go with unlatched lines. Which makes me think that gating should be separated from
the memory board so that 128,256,512k memory can be implemented for those who wish to use it. Mind you I have piggy backed Sram on parallel SIPS before now and·used the bar CS line for paging.
Thanks Steve, would have taken me a while to sort it out on my own. I am very rusty having been cruising for five years.
I have another project lined up next. Not sure when I will get anything posted. No more ram projects
Ron
Post Edited (Ron Sutcliffe) : 6/6/2009 12:51:02 PM GMT
As discussed here is a circuit for a 1 mbyte x 32 bit external RAM that uses a serial interface.
It uses a minimum of 5 IO pins and a 6th pin if you want to deselect the RAM to save power.
It can be expanded up to a 24 bit address space.
I have not spent a lot of time checking it as this was knocked up while watching TV so if you find any erroneous connections let me know and I will update it
Cheers
David
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adaequatio Rei Et Intellectus
Hi David,
The next time you get a chance to watch a bit of TV, just throw in a Prop, Micro SD card, VGA and a PS2 socket in then it’s finished[noparse]:)[/noparse]
Sure the CCT can handle it, but are we not limited by the Props capacity to the drive the syncronous lines. Two longs to bit bang per transaction plus some overhead. I can't see it doing·better then·10MB/S with one cog, but there again it takes a little while for this stuff to sink in here. I need to turn the TV off to digest what you have done.
I was just re-working Steve’s code to fit with my final layout, then I will take a look at using a CPLD. I need to document it, before I put the project to bed.
It’s a been while since I have checked out the Praxis Group website.
Regards
Ron
Post Edited (Ron Sutcliffe) : 6/7/2009 1:25:52 AM GMT
I suppose only 56 bits are required per transaction not 64,·and it would be easier to implement block transfers with your system. Something which·I am considering. Its another minor change, but might be worth the effort.·My layout has not been·checked it is nothing more than a basis·for looking at·code.
Ron
Post Edited (Ron Sutcliffe) : 6/6/2009 4:25:14 PM GMT
For the circuit as drawn (1 mbyte) you only need to clock 52 bits.
I have not looked at or read up about the video generator in the prop so maybe this is a wrong assumption but would it be possible to use it to provide the clock source and perhaps the serial out data stream, if so it would reduce the software over head.
Cheers
David
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adaequatio Rei Et Intellectus
Praxis said...
I have not looked at or read up about the video generator in the prop so maybe this is a wrong assumption but would it be possible to use it to provide the clock source and perhaps the serial out data stream, if so it would reduce the software over head.
Getting the stuff out at speed shouldn't be the problem. I see more obstacles in getting it back. One cog can manage 20Mbit/s, 2 of them (2 cycle interleave) quite possibly 40Mbit/s. I say possibly as I only verified the 20Mbit/s part [noparse]:)[/noparse]
So even with a 40MBit/s solution that's only 5MB/s not counting any overheads. Is that worth the trouble?
I am not that familiar with SPI, but If you had separate SDI/SDO for each of the 74AHC299 chips It would use more pins, but wouldn't you get higher bandwidth?
Also, isn't the circuit drawn 1Mx32 or 4MB? Or maybe I am mistaken?
David, I could never see it, for the same reasons mentioned in the two posts above, but Hey, what a pity.
Having done a bit more tweaking.
The OUTA register now never changes for both read or write once initialized. The DIRA register now drives all the hardware further reducing the code by two instructions by my reckoning. (MAYBE, added in post edit)
The OE line on the ADR latch line is always tied true.
The low word OE read latch is common to ram OE, but is inverted to the low word OE write Latch.
The D read LE is inverted to D LE write.
The Ram WE, which is pulled, low is forced HIGH by the Prop WE line. Making a total on four control lines.
We now have.
OEL=OUT=L Inverted to Data OE ,
DL=OUT=L, Inverted to Data read
WE=OUT=H, Keeps RAM WE on ice
AL=OUT=L No Control is required over the ADR OE.
Ony the address latch is required.
Ron
Post Edited (Ron Sutcliffe) : 6/12/2009 2:50:48 AM GMT
Comments
That sounds fantastic. I think the 74hc299 would be too slow for what I am trying to do.
PM me when you have got it sorted.
Regards Ron
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Quote from his forum:
"It's a Lattice PLD. It performs a bunch of simple glue logic/muxing, and is primarily there to latch/increment the SRAM address. It needs to perform operations at single clock cycle speeds, so a propeller would have been too slow, more expensive, and would have had insufficient I/O"
Jim
If I recall (and that is quite a while ago) the 74HC299 could be clocked up to about 50MHz.
That would be (assuming 32 bits) around 640nS plus whatever overhead for the instructions for bit banging to read or write.
Perhaps you dig up the data sheet to confirm it.
Cheers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adaequatio Rei Et Intellectus
David,
I envisage a write cycle something like so.
Write_long mov outa,adr 'Write ADR, and latch.Propogation delay allows data to settle muxz outa, clr_adr_le 'Set gates mov outa, data 'Write low order word muxz outa, clr_low_le 'Set gates shr data, #16 mov outa, how 'write high order word not latched, gates are open retNow I really am shooting from the hip. I got a few hours again today to look at the gating, its far for sorted. Hopefully if I don't get bogged down
with boat stuff I will get a few hours tomorrow and we might have something to look at.
But its tight. The read cycle adds to extra instuctions because we need to toggle DIRA (aka muxnz dira, low_mask)
Ron
Pula Penang [noparse]:)[/noparse]
Other·gating logic is derived from the four control lines.
The four ctrl lines plus·the not latched·Ram paging lines attach to Prop. During·a write the 16 bus pins are·obviously outputs. During read·after the adr lines have been latched the 16 pins are set to inputs to read the long in two fetches. The 16 pins then revert to outputs before commencing a new read or write.
I hope that it makes sense to those interested. I should get the other logic done·today.
Yikes its 2am. Maybe I am not making any sense, just think I am!
Ron
How do you get more address bits? I have several paragraphs of ideas on how to optimize
the hardware/software for your 16 bit method, but I only see 16 address bits. At this point
it seems you need 2 more instructions for another latch (or d-flip-flop).
Oops ... re-evaluating.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Ron
Post Edited (Ron Sutcliffe) : 6/3/2009 6:50:53 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Board layout to accomodate 64k, 128k and 516k is something I have not considered. That it over the horizon for now, but
the logic is straight forward.
Maybe·I am missing something?·
Ron
I was thinking about building on your previous design. Consider these routines:
Most of this should be clear. I hope the schematic pops out at you. Some notes incase.
Address bits A[noparse][[/noparse]15:0] are latched. Data D[noparse][[/noparse]15:0] are latched. ALE* and WE* + 16 = 18 bits.
ALE* and WE* are both pulled up with 1.2K resistors.
One problem I see that also hit me is the need to disable the SRAM output during the address cycle.
I thought I could get away with using series resistors, but that introduced too many "analog" dependencies.
A delayed ALE* by on 5MHz buffered crystal clock any edge (or DLE* data latch enable) can double as an
output enable for read and your data latch. SRAM OE* does not need to be disasserted during writes.
Need to check timing of clock in relation to 2 executing PASM instructions. 10MHz posedge would be
required for non-CPLD glue. Please check all this!
A method for setting the latch bit(s) in the first place is also necessary. This can be done at the end of
read/write (init sets ALE* the first time). You need one more instruction before ret on write anyway to
terminate the write strobe (that could be started with the data latch).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Thanks I will have to digest your last post after a long walk.
Feel free the push it along. Just to make sure we are thinking about the same sort of latch, see layout.
Hoping there is enough delay across the ALE inverter for the data to have settled when ...mov outa outa, adr+the ALE bit, otherwise the fix just adds more complexity.
Ron
Is there any reason why you cannot use shift registers to do what you want i.e.
4 bidirectional SR's to handle to the data bus (32 bit) and say 3 serial to parallel SR's for a 24 bit address bus.
That would limit the prop IO usage to a serial data line, clock, address or data SR select and RW at first glance.
This would allow for a memory array of up to 16mb x 32.
The 74AC299 @3.3v can be clocked to 124mhz and 173mhz @ 5v (TA = +25°C).
Cheers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adaequatio Rei Et Intellectus
Post Edited (Praxis) : 6/4/2009 8:49:18 AM GMT
Given that we need to have at least one unlatched address line and a move up the 128K. I think we have to assign ctrl lines differently. W/R (Read or write), A/D (address or Data) and EO Expanded we now have 8 ctrls for the gating. A little more complex but if a CPLD was to be used its probably the way to go.
I agree that the sram OE will come into play hence the need for access to 8 CTRL functions, I can see at least five being required. ADR, RLO, WLO, RHO, WHO (LO, low order word and HO high order word).
Three is a comfortable reserve at this stage of the game. I sure don’t like the using resistors that way but it does raise the··need to protect the 16 I/O pins, Open collector output latches will be required. Faulty code would be catastrophic.
David, I confess have not given your idea much thought.
We should look at all the options, before anything is set concrete, but how much time have all got to play Prop.
It would be great to see something from you.
Ron
I will knock up a circuit but before that can you define some parameters for me such as;
1. Data bus width, will it be 32 bits?
2. Min/Max memory size?
3. Max read/writes per second?
4. Low power standby required?
Cheers
David
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adaequatio Rei Et Intellectus
Since you asked here is my wish list.
Pin count is an important consideration, the lower the Pin count, the more flexible a singe Prop is
I think the C power users·are looking for 1meg of external ram. Random access data 32 bit wide.
Optimized around LMM. Two-cog maximum for driver?
Can you·get close·to 10 MB/s and reduce the pin count·with true random access?
@Steve,·It's a fantastic starting point.·I got it!
Regards
Ron
Post Edited (Ron Sutcliffe) : 6/4/2009 3:26:33 PM GMT
The latch schematic you show looks like a D-flip-flop ... I could be mistaken. I'm thinking about the '73 variation ... 74*16373 for example. Even the '73 variety needs a 1ns setup before the latch enable falls though. I believe there is 50ns of setup time in what I described though.
As far as byte lane selects go this is a case where trying to generalize a solution gets in the way of optimization.
For XMM/LMM applications, byte lane steering bits have no value ... if someone needs to write a byte a read/modify/write can be done [noparse]:)[/noparse]
It would be fairly easy to make this feature optional though. For XMM/LMM applications all byte lane bits would be asserted ... pulled low perhaps.
David,
Performance and density are the most important factors to me. Anything over 250ns just to set an address is a non-starter. At least 19 bits are needed for 512KB. I think the sweet spot for C programs will be 2M though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
SN74AUC163733 this is really a very low voltage low power job, not suitable but was used in the mix for starters.
Ron
Disregard above.
Sorry Steve I mis read your post, we are both thinking the same chip. Yep I saw the inverter· on·LE and thought·the progation delay might have been enough for the data to be·stable by the time it got the CLK and·I think I did mention the possibility in an earlier post. I was going to fix·but you have done it in the code. Good Job.
This is getting close.
Post Edited (Ron Sutcliffe) : 6/4/2009 3:22:35 PM GMT
If you can see a way I can strobe the ram wrte line with the three available prop pins, Pin Data, Pin Adr, Pin Ram,(PD,PA,PR) you
are welcome to put me out of my misery [noparse]:([/noparse]
Ron
Back after some fresh air, what about a·mono stable between PR and·bar WR to allow the data to time settle?
The·extra gates·in the hex inverter are availble to generate the small·delay.
Time·to revisit your code now.
Post Edited (Ron Sutcliffe) : 6/5/2009 10:29:16 AM GMT
I have a provision on the first PropXMM-D40 prototypes for using gate delay to latch addresses, but decided the idea is too unreliable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Its provides plenty of headroom for people who want get up and running with C using VGA and serial keyboard.
Finding the extra pins for SDcard, is a problem but for those interested in Zilog and CPM a serial terminal it should be
fine (I think heater?)
Power users like yourself may decided to go with unlatched lines. Which makes me think that gating should be separated from
the memory board so that 128,256,512k memory can be implemented for those who wish to use it. Mind you I have piggy backed Sram on parallel SIPS before now and·used the bar CS line for paging.
Thanks Steve, would have taken me a while to sort it out on my own. I am very rusty having been cruising for five years.
I have another project lined up next. Not sure when I will get anything posted. No more ram projects
Ron
Post Edited (Ron Sutcliffe) : 6/6/2009 12:51:02 PM GMT
As discussed here is a circuit for a 1 mbyte x 32 bit external RAM that uses a serial interface.
It uses a minimum of 5 IO pins and a 6th pin if you want to deselect the RAM to save power.
It can be expanded up to a 24 bit address space.
I have not spent a lot of time checking it as this was knocked up while watching TV so if you find any erroneous connections let me know and I will update it
Cheers
David
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adaequatio Rei Et Intellectus
Post Edited (Praxis) : 6/6/2009 6:25:10 AM GMT
The next time you get a chance to watch a bit of TV, just throw in a Prop, Micro SD card, VGA and a PS2 socket in then it’s finished[noparse]:)[/noparse]
Sure the CCT can handle it, but are we not limited by the Props capacity to the drive the syncronous lines. Two longs to bit bang per transaction plus some overhead. I can't see it doing·better then·10MB/S with one cog, but there again it takes a little while for this stuff to sink in here. I need to turn the TV off to digest what you have done.
I was just re-working Steve’s code to fit with my final layout, then I will take a look at using a CPLD. I need to document it, before I put the project to bed.
It’s a been while since I have checked out the Praxis Group website.
Regards
Ron
Post Edited (Ron Sutcliffe) : 6/7/2009 1:25:52 AM GMT
Ron
Post Edited (Ron Sutcliffe) : 6/6/2009 4:25:14 PM GMT
For the circuit as drawn (1 mbyte) you only need to clock 52 bits.
I have not looked at or read up about the video generator in the prop so maybe this is a wrong assumption but would it be possible to use it to provide the clock source and perhaps the serial out data stream, if so it would reduce the software over head.
Cheers
David
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adaequatio Rei Et Intellectus
Post Edited (Praxis) : 6/6/2009 12:15:13 PM GMT
So even with a 40MBit/s solution that's only 5MB/s not counting any overheads. Is that worth the trouble?
I am not that familiar with SPI, but If you had separate SDI/SDO for each of the 74AHC299 chips It would use more pins, but wouldn't you get higher bandwidth?
Also, isn't the circuit drawn 1Mx32 or 4MB? Or maybe I am mistaken?
Thanks,
Doug
Having done a bit more tweaking.
The OUTA register now never changes for both read or write once initialized. The DIRA register now drives all the hardware further reducing the code by two instructions by my reckoning. (MAYBE, added in post edit)
The OE line on the ADR latch line is always tied true.
The low word OE read latch is common to ram OE, but is inverted to the low word OE write Latch.
The D read LE is inverted to D LE write.
The Ram WE, which is pulled, low is forced HIGH by the Prop WE line. Making a total on four control lines.
We now have.
OEL=OUT=L Inverted to Data OE ,
DL=OUT=L, Inverted to Data read
WE=OUT=H, Keeps RAM WE on ice
AL=OUT=L No Control is required over the ADR OE.
Ony the address latch is required.
Ron
Post Edited (Ron Sutcliffe) : 6/12/2009 2:50:48 AM GMT