Agreed, a PAL or similar is a pretty good idea here, if you can tolerate the relatively high ICC requirements and have the tools to design/test/burn it. Even if you use a PAL or equivalent, it is often helpful to use little 'tricks' like this to reduce I/O counts. One PAL implementation could use 2 22V10 style PALs, if you see a non-obvious trick: Implement address bits A0..A3 and A8..A11 in one PAL, and address bits A4..A7 and A12..A15 in the other. This reduces the number of inputs required to each chip, and still lets you output the address in the natual 2 byte (rather than 4 nibble) form. Bob Ammerman RAm Systems (high function, high performance, low-level software) ----- Original Message ----- From: Peter L. Peres To: Sent: Sunday, June 11, 2000 5:13 PM Subject: [EE]: PAL Tools - address counter > >From: Bob Ammerman > > >Re: accessing external RAM: > > > > >Assuming you are using '161 style counters to access 64KB of memory, here > >is a 12 I/O's solution: > > > Use 8 I/Os as a bidirectional address/data bus. Connect these I/O's to > > the > 8 data pins in the RAM, and to the D inputs of the two least > significant > '161 chips. > > The original solution for this as I remember it from digital design called > for all the 161's being daisy chained (inputs of next from outputs of > previous) with common load and clock enable. The controller would require > 6 bits to access the whole thing, four of which can be shared with the RAM > data bus. Incidentally this places the solution within range of 12 IO PICs > (like F84) with some more artifices used. The RAM would likely have the > /WE OR /OE gated directly from the clock or some other cunning logic to > drive them. This can have a midrange PIC operate ANY size of memory on 8 > bits. However, by the time all this is thought out and wired, a small PAL > or PEEL or other programmable logic chip will be preferred. The time of > such complex 'artifice' bunches is simply gone imho. > > Peter